Microsoft開發(fā)記事本的團(tuán)隊(duì),是不是使用了一個(gè)非常弱智的行為來保存UTF-8編碼的
時(shí)間:2023-11-30 10:48:02 | 來源:網(wǎng)站運(yùn)營
時(shí)間:2023-11-30 10:48:02 來源:網(wǎng)站運(yùn)營
Microsoft開發(fā)記事本的團(tuán)隊(duì),是不是使用了一個(gè)非常弱智的行為來保存UTF-8編碼的文件?:并不弱智,而是和Linux的做法一樣遵守Unicode標(biāo)準(zhǔn)推薦的做法。至于那些說Linux不鳥BOM不標(biāo)準(zhǔn)之類的,你發(fā)現(xiàn)了么,他們的回答里雖然都去Unicode網(wǎng)站截了圖,卻只找了一票Q&A,為啥不直接看標(biāo)準(zhǔn)文檔?
https://www.unicode.org/versions/Unicode10.0.0/UnicodeStandard-10.0.pdf為了方便大家看,這里把那段文字截圖+引用一把:
然后對(duì)比較重要的部分簡單說明一下:
字節(jié)序標(biāo)記(BOM)
UTF-16和UTF-32這兩個(gè)Unicode文本編碼形式在讀寫文件和網(wǎng)絡(luò)傳輸?shù)刃蛄谢瘓鼍爸袑?duì)字節(jié)序敏感。盡管Unicode理應(yīng)只包含一種規(guī)則,但沒這個(gè)能量去要求處理器硬得扭個(gè)字節(jié)序。
Unicode標(biāo)準(zhǔn)里的U+FEFF表示無寬度占位符,而U+FFFE則壓根不是字符,他倆都是不可見內(nèi)容,且是雙字節(jié)鏡像,所以在頭部添加一個(gè)標(biāo)記FEFF,如果雙方字節(jié)序一致,取到的都是FEFF,否則另一方取到的時(shí)FFFE,既能指明字節(jié)序是否正確,同時(shí)又都是不可見字符不影響文字表現(xiàn)。
而這樣的BOM標(biāo)記同時(shí)也是指出文件中有Unicode的標(biāo)記,稱之為Unicode簽名。UTF-16是可以把FEFF添加到頭部表示的,
為了保持一致性,UTF-8添加EFBBBF作為簽名。無論哪種簽名方式,因?yàn)槎际菦]用的符號(hào),所以通常不會(huì)讓人把它與后續(xù)的文字體弄混。
如果一個(gè)數(shù)據(jù)流(或者文件)以FEFF這樣的BOM作為開始,說明他很有可能包含Unicode字符。
推薦在傳輸U(kuò)nicode數(shù)據(jù)時(shí)使用BOM,但是如果已經(jīng)用了別的簽名方法,就不該用BOM當(dāng)Unicode簽名。換句話說,
MS在記事本里嵌BOM,不屬于不規(guī)范或者設(shè)計(jì)爛;UTF-8雖然字節(jié)序無關(guān),但是加上個(gè)Unicode簽名也并不是不合規(guī)矩的事情。Linux下的那些個(gè)工具,有自己的簽名方法,就那個(gè)首行注釋
#-*- coding:utf-8 -*-
這個(gè)也是編碼簽名,來自于Emacs(Specify Coding - GNU Emacs Manual),其它工具一般要么有自己的標(biāo)注方式,要么參照了Emacs的標(biāo)注方式,所以在Linux下不用BOM也是按照標(biāo)準(zhǔn)的推薦方法來做的做法。
如果說MS有什么事情做得不夠規(guī)范,那就是在記事本等軟件里,把UTF-16編碼方式寫成Unicode這個(gè)名字。因?yàn)榘凑誙nicode標(biāo)準(zhǔn),Unicode本身不是個(gè)編碼表現(xiàn)形式,存儲(chǔ)文件為Unicode編碼這個(gè)說法是說不通的;記事本里保存成Unicode其實(shí)是保存成UTF-16。
反倒是說,很多人,包括很多常年寫代碼的人,無論在Windows下還是Linux下,既不用BOM,也不做與系統(tǒng)標(biāo)準(zhǔn)一致的標(biāo)準(zhǔn)簽名(比如在Linux下做coding標(biāo)注),其實(shí)是屬于自己做得不標(biāo)準(zhǔn),就不要去怪任何一方設(shè)計(jì)太傻了吧……(當(dāng)然實(shí)際上很多做開發(fā)的人為了照顧用戶體驗(yàn),就算不寫編碼集標(biāo)記也會(huì)想辦法探測系統(tǒng)默認(rèn)編碼或者指定默認(rèn)編碼來嘗試解讀你的文件,比如Python3里默認(rèn)用UTF-8解析沒有編碼標(biāo)注的源碼,算是開發(fā)者的妥協(xié))