BOM-i esimeste märkide probleem, millega tekivad Unicode failide (UTF-8 jne) lugemisel Java-s ja kuidas nendega toime tulla
Windowsis tekstiredaktoriga loodud tekstifailidele lisatakse BOM ID failipäisele (esimene märk), kui salvestada need Unicode formaadis, näiteks UTF-8.
See identifitseerimine ei kao, kui faili loetakse Java-s, ning String.trim() ei saa eemaldada. Kui kasutad readLine() esimese rea lugemiseks ja salvestad selle stringi, on stringi pikkus 1 võrra suurem kui see, mida näed, ja esimene märk on see BOM.
See võib tekitada probleeme, näiteks ini-faili lugemisel, kui tahad teada, kas esimene rida algab tähega "[", ei saa sa õigesti hinnata.
Õnneks, kui Java loeb Unicode'i faile, muudab ta BOM-i ühtlaselt "\uFEFF"-iks, nii et saad selle käsitsi lahendada (pärast otsust kasuta substring() või replace() selle BOM-i eemaldamiseks):
KuidSee lähenemine ei ole täiuslikKui genereeritud jar-fail töötab Windowsis, on probleem ikkagi olemas. Parim lahendus on kasutada BOMInputStreami, mida pakub apache commons io:
Mis on BOM?
BOM = Baitide järjekorra märk
BOM on soovitatav meetod baitide järjekorra märkimiseks Unicode'i spetsifikatsioonis. Näiteks UTF-16 puhul, kui vastuvõtja saab BOM-i FEFF, näitab see, et baitvoog on Big-Endian; Kui FFFE vastu võetakse, näitab see, et baitvoog on Little-Endian.
UTF-8 ei nõua baitide järjekorra näitamiseks BOM-i, kuid seda saab kasutada selleks, et näidata "Olen UTF-8 kodeeritud". BOM-i UTF-8 kodeerimine on EF BB BF (nagu näha, kui avada teksti UltraEditiga ja lülituda kuueteistkümnendsüsteemile). Kui vastuvõtja saab baitvoo, mis algab EF BB BF-ga, teab ta, et see on UTF-8 kodeerimine.
|
Postitatud 14.01.2019 16:26:17
|
|
|
