【发布时间】：2026-02-04 18:15:02
【问题描述】：
UTF-8 和 ISO-8859-1 有什么区别？
【问题讨论】：
标签： utf-8 character-encoding iso-8859-1
【发布时间】：2026-02-04 18:15:02
【问题描述】：
UTF-8 是一种多字节编码，可以表示任何 Unicode 字符。 ISO 8859-1 是一种单字节编码，可以表示前 256 个 Unicode 字符。两者编码 ASCII 的方式完全相同。
【讨论】：
-
需要注意的是，ASCII 仅从 0 扩展到 127。 MSB 始终为 0。
-
当定义高于 127 的码位时，编码系统是扩展 ASCII 的一个版本。
-
@RohanBhale 不要使用短语扩展 ASCII；只会造成混乱。
-
但扩展 ascii 可能是正确的术语。我在多个资源上阅读过它
【讨论】：
-
@mu 也许我的陈述是模棱两可的，但它并没有错——我不是在谈论编码的字节序列，而是正在编码的字符集；这意味着 ISO-8859-1 用于编码 Unicode 字符集的前 256 个代码点。
-
你的澄清对我有用，“模棱两可”比“不正确”是一个更好的词选择。
UTF
UTF 是一系列多字节编码方案，可以表示Unicode 代码点，最多可以表示 2^31 [大约 20 亿] 个字符。 UTF-8 是一个灵活的编码系统，它使用 1 到 4 个字节来表示前 2^21 [大约 200 万] 个代码点。
长话短说：代码点/序数表示低于 127 的任何字符，也就是 7 位安全 ASCII 由与大多数其他单字节编码相同的 1 字节序列表示。代码点高于 127 的任何字符都由两个或多个字节的序列表示，编码的细节最好解释here。
ISO-8859
ISO-8859 是一系列单字节编码方案，用于表示可以在 127 到 255 范围内表示的字母表。这些不同的字母表以 ISO-8859- 格式定义为“部分” n，其中最熟悉的可能是ISO-8859-1 aka 'Latin-1'。与 UTF-8 一样，无论使用何种编码系列，7 位安全 ASCII 都不会受到影响。
这种编码方案的缺点是它无法容纳包含超过 128 个符号的语言，或者一次安全地显示多个符号系列。同样，随着 UTF 的兴起，ISO-8859 编码已经失宠。负责它的 ISO“工作组”已于 2004 年解散，将维护工作留给其上级小组委员会。
Windows 代码页
值得一提的是，微软还保持a set of character encodings 与 ISO-8859 的有限兼容性，通常表示为“cp####”。 MS 似乎在推动他们最近的产品版本以一种或另一种形式使用 Unicode，但出于遗留和/或互操作性的原因，您仍然可能会遇到它们。
例如，cp1252 是 ISO-8859-1 的超集，包含 0x80-0x9F 范围内的其他可打印字符，特别是欧元符号 € 和备受诟病的“智能引号”“”。这通常会导致不匹配，其中 8859-1 可以完美地显示为 1252，而 1252 可能似乎 可以很好地显示为 8859-1，但是当出现这些额外符号之一时会出现异常。
除了 cp1252，土耳其语 cp1254 是 ISO-8859-9 的类似超集，但所有其他 Windows 代码页至少存在一些基本冲突，如果与它们的 8859 等效项没有完全不同的话。
【讨论】：
-
+1 用于回答问题，但不限于提供有关相关编码的信息。回复：UTF-8 的代码点，根据*.com/a/38488358/3353984，UTF-8 支持 2^21 个代码点。这是一个错误，还是需要修复？
-
Unicode 实际上是 2^16 个代码点的 17 个平面。 0x00_0000 到 0x1F_FFFF。 17 个平面可容纳 1,114,112 个代码点。其中，2,048 个是代理，66 个是非字符，137,468 个保留供私人使用，剩下 974,530 个用于公共分配。大约 100 万个。见How many characters can UTF-8 encode?。
ASCII：7 位。 128 个代码点。
ISO-8859-1：8 位。 256 个代码点。
UTF-8：8-32 位（1-4 字节）。 1,112,064 个代码点。
ISO-8859-1 和 UTF-8 都向后兼容 ASCII，但 UTF-8 不向后兼容 ISO-8859-1：
#!/usr/bin/env python3
c = chr(0xa9)
print(c)
print(c.encode('utf-8'))
print(c.encode('iso-8859-1'))
输出：
©
b'\xc2\xa9'
b'\xa9'
【讨论】：
ISO-8859-1 是 1980 年代的遗留标准。它只能表示 256 个字符，因此仅适用于西方世界的某些语言。即使对于许多受支持的语言，也缺少一些字符。如果您以这种编码创建一个文本文件并尝试复制/粘贴一些中文字符，您会看到奇怪的结果。所以换句话说，不要使用它。 Unicode 已经占领了世界，UTF-8 几乎是当今的标准，除非你有一些遗留的原因（比如需要与所有东西兼容的 HTTP 标头）。
【讨论】：
-
我已经看到了元音变音不是用 UTF8 转换的。我们看到了这样的例子，在搜索中我们找到了 ISO-8859-1，它似乎有效。我们有很多与我们合作的德国科学家。
-
元音变音在 utf8 中表示为两个字符。他们转换得很好并且工作得很好。问题来自期望每个字符 1 个字节的程序。对于这些遗留程序，ISO-8859-1 有 1 个字节的变音符号。
-
“也就是说，不要使用它。”我不会这么说，因为在某些用例中，ISO-8859-1 比 UTF-8 更适合，因为单字节和 256 个字符就足够了，从而可以加快处理速度并减少有效负载。
-
作为首选单字节编码的示例，SMS 消息有 140 个字节的限制，并且主要使用单字节编码。如果您是一家发送自动 SMS 消息的企业，您不希望仅仅为了不使用旧标准而将成本翻倍。
需要意识到的更重要的一点是：如果您看到iso-8859-1，它可能指的是Windows-1252，而不是ISO/IEC 8859-1。它们在 0x80–0x9F 范围内有所不同，其中 ISO 8859-1 具有 C1 控制代码，而 Windows-1252 具有有用的可见字符。
例如，ISO 8859-1 有 0x85 作为控制字符（在 Unicode 中，U+0085，``），而 Windows-1252 有一个水平省略号（在 Unicode 中，U+2026 HORIZONTAL ELLIPSIS，…） .
WHATWG Encoding spec（由 HTML 使用）明确声明 iso-8859-1 是 windows-1252 的标签，并且 Web 浏览器不以任何方式支持 ISO 8859-1：HTML 规范说必须支持编码规范，仅此而已。
同样有趣的是，HTML 数字字符引用基本上使用 Windows-1252 来表示 8 位值，而不是 Unicode 代码点；每https://html.spec.whatwg.org/#numeric-character-reference-end-state，… 将产生 U+2026 而不是 U+0085。
【讨论】：
-
糟糕！以为我已经写了，但我在重写时丢失了它。我已经把它放进去了。
从另一个角度来看，unicode 和 ascii 编码都无法读取的文件，因为它们中有一个字节 0xc0，似乎可以被 iso-8859-1 正确读取。需要注意的是，文件中当然不应包含 unicode 字符。
【讨论】：
我研究这个问题的原因是从这个角度来看，它们在什么方面是兼容的。 Latin1 字符集 (iso-8859) 100% 兼容存储在 utf8 数据存储中。所有 ascii 和扩展 ascii 字符都将存储为单字节。
换一种方式，从 utf8 到 Latin1 字符集可能有效，也可能无效。如果有任何 2 字节字符（扩展 ascii 255 之外的字符），它们将不会存储在 Latin1 数据存储中。
【讨论】：
-
有帮助，但我认为您的意思是扩展 ascii 255 中的 127 而不是 255？
-
Latin-1 或 iso-8859-1 不是 100% 兼容存储在 utf8 中。任何大于 127 的 Latin-n 或 iso-8859-n 字符都不会被转换为单字节 utf-8 字符。但是，对于 1-127 的值，它们将完全转换。
-
这个答案在使用术语“扩展 ascii”时有点令人困惑，它只是指任何非 ASCII 字符编码的术语。 UTF-8 和 latin-1 是扩展 ASCII 编码的示例。但是，非 ascii latin-1 字符（即高于 127 的代码点）不能在 UTF-8 中编码为单个字节。
-
在 UTF-8 中，2 字节编码从 128 开始。但是两者都有匹配的字符，所以可以去：ISO 8859-1 -> UTF-8 -> ISO 8859-1 无损但如果 UTF-8 文档中有大于 255 的字符，则无法无损转换。