Warum UTF-8?
23.01.2010 in: Webdesign und Zeichen • 14 Kommentare
Letzte Änderung: 27.08.2012, 12:39 Uhr.
Manche Leute halten UTF-8 immer noch für Voodoo. Schade. Wer Textformate produziert, muß irgendwann 20 Minuten aufwenden, um die Grundlagen der Zeichenkodierung zu verstehen, und er sollte UTF-8 benutzen – und dabei wissen, was er tut. Warum?
UTF-8 ist eine Zeichenkodierung für Unicode. Damit können wir alle Zeichen aus Unicode benutzen, ohne sie zu maskieren: das deutsche Alphabet und das chinesische, Währungszeichen, Musiknoten, Pfeile und Schachfiguren.
In E-Mails mag UTF-8 noch nicht immer angebracht sein; im Markup jedoch können wir nicht mehr darauf verzichten:
- In unseren Formularen wollen wir jedes Zeichen verarbeiten können. Wenn wir kein UTF benutzen, riskieren wir, wichtige Daten zu verlieren.
- Alle XML-Parser müssen UTF-8 verstehen (und UTF-16). Newsfeeds, SVG, XSLT, RDF – all diese Formate sollten wir nur in UTF-8 oder UTF-16 schreiben, damit jeder sie gewiß verarbeiten kann.
- Alle wichtigen APIs der großen Webdienste liefern UTF-8 aus: Flickr, Twitter, Youtube oder Delicious. Wenn wir diese Daten verarbeiten wollen, sollten wir uns nicht den Umweg einer Konvertierung zumuten.
- UTF-8 ist im Unterschied zu UTF-16 bedingt kompatibel zu US-ASCII, denn alle ASCII-Zeichen werden deckungsgleich kodiert. Zeichen oberhalb des Dezimalwerts 127 freilich brauchen mindestens zwei Bytes. Deshalb ist es in allen Sprachen, die eine Variante des lateinischen Alphabets verwenden, sehr kompakt.
- Die meisten Browser verwenden für Nicht-ASCII-Zeichen in URLs UTF-8. Wenn wir das nicht erwarten, werden wir unsere Besucher sicher bald frustrieren.
- UTF-8 können wir validieren: So finden und reparieren wir falsch kodierte Zeichen, ehe der Leser sie sieht.
- UTF-8 braucht kein BOM. Auch ein Vorteil gegenüber UTF-16 und UTF-32. Anleitung: Bom entfernen.
In einigen Programmiersprachen – Perl oder PHP beispielsweise – hängt die Implementierung der Multibytekodierungen noch ein bißchen. Aber mit ein wenig Lektüre können wir auch diese Probleme meistens lösen. Nie entschuldigen sie allein den Verzicht auf UTF-8.
Zu diesem Artikel wurde ich durch zwei Diskussionsbeiträge inspiriert: einen schlechten und einen guten. Der gute stammt von Björn Höhrmann, dem ich deshalb ausdrücklich danken will.
Lesebefehl dazu: "The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)" http://www.joelonsoftware.com/articles/Unicode.html
David am 24.01.2010 · 00:45
Wenn es um CMS geht, mag das alles stimmen. Wenn ich Seiten von Hand schreibe, verwende ich dennoch ISO-8859 bzw. den Windows-abklatsch davon. Denn so kann ich die Datein in jedem belibigen Editor mal fix ändern. Und so lange das Kontaktformular von keinem Chinesen verwendet wird, bleib ich auch dabei. Ich lehne mich sogar soweit aus dem Fenster zu behaupten, dass der Inhalt eines Textes weitgehend zu erfassen bleibt, wenn Noten, Pfeile und Schachfiguren nicht dargestellt werden.
@David: Gibt es denn noch Editoren, die kein UTF-8 verstehen?
Das Formularproblem beginnt schon mit ISO-8859-1(5): Wenn da jemand ein Eurozeichen eingibt, ein š oder ă, weil er einen tschechischen Namen führt, oder „deutsche“ Anführungszeichen – was soll der Browser dann übermitteln? So exotisch sind die Zeichen gar nicht, bei denen man ohne UTF-8 Probleme bekommt.
Programmiere nicht und verstehe deshalb wahrscheinlich nicht alle Argumente für UTF-8. Gleichwohl habe ich schon vor geraumer Zeit meine Webseiten mit UTF-8 angelegt oder auf UTF-8 umgestellt.
Für die Umstellung auf UTF-8 war für mich das Buch Little Boxes Teil 2 von Peter Müller (Seiten 25 ff) sehr hilfreich. Als typische Fallstricke habe ich wahrgenommen:
- Editoren, die kein UTF-8 unterstützen,
- das Abspeichern als UTF-8 mit BOM statt ohne BOM und
- die Umstellung des Zeichensatzes bei in Datenbanken gespeichertem Text.
@David
Wenn du aber Zugang zu einem FTP-Programm hast, findest du doch auch bestimmt einen passenden Editor. Ich bin auch viel unterwegs und muss auf unterschiedlichen OS arbeiten. Vielleicht guckst du dir einfach mal PortableApps an, denn die Vorteile von UTF8 sind erdrückend, gerade im nicht englischsprachigen Raum!
Interessant, was man im ecombiz-Forum so alles verzapft bekommt. Da bei anständigen Betriebssystemen sowieso alles auf UTF-8 läuft, frage ich mich eigentlich eher, warum eigentlich nicht UTF-8? Dann beschwert sich auch keiner aus Fernost.
Zugegeben, es gibt immer noch nichts nervigeres als Zeichenkodierungen... mal ASCII input, mal URL-encodings, dann wieder html entities.
theyl am 30.01.2010 · 17:33
Hallo!
Als Perl-Freund habe ich da ein ganz spezielles Problem. Ganz abgesehen von den Editoren würde ich meine Seiten schon gerne auf utf-8 umbauen. Leider wird mir das Leben dabei jedoch weniger von Perl als vom Betriebssystem schwer gemacht. Unter Perl und Windows steht nämlich zwischen utf-8 und UNIX-Zeilenumbrüchen ein "oder". Will sagen, ich kann zwar in einem Schwipps iso-8859-1 in utf-8 ohne BOM umwandeln, dabei verwandelt jedoch das Betriebssystem die *ix-Zeilenumbrüche in Windoof-Umbrüche. Und um die weg zu bekommen, muss ich die Datei dann noch einmal ohne utf-8-Support, jedoch binär umschreiben.
Perl an sich kommt mit dem hin und her prima klar - das ist also nicht der Punkt, und sobald das auf einem *.ix-Server läuft, der Rest auch nicht. Für die Konvertierung meiner Dateien und Programme brauche ich jedenfalls mindestens eine Woche Urlaub - einschließlich der Tests. Darum habe ich diesen Schritt auch noch nicht gemacht.
Beste Grüße, Thomas
@theyl: Ich verstehe nicht, wie Windows an deine Zeilenumbrüche kommt. Die Umwandlung mußt du doch nicht mit den Funktionen des Betriebssystems vornehmen, oder?
Ich habe Perl noch nie unter Windows benutzt, PHP-Dateien jedoch habe ich schon öfter auf UTF-8 mit UNIX-Umbrüchen umgestellt. Damit hatte ich noch nie ein Problem.
theyl am 30.01.2010 · 18:10
Hallo Thomas!
Die Umwandlung mußt du doch nicht mit den Funktionen des Betriebssystems vornehmen, oder?
Nein, natürlich nicht! So geht's (eben nicht ;-) ):
utf-8-Datei aus beliebiger Quelle schreiben (binmode und ":utf8"-Flag).
Bei Zeilenumbrüchen \n, \x0a, \012 oder den Wert von Perl aus "CRLF" einsetzen. Datei öffnen. Was steht drin? "\r\n". Unter *ix steht da "\012".
Abhilfe schafft dann nur, die Datei noch einmal binär, aber ohne utf-8-Flag zu öffnen und [\r|\n] in \012 umzuwandeln (und das noch einmal zu schreiben).
Missmutige Grüße (vielleicht habe ich die richtige Lösung auch nur noch nicht gefunden) - Thomas
@theyl: Dann liegt’s doch an Perl, bzw. dessen Windows-Interpreter. Funktioniert denn die in der Dokumentation genannte Lösung mit
:raw:utf8nicht?theyl am 30.01.2010 · 21:45
Hmm... Ich dachte bisher, :raw sei mit binmode schon erschlagen. :utf8 klappt ja und binmode auch - nur die Belassung des \012, so wie ich ihn schreibe, nicht (im binmode!). Ich fuchse mich da nochmal 'rein, aber nicht jetzt ;-) .
Grüße Thomas
David am 07.02.2010 · 17:49
Ich habe gerade den „schlechten“ Forenbeitrag gelesen. Dem armen Tropf, dem da so falsch geantwortet wurde, möchte man am liebsten helfen. Aber die Registrierung in dem Forum soll mit Realnamen und einer nich-freemail-Adresse erfolgen. Manche Foren scheinen wirklich an zu viel Nutzern zu leiden.
Thomas Hey'l am 07.02.2010 · 18:43
Hallo Thomas,
der Tipp mit ":raw:utf8" ist gut. Er wirkt unter Windows tatsächlich anders als nur "binmode" einzuschalten. Die *ix-Umbrüche werden damit sofort richtig geschrieben. Damit ist für mich eine wichtige Frage auf dem Weg von iso-8859-1 zu utf-8 ohne BOM geklärt, weil es arg mühsam wäre, alle meine Inhalte und Scriptchen händisch zu konvertieren.
Danke und beste Grüße, Thomas
Andreas Borutta am 25.09.2010 · 07:45
Manchmal gibt es den Bedarf alle Dateien eines Verzeichnisses in einem Rutsch nach UTF-8 zu konvertieren.
Christoph Schneegans war so nett und hat auf meine Anregung hin ein VB-Skript für diese Aufgabe verfasst.
http://schneegans.de/temp/recode.vbs
Ob Christoph das Skript an dieser Stelle dauerhaft bereitstellt, kann ich nicht sagen.
Anwendung:
Drag&Drop eines Verzeichnisses (oder einer einzelnen Datei) auf das Skript. Fertig.
Ein BOM wird nicht erzeugt.