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

90

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

encoding  language-agnostic  binary 
— 加马尔
source
60
为什么甚至不以256为基数？
— Gumbo
22
我认为关键是要有可打印的字符（尽管也有64个以上的字符）
— Felix Kling
29
我认为128基地属于我们。分配给后卫基地64的团队仍在坚持。
— 里奇·梅尔顿
5
为什么这个问题是javascript特定的？这对于网络上使用的其他大多数语言也适用，不是吗？
— Benedikt Waldvogel，2011年
5
@KenRockot：我看到您认识到您的某些15位字符将被编码为3个字节。您的base-2048编码意味着将11位压缩为2个字节，这使得每字节5.5位-比base-64少一半。
— maaartinus 2014年

Answers:

105

问题在于，ASCII字符集中的至少32个字符是“控制字符”，可以由接收终端解释。例如，有BEL（铃）字符使接收终端发出提示音。有SOT（传输开始）和EOT（传输结束）字符，它们的作用恰如其名。并且不要忘记字符CR和LF，它们对于如何将数据结构序列化/展平到流中可能具有特殊的含义。

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

— 佩波卢安
source
7
Base91似乎是一个不错的开源选项：base91.sourceforge.net
— Jorge Cevallos
2
值得考虑的是，2的幂更容易适应字节数据，并且编码更简单。然后就是可移植性；每种语言都有base64编码和/或base64解码。
— 罗德韦克
5
再Base85和Adobe：答案可以作出更多的有用的，如果它引用授予的专利号和年份。如果专利是一个问题，那么总是btoa可以追溯到1990年，不受专利的限制，而且这些专利肯定会过期。
— agc
65

因为这128个字符中的某些是不可打印的（主要是那些位于代码点0x20以下的字符）。因此，它们不能可靠地以线的形式通过电线传输。而且，如果超出代码点128，则可能会出现编码问题，因为跨系统使用的编码不同。

— 德里斯
source
8
Base94存在于github中，它使用所有94个可打印的ASCII字符：gist.github.com/iso2022jp/4054241
— intrepidis
15

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

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

更新：现在在GitHub上。

— 本尼迪克特·沃尔德沃格尔
source
我很想在Java版本
— 迈克尔Deardeuff
2
— Benedikt Waldvogel，2011年
12

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

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

这就是原因！

— 用户名
source
7
控制字符是相关的，因为几乎每个人都已经假设您的观点是代码页/编码应尽可能中性。这必然将您限制为仅（7位）ASCII，这是大多数相关编码的子集。同样，并非所有的互联网都是8位纯净的，其中大部分是事实上的ASCII。您的观点值得一提。
— Tim Seguine 2014年
7
只需添加：ASCII仅定义128个字符。字符＃128至＃255 没有用ASCII定义。由于问题明确引用了ASCII而不是“任何8位编码”，因此所有答案都将自己限制为ASCII集的128个字符。
— pepoluan '16
以最常见的UTF-8编码为例：128到196之间的字节将立即导致UTF8解码错误；位于196到256的字节表示下一个字节也具有相同的字符，但是如果下一个字节小于128，则将再次导致UTF8解码错误。但是，几乎所有对字符编码敏感的语言都会使base64库将base64字符串作为UTF8安全的字符串。base128无法完成相同的操作，因为它不能被编码为UTF8安全的字符串。
— SOFe
10

Base64很常见，因为它解决了许多问题（几乎可以想到的所有地方都可以使用）

  • 您无需担心传输是否是8位干净的。

  • 编码中的所有字符都是可打印的。您可以看到它们。您可以复制并粘贴它们。您可以在URL（特定变体）中使用它们。等等

  • 固定的编码大小。您知道m字节总是可以编码为n字节。

  • 每个人都听说过-它得到了广泛支持，有很多库，因此很容易进行互操作。

Base128没有所有这些优点。

看起来它是8位整洁的-但请记住，base64使用65个符号。如果没有带外字符，则无法获得固定编码大小的好处。如果您使用带外字符，则无法再进行8位清除。

但是，这并非全都是负面的。

  • base128比base64更易于编码/解码-您只需使用移位和掩码即可。对于嵌入式实现可能很重要

  • 通过使用更多可用位，base128比base64更加有效地使用了传输。

人们确实使用base128-我现在正在使用它做一些事情。只是不那么普遍。

— 约翰·拉鲁伊
source
还要记住，邮件/新闻系统及其同类（以及XML）并不总是对前32个代码点友好（例如，考虑CR LF与LF），但是否则您的答案看起来非常好。
— SamB
“ base64使用65个符号。” =>错字还是我错过了什么？
— 奇奇瓦
@Kikiwa，在Wikipedia上查看此Java示例。检查CODES变量的长度。
— John La Rooy
哦，是的，填充字符'='仅在编码有效负载的末尾，您是对的，谢谢。
— 奇奇瓦
4

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

— aj
source
2

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

GoogleCode PHP级Base128

— 清水
source
1
我希望它改用utf-8 ...
— Janus Troelsen
1
基本编码与基础数据无关。您可以使用所需的任何文本编码来编码文本/数据。他的意思是Base ##索引表使用ISO 8859-1 ASCII字符集作为转换。
— 乍得2014年
1
尝试在文本中嵌入基本编码的二进制数据后，它确实与基础数据有关。如果该文本以其他编码方式编码，您将遇到问题。
— Stijn de Witt
没有“ ISO 8859-1 ASCII”字符集。该程序使用128个不同的可打印ISO 8859-1字符对数据进行编码。它不以任何形式，形式或形式使用ASCII。
— NisseEngström'5
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.