Kodierung in UCS-2 Little Endian

[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

[Bernhard Geyer]

Zitat von mjustin:

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

Das ist kein Problem. Es wird so gemacht wie bei "dummen" Druckern auch. Statt dem Drucker zu sagen "Drucke Zeichen ♫" sagt man ihm. MoveTo(x,y); LineTo(...); ...
Und deshalb wird das UCS-2 kein Problem darstellen da der Befehlsvorrat mit Sicherheit keinen ♫-Befehl kennt.

[NicoDE]

Zitat von mjustin:

Die umgekehrte Richtung geht nicht (UTF-16 nach UCS-2 konvertieren).

Soweit richtig. Aber ein UTF-16-Parser würde in UCS-2 Code-Units finden die als Surrogates interpretiert werden (die keine sein sollen) und dann hängt es vom Parser ab, was er damit macht. Das Prolem taucht zum Beispiel dann auf, wenn man UTF-16 Code-Units direkt mit UTF-8 codiert ohne es vorher in Unicode zu konvertieren - für dieses Problem wurde CESU-8 definiert

edit: Auch bei UCS-2 sind U-D800 bis U-DFFF nicht erlaubt... was mich wieder die Frage stellen lässt, welche Zeichen denn nicht funktionieren. Aber wahrscheinlich hat sich die Frage durch die Verwendung von UTF-16 ohnehin erledigt