EEncodingError Fehler

[greenmile]

Die Datei lade ich direkt aus dem Internet, die kommt also immer Frisch auf den Tisch
Die Datei wird mit Indy mittels GET direkt in einen Stream geschrieben und ja, ich lese Sie nur mit TMemIni ein. Wieso greift da irgendein Encoding-Gedöns?

[himitsu]

Und in Windows ist es standardmäßig ANSI (wie bekommt man im iOS/OSX raus, ob eine Datei ANSI ist, wenn es für ANSI doch kein BOM gibt)

Und ja, Encoding (Umkodierung) brauchst du fast immer, außer
wenn das Format der Datei dem Format der Stringauswertung entspricht.

Und die INI ist vermutlich nicht als Unicode gespeichert.

[greenmile]

Nochmal: Ich lade die Datei mittels IndyHTTP.GET aus dem Netz, es handelt sich halt nur um eine INI Datei. In XE4 geht es einwandfrei, also das einlesen. In XE6 plötzlich nicht mehr. Jetzt kann ich die Quelle natürlich schlecht ändern, weil sonst meine XE4 Anwendungen nicht mehr laufen, also muss ich XE6 irgendwie überreden.

[mjustin]

Zitat von greenmile:

Die Datei lade ich direkt aus dem Internet

Wie sieht denn der Code zum laden aus dem Internet aus?
Encoding ist immer relevant, wenn man mit mehr als einem Rechner zu tun hat: es kann zu Encoding-Problemen zwischen der auf dem Server liegenden Datei und dem Server, und Encoding-Problemen zwischen dem Server und dem Client kommen.

[greenmile]

Also, ich habe mir die Datei mal mit Notepad++ angeschaut, sie scheint eine UTF8 Datei zu sein, ich kann auch alles darin lesen.
Wenn ich die Datei allerdings mit "TMemIniFile.Create(TempFile,TEncoding.UTF8);" öffne, kommt die Exception.
Genau wie bei TMemIniFile.Create(TempFile,TEncoding.AutoDetect);

[Harry Stahl]

Was meinst Du mit

TMemIniFile.Create(TempFile,TEncoding.AutoDetect); ?

Meinst Du das ohne Parameterangabe (.AutoDetect gibt es ja so als Bezeichner nicht),

also so:

TMemIniFile.Create(TempFile);

Wie auch immer, ich habe hier mal eine UTF8-Ini-Datei auf dem MAC erzeugt und kann die auch ohne Probleme in allen Varianten einlesen (auch wenn die Umlaute oder ähnliches enthält).

Folge doch einfach mal mit dem Debugger den weiteren Verlauf, dann siehst Du ja genau, wo es kracht und erhältst evtl. einen hilfreichen Hinweis, wo das Problem liegen könnte.

[greenmile]

Ich schicke Dir die Datei per PN, sobald ich dazu komme.

[Union]

In XE6 hat sich viel am TEncoding getan. In Anbetracht bisheriger Erfahrungen vermute ich, dass unsere amerikanischen Freunde mal wieder eine Standard-Codepage im Constructor verwendet haben. Kannst Du einen reproduzierbaren Code posten, bspw. mit zwei Buttons zum Speichern / Laden einer Ini, mit der das unter XE6 nachvollziehbar ist? Interessant wäre auch die sw_vers des Mac sowie die sonstige Konfiguration.
Und was gibt file für die Datei aus (z.b. ASCII)?

[Bambini]

Zitat von Harry Stahl:

TMemIniFile.Create(TempFile,TEncoding.AutoDetect); ?

Denke nicht das es Autodetect gibt, da es für Windows 1252 Zeichensatz kein BOM gibt. Wenn es also eine Datei mit der Codepage 1252 ist, dann stehen die deutschen Umlaute wie z.B. ö mit dem Hexwert $F6 in der Datei. In einer UTF8 codierten Datei steht das ö als zwei Byte $C3 $B6 drin.

Wenn man auf Mac Seite einen String von Codepage 1252 in UTF8 konvertiert möchste, müßte man die
Datei so öffen:
TMemIniFile.Create(TempFile,TEncoding.GetEncoding(1252)); Aber ich denke nicht das das MacOS alle Codepages und deren Konvertierung von und zu UTF8 kennt.
Entweder man sorgt dafür, dass die Datei bereits in UTF8 vorliegt oder man liesst die Datei in TBytes und konvertiert die deutschen Umlaute selbst ins UTF8.

Vielleicht so:

Delphi-Quellcode:

for i:=Low(DateiInBytes) to High(DateiInBytes) do
  case DateiInBytes[i] of
    $F6 : Result := Result + 'ö';

...

[himitsu]

Zitat:

Denke nicht das es Autodetect gibt, da es für Windows 1252 Zeichensatz kein BOM gibt

Es gibt für alle ANSI kein BOM.

Das bekannte BOM ist im Prinzip nur ein Unicode-Zeichen #$FFFE (eventuell war es auch #$FEFF ... vergess das immer), welches mit dem Text kodiert wurde.
(Das Zeichen #$FFFE als UTF-8 kodiert, ergibt die bekannten 3 Byte des UTF-8-BOM)

Alle Zeichensätze, die kein Unicode darstellen können, können also dieses BOM nicht besitzen.
Da würde dann maximal ein "?", oder welches Ersatzzeichen bei der Umwandlung von Unicode verwendet wurde, dort stehen.

(Drum find ich es im Windows besser, wenn dort ohne BOM der Standard die lokale ANSI-Codepage ist, da es für UTF-8 ein BOM gibt)

Die einzige und unsichere Lösung wäre also, wenn man den Text analysiert, bzw. erst nach dem BOM sieht und das verwendet, oder versucht es als UTF-8 zu laden und wenn das knallt, es dann als ANSI zu behandeln.