我们在基于Debian的LAMP安装上托管PHP应用程序。 一切都很好 - 性能，管理和管理明智。 然而，作为一个新的开发者（我们还在高中），我们遇到了一些西方字符集的字符编码问题。
经过大量的研究，我得出的结论是，网上的信息有点令人困惑。它说的是Windows-1252是ANSI并且完全兼容ISO-8859-1。
无论如何，Windows-1252（1/3/4）和ISO-8859-1有什么区别？ ANSI无论如何都会进入这个领域？
我们应该在Debian服务器（和工作站）上使用什么编码，以确保客户以预期的方式获取所有信息，并且我们不会丢失任何字符？
答案 0 :(得分：29)
我想以更像网络的方式回答这个问题，为了回答这个问题，我们需要一点历史。 Joel Spolsky已经写了一个非常good introductionary article的每个开发人员应该知道的Unicode字符编码的绝对最小值。
请耐心等待，因为这有点looong答案。 ：）
作为一段历史，我会从那里指出一些引用:(非常感谢Joel！:)）
唯一重要的字符是好的旧的非重音英文字母，我们有一个名为ASCII的代码，能够用32到127之间的数字代表每个字符。空格是32，字母＆＃34; A＆ ＃34;是65等。这可以方便地存储在7位。当时大多数计算机使用的是8位字节，所以你不仅可以存储所有可能的ASCII字符，而且还有一点闲暇，如果你是邪恶的，那么你可以用它来实现你自己的目的。
假设你是一位说英语的人，一切都很好。 因为字节有多达8位的空间，所以很多人都在思考，而且，我们可以将代码128-255用于我们自己的目的。＆＃34;麻烦的是，很多人同时有这个想法，并且他们有自己的想法，应该在128到255的空间里去哪里。
所以现在＆＃34; OEM字符集＆＃34;与PC一起分发，这些仍然是不同的和不兼容的。对我们当代的惊奇 - 一切都很好！他们没有互联网，人们很少在不同地区的系统之间交换文件。
乔尔接着说：
事实上，一旦人们开始在美国以外地区购买个人电脑，就会设想各种不同的OEM字符集，这些字符集都是出于自己的目的使用前128个字符。 最终这个免费的OEM被编入ANSI标准。在ANSI标准中，每个人都同意在128以下做什么，这几乎与ASCII相同，但是有很多不同的方法可以处理128和以上的字符，具体取决于你居住的地方。这些不同的系统称为code pages。
这就是＆＃34; Windows Code page＆＃34;最终出生了。他们实际上是'＃34;父母＆＃34;由DOS代码页。然后Unicode诞生了！ :)和UTF-8是＆＃34;另一个用于存储Unicode代码点串的系统＆＃34;实际上＆＃34; 0-127的每个代码点都存储在一个字节中＃34;和ASCII相同。我不再讨论Unicode和UTF-8的细节，但你应该阅读BOM，Endianness和Character Encoding作为一般信息。
On＆＃34; ANSI阴谋＆＃34;，Microsoft实际上承认Windows-1252中glossary of terms的错误标记：
所谓的Windows字符集（确切地说是WinLatin1或Windows代码页1252）将一些位置用于可打印字符。因此，Windows字符集与ISO 8859-1不同。 Windows字符集通常称为＆＃34; ANSI字符集＆＃34;，但这是严重错误的。它尚未获得ANSI批准。
因此，引用Windows字符集时的ANSI未经ANSI认证！ ：）
正如Jukka所指出的那样（积分向你致谢）
Windows-1252 ISO Latin 1，也称为ISO-8859-1作为字符编码，因此代码范围0x80到0x9F保留用于ISO-8859-1中的控制字符（所谓的C1控制），在Windows-1252中，有些代码被分配给可打印字符（主要是标点字符），其他代码未定义。
然而，我的个人观点和技术理解是Windows-1252和ISO-8859-1 都不是WEB编码！ :)所以：
对于网页，请使用UTF-8作为内容的编码
因此，将数据存储为UTF-8和＆＃34;将其吐出＆＃34;使用HTTP Header：Content-Type: text/html; charset=utf-8。
还有一个名为 HTML内容类型元标记的东西：
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
现在，浏览器在遇到此标记时实际执行的操作是，它们再次从HTML文档的开头开始，以便它们可以在声明的编码中重新解释文档。只有在没有“内容类型”的情况下才会发生这种情况。报头中。
如果系统用户需要从中生成文件，请使用其他特定编码。 例如，一些西方用户可能需要Excel生成的文件，或Windows-1252中的CSV。如果是这种情况，请对该语言环境中的文本进行编码，然后将其存储在fs中，并将其作为可下载文件提供。
在设计HTTP 中还有另一件需要注意的事项： 内容编码分发机制应该像这样工作。
我。客户通过以下方式请求特定内容类型和编码的网页：接受＆＃39;和＆＃39; Accept-Charset＆＃39; request headers
II。然后，服务器（或Web应用程序）将转码的内容返回到该编码和字符集。
在大多数现代网络应用中，这不是个案。实际上，Web应用程序以UTF-8的形式提供（强制客户端）内容。这是有效的，因为浏览器根据响应头而不是实际预期的内容来解释收到的文档。
我们都应该使用Unicode，所以请使用UTF-8尽可能地分发您的内容，最重要的是。否则the elders of the Internet会困扰你！ ：）
答案 1 :(得分：15)
对字符编码名称含义最权威的参考是IANA注册管理机构Character Sets。
Windows-1252通常称为Windows Latin 1或Windows West European或类似的东西。它不同于ISO Latin 1，也称为ISO-8859-1作为字符编码，因此代码范围0x80到0x9F保留用于ISO-8859-1（所谓的C1控件）中的控制字符，在Windows中-1252，某些代码被分配给可打印字符（主要是标点字符），其他代码未定义。
ANSI在这里用作用词不当。微软曾将Windows-1252提交给美国国家标准协会（ANSI）作为标准;该提案遭到拒绝，但微软仍将其代码称为“ANSI”。为了进一步混淆，他们可能会使用“ANSI”来表示不同的编码（基本上是Windows安装的“本机8位编码”）。
在Web上下文中，将声明ISO-8859-1，就像您声明了Windows-1252一样。原因是在网络上没有使用或使用C1控件，而经常使用添加的字符，即使在错误标记为ISO-8859-1的页面上也是如此。所以从实际角度来说，你声明哪一个并不重要。
如果声明的话，可能仍然有一些浏览器实际上将数据解释为ISO-8859-1，但它们必须非常罕见（我记得最后看到的是大约十年前的Opera版本）。
您没有描述遇到的问题。问题的最常见原因似乎是数据实际上是UTF-8编码但声明为ISO-8859-1（或Windows-1252），反之亦然。如果服务器强制 Content-Type标头声明字符编码并且它们在他们的创作环境中无法处理（或者不知道），那么对于网页作者来说这就成了一个真正的问题该怎么做）。
答案 2 :(得分：2)
ANSI （Windows-1252）在具有英语/拉丁字母的国家/地区，例如英国/美国/法国/德国等，指的是Windows-1252编码。 https://web.archive.org/web/20170916200715/http://www.microsoft.com:80/resources/msdn/goglobal/default.mspx
视窗1252。和ISO-8859-1非常相似。他们只是不同 32个字符。
在Windows-1252中，128到159之间的字符用于一些有用的字符 欧元符号等字符。
在ISO-8859-1中，这些字符被映射到控制字符 在HTML中没用。
__ 所以一个建议 所以看看128是否是欧元符号..如果是它的Windows 1252。 __
ISO-8859-1中没有使用128到159的代码，但很多 浏览器将显示Windows-1252中的字符） 字符集而不是什么。
这两个链接列出了它们。
http://www.w3schools.com/charsets/ref_html_ansi.asp
http://www.w3schools.com/charsets/ref_html_8859.asp
有些评论非常有用，我根据这些评论相应修改了我的帖子。
陈峰指出 在Windows上，＆＃34; ANSI＆＃34;指的是由语言环境指定的系统代码页，无论是什么（阿拉伯语/中文/西里尔语/越南语......）。它[不一定]指向Windows-1252。您可以通过更改语言环境进行测试，然后使用notepad.exe将文本文件保存在＆＃34; ANSI＆＃34;中。根据这个MS文档，有14种不同的＆＃34; ANSI＆＃34;代码页https://docs.microsoft.com/en-us/windows/desktop/intl/code-page-identifiersWernfriend指出 https://web.archive.org/web/20170916200715/http://www.microsoft.com:80/resources/msdn/goglobal/default.mspx并且美国代码页437是“OEM代码页”，（请参阅OEM列），OEM代码页是cmd提示符使用的代码页。他指出/建议，从该网页显示，在许多非英语/拉丁字母的国家，ansi不是Windows 1252.我注意到，例如，希伯来语ansi使用1255.（希伯来OEM代码页是862）。 / p>
答案 3 :(得分：1)
此表概述了差异。它显示了在Windows-1252中定义但在ISO-8859-1 / ISO-8859-15中不可用的所有字符：
│ …0 │ …1 │ …2 │ …3 │ …4 │ …5 │ …6 │ …7 │ …8 │ …9 │ …A │ …B │ …C │ …D │ …E │ …F │
─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
8… │ € │ │ ‚ │ ƒ │ „ │ … │ † │ ‡ │ ˆ │ ‰ │ Š │ ‹ │ Œ │ │ Ž │ │
Unicode │ 20AC │ │ 201A │ 0192 │ 201E │ 2026 │ 2020 │ 2021 │ 02C6 │ 2030 │ 0160 │ 2039 │ 0152 │ │ 017D │ │
─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
9… │ │ ‘ │ ’ │ “ │ ” │ • │ – │ — │ ˜ │ ™ │ š │ › │ œ │ │ ž │ Ÿ │
Unicode │ │ 2018 │ 2019 │ 201C │ 201D │ 2022 │ 2013 │ 2014 │ 02DC │ 2122 │ 0161 │ 203A │ 0153 │ │ 017E │ 0178 │
与Windows-1252不同，范围0x80 ... 0x9F用于ISO-8859-1中的Control Codes。
此表显示Windows-1252，ISO-8859-1和ISO-8859-15之间的差异
Character │ € │ Š │ š │ Ž │ ž │ Œ │ œ │ Ÿ │ ¤ │ ¦ │ ¨ │ ´ │ ¸ │ ¼ │ ½ │ ¾ │
───────────────────────────────────────────────────────────────────────────────────────────────────────
ISO 8859-1 │ – │ – │ – │ – │ – │ – │ – │ – │ A4 │ A6 │ A8 │ B4 │ B8 │ BC │ BD │ BE │
ISO 8859-15 │ A4 │ A6 │ A8 │ B4 │ B8 │ BC │ BD │ BE │ – │ – │ – │ – │ – │ – │ – │ – │
Windows-1252 │ 80 │ 8A │ 9A │ 8E │ 9E │ 8C │ 9C │ 9F │ A4 │ A6 │ A8 │ B4 │ B8 │ BC │ BD │ BE │
Unicode │ 20AC │ 160 │ 161 │ 17D │ 17E │ 152 │ 153 │ 178 │ A4 │ A6 │ A8 │ B4 │ B8 │ BC │ BD │ BE │