记事本⼏种编码格式的解释
格式介绍：
在windows平台下，打开内置的记事本⼩程序打开后，点击【⽂件】→【另存为】，弹出⼀个对话框，在最低部有⼀个"编码"的下拉条。
⾥⾯有个四个编码选型：ANSI,Unicode,Unicode big endian,UTF-8
UTF-8是unicode的实现⽅式之⼀，它规定了字符如何在计算机中存储，传输等。
1）ANSI是默认的编码⽅式。对于英⽂⽂件是ASCII编码，对于简体中⽂⽂件是GB2312编码（只针对Windows简体中⽂版，如果是繁体中⽂版会采⽤Big5码）。
2）Unicode编码指的是UCS-2编码⽅式，即直接⽤两个字节存⼊字符的Unicode码。这个选项⽤的little endian格式。
3）Unicode big endian编码与上⼀个选项相对应。两个字节中，⾼位字节在前。
4）UTF-8编码。
（1）对于单字节的符号，字节的第⼀位设为0，后⾯7位为这个符号的unicode码。因此对于英语字母，UTF-8编码和ASCII码是相同的。
（2）对于n字节的符号（n>1），第⼀个字节的前n位都设为1，第n+1位设为0，后⾯字节的前两位⼀律设为10。剩下的没有提及的⼆进制位，全部为这个符号的unicode码。
详解
Windows早期是ANSI字符集，也就是说⼀个中⽂⽂本，在windows简体中⽂版显⽰的是中⽂，到Windows⽇⽂版显⽰的就不知道是什么东西了。
后来，Windows⽀持Unicode，但当时⼤部分软件依然使⽤ANSI编码，Unicode还不流⾏，如何推⼴和⽀持Unicode？，windows想了个办法，就是允许⼀个默认语⾔编码，就是当遇到⼀个字符串，不是Unicode的时候，就⽤默认语⾔编码解释，（在区域和语⾔选项⾥修改默认语⾔）。这个默认语⾔，在不同Windows语⾔版本⾥是不同的，在简体中⽂版⾥，是GBK，在繁体中⽂版本⾥⾯，是BIG5，在⽇⽂版⾥是JIS。
⽽记事本的ANSI编码，就是这种默认编码，所以，⼀个中⽂⽂本，⽤ANSI编码保存，在中⽂版⾥编码是GBK模式保存的时候，到繁体中⽂版⾥，⽤BIG5读取，就全乱套了。
记事本为了解决这个问题，所以⽀持Unicode，但有⼀个问题，⼀段⼆进制编码，如何确定它是GBK，还是Big5、UTF-8、UTF-16等，记事本的做法是在.txt⽂本的最前⾯保存⼀个标签，这个标签叫"BOM"，在读取这个⽂本时，如果是0xEF 0xBB 0xBF则是UTF-8，如果是0xFF
0xFE，则是UTF-16LE，如果是0xFE 0xFF则UTF-16BE。如果没有这三个东西，那么就是ANSI，使⽤操作系统的默认语⾔设置来解析。
⼀句话建议：涉及兼容性考量时，不要⽤记事本，⽤专业的⽂本编辑器保存为不带 BOM 的 UTF-8。
如果是为了跨平台兼容性，只需要知道，在 Windows 记事本的语境中：
·所谓的「ANSI」指的是对应当前系统 locale 的遗留（legacy）编码。[1]
·所谓的「Unicode」指的是带有 BOM 的⼩端序 UTF-16。[2]
·所谓的「UTF-8」指的是带 BOM 的 UTF-8。[3]
unicode码和ascii码区别
GBK 等遗留编码最⿇烦，所以除⾮你知道⾃⼰在⼲什么否则不要再⽤了。
UTF-16 理论上其实很好，字节序也标明了，但 UTF-16 毕竟不常⽤。
UTF-8 本来是兼容性最好的编码但 Windows 偏要加 BOM 于是经常出问题。
所以，跨平台兼容性最好的其实就是不⽤记事本。
建议⽤ Notepad++ 等正常的专业⽂本编辑器保存为不带 BOM 的 UTF-8。
另外，如果⽂本中所有字符都在 ASCII 范围内，那么其实，记事本保存的所谓的「ANSI」⽂件，和 ASCII 或⽆ BOM 的 UTF-8是⼀样的。阮⼀峰那篇〈字符编码笔记：ASCII，Unicode和UTF-8〉的确很有名，但从那篇⽂章能看出来他其实还是没完全搞清楚 Unicode和 UTF-
8 的关系。他依旧被 Windows 的混乱措词误导。事实上，⼏年前我读完他那篇⽂章之后依旧⼀头雾⽔，最终还是⾃⼰看看明⽩的。
BOM 介绍
（字节顺序标记(ByteOrderMark)）
BOM（Byte Order Mark），字节顺序标记，出现在⽂本⽂件头部，Unicode编码标准中⽤于标识⽂件是采⽤哪种格式的编码。
中⽂名
BOM
外⽂名
ByteOrderMark
实质
字节顺序标记
BOM —— Byte Order Mark，中⽂名译作"标记"。在这⾥到⼀段关于 BOM 的说明：
在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。
不需要 BOM 来表明，但可以⽤ BOM 来表明编码⽅式。字符 "Zero Width No-Break Space" 的 UTF-8 编码是 EF BB BF。所以如果接收者收到以 EF BB BF 开头的，就知道这是 UTF-8编码了。Windows 就是使⽤ BOM 来标记⽂本⽂件的编码⽅式的。
字符U+FEFF如果出现在字节流的开头，则⽤来标识该字节流的，是⾼位在前还是低位在前。如果它出现在字节流的中间，则表达零宽度⾮换⾏空格的意义，⽤户看起来就是⼀个空格。从Unicode3.2开始，U+FEFF只能出现在字节流的开头，只能⽤于标识字节序，就如它的名称——字节序标记——所表⽰的⼀样；除此以外的⽤法已被舍弃。取⽽代之的是，使⽤U+2060来表达零宽度⽆断空⽩。
类似WINDOWS⾃带的记事本等软件，在保存⼀个以编码的⽂件时，会在⽂件开始的地⽅插⼊三个不可见的字符（0xEF 0xBB 0xBF，即BOM）。它是⼀串隐藏的字符，⽤于让记事本等编辑器识别这个⽂件是否以UTF-8编码。对于⼀般的⽂件，这样并不会产⽣什么⿇烦。但对于 PHP来说，BOM是个⼤⿇烦。
并不会忽略BOM，所以在读取、包含或者引⽤这些⽂件时，会把BOM作为该⽂件开头正⽂的⼀部分。根据嵌⼊式语⾔的特点，这串字符将被直接执⾏（显⽰）出来。由此造成即使页⾯的 top padding 设置为0，也⽆法让整个⽹页紧贴浏览器顶部，因为在html⼀开头有这3个字符呢！
编码表⽰ (表⽰ (
EF BB BF239 187 191
（⼤端序）FE FF254 255
（⼩端序）FF FE255 254
（⼤端序）00 00 FE FF0 0 254 255
（⼩端序）FF FE 00 00255 254 0 0
2B 2F 76和以下的⼀个字节：[ 38 | 39 | 2B | 2F ]43 47 118和以下的⼀个字节：[ 56 | 57 | 43 | 47 ]
en:UTF-1F7 64 4C247 100 76
en:UTF-EBCDIC DD 73 66 73221 115 102 115
en:Standard Compression
Scheme for Unicode
0E FE FF14 254 255
en:BOCU-1FB EE 28及可能跟随着FF251 238 40及可能跟随着255 GB-1803084 31 95 33132 49 149 51

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。