所在位置：
首页 >
营销资讯 >
网站运营 > Microsoft开发记事本的团队，是不是使用了一个非常弱智的行为来保存UTF-8编码的
Microsoft开发记事本的团队，是不是使用了一个非常弱智的行为来保存UTF-8编码的
时间：2023-11-30 10:48:02 | 来源：网站运营
时间：2023-11-30 10:48:02 来源：网站运营
Microsoft开发记事本的团队，是不是使用了一个非常弱智的行为来保存UTF-8编码的文件？：并不弱智，而是和Linux的做法一样遵守Unicode标准推荐的做法。至于那些说Linux不鸟BOM不标准之类的，你发现了么，他们的回答里虽然都去Unicode网站截了图，却只找了一票Q&A，为啥不直接看标准文档？
https://www.unicode.org/versions/Unicode10.0.0/UnicodeStandard-10.0.pdf为了方便大家看，这里把那段文字截图+引用一把：
然后对比较重要的部分简单说明一下：
字节序标记（BOM）
UTF-16和UTF-32这两个Unicode文本编码形式在读写文件和网络传输等序列化场景中对字节序敏感。尽管Unicode理应只包含一种规则，但没这个能量去要求处理器硬得扭个字节序。
Unicode标准里的U+FEFF表示无宽度占位符，而U+FFFE则压根不是字符，他俩都是不可见内容，且是双字节镜像，所以在头部添加一个标记FEFF，如果双方字节序一致，取到的都是FEFF，否则另一方取到的时FFFE，既能指明字节序是否正确，同时又都是不可见字符不影响文字表现。
而这样的BOM标记同时也是指出文件中有Unicode的标记，称之为Unicode签名。UTF-16是可以把FEFF添加到头部表示的，
为了保持一致性，UTF-8添加EFBBBF作为签名。无论哪种签名方式，因为都是没用的符号，所以通常不会让人把它与后续的文字体弄混。
如果一个数据流（或者文件）以FEFF这样的BOM作为开始，说明他很有可能包含Unicode字符。
推荐在传输Unicode数据时使用BOM，但是如果已经用了别的签名方法，就不该用BOM当Unicode签名。换句话说，
MS在记事本里嵌BOM，不属于不规范或者设计烂；UTF-8虽然字节序无关，但是加上个Unicode签名也并不是不合规矩的事情。Linux下的那些个工具，有自己的签名方法，就那个首行注释
#-*- coding:utf-8 -*-这个也是编码签名，来自于Emacs（Specify Coding - GNU Emacs Manual），其它工具一般要么有自己的标注方式，要么参照了Emacs的标注方式，所以在Linux下不用BOM也是按照标准的推荐方法来做的做法。
如果说MS有什么事情做得不够规范，那就是在记事本等软件里，把UTF-16编码方式写成Unicode这个名字。因为按照Unicode标准，Unicode本身不是个编码表现形式，存储文件为Unicode编码这个说法是说不通的；记事本里保存成Unicode其实是保存成UTF-16。
反倒是说，很多人，包括很多常年写代码的人，无论在Windows下还是Linux下，既不用BOM，也不做与系统标准一致的标准签名（比如在Linux下做coding标注），其实是属于自己做得不标准，就不要去怪任何一方设计太傻了吧……（当然实际上很多做开发的人为了照顾用户体验，就算不写编码集标记也会想办法探测系统默认编码或者指定默认编码来尝试解读你的文件，比如Python3里默认用UTF-8解析没有编码标注的源码，算是开发者的妥协）
在线咨询
