Unicode fails

[Helmi]

vielleicht heißt der ja so

[Gausi]

So eine falsche Kodierung wie im Video oben hatte ich mal bei einer Bestellung im xkcd-Shop. Bei der Stadt war das "ü" kaputt, und in Namen das "ß". Ist aber trotzdem ohne Verzögerung angekommen.

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

[himitsu]

Ich hatte nichtmal gesehn wo der Fehler sein sollte?
Hab mir aber auch nicht jede Sekunde des Films genau angeguckt.

@Gausi: Na komm schon, das zu implememntieren wäre doich witzig geworden.
Noch besser wäre es aber, wenn jedes Zeichen auch noch anders kodiert worden wäre.
Ob die beim NSA auch so faul sind? Dann hätten wir jetzt eine neue "Verschlüsselung" gefunden.



Ein Deutscher Eurofighter-Pilot.
Und im Vorspann kommt Deutschland auch nur einmal vor ... außer den Braunkohledingern hat Deutschland doch nichts Großartiges zu bieten
und wenn wir die bald alle abgeschaltet haben, dann existieren wir in solchen Dokumentationen garnicht mehr.

[edit]
Grad nochmal geguckt und da war es ja ... aber nach ner halben Sekunde durch die Werbung verdeckt. (sollte ich hier auch mal den YT-Werbeblocker installieren)


Ich denk mal das Programm kann Unicode, aber irgendwo wurde UTF-8 als ANSI/ASCII behandelt, z.B. ohne BOM gespeichert und dann beim Einlesen mit falscher Kodierung.


Wir haben jetzt einen Linux-"Guru" in der Firma
und weil sein Programm nicht mit UTF-8-Dateien mit BOM klar kommt und abstürzt,
wurden alle Dateien als UTF-8 ohne BOM neu abgespeichert,
aber nun kommt Delphi nicht mit UTF-8 ohne BOM klar
und speichert das wieder mit BOM ab und wenn das dann im GitHub landet,
dann verreckt dessen CI, wenn es die SQL-Scripte testen will.

[Der schöne Günther]

Zitat von himitsu:

Wir haben jetzt einen Linux-"Guru" in der Firma
und weil sein Programm nicht mit UTF-8-Dateien mit BOM klar kommt und abstürzt,
wurden alle Dateien als UTF-8 ohne BOM neu abgespeichert,
aber nun kommt Delphi nicht mit UTF-8 ohne BOM klar
und speichert das wieder mit BOM ab und wenn das dann im GitHub landet,
dann verreckt dessen CI, wenn es die SQL-Scripte testen will.

Da stelle ich mir immer vor, wenn so Leute in 1970 dachten "In 50 Jahren haben wir fliegende Autos und Weltfrieden und so" und dann scheitert Computersoftware immer noch an Text-Encoding.

[himitsu]

Nja, Problem ist ja, dass im Linux viele Programme ohne BOM davon ausgehen, dass es UTF-8 ist (bzw. die haben eine Encoding-Erkennung drin), während im Windows viele Programme standardmäßig von ANSI ausgehn.
Mit BOM wüsste jeder was es ist.

Bin ich der Einzige, der meint, dass man etwas so bauen sollte, dass Programme mit den frischinstallierten Standardeinstellungen etwas hinbekommen sollten?
k.A. was so schwer dran ist das BOM einfach zu ignorieren (oder besser noch zu behandeln), in dem Programm was er geschrieben hat, so dass auch Fremdprogramme (die ich nicht selbst programmiert habe) damit umgehen können?
Sorry, wenn ich zum Bearbeiten von SQL-Dateien (was selten passiert) gleich die schon offene Delphi-IDE benutzte, wenn ich parallel im DelphiCode rumfummle und keine "Lust" hab noch ein weiteres Programm zu installieren und zu nutzen. (ja, Codefolding, Codevervollständigung und so gibt es da nicht, aber brauch ich auch nicht)



Vor 20 Jahren wollte Intel in 10 Jahren (also vor 10) den P4 so weit haben, dass der mit 30 GHz läuft. (falls ich das vor Kurzem richtig gelesen hatte)
Datei aber bis zu 5 KW verbrät, also 20 A zieht (aus der Stecktose und somit am Starkstromstecker) und durch den Chip selbst 2500 A "rauchen" müssten (bei 2 V).
(wenn jetzt ein Chip grade mal so die 3 GHz schafft, ist das "schnell")

[TiGü]

Zitat von Der schöne Günther:

Da stelle ich mir immer vor, wenn so Leute in 1970 dachten "In 50 Jahren haben wir fliegende Autos und Weltfrieden und so" und dann scheitert Computersoftware immer noch an Text-Encoding.

Passend dazu:
https://xkcd.com/1953/

Und die zum eigentlichen Thema:
https://xkcd.com/1137/
https://xkcd.com/1209/

[himitsu]

Falls jemand den Text nicht lesen kann.
202E schaltet von left-to-right um

Das ist hier auf irgendeinem Shortcut ... k.A. auf Welchem, ich erwisch ihn nur machmal und muß dann neu starten, weil ich den Shortcut mir nicht merken kann.
Genauso wie in der Delphi-IDE der Editormode mit dem grauenhaft permanenten Verhalten der Selektierung.

[Redeemer]

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.

Zitat von Gausi:

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?

[Gausi]

Zitat von Redeemer:

Bist du dir sicher, dass du UTF-16 meinst und nicht UCS-2?

Ähm ... nein. Aber ich habe grade noch mal in den ID3-Tag-Standard auf id3.org geschaut. Für Version ID3Tag 2.3 gilt

Zitat:

All Unicode strings use 16-bit unicode 2.0 (ISO/IEC 10646-1:1993, UCS-2).

Für Version 2.4 gilt:

Zitat:

Frames that allow different types of text encoding contains a text encoding description byte. Possible encodings:

• $00 ISO-8859-1 [ISO-8859-1]. Terminated with $00.
• $01 UTF-16 [UTF-16] encoded Unicode [UNICODE] with BOM. All strings in the same frame SHALL have the same byteorder. Terminated with $00 00.
• $02 UTF-16BE [UTF-16] encoded Unicode [UNICODE] without BOM. Terminated with $00 00.
• $03 UTF-8 [UTF-8] encoded Unicode [UNICODE]. Terminated with $00.

Ob das nun wirklich genau so von den üblichen Libraries umgesetzt ist, weiß ich nicht. Nach meiner Erfahrung würde ich wetten: Ne.

Tatsächlich gibt es auch inoffizielle Mischformen der beiden Versionen, und für die ISO-8859-x Variante habe ich eine Heuristik, die ggf. das "x" aus dem Dateinamen versucht zu schätzen - denn das ist längst nicht immer ISO-8859-1.

(Du hast nicht zufällig ein paar Testfiles dazu irgendwo rumliegen? Zusammen mit Screenshots, wie der Text richtig aussähe? )