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.
Danke, jetzt weiß ich endlich, was zum Teufel das Problem mit den Emails nach Japan ist. Mit UTF8 kann es also gar nicht funktionieren. Aber woran liegts? Warum ausgerechnet nur JIS?
Warum nur JIS? Gute Frage! Dieser Standard hat sich ebend irgendwann durchgesetzt und bleibt bestehen. Das wird sich wohl auch nicht so schnell ändern.
Ich kenne die Konfiguration Deines Rechners nicht, aber von deutschem Windows XP / Vista und von Macs sowieso kann man eigentlich problemlos japanische Mails schicken. Erst beim programmieren muss man ebend aufpassen.
Im Grunde klappt es meistens (Win2k/XP), aber gelegentlich habe ich auf der anderen Seite einen Japaner, der dann nur Schrott empfängt. Gerade bei irgendwelchen Webmail-Providern. Ist vielleicht das Äquivalent zum GMX-Problem.
Doch nochmal eine Frage. Hast du Erfahrungen damit, japanischen Text einfach zu gzcompressen und dann als BLOB (Binary Large Object) zu speichern, um sich den Ärger mit der Datenkorruption zu ersparen.
Ja, das geht – das japanische Drupal zum Beispiel speichert nahezu alles als BLOB. Trotzdem – lieber Finger weg von Shift-JIS.
Naja, das Projekt, dass hier an der Uni angedacht ist, ist eh ein typischer Fall für Unicode, da sich Japanisch und Umlaute nicht all zu gut auf einer Seite in irgendeiner anderen Kodierung machen lässt.
Ich verstehe nicht viel von der Materie, aber weiß nicht wohin mit meiner Frage:
Wenn ich bei Firefox Mails bei einem Onlinemail-Service empfange, kann ich mit der Einstellung Japanisch (ISO-2022-JP) zwar den Inhalt der Mail lesen, aber der Betreff besteht nach wie vor aus komischen Zeichen.
Bei Mozillas hauseigenem Thunderbird-Mail-Programm klappt alles wunderbar. Inhalt + Betreff in Japanisch.
Woran liegt das?
Mit sehr hoher Wahrscheinlichkeit an Deinem Online-Mailservice. Da wirst Du auch nicht viel machen können. Da hilft nur Mailservice wechseln – Hotmail & Co sind komplett internationalisiert.
Und wennman die Anhänge mit Kanji im Dateinamen abspeichert, dann habe ich im Explorer (Windows XP) nur z.B. ____.doc stehen…
Ist das ein Problem, welches in den Griff zu bekommen ist?
Stefan
@Stefan
Es gibt Lösungen dafür, aber prinzipiell würde ich jedem raten, Dateien nicht mit Sonderzeichen zu versehen.
Ich benutze gelegentlich japanisches XP zu Hause und habe jedes Mal Probleme, wenn mir jemand etwas mit Umlauten im Dateinamen schickt.
Andersrum gilt das Gleiche. Auf Mac kein Problem, aber für Windows nachwievor ein Thema.
Hallo!
Kann mir bitte jemand in einfachen Worten erklären, wie ich es schaffe, dass meine auf englisch geschriebene Email in Japan ankommt? Möchte eigentlich nur eine Anfrage an ein Hotel schicken. Aber die meisten kommen zurück!
HILFE!!!
Lieben Dank, Nicole
Es wäre allerdings auch von Vorteil zu erwähnen das Unicode Probleme damit hat Zeichen darzustellen.
Besonders UTF-8 ist überhaupt nicht fit genug Japanisch akkurat wiederzugeben.
Zwei Hauptprobleme sind:
1. Keine eigene Speicherung von historischen Zeichen = Keine Unterscheidung
2. Fonts im Ausland (wenn nicht Jap.) nutzen generell die chinesische Darstellung von Kanji = Nicht wirklich attraktiv zu wissen das etwas falsch angezeigt wird.
In den nächsten 5 Jahren wo als UTF-8 Standard dann also nicht MS Mincho sondern meinetwegen Arial installiert ist bedeutet das nur Probleme.
Mit UTF-16 oder UTF-32 mag das anders sein – da gibt es aber ganz andere Probleme.
Datenmenge und Übertragung zB -_-‘
Grüße
@寛郎: Tut mir leid aber die von dir genannten Probleme sind Unicode typisch und über sämtliche Implementierungen (UTF-8, UTF-16 und UTF-32 – egal ob little oder big endian) vorhanden. Sämtliche dieser Kodierungen basieren auf dem gleichen Standard. In UTF-8 können die selben Zeichen kodiert werden, die auch in UTF-* kodierbar sind.
Allgemein weise ich mal für die Softwareentwickler hier auf Ruby hin. Ab der Version 1.9 kann da Encodingtechnisch sehr elegant gearbeitet werden. RegExps funktionieren z.B. im Gegensatz zu PHP (und eigentlich allen anderen Sprachen) einwandfrei auch mit Shift-JIS, EUC oder Unicode.
Das ist ein wirkich spannendes Thema, mit dem ich mich auch gerade beschäftige.
Nur zur der Menge der betroffenen Zeichen bekomme ich leider überhaupt keine Infos. Vielleicht weißt du da ja mehr:
Wieviele Zeichen gehen eigentlich im Schnitt bei einer Umwandlung von Shift_JIS in UTF8 verlohren? 10%? Mehr? Weniger? Und welche Zeichen sind besonders betroffen? Eher “traditional Japanese characters” oder auch Zeichen aus dem “simplified Japanese”?
Danke :)