Ines hat sich im Beitrag Flash: Umlaute in XML gewundert, wieso in Flash Sonderzeichen so komisch kodiert werden. Ich hätte es fast als Kommentar beantwortet, aber dann schien es mir sinnvoll zu sein, einen eigenen Beitrag zu schreiben. Hier mal zum Verständnis ein gekürzter Ausschnitt:
ä > %C3%A4
Warum Flash solch eine eigenartige hex-Interpretation der Umlaute benötigt, ist mir schleierhaft. Ich konnte es jedenfalls nicht anhand einer ASCII-Tabelle nachvollziehen.
Eigentlich macht Flash gar nichts komisches sondern eine reine Kodierung in UTF-8. Um das zu erklären, muss man etwas weiter ausholen. Früher gab es die »ASCII-Tabellen«. Ein Zeichen wurde als ein Byte kodiert, d.h. bei 256 Zeichen ist Schluss. Die Lösung bestand darin, dass es nicht nur eine ASCII-Tabelle gab, sondern viele für verschiedene Sprachen und Alphabete. Beispiele für solche sogenannten Codepages oder Zeichensätze sind cp1252 oder iso8859-15. Die ersten 127 Plätze der Tabelle waren immer gleich, man sprach von 7-Bit-ASCII, darunter fallen z.B. Ziffern und das normale lateinische Alphabet, Sonderzeichen wie das kleine ä wurden in der anderen Hälfte kodiert.
Diese vielen Codepages stellen natürlich eine erhebliche Einschränkung dar, deswegen wurde Unicode entwickelt. Die einfachste Variante wäre es, statt ein Byte pro Zeichen einfach mehrere zu nehmen, bei UTF-16 und UTF-32 wird das auch so gemacht. Für Texte mit einem geringen Zeichenvorrat ist das aber Verschwendung von Speicherplatz, immerhin konnte man auch in iso8859 ganze Texte abbilden, ohne dass einem Zeichen fehlen und die wären gegenüber einer Kodierung mit konstant zwei Byte pro Zeichen nur halb so groß.
Deswegen gibt es UTF-8. Der Trick ist nun, dass in UTF-8 Zeichen mit unterschiedlich vielen Bytes kodiert werden können – es gibt 1-Byte-, 2-Byte-, 3-Byte und 4-Byte-Zeichen. Öffnet man einen Texteditor, legt eine UTF-8-Datei an, schreibt das kleine ä hinein und betrachtet das Ergebnis dann in einem Hex-Editor, sieht man dass es sich um ein 2-Byte-Zeichen handelt: C34A.
Wieso kann man diesen Wert nun nicht einfach so in einer Unicode-Tabelle nachschlagen? Das liegt daran, dass man in einem Strom von Zeichen ja auch die 1-Byte von den 2-Byte-Zeichen (und natürlich von den noch längeren) unterscheiden können muss. Wenn ich Zeichen a mit 8 kodieren würde, b mit 9 und ß mit 89, woran sehe ich dann, ob es ab ist oder ß? Deswegen werden bei UTF-8 nie alle acht Bit eines Bytes zum Speichern des eigentlichen Inhalts verwendet.
Um das zu erklären hilft zunächst ein Blick auf eine Unicode-Tabelle, z.B. auf decodeunicode.org, diese Tabelle gibt es nämlich trotzdem. Dort hat jedes Zeichen eine Zahl zugeordnet. So können die gleichen Zeichen mit dem gleichen Platz in der Unicode-Tabelle in verschiedenen Kodierungen wie eben UTF-8 und UTF-16 kodiert werden.
Das kleine ä hat also in Unicode den Platz 00E4 in Hexadezimal, das entspricht 228 im Dezimalsystem. Als nächstes hilft ein Blick auf Wikipedia. Dort sieht man, dass es in UTF-8 spezielle Markerbits gibt. Ich zeige das mal anhand vom oben erwähnten C3A4:
1100 0011 1010 0100
Diese Bits zeigen an, dass es sich um ein 2-Byte-Zeichen handelt. Wenn ich diese Bits jetzt wegstreiche, bleibt folgendes übrig:
000 1110 0100
Die führenden Nullen noch weg und dann ist das hexadezimal wieder genau E4 und dezimal 228, also genau der Platz vom kleinen ä in der Unicode-Tabelle. Die Bits des E4 werden also zusammen mit dem, was ich oben Markerbits genannt habe, in die Zwei Byte des C3A4 gepackt. Bei Zeichen, die weiter hinten stehen in der Unicode-Tabelle, werden die entsprechenden Bits dann eben auf drei oder vier Bytes verteilt. Kurz und gut, sieht alles komisch aus, ist aber keine Hexerei.
