3.3. Notepad++的多种编码支持
3.3. Notepad++的多种编码支持
关于字符编码的知识
关于字符编码方面的知识，如果不是很了解的话，建议先去看看
以及相关的中文字符编码：
在对什么字符编码，以及常见的一些字符编码，比如，，，等，有个最基本的了解之后，我们再来看看Notepad++在字符编码方面，有哪些功能：
3.3.1. 用Notepad++查看当前文件编码
对于想要知道当前文件所用的字符编码类型，可以如下操作：
选择 格式(M)，然后就可以看到当前字符编码类型了：
可以看到，当前xml文件所用字符编码类型为"以 UTF-8 无 BOM 格式编码"。
关于UTF-8的BOM，不了解的可参考
需要提及的一些是，一般我们中文和英文，最常用的几个字符编码，大概有：
最通用的UTF-8，包含了（全世界几乎）所有的字符
双字节的Unicode/UTF-16/UCS-2 LE(Little Endian)
简体中文：GB18030 & GBK & GB2312
繁体中文：Big5
对应的编码，截图如下：
3.3.2. 用Notepad++选用合适的编码打开对应的文件
当你打开某个文件时，可能会遇到一些乱码。
此时，如果知道当前文本本身是用的是何种编码，则可在Notepad++中选择对应编码打开，就可以正确显示文件内容了。
例 3.1. 在Notepad++中使用ISO-8859-1编码打开VirtualBox的Manual的HTML源码
比如，在打开官网中的的HTML源码的时候，默认是用ANSI编码打开的，所以会有乱码：
对于如何用Notepad++打开该HTML并高亮显示，可参考
此时，注意到该HTML源码已经通过charset=ISO-8859-1标明了使用的编码是ISO-8859-1了，所以，此时可以去改为对应的ISO-8859-1编码：
就可以看到对应的乱码的字符，都可以正常显示了：
由此，就可以实现了，在Notepad++中，使用正确的编码打开相应的文件，解决了乱码显示问题。
通过html中的charset推测编码
此处由于HTML的特殊性，正常情况下，都会在头部加上charset=xxx来指明当前HTML所用编码
所以此处可以利用此信息去以正确编码显示出内容，而避免了乱码。
对于其他类型文件，在不知道文件编码的情况下，就只能自己手动多试试不同编码了。
最常见的几种，其实也就是那几种，比如UTF-8,ANSI(此处为GBK),GB2312之类的。
3.3.3. 如果乱码则切换到所推测的正确的编码直至消除乱码
如上所述，当HTML源码时，可以通过charset去得知文件编码。
但是，很多时候，我们去打开一个文件时，
可能会遇到乱码，但是由于未必立刻就已知其文件编码是什么
所以，只能去猜测其编码是什么，然后再切换到对应的编码类型，去查看内容是否可以正常显示。
例 3.2. 出现乱码，猜测出是西欧编码，切换到ISO 8859-1而消除乱码
比如遇到一个例子：
打开文件时，出现是乱码：
看起来，就像是西欧类的字符，所以，去切换到对应的ISO 8859-1编码：
然后真的就消除了乱码，可以正常显示出对应的一些特殊的西欧字符了：
此处，很明显，由于对于编码稍微熟悉，所以一次就猜对了编码，而使得快速消除了乱码。
如果，你对于编码不是很熟悉，则可以多去尝试不同的编码，
最后，肯定也还是可以切换到正确的编码，可以正常显示字符的。
而随着对于字符编码的了解越来越深入，则自然会越加熟悉的，越容易一次或几次就猜对文件的正确的编码的。
3.3.4. 用Notepad++实现不同字符编码之间的转换
很多时候，我们需要在不同字符编码之间，进行相互转换。
或者由于某些需要，要建立对应的编码的文件。
比如，写Python代码的时候，常需要文件本身的编码就是UTF-8的，
此时，就可以用Notepad++的字符编码转换方面的功能了。
比如，此处将本地一个UTF-8的xml文件：
其中，中文字符所对应的16进制的如下：
然后点击“转为 ANSI 编码格式”：
即可转为ANSI编码了，此时文件已被修改，所以先保存一下该文件，然后再查看编码，就变为ANSI编码了：
此时再去查看对应的中文字符所对应的16进制的值，就变了：
而此处的ANSI编码，可以简单的理解为“本地”编码，而此处是本地编码是中文的GBK，所以此处ANSI即为GBK中文编码。
相应地，可以根据自己需要，在多个不同的字符编码之间互相转换。
3.3.5. 设置Notepad++新建文件（默认）的编码类型
当我们在Notepad++中新建一个文件时，可以通过看到新建的文件所使用的字符编码：
此处为UTF-8。
而想要改变新建文件的默认所用字符编码，可以通过：
设置(T) => 首选项...
新建，中的“编码”：
然后设置为自己所需要的编码格式。
Notepad++的bug：有时候执行编码转换会导致内容丢失
我遇到过好多次了，在执行代码转换的时候，结果是当前Notepad++打开页面变成空白了，即内容瞬间丢失了，按Ctrl+Z，也无法撤销此操作。
如果不是有备份文件的话，则就会导致文件内容丢失。
如果是很重要的文件的话，文件内容丢失，损失还是很严重的。
尽管Notepad++此编码转换导致文件内容丢失的bug，出现的概率很小，但是也还是建议，对于重要文件的编码转换，转换之前，先备份一下。常见编码总结：Unicode、UTF、ISO 8859-1等 | 小谢的小站
TearSnow Fan
我一句话都不说……
您当前位置 :
>> 常见编码总结：Unicode、UTF、ISO 8859-1等
常见编码总结：Unicode、UTF、ISO 8859-1等
我们最初学习计算机的时候，都学过ASCII编码。但是为了表示各种各样的语言，在计算机技术的发展过程中，逐渐出现了很多不同标准的编码格式，重要的有Unicode、UTF、ISO 8859-1和中国人经常使用的GB2312、BIG5、GBK等。
1. ISO 8859-1
最早的编码就是ISO 8859-1，属于单字节编码，应用于英文系列。最多能表示的字符范围是0-255（编码范围是0x00-0xFF），其中0x00-0x7F之间完全和ASCII一致（ASCII是7位编码，能个表示128个字符），因此向下兼容ASCII。除ASCII收录的字符外，ISO-8859-1收录的字符还包括西欧语言、希腊语、泰语、阿拉伯语、希伯来语对应的文字符号。欧元符号等出现的比较晚，没有被收录在ISO 8859-1当中。
很明显，ISO 8859-1编码表示的字符范围很窄，例如无法表示中文字符。但是由于ISO-8859-1编码范围使用了单字节内的所有空间，在支持ISO 8859-1的系统中传输和存储其他任何编码的字节流都不会被抛弃。换言之，把其他任何编码的字节流当作ISO-8859-1编码看待都没有问题。这是个很重要的特性，所以很多情况下（如很多协议传输数据时）都使用ISO 8859-1编码。我们可以这么说，ASCII编码是一个7位的容器，ISO 8859-1编码是一个8位的容器。
比如，虽然“中文”两个字符就不存在ISO 8859-1编码，但可以用iso8859-1编码来“表示”。通过查询下文将要介绍的GB2312编码表，“中文”应该是"d6d0 cec4"两个字符，使用ISO 8859-1编码来“表示”的时候则将它拆开为4个字节来表示，即"d6 d0
ce c4"（事实上，在进行存储的时候，也是以字节为单位处理的）。如果使用Unicode编码，则表示为"4e2d 6587"；使用UTF编码，则是6个字节"e4 b8 ad
e6 96 87"。很明显，这种使用ISO 8869-1对汉字进行表示的方法还需要以另一种编码为基础。
有些环境下，将ISO 8859-1写作Latin-1。
2. GB2312/BIG5/GBK
GB2312是汉子的国标码，由中华人民共和国政府制定的，简体汉字编码规范。其表示汉字时是双字节编码，而英文字母和ISO 8859-1一致（兼容ISO 8859-1单字节编码，因此是变长编码系统）。与此对应的还有BIG5，是中华民国政府制定的，繁体汉字的编码规范，一般用于海外计算机的繁体中文显示。所谓的繁体中文Windows，简体中文Windows，指的就是采用BIG5和GB2312编码格式的操作系统。这两种编码方式不兼容，如果使用一种编码的文本阅读器来读另一种编码的文本，就会出现乱码。比如在简体中文Windows上读BIG5编码的文件，就是乱码，反之亦然。使用简体浏览器浏览的时候，到了繁体中文网站，如果不改变码制，也是乱码。
GBK，又称GBK大字符集，简而言之就是将所有亚洲文字的双字节字符，包括简体中文，繁体中文，日语，韩语等，都使用一种格式编码，这样就能够做到在所有的语言平台上面兼容。而且，目前GB2312，BIG5所包含的汉字数量也不足，比如朱总理的名字中间那个字一般就打不出。而GBK大字符集包含的汉字数量比GB2312和BIG5多的多了，足够使用。简而言之，GBK编码能够用来同时表示繁体字和简体字，而GB2312只能表示简体字，因此GBK又是兼容GB2312编码的。
3. Unicode
Unicode是Unicode.org制定的编码标准，目前得到了绝大部分操作系统和编程语言的支持。Unicode.org官方对Unicode的定义是：Unicode provides a unique number for every character。可见，Unicode所做的是为每个字符定义了一个相应的数字表示。比如，"a"的Unicode值是0x0061,“一”的Unicde值是0x4E00，这是最简单的情况，每个字符用2个字节表示。
Unicode是最统一的编码，可以用来表示所有语言的字符，而且是定长双字节（如果考虑辅助平面，也有四字节的）编码，包括英文字母在内，都以双字节表示，所以它是不兼容ISO 8859-1编码的。不过，相对于ISO 8859-1中所编码的字符来说，Unicode编码只是在前面增加了一个全0字节，例如字母a的Unicode编码为"00 61"。和GB2312/GBK等非定长编码相比，定长编码便于计算机处理，而Unicode又可以用来表示所有字符，所以在很多软件内部是使用Unicode编码来处理的，比如java。
Unicode的编码空间从U+0000到U+10FFFF，共有1,112,064个码位（code point）可用来映射字符. Unicode的编码空间可以划分为17个平面（plane），每个平面包含216（65,536）个码位。17个平面的码位可表示为从U+xx0000到U+xxFFFF， 其中xx表示十六进制值从00(16) 到10(16)，共计17个平面。第一个平面称为基本多语言平面（Basic Multilingual Plane, BMP），或称第零平面（Plane 0），码位从U+0000至U+FFFF，包含了最常用的字符。其他平面称为辅助平面(Supplementary Planes)。
对于在Unicode基本多文种平面定义的字符（无论是拉丁字母、汉字或其他文字或符号），一律使用2字节储存，但是从U+D800到U+DFFF之间的码位区段是永久保留不映射到任何Unicode字符的。而在辅助平面定义的字符，即从U+10000到U+10FFFF的码位，则（UTF-16的做法是）以代理对（surrogate pair）的形式，将其拆分成两个2字节（位于0xD800-0xDFFF区段）共4字节的值来储存。进行代理对映射的方法本文就不深入讨论了，有兴趣的可以自行搜索。
考虑到Unicode编码不兼容ISO 8859-1编码，而且容易占用更多的空间：因为对于英文字母，Unicode也需要两个字节来表示，所以Unicode不便于传输和存储。因此而产生了UTF编码。
UTF 是 Unicode Translation Format，即把Unicode转做某种格式的意思。事实上可以这么认为，Unicode是一种编码方式，和ACSII是同一个概念，而UTF是一种存储方式（格式）。
那么，UTF是如何做这种格式转换的呢？
Unicode.org定义了百万个以上的字符，如果将所有的字符用统一的格式表示，需要的是4个字节。"a"的Unicode表示就会变成0x，而“一”的Unicode值是0x00004E00。实际上，这就是UTF-32，也是Linux操作系统上所使用的Unicode方案，也是一种定长编码。其缺点很显然是造成了空间的巨大浪费，从而非常没有效率，因此没有UTF-8和UTF-16使用的频繁。
但是，上文已经提到，Unicode基本多语言平面的字符只使用2个字节就可以表示了，真正需要扩展到4个字节来表示的字符少之又少。所以使用2个字节来表示Unicode代码是一种很自然的选择，例如英文的Unicode范围是0xF，中文的Unicode范围是0x4E00-0x9F**。对于那些扩展平面中需要4个字节才能表示的字符，UTF-16使用一种代理的手法来扩展（使用了基本多语言平面保留的0xD800-0xDFFF区段，表示这是一个代理，从而用2个16位码元组成一个字符）。这样的好处是大量的节约了存取空间，也提高了处理的速度。这种Unicode表示方法就是UTF-16，显然，UTF-16需要1个或者2个16位长的码元来表示，因此这是一个变长表示。一般在Windows平台上，提到Unicode，那就是指UTF-16了。
UTF-16有一个著名的Endian的问题，即UTF16-LE和UTF16-BE，LE指Little Endian，而BE指Big Endian。关于这方面的信息，网上有很多相关的帖子。这与计算机的CPU架构有一定关系，我们一般的X86系统都是Little Endian的，可以认为UTF16就是UTF16-LE。
另外，UTF有一个BOM（Byte Order Mark）的问题。在Unicode编码中有一个叫做"zero-width no-break space (ZWNBSP)"的字符，它的编码是0xFEFF。而0xFEFF在是一个实际中不存在的字符，所以不应该出现在实际传输中。UCSUCS (Unicode Character Set) 规范建议我们在传输字节流前，先传输字符"ZWNBSP"。这样如果接收者收到FEFF，就表明这个字节流是Big-Endian的；如果收到FFFE，就表明这个字节流是Little- Endian的。因此字符"ZWNBSP"又被称作BOM。
UTF16的最大好处在于大部分字符都以固定长度的字节（2字节）储存，但UTF-16却无法兼容于ASCII编码。由于对于欧洲和北美，实际上使用的编码范围在0xFF之间，只需要一个字符就可以表示所有的字符。即使是使用UTF16来作为内存的存取方式，还是会带来巨大的空间浪费，因此就有了UTF8的编码方式。
UTF-8编码是最灵活的UTF编码形式，即兼容ISO 8859-1的编码，同时也可以用来表示所有语言的字符。显然，UTF-8编码是不定长编码，每一个字符的长度从1-6个字节不等。另外，UTF编码自带简单的校验功能。
UTF-8编码中，对于只需要1个字节的字符，就使用一个字节；对于中日韩等Unicode中需要两个字节才能表示的字符，则通过一个 UTF16 – UTF8 的算法实现相互之间的转换（转换后的UTF-8一般需要3个字节），而对于Unicode中需要4个字节才能表示的字符，UTF-8根据需要可以扩展到6个字节来表示一个字符。UTF8使用的算法很有意思，大致映射关系如下：
0x - 0x0000007F
0x - 0x000007FF
110xxxxx 10xxxxxx
0x - 0x0000FFFF
1110xxxx 10xxxxxx 10xxxxxx
0x - 0x001FFFFF
11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
0x - 0x03FFFFFF
111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
0x - 0x7FFFFFFF
xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
可以发现这和IP的分址算法很是相像。
由于UTF-8可以方便的转换为UTF16和UTF32（不需要码表，执行一个转换算法即可，在Unicode.org上提供了）。而且UTF-8在每个操作系统平台上的实现都是一样的，也不存在跨平台的问题，所以UTF-8成为跨平台的Unicode很好的解决方案。当然，对于中文来说，由于每个字符需要3个字节才能表示，还是有点浪费的。
注意，虽然说UTF-8是为了使用更少的空间而使用的，但那只是相对于Unicode编码来说，如果已经知道是汉字，则使用GB2312/GBK无疑是最节省的。不过另一方面，值得说明的是，对于中文网页，虽然UTF-8编码对汉字使用3个字节，UTF8编码也会比UTF-16编码节省，因为网页HTML中包含了更多的英文字符。
UTF-8 是不需要BOM来表明字节顺序，但可以用BOM来表明编码方式。字符"ZWNBSP"即“0xFEFF”的UTF-8编码是EF BB BF（根据上表转换关系）。所以如果接收者收到以EF BB BF开头的字节流，就知道这是通知其收到的是UTF-8编码了。
Windows系统就是用BOM来标记文本文件的编码方式的。用UltraEdit的16进制编辑模式查看UTF-8编码的文件，都是EF BB BF开头的，说明都是带BOM的。参照下面的GB2312/GBK的编码，可以解释为什么在出现编码问题时，经常看到这三个汉字“锘匡豢”：
参考资料：
[1] TechGuru:
本文固定链接:
【上一篇】【下一篇】
您可能还会对这些文章感兴趣！
最新日志热评日志随机日志
官方微信扫一扫
日志总数：151 篇
评论总数：289 篇
分类总数：9 个
标签数量：251 个
链接总数：10 个
建站日期：
运行天数：1511 天
最后更新：
如果您觉得本站的内容对您有帮助，非要感谢一下不可，那么请给小谢捐赠。【ios】怎的将字符编码弄成iso-8859-1 - Iphone当前位置:& &&&【ios】怎的将字符编码弄成iso-8859-1【ios】怎的将字符编码弄成iso-8859-1&&网友分享于：&&浏览：299次【ios】怎样将字符编码弄成iso-8859-1公司服务器接受的数据是以ios-8859-1格式编码
在iphone中好像没有这种格式&应该怎么办才能转换为ios-8859-1编码
求大侠帮忙！------最佳解决方案--------------------有这种编码格式的：
kCFStringEncodingISOLatin1&=&0x0201,&/*&ISO&8859-1&*/
然后配合CFStringConvertEncodingToNSStringEncoding转换下编码即可。
楼主可参考：
/cxsjabc/iphone-common-codes-ccteam
中CCEncoding.m中的实现。------其他解决方案--------------------用NSISOLatin1StringEncoding&试试------其他解决方案--------------------IOS&貌似没有这种编码。。。&你需要自己去解析编码格式了------其他解决方案--------------------引用:IOS&貌似没有这种编码。。。&你需要自己去解析编码格式了那怎么解决呀&&&高手帮帮忙呀！------其他解决方案--------------------cxsjabcabc&谢谢你&&非常感谢你！贴了几个星期的帖，终于搞定了&！（
晒晒代码：
+&(const&char&*)UnicodeToISO88591:(NSString&*)src
NSStringEncoding&enc&=&&&&&&CFStringConvertEncodingToNSStringEncoding(kCFStringEncodingISOLatin1);
return&[src&cStringUsingEncoding:enc];&
12345678910
12345678910
12345678910 上一篇：下一篇：文章评论相关解决方案 12345678910 Copyright & &&版权所有找好工作，快人一步