我有一个结构，我将它转换成长度为37的字节数组，然后再转换成一个字符串。

我正在编写一个非常基本的激活类型库，这个字符串将在人们之间传递。所以我想把它从长度37缩短到更容易打字的长度。

马上：

• 将结构转换为字节数组，
• 将字节数组转换为base 64字符串(仍然太长)。

在保持存储在字符串中的数据的情况下，缩短该字符串的好方法是什么？

谢谢。

在一般情况下，从任意字节[]转换为字符串需要更多的数据，因为我们假定要避免不可打印的字符。唯一的方法是压缩之前的基地无论什么(你可以得到一点比base-64高，但不太多-而且它肯定不是任何"友好")，但压缩不会真正踢到这么短的规模。基本上，你不能这样做。你想把一夸脱装进一品脱的罐子里，但这行不通。

你可能需要重新考虑你的要求。可能在内部保存blob，并发出一个较短的令牌(可能10个字符，可能是一个guid)，它是实际blob的密钥。

使用160位哈希，希望不会发生冲突？它会短得多。如果可以使用查找表，只需使用128位甚至64位的增量值。比37个字符短得多。

如果你真的有37字节的非冗余信息，那么你就走运了。压缩在某些情况下可能会有所帮助，但如果这是一个激活密钥，我建议使用相同长度的密钥(压缩不会强制执行这一点)。

如果要通过电子邮件传递此代码，那么我认为拥有更大的密钥没有问题。另一种选择可能是每隔5个左右的字符插入一个连字符，将其分成更小的块(例如XXXXX-XXXXX-XXXXX-XXXXX-XXXXX)。

字符串中的字符是否可以有不可打印的字符？如果是这样，您不需要对字节进行base64编码，只需从中创建字符串(保存了33%)。

此外，字节数组中的值是否以某种方式受到限制？如果它们属于某个范围(即不是所有256个可能的值)，可以考虑在字符串的每个字符中填充每个值中的两个。

我不知道比Base-64更好的东西，如果你真的需要传递这个值，如果用户必须输入它的话。

如果您有一个中央数据存储，它们都可以访问，您只需给它们您保存它的行的ID即可。当然，这取决于这些数据需要如何"保密"。

但我怀疑，如果您试图用它来激活，您需要它们有一个实际的值。

如何传递字符串？你能指望用户只是复制/粘贴吗？也许花些时间来清除来自电子邮件阅读器的多余的换行符，甚至你的"从这里复制"和"从这里复制"行可能会结出更多的果实！

数据压缩可能是一种签出的可能性，但不能将40字节的消息压缩为6字节(例如)。

如果可能的字符串/类型的空间有限，请将它们映射到列表(信息编码)。