Kodierung in UCS-2 Little Endian

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