UTF8最棒永不带BOM天文学

By admin in 天文学 on 2019年3月20日

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.:本难题是和谐的第一五拾五个应答。突然发现自身回答得很少很少⋯⋯
P.S.
2:突然想起要求解释一下为啥说VIM去除bomb的操作需求在UNIX下形成。因为VIM在Windows环境下有3个竟然的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错误),甚至可能引起页面包车型大巴乱码(那二个字节影响了浏览器对页面编码的拍卖),因而老是推荐使用无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上,因为上面很多软件都以针对性土耳其共和国(The Republic of Turkey)语国家开发的,是不会设想别的语种编码难点。在际遇编码的成千成万大坑之后,作者控制仔细斟酌下编码难点,因为那就如一道坎平素横在您眼下,每趟到那里你都会跌到,每一趟爬起来之后,你都若无其事,那样的人被称应战士,真正的主力。可惜是个力量战士,做为新时期的灵性战士,当然无法在那跌到接下来又在这勇往直前跌到。
文件的储存方式:
文件都有温馨的存款和储蓄格式,比如最广泛的txt,cpp,h,c,xml ,png,
rmvb各类格式,还有自定义格式。这么些文件不论是怎样格式,都以储存在微型总计机硬盘里的2进制格存款和储蓄,对应差别文件格式,有例外的软件解析。那篇作品不谈文件是什么样存款和储蓄的,只谈文件是如何剖析的。
文件文件分析:
天文学,文件文件对应于人类可以翻阅的文书,如何从2进制转换为文本文件呢?早先是因为电脑在United States表明,自然我们考虑的是丹麦语怎么表示,希伯来语字母总共2五个,加上特殊字符,135个字符,陆人既三个byte即可表示出来。那些正是大家所纯熟的ascill编码。对应涉及一点也不细略,五个字符对应一一个byte。
但快速发现,别的非土耳其语国家的文字远远当先ascill码,那时候我们自然想统一一下,差异国家出了协调分裂的编码格局,中中原人民共和国的gb2312就是友好做出来的编码格局,那样下去每一个国家都有投机的编码格局,来回转换太难为了。那时候出现了新的编码方式,unicode编码格局,想将编码统一,所以规定了每种字符对应的unicode码。
壹 、很多文书都以ascii编码,如果用unicode 太浪费。
贰 、没有标志位表明该多少个字节来分析为一个标志。
那时候拯救世界的utf出现了,utf是unicode的一种达成,只不过更智慧了。utf16是占有两字节,只怕四字节,utf32是占有四字节。utf8是很聪明的一种表示方法。
① 、对于单字节符号,字节第4位为0,前边7人代表字节编码。
贰 、对于n字节标记,第1字节的前n位都设为1,第n+一人为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头搞了不怎么次,尤其是对于自身那种完全自学的人,知道找1个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 下写了3个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和GB二零一一,港台的big5,这一个编码因为针对地方所用的字符制定的,所以呢,其储存文件较小,所以会大方施用,并且也大方留存着,微软不容许不考虑举世几十亿的用户的公文而盲目地修改解码方式,并且微软也是uncode
制定者之一,所以,带用bom的utf-8也是符合国际标准的。

唯恐是因为程序编写者的村办原因,大概是考虑到效能,很多的次第不或然正确区分2个utf-8文件是还是不是有bom,所以导致了各样乱码的面世。

个体不想说哪些是标准,也不想用语言去攻击哪个企业或公司。微软在细水长流利用bom上从不错,因为这是在为用户考虑的。恐怕给大家那几个写程序的牵动了劳苦,可是,总括机最广泛的用户不是程序员。

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

发表评论

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

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