我最近发现base32, base64 and base128 are the most efficient forms of base-n encoding，虽然base58，ascii85，base91，base92等人提供了一些效率改善优于无处不在的base64，由于他们使用更多的字符，有一些映射损失;例如，基数92中每个字符对恰好有272个指数，不可能映射到2的基数为10的幂，因此完全被浪费掉了。 （Base91编码只有89个字符的相似损失（如以上链接中的脚本所示），但是it's patented。）对于JavaScript字符串等场景，base128编码的可行性如何？
如果在现代真实世界的场景中使用base128是可行的，那将会很棒。
有0×21（33）的0x7E（126）中提供92个字符SANS\和"，它使一个很好的开始创造与可能的字符最多JSONifiable字符串。
以下是我设想可以找到其余字符的几种方法。这是我问的问题。
只是默默地使用Unicode
两字节Unicode字符可以用来填补剩余的36个所需的指数。非常不理想;如果这比线路上的base64差，我不会感到惊讶。仅对于推文长度等Unicode字符计数场景才有用。不完全是我要去的。
选择从上（> 128）ASCII范围
的JavaScript内36非Unicode字符被以期望的字符编码配置将偶尔严重错误建造。所以语言（和网页浏览器）处理打印任意和不可打印的二进制数据就好了。那么为什么不使用上面的ASCII范围呢？它在那里被使用，对吧？
一个非常现实的问题可能是数据通过HTTP进行传输，并通过一个或多个
开罐器代理服务器在我的浏览器和服务器之间传输。这有多严重？我知道HTTP上的WebSockets几年前造成了一些真正的痛苦，甚至可能在今天。
使用UTF-8以有趣的方式
UTF-8定义的1至4个字节的长序列来封装Unicode代码点的种类。字节2到4始终始于
10xxxxxx。该范围内有64个字符。如果我通过一个na代理服务器，它可以逐个字符地过滤Unicode范围之外的字符，在这个范围内使用字节可能意味着我的数据将毫发无损！
确定36个魔法字节，将各种深奥的原因
也许有一些会成功穿越互联网基础设施的> 99％，由于各种历史和实施过程中的原因，某些高ASCII字符的工作。这些可能是什么字符？
Base64是无处不在的，并已清盘正在使用无处不在，这是很容易理解为什么：它是在1987年定义为使用一个精心挑选的，非常有限的AZ的字母， az，0-9，+和/对于大多数环境（例如使用非ASCII编码的大型机）来说（并且仍然）很困难。
EBCDIC大型机和MIME电子邮件仍然非常有，但今天的base64也结束了作为频繁使用的管道内的JavaScript来处理的情况下，“东西在这个数据路径威力呛二进制”它增加的集体开销并不重要。
目前只有one other question on SO regarding the general viability of base128 encoding，从字面上看，每一个答案都有一个或多个问题。接受的答案表明base128必须使用ASCII的前128个字符，并且唯一的答案是确认编码字母可以使用任何字符，然后继续声称base128未被使用，因为编码字符必须易于重新输入（这是base58针对FWIW进行了优化）。所有其他人都有各种各样的问题（如果需要，我可以进一步解释）。
这个问题试图重新提出上面的一些额外的明确主题澄清，希望能够确定具体的去/不去。