Probleme mit UTF-8

[BenTech]

Hi,
vielleicht hab ich gerade ein mittelgroßes Brett vorm Kopf, aber ich finde keine Lösung für folgendes Problem:
Ich habe eine Xml-Datei, die in UTF-8 codiert ist. Diese versuche ich mit "LoadFromFile" in ein Tnt-Memo zu laden. Seltsamer Weise werden hier die Umlaute genauso falsch angezeigt, wie wenn ich die Datei in ein "normales" Memo lade. Also statt einem "ä" steht dort ein "ä"

Ich habe noch nicht viel Erfahrung mit Unicode, meine aber mal gelesen zu haben, dass WideString Utf-16 entspricht. Liegt der Fehler jetzt darin, dass die Datei in Utf-8 gespeichert ist?
Wenn ja, wie kann ich das Problem lösen?

Herzlichen Dank schonmal für eure Hilfe

[cruiser]

schau dir mal UTF8ToUnicode und UnicodeToUTF8 an

[BenTech]

Okay, vielen Dank

Also war ich ein wenig auf dem Holzweg. Wie erkenne ich eigentlich, ob eine Textdatei in UTF-8 oder UTF-16 codiert ist?

[xaromz]

Hallo,

Zitat von BenTech:

Also war ich ein wenig auf dem Holzweg. Wie erkenne ich eigentlich, ob eine Textdatei in UTF-8 oder UTF-16 codiert ist?

Normalerweise besitzen codierte Dateien ein sogenanntes BOM am Anfang. Die Tnt-Komponenten können damit auch automatisch umgehen.

Gruß
xaromz

[Ydobon]

Ganz so automatisch ist es nicht, LoadFromFile erwartet immer eine UTF-16 Datei. Für UTF-8 (oder andere Codierungen) gibt es
TntMemo1.Lines.AnsiStrings.LoadFromFileEx('datei', CP_UTF8); Dann wird UTF8Decode schon mal intern aufgerufen, auch wenn es nicht die beste Funktion von Delphi ist.

Die Bommeln sind nicht unbedingt verlässlich, zumal sie für UTF-8 eigentlich überflüssig sind. Bei XML kann man aber meist mit UTF-8 rechnen. Wenn nur die Auswahl UTF-8 oder UTF-16 besteht, sollte es reichen, die Datei mal Byteweise zu lesen, trifft man auf Nullbytes, ist es UTF-16. Ansonsten ist aber UTF-8 eine der wenigen Codierungen, die sich einigermaßen eindeutig identifizieren lassen.

[xaromz]

Hallo,

Zitat von Ydobon:

Ganz so automatisch ist es nicht, LoadFromFile erwartet immer eine UTF-16 Datei.

Doch, es geht so automatisch. Die Klasse TntStrings ruft in der Methode "LoadFromFile" die Methode "AutoDetectCharacterSet" auf, welche das BOM auswertet. Wenn kein BOM vorhanden ist, geht diese Methode von ANSI aus.

Übrigens lässt sich UTF16 zumindest bei Inhalt in westlicher Sprache wesentlich leichter erkennen als UTF8 (nämlich wegen der NULL-Zeichen). Wenn bei einer UTF8-codierten Datei nur der letzte von einer Million Buchstaben codiert ist, muss die gesamte Datei geparst werden. Und vielleicht sollen da ja genau die zwei Bytes stehen und es ist gar nicht codiert. Insofern ist ein BOM schon nützlich.

Gruß
xaromz

[BenTech]

Zitat von xaromz:

Doch, es geht so automatisch. Die Klasse TntStrings ruft in der Methode "LoadFromFile" die Methode "AutoDetectCharacterSet" auf, welche das BOM auswertet. Wenn kein BOM vorhanden ist, geht diese Methode von ANSI aus.

Also müsste ich dann nurnoch prüfen, ob es sich um normales ANSI, oder um UTF-8 handelt. Das finde ich über die Analyse des BOM am Anfang der Datei raus. Das ist doch schonmal nicht schlecht

Zitat von Ydobon:

Die Bommeln sind nicht unbedingt verlässlich, zumal sie für UTF-8 eigentlich überflüssig sind.

Inwieweit ist das BOM nicht verlässlich?

[Edit: Die Frage hat sich erledigt. Ich habe gerade gelesen, dass das BOM bei UTF-8 Dateien keine Pflicht ist. So kann ich das wirklich nicht als zuverlässigen Indikator nutzen. Wie Unterscheide ich dann UTF-8 von ANSI? Oder kann ich UTF8ToAnsi zur Sicherheit immer vorher anwenden?]

[Ydobon]

Besser nicht auf eine BOM verlassen, sonst ist man schneller selbiges, als man möchte. Dass bei deiner Datei keine dabei war, hast du ja gemerkt. Wenn es nur um XML geht, sollte man davon ausgehen können, dass hier die Codierung noch einmal direkt in der Datei angegeben ist. Wenn ich mich richtig erinnere, gab es hier vor nicht allzu langer Zeit auch schon mal ein längeres Thema dazu.

Ansonsten ist die Erkennung der Codierung ein recht freudiges Thema.
Falls es sich auf nur CP1252, UTF-8 und UTF-16 Dateien beschränkt, ist es aber noch recht einfach. Bei UTF-16 gibt es halt Nullbytes und das schon beim ersten "<". UTF-8 hat strikte Regeln, die für alle Zeichen eingehalten werden müssen. ANSI ist dann der Rest. Um nicht selbst auf UTF-8 testen zu müssen, kannst du UTF8Decode verwenden, das gibt einen Leerstring zurück, wenn es irgendwo ein illegales Zeichen findet.
Also, ein paar Bytes einlesen, ist eine Null dabei, dann ist es UTF-16, gibt UTF8Decode für den gesamten Text mehr als einen Leerstring zurück, ist es UTF-8, sonst kann es bei der Auswahl nur ANSI sein.

[mkinzler]

Auf SourceForge gibt es ein Projekt, daß sich diesem Thema annimmt:
http://sourceforge.net/projects/utf8vcl

[Robert Marquardt]

utf8VCL ist aber noch ganz frisch.