Problemet med BOM-første tegn, der opstod, når man læste Unicode-filer (UTF-8 osv.) i Java, og hvordan man håndterer dem
Tekstfiler oprettet med en teksteditor i Windows vil få et BOM-ID tilføjet til filheaderen (det første tegn), hvis du vælger at gemme dem i Unicode-format som UTF-8.
Denne identifikation fjernes ikke, når filen læses i Java, og String.trim() kan ikke fjernes. Hvis du bruger readLine() til at læse den første linje og gemme den i strengen, vil længden af strengen være 1 ord større end det, du ser, og det første tegn er denne stukliste.
Dette kan give nogle problemer, for eksempel når du læser en ini-fil, hvis du vil se, om den første linje starter med "[], kan du ikke bedømme korrekt.
Heldigvis, når Java læser Unicode-filer, ændrer det ensartet stykklisten til "\uFEFF", så du kan løse det manuelt (efter vurdering, brug substring() eller replace() for at fjerne denne listeliste):
Men,Denne tilgang er ikke perfektHvis den genererede jar-fil kører under Windows, er der stadig et problem. Den ultimative løsning er at bruge BOMInputStream, som leveres af apache commons io:
Hvad er BOM?
BOM = Byte Order Mark
BOM er den anbefalede metode til at markere rækkefølgen af bytes i Unicode-specifikationen. For eksempel, for UTF-16, hvis modtageren modtager en BOM af FEFF, indikerer det, at bytestrømmen er Big-Endian; Hvis FFFE modtages, indikerer det, at bytestrømmen er Little-Endian.
UTF-8 kræver ikke en stykk for at angive byte-rækkefølge, men den kan bruges til at angive "Jeg er UTF-8-kodet". UTF-8-kodningen af BOM er EF BB BF (som ses ved at åbne tekst med UltraEdit og skifte til hexadecimal). Så hvis modtageren modtager en bytestrøm, der starter med EF BB BF, ved de, at det er UTF-8-kodning.
|
Opslået på 14/01/2019 16.26.17
|
|
|
