I know that most hash functions today use Base64 encoding for their functions, resulting in hashes that use a-Z and 0-9, and, sometimes, other special characters. This results in 62-76ish possible values for each character, so if your hash ends up being say, 70 characters long, there are 70^62 possible combinations.
But what if there was a hashing functioned designed to take advantage of UTF-8? From what I understand there are roughly 100,000 possible values for each character. This means, near as I can tell, that there would be 70^100,000 possible values, which is a lot. Seems like you couldn't make a rainbow table of that.
Also, I know that speed is very important in hashing functions. Would this be inherently slower than a Base64 hashing function?
I know that "bits of entropy" have a lot to do with the security of a password. Does this somehow improve those entropied bits? I'm pretty confused about entropy, to be honest.
Note that I'm not talking about combining a existing function with UTF8. I'm wondering if a whole new cryptographic hashing function was made to take advantage of UTF-8's larger character set, would it be better (at least in theory) than existing functions?
From my reading there seems to be some problems with bits floating around and causing confusion. Would it be possible to work around this, or is it the reason why you can't successfully hash UTF-8 for passwords, as the risk of collision increases dramatically and unpredictably?