Es gibt genügend Programme, die an UTF-16 scheitern, weil sie nur UCS-2 unterstützen. Von denen, die UTF-16 unterstützen, aber zum Speichern/Datentransfer meinen, sie würden UTF-8 benutzen, nutzen manche in Wirklichkeit CESU-8.
Delphi unterstützt seit der Einführung in Delphi 2009 UTF-16 komplett. UTF8Decode funktioniert bei mir hingegen in D2009 teils nicht mit z.B. großen Umlauten, weshalb ich eine eigene Decoderfunktion verwende. In neueren Delphis funktioniert mein Code nicht mit, dafür aber ohne diese eigene Decoderfunktion.
Unsere Telefonanlage in der Firma (Starface) ist sehr interessant: Die Mobile App ist
unicode-fähig. Der Windows-Client kann nur UCS-2. Fügt man ein Zeichen außerhalb der BMP ein, kommt es trotzdem auf dem Handy richtig an, obwohl der Windows-Client es als zwei Klötzchen darstellt.
Im Rahmen meiner ID3-Tag-Library bin ich mal auf ein mp3-File gestoßen, bei dem die Informationen "seltsam" angezeigt wurden. Mit Hilfe von HxD habe ich dann erkannt, dass folgende Kodierung verwendet wurde:
- UTF-16 (ok, kein Problem)
- Nullterminiert (ist ja durchaus sinnvoll)
- mit Byte-Order-Mark (kann man machen ...)
- das alles aber zeichenweise
Kein Witz - 6 Byte pro Zeichen. Für jedes 2-Byte Zeichen zusätzliche 2 Byte BOM und 2 Byte Terminator. Ich habe dann beschlossen, für diesen Murks keine Erkennungs-Heuristik einzubauen. Bei sowas wird dann einfach Murks angezeigt.
Bist du dir sicher, dass du UTF-16 meinst und nicht UCS-2?