为什么 ASCII 和 ISO-8859-1 编码没有成为历史？答案

【问题标题】：Why haven't ASCII and ISO-8859-1 encoding been relegated to history?为什么 ASCII 和 ISO-8859-1 编码没有成为历史？
【发布时间】：2010-09-02 04:26:16
【问题描述】：

在我看来，如果 UTF-8 是唯一使用过的编码，那么代码问题就会少很多：

甚至不需要考虑编码问题。
混合 1-2 字节字符流没有问题，因为所有内容都使用 2 个字节。
浏览器无需等待<meta> 标记指定编码就可以执行任何操作。 StackOverflow 甚至没有 meta 标签，使得浏览器首先下载整个页面，从而降低页面渲染速度。
您永远不会在旧网页上看到 ? 和其他随机符号（例如，代替 Microsoft Word 的特殊 [阅读：可怕] 引号）。
更多字符可以用 UTF-8 表示。
其他我暂时想不到的事情。

那么为什么劣质编码没有从太空中被淘汰呢？

【问题讨论】：

是什么让它们“劣质”？与 UTF-8 相比，ASCII 具有许多优点。您所有的抱怨都是关于编码之间的混淆，而不是 UTF-8 的“劣质”编码（如 ASCII 或 EBCDIC）的固有优势。请解决问题以删除“劣质”短语并坚持您的观点 - 混淆。不是“优越感”。
ASCII 比 UTF-8 有很多优点？请赐教！
好吧，让我把我的 Tardis 跳回 1960 年左右，并确保“无处不在”使用除了 utf-8 之外的任何东西。
如果你是一台自动取款机，UTF-8 就差很多了：en.wikipedia.org/wiki/ISO_8583
ASCII 有许多优点：1) 它是一种广泛使用的传统，可能在比 UTF-8 更多的地方和更多的语言中得到支持。 2）这很简单。 3）它没有复杂的“转义”来编码额外的字符。您可能不喜欢它，但这些都可以视为“优势”。称其为“劣等”只是价值判断，使问题具有“争论性”。

标签： encoding utf-8 character-encoding

【解决方案1】：

甚至不需要考虑编码问题。

没错。除了仍然是旧 ASCII 格式的所有数据。

混合 1-2 字节字符流没有问题，因为所有内容都使用 2 个字节。

不正确。 UTF-8 是可变长度的，从 1 到 6 个字节左右。

浏览器无需等待指定编码的标记就可以执行任何操作。 StackOverflow 甚至没有 meta 标签，使得浏览器首先下载整个页面，从而减慢页面渲染速度。

浏览器一般不会等待整个页面，它们会根据页面数据的第一部分进行猜测。

你永远不会看到？和旧网页上的其他随机符号（例如，代替 Microsoft Word 的特殊 [阅读：可怕] 引号）。

除了所有那些other使用其他非UTF-8编码的旧网页（非英语世界相当大）。

更多字符可以用 UTF-8 表示。

没错。您的数据验证问题也变得更加困难。

【讨论】：

好答案。除了第一点，因为 UTF-8 可以将现有的 ASCII 文本视为完全有效的 UTF-8。这不适用于 ISO-8859-1。

【解决方案2】：

为什么 EBCDIC、Baudot 和 Morse 仍未脱离轨道？为什么在戈特利布·戴姆勒（Gottlieb Daimler）交付他的第一辆汽车后的第二天，马车制造商没有关门？

将技术归入历史需要非零时间。

【讨论】：

但是Baudot已经存在了100多年，只占据了浪费ASCII的70%空间！

【解决方案3】：

混合 1-2 字节没有问题字符流，因为一切都使用 2 个字节。

完全不正确。 UTF-8 是一种混合宽度的 1、2、3 和 4 字节编码。您可能一直在考虑 UTF-16，但即使是 4 字节字符也有一段时间了。如果你想要一个“简单”的固定宽度编码，你需要 UTF-32。

你永远不会看到？和其他随机旧网页上的符号

即使使用 UTF-8 网页，您仍然可能没有支持所有 Unicode 字符的字体，所以这仍然是个问题。

更多的字符可以表示为 UTF-8。

有时这是一个缺点。拥有更多字符意味着需要更多位来对字符进行编码。并跟踪哪些是字母、数字等。并存储用于显示这些字符的字体。并处理其他与 Unicode 相关的复杂性，例如规范化。

对于具有千兆字节 RAM 的现代计算机来说，这可能不是问题，但不要指望您的 TI-83 很快就会支持 Unicode。

但是，如果您确实需要这些额外的字符，使用 UTF-8 比使用数以千计的不同 8 位字符编码（加上一些非自同步东亚多字节编码）。

那么为什么没有劣质编码被太空核弹了？

在很大程度上，这是因为“劣质”编程语言还没有从太空中被淘汰。许多代码仍然是用早于 Unicode 的 C 和 C++（甚至是 COBOL！）等语言编写的，并且仍然没有很好的支持。

我很遗憾希望我们摆脱某些库使用以 UTF-8 编码的基于 char 的字符串的情况，而另一些库则认为 char 用于传统编码，而 Unicode 应始终使用 @ 987654323@ 然后你必须处理 wchar_t 是 UTF-16 还是 UTF-32（或两者都不是）。

【讨论】：

【解决方案4】：

我不认为 UTF-8 使用“2 位”它是可变长度的。还有很多操作系统级别的代码分别是 UTF-16 和 UTF-32，这意味着拉丁编码可以选择 ASCII 或 ISO-8859-1。

【讨论】：

2 位意味着 2 个字节。编辑了问题。
是的，但它仍然认为 UTF-8 介于 1 到 4 个字节之间。
@Coronatus 但重点是，UTF-8 不是 2 字节编码。这是一种可变长度编码，每个字符使用 1-4 个字节。与单字节编码相比，这是它的缺点之一：您必须担心在字符中间拆分字符串，如果不解析每个字节就无法判断字符串有多长（以字符为单位），等等。
通常需要知道字符串中有多少字节用于内存分配。或者，不太常见的是，要知道一个字符串需要多少个 终端列 用于文本换行。但是您需要多久知道一次字符的数量？

【解决方案5】：

嗯，你的问题有点像为什么世界如此糟糕的抱怨。这是因为它是如此。使用 UTF-8 以外的其他编码编写的页面来自 UTF-8 被操作系统严重支持且 UTF-8 尚未成为事实上的标准的时代。

只要有人不更改这些页面，它们就会保持其原始编码，这在许多情况下不太可能。他们中的许多人不再得到任何人的支持。

互联网上也有很多非 unicode 编码的文档，格式很多。有人可以转换它们，但如上所述，需要付出很多努力。

因此，对非 unicode 的支持也必须保留。

在当前，当有人使用非 unicode 编码时，小猫会死掉。

【讨论】：