Het probleem van BOM-eerste tekens die je tegenkomt bij het lezen van Unicode-bestanden (UTF-8, enz.) in Java en hoe je ermee om moet gaan
Tekstbestanden die met een teksteditor in Windows zijn gemaakt, krijgen een BOM-ID toegevoegd aan de bestandsheader (het eerste teken) als je ze opslaat in een Unicode-formaat zoals UTF-8.
Deze identificatie wordt niet verwijderd wanneer het bestand in Java wordt gelezen, en String.trim() kan niet worden verwijderd. Als je readLine() gebruikt om de eerste regel te lezen en deze in de string op te slaan, zal de lengte van de string één groter zijn dan wat je ziet, en het eerste teken is deze stuklijst.
Dit kan problemen veroorzaken, bijvoorbeeld bij het lezen van een ini-bestand; als je wilt zien of de eerste regel begint met "[", kun je niet correct inschatten.
Gelukkig verandert Java bij het lezen van Unicode-bestanden de BOM uniform naar "\uFEFF", zodat je het handmatig kunt oplossen (na het oordeel gebruik substring() of vervang() om deze BOM te verwijderen):
Echter,Deze aanpak is niet perfectAls het gegenereerde jar-bestand onder Windows draait, is er nog steeds een probleem. De ultieme oplossing is het gebruik van de BOMInputStream die wordt geleverd door apache commons io:
Wat is BOM?
BOM = Byte Order Mark
De BOM is de aanbevolen methode om de volgorde van bytes in de Unicode-specificatie te markeren. Bijvoorbeeld, voor UTF-16, als de ontvanger een BOM van FEFF ontvangt, geeft dit aan dat de bytestroom Big-End is; Als FFFE wordt ontvangen, geeft dit aan dat de bytestream Little-Endiaans is.
UTF-8 vereist geen BOM om bytevolgorde aan te geven, maar kan wel worden gebruikt om aan te geven "Ik ben UTF-8-gecodeerd". De UTF-8-codering van de BOM is EF BB BF (zoals te zien is door tekst te openen met UltraEdit en over te schakelen naar hexadecimaal). Dus als de ontvanger een bytestroom ontvangt die begint met EF BB BF, weten ze dat het UTF-8-codering is.
|
Geplaatst op 14-01-2019 16:26:17
|
|
|
