Artwork

Inhalt bereitgestellt von Stefan Majewsky and Xyrillian Noises. Alle Podcast-Inhalte, einschließlich Episoden, Grafiken und Podcast-Beschreibungen, werden direkt von Stefan Majewsky and Xyrillian Noises oder seinem Podcast-Plattformpartner hochgeladen und bereitgestellt. Wenn Sie glauben, dass jemand Ihr urheberrechtlich geschütztes Werk ohne Ihre Erlaubnis nutzt, können Sie dem hier beschriebenen Verfahren folgen https://de.player.fm/legal.
Player FM - Podcast-App
Gehen Sie mit der App Player FM offline!

STP013: Textkodierung

1:10:24
 
Teilen
 

Manage episode 316735934 series 2920733
Inhalt bereitgestellt von Stefan Majewsky and Xyrillian Noises. Alle Podcast-Inhalte, einschließlich Episoden, Grafiken und Podcast-Beschreibungen, werden direkt von Stefan Majewsky and Xyrillian Noises oder seinem Podcast-Plattformpartner hochgeladen und bereitgestellt. Wenn Sie glauben, dass jemand Ihr urheberrechtlich geschütztes Werk ohne Ihre Erlaubnis nutzt, können Sie dem hier beschriebenen Verfahren folgen https://de.player.fm/legal.

Dies ist ein Text. Für den Computer besteht er nur aus Zahlen. Xyrill erklärt diesmal, wie es kommt, dass wir ihn trotzdem lesen können. Und jedes andere geschriebene Wort, das je existiert hat… natürlich nur idealtypisch.

Shownotes

Laut Wiktionary:

[Text ist eine] mündliche oder schriftliche Folge von Sätzen, die miteinander syntaktisch und semantisch verbunden sind (Kohärenz, Kohäsion), eine abgeschlossene Einheit bilden (Kompletion) und eine bestimmte kommunikative Funktion (Textfunktion) erfüllen.

[Von] lateinisch textus für "Inhalt" oder "Gewebe der Rede", "Text".

  • zur Definition

    • Wiktionary geht vom linguistischen Blickwinkel aus
    • in der Informatik: Zeichenketten (oder synonym "Zeichenfolgen"), in Programmiersprachen meist als String bezeichnet
  • Problem: Computer können nur Zahlen! Wie bilden wir Zeichenketten als Zahlenfolgen ab?

    • Idee 1: jedes Zeichen als eine Zahl einer bestimmten Größe, z.B. 1 Byte oder 2 Byte (fixed-length code)
      • primitives Beispiel: alle Buchstaben des Alphabets durch ihre Position darstellen, z.B. "hallo" -> "08 01 12 12 15"
    • Idee 2: häufige Zeichen mit kurzen Bytefolgen darstellen, seltene Zeichen mit längeren Bytefolgen (variable-length code, siehe Entropiekodierung)
  • Beispiel: Morse-Code

    • variable Länge: z.B. "e" ist am häufigsten und deswegen nur 1 Ton kurz, "q" ist sehr selten und deswegen 4 Töne lang
    • Kodiertabelle enthält nicht nur Buchstaben und Ziffern, sondern auch Sonderzeichen (Punkt, Komma, etc.) und Spezialzeichen wie "Spruchende" oder "Fehler, Wiederholung ab letztem vollständigem Wort"
  • in der frühen Informatik (bis in die 1990er Jahre): Codepages (Zeichentabellen)

    • Codes mit fester Länge von meist 1 Byte (7 oder 8 Bit) pro Zeichen
    • Beispiel mit 7 Bit: ASCII, unter Linux siehe man ascii (RFC 20)
    • Beispiel mit 8 Bit: Codepage 437
    • Standardisierung als ISO/IEC 8859
    • Problem: 8 Bit (256 Zeichen) sind zu wenig für alle in europäischen Sprachen verwendeten Zeichen, insb. wegen diakritischer Zeichen -> verschiedene Codepages für verschiedene Sprachen -> Mojibake
    • spätestens mit zunehmend globaler Kommunikation im Internetzeitalter musste eine bessere Lösung her
  • Unicode

    • keine Textkodierung im engeren Sinne, sondern erstmal nur eine durchnummerierte Liste aller möglichen Zeichen (die Nummer zu einem Zeichen heißt Codepunkt)
    • Anspruch: wenn ein Zeichen in tatsächlichen Textdokumenten verwendet wird oder wurde, gehört es in Unicode (von Buchstaben über Redigierungssymbole mittelalterlicher Typografen bis zu Hieroglyphen und Keilschrift)
    • Größe: 17 Ebenen (Planes) zu je 65536 Codepunkten = 1.114.112 Codepunkte; davon sind 2048 Codepunkte aus technischen Gründen (für die Kodierung von Surrogatpaaren) unbelegbar, somit maximal möglich 1.112.064 Codepunkte
  • Ebenen in Unicode

    • Ebene 0: Basic Multilingual Plane mit allen zeitgenössischen und weitverbreiteten Schriftsystemen (Übersichtskarte)
    • Ebene 1: Supplementary Multilingual Plane mit historischen Schriftsystemen und Obskuritäten wie Domino/Mahjongg-Steinen und 😍 Emoji 😍
    • Ebene 2: Supplementary Ideographic Plane mit selten benutzten CJK-Schriftzeichen
    • Ebene 3-13: noch frei
    • Ebene 14: Supplementary Special-purpose Plane mit Steuerzeichen zur Selektion alternativer Schriftzeichenformen
    • Ebene 15/16: für private Verwendung reserviert
  • Kodierungen für Unicode mit fixer Länge

    • UCS-2: eine 16-Bit-Zahl pro Zeichen -> kann nur die BMP kodieren (UCS-2 stammt aus der Zeit, bevor Unicode mehrere Planes hatte)
    • UCS-4/UTF-32: eine 32-Bit-Zahl pro Zeichen -> extrem verschwenderisch
  • Kodierungen für Unicode mit variabler Länge

    • UTF-16: BMP-Zeichen als eine 16-Bit-Zahl, andere Zeichen als zwei 16-Bit-Zahlen -> Probleme mit Endianness
    • UTF-8: jedes ASCII-Zeichen als ein Byte, alle anderen Zeichen als eine Folge von 2-5 Bytes (unter Linux siehe man utf-8)
    • UTF-8 ist spektakulär: sehr kompakt, selbstsynchronisierend, einfach zu implementieren (auch in Hardware), sortierungserhaltend, ASCII-abwärtskompatibel, Nicht-ASCII-Zeichen enthalten niemals ASCII-Bytes; und wurde buchstäblich in einem Abend von Ken Thompson und Rob Pike auf einer Serviette entworfen
  • Probleme von Unicode

    • Anspruch: jeder bestehende Kodierungsstandard soll Zeichen für Zeichen in Unicode abbildbar sein -> dadurch unnötig viele Codepunkte insb. für diakritische Zeichen und Probleme mit Normalisierung
    • allgemeiner: Was ist eigentlich ein Zeichen im Sinne von "ein Codepunkt"? (mehr dazu in der nächsten Folge) -> Unicode übernimmt hier oftmals teils kontroverse Klassifikationen aus nationalen Standards z.B. für indische und thailändische Schriften
    • am signifikantesten hier: Han-Vereinheitlichung (Beispiel)

Für die historische Herleitung von Schriftkodierung empfehlen wir wieder den großartigen Podcast Request for Comments. Diesmal die Folge über RFC 20 ASCII.

Das nächste Mal geht es dann um T̪͙̪̻̹̩̠͔͑͋ͥ͘ę̥͔̝̘ͦͬx̨̜̩̜͙̦̻̗̳̒̊͆t̯̳̓ͥ͐ͣd͔̱̗̯̪̭́͛͜ͅa̵͕̯͕̻̜ͮ͒ͭȓ̜͚͚̯͎͓̋̎̈́͘s̥̯̠̬̆̿͡t̫̱̺͉̱̓͒͑͐͢e̸͖̮̙̺̠̗̬̅ͅl̝͉͚ͪ͋ͤ͜l̵̦̪͔͈̉͑u̴̝̲̠̳̖̘͚̔n͙̹̍̆͊̈͢g̨͍̣̝̣͇̯̮̠̏.

  continue reading

53 Episoden

Artwork
iconTeilen
 
Manage episode 316735934 series 2920733
Inhalt bereitgestellt von Stefan Majewsky and Xyrillian Noises. Alle Podcast-Inhalte, einschließlich Episoden, Grafiken und Podcast-Beschreibungen, werden direkt von Stefan Majewsky and Xyrillian Noises oder seinem Podcast-Plattformpartner hochgeladen und bereitgestellt. Wenn Sie glauben, dass jemand Ihr urheberrechtlich geschütztes Werk ohne Ihre Erlaubnis nutzt, können Sie dem hier beschriebenen Verfahren folgen https://de.player.fm/legal.

Dies ist ein Text. Für den Computer besteht er nur aus Zahlen. Xyrill erklärt diesmal, wie es kommt, dass wir ihn trotzdem lesen können. Und jedes andere geschriebene Wort, das je existiert hat… natürlich nur idealtypisch.

Shownotes

Laut Wiktionary:

[Text ist eine] mündliche oder schriftliche Folge von Sätzen, die miteinander syntaktisch und semantisch verbunden sind (Kohärenz, Kohäsion), eine abgeschlossene Einheit bilden (Kompletion) und eine bestimmte kommunikative Funktion (Textfunktion) erfüllen.

[Von] lateinisch textus für "Inhalt" oder "Gewebe der Rede", "Text".

  • zur Definition

    • Wiktionary geht vom linguistischen Blickwinkel aus
    • in der Informatik: Zeichenketten (oder synonym "Zeichenfolgen"), in Programmiersprachen meist als String bezeichnet
  • Problem: Computer können nur Zahlen! Wie bilden wir Zeichenketten als Zahlenfolgen ab?

    • Idee 1: jedes Zeichen als eine Zahl einer bestimmten Größe, z.B. 1 Byte oder 2 Byte (fixed-length code)
      • primitives Beispiel: alle Buchstaben des Alphabets durch ihre Position darstellen, z.B. "hallo" -> "08 01 12 12 15"
    • Idee 2: häufige Zeichen mit kurzen Bytefolgen darstellen, seltene Zeichen mit längeren Bytefolgen (variable-length code, siehe Entropiekodierung)
  • Beispiel: Morse-Code

    • variable Länge: z.B. "e" ist am häufigsten und deswegen nur 1 Ton kurz, "q" ist sehr selten und deswegen 4 Töne lang
    • Kodiertabelle enthält nicht nur Buchstaben und Ziffern, sondern auch Sonderzeichen (Punkt, Komma, etc.) und Spezialzeichen wie "Spruchende" oder "Fehler, Wiederholung ab letztem vollständigem Wort"
  • in der frühen Informatik (bis in die 1990er Jahre): Codepages (Zeichentabellen)

    • Codes mit fester Länge von meist 1 Byte (7 oder 8 Bit) pro Zeichen
    • Beispiel mit 7 Bit: ASCII, unter Linux siehe man ascii (RFC 20)
    • Beispiel mit 8 Bit: Codepage 437
    • Standardisierung als ISO/IEC 8859
    • Problem: 8 Bit (256 Zeichen) sind zu wenig für alle in europäischen Sprachen verwendeten Zeichen, insb. wegen diakritischer Zeichen -> verschiedene Codepages für verschiedene Sprachen -> Mojibake
    • spätestens mit zunehmend globaler Kommunikation im Internetzeitalter musste eine bessere Lösung her
  • Unicode

    • keine Textkodierung im engeren Sinne, sondern erstmal nur eine durchnummerierte Liste aller möglichen Zeichen (die Nummer zu einem Zeichen heißt Codepunkt)
    • Anspruch: wenn ein Zeichen in tatsächlichen Textdokumenten verwendet wird oder wurde, gehört es in Unicode (von Buchstaben über Redigierungssymbole mittelalterlicher Typografen bis zu Hieroglyphen und Keilschrift)
    • Größe: 17 Ebenen (Planes) zu je 65536 Codepunkten = 1.114.112 Codepunkte; davon sind 2048 Codepunkte aus technischen Gründen (für die Kodierung von Surrogatpaaren) unbelegbar, somit maximal möglich 1.112.064 Codepunkte
  • Ebenen in Unicode

    • Ebene 0: Basic Multilingual Plane mit allen zeitgenössischen und weitverbreiteten Schriftsystemen (Übersichtskarte)
    • Ebene 1: Supplementary Multilingual Plane mit historischen Schriftsystemen und Obskuritäten wie Domino/Mahjongg-Steinen und 😍 Emoji 😍
    • Ebene 2: Supplementary Ideographic Plane mit selten benutzten CJK-Schriftzeichen
    • Ebene 3-13: noch frei
    • Ebene 14: Supplementary Special-purpose Plane mit Steuerzeichen zur Selektion alternativer Schriftzeichenformen
    • Ebene 15/16: für private Verwendung reserviert
  • Kodierungen für Unicode mit fixer Länge

    • UCS-2: eine 16-Bit-Zahl pro Zeichen -> kann nur die BMP kodieren (UCS-2 stammt aus der Zeit, bevor Unicode mehrere Planes hatte)
    • UCS-4/UTF-32: eine 32-Bit-Zahl pro Zeichen -> extrem verschwenderisch
  • Kodierungen für Unicode mit variabler Länge

    • UTF-16: BMP-Zeichen als eine 16-Bit-Zahl, andere Zeichen als zwei 16-Bit-Zahlen -> Probleme mit Endianness
    • UTF-8: jedes ASCII-Zeichen als ein Byte, alle anderen Zeichen als eine Folge von 2-5 Bytes (unter Linux siehe man utf-8)
    • UTF-8 ist spektakulär: sehr kompakt, selbstsynchronisierend, einfach zu implementieren (auch in Hardware), sortierungserhaltend, ASCII-abwärtskompatibel, Nicht-ASCII-Zeichen enthalten niemals ASCII-Bytes; und wurde buchstäblich in einem Abend von Ken Thompson und Rob Pike auf einer Serviette entworfen
  • Probleme von Unicode

    • Anspruch: jeder bestehende Kodierungsstandard soll Zeichen für Zeichen in Unicode abbildbar sein -> dadurch unnötig viele Codepunkte insb. für diakritische Zeichen und Probleme mit Normalisierung
    • allgemeiner: Was ist eigentlich ein Zeichen im Sinne von "ein Codepunkt"? (mehr dazu in der nächsten Folge) -> Unicode übernimmt hier oftmals teils kontroverse Klassifikationen aus nationalen Standards z.B. für indische und thailändische Schriften
    • am signifikantesten hier: Han-Vereinheitlichung (Beispiel)

Für die historische Herleitung von Schriftkodierung empfehlen wir wieder den großartigen Podcast Request for Comments. Diesmal die Folge über RFC 20 ASCII.

Das nächste Mal geht es dann um T̪͙̪̻̹̩̠͔͑͋ͥ͘ę̥͔̝̘ͦͬx̨̜̩̜͙̦̻̗̳̒̊͆t̯̳̓ͥ͐ͣd͔̱̗̯̪̭́͛͜ͅa̵͕̯͕̻̜ͮ͒ͭȓ̜͚͚̯͎͓̋̎̈́͘s̥̯̠̬̆̿͡t̫̱̺͉̱̓͒͑͐͢e̸͖̮̙̺̠̗̬̅ͅl̝͉͚ͪ͋ͤ͜l̵̦̪͔͈̉͑u̴̝̲̠̳̖̘͚̔n͙̹̍̆͊̈͢g̨͍̣̝̣͇̯̮̠̏.

  continue reading

53 Episoden

Alle Folgen

×
 
Loading …

Willkommen auf Player FM!

Player FM scannt gerade das Web nach Podcasts mit hoher Qualität, die du genießen kannst. Es ist die beste Podcast-App und funktioniert auf Android, iPhone und im Web. Melde dich an, um Abos geräteübergreifend zu synchronisieren.

 

Kurzanleitung