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:

Delphi-Quellcode:

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:

Zitat von Dragon27 (Beitrag 1287443)

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:

Zitat von mjustin (Beitrag 1287454)

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:

Zitat von Bernhard Geyer (Beitrag 1287456)

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:

Zitat von Bernhard Geyer (Beitrag 1287456)

Zitat:

Zitat von mjustin (Beitrag 1287454)

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:

Zitat von mjustin (Beitrag 1287462)

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. :stupid:

[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? :stupid:

[mjustin]

Zitat:

Zitat von himitsu (Beitrag 1287490)

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

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:

Zitat von mjustin (Beitrag 1287493)

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:

Zitat von mjustin (Beitrag 1287493)

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 :)

[himitsu]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1287498)

Es wird so gemacht wie bei "dummen" Druckern auch. Statt dem Drucker zu sagen "Drucke Zeichen ♫" sagt man ihm. MoveTo(x,y); LineTo(...); ...

Na dann isses doch irgendwie sinnlos, daß man zwangsweise doppelt so viel Daten hinschicken muß, wo doch ASCII ausreichen würde. :stupid:

[Dragon27]

Hallo zusammen,

erstmal danke für die vielen Antworten.

Ich hoffe ich kann auch hier ein paar Fragen beantworten:

1. Wieviele Dateien lädt ein Laser pro Tag?

Das ist unterschiedlich und kommt auf die Chargengröße an. Normalerweise wird 5 bis 10 mal pro
Tag ein neues File geladen.

2. Bei welchen Zeichen funktioniert der Code nicht?

Also er schafft es nicht einen "Line Feed character" richtig zu codieren. Der Laser bekommt das Zeichen

Code:

&xA;

sollte aber

Code:




bekommen. Das trat übrigends schon bei der ersten Datei auf ;)

Mein aktueller Stand ist, dass ich versuche mit einem TXMLDocument das ganze ans laufen zu bekommen. Leider
gibt es bei LoadFromFile scheinbar keinen Parameter um das Encoding festzulegen... Geht das dann in diesem
Fall automatisch?

Danke!

[Bernhard Geyer]

Zitat:

Zitat von Dragon27 (Beitrag 1287680)

2. Bei welchen Zeichen funktioniert der Code nicht?

Also er schafft es nicht einen "Line Feed character" richtig zu codieren. Der Laser bekommt das Zeichen

Code:

&xA;

sollte aber

Code:




bekommen. Das trat übrigends schon bei der ersten Datei auf ;)

Dein Problem hat eigentlich gar nix mit UTF-16 oder UCS-2 zu tun. Sondern einfach mit der unvollständigen Implementierung auf der Lasermaschine im Bereich Sonderzeichen.

Der XML-Standard schreibt die Möglichkeit vor Sonderzeichen auf mehrer Arten zu Codieren.
Bei einem LF wäre das die oben aufgeführten Möglichkeiten. Beide sind erlaubt und ein vollständig implementierter XML-Parser hat mit keiner davon Probleme.


Jetzt ist eigentlich die Aufgabe/Suche zu finden ob man einen XML-Parser darauf einstellen kann statt der Hexcodierung die Dezimalcodierung bei solchen Zeichen zu verwenden.

[himitsu]

Zitat:

Zitat von Dragon27 (Beitrag 1287680)

Leider
gibt es bei LoadFromFile scheinbar keinen Parameter um das Encoding festzulegen... Geht das dann in diesem
Fall automatisch?

XML ist standardmäßig UTF-8 (wenn nichts anderes gefunden) und ansonsten gibt es bei XML eigntlich keine BOM.
Die MultyByte-Zeichensätze werden Anhand des Encoding-Parameters in der XML-Processing-Instruction (

XML-Code:

<?xml encoding="...">

) ermittelt.
Und bei den Unicode-Zeichensätzen fängt es mit dem ersten "<" an, also ob und wo dort die #0 drin steht wird erstmal entschieden, ob Little-Endiian oder Big-Endian und dann das Encoding.
Daher ist ein Encoding an den Load-Methoden nicht nötig, da alle nötigen Informationen genau definiert sind und immer in der Datei stehen müssen. (außer bei UTF-8, was ja der Standard ist)
XML ist so gestaltet, daß man mitten beim Lesen das Encoding umschalten kann. (siehe die Processing-Instruction, welche es innerhalb des XML-Dokumentets nicht nur für XML gibt ... "xml" ist dort der Prozessor-Name)

Und das mit den Sonderzeichen und dem "schrottigen" Parser hat der Vorgänger bereits erwähnt.

[NicoDE]

Zitat:

Zitat von Dragon27 (Beitrag 1287680)

Also er schafft es nicht einen "Line Feed character" richtig zu codieren. Der Laser bekommt das Zeichen

Code:

&xA;

Hm, ich kenne es nur in der Form: &#xA;

[Sir Rufo]

Zitat:

Zitat von NicoDE (Beitrag 1287746)

Zitat:

Zitat von Dragon27 (Beitrag 1287680)

Also er schafft es nicht einen "Line Feed character" richtig zu codieren. Der Laser bekommt das Zeichen

Code:

&xA;

Hm, ich kenne es nur in der Form: &#xA;

Es kann als

Code:

& #10 ;

oder als

Code:

& #xA ;

übertragen werden und ist dabei völlig gleichwertig. (Die Leerzeichen bitte wegdenken, aber wenn ich die wegmache, dann zeigt der Browser und Editor nur einen Zeilenumbruch an - warum wohl :mrgreen:)

Code:

& - Escapezeichen
# - jetzt kommt ein Wert für ein Zeichen
x - der Wert ist Hexadezimal
; - Ende der Durchsage

[Bernhard Geyer]

Zitat:

Zitat von Sir Rufo (Beitrag 1287758)

(Die Leerzeichen bitte wegdenken, aber wenn ich die wegmache, dann zeigt der Browser und Editor nur einen Zeilenumbruch an - warum wohl :mrgreen:)

Liegt eher an vBulletin das hier diese Element immer wieder nur als HTML direkt durchlässt.

[himitsu]

&amp;#10;

[edit] hmmmmmmmmmm, warum wandelt vB das & nicht um? :gruebel:


& #38;#10; wird einfach gelöscht (doppelte Umwandlung? :wall:)

[Der schöne Günther]

Sehe ich das richtig dass dem armen Mann im Endeffekt empfohlen wurde "Wird schon nichts außerhalb von UCS-2 vorkommen"?

Wenn es für mich noch nicht zu früh am Morgen ist dann entfernt man aus einem String doch einfach nur die Surrogates und hat einen String wo jedes Zeichen in die Basic Multilingual Plane, also 16 Bit, passt:

Delphi-Quellcode:

uses
   System.SysUtils,
   System.Character;

procedure RemoveNonUCS2(var str: String; const replacement: String = '');
var
   index: Integer;
   stringBuilder: TStringBuilder;
begin
   stringBuilder := TStringBuilder.Create(str.Length);
   try
      index := 0;
      repeat
         if Char.IsSurrogatePair(str, index) then
            begin
               Inc(index);
               if (not replacement.IsEmpty()) then
                  stringBuilder.Append(replacement);
            end
         else
            stringBuilder.Append(str.Chars[index]);
         Inc(index);
      until (index >= str.Length);

      str := stringBuilder.ToString();
   finally
      stringBuilder.Destroy();
   end;
end;

[peterbelow]

Zitat:

Zitat von Dragon27 (Beitrag 1287443)

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:

Delphi-Quellcode:

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!

Hat die XML-Datei eine BOM am Anfang, wenn ja, welche?

[TiGü]

Erstellungsdatum des Threads? Anyone? :roll:

[Der schöne Günther]

Es ist nie zu spät gegen vergangene Verbrechen vorzugehen :warn: