ADMIN-Tipp: Unsichtbare Zeichen in Textdateien

Jede Woche erscheint in unserem Newsletter ein neuer ADMIN-Tipp. Eine Sammlung aller Tipps finden Sie im Archiv der ADMIN-Tipps.

Unicode-Zeichen in Textdateien bescheren Anwendern auch im Jahr 2012 noch oft Probleme. Zu dumm, wenn der Editor sie nicht einmal anzeigt und man deshalb bei der Fehlersuche im Dunkeln tappt. Eine wahre Geschichte aus der ADMIN-Redaktion ...

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.

04.12.2012

Ähnliche Artikel

Comments

Unfähig

Es freut mich ja immer, nicht nur zur Information, sondern auch zur Unterhaltung der Leser beitragen zu können :) Aber im Ernst: Aus meiner eigenen Praxis (außerhalb der Redaktion) weiß ich, dass solche "Legacy-Problem" in Unternehmen nicht gerade selten sind. Und meistens gibt es dann ein Dutzend andere Projekte, die dringender sind als etwa die Umstellung einiger Tools auf UTF-8 - solange der "Leidensdruck" nicht groß genug. In 99% der Fälle funktioniert die Konvertierung ja auch reibungslos. Und dann gibt es immer auch noch eine Reihe von Programmen, auf die man angewiesen ist, und die man nicht unbedingt selber auf UTF-8 portieren will, auch wenn sie nun Open Source sind (zB. Nedit).

Der eigentlich Skandal ist ja, dass die meisten Standard-Programme einfach unfähig sind, mit dem Problem richtig umzugehen. Öffne ich die UTF-8-Datei in Gedit und will sie als Latin-1 speichen, erhalte ich die gleiche Fehlermeldung wie mit Recode (vermutlich verwendet es auch Recode oder dessen Library). Während das Perl-Beispiel zeigt, dass man die Umwandlung tatsächlich sinnvoll hinbekommen kann.

Hahahahaha!!!

Hahahahaha!!! Echt, sowas gibt es noch? 

Ne, mal ernsthaft. Was du hier beschreibst ist wirklich weniger Aufwand, als endlich ins 21. Jahrhundert zu wechseln? Kann ich einfach nicht glauben...

Finde ich aber echt sympatisch, dass ihr Euch als eine Technik-Redaktion so eine Blöße gibt. Mir wäre sowas wahrscheinlich zu peinlich gewesen. Respekt. ;-)

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023