不使用“”/=”的base64编码（加或等于）字符？
我需要对一个大约 1000 个字符的字符串进行编码，该字符串可以是任何字节值 (00-FF)。我不想使用十六进制，因为它不够密集。据我了解，base64 的问题在于它包含 + / 和 =，这些字符是我在应用程序中无法容忍的字符。
有什么建议吗？
I need to encode a string of about 1000 characters that can be any byte value (00-FF). I don't want to use Hex because it's not dense enough. the problem with base64 as I understand it is that it includes + / and = which are characters I can not tolerate in my application.
Any suggestions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
Base58Check 是一个选项。它开始成为加密货币地址的事实上的标准。
相对于 Base64 的基本改进：
[0-9a-zA-Z]0OIl/ 0OIl比特币地址实用程序是一个实现示例；专为比特币而设计。
注意：新颖的事实标准可能不足以满足您的需求。目前尚不清楚 Base58Check 编码方法是否会在当前协议中正式化。
Base58Check is an option. It is starting to become something of a de facto standard in cryptocurrency addresses.
Basic improvements over Base64:
[0-9a-zA-Z]0OIl/ 0OIlThe Bitcoin Address Utility is an implementation example; geared for Bitcoins.
Note: A novel de facto standard may not be adequate for your needs. It is unclear if the Base58Check encoding method will formalise across current protocols.
选择你的替代者。考虑一些其他变体：来自维基百科的 Base64 变体表。
虽然 Base64 编码器/解码器很简单，但替换替换可以通过现有 Base64 编码/解码函数（在包装器内）的简单前/后处理步骤来完成 - 否需要（完全）重新发明轮子。或者，更好的是，正如斯基特先生指出的那样，找到一个具有足够灵活性的现有库。
如果您没有其他合适的“有趣”字符可供选择（也许所有其他字符都无效，只剩下 62 个字母数字字符可供选择），您始终可以使用转义字符尺寸略有增加（~3/64？）。例如，0 (A) 将被编码为“AA”，62 (+) 将被编码为“AB”，63 (/) 将被编码为“AC”。如果您不想从头开始编写自己的编码器/解码器，这也可以作为前/后步骤完成。这种方法的缺点是输出字符与输入字节的比率不固定。
Pick your replacements. Consider some other variants: base64 Variant table from Wikipedia.
While base64 encoder/decoders are trivial, replacement subsitution can be done in a simple pre/post processing step of an existing base64 encode/decode functions (inside wrappers) -- no need to re-invent the wheel (entirely). Or, better yet, as Mr. Skeet points out, find an existing library with enough flexibility.
If you have no alternative suitable "funny" characters to choose from (perhaps all the other characters are invalid leaving only the 62 alphanumeric characters to choose from), you can always use an escape character for a very slight (~3/64?) increase in size. For instance, 0 (A) would be encoded as "AA", 62 (+) would be encoded as "AB" and 63 (/) would be encoded as "AC". This too could be done as a pre/post step if you don't want to write your own encoder/decoder from the ground-up. The disadvantage with this approach is that the ratio of output characters to input bytes is not fixed.
如果只是那些特定的字符困扰您，并且您可以找到一些其他字符来代替，那么实现您自己的自定义 Base64 模块怎么样？这并不是那么困难。
If it's just those particular characters that bother you, and you can find some other characters to use instead, then how about implementing your own custom base64 module? It's not all that difficult.
您可以使用 Base32 代替。密度低于 Base64，但完全消除了不需要的字符。
You could use Base32 instead. Less dense than Base64, but eliminates unwanted characters completely.
正如 Ciaran 所说，base64 并不是很难实现 - 但您可能需要查看现有的库，它们允许您指定要使用的自定义字符集。我很确定那里有很多，但您还没有指定您需要哪个平台。
基本上，您只需要 65 个可接受的 ASCII 字符 - 最好除了换行符之外。
As Ciaran says, base64 isn't terribly hard to implement - but you may want to have a look for existing libraries which allow you to specify a custom set of characters to use. I'm pretty sure there are plenty out there, but you haven't specified which platform you need this for.
Basically, you just need 65 ASCII characters which are acceptable - preferably in addition to line breaks.
当然。为什么不编写自己的 Base64 编码器/解码器，而是替换算法中的这些字符。当然，它无法用普通解码器解码，但如果这不是问题，那为什么还要担心呢。但是，您最好拥有至少 3 个可在您的应用中使用的其他字符来表示 +/ 和 =...
Sure. Why not write your own Base64 encoder/decoder, but replace those chars in your algorithm. Sure, it will not be able to be decoded with a normal decoder, but if that's not an issue, then whyt worry about it. But, you better have at least 3 other chars that ARE useable in your app to represent the +/ and ='s...
Base62 本质上是 Base64，但只是字母数字。
base62 is essentially base64 but alphanumeric only.