Encoding-Probleme? Nie von gehört!

Heute schon ein Encoding-Problem gehabt? Nein? Dann bestimmt nächste Woche! Spätestens dann, wenn ein System anzubinden ist, das von UTF-8 nichts wissen will und seine Zeichen mit einem 8-Bit-Code codiert, z.B. Windows CP-1252 oder ISO-8859–1. Von Mainframes reden wir hier besser erst gar nicht.

Eisberg voraus, Herr Kapitän!

Encoding ist für viele Entwickler ein geradezu mystisches Thema. Umlaute verschwinden und tauchen wieder auf, komische Zeichen verdoppeln sich, Editoren, Datenbanktools und Datei-Viewer legen einen aufs Kreuz, weil sie ihre eigene Interpretation der binären Daten haben, Libraries nehmen einfach ein Default-Encoding, das je nach Alter der Library was anderes ist, als man brauchen kann.

Oft rettet einen nur der Hex-Viewer, der als einziger nicht lügt.

In meiner Enterprise-Application-Integration-Zeit gehörte das zum Alltag.

Wenn wir Tests mit Umlauten durchführten, habe ich oft beobachtet (auch an mir selbst), dass eine Reihe von ä, ü, ö, ß, etc. in ein Feld gesteckt wurden. Nach dem Motto: eins ist zu wenig, doppelt und dreifach hält besser.

Mal kurz nachgedacht: Wenn ein einzelnes ä nicht durchkommt, machen die zusätzlichen Umlaute den Test nicht aussagekräftiger!

Die Entdeckung des €

Dann entdeckte ich den (das?) Euro €.

Das € hat sehr nützliche Eigenschaften:

Wenn Dein Schnittstellenpartner Dich das nächste Mal fragt, welche Zeichen ihr beim nächsten Test verwenden sollt, dann sag' ihm einfach:

Hast mal ein paar Euro?

TAGS