Zur Abwechslung mal eine Geschichte aus dem echten Redaktionsalltag: Eigentlich verwendet das ADMIN-Magazin für sein Autorenformat als Character Encoding Latin-1 alias ISO-8859-1 beziehungsweise -15, wenn das Euro-Zeichen besonders wichtig ist. "Aus historischen Gründen", wie es so schön heißt, denn schließlich hängt daran ein Rattenschwanz an Tools, die dieses Format weiterverarbeiten, und wer will die ins 21. Jahrhundert portieren?
Natürlich schicken uns Autoren trotzdem oft einfach zu, was sie gerade haben, seien es Open- oder neuerdings Libre-Office-, Word-Dokumente oder Textdateien, die in UTF-8 kodiert sind. Prinzipiell ist UTF-8 eine gute Sache und die mir bekannten Linux-Distributionen haben die Umstellung darauf längst vollzogen, aber trotzdem gibt es noch immer Programme, die damit nicht klarkommen, etwa der gute alte Editor Nedit, der wie wir noch im Latin-1-Zeitalter lebt.
Normalerweise ist das kein großes Problem, denn mit einem einfachen Aufruf auf der Kommandozeile lässt sich eine Datei vom einen ins andere Encoding wandeln:
recode utf8..latin artikel.txt
Das funktioniert fast immer, doch manchmal meldet Recode lapidar "fehlgeschlagen: ungültige Eingabe bei Schritt »UTF-8..ISO-8859-1« (man beachte hierbei, wie schön das Terminal den Umlaut und die französischen Anführungszeichen wiedergibt). Schöner wäre es natürlich, wenn man eine brauchbare Hilfe zur Fehlersuche bekäme, aber wäre wohl zuviel des Guten.
Oft habe ich das gleiche Problem beim so genannten Byte Order Mark (BOM) ausgemacht, den manche Editoren an den Anfang der Datei setzen. Die Interpretationen darüber gehen auseinander, aber generell scheint es nicht unbedingt eine gute Idee zu sein, dies bei UTF-8-Dateien zu tun, und es führt oft zu Schwierigkeiten.
Leider war das Problem mit dem Löschen des BOM aber dieses Mal nicht erledigt und Recode weigerte sich weiter standhaft, die Datei zu konvertieren. Bei näherer Betrachtung stellte ich fest, dass statt der ASCII-Anführungszeichen (einfache und doppelte) in der Datei typografische Anführungszeichen (U+2019, U+201c usw.) enthalten waren, die in Latin-1 keine Entsprechung haben und deshalb die Umwandlung verhindern. Doch selbst nach dem Ersetzen der fraglichen Zeichen klappte es nicht.
Ich starrte eine Zeit lang angestrengt auf die Datei im Gedit-Editor und wechselte dann in die Konsole. Eine Zeit lang versuchte ich mich an einem Python-Skript, aber letztlich ist die Unterstützung von Unicode bei Perl doch besser. Tatsächlich konvertierte ein Einzeiler die Datei ohne zu murren:
cat artikel.txt | perl -MEncode=from_to -pe 'from_to($_,"utf8","latin1");' > artikel-latin.txt
Hierbei konvertiert die Funktion "from_to()" aus dem Encode-Modul jedes Zeichen in Latin-1 und verwendet einen Substitution Character, wenn es das Zeichen in Latin-1 nicht gibt. Wer sich nun noch dafür interessiert, welche unsichtbaren Zeichen in der Datei enthalten sind, ruft die Funktion "from_to()" mit einem dritten Parameter auf, der festlegt, dass sie bei nicht konvertierbaren Zeichen eine Warnung ausgibt (die Default-Einstellung ist, dies zu ignorieren):
cat artikel.txt | perl -MEncode=from_to -pe 'from_to($_,"utf8","latin1", Encode::FB_WARN);' > artikel-latin.txt
Im Beispielfall war der Schuldige dann der Unicode-Codepoint U+2028 (LINE SEPARATOR), den der Editor natürlich nicht sichtbar darstellt. Darauf muss man auch erst mal kommen.
Unfähig
Mittwoch, 05. Dezember 2012 11:07:11