Incorrect encoding/decoding about crockford HOT 8 CLOSED

Hi! Thanks for your report. As near as I can tell, the correct Crockford-encoded value for 18198581554926920725 is actually "FS3JSG42PA90N". Are you sure these other sites are encoding integers instead of arrays of bytes?

from crockford.

For one thing, a Crockford-encoded u64 can't start with z. That'd be bigger than the maximum value of a u64. At least, I'm pretty sure that I have "FZZZZZZZZZZZZ" down as the maximum value.

from crockford.

I suppose, in that case, it would be a bug to decode any value that long and starting with a z....

from crockford.

Ok, try it now. You should get a nice fat error.

from crockford.

Unless I'm mistaken with this library, it shouldn't be an error. ZJ75K085CMJ1A is actually the correct value for my example. My use case is that I'm implementing the Microsoft's Package Family Name algorithm. Even in the article's author's example, it starts with a z.

I have a gist of my code here. Everything after .take(8) is just manually encoding with crockford base32.

This is my test case:

#[cfg(test)]
mod tests {
    use crate::msix_impl::package_family_name::get_package_family_name;

    #[test]
    fn test_package_family_name() {
        assert_eq!(
            get_package_family_name("AppName", "Publisher Software"),
            "AppName_zj75k085cmj1a"
        );
    }
}

from crockford.

from crockford.

Ok, think of it this way: Crockford encoding encodes five bits per character, right? So, multiply 13*5 and what do you get? You get 65. Not 64. That means that if you fully load up all 65 bits that COULD be represented by the string "zzzzzzzzzzzzz," you get a number larger than the maximum value that can be represented in only SIXTY-FOUR bits. You get what I'm saying? That's why the max value starts with an F and not a Z. No value beginning with a Z is a valid u64.

from crockford.

Thanks for explaining :)

from crockford.