Windows代码页

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

有问题还请指正。

  1. 2013年3月3日17:40

    正在做编码转换相关的开发,这篇文章非常有用!

    [回复]

[cusFace:84] [cusFace:83] [cusFace:82] [cusFace:79] [cusFace:67] [cusFace:66] [cusFace:65] [cusFace:54] [cusFace:53] [cusFace:52] [cusFace:51] [cusFace:50] [cusFace:49] [cusFace:48] [cusFace:47] [cusFace:44] [cusFace:43] [cusFace:42] [cusFace:41] [cusFace:40] [cusFace:39] [cusFace:38] [cusFace:37] [cusFace:36] [cusFace:35] [cusFace:34] [cusFace:33] [cusFace:32] [cusFace:31] [cusFace:30] [cusFace:29] [cusFace:28] [cusFace:27] [cusFace:26] [cusFace:25] [cusFace:24] [cusFace:23] [cusFace:22] [cusFace:21] [cusFace:20] [cusFace:19] [cusFace:18] [cusFace:17] [cusFace:16] [cusFace:15] [cusFace:14] [cusFace:13] [cusFace:12] [cusFace:11] [cusFace:10] [cusFace:09] [cusFace:08] [cusFace:07] [cusFace:06] [cusFace:05] [cusFace:04] [cusFace:03] [cusFace:02] [cusFace:01] [cusFace:00]