我希望以更符合网络语言的方式回答这个问题,为了回答这个问题,我们需要了解一些历史背景。
Joel Spolsky 写了一篇非常
好的入门文章,介绍了每个开发者都应该了解的 Unicode 字符编码的绝对最低要求。
请您稍等片刻,因为这将是一个相当
冗长的
答案。 :)
作为历史背景,我将引用他的一些引述:(非常感谢 Joel! :) )
唯一重要的字符是好老的无重音英文字母,我们有一个叫做ASCII的代码来表示它们,能够使用32到127之间的数字来表示每个字符。空格是32,字母“A”是65,等等。这可以方便地存储在7位中。那时候大多数计算机都使用8位字节,因此不仅可以存储每个可能的ASCII字符,而且还有一个整整的比特可以节省下来,如果你很邪恶,可以用于自己的阴险目的。
一切都很好,假设你是一个英语使用者。
因为字节可以容纳多达八个比特,许多人开始思考,“哎呀,我们可以使用128-255的代码来实现自己的目的。”问题在于,许多人同时想到了这个主意,并且他们对128到255之间的空间中应该放什么有自己的想法。
所以现在PC上分发“OEM字符集”,这些字符集仍然各不相同、不兼容。令我们当代感到惊讶的是——这一切都没问题!当时他们没有互联网,人们很少在不同区域的系统之间交换文件。
Joel继续说:
事实上,自从人们在美国以外购买电脑之后,各种不同的OEM字符集被想出来了,它们都使用前128个字符来满足自己的需要。最终,这种OEM的自由竞争在ANSI标准中得到了规范。在ANSI标准中,大家都同意在128以下怎么做,基本上与ASCII相同,但是在128及以上的字符处理方面,因所处地区而异,有许多不同的处理方式。这些不同的系统被称为
代码页。
这就是“Windows代码页”最终诞生的过程。它们实际上是由DOS代码页“孕育”而来的。然后Unicode诞生了! :)
UTF-8 是“另一种存储Unicode代码点字符串的系统”,实际上“0-127之间的每个代码点都存储在单个字节中”,与
ASCII相同。我不会再进一步解释Unicode和UTF-8,但您应该阅读有关
BOM、
字节序和
字符编码的一般信息。
在“ANSI阴谋论”中,微软实际上承认了
Windows-1252的错误标记,并在术语
词汇表中解释:
所谓的Windows字符集(WinLatin1或Windows代码页1252)使用其中一些位置用于可打印字符。因此,Windows字符集与ISO 8859-1不完全相同。Windows字符集经常被称为“ANSI字符集”,但这是非常误导人的。它没有得到ANSI的批准。
因此,指的是Windows字符集时,ANSI未经过认证!:)
正如Jukka所指出的(感谢您提供精彩的答案)
“Windows-1252 ISO Latin 1”也称为ISO-8859-1字符编码,因此在ISO-8859-1中,代码范围0x80到0x9F保留为控制字符(所谓的C1控制字符),而在Windows-1252中,其中一些代码被分配给可打印字符(大多是标点符号字符),其他未定义。然而,我的个人观点和技术理解是,Windows-1252和ISO-8859-1都
不是Web编码! :) 所以:
对于网页,请使用UTF-8编码来存储内容。同时,通过HTTP Header: Content-Type: text/html; charset=utf-8
输出。
还有一种叫做HTML内容类型元标记的东西:
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
当浏览器遇到这个标记时,会重新从HTML文档的开始处进行解释,以便使用声明的编码方式解释文档。只有在没有“内容类型”头时才会发生这种情况。
如果您的系统用户需要生成文件,请使用其他特定的编码方式。例如,某些西方用户可能需要使用Windows-1252的Excel生成文件或CSV。如果是这种情况,请以该区域设置的编码方式编码文本,然后将其存储在fs上并作为可下载文件提供。
设计HTTP时还要注意另一件事情:
内容编码分发机制应该遵循以下步骤:
I.客户端通过“接受”和“接受字符集”request headers请求特定内容类型和编码的网页。
II.然后服务器(或Web应用程序)返回转码为该编码和字符集的内容。
在大多数现代Web应用程序中并非如此。实际上,Web应用程序会强制客户端使用UTF-8来提供内容。这样做的原因是浏览器根据响应头而不是实际预期对接收到的文档进行解释。
我们应该全部采用Unicode编码,所以请尽可能和最适用的情况下使用UTF-8来分发您的内容。否则
互联网长者会来找你! :)
附注:
有关在Web页面中使用MS Windows字符的更多好文章可以在
这里和
这里找到。