Shift JIS, EUC, Utf-8? Oder doch lieber ISO-2022-JP?

Da es hier seit Tagen ununterbrochen regnet, wird es mal Zeit, länger über ein besonderes Thema zu schreiben. Nämlich über meinen täglichen Kampf mit dem Japanischen. Offline kein grosses Thema mehr, da ich sowieso fast nur noch Japanisch spreche. Aber als Web-Systementwickler eröffnen sich da Abgründe.
Da japanische Schriftzeichen komplexer sind als lateinische Buchstaben, benutzt man hierzulande (wie auch in China und Korea) Multi-Byte-Zeichen – bei lateinischen Buchstaben Single-Byte-Zeichen. Das bedeutet, dass mit diesen Zeichen bei der Datenverarbeitung ganz anders umgegangen werden muss. Man kann nicht einfach Byte für Byte Text verarbeiten – da kommt nur Salat heraus.
Dummerweise gibt es viele verschiedene Kodierungsformen. Wer bei seinem Browser mal bei Dekodierung nachschaut und Japanisch-Unterstützung aktiviert hat, wird unter anderem Shift-JIS, EUC-JP, UTF 8 und vielleicht noch JIS (bzw. ISO-2022-JP) vorfinden.
Einfach mal EUC zum Beispiel wählen und schauen, wie sich das Japanisch auf diesen Seiten ändert. Genau da liegt der Hase im Pfeffer.
Das Gros der japanischen Internetseiten wird mit Shift-JIS kodiert – von Systementwicklern auch gern Shit-JIS genannt (JIS = Japanese Industrial Standard, japanische ISO). Warum dieser elegante Spitzname? Shift-JIS wird zum Alptraum, sobald man Datenbanken wie MySQL oder PostgreSQL einsetzt. Die Folgen sind meistens katastrophal – Zeichen werden willkürlich zerstört.
Deshalb breitet sich allmählich EUC aus (z.B. benutzt von XOOPS) aber mehr noch (und das ist begrüssenswert) UTF-8 (z.B. bei Joomla, phpBB, Moodle, Movable Type & Konsorten und natürlich auch auf diesem Blog.
Schön und gut, könnte man jetzt sagen. Wenn UTF-8 so toll ist, dann nehmt das doch als Standard! Pustekuchen. Für Emails zum Beispiel gelten andere Regeln. E-Mails können UTF-8 sein, sogar EUC oder notfalls Shift-JIS. Aber der Absender und die Betreffzeile müssen auf jeden Fall in einem Format sein – JIS (bzw. ISO-2022-JP). Wenn nicht, ist bestenfalls die Betreffzeile und der Absender nicht lesbar. Schlimmstenfalls kommt die Mail schlichtweg nicht an oder ist leer. Deshalb sieht der Header einer japanischen Email so aus:
Subject: =?ISO-2022-JP?B?GyRCJSolaSVHJSIkTiVWJW0lMBsoQg==?= - das ist die Betreffzeile!!!!
MIME-Version: 1.0
Content-Type: text/plain; charset=EUC-JP; format=flowed
Content-Transfer-Encoding: 7bit
Genau, eine japanische Mail kann aus zwei Kodierungen bestehen: eine für den Header, die andere für den Rest. Der Einfachheit halber wird aber der Grossteil der Mails heuer komplett in JIS kodiert.
PHP z.B. hat deshalb auch eine ganze Phalanx von Befehlen, die für diesen Zweck entwickelt wurden. So sind für Programmierer in Japan so ziemlich alle mb_-Befehle von elementarer Bedeutung. Auch Regex funktioniert hier anders. So ist es zum Beispiel manchmal nötig, Double-Byte-Leerzeichen mit Single-Byte-Leerzeichen zu ersetzen. Ein Heidenspass!
Was bedeutet das alles für einen ausländischen Systementwickler in Japan? Ganz einfach. Man kann noch so schöne Systeme im Ausland auftreiben – OpenSource oder nicht – es ist schlichtweg nicht damit getan, die Sprache der Oberfläche zu ändern. Man muss die Datenbankkonfiguration ändern. Die ganzen Funktionen zur Datenbankverbindung und zum Senden von Mails. Eingabefelder müssen geändert werden. Aus diesem Grunde verläuft deshalb auch leider die Entwicklung einiger Open Source CMS wie XOOPS in Japan (extrem beliebt hier) abgekoppelt vom Rest der Welt. Das japanische XOOPS hat andere Versionsnummern und Probleme mit ausländischen Modulen.
Ein echter Alptraum sind die sogenannten 機種依存文字 (kishu izon moji – plattformabhängige Zeichen). Eine geniale Erfindung! Da gibt es Zeichen, die nur auf NEC-Computern benutzbar sind. Andere sind nur auf Windows (ab XP) erkennbar. Andere nur auf Mac OS Tiger. Man versuche einem User mal zu erklären, dass er beim Ausfüllen eines Formulars doch bitte diese Zeichen nicht benutzen möge! Zumal diese schrägen Zeichen oftmals gern in Adressen – beim Namen des Hauses benutzt werden. Zum Beispiel Hill Mansion IV, wobei die römische Vier ein plattformabhängiges Double-(oder auch Multibyte-)Zeichen ist, das, sobald man es in eine Datenbank stopft oder mailgerecht in JIS umwandelt, das ganze System sprengt.
Geben wir mal auf einem Apple (Mac OS Tiger 10.4.9) die Zahl 7 ein und sehen, was der native IME (Input Method Editor) uns bietet:
2) ist eine grosse römische 7 – Multi-Byte.
3) ist eine Double-Byte-7 (auf Japanisch 全角 – zenkaku).
4) ist eine Single-Byte-7 (auf Japanisch 半角 – hankaku) wie sie auch jeder andere Computer und jede Datenbank versteht.
5) ist das Schriftzeichen – Multi-Byte natürlich.
Die Zeichen rechts mit den Warndreiecken sind plattformabhängige Zeichen und potenziell reif dafür, misinterpretiert zu werden.

Man beachte die Warndreiecke an den Zeichen: Hier kommt die Meldung „Diese Auswahl enthält Zeichen, die nicht im JIS enthalten sind“. Will heissen, versenden in Emails geht nicht – zumindest in JIS. Shift-JIS geht auch nicht. Und das aufspüren und ersetzen dieses Zeichens mit regex, ob perl oder php, kann man auch vergessen.

Auch hier eine Warnung: Dieses Zeichen gehört zum neuen JIS-Satz. Computer mit Windows 98 z.B. können sich noch so anstrengen – das Zeichen wird nicht dargestellt.
In Windows erscheint auch eine Vielzahl von Zeichen, wenn man die 7 eingeht. Leider ohne Warnungen. Hier wird Zeichen 6) aus der Liste gewählt, und man sieht oben schon das Ergebnis: ein Kästchen. Stimmen Font UND Kodierung nicht, kann man dieses Zeichen nicht benutzen. Wie auch Nr 3, 4, 5, 7, 8, 9 auf der linken Seite und die oberen 5 auf der rechten Seite.
Dies ist nur ein seichtes Kratzen an der Oberfläche. Bei Bedarf schreibe ich später mehr dazu, aber dieser Artikel ist wohl schon lang genug.
Das Wort des Tages: 文字化け mojibake – „veränderte Zeichen“. Ein leidliches Problem in Japan – aufgrund eines Eingabe- oder Programmierfehlers gehen Zeichen verloren oder werden falsch dargestellt.