Kaputte Datei ohne Encoding mit Umlauten in StringList laden+Zeichen erhalten

[DieDolly]

Genau und wenn ich die Datei mit UTF8 Encoding laden möchte knallt es. Deswegen try-except und im except dann TEncoding.Default.

Erst gucke ich ob ein BOM vorhanden ist. Wenn nicht prüfe ich jedes Zeichen der Datei (Stream) ob es über #127 hinaus geht. Wenn ja, sind zumindest Zeichen außerhalb der 8 bit vorhanden.
Dann versuche ich mit UTF8 Encoding die Datei zu laden was auch bei vernünftigen Dateien funktioniert. Knallt es dann im Except kommt Default zum Einsatz.

[Gausi]

Zitat von DieDolly:

Wenn nicht prüfe ich jedes Zeichen der Datei (Stream) ob es über #127 hinaus geht. Wenn ja, sind zumindest Zeichen außerhalb der 8 bit vorhanden.

Mit dem Test auf #127 erreichst du aber nur 7 Bit. D.h. wenn du eine "Ansi-kodierte" Datei hast (oder Windows 1252, oder eine andere 1-Byte-Kodierung), und du hast Umlaute drin, dann schlägt das schon fehl - denn die sind jenseits von #127. Wenn du dann mit UTF8 dran gehst, dann dürfte es regelmäßig knallen, würde ich vermuten. Oder es kommt zumindest anderweitig Unsinn raus.

[Uwe Raabe]

Du könntest die Überprüfung noch etwas verfeinern, in dem du auf eine gültige UTF-8 Kodierung prüfst:

1. Ist das höchste Bit 0, ist es ein ASCII-Zeichen (entspricht deinem Test)
2. Sind die höchsten drei Bit eine 110, dann kommt als nächstes ein Folgebyte
3. Sind die höchsten vier Bit eine 1110, dann kommen als nächstes zwei Folgebyte
4. Sind die höchsten fünf Bit eine 11110, dann kommen als nächstes drei Folgebyte
5. Ein Folgebyte hat als höchste zwei Bit eine 10

[DieDolly]

Habe ich eben reingeschrieben.
Ich erhalte jetzt TEncoding.Default immer dann zurück, wenn alle Versuche UTF-8 zu erkennen schief gehen und nichts vorhanden ist.
UTF-8 mit und ohne BOM erkennen ist ja relativ einfach. Aber solche Western Dateien die fallen durch alle Raster und ganz am Ende der Prüfkette muss man dann eben auf Default ausweichen.

Eine andere Lösung für das Problem ist, dass ich das was zu speichern ist prüfe. Notwendig eigentlich nicht.

Delphi-Quellcode:

for Ch in Str do
 begin
  if (Ch >= #32) and (Ch <= #127) then
   Result := Result + Ch;
 end;

Bis zu welchem Bereich kann man bedenkenlos prüfen, um noch im UTF-8-Bereich zu bleiben?
ASCII ist ja scheinbar bis 127. Bis wohin geht denn UTF-8? Weil irgendwann sind die Zeichen so groß, dass sie unter UTF-16 fallen.
Und standardmäßig lade und speichere ich Daten in meinem Programm mit UTF-8-Encoding.

Obwohl ich gerade sehe, dass ich bis Unicode U+5613 gehen kann und alles richtig gespeichert und geladen wird mit UTF-8.
Das passt denke ich.

" U+24F5C " wird auch korrekt mit UTF 8 kodiert gespeichert und gelesen.
Entweder war mein Delphi damals einfach zu alt für solche Spielchen oder es liegt an Windows 10 dass jetzt alles mit solchen Zeichen funktioniert
https://de.wikipedia.org/wiki/UTF-16

[Uwe Raabe]

Zitat von DieDolly:

Bis wohin geht denn UTF-8?

UTF-8 ist ja nicht durch einen Zahlenbereich gekennzeichnet, sondern wie oben beschrieben über bestimmte Bitmuster. Insbesondere gibt es Bytes bzw. Bytefolgen zwischen 128 und 255, die kein UTF-8 darstellen. Deswegen kann ja auch das Decodieren mit UTF-8 zu einer Exception führen.

ANSI-Decodieren (wie z.b. 1252) geht aber immer, da dort alle Zeichen im Bereich 0..255 gültig sind (vielleicht nicht sinnvoll, aber gültig). Was dann allerdings dabei heraus kommt ist eben von der verwendeten Codepage abhängig. Wenn du ein mit CP 1253 codiertes File als CP 1252 decodierst, kann eben was falsches raus kommen und du würdest es nicht mal merken, wenn du das gewünschte Ergebnis nicht kennst.

Mit UTF-8 kannst du im Grunde jedes Unicode Zeichen codieren. Du brauchst halt für manche Zeichen eben mehr als 1 Byte.

[DieDolly]

Bei meinen Tests bin ich von 1 bis 4 Byte pro Zeichen gekommen und UTF-8 ging immer gut.
Ich versuche nur das Schlimmste zu vermeiden. Aber wenn jemand in den Daten rumspielt und sie absichtlich verändert kann ich auch nix mehr machen