A BOM első karakterek problémája, amelyekkel Unicode fájlok (UTF-8 stb.) olvasása közben Java-ban találkozunk, és hogyan kezeljük őket
A Windowsban szövegszerkesztővel létrehozott szövegfájlokhoz BOM azonosító (BOM ID) kerül a fájlfejléchez (az első karakterhez), ha Unicode formátumban, például UTF-8-ban mented őket.
Ez az azonosítás nem kerül el, ha a fájlt Java-ban olvassuk, és a String.trim() nem távolítható. Ha readLine() segítségével olvasod az első sort és eltárolod a Stringben, akkor a String hossza 1-vel nagyobb lesz, mint amit látsz, és az első karakter ez a BOM.
Ez problémát okozhat, például egy ini fájl olvasásakor, ha meg akarod mondani, hogy az első sor "["-vel-e kezdődik-e, nem tudod helyesen ítélni.
Szerencsére, amikor a Java Unicode fájlokat olvas, egyenletesen megváltoztatja a BOM-ot "\uFEFF"-re, így manuálisan meg lehet oldani (ítélet után használd a substring() vagy a replace() használatát, hogy eltávolítsd ezt a BOM-ot):
AzonbanEz a megközelítés nem tökéletesHa a generált jar fájl Windows alatt fut, akkor is fennáll a probléma. A végső megoldás az apache commons io által biztosított BOMInputStream használata:
Mi az a BOM?
BOM = Bájt-sorrend jel
A BOM a javasolt módszer a bájtok sorrendjének megjelölésére a Unicode specifikációban. Például UTF-16 esetén, ha a vevő FEFF BOM-ot kap, az azt jelzi, hogy a bájtfolyam Big-Endian; Ha FFFE érkezik, az azt jelzi, hogy a bytestream Little-Endian.
Az UTF-8 nem igényel BOM-ot a bájtsorrend megjelöléséhez, de használható arra, hogy jelezze: "UTF-8 vagyok kódolva". A BOM UTF-8 kódolása EF BB BF (amit az UltraEdit-tel nyitva és hatdexineltira, akkor is látható). Tehát ha a vevő egy EF BB BF-vel kezdődő bájtfolyamot kap, akkor tudja, hogy UTF-8 kódolásról van szó.
|
Közzétéve 2019. 01. 14. 16:26:17
|
|
|
