Geschichte: Wie es zu dem Durcheinander mit den Encodings kam

encodings-erklaert.txt

Das mit den Kodierungen ist so:
Als die Welt nur 127 Zeichen hatte, war noch alles einfach. Wir haben in jedes Byte ein Zeichen kodiert, und die Zuordnung von numerischem Wert zu Zeichen wurde standardisiert: ASCII. Das A hat den Wert 65 bekommen, das B die 66, usw. Kleinbuchstaben fangen bei 97 an, Zahlen bei 48.
Irgendwann haben dann irgendwelche Europäer gemeint, es gäbe ja noch viel mehr Zeichen.
ANSI ist das, was den Europäern als Lösung eingefallen ist. Die haben einfach auf die 127 Zeichen nochmal 128 drauf gesetzt.
255 Zeichen sollten ja wohl genug sein.
Aber die Russen haben gemeint, sie seien vergessen worden, und haben auf die 127 Zeichen ihre eignen 128 drauf gesetzt. KOI8R hiess das.
Das heisst, wenn man eine 65 in seiner Datei hatte, wurde das jetzt bei Russen, Europäern und Amis als A angezeigt, aber wenn man eine 132 hat, ist das bei Amerikanern ungültig, bei (West-)Europäern ein ä, und bei Russen ... irgendwas kyrillisches.
Man musste also plötzlich wissen, welchem Standard die Datei folgt (Encoding).
Und dann kamen die ganzen Asiaten und meinten, sie wollten auch sowas, aber 128 zusätzliche Zeichen reichen ihnen nicht.
Also haben wir uns geeinigt, wir machen das ganz anders. Wir ordnen jedem Buchstaben aus jedem Alphabet eine eindeutige Zahl zu. Nichts mehr mit 132 ist entweder ä oder æ oder ...
Aber natürlich sind das mehr als 256 Zeichen, passt also nicht mehr in ein einzelnes Byte.
Anfangs meinte man, na, dann halt zwei Bytes nehmen.
Jetzt musste man dann wissen, ob die Datei ein 8-bit Encoding hatte, und wenn ja, welches, oder 16-bit Zeichen benutzt.
Und wenn 16 bit (2 bytes), dann auch noch, in welcher Reihenfolge man die Bytes speichert.
denn da gab es zwei Sorten CPU-Architekturen, die das verscheiden machten.
Dafür ist der BOM (Byte Order Mark) erfunden worden. Da stehe in den ersten 3 Bytes der Datei "ich bin eine 16-bit Datei, und das signifikante Byte kommt als erstes (oder als zweites)"
16 bit gibt 64 K verschiedene Zeichen. Das reicht für alle lebenden Sprachen.
Aber dann kamen die Klingonen, und die Leute, die babylonische Schriften analysieren, und meinten, sie bräuchten auch Computer.
So, 64 K Zeichen (16 bit) reichen nicht. 3 Bytes sind eine unhandliche Größe, deswegen hat man dann gesagt "wir lassen halt 4 Milliarden Zeichen zu, 4 bytes sind prima"
4 Bytes pro Zeichen ist aber eine Menge Speicher, besonders wenn man Amerikaner ist, und früher nur eins brauchte. Mein Bibeltext har früher auf eine Diskette gepasst, und ist jetzt viermal so groß!
**old man yells at cloud.gif**
Also ist man auf die schlaue Idee gekommen, man könnte doch einfach komprimieren. Und zwar so: Wenn das Zeichen Teil von ASCII ist (also nur 7 bits braucht, weil einen Codepoint von 0-127 hat), dann schreiben wir einfach nur dieses eine Byte.
Codepoint habe ich nicht erklärt: Das ist die Zahl, die einem Zeichen zugeordnet wurde (also 65 für unser A)
Die Codepoints verteilt das Unicode-Konsortium.
Aber wenn wir ein Zeichen schreiben wollen, dessen Codepoint mehr als 7 bits braucht, dann schreiben wir die niedrigen 7 bit davon, und setzen das achte bit auf 1, um zu signalisieren "hier kommt noch ein byte"
und in das nächste byte schreiben wir dann die nächsten 7 bit von unserem Codepoint. und wenn das gereicht hat ist gut, ansonsten setzen wir wieder bit 8, und so fort.
jetzt sind ASCII-Texte wieder ein Byte pro Zeichen groß, aber das Lesen der Datei ist für alls Nicht-Angelsachsen schwieriger geworden, und ein Zeichen kann auf bis zu 6 Bytes ausgedehnt sein, weil wir ja den Extra-Platz für diese Signalbits brauchen.
Das passiert aber zum Glück nur für dummes Zeug das spät dazu gekommen ist, wie Emojis.
Das Verfahren heisst UTF-8
Jetzt muss ich wieder wissen, dass die Datei UTF-8 ist, damit ich diese komplizierte Dekoding mache.
Und noch schlimmer, wenn ich eine ANSI-Datei habe, wie sie aus Vorlage kommt, sind da lauter Zeichen drin, in denen das achte Bit gesetzt, insbesondere bei Umlauten. Und ein UTF-8 Dekoder der das sieht, denkt "davon brauche ich nur die ersten 7 Bit, und dann das nächste Byte". Und weil die resultirende Zahl dann schön groß wird, liegt sie irgendwo in dem Raum, wo die ganzen chinesischen Ideogramme sind.
Das gleiche ist auch vorher schon passiert, wenn ein Programm, das 16-bit Zeichen erwartete z.B. eine ASCII-Datei bekommen hat.
Weil die z.B. keinen BOM hatte.
Zur Vervollstängigung hat man zu UTF8 auch noch einen BOM definiert, obwohl die Bytes da nicht "umgekehrt" sein können, aber um klar erkennen zu können, das eine Datei eben NICHT 16-bit kodiert ist, was damals noch total üblich war.
In vielen asiatischen Märkten auch jetzt noch, weil deren Zeichen mit 16-bit weniger Speicher brauchen als mit UTF-8, und ihnen klingonisch egal ist.
so, das ist meine kurze Geschichte der Encodings, schwer vereinfacht, und evtl. teilweise verkehrt.