Delphi und Linux - Encoding-Salat?

[knaeuel]

naja, Default meint hier nicht (oder sagen wir "sollte nicht meinen") das Betriebssystem-Default, sondern einfach einen Notfallwert, wenn kein BOM vorhanden ist. (BOMs sind bei UTF8 ja Standard)

ich schätze, mit genau der Überlegung kam es zu der Entscheidung, UTF-8 als Fallback zu setzen. Aber sinnvoll ist es eher nicht, würde ich sagen.

1. es ist hart kodiert. (siehe class function TEncoding.GetDefault: TEncoding; in System.SysUtils.pas)

2. die Procedure TEncoding.GetBufferEncoding (System.SysUtils.pas Zeile 32708) prüft zunächst, ob die Kodierung UTF-8, Unicode LE oder Unicode BE ist. Trifft alles NICHT zu, wird der FEST KODIERTE Wert UTF-8 zurückgegeben, OBWOHL direkt vorher festgestellt wurde, dass es UTF-8 NICHT sein kann.

3. Das führt dazu, dass unter Linux keine ANSI-Dateien in Strings geladen werden können. Sobald du das versuchst, versucht Delphi einen UTF8-String einzulesen, obwohl ein ANSI-String kommt. Das führt bei Umlauten und vielen anderen Sonderzeichen zum Abbruch mit der Meldung "No mapping for the Unicode character exists in the target multi-byte code page". Kein Wunder -> es ist ja auch kein Unicode-Character sondern ein ANSI-Character, der zu verarbeiten wäre.

Also für mich ist das ein Bug. Ich habe inzwischen einen funktionierenden Workaround und kann jetzt einfach meine ANSI-kodierten XML-Dateien unter Linux öffnen. Fehlerfrei. Alle Sonderzeichen werden korrekt dargestellt.

[Schokohase]

Irgendwie verstehe ich dich glaube ich nicht.

Wenn du egal wo immer den gleichen Standard-Wert für das Encoding haben möchtest, falls es keinen BOM gibt, dann verwende die overload Variante der Methode und gib das gewünschte Encoding mit

Delphi-Quellcode:

LEncoding := nil;
LOffset := TEncoding.GetBufferEncoding( LBuffer, LEncoding, TEncoding.ANSI { dieses Default-Encoding verwenden } );

und das Kas is gerollt.

Oder etwa nicht?

[knaeuel]

ja, solange ich den Aufruf selber mache, passts. Problematisch wirds, wenn innerhalb der Delphi-Bibliotheken "GetBufferEncoding" aufgerufen wird. Dann kann ich nicht verhindern, dass (unter Linux) ANSI-Dateien fälschlicherweise als UTF-8 betrachtet werden.

Ich habe ja jetzt auch einen funktionierenden Workaround, seit ich gesehen habe, dass ich eine XML-Datei auch per LoadFromStream in die TXMLDocument-komponente bekomme. Da kann ich nämlich die Kodierung auch mitangeben.

Zum Feststellen der Kodierung einer Datei musste ich die Klasse TEncoding erben und die Methoden "GetBufferEncoding" und "GetDefault" überschreiben.

Durch diese neue Klasse TMyEncoding kann ich jetzt auch unter Linux ANSI-Dateien konvertieren und als z.B. UTF-8 oder UTF-16 LE/BE speichern. Das war vorher nicht möglich, weil eben auch wieder von einem falschen Quellformat ausgegangen wurde.

[TurboMagic]

Zitat von knaeuel:

ja, solange ich den Aufruf selber mache, passts. Problematisch wirds, wenn innerhalb der Delphi-Bibliotheken "GetBufferEncoding" aufgerufen wird. Dann kann ich nicht verhindern, dass (unter Linux) ANSI-Dateien fälschlicherweise als UTF-8 betrachtet werden.

Ich habe ja jetzt auch einen funktionierenden Workaround, seit ich gesehen habe, dass ich eine XML-Datei auch per LoadFromStream in die TXMLDocument-komponente bekomme. Da kann ich nämlich die Kodierung auch mitangeben.

Zum Feststellen der Kodierung einer Datei musste ich die Klasse TEncoding erben und die Methoden "GetBufferEncoding" und "GetDefault" überschreiben.

Durch diese neue Klasse TMyEncoding kann ich jetzt auch unter Linux ANSI-Dateien konvertieren und als z.B. UTF-8 oder UTF-16 LE/BE speichern. Das war vorher nicht möglich, weil eben auch wieder von einem falschen Quellformat ausgegangen wurde.

Ok, dann erstelle dopch mal einen QP Report. Dan sehen wir ja auch bald wie EMBT darauf reagiert.