如果您有需要编码的二进制数据，您使用什么编码方案？
我知道：
还有其他常用的编码方案吗？如果是这样，有什么优点和缺点？
编辑：这很有用，例如，当尝试在 cookie 中存储任意数据时。Cookie 只能存储文本，不能存储任意数据，因此您需要以某种方式对其进行转换，最好是通过某种方式将其转换回来。此外，假设您使用的是无状态服务器，因此您无法将状态保存在服务器上，而只是将标识符放入 cookie 中。当然，如果您这样做，您还需要某种方式来验证用户传回给您的内容是否就是您传递给用户的内容，例如签名。
此外，由于目前的共识是你应该使用 base64，因为它很普遍，我还要指出这是我使用的......我只是好奇是否有人使用过其他任何东西，如果是，为什么。
编辑：以防万一有人偶然发现，如果您确实想使用 Base64 将数据存储在 cookie 中，则需要使用修改后的 Base64 实现。看到这个答案的原因。
对于编码 cookie 值，您需要小心。请参阅这个较旧的答案：
对于版本 0 cookie，值不应包含空格、方括号、圆括号、等号、逗号、双引号、斜杠、问号、at 符号、冒号和分号。空值在所有浏览器上的行为方式可能不同。
Base64 编码可以=为某些输入生成符号，这在 cookie 中技术上是不允许的（无论如何，版本 0 cookie，这是最广泛支持的）。在实践中，我怀疑它=实际上可以正常工作，但也许不是。
我建议绝对确定您的编码二进制文件与 cookie 兼容，然后基本的十六进制编码是最安全的（例如在 java 中）。
编辑：正如@Paul 有用地指出的那样，Base 64 的修改版本是“URL 安全的”（并且，我假设是“cookie 安全的”）。请注意，使用标准算法的修改版本会削弱其魅力。
编辑：@shoosh 指出，=仅用于表示 base64 字符串的结尾，因此您可以修剪=，设置 cookie，然后=在需要解码时重新附加。
Base64 获胜是因为它非常普遍，我不必担心滚动我自己的编码器/解码器。我没有遇到任何担心在编码的二进制数据中节省带宽或文件空间的应用程序。
曾几何时，有 UTF-7。它已正式弃用，但仍可用作 ACE（ASCII 兼容编码）。现在有IDN。
Base64 是事实上的标准。使用其他任何东西都是自找麻烦。