在不让事情变得过于可压缩的情况下，我能得到的最小哈希是什么？我想一个很好的例子就是散列"foo"。
input = foo
sha1 = 0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33
sha1 + b64 = C+7Hteo/D9vJXQ3UfzxbwnXaijM
有没有其他像Base64这样使用unicode字符的标准？可能包括上/下元音变音符字符，如Ü和ü，以将更多的比特打包到每个字符中？理想情况下，我希望将sha1散列压缩为4-6个unicode字符，我可以将其粘贴到URL上。
对哈希进行可逆编码不会影响冲突率。。。除非您的编码导致数据丢失(否则它将不再可逆)。
Base64和其他二进制到文本编码方案都是可逆的。您的第一个输出是十六进制(或base16)表示，其效率为50%。Base64实现了75%的效率，这意味着它将40个字符的十六进制表示减少到28个字符。
最有效的二进制编码方案是yEnc，它实现了98%的效率，这意味着当用yEnc编码时，100字节长的输入大约为102字节。这就是真正的问题出现的地方：SHA-1输出是160位(20字节)长。如果您通过使用每2字节的UTF16字符来实现200%的字符字节效率，那么您仍然会看到10个字符。您无法实现这一点，因为从U+D7FF到U+E000的2字节值不是有效的UTF16字符。这些字节值被保留为较高平面字符的前缀。
即使你发现这样一个使用unicode的超高效1编码方案，你也不能真正将其用作URL。URL中禁止使用Unicode字符，为了符合标准，您应该对URL使用%编码。许多浏览器都会自动转换它们，所以你可能会觉得这是可以接受的，但你经常使用的许多字符都不是人类可读的，还有更多的字符可能是不同的语言。
在这一点上，如果你真的需要短URL，你应该重新考虑使用哈希值，而是实现你自己的身份服务(例如，为每个页面或资源分配一个增量ID，这显然很难扩展)或使用另一个链接缩短服务。
1：从比特的角度来看，这是不可能的。Unicode可以实现更高的字符位比，但Unicode字符本身由多个字节表示。大多数浏览器将UTF8的%编码作为无法识别的编码的默认值，它很快就会变得混乱。