为什么不使用base128？ [关闭]答案

【问题标题】：Why is base128 not used? [closed]为什么不使用base128？ [关闭]
【发布时间】：2011-05-15 11:18:25
【问题描述】：

为什么在网络上传输二进制数据只使用base64而不是base128？ ASCII 字符集有 128 个字符，理论上可以表示 base 128，但大多数情况下只使用 base64 而不是 base128。

【问题讨论】：

为什么不是基数 256？
我认为重点是要有可打印个字符（虽然也有超过64个...）
我认为 base 128 不久前属于我们。分配到 64 号基地守卫的小队仍在坚持。
为什么这个问题是特定于 javascript 的？这也适用于网络中使用的大多数其他语言，不是吗？
@KenRockot：我看到你认识到你的一些 15 位字符会被编码为 3 个字节。您的 base-2048 编码意味着将 11 位打包成 2 个字节，这使得每个字节 5.5 位 - 比 base-64 少一半。

【解决方案1】：

问题在于 ASCII 字符集中至少有 32 个字符是“控制字符”，可以由接收终端解释。例如，有一个 BEL（铃）字符使接收终端响铃。有 SOT（传输开始）和 EOT（传输结束）字符，它们的功能完全符合其名称的含义。并且不要忘记字符 CR 和 LF，它们可能在数据结构如何序列化/扁平化为流时具有特殊含义。

Adobe 创建 the Base85 encoding 以在 ASCII 字符集中使用更多字符，但 AFAIK 它受专利保护。

【讨论】：

Base91 似乎是一个不错的开源选项：base91.sourceforge.net
值得考虑的是，2 的幂更容易拟合字节数据，并且编码更简单。然后是便携性；每种语言都有 base64 编码和/或 base64 解码。
Re Base85 和 Adobe：如果引用专利号和授予年份，答案可能会更有用。如果专利有问题，总是有btoa，它的历史可以追溯到 1990 年，不受专利的影响，而且这些肯定会过期。

【解决方案2】：

因为这 128 个字符中有一些是不可打印的（主要是那些低于代码点 0x20 的字符）。因此，它们不能作为字符串可靠地通过电线传输。而且，如果您超过代码点 128，您可能会遇到编码问题，因为跨系统使用不同的编码。

【讨论】：

Base94 存在于 github 中，它使用所有 94 个可打印的 ASCII 字符：gist.github.com/iso2022jp/4054241

【解决方案3】：

正如其他答案中已经说明的那样，关键是将字符集减少为 可打印 字符集。更有效的编码方案是basE91，因为它使用更大的字符集并且仍然避免低 ASCII 范围内的控制/空白字符。该网页包含二进制与 base64 与basE91 编码效率的很好比较。

我曾经清理过 Java 实现。如果有人感兴趣，我可以在 GitHub 上推送。

更新：现在是on GitHub。

【讨论】：

我对java版本感兴趣
推送到：github.com/bwaldvogel/base91

【解决方案4】：

前 32 个字符是控制字符绝对没有相关性，因为您不必使用它们来获得 128 个字符。我们有 256 个字符可供选择，只有前 32 个是控制字符。剩下 192 个字符，因此 128 个字符完全可以不使用控制字符。

原因如下：它必须看起来相同，并且无论在哪里都可以复制和粘贴。因此，它必须是在任何论坛、聊天、电子邮件等中显示相同的字符。这意味着我们不能使用字符，论坛/聊天/电子邮件客户端通常可以使用这些字符进行格式化或忽略。它还必须是相同的字符，无论字体、语言和区域设置如何。

这就是原因！

【讨论】：

控制字符是相关的，因为几乎每个人都已经假设你的观点应该尽可能地保持代码页/编码中性。这必然会限制您使用（7 位）ASCII，它是大多数相关编码的子集。也不是所有的互联网都是 8 位干净的，而且大部分都是事实上的 ASCII。不过，您的观点是值得的。
补充一点：ASCII 只定义了 128 个字符。 #128 到#255 字符不是用 ASCII 定义的。由于该问题明确引用了 ASCII 而不是“任何 8 位编码”，因此所有答案都将自己限制为 ASCII 集的 128 个字符。
以最常见的 UTF-8 编码为例： 128 到 196 的字节会立即导致 UTF8 解码错误； 196 到 256 的字节意味着下一个字节也是相同的字符，但是如果下一个字节低于 128，它将再次导致 UTF8 解码错误。但是，几乎所有对字符编码敏感的语言都会让 base64 库将 base64 字符串作为 UTF8 安全字符串。 base128 不能这样做，因为它不能被编码为 UTF8 安全字符串。

【解决方案5】：

Base64 很常见，因为它解决了各种问题（几乎可以在您能想到的任何地方使用）

您不必担心传输是否为8-bit clean。
编码中的所有字符都是可打印的。你可以看到他们。您可以复制和粘贴它们。您可以在 URL（特定变体）中使用它们。等等。
固定编码大小。你知道m 字节总是可以编码为n 字节。
每个人都听说过 - 它得到广泛的支持，有很多库，因此很容易互操作。

Base128 并不具备所有这些优势。

看起来它是 8 位干净的 - 但请记住 base64 使用 65 个符号。如果没有带外字符，您将无法获得固定编码大小的好处。如果你使用带外字符，你就不能再 8 位干净了。

但也不全是负面的。

base128 比 base64 更容易编码/解码 - 您只需使用移位和掩码。对于嵌入式实现可能很重要
通过使用更多可用位，base128 比 base64 更有效地利用传输。

人们做使用base128 - 我现在正在使用它。这并不常见。

【讨论】：

还请记住，邮件/新闻系统及其同类（以及 XML）并不总是对前 32 个代码点友好（例如，考虑 CR LF 与 LF），但否则你的答案看起来很很好。
"base64 使用 65 个符号。" => 错字还是我遗漏了什么？
@Kikiwa，看看这个java sample on wikipedia。检查CODES 变量的长度。
哦，是的，填充字符 '=' 仅在编码有效负载的末尾，你是对的，谢谢。

【解决方案6】：

不确定，但我认为较低的值（表示控制代码或其他内容）不能可靠地作为 HTTP 请求/响应中的文本/字符传输，并且 127 以上的值可能是特定于语言环境/代码页/任何内容的，所以没有 128 个不同的字符可以在所有浏览器/平台上使用。

【讨论】：

【解决方案7】：

esaji 是对的。 Base64 用于对二进制数据进行编码，以便使用仅需要文本的协议进行传输。就在Wiki 条目中。

【讨论】：

【解决方案8】：

检查 base128 PHP 类。使用 ISO 8859-1 字符集进行编码和解码。

GoogleCode PHP-Class Base128

【讨论】：

我希望它使用 utf-8...
基本编码与底层数据无关。您可以使用您希望对文本/数据进行编码的任何文本编码。他的意思是 Base## 索引表使用 ISO 8859-1 ASCII 字符集作为翻译。
当您尝试在文本中嵌入基本编码的二进制数据时，它确实与基础数据有关。如果该文本以另一种编码方式编码，则会出现问题。
没有“ISO 8859-1 ASCII”字符集这样的东西。该程序使用 128 个不同的可打印 ISO 8859-1 字符对数据进行编码。 它不以任何方式、形状或形式使用 ASCII。