Kann jemand dieses kodierungsbezogene Verhalten erklären?

Kann jemand dieses kodierungsbezogene Verhalten erklären?

Kodieren ist nicht meine Stärke, obwohl ich schon viel gelesen habe.

Es gibt eine Datei, die ich bearbeiten möchte. Ihre Erweiterung ist .tdl, aber das bedeutet nichts Besonderes.

Es handelt sich um eine XML-Datei. Die erste Zeile sieht folgendermaßen aus:

<?xml version="1.0" encoding="utf-16"?>

Wenn ich versuche, diese Datei mit gedit zu öffnen, erhalte ich eine große Meldung auf gelbem Hintergrund mit folgendem Inhalt:

„Beim Öffnen der Datei ist ein Problem aufgetreten … Die von Ihnen geöffnete Datei enthält einige ungültige Zeichen. Wenn Sie mit der Bearbeitung dieser Datei fortfahren, könnte das Dokument beschädigt werden. Sie können auch eine andere Zeichenkodierung wählen und es erneut versuchen.“

In der Dropdown-Box „Zeichenkodierung“ darunter steht „Aktuelles Gebietsschema (UTF-8)“.

Ich versuche, das auf „Unicode (UTF-16)“ einzustellen und klicke auf „Wiederholen“. Die unangenehme Meldung kommt wieder und das Dropdown-Menü wird wieder auf „Aktuelles Gebietsschema (UTF-8)“ eingestellt.

Ich habe auch versucht, die Datei zu öffnen, indem ich auf Datei --> Öffnen --> Zeichenkodierung gehe: von „Automatisch erkannt“ auf „Unicode (UTF-16)“ ändere. Aber ich bekomme wieder die unangenehme Meldung, wieder mit der Dropdown-Liste „Aktuelles Gebietsschema (UTF-8)“.

Programmgesteuert (mit Groovy groovy.xml.XMLParser) kann ich diese Datei analysieren und eine scheinbar gültige groovy.util.NodeStruktur erstellen. Ich bin noch nicht so weit gekommen, diese interne Node-Struktur zu speichern, ob geändert oder nicht.

Kann mir jemand sagen, was mit dieser Datei nicht stimmt (falls überhaupt etwas nicht stimmt) und wie ich sie sicher bearbeiten kann?

Antwort1

In UTF-16 bestehen Zeichen aus zwei Bytes und für ASCII-Zeichen ist das höchste Byte 0x00.

Beispielsweise ist „Etwas“ in UTF-16:

00000000  ff fe 53 00 6f 00 6d 00  65 00 74 00 68 00 69 00  |..S.o.m.e.t.h.i.|
00000010  6e 00 67 00 0a 00                                 |n.g...|

( OxFFFEAm Anfang steht die Byte-Order-Markierung. Wenn Sie 0xFEFF sehen, wissen Sie, dass Sie Bytes vertauschen müssen …).

Die überall herumliegenden NUL-Zeichen verwirren die Software ...

Sie können in ein praktischeres UTF-8 konvertieren, indem Sie Folgendes verwenden iconv:

iconv -f UTF-16 -t UTF-8 <utf16file >utf8file

Und vergessen Sie nicht, die Kodierung im Dateikopf zu ändern

Antwort2

Wenn die Datei UTF-16 ist (Windows-typische Kodierung), werden Sie unter Linux Probleme haben (UTF-8 nativ, militant...). Zumindest behauptet GNU Emacs, dass es UTF-16 unterstützt, ich habe es nie aus Wut verwendet.

Sie können versuchen, mit recode(1) in UTF-8 zu übersetzen (und Header etc. entsprechend zu korrigieren), aber das könnte Tools, die UTF-16 erwarten, erheblich beschädigen.

Aktualisieren:Habe gerade darüber nachgedacht: Umkodieren auf UTF-8; nach Belieben mangle, spindeln, verunstalten; zurück auf UTF-16 kodieren. Auf diese Weise können Sie vertraute Werkzeuge in der Mitte verwenden. AberTunKorrektur der angekündigten UTF-16-Kodierung. Wer weiß, ob die Tools dadurch verwirrt werden. Oder vielleicht beachten XML-Mangling-Tools dies doch ...

verwandte Informationen