我们在基于 Debian 的 LAMP 安装上托管 PHP 应用程序。一切都很好-性能，行政和管理方面的明智。然而，作为一个有点新的开发者（我们还在上高中），我们在 Western Charsets 的字符编码方面遇到了一些问题。
经过大量研究，我得出的结论是，网上的信息有些混乱。它谈论的是 Windows-1252 是 ANSI 并且完全兼容 ISO-8859-1。
那么无论如何，Windows-1252（1/3/4）和ISO-8859-1有什么区别？无论如何，ANSI 在哪里出现？
我们应该在我们的 Debian 服务器（和工作站）上使用什么编码，以确保客户端以预期的方式获取所有信息并且我们不会在途中丢失任何字符？
我想以更像网络的方式回答这个问题，为了回答这个问题，我们需要一点历史。Joel Spolsky写了一篇非常好的介绍性文章，介绍了每个开发人员都应该知道的关于 Unicode 字符编码的绝对最小值。在这里忍受我，因为这将是一个looong答案。:)
作为历史，我将引用那里的一些引言：（非常感谢乔尔！:)）
唯一重要的字符是古老的无重音英文字母，我们有一个称为 ASCII 的代码，它能够使用 32 到 127 之间的数字表示每个字符。空格是 32，字母“A”是 65，等等。这可以方便地存储在 7 位中。那时的大多数计算机都使用 8 位字节，因此您不仅可以存储所有可能的 ASCII 字符，而且您还有一整点的空闲空间，如果您是邪恶的，您可以将其用于您自己的狡猾目的。
一切都很好，假设你会说英语。因为字节最多可容纳八位，所以很多人开始思考，“天哪，我们可以将代码 128-255 用于我们自己的目的。” 问题是，很多人同时有这个想法，他们对从 128 到 255 的空间应该去哪里有自己的想法。
因此，现在“OEM 字符集”与 PC 一起分发，但这些仍然不同且不兼容。令我们当代惊讶的是——一切都很好！他们没有互联网，人们很少在具有不同语言环境的系统之间交换文件。
乔尔继续说：
事实上，当人们开始在美国以外的地方购买 PC 时，各种不同的 OEM 字符集就出现了，它们都将前 128 个字符用于自己的目的。最终，这个免费的 OEM 被编入了 ANSI 标准。在 ANSI 标准中，每个人都同意在 128 以下做什么，这与 ASCII 几乎相同，但是有很多不同的方法可以处理 128 及以上的字符，具体取决于您居住的地方。这些不同的系统被称为代码页。
这就是“Windows 代码页”最终诞生的方式。它们实际上是 DOS 代码页的“父级”。然后 Unicode 诞生了！:) 并且UTF-8是“另一种用于存储 Unicode 代码点字符串的系统”，实际上“0-127 的每个代码点都存储在一个字节中”，并且与ASCII相同。我将不再详细介绍 Unicode 和 UTF-8，但您应该阅读BOM、Endianness和Character Encoding作为一般信息。
关于“ANSI 阴谋”，微软实际上承认了Windows-1252在术语表中的错误标签：
所谓的 Windows 字符集（准确地说是 WinLatin1，或 Windows 代码页 1252）使用其中一些位置来存储可打印字符。因此，Windows 字符集与 ISO 8859-1 不同。Windows 字符集通常称为“ANSI 字符集”，但这是严重误导。它尚未获得 ANSI 的批准。
因此，ANSI 在引用 Windows 字符集时不是经过 ANSI 认证的！:)
正如 Jukka 指出的那样（感谢你的好答案）
Windows-1252 ISO Latin 1，也称为 ISO-8859-1 作为字符编码，因此代码范围 0x80 到 0x9F 是为 ISO-8859-1 中的控制字符（所谓的 C1 Controls）保留的，而在 Windows 中-1252，其中一些代码分配给可打印字符（主要是标点符号），其他代码未定义。
但是我个人的观点和技术理解是 Windows-1252 和 ISO-8859-1都不是 WEB 编码！：） 所以：
对于网页，请使用 UTF-8 作为内容的编码因此将数据存储为 UTF-8 并使用HTTP Header :将其“吐出” Content-Type: text/html; charset=utf-8。
还有一种叫做HTML content-type meta-tag的东西：
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
现在，当浏览器遇到这个标签时，实际上他们会从 HTML 文档的开头重新开始，以便他们可以重新解释声明编码的文档。仅当没有“Content-type”标头时才会发生这种情况。
如果您的系统用户需要从中生成的文件，请使用其他特定编码。例如，一些西方用户可能需要 Excel 生成的文件，或 Windows-1252 中的 CSV。如果是这种情况，请在该语言环境中对文本进行编码，然后将其存储在 fs 上并将其作为可下载文件提供。
在HTTP的设计中还有一点需要注意：内容编码分发机制应该像这样工作。
I.客户端通过以下方式请求具有特定内容类型和编码的网页：“Accept”和“Accept-Charset”请求标头。
二、然后服务器（或 Web 应用程序）将内容转码为该编码和字符集。
大多数现代网络应用程序都不是这种情况。Web 应用程序以 UTF-8 提供（强制客户端）内容的实际情况。这之所以有效，是因为浏览器根据响应标头而不是它们实际预期的内容来解释接收到的文档。
我们都应该使用 Unicode，所以请，请，请尽可能使用 UTF-8 分发您的内容，并且最重要的是适用。否则互联网的长辈会缠着你！:)
对字符编码名称含义最权威的参考是 IANA 注册表字符集。
Windows-1252 通常称为 Windows Latin 1 或 Windows West European 或类似名称。它不同于 ISO Latin 1，也称为 ISO-8859-1 作为字符编码，因此代码范围 0x80 到 0x9F 是为 ISO-8859-1 中的控制字符（所谓的 C1 Controls）保留的，而在 Windows -1252，其中一些代码分配给可打印字符（主要是标点符号），其他代码未定义。
ANSI 在这里是用词不当。微软曾向美国国家标准协会 (ANSI) 提交 Windows-1252 作为标准采用；该提议被拒绝，但微软仍然称他们的代码为“ANSI”。为了进一步混淆，他们可能将“ANSI”用于不同的编码（基本上，Windows 安装的“本机 8 位编码”）。
在 Web 上下文中，声明 ISO-8859-1 将被视为您声明了 Windows-1252。原因是 C1 控件在 Web 上没有使用或有用，而添加的字符经常被使用，即使在错误标记为 ISO-8859-1 的页面上也是如此。因此，实际上，您声明哪一个并不重要。
如果这样声明，可能仍然有一些浏览器实际上将数据解释为 ISO-8859-1，但它们一定非常罕见（我记得最后一次看到的是大约十年前的 Opera 版本）。
你没有描述你遇到了什么问题。问题的最常见原因似乎是数据实际上是 UTF-8 编码但声明为 ISO-8859-1（或 Windows-1252），反之亦然。如果服务器强制标Content-Type头声明字符编码并且这是他们无法在其创作环境中处理的（或不知道如何处理），这对于网页作者来说将成为一个真正的问题。
此表概述了这些差异。它显示了在 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 中的控制代码。
此表显示 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 │
ANSI (Windows-1252) 在使用英语/拉丁字母的国家/地区，例如英国/美国/法国/德国等，指的是 Windows-1252 编码。 https://web.archive.org/web/20170916200715/http://www.microsoft.com:80/resources/msdn/goglobal/default.mspx
Windows-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
一些评论非常有用，我根据它们相应地修改了我的帖子。
Chenfeng 指出，在 Windows 上，“ANSI”指的是由语言环境指定的系统代码页，无论是什么（阿拉伯文/中文/西里尔文/越南文/...）。它没有 [必要] 参考 Windows-1252。您可以通过更改您的语言环境来测试这一点，然后使用 notepad.exe 将文本文件保存为“ANSI”。根据这个 MS 文档，有 14 个不同的“ANSI”代码页 https://docs.microsoft.com/en-us/windows/desktop/intl/code-page-identifiers
Wernfriend 指出 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）。