我有一个结构，我将转换为长度为37的字节数组，然后转换为该字符串。
我正在编写一个非常基本的激活类型库，这个字符串将在人们之间传递。所以我希望将它从长度37缩短到更容易管理的东西。
现在：
有什么方法可以缩短此字符串，但仍保留存储在其中的数据？
感谢。
答案 0 :(得分：2)
在一般情况下，从任意byte []到字符串需要 more 数据，因为我们假设我们要避免使用不可打印的字符。 减少的唯一方法就是在基数之前压缩 - 无论什么（你可以比基数64高一点，但不是很多 - 而且当然不是任何更“友好”） - 但压缩不会真的踢这么短的尺寸。基本上，你不能这样做。你试图在一个品脱罐中装一个夸脱，不起作用。
您可能需要重新考虑您的要求。也许在内部保存BLOB，并发出一个更短的令牌（可能是10个字符，可能是一个guid），它是实际BLOB的键。
答案 1 :(得分：0)
数据压缩可能是签出的可能性，但您不能将40字节的消息压缩为6个字节（例如）。
如果可能的字符串/类型的空间有限，请将它们映射到列表（信息编码）。
答案 2 :(得分：0)
如果你真的必须传递价值并且用户必须输入它，我不知道比base-64更好的东西。
如果您有一个可以访问的中央数据存储，您可以只为他们提供您保存它的行的ID。这当然取决于这些数据需要的“秘密”。
但我怀疑如果您尝试将其用于激活，则需要它们具有实际值。
字符串将如何传递？您是否可以期望用户可能只是复制/粘贴？也许花一些时间来清理来自电子邮件阅读器的多余的换行符，甚至你的“从这里复制”和“复制到这里”的行可能会有更多的成果！
答案 3 :(得分：0)
字符串中的字符是否可以使用不可打印的字符？如果是这样，你不需要对字节进行base64编码，你可以简单地从它们创建字符串（保存33％）
string str = new string(byteArray.Cast<char>().ToArray());
此外，字节数组中的值是否以某种方式受到限制？如果它们落入某个范围（即不是所有256个可能的值），您可以考虑在字符串的每个字符中填充两个。
答案 4 :(得分：0)
如果你真的有37个字节的非冗余信息，那么你就不走运了。压缩在某些情况下可能有所帮助，但如果这是激活密钥，我建议使用相同长度的密钥（并且压缩不会强制执行此操作）。
如果这段代码将通过电子邮件传递，那么我认为拥有更大的密钥没有问题。另一种选择可能是在每个5个左右的字符中插入连字符，将其分成更小的块（例如XXXXX-XXXXX-XXXXX-XXXXX-XXXXX）。
答案 5 :(得分：0)
使用160位哈希并希望不会发生冲突？它会短得多。如果您可以使用查找表，只需使用128或甚至64位增量值。比你的37个字符短得多。