Das Problem der BOM-Erstzeichen, die beim Lesen von Unicode-Dateien (UTF-8 usw.) in Java auftreten, und wie man damit umgeht
Textdateien, die mit einem Texteditor unter Windows erstellt werden, erhalten eine BOM-ID (das erste Zeichen), wenn Sie sie in einem Unicode-Format wie UTF-8 speichern.
Diese Identifikation wird nicht entfernt, wenn die Datei in Java gelesen wird, und String.trim() kann nicht entfernt werden. Wenn du readLine() verwendest, um die erste Zeile zu lesen und sie im String zu speichern, ist die Länge des Strings 1 Mal größer als das, was du siehst, und das erste Zeichen ist dieser Stückliste.
Das kann Probleme verursachen, zum Beispiel beim Lesen einer ini-Datei; wenn du wissen willst, ob die erste Zeile mit "[[beginnt", kannst du nicht richtig urteilen.
Glücklicherweise ändert Java beim Lesen von Unicode-Dateien den Stückliste einheitlich zu "\uFEFF", sodass man das Problem manuell lösen kann (nach Urteil, substring() oder ersetzen() verwenden, um diesen BOM zu entfernen):
Allerdings,Dieser Ansatz ist nicht perfektWenn die generierte jar-Datei unter Windows läuft, gibt es weiterhin ein Problem. Der ultimative Workaround ist die Verwendung des BOMInputStreams, der von apache commons io bereitgestellt wird:
Was ist BOM?
BOM = Byte Order Mark
Der BOM ist die empfohlene Methode, um die Reihenfolge der Bytes in der Unicode-Spezifikation zu markieren. Zum Beispiel zeigt bei UTF-16, wenn der Empfänger einen BOM von FEFF erhält, an, dass der Bytestrom Big-End ist; Wenn FFFE empfangen wird, zeigt dies an, dass der Bytestream Little-Endian ist.
UTF-8 benötigt keinen BOM zur Angabe der Bytereihenfolge, kann aber verwendet werden, um anzugeben: "Ich bin UTF-8-codiert". Die UTF-8-Codierung der Stückliste ist EF BB BF (sichtbar durch das Öffnen des Textes mit UltraEdit und das Wechseln auf hexadezimal). Wenn der Empfänger also einen Bytestrom erhält, der mit EF BB BF beginnt, weiß er, dass es sich um eine UTF-8-Codierung handelt.
|
Veröffentlicht am 14.01.2019 16:26:17
|
|
|
