EEncodingError Fehler

[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.

[Harry Stahl]

Also ich hatte die gleiche Fehlermeldung unter XE6, als ich unter MAC OSX eine Ansi-Datei einlesen wollte (ohne konkrete Encoding-Angabe unterstellt Delphi unter MAC OSX -anders als unter Windows: dort Ansi- , dass die Datei im UTF8-Format vorliegt). Die habe ich dann als Unicode-16 gespeichert (das ist das Format, dass ich für Programme verwende, wenn die Daten Plattformübergreifend unter Windows, MAC OSX, Android uns IOS austauschbar sein sollen), dann war wieder alles OK.

Also ist Deine Datei aus dem Internet wohl doch eine ANSI-Datei.

Delphi kann das nicht richtig erkennen. Für mein TEditor-Programm unter MAC musste ich auch was eigenes entwickeln, um eine ANSI-Datei von UTF8 (und andere Unicode-Varianten) unterscheiden zu können. Da eigentliche Problem ist hauptsächlich die Unterscheidung zwischen UTF8 und ANSI, da ja UTF-8 in den ersten 128 Zeichen identisch ist mit ANSI. Davon abgesehen gibt es auch Unicode-Dateien ohne BOM!

[greenmile]

Hmm, bei der Datei handelt es sich um Text-Daten, die ich vorher mittels PHP aus einer mySQL Datei auslese. Die gebe ich dann, grob formatiert, zurück. Eigentlich sollten sich darin nur (deutsche) lesbare Zeichen befinden, also ANSI. Dass das so nicht funktioniert ist ja schon irgendwie krass. Ich pfusche es jetzt so da ich nicht weiß, was mich in Zukunft so als eingehendes Format erwartet:

Code:

      Err := false;
      Try TempIni  := TMemIniFile.Create(TempFile,TEncoding.UTF8); Except Err := true; End;
      if Err then begin
        Err := false;
        Try TempIni  := TMemIniFile.Create(TempFile,TEncoding.Ansi); Except Err := true; End;
      End;
      if Err then begin
        Err := false;
        Try TempIni  := TMemIniFile.Create(TempFile,TEncoding.Ascii); Except Err := true; End;
      End;
      if Err then begin
        Err := false;
        Try TempIni  := TMemIniFile.Create(TempFile,TEncoding.BigEndianUnicode); Except Err := true; End;
      End;
      if Err then begin
        Err := false;
        Try TempIni  := TMemIniFile.Create(TempFile,TEncoding.Unicode); Except Err := true; End;
      End;
      if Err then begin
        Err := false;
        Try TempIni  := TMemIniFile.Create(TempFile,TEncoding.UTF7); Except Err := true; End;
      End;

[Union]

Wie sieht denn das encoding in request und response aus?

[himitsu]

Meinst du nicht, daß die Logik andersrum einfacher ist?

Delphi-Quellcode:

      Ok := False;
      if not Ok then  // ich weiß, das IF ist sinnlos, aber was soll's ... ich mag Symetrie und ich mag es nicht, wie die DP Leerzeichen löscht.
        try  TempIni := TMemIniFile.Create(TempFile, TEncoding.UTF8);   Ok := True;  except end;
      if not Ok then
        try  TempIni := TMemIniFile.Create(TempFile, TEncoding.ASCII);  Ok := True;  except end;
      if not Ok then
        try  TempIni := TMemIniFile.Create(TempFile, TEncoding.UTF7);   Ok := True;  except end;
      if not Ok then
        try  TempIni := TMemIniFile.Create(TempFile, TEncoding.ANSI);   Ok := True;  except end;

Wobei du ein Problem haben wirst, denn man kann einige Kodierugen nicht prüfen, bzw. einige Codierungen lassen alle Daten zu, da sie keine "ungültigen" Byte-Kombinationen kennen.

Als Erstes kann man schauen ob die Datei ein Encoding besitzt.
z.B. über TFileStream und TEncoding.GetBufferEncoding

Wenn es ein BOM gibt, dann über die Automatik laden, also ohne Encoding-Parameter, bzw. man besorgt sich einen passenden über TEncoding.GetEncoding .

Ohne BOM kann man nur versuchen sich gegenseitig ausschließende Codierungen nacheinander durchzuprobieren.

Unicode und BEUnicode nehmen alles an, was (zufällig) eine grade Anzahl an Bytes besitzt, aber wenn man Chinesisch als Sprache erlaubt, dann kann man damit auch jedes andere Format einlesen.

UTF-7 ist 7 Bit pro Zeichen, was zufällig der Spezifikation von von ASCII entspricht, auch als ANSI kann man es problemlos laden und mit UTF-8 geht es auch.
Alles mit 7 Bit lässt sich mit UTF-8 Laden, da das UTF-8 erst am 8. Bit erkennen kann, daß es kein UTF-8 ist.

usw.



Aber ja, hier hat man den Vorteil das eventuell aus dem HTTP-Header rauszubekommen.
Bei einigen Protokollen kann der Client sagen, was er gern haben möchte. (die möglichen Encodings, die unterstützten Komprimierungen, bestimmte Dateiformate, ...)
Und der Server "kann" umgekehrt auch sagen was er letztendlich ausgeliefert hat. (DatenFormat, Datenmenge, ...)

[greenmile]

So, Sch..e voll, mache es jetzt anders:

Code:

TempListDL := TStringlist.Create;
TempListDL.Text := IdHTTP1.Get(URL);
TempListDL.SaveToFile(TempFile);

Dann läuft's auch ...