Problemet med BOM-första tecken som uppstår när man läser Unicode-filer (UTF-8, etc.) i Java och hur man hanterar dem
Textfiler skapade med en textredigerare i Windows kommer att få ett BOM-ID lagt till i filhuvudet (det första tecknet) om du väljer att spara dem i ett Unicode-format som UTF-8.
Denna identifiering tas inte bort när filen läses i Java, och String.trim() kan inte tas bort. Om du använder readLine() för att läsa den första raden och lagrar den i strängen, blir längden på strängen 1 större än vad du ser, och det första tecknet är denna styckliste.
Detta kan orsaka problem, till exempel när du läser en ini-fil, om du vill se om första raden börjar med "[" kan du inte bedöma rätt.
Som tur är, när Java läser Unicode-filer, ändrar det enhetligt stycklistan till "\uFEFF", så du kan lösa det manuellt (efter bedömning, använd substring() eller replace() för att ta bort denna styckliste):
Men,Detta tillvägagångssätt är inte perfektOm den genererade jar-filen körs under Windows finns det fortfarande ett problem. Den ultimata lösningen är att använda BOMInputStream som tillhandahålls av apache commons io:
Vad är BOM?
BOM = Byte Order Mark
Stykklisten är den rekommenderade metoden för att markera byteordningen i Unicode-specifikationen. Till exempel, för UTF-16, om mottagaren får en BOM av FEFF, indikerar det att byteströmmen är Big-Endian; Om FFFE tas emot indikerar det att byteströmmen är Little-Endian.
UTF-8 kräver inte en styckliste för att ange byteordning, men den kan användas för att ange "Jag är UTF-8-kodad". UTF-8-kodningen av stycklisten är EF BB BF (som ses genom att öppna text med UltraEdit och växla till hexadecimal). Så om mottagaren får en byteström som börjar med EF BB BF, vet de att det är UTF-8-kodning.
|
Publicerad på 2019-01-14 16:26:17
|
|
|
