UTF8尽好永不带BOM,附许多经典评价

By admin in 天文学 on 2018年11月18日

UTF-8 不需要 BOM,尽管 Unicode 标准允许以 UTF-8 中利用 BOM。
所以勿含有 BOM 的 UTF-8
才是专业形式,**
在 UTF-8
文件中放置 BOM 主要是微软的习惯(顺便取一下:将带有 BOM 的小端序 UTF-16
称作「Unicode」而同时不详细说明,这为是微软的习惯)。 BOM(byte order mark)是为 UTF-16 和
UTF-32 准备的,用于标记字节序(byte order)微软于 UTF-8 中以 BOM 是坐如此可管 UTF-8
和 ASCII 等编码明确区分开,但这样的文件在 Windows
之外的操作系统里会带动问题。**

「UTF-8」和「带 BOM 的 UTF-8」的分别就是发生没来 BOM。即文件开始有没有出
U+FEFF。
UTF-8 的网页代码不应允采用 BOM,否则常常会出错。这是一个稍稍例子:
为什么这个网页代码 <head> 内的音会叫浏览器理解也当 <body>
内?

其它把《The Unicode Standard, Version 6.0》之 3.10 D95 UTF-8 encoding
scheme 的平等段话:
While there is obviously no need for a byte order signature when using
UTF-8, there are occasions when processes convert UTF-16 or UTF-32 data
containing a byte order mark into UTF-8. When represented in UTF-8, the
byte order mark turns into the byte sequence. Its usage at the beginning
of a UTF-8 data stream is neither required nor recommended by the
Unicode Standard, but its presence does not affect conformance to the
UTF-8 encoding scheme. Identification of the byte sequence at the
beginning of a data stream can, however, be taken as a near-certain
indication that the data stream is using the UTF-8 encoding scheme.
http://www.unicode.org/versions/Unicode6.0.0/ch03.pdf


先是,BOM是甚。这个就不解释了,Wikipedia上深详细。http://en.wikipedia.org/wiki/Byte\_order\_mark。
每当网页上行使BOM是只谬误。BOM设计出不是用来支持HTML和XML的。要辨识文本编码,HTML有charset属性,XML有encoding属性,没必要拉BOM撑场面。虽然理论及BOM可以为此来识别UTF-16编码的HTML页面,但实际工程达标挺少有人这样干。毕竟UTF-16这种编码连ASCII都双字节,实在不适用于做网页。

事实上说BOM是单可怜习惯吗非尽然。BOM也是Unicode标准的同样有的,有其一定的适用范围。寻常BOM是故来标示Unicode纯文本字节流的,用来提供相同种便民之法吃文本处理程序识别读入的.txt文件是谁Unicode编码(UTF-8,UTF-16BE,UTF-16LE)。Windows相对对BOM处理比较好,是因Windows把Unicode识别代码集成进了API里,主要是CreateFile()。打开文本文件时它见面自动识别并删除BOM。Windows用是起历史原因,因为其最初脱胎于多替码页的条件(ANSI环境)。而引入Unicode时Windows的设计者又想能于用户不理会的景况下又兼容Unicode和非Unicode(Multiple
byte)文本文件,就只好借助这种小trick了。
对照,Linux这样的系于多locale的环境面临感染的时日较短,再增长社区自身吗闹足够的动力轻装前进(吐槽:微软对兼容性的求确实是暨了要命固执的地步,任何一样点破坏兼容性的做法都非容许,以至于许多时候是和谐绑住自己的双手),所以干脆一步到位进入UTF-8。当然中间其实有平等截过渡期,比如从早期备UTF-8的GTK+2.0发表到差不多有GTK开发者都丢用几近locale的GTK+1.2,我印象中至少经历了三暨四年。

BOM不深受欢迎主要是在UNIX环境下,因为多UNIX程序不鸟BOM。主要问题发出在UNIX那个有脚本语言通行的首行#!标示,这东西依赖让shell解析,而过多shell出于兼容的考虑无检测BOM,所以多BOM时shell会把它说明吗某个普通字符输入导致破坏#!标示,这虽烦了。其实过多现代脚本语言,比如Python,其解释器本身都是力所能及处理BOM的,但是shell卡在此地,没道,只能睡着啊中枪。说起来就为无可知生shell,因为BOM本身违反了一个UNIX设计的大规模原则,就是文档中在的多寡必须可见。BOM不可知当可见字符被文本编辑器编辑,就顿时无异条多UNIX开发者就不称心。

顺便说一样句,即使脚本语言能处理BOM,随处使用BOM也不是推荐的点子。各个脚本语言对Unicode的拍卖还产生谈得来之平等法,Python的
# -*- coding: utf-8 -*-,Perl的use
utf8,都比BOM简单而可靠。另一个吓信息是,即使是须以Windows和UNIX之间切换的冤家吗无会见悲催。幸亏在UNIX环境下我们还有VIM这种神器,即使撞BOM挡道,我们呢得通过
set nobomb; set fileencoding=utf8; w 三条命令解决问题。

最终回头想,似乎为确即惟有Windows坚持用BOM了。

P.S.:本问题是友善之第150单应答。突然发现自己回答得深少好少⋯⋯
P.S.
2:突然想起要解释一下为什么说VIM去除bomb的操作需要以UNIX下做到。因为VIM在Windows环境下发生一个意外之bug,总是将UTF-16文件识别成二进制文件,而UNIX(Linux或者Mac都得)下VIM则任问题。这个题目由VIM
6.8直就我及VIM
7.3。目前还不清楚就是VIM的bug还是我好挺.vimrc文件的bug。如发生高手解答不胜感激。


起bom格式在开会多起3个字节 EF BB BF
,主要用于识别编码。bom应该是windows特有的,在打造网页时会有各种奇怪的题材,例如多输出了一个空行,影响PHP的session或者cookies功能(出现
header already
sent错误),甚至可能勾页面的乱码(那3独字节影响了浏览器对页面编码的处理),因此老是推荐下无bom编码。为了处理者题目本身居然形容了一个批量处理的PHP脚本。


邸强,软件开发ing
张旭东、Mingyue Zhou、sapjax 赞同
几乎圆前还在为BOM的问题堵着。。。
巧使@梁海所说,“不带有 BOM 的 UTF-8
才是专业形式”,的确是如此,无BOM使用得重新多来,所以个人还是推动引进一般情形下用无BOM的款式吧,除非有问题之时段,再考虑更换来BOM的。Windows系统保存的都是出BOM的,所以若可见到,用记事本保存一个UTF-8的txt,其实是发生BOM的,这一点待小心。另外不同之文本编辑器对于生无BOM的名叫吗略有不同,比如EditPlus,有BOM的称为UTF-8+,无BOM的称为UTF-8,而在Notepad++中,有BOM的让号称标准UTF-8,而无BOM则为称呼UTF-8无BOM。


武龙飞,c/c++ 程序员,喜欢天文学,数学及心理学。
Weijing Huang、Bill Chan、icky R 赞同

以下文字产生我的博客内容,从旁一头说不相同的bom。

字符编码相信是每个程序员的梦魇,只要是产生中文的地方,总是会赶上各种编码的问题,并且这种题材还充分难缠,尤其当linux上,因为地方很多软件还是对英语国家支付之,是休会见考虑其他语种编码问题。在碰到编码的多多大坑之后,我控制仔细研究下编码问题,因为就就是如一道坎一直横在公面前,每次到此你都见面骤降至,每次爬起来以后,你都要任由其事,这样的食指受叫作战士,真正的老将。可惜是个力量战士,做吧新时代之灵性战士,当然不能够当那么跌至接下来以以就前赴后继下滑至。
文件的囤积方:
文件还出协调之贮存格式,比如最常见的txt,cpp,h,c,xml ,png,
rmvb各种格式,还有从定义格式。这些文件管是呀格式,都是储存于电脑硬盘里的2上制格存储,对诺不同文件格式,有不同之软件解析。这首文章不出口文件是怎么存储的,只讲文件是怎么样分析的。
文本文件分析:
文本文件对应于人类可以翻阅的文件,如何由2进制转换为文本文件呢?起初由计算机于美国表明,自然大家考虑的是英语怎么表示,英语字母总共26单,加上特殊字符,128只字符,7位既一个byte即可表示出。这个就是大家所熟知的ascill编码。对许提到很简短,一个字符对应一一个byte。
然高速发现,其他非英语国家之契远远超过ascill码,这时候大家自然想统一一下,不同国度发生了上下一心不同的编码方式,中国之gb2312就是和谐做出来的编码方式,这样下去每个国家都来和好之编码方式,来回换太累了。这时候出现了初的编码方式,unicode编码方式,想拿编码统一,所以规定了每个字符对应之unicode码。
1、很多文件都是ascii编码,如果用unicode 太浪费。
2、没有标志位说明该几单字节来分析为一个记。
这会儿拯救世界的utf出现了,utf是unicode的同样栽实现,只不过更明白了。utf16凡是占有两字节,或者四字节,utf32凡占据四字节。utf8凡可怜聪明的一致栽表示方法。
1、对于只有字节符号,字节第一员也0,后面7员代表字节编码。
2、对于n字节记,第一字节的眼前n位都设为1,第n+1位为0,其余各各编码位置。
对于不同之编码,在文书的极前方有例外的表明,unicode
通常有少数各来表示分别是ff fe, 或者feff, fffe表示big-endian
编码feff表示litte-endian编码。utf8凡efbbbf来开的。可以关押出来utf-8凡是起说的,所以不用带这个标志文件,大多数主次是足以分辨的。但有点程序不能够识别是标志,比如php就会见一直拿此标志当文本分析,不会见忽略。相信广大相遇php输出文本分析乱码或者解析错误的同校都遇到这么的题材。
末了说说哪些去丢或者加上bom,如果起vim那最好不了了,去丢命令:
set encoding=utf-8
set nobomb
补偿加命令:
set encoding=utf-8

set bomb

带来 BOM 的 UTF-8 就是赤裸裸的刺头!!!!!!!!!

windows总是从开聪明的开片旁人无法知晓的事务!!!UTF-8凡是勿需要BOM头的~~~!!

打刚刚开头攻读代码(实在不克如自己开的东西吗序)到如今,不清楚被这个BOM头搞了有些次,特别是对此自这种完全自学的口,知道找一个BUG需要多久多久不????

拉动非带来BOM头区别就是在于这个BOM头,祥见排名靠前之不得了神答案。windows特有的奇葩。请动UTF-8
不牵动BOM头!!

它们发的BUG包含但不光限于:
锘 — 感谢 @飞扬 提供,参考其答案
HTML空白行
div之间莫明的区间
乱码!
而你用ssl那么一定会生出问题!!!

顺手再轻敌一下 SONY的记忆棒、IPHONE的接口~~

这种吐槽的事物就是给她折叠吧

带来 BOM 的 UTF-8 非常操蛋,经常造成莫名其妙的题材。

自己还是故底UTF-8 without BOM,带BOM的经常出现乱码

notepad++会自动抬高为拉动Bom的utf8比较坑爹

建议编程人员能采用 Mac

编程的尽心以Mac,Window是连同操蛋的操作系统。其次,如果我们若读取三正的文本并为UTF-8格式解析的下一定要留心去看清这文件是否出BOM,例如:sql文件之辨析执行。

网页编程中因故不用bom我虽不说啊了,因为软件由无法使用的即又非克为此了。

近日于念书用cocos2d-x,纯C++的编码,如果代码中有中文等之非ascii字符出现。发现会错。代码是在mac
下用xcode 写的,放到windows 下用vs 编译。
最终把富有的源文件转成了带动bom的格式后编译通过了,链接失败,这想以此就未是编码的题材了。

一般性状态下,一般都
会认为在描写C++代码的当儿绝不因此中文,但是多时刻咱们程序员也起想协调拘留正在舒心的上,为神马就未可知写中文了?

乃以windows 下写了一个helloworld.cpp
类型的文件,输出内容用中文,然后存为utf-8 带bom格式,再管其copy到mac
下用g++ 编译,发现成功通过并且只是正常运行,用xcode打开源文件也健康显示。

就此,这里建议程序要在windows 和 mac 还产生linux
上运行吧,源代码最好保存成utf-8
带bom的格式,这样于通用一些。而因此utf-16 无论大端还是小端,g++
都无认的。
或者用utf-8
不带bom格式,然后代码不要出现非ascii 127自此的字符。

关于说utf-8 不带bom
才是业内的,我眷恋应该是带用个人心情的说法吧。真正的标准应当是bom是可选的,为什么而选取?因为有些时候不牵动bom会错,就将历史比较长期的windows来发话吧,很多国家之用户都于于是windows
,其文件还是用该地面的ansi
编码来做的,比如大陆的GBK和GB2013,港大之big5,这些编码为对当地所用底字符制定的,所以呢,其储存文件较小,所以会见大方用,并且也豁达留存正在,微软无容许不考虑全球几十亿之用户之公文要盲目地修改解码方式,并且微软呢是uncode
制定者之一,所以,带用bom的utf-8也是符合国际标准的。

或许是为程序编写者的民用原因,也许是考虑到效率,很多的次第无法正确区分一个utf-8文件是否出bom,所以造成了各种乱码的产出。

村办不思说谁是规范,也无思量用语言去攻击哪个企业要组织。微软在坚持使用bom上无错,因为就是当也用户着想的。也许让我们这些写序的牵动了困难,但是,计算机最普遍的用户不是程序员。

摘自:
http://www.zhihu.com/question/20167122

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图
Copyright @ 2010-2019 亚洲必赢手机官网 版权所有