Windows 记事本的 ANSI、Unicode、UTF-8 区别+BOM【linux吧】_百度贴吧
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&签到排名：今日本吧第个签到，本吧因你更精彩，明天继续来努力！
本吧签到人数：0成为超级会员，使用一键签到本月漏签0次！成为超级会员，赠送8张补签卡连续签到：天&&累计签到：天超级会员单次开通12个月以上，赠送连续签到卡3张
关注：176,662贴子：
Windows 记事本的 ANSI、Unicode、UTF-8 区别+BOM收藏
梁海，U+6211, U+7231, U+5B83
46 票，来自
Moeraki、王君櫹、winter
简答。一些细节暂无精力查证，如果说错了还请指出。一句话建议：涉及兼容性考量时，不要用记事本，用专业的文本编辑器保存为不带 BOM 的 UTF-8。* * *如果是为了跨平台兼容性，只需要知道，在 Windows 记事本的语境中：所谓的「ANSI」指的是对应当前系统 locale 的遗留（legacy）编码。[1]所谓的「Unicode」指的是 UTF-16LE。[2]所谓的「UTF-8」指的是带 BOM 的 UTF-8。[3]GBK 等遗留编码最麻烦，所以除非你知道自己在干什么否则不要再用了。UTF-16LE 理论上其实很好，字节序也标明了，但 UTF-16 毕竟不常用。UTF-8 本来是兼容性最好的编码但 Windows 偏要加 BOM 于是经常出问题。所以，跨平台兼容性最好的其实就是不用记事本。建议用 Notepad++ 等正常的专业文本编辑器保存为不带 BOM 的 UTF-8。另外，如果文本中所有字符都在 ASCII 范围内，那么其实，记事本保存的所谓的「ANSI」文件，和 ASCII 或无 BOM 的 UTF-8 是一样的。* * *阮
一峰那篇〈字符编码笔记：ASCII，Unicode和UTF-8〉的确很有名，但从那篇文章能看出来他其实还是没完全搞清楚 Unicode 和
UTF-8 的关系。他依旧被 Windows 的混乱措词误导。事实上，几年前我读完他那篇文章之后依旧一头雾水，最终还是自己看维基百科看明白的。所以，那篇文章不值得推荐。* * *关于字符集（character set）和编码（encoding），某几篇答案中似乎有些混淆。对于 ASCII、GB 2312、Big5、GBK、GB 18030 之类的遗留方案来说，基本上一个字符集方案只使用一种编码方案。比
如 ASCII 这部标准本身就直接规定了字符和字符编码的方式，所以既是字符集又是编码方案；而 GB 2312
只是一个区位码形式的字符集标准，不过实际上基本都用 EUC-CN 来编码，所以提及「GB 2312」时也说的是一个字符集和编码连锁的方案；GBK
和 GB 18030 等向后兼容于 GB 2312 的方案也类似。于是，很多人受这些遗留方案的影响而无法理解字符集和编码的关系。对
于 Unicode，字符集和编码是明确区分的。Unicode/UCS 标准首先是个统一的字符集标准。而 Unicode/UCS
标准同时也定义了几种可选的编码方案，在标准文档中称作「encoding form」，主要包括 UTF-8、UTF-16 和 UTF-32。所以，对 Unicode 方案来说，同样的基于 Unicode 字符集的文本可以用多种编码来存储、传输。所以，用「Unicode」来称呼一个编码方案不合适，并且误导。* * *[1] Windows 里说的「ANSI」其实是 Windows code pages，这个模式根据当前 locale 选定具体的编码，比如简中 locale 下是 GBK。把自己这些 code page 称作「ANSI」是 Windows 的臭毛病。在 ASCII 范围内它们应该是和 ASCII 一致的。[2] 把 UTF-16LE 称作「Unicode」也是 Windows 的臭毛病。Windows
从 Windows 2000 开始就已经支持 surrogate pair 了，所以已经是 UTF-16
了，「UCS-2」这个说法已经不合适了。UCS-2 只能编码 BMP 范围内的字符，从 1996 年起就在 Unicode/ISO 标准中被
UTF-16 取代了（UTF-16 通过蛋疼的 surrogate pair 来编码超出 BMP 的字符）。都十多年了，求求大家别再误称了……[3] 把带 BOM 的 UTF-8 称作「UTF-8」又是 Windows 的臭毛病。如果忽略 BOM，那么在 ASCII 范围内与 ASCII 一致。另请参见：「带 BOM 的 UTF-8」和「无 BOM 的 UTF-8」有什么区别？============BOM——Byte Order Mark，就是字节序标记在UCS 编码中有一个叫做"ZERO WIDTH NO-BREAK SPACE"的字符，它的编码是FEFF。而FFFE在UCS中是不存在的字符，所以不应该出现在实际传输中。UCS规范建议我们在传输字节流前，先传输字符"ZERO WIDTH NO-BREAK SPACE"。这样如果接收者收到FEFF，就表明这个字节流是Big-Endian的；如果收到FFFE，就表明这个字节流是Little-Endian的。因此字符"ZERO WIDTH NO-BREAK SPACE"又被称作BOM。UTF-8不需要BOM来表明字节顺序，但可以用BOM来表明编码方式。字符"ZERO WIDTH NO-BREAK SPACE"的UTF-8编码是EF BB BF。所以如果接收者收到以EF BB BF开头的字节流，就知道这是UTF-8编码了。UTF-8编码的文件中，BOM占三个字节。如果用记事本把一个文本文件另存为UTF-8编码方式的话，用UE打开这个文件，切换到十六进制编辑状态就可以看到开头的FFFE了。这是个标识UTF-8编码文件的好办法，软件通过BOM来识别这个文件是否是UTF-8编码，很多软件还要求读入的文件必须带BOM。可是，还是有很多软件不能识别BOM。在Firefox早期的版本里，扩展是不能有BOM的，不过Firefox 1.5以后的版本已经开始支持BOM了。现在又发现，PHP也不支持BOM。PHP在设计时就没有考虑BOM的问题，也就是说他不会忽略UTF-8编码的文件开头BOM的那三个字符。由于必须在在Bo-Blog的wiki看到，同样使用PHP的Bo-Blog也一样受到BOM的困扰。其中有提到另一个麻烦：“受COOKIE送出机制的限制，在这些文件开头已经有BOM的文件中，COOKIE无法送出（因为在COOKIE送出前PHP已经送出了文件头），所以登入和登出功能失效。一切依赖COOKIE、SESSION实现的功能全部无效。”这个应该就是Wordpress后台出现空白页面的原因了，因为任何一个被执行的文件包含了BOM，这三个字符都将被送出，导致依赖cookies和session的功能失效。解决的办法嘛，如果只包含英文字符(或者说ASCII编码内的字符)，就把文件存成ASCII码方式吧。用UE等编辑器的话，点文件-&转换-&UTF-8转ASCII，或者在另存为里选择ASCII编码。如果是DOS格式的行尾符，可以用记事本打开，点另存为，选ASCII编码。如果包含中文字符的话，可以用UE的另存为功能，选择“UTF-8 无 BOM”即可。
linux培训选择达内,资深10年linux讲师悉心传授,linux项目实战+设备实操+名企内推.达内linux云计算培训将网络工程与linux运维相结合专门培养高端linux复合型人才.
UTF8是趋势
万国码万岁
UTF8是用3个字节储存文字，对于文本文件，需要BOM来标示编码，对于网页，统一使用UTF8编码，故无需BOM，当然，部分旧网页依然使用ANSI编码，打开后是乱码，只能手动选择编码了。
英语国家有先天优势啊！
请教一下搂主，我这里有一个软件，字符串是unicode的，和二进制数据储存在文件中，怎么查看文本部份？目前是采用添加FF FE两个字节，然后用文本编辑器查看。不知是否有更好的办法？
请教一下搂主，我这里有一个软件，字符串是unicode的，和二进制数据储存在文件中，怎么查看文本部份？目前是采用添加FF FE两个字节，然后用文本编辑器查看。不知是否有更好的办法？
请教一下搂主，我这里有一个软件，字符串是unicode的，和二进制数据储存在文件中，怎么查看文本部份？目前是采用添加FF FE两个字节，然后用文本编辑器查看。不知是否有更好的办法？
请教一下搂主，我这里有一个软件，字符串是unicode的，和二进制数据储存在文件中，怎么查看文本部份？目前是采用添加FF FE两个字节，然后用文本编辑器查看。不知是否有更好的办法？
请教一下搂主，我这里有一个软件，字符串是unicode的，和二进制数据储存在文件中，怎么查看文本部份？目前是采用添加FF FE两个字节，然后用文本编辑器查看。不知是否有更好的办法？
linux,选万和.全程RHCA讲师亲授,红帽原厂独家技术支持.培训+考试+就业一条龙服务,项目实战+真机实验=高薪就业.
请教一下搂主，我这里有一个软件，字符串是unicode的，和二进制数据储存在文件中，怎么查看文本部份？目前是采用添加FF FE两个字节，然后用文本编辑器查看。不知是否有更好的办法？
手机网络不好，重复了。
在WINDOWS里面，UTF编码的文本文件都带BOM的。
我仔细看了一下，在windows里面记事本可以保存四种格式。ansi，这种格式的文本没有BOM的。然后就是下面的三种格式，UTF-8 UTF-16（大端序）UTF-16（小端序）（即unicode）编码表示 (十六进制)表示 (十进制)UTF-8
239 187 191
UTF-16（大端序）
UTF-16（小端序）
（以下供参考）UTF-32（大端序）
00 00 FE FF
0 0 254 255
UTF-32（小端序）
FF FE 00 00
255 254 0 0
2B 2F 76和以下的一个字节：[ 38 | 39 | 2B | 2F ]
43 47 118和以下的一个字节：[ 56 | 57 | 43 | 47 ]
247 100 76
en:UTF-EBCDIC
DD 73 66 73
221 115 102 115
en:Standard Compression Scheme for Unicode
14 254 255
FB EE 28及可能跟随着FF
251 238 40及可能跟随着255
84 31 95 33
132 49 149 51
建议楼主加上原文链接复制粘贴的排版看起来糟透了。
在 ANSI 版本中，长度指的是字节数，在 Unicode 版本中，长度指的是字符的个数。
登录百度帐号推荐应用Windows 记事本的 ANSI、Unicode、UTF-8 这三种编码模式有什么区别？ - 知乎1120被浏览109883分享邀请回答62 条评论分享收藏感谢收起Windows&的记事本默认存储文本文档编码是&ANSI，想问一下为了最大跨平台兼容性，应该采用哪种编码格式比较好？
ANSI：最早的时候计算机ASCII码只能表示256个符号（含控制符号），这个字符集表示英文字母足够，其中，我们键盘上可见的符号的编码范围是从32到126（大小写英文字母、数字、英文符号等）。但表示汉字、日语、韩语就不太够用了，汉字常用字有3000多个。
但是中国人也要用电脑打字，于是，中国人就研究出来了最早的中文字符集GB2312（GBK就是后来的扩展），GB2312的做法是，把ASC码取值范围的128～255这个区间挪用了一下，用两个ASC码表示一个汉字，这样可用的编码范围用十六进制表示就是0x8080到0xFFFF，这大概能表示一万多个符号，足够了。[注:实际没用那么多，GBK的范围是8140-FEFE]
那个时候，计算机技术还不发达，各个国家搞自己的，比如台湾，也另搞了一套，叫BIG5（俗称：大五码），跟大陆的也不太一样，但方法是类似的，都是用0x80到0xFF这个区间。
然后日语（有编码JIS）、韩语等等也各搞一套。
这些国家的编码区间都是重叠的，但同一个汉字（比如有一些汉字同时存在于简体、繁体、日语汉字中）有不同的编码，很混乱是不是？但也凑合用了。编码不同导致了很多麻烦，比如一个网页，如果你不知道它是什么编码的，那么你可能很难确定它显示的是什么，一个字符可能是大陆简体/台湾繁体/日本汉字，但又完全是不同的几个字。
所以如果用一些很老的软件，可能会听说有中文版/日文版之类的，对应的版本只能在对应的系统上运行。
后来，这个对操作系统的开发实在是太困难了，因为这意味着不同语言的版本，都要重新编码。于是发明了Unicode。
Unicode这个东西，就是要把地球上所有的语言的符号，都用统一的字符集来表示，一个编码真正做到了唯一。
Unicode里有几种方式：
UTF-16BE/LE：UTF-16就是Windows模式的编码模式(Windows里说的Unicode一般都是指这种编码），用2个字节表示任意字符，注意：英文字符也占2个字节（变态不？），这种编码可以表示65536个字符，至于LE和BE，就是一个数值在内存/磁盘上的保存方式，比如一个编码0x8182，在磁盘上应该是0x81
0x82呢？还是0x82 0x81呢？就是高位是最先保存还是最后保存的问题，前者为BE，后者为LE。
UTF-8：UTF-8则是网页比较流行的一种格式：用一个字节表示英文字符，用3个字节表示汉字，准确的说，UTF-8是用二进制编码的前缀，如果某个UTF-8的编码的第一个字节的最高二进制位是0，则这个编码占1字节，如果是110，则占2字节，如果是1110，则占3字节……
好了，说了这么，再来研究Windows的记事本。
Windows早期（至少是95年以前的事情了）是ANSI字符集的，也就是说一个中文文本，在Windows简体中文版显示的是中文，到Windows日文版显示的就不知道是什么东西了。
后来，Windows支持了Unicode，但当时大部分软件都是用ANSI编码的，unicode还不流行，怎么办？Windows想了个办法，就是允许一个默认语言编码，就是当遇到一个字符串，不是unicode的时候，就用默认语言编码解释。（在区域和语言选项里可以改默认语言）
这个默认语言，在不同Windows语言版本里是不同的，在简体中文版里，是GBK，在繁体中文版里，是BIG5，在日文版里是JIS
而记事本的ANSI编码，就是这种默认编码，所以，一个中文文本，用ANSI编码保存，在中文版里编码是GBK模式保存的时候，到繁体中文版里，用BIG5读取，就全乱套了。
记事本也不甘心这样，所以它要支持Unicode，但是有一个问题，一段二进制编码，如何确定它是GBK还是BIG5还是UTF-16/UTF-8？记事本的做法是在TXT文件的最前面保存一个标签，如果记事本打开一个TXT，发现这个标签，就说明是unicode。标签叫BOM，如果是0xFF
0xFE，是UTF16LE，如果是0xFE
0xFF则UTF16BE，如果是0xEF
0xBB 0xBF，则是UTF-8。如果没有这三个东西，那么就是ANSI，使用操作系统的默认语言编码来解释。
Unicode的好处就是，不论你的TXT放到什么语言版本的Windows上，都能正常显示。而ANSI编码则不能。（UTF-8的好处是在网络环境下，比较节约流量，毕竟网络里英文的数据还是最多的）
同样一段中文文本（可以插入一些英文），保存成ANSI/Unicode/UTF-8，三个文件。
修改windows的默认语言为日语之类的（WIN7的改法是：控制面板-时钟、语言和区域-更改显示语言-区域和语言-管理-非unicode程序语言-更改区域设置/WNIXP改法是：控制面板-区域和语言选项-非unicode程序语言）。
修改完要求重启，重启以后，再打开这三个文件，ANSI的编码全乱了，其余两个都正常显示，这就是UNICODE的作用。
另外，为什么记事本、开始菜单什么的还是正确的中文呢？明明我已经改了默认语言了？因为它们的程序编码也是unicode的。
要把txt发给国外的朋友或者用在非中文的操作系统/软件里，那么你的编码最好选择unicode
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：2449次
排名：千里之外
转载：11篇
(7)(2)(1)(1)(1)(3)(2)Windows 记事本的 ANSI、Unicode、UTF-8 这三种编码模式有什么区别？ - 知乎1120被浏览109883分享邀请回答该回答已被折叠 折叠原因：算法识别自动折叠0添加评论分享收藏感谢收起Windows 7 右键新建记事本为UTF-8格式 设置方式 - 空即是色 - ITeye博客
博客分类：
目前状况是，新建记事本(txt)文档时默认的编码格式是ANSI编码的，其缺点是有些中文、特殊符号在保存时会丢失，为了方便大家不用每次存档时都要另存为utf-8或者unicode等编码，特从Microsoft的问答论坛找到一个解决方法（仅限于右键“新建--&文本文档”）：
1. 打开目录（没有则自己新建）
引用C:\WINDOWS\SHELLNEW
2. 在该目录下创建一个文本文档(txt)：
引用右键 -& 新建 -& 文本文档
3. 命名为：
引用UTF8.txt
4. 打开该文档，然后选择：
引用文件 -& 另存为...
5. 选择编码格式为：
引用UTF-8
保存并关闭文件。
6.点击开始菜单：
引用开始 -& 运行... 或者 快捷键 WIN + R
7. 输入：regedit 回车，打开注册表。
8. 按以下路径找到ShellNew项：
引用HKEY_CLASSES_ROOT\.txt\ShellNew
9. 右键右边区域：
引用新建 -& 字符串
10. 命名为：
引用FileName
11. 双击 FileName这项，输入：
引用UTF8.txt
12. 按以下路径找到Notepad项：
引用HKEY_CURRENT_USER\Software\Microsoft\Notepad
13. 更改以下两项值为：1（如果不存在，自行创建：右键 -& 新建 -& DWORD）
引用fSavePageSettings
fSaveWindowPositions
浏览: 103869 次
来自: 广州
myeclipse 8.5 使用maven的时候&dep ...
那你有没有在360浏览器和百度浏览器里测试过呢？
有没有 配置 2.2 的 似乎Myeclipse 没有2.2的 ...