notice
...
2013年4月20日 | 分类: 日志 | 标签:

在cnbeta上看到这样一篇文章 [评论]GB18030 – 想说爱你不容易,看完此文再次见识到CB喷子们的智商。这样一篇没有水准的文章,我觉得有必要再写点东西留给有需要的人,虽然之前已经写过一点相关的东西了。

注:本文名词较多,需要对字符编码有一定了解才可以看明白,本文不是科普文章抱歉。在此推荐一篇比较详细的编码知识讲解文章http://www.luanxiang.org/blog/archives/1271.html。

首先要明确的是:
1.没有所谓的ANSI字符集或者ANSI编码,所谓的ANSI编码正确的叫法是windows代码页(内码表),简体中文的Windows使用936代码页,基本等同于GBK字符集。(作者开头就说“疑惑一:GB18030到底是一种ANSI编码还是Unicode编码?”真是莫名其妙的很,能提出这种问题足见其水准之低)
2.早期的Windows(NT之前)是原生的单字符操作系统,并非原生支持Unicode,东亚版本的Windows系统则使用多字节字符集,具体而言就是双字节字符集(DBCS),原理是使用一个前导字节和尾字节,DBCS是不可能同时支持所有现有的字符集(由UCS-2与UTF-8转换关系很容易看出)所以不同语言地区会使用不同的代码页,如简体中文的Windows使用的是936代码页,繁体中文的使用950代码页。
3.Windows NT则是原生支持Unicode的,使用的是UCS-2编码(UTF-16的子集,在UNICODE辅助平面字符出来前与UTF-16一样),但是为了兼容以前的MBCS程序还是加上了代码页的功能。WIN32 API所有文本参数的函数接口都包括2个版本:一个基于代码页(ANSI)的版本,一个宽版本(称为’W’)处理Unicode。前者的实现其实就是先调用MultiByteToWideChar将基于代码页编码转化为UCS-2然后再调用后者,另外还有一个WideCharToMultiByte接口将UCS-2编码转换为基于代码页的版本。
4.GB18030与UTF-8一致,采用多字节编码,是ASCII的超集。(作者居然说“这就是说微软确实是把GB18030当作一种多字节的ANSI编码来看待的。”,我已经不知道说什么好了)

知道了这些, 就容易理解Microsoft GB18030 支持工具包的原理了。正如Windows提供对GBK编码的支持一样,通过提供MultiByteToWideChar/WideCharToMultiByte接口实现对GBK与UCS-2编码的互相转换以支持,Microsoft GB18030 支持工具包提供了一个动态链接库ms4bsp.dll来实现GB18030-2000与UCS-2编码之间的互相转换。我只能说并非Windows不支持这些编码标准,而是作者根本不懂这个工具怎么用。把责任推倒有关部门的头上更是莫名其妙……

2012年9月21日 | 分类: 日志 | 标签:

RT,之前每次用U盘安装debian或者ubuntu时就会遇到这个问题,其他发行版我没试过所以不确定有没有此问题。

今天这次安装是用一个SD卡读卡器和SD卡,使用UltraISO的写入映像功能(USB-HDD+)做的启动盘,安装到磁盘分区步骤是就卡着不动,由于不是第一次两次遇到这个问题所以基本排除是硬盘的问题。我尝试用unetbootin重新做了一次启动盘,仍然是同样的问题。于是我尝试在进入partitioner时拔掉U盘(其实是读卡器……),果然partitioner可以正常设置分区,看来此问题是partitioner对这种启动U盘支持不好导致。但是到了下一步“安装基本系统”时,遇到“Debootstrap错误无法确定发布代号”的错误提示,重新插入U盘也没用,如果只是拔掉SD卡又是另外一个奇怪的错误。估计是没有mount上导致安装程序无法读取某些文件的原因。

再次安装时,在通过拔掉U盘的方式顺利走完partitioner这步之后,我插上U盘,按“ctrl + alt + f2”切换到一个字符界面,输入”mount -t vfat /dev/sdb1 /cdrom” (sdb1是U盘的第一个分区,不清楚U盘在哪儿可以通过命令“fdisk -l”查看),然后再按“ctrl + alt + f1”切换到安装界面,此时就可以顺利的继续安装系统啦!

2012年7月8日 | 分类: 日志 | 标签:

本文内容整理自维基百科,建议先阅读俺之前的《Windows代码页》和《Unicode和MBCS》。

微软的CP936通常被视为等同GBK,连 IANA 也以“CP936”为“GBK”之别名。事实上比较起来, GBK 定义之字符较 CP936 多出95字(15个非汉字及80个汉字)。

GB2312或GB2312-80是中国国家标准简体中文字符集,1981年5月1日实施,通行于中国大陆,新加坡也采用此编码。GB2312标准共收录6763个汉字以及包括拉丁字母、希腊字母、日文平假名及片假名字母、俄语西里尔字母在内的682个字符。

由于GB2312里有很多汉字并没有收录,繁体字、日语以及朝鲜语汉字也未收录在内。于是微软利用GB2312未使用的编码空间,收录GB13000.1-93全部字符制订了GBK编码。GBK是对GB2312的扩展,向下完全兼容GB2312,也就是CP936字码表的扩展(在此之前CP936与GB2312-80完全一样)。GBK采用单字节和双字节编码,兼容ASCII。

GB 18030,版本为GB 18030-2000,全称中华人民共和国国家标准GB 18030-2005《信息技术 中文编码字符集》。与GB2312完全兼容,与GBK基本兼容,支持GB 13000和Unicode的全部统一汉字,共收录汉字70244个。采用多字节编码(1/2/4)。

参考资料:
http://zh.wikipedia.org/wiki/GB_2312
http://zh.wikipedia.org/wiki/GBK
http://zh.wikipedia.org/wiki/GB_18030

 

2012年7月8日 | 分类: 日志 | 标签:

本文内容整理自微软msdn文档和维基百科,建议先了解UnicodeWindows代码页的相关知识。

Windows NT系列之前,例如Windows 95系统是原生的八位字符的操作系统,即处理字符串是每次处理一个字节。东亚版本的Windows 95系统成为多字节字符集(MBCS)系统,因为它们使用一个前导字节和一个尾字节将字符集扩展到256个以上(ANSI ASCII码只用了前面7个bit)。

Windows NT的操作系统是原生支持Unicode的,文本的基本表示是UTF-16,WCHAR的数据类型是UTF-16编码(准确的说是UCS-2,UTF-16可以看成是UCS-2的父集,在UNICODE辅助平面字符出来前,UTF-16与UCS-2是一样的)。

Win32 API里所有文本参数作为输入或输出变量的接口都有一个通用函数原型和两个定义:一个基于代码页(ANSI)的版本(称为’A’)处理代码页文本,一个宽版本(称为’W’)处理Unicode。通用函数原型包括宏形式的标准 API 函数名称。通用原型解析为一种显式函数原型(”A” 或 “W”),具体取决于编译时明示常量 UNICODE 是否是在 #define 语句中定义。在显式函数原型中,字母 “W” 或 “A” 添加在 API 函数名称的结尾处

// windows.h
#ifdef UNICODE
#define SetWindowText SetWindowTextW
#else
#define SetWindowText SetWindowTextA
#endif // UNICODE

DBCS:Windows系统上支持称为双字节字符集 (DBCS) 的多字节字符集 (MBCS) 形式。在Visual C++里,MBCS始终是指DBCS,不支持比两个字节宽的字符集。对应的还有单字节字符集SBCS,例如Windows系统里使用的CP1252。用于中文的CP936则是DBCS。

MBCS应用程序可以在任何Win32平台运行,但是依赖于系统区域语言设置(代码页)。具体问题可以参考上一篇《Windows代码页》中代码页的问题。

参考资料:

http://support.microsoft.com/kb/210341/
http://msdn.microsoft.com/zh-cn/library/cwe8bzh0%28v=vs.80%29.aspx
http://msdn.microsoft.com/zh-cn/library/5z097dxa%28v=VS.80%29.aspx
http://msdn.microsoft.com/zh-cn/subscriptions/downloads/dd317752.aspx

2012年7月8日 | 分类: 日志 | 标签:

下面内容基本上是对维基百科条目Windows code page的翻译,部分地方加了自己整理的一些东西。感谢维基百科和Google。

————————————————————分割线————————————————————

Windows代码页

Windows代码页是20世纪80年代、90年代用于Microsoft Windows系统的字符集或者说代码页,也称内码表。 Windows系统从底层支持Unicode之后,代码页被逐渐取代, 但是Windows系统和其他平台仍然支持代码页。(参考:http://en.wikipedia.org/wiki/Unicode_in_Microsoft_Windows)
Windows NT系统出现之前,Windows系统使用两类代码页:OEM和ANSI代码页。这两类代码页都是EASCII代码页。

ANSI代码页

ANSI代码页 (正式名称叫“Windows代码页”,微软承认前者是误称。http://msdn.microsoft.com/en-us/goglobal /bb964658.aspx)供非原生支持Unicode的Windows图形界面应用程序使用。ANSI Windows代码页,尤其是代码页1252,自从 据称是基于ANSI草案后,就有这个叫法了(ANSI代码页)。然而,ANSI和ISO没有标准化任何这些代码页。相反,ANSI代码页要么是ISO标准字符集的超集,如ISO 8859各种标准和各种国家标准(如用于西欧语言的Windows-1252就是ISO-8859-1的一个超集,但是与INNA的ISO-8859-1标准不同,Windows-1252使用80-9F码位定义可显示的字符而不是控制字符。),要么是标准字符集的大幅修改版本(使得这些字符集不同程度的不兼容,例如用于中欧语言的Windows-1250 ISO-8859-2,前者包含了ISO-8859-2所有的可打印字符,但是有些字符的位置有区别),要么就是没有平行的编码(比如Windows-1257ISO-8859-4; ISO-8859-13 是很久之后才制定的)。 CP1252中0x80-0x9F范围(在ISO 8859标准里被C1控制代码占用)里面的12个排版和商业字符也出现在很多其他ANSI/Windows代码页的同样位置。这些代码页被由互联网号码分配机构 (IANA)标记为“Windows-number ”。

OEM代码页

OEM代码页(OEM:原始设备制造商)被Win32控制台程序、虚拟DOS使用,可以被认为是DOS系统和原来IBM PC架构的遗留下来的产物。实现一套单独的代码页不仅仅是因为兼容性的问题,而且是因为VGA文字模式建议画线字符的编码与CP437兼容。大部分OEM代码页公用CP437的非ASCII的那一半的很多代码值,特别是对于非字母的字符。

一个典型的OEM代码页,在非ASCII的那一半,并不与任何ANSI / Windows代码页类似。然而,两个单字节,固定宽度的代码页(泰国874 和越南 1258)和四个多字节CJK代码页(932,936949950)同时用作OEM和ANSI代码页。代码页1258使用组合字符 ,因为越南语需要超过128个字母组合。相比之下,VISCII替换了一些C0控制码。

历史

最初,计算机系统和系统编程语言,并没有做字符与字节之间的识别。这导致后来很多混乱。Windows NT系列之前微软的软件和系统就是这方面的例子,使用OEM和ANSI代码页, 行前是这方面的例子,使用OEM和ANSI代码页,不作识别。

自20世纪90年代末,软件和系统越来越多地采用更直接的Unicode编码,特别是UTF-8和UTF-16; XML提 供了一个更适合标记所用编码的机制,其广泛应用更加促进了这个趋势。 最近微软的产品和应用程序接口内部使用Unicode,但是很多应用程序和API读写文本数据到文件或标准输出时继续使用计算机区域设置的默认编码。因 此,尽管Unicode是公认的标准,(Windows系统)仍然保持与旧的Windows代码页的向后兼容性。
欧元符号最近才被添加到ANSI代码页,某些字体可能无法显示。

Windows代码页列表

下面是已有的Windows代码页:

 

  • 874 – 泰文
  • 932 – 日文
  • 936 – 简体中文(中国,新加坡)
  • 949 – 韩文
  • 950 – 繁体中文(台湾,香港)
  • 1200 – Unicode(BMP ISO 10646国际编码,UTF-16LE
  • 1201 – Unicode(BMP ISO 10646国际编码,UTF-16BE
  • 1250 – 拉丁字母 ( 中欧语言)
  • 1251 – 西里尔字母
  • 1252 – 拉丁字母( 西欧语言)
  • 1253 – 希腊语
  • 1254 – 土耳其语
  • 1255 – 希伯来语
  • 1256 – 阿拉伯语
  • 1257 – 波罗的语
  • 1258 – 越南语
  • 65000 – 的Unicode(BMP ISO 10646国际编码,UTF-7)
  • 65001 – 的Unicode(BMP ISO 10646国际编码,UTF-8)

代码页的问题

Microsoft强烈建议在现代应用程序里使用Unicode,但很多应用程序和数据文件仍然依赖于遗留的代码页。这可能会导致许多问题:

  • 程序需要知道用什么样的代码页,以正确显示文件的内容。如果一个程序使用错误的代码页,它可能会显示为乱码
  • 在使用代码页的机器之间可能会有所不同,所以一台机器上创建的文件可能会在另一不可读。
  • 数据往往没有被正确地标记代码页,或者根本没有标记,导致读取数据时检测正确的代码页会很困难。
  • 这些微软的代码页与一些标准和其他厂商的实现有不同程度的区别。这不是微软本身的问题,它发生在所有的供应商,但缺乏一致性使得在某些情况下与其他系统的互操作性并不可靠。
  • 使用代码页限制了可使用的字符集。
  • 显示的代码页不支持的字符可能被转换为问号(?)或者被转换为其他替代字符,或者被转换为简单的版本(如去掉字母的重音符号)。无论哪种情况,原来的字符都可能会丢失。

参见

 

  • AppLocale -一个用来在用户的选择区域运行非Unicode(基于代码页)的应用程序的实用程序。

参考文献:

[0] ^ Code Pages, MSDN
[1] ^ MSDN: Glossary of Terms
[3] ^ IANA list of Character Sets

外部链接

 

————————————————————分割线————————————————————

updated:

为了加深理解传2个图片大家看看:

mode con cp

mode con cp select=437

有问题还请指正。

Page 2 of 41234