Textkodierungskonverter
Dekodiert wohlgeformte UTF-8-, UTF-16LE- oder UTF-16BE-Bytes in Unicode-Text, normalisiert optional Zeilenenden und schreibt dann dieselben Zeichen in einer dieser drei Codierungen mit einer expliziten Auswahl der Byte-Reihenfolgemarkierung.
Eine reine Textdatei mit bis zu 25 MB. Binärformate wie Word-Dokumente sind keine Textkodierungen und werden abgelehnt.
Die Ergebnisse werden ohne Gewähr für ihre Richtigkeit bereitgestellt. Die Methode und ihre Quellen stehen unten, damit Sie den Rechenweg prüfen können.
So funktioniert es
Was das bringt
Eine Textdatei besteht aus Bytes und einer Vereinbarung darüber, was diese Bytes bedeuten. UTF-8, UTF-16 Little-Endian und UTF-16 Big-Endian können dieselben Unicode-Zeichen darstellen, verwenden jedoch unterschiedliche Bytesequenzen. Wenn Sie UTF-16 als UTF-8 öffnen, wird keine andere Schriftart angezeigt. es dekodiert die falschen Zahlen.
Dieser Konverter macht beide Vereinbarungen sichtbar: wie man die Quelle liest und wie man das Ergebnis schreibt. Die automatische Erkennung ist bewusst eng gefasst. Es erkennt eine Unicode-Byte-Reihenfolge-Markierung und verwendet ansonsten UTF-8 – die sichere Standardeinstellung des Webs –, anstatt Gewissheit über eine unmarkierte Legacy-Codepage zu erfinden.
Die Methode
Der BOM-Sniff des WHATWG Encoding Standards ist eine dreizeilige Tabelle:
| Führende Bytes | Codierung |
|---|---|
EF BB BF | UTF-8 |
FF FE | UTF-16 Little-Endian |
FE FF | UTF-16 Big-Endian |
Der Marker wird entfernt, bevor der Text freigelegt wird. Wenn eine Quellkodierung manuell ausgewählt wird und ihre Markierung etwas anderes sagt, wird die Datei abgelehnt. Eine UTF-16LE-Markierung mit einer UTF-16BE-Auswahl ist ein stärkerer Beweis als ein Dateiname oder eine Vermutung.
Die Dekodierung ist fatal: Jedes Eingabebyte muss zu einer wohlgeformten Sequenz gehören. Das Unicode-Konsortium erlaubt Wiederherstellungsaktionen wie das Ersetzen von Zeichen für illegale Eingaben, die Ersetzung erfolgt jedoch nicht durch den Originaltext. Ein Konverter, dessen Versprechen verlustfrei ist, sollte anhalten und dem Besitzer die Auswahl eines Wiederherstellungstools überlassen.
Vor dem Weiterlesen
Eine nicht markierte Datei enthält das Byte 80. Kann die alte Codierung allein anhand dieses Bytes identifiziert werden?
Nein. Ein nicht markierter Legacy-Bytestream enthält nicht genügend Informationen, um alle Codepages zu unterscheiden. Die automatische Erkennung erkennt daher explizite Unicode-Stücklisten und erfordert ansonsten wohlgeformtes UTF-8.
Ein gelungenes Beispiel
song.txt ist UTF-16LE mit der Zwei-Byte-Markierung FF FE und enthält:
café
🎵
Der sichtbare Inhalt verfügt über 9 Unicode-Codepunkte: vier Buchstaben, zwei CRLF-Paare und ein Musiknotenzeichen. UTF-16 speichert die Notiz als Ersatzpaar – zwei 16-Bit-Codeeinheiten –, es bleibt jedoch ein Codepunkt.
Die Quelle umfasst 22 Bytes: 2 Markierungsbytes plus 10 UTF-16-Codeeinheiten. Als UTF-8 ohne Markierung und unter Beibehaltung der Zeilenenden geschrieben, beträgt das Ergebnis 13 Byte. Der genaue Text bleibt café\r\n🎵\r\n und der heruntergeladene Dateiname ist song-utf8.txt. Der Formeltest bestätigt alle 22 Eingabebytes, die 13 Ausgabebytes, die Zeichenanzahl, beide Codierungsbezeichnungen und den Dateinamen.
Byte-Reihenfolge und Byte-Reihenfolge-Markierungen
UTF-8 arbeitet mit Acht-Bit-Codeeinheiten und hat auf jedem Prozessor die gleiche Bytesequenz. Sein Marker ist eine Signatur, kein Endian-Schalter. ASCII-Zeichen bleiben ihre ASCII-Bytes; andere Codepunkte benötigen zwei bis vier Bytes.
UTF-16 funktioniert in 16-Bit-Codeeinheiten. UTF-16LE schreibt zuerst das niedrigstwertige Byte jeder Einheit; UTF-16BE schreibt das höchstwertige Byte zuerst. Zeichen über U+FFFF verwenden ein Hoch- und Tief-Ersatzzeichen, sodass jede Byte-Reihenfolge vier Bytes für dieses Zeichen benötigt. Der Marker ermöglicht es einem Leser, die beiden Serialisierungen zu unterscheiden, wenn kein externes Etikett vorhanden ist.
Zeilenenden sind eine separate Auswahl
Für die Änderung von UTF-16LE in UTF-8 ist keine Änderung von CRLF in LF erforderlich. Es handelt sich um verschiedene Ebenen: Eine Kodierung ordnet Zeichen Bytes zu, während ein Zeilenende aus einem oder zwei Zeichen besteht, die sich bereits im Text befinden. Genau beibehalten lässt einzelne CR-, LF- und CRLF-Sequenzen an ihrem Platz. Die erweiterten Auswahlmöglichkeiten normalisieren zunächst alle drei und schreiben dann konsistent als LF oder CRLF.
Was es nicht tut
.docx, PDF, Rich Text oder andere Container, deren sichtbare Wörter in einem strukturierten Binärformat vorliegen, werden nicht geöffnet. Es erkennt auch nicht Windows-1252, Shift_JIS, GBK oder eine andere ältere Kodierung. Diese Konvertierungen sind möglich, wenn die Quellbezeichnung bekannt ist, aber das automatische Erraten würde das Kernversprechen des Tools, dass sich Zeichen nicht stillschweigend ändern, schwächen.
Es führt eine Unicode-Codierungskonvertierung durch, keine Unicode-Normalisierung. Ein zusammengesetztes é und die kanonisch äquivalente Folge e plus Kombinationsakut bleiben in der von der Quelle verwendeten Form erhalten.
So wird es gemacht
- Überprüfen Sie die ersten drei Bytes auf EF BB BF (UTF-8), FF FE (UTF-16LE) oder FE FF (UTF-16BE). Im automatischen Modus wählt der Markierer den Decoder; ohne eine benötigen Sie UTF-8, anstatt eine alte Codepage zu erraten.
- Wenn die Quellkodierung manuell ausgewählt wird, ist die Zustimmung aller vorhandenen Markierungen erforderlich. Entfernen Sie die vereinbarte Markierung und dekodieren Sie dann im Fatal-Modus, sodass eine illegale Bytesequenz die Konvertierung stoppt, anstatt zu einem stillen Ersatzzeichen zu werden.
- Behalten Sie standardmäßig jede CR-, LF- und CRLF-Sequenz bei. Nur wenn diese Option ausgewählt ist, werden alle drei Formen als separater Vorgang von der Zeichenkodierung auf LF oder CRLF normalisiert.
- Zählen Sie Unicode-Codepunkte und behandeln Sie ein gültiges UTF-16-Ersatzzeichenpaar als ein zusätzliches Zeichen. Kodieren Sie die resultierende Zeichenfolge als UTF-8-Bytes oder als Zwei-Byte-UTF-16-Codeeinheiten in der ausgewählten Bytereihenfolge.
- Fügen Sie den ausgewählten Zielmarker – EF BB BF, FF FE oder FE FF – nur hinzu, wenn Sie dazu aufgefordert werden, und bieten Sie dann eine separate TXT-Datei an. Die Quelldatei wird nie geändert.
Wovon es ausgeht
- Auto ist absichtlich auf die drei Unicode-Bytereihenfolgemarkierungen beschränkt. Eine nicht markierte Datei verwendet standardmäßig das strikte UTF-8; Windows-1252-, ISO-8859-Varianten und andere ältere Codepages können nicht zuverlässig anhand von Bytes allein unterschieden werden.
- Eine Bytereihenfolgemarkierung am Anfang stellt Metadaten dar und wird vor dem ersten Textzeichen verbraucht. Ein U+FEFF weiter unten in der Datei ist Inhalt und bleibt Inhalt.
- UTF-8 hat keine Frage zur Bytereihenfolge; seine Stückliste ist nur eine Signatur. UTF-16LE und UTF-16BE serialisieren dieselben 16-Bit-Codeeinheiten in entgegengesetzter Bytereihenfolge.
- Ungültige UTF-Sequenzen werden abgelehnt statt repariert. Die Eingabeobergrenze beträgt 25 MB und die Codepunkt- und UTF-16-Schleifen ergeben alle 250.000 Codeeinheiten für Fortschritt und Abbruch.
Fragen
Wird die Textdatei zur Kodierungskonvertierung hochgeladen?
Nein. Die Bytes werden in einem Worker auf dieser Browser-Registerkarte dekodiert und neu kodiert, und die neue Datei wird lokal zusammengestellt. Der generierte Browsertest schlägt fehl, wenn die Verwendung einer echten Datei eine Anfrage vom Ursprung von Tessalor weg sendet.
Was passiert, wenn eine ungültige UTF-8- oder UTF-16-Sequenz gefunden wird?
Die Konvertierung endet mit einer Erklärung. Das Ersetzen von U+FFFD kann eine nützliche Wiederherstellungsrichtlinie sein, aber es ändert Daten; Ein allgemeiner Konverter sollte diese Entscheidung nicht ungefragt treffen.
Benötigt UTF-8 eine Byte-Reihenfolge-Markierung?
UTF-8 ist byteorientiert und weist daher keine Endian-Mehrdeutigkeit auf. EF BB BF ist lediglich eine Codierungssignatur und in modernen Web- und Befehlszeilen-Workflows normalerweise unnötig, obwohl einige ältere Software dies erwartet.
Warum kann ein Emoji sowohl in UTF-8 als auch in UTF-16 vier Bytes belegen?
Ein zusätzliches Unicode-Zeichen verwendet eine vier Byte lange UTF-8-Sequenz und ein Paar zwei Byte lange UTF-16-Ersatzcodeeinheiten. Es handelt sich immer noch um einen Codepunkt, weshalb die Ergebniszählung ihn nicht als zwei Zeichen bezeichnet.
Ändert eine Änderung der Kodierung auch die Zeilenenden unter Windows und Unix?
Nicht standardmäßig. Die Zeichenkodierung ordnet Zeichen Bytes zu. CRLF und LF sind Zeichenfolgen. Die erweiterte Steuerung hält diese Jobs getrennt und behält die ursprüngliche Reihenfolge bei, sofern keine Konvertierung ausgewählt wird.