Windows und UTF-8

Wndows
Posted by Administrator (renee) on Nov 22 2018 at 9:22 AM
Meldungen >> Wndows

UTF und UCS


Überall, wo man von UCS-2 abweicht, zeigt Windows inkorrektes Verhalten, was aber kaum auffällt, weil selbst bei CJKV die häufigsten Zeichen alle in 16 Bits reinpassen, und ansonsten das einfach ignoriert werden kann. Hat zum Beispiel ein chinesischer Städtename ein seltenes Zeichen, so sind es in UTF16 zwei Blöcke, aber das ist ihm beim Dateinamen einfach egal. Das interessiert am Ende nur die GUI, wenn das Zeichen gerendert wird.

Noch ein paar Punkte, die man sich als Entwickler eigentlich grundsätzlich merken könnte:
 

  • UTF-32 ist übrigens auch nicht feste Breite, weil ein Codepoint nicht genau einem Zeichen entsprechen muss. So kann ein Ü als zwei Zeichen kodiert werden. Bei Zeichen mit mehreren "Verzierungen" wird es noch komplizierter, weil man die Reihenfolge ändern kann. Hier muaa man also zum Suchen von Dateinamen immer in Normalformen konvertieren usw
  • Das geniale an UTF-8 ist, dass es eigentlich keine Verwechslungsgefahr gibt. Es gibt keine Nullbytes in einem UTF-8-String außer der tatsächliche Nullcode. In einem Multibyte-Ausdruck kann niemals ein Byte zufällig einem ASCII-Zeichen oder einem anderen Multibyte-Ausdruck entsprechend. Man kann mitten in einen UTF-8-String hineinspringen und weiß sofort, was Sache ist. Wenn man mitten in einem Multibyte-Ausdruck ist, erkennt man das, selbst ohne auch nur Vorgänger- oder Nachfolgezeichen zu lesen. Das meinte ich damit, daß man UTF-8 einfach in eine ASCII-Funktion hineinfüttern kann. Dinge wie "Kopiere bis zum Nullbyte" oder funktionieren. 
  • UTF-16 gibt es nur wegen dem oben genannten UCS-2. Es gibt sonst überhaupt keine Vorteile für UCS16. Selbst reine asiatische Texte sind mit UTF-8 nicht kleiner. Von praktischen Texten mit Formatierungstags (meistens ASCII) und dann noch GZIP-Kompression ganz zu schweigen.

Back