Windows-1252 in UTF-8 umwandeln und Zeilenenden erhalten

Ein bytegenaues Beispiel zum Erhalt von Akzenten, Eurozeichen und CRLF bei einer lokalen UTF-8-Konvertierung.

Ein nachvollziehbares Beispiel

Klicken Sie auf Windows-1252-Beispiel laden. Die künstliche Datei enthält genau acht Bytes: 43 61 66 E9 20 80 0D 0A. Windows-1252 wird ausdrücklich ausgewählt. Der erwartete Unicode-Text lautet Café €\r\n: Die Schlussnotation bezeichnet ein tatsächliches CR gefolgt von LF, keine vier wörtlichen Zeichen.

Die Codepunkte sind U+0043 U+0061 U+0066 U+00E9 U+0020 U+20AC U+000D U+000A. Die Eingabe ist kein striktes UTF-8, weil auf E9 nicht die nötigen Fortsetzungsbytes folgen. Das ist ein Grund, die Quellkodierung zu prüfen, kein Beweis für Windows-1252 bei jeder ähnlichen Datei.

1. Lassen Sie Windows-1252 ausgewählt und klicken Sie auf Konvertierung prüfen.
2. Kontrollieren Sie Café € sowie ein CRLF und einen abschließenden Zeilenumbruch in den Details.
3. Lassen Sie die Ausgabe-BOM deaktiviert, außer die Zielanwendung verlangt sie ausdrücklich.
4. Laden Sie die Ausgabe herunter. Ihre elf Bytes lauten 43 61 66 C3 A9 20 E2 82 AC 0D 0A.
5. Mit aktivierter BOM prüfen Sie erneut: Die Ausgabe hat vierzehn Bytes, mit EF BB BF vor diesen elf Bytes.

Warum die Bezeichnung „ANSI“ nicht genügt

„ANSI“ ist als Softwarebezeichnung mehrdeutig. Windows-1252 ordnet Byte 80 dem Eurozeichen zu; ISO-8859-1 bildet es auf U+0080 ab, ein hier abgelehntes C1-Steuerzeichen. Die Bytes 81, 8D, 8F, 90 und 9D sind in der strikten Windows-1252-Zuordnung dieses Tools undefiniert und stoppen die Konvertierung. Fragen Sie beim Ersteller des Exports nach der tatsächlichen Kodierung, statt nur eine lesbare Vorschau zu wählen.

BOM, UTF-16 und unvollständige Bytefolgen am Dateiende

FF FE 41 00 0D 00 0A 00 ist ein UTF-16LE-Beispiel mit BOM. Daraus wird 41 0D 0A in UTF-8 ohne BOM: A gefolgt von CRLF. Ohne BOM muss UTF-16 ausdrücklich gewählt werden. Ein einzelnes Schlussbyte oder ein fehlerhaftes Surrogat stoppt die Konvertierung, auch außerhalb des sichtbaren Ausschnitts. Eine UTF-32-BOM wird erkannt, das Format aber nicht unterstützt.

Was erhalten bleibt und was verloren ist

Leerzeichen, Tabulatoren, gemischte CRLF/LF/CR-Zeilenenden, das Vorhandensein oder Fehlen eines letzten Zeilenumbruchs und zusammengesetzte oder kombinierende Unicode-Zeichen bleiben erhalten. Nur die ursprüngliche führende BOM wird entfernt; eine Ausgabe-BOM ist Ihre Wahl. Ein bereits vorhandenes U+FFFD bleibt bestehen. Eine Konvertierung von bereits beschädigtem „Café“ stellt die Originalbytes nicht wieder her.

Die Grenze beträgt 5 MiB (5.242.880 Bytes). Die Vorschau zeigt höchstens 16.000 UTF-16-Codeeinheiten, doch Validierung und Export betreffen die gesamte Datei. Bekannte Binärsignaturen und NUL/C0/C1-Steuerzeichen außer Tabulator, CR und LF werden abgelehnt. Diese Vorsicht kann ungewöhnlichen legitimen Text ausschließen. Der Download ist eine reine Textdatei mit .utf8.txt; das Original wird nicht überschrieben.

Bei CSV konvertieren Sie erst die Kodierung und nutzen danach CSV zu JSON für die Struktur. Der Kodierungsprüfer liest keine CSV-Felder und verändert keine Trennzeichen. Er arbeitet im Speicher ohne eigene Netzwerkanfragen oder Browserspeicherung; die Website lädt weiterhin ihre Ressourcen. Probieren Sie das Beispiel im Kodierungsprüfer aus.