Kodierung in UCS-2 Little Endian

[Dragon27]

Hallo zusammen,

wie die Überschrift sagt, habe ich Probleme mit dem kodieren einer Nachricht in "UCS-2 Little Endian".
Leider kann die lesende Lasermaschine nur dieses Encoding einwandfrei verarbeiten.
Wie kann ich Delphi am Besten dazu bringen, die Datei richtig zu kodieren?

Folgenden Code habe ich geschrieben, aber er funktioniert leider bei einigen Zeichen nicht:

strStream := TStringStream.Create('', TEncoding.Unicode); Am Anfang der XML Datei steht übrigends folgendes Encoding:

Code:

<?xml version="1.0" encoding="utf-16"?>

Danke für eure Hilfe!

[Bernhard Geyer]

Am besten einen XML-Parser zum schreiben nehmen der UTF16 kann.

[mjustin]

Zitat von Dragon27:

wie die Überschrift sagt, habe ich Probleme mit dem kodieren einer Nachricht in "UCS-2 Little Endian".
...
Am Anfang der XML Datei steht übrigends folgendes Encoding:

Code:

<?xml version="1.0" encoding="utf-16"?>

Delphi "kennt" UTF-16 LE als "xetUTF_16LE" laut http://docwiki.embarcadero.com/Libra...MLEncodingType

Das würde ich testen, aber auch mal den Hersteller fragen wie "utf-16" im Header zu "ucs-2 LE" passt, denn es gibt auch "ISO-10646-UCS-2" als XML encoding.

[Bernhard Geyer]

Zitat von mjustin:

Das würde ich testen, aber auch mal den Hersteller fragen wie "utf-16" im Header zu "ucs-2 LE" passt, denn es gibt auch "ISO-10646-UCS-2" als XML encoding.

Solange man nicht Klingonischen Text überträgt ist UTF-16 und UCS-2 das gleiche. UTF-16 erweitert UCS-2 um einen ähnlichen Mechanismus wie UTF-8 die Ansistrings. 99,99% der realen vorkommenden UTF-16 Texte sind 1:1 in UCS-2 abbildbar.

[NicoDE]

Zitat von Bernhard Geyer:

Solange man nicht Klingonischen Text überträgt ist UTF-16 und UCS-2 das gleiche.

Ja, aber wenn die Maschine spezielle UCS-2 Code-Units braucht, die als UTF-16 Surrogates interpretiert werden, dann braucht man eine Alternative.
Also ist eher die Frage, bei welchen Zeichen es nicht funktioniert und wie die Quelldaten erzeugt/generiert werden...

[mjustin]

Zitat von Bernhard Geyer:

Zitat von mjustin:

Das würde ich testen, aber auch mal den Hersteller fragen wie "utf-16" im Header zu "ucs-2 LE" passt, denn es gibt auch "ISO-10646-UCS-2" als XML encoding.

Solange man nicht Klingonischen Text überträgt ist UTF-16 und UCS-2 das gleiche. UTF-16 erweitert UCS-2 um einen ähnlichen Mechanismus wie UTF-8 die Ansistrings. 99,99% der realen vorkommenden UTF-16 Texte sind 1:1 in UCS-2 abbildbar.

In Statistik bin ich ganz schwach, aber dann wäre mit diesem Wert das Risiko auf ein nicht abbildbares XML Dokument zu laufen um einige Größenordnungen größer als einen Sechser im Lotto zu haben? (Laut Wikipedia 0,0000064360%) - Andererseits weiss ich nicht, wie viele XML Dateien so eine Lasermschine pro Woche bekommt, Millionen wohl kaum ...

[himitsu]

Zitat von mjustin:

Andererseits weiss ich nicht, wie viele XML Dateien so eine Lasermschine pro Woche bekommt, Millionen wohl kaum ...

Mit viel Glück kann es ja auch gleich beim ersten Mal knallen.

[Bernhard Geyer]

Ich glaube nicht das man im Bereich der erstellen dieser Daten in die Gefahr kommt Zeichen zu haben die in UTF-16 und UCS-2 anders codiert wären.

Unsere Anwendung lief problemlos auf einem UCS-2 System (Windows 2000) und läuft auch Problemlos auf UTF-16 Systemen (Windows XP und neuer) ohne eine einzige Quellcodezeile angepasst zu haben!

[himitsu]

Habt ihr auch damals Daten als UCS-2 gespeichert und dann versucht als UTF-16 zu laden?

[mjustin]

Zitat von himitsu:

Habt ihr auch damals Daten als UCS-2 gespeichert und dann versucht als UTF-16 zu laden?

Das sollte gehen, UCS-2 umfasst die BMP, welche Platz für 65.536 Zeichen hat.

Die umgekehrte Richtung geht nicht (UTF-16 nach UCS-2 konvertieren). Für die Zeichencodierung stehen in Unicode insgesamt 1.111.998 Codepunkte zur Verfügung. Und 1.111.998 > 65.536.

Wenn man mit der Lasermaschine zum Beispiel keine Emojis oder Mahongg-Zeichen ausgeben muss, Gl♫ckwunsch