i33*_*36_ 6 javascript encoding bit-manipulation utf-8 character-encoding
我最近发现base32、base64和base128是最有效的base- n编码形式，虽然base58、Ascii85、base91、base92等由于使用了更多字符而确实比普遍存在的base64提供了一些效率改进，但是一些映射损失；例如，base92 中的每个字符对恰好有 272 个索引，这些索引无法映射到以 10 为底的 2 的幂，因此完全被浪费了。（Base91 编码仅丢失 89 个字符（如上面链接中的脚本所示），但它已获得专利。）
如果能够在现代的现实场景中使用 base128，那就太好了。
0x21 (33) 到 0x7E (126) 之间有 92 个可用字符（不含 \和"），这为创建具有尽可能多字符的可 JSON 字符串提供了良好的开端。
以下是我设想的找到其余角色的几种方法。这就是我要问的问题。
就傻傻的用Unicode吧
可以使用两字节 Unicode 字符来填充剩余的 36 个所需索引。高度次优；如果这比网络上的 Base64 更糟糕，我不会感到惊讶。仅对 Unicode 字符计数场景有用，例如推文长度。不完全是我想要的。
从上限 (>128) ASCII 范围内选择 36 个非 Unicode 字符
JavaScript 是在字符编码配置偶尔会出现严重错误的情况下构建的。因此，该语言（和网络浏览器）可以很好地处理打印任意和不可打印的二进制数据。那么为什么不直接使用 ASCII 范围的上限呢？是要用的，对吧？
一个非常现实的问题可能是数据在我的浏览器和服务器之间通过 HTTP 传输并通过一个或多个开罐器代理。事情会变得多么糟糕？我知道几年前，甚至在今天，基于 HTTP 的 WebSocket 造成了一些真正的痛苦。
以有趣的方式使用 UTF-8
UTF-8 定义 1 到 4 字节长的序列来封装 Unicode 代码点。字节 2 到 4 始终以 开头10xxxxxx。该范围内有 64 个字符。如果我通过一个简单的代理来逐个字符地过滤 Unicode 范围之外的字符，那么使用此范围内的字节可能意味着我的数据将毫发无伤地通过！
确定可用于各种深奥原因的 36 个魔法字节
由于各种历史或实施原因，也许有一些高 ASCII 字符将成功穿越 > 99% 的互联网基础设施。这些可能是什么角色？
Base64 无处不在，并且最终被广泛使用，原因很容易理解：它于1987 年定义，使用精心挑选的、非常受限制的 AZ、az、0-9、+ 和 / 字母表，过去（现在仍然如此） ）对于大多数环境（例如使用非 ASCII 编码的大型机）来说很难出现问题。
EBCDIC 大型机和 MIME 电子邮件仍然存在，但如今，base64 也已成为 JavaScript 中广泛使用的管道，用于处理“此数据路径中的某些内容可能因二进制文件而阻塞”的情况，以及它增加的集体开销是不平凡的。
目前，SO 上只有一个关于 base128 编码的一般可行性的问题，并且实际上每个答案都有一个或多个问题。接受的答案表明，base128 必须准确使用 ASCII 的前 128 个字符，并且承认编码字母表可以使用任何字符的唯一答案继续声称未使用 base128，因为编码字符必须易于重新键入（其中base58 针对 FWIW 进行了优化）。所有其他人都有各种问题（如果需要，我可以进一步解释）。
这个问题试图通过一些额外的明确主题澄清来重新询问上述内容，希望能够确定具体的进行/不进行。
它在技术上可行的意义上是可行的，但在能够比更简单的替代方案（使用 HTTP gzip 压缩）获得更好的结果方面是不可行的。实际上，如果启用压缩，字符串的霍夫曼编码将抵消 Base64 编码大小增加的 1/3，因为 Base64 字符串中的每个字符只有 6 位熵。
作为测试，我尝试使用Dummy File Creator等实用程序生成 1Mb 的随机数据文件。然后对其进行 base64 编码并使用 7zip 对生成的文件进行 gzip 压缩。
这仅增加了 1.12% 的大小（以及编码 -> 压缩 -> 解压缩 -> 解码的开销）。
Base128 编码将占用 1,198,373 字节，因此如果您想要类似的文件大小，您也必须对其进行压缩。Gzip 压缩是所有现代浏览器的标准功能，那么 base128 的情况以及由此带来的所有额外复杂性又如何呢？