-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Non-Crockford's Base32 letters converted differently in Java or Python implementations #58
Comments
Eddie, Thanks for reporting the issue. I've got a couple ideas but this will need some deeper investigation. No promises but I should have some free time to dive-in within the next couple of days. Best, |
Eddie, Thanks again for reporting this and I apologize for the issue! I merged in a fix and pushed out version Best, |
Thanks Andrew, that was super fast! |
Andrew, sorry to be a pain. I was testing those cases and they now work perfectly (thanks again for being so fast!). In [6]: u = ulid.from_str('01BX73KC0TNH409RTFD1UXKM00')
In [7]: u
Out[7]: <ULID('01BX73KC0TNH409RTFD3ZXKM00')>
In [8]: u.str
Out[8]: '01BX73KC0TNH409RTFD3ZXKM00'
I checked Crockford's Base32 and values I'm guessing we should error out if we encounter those? I checked the Java implementation we're currently using and we do get an
Is this behaviour something we should also be compliant with in the Python version? Thanks again! Eddie |
Eddie, Yes, this observation is correct. I was working on changes for this last night as well but didn't have time to finish so I just got out a quick release to the initial issue. The current implementation will validate that the input string is at least in ASCII but yes, there are certain characters that don't overlap between that and Base32, so those will sneak in. The code to solve this is relatively straight forward but I want to run it though some performance benchmarks to see the impact before committing to an implementation design. I've created #60 to track this. Best, |
Thanks Andrew! |
Eddie, I merged in a fix tonight and closed #60. Version Let me know if it works or if you run into any regressions. Thanks again for reporting this! Best, |
Thanks Andrew, just made a few examples on my local and now it raises a Thanks again for the swift response to this! Eddie |
Hi Andrew,
first of all, thanks for the amazing library, we've been using a lot!
I have a doubt regarding how we fix the conversion of ULIDs which are not following Crockford's Base32 standard.
We are using Lua to generate some guids (https://github.com/Tieske/ulid.lua) and for some reason, we get from time to time letters outside the Crockford's Base32.
While trying to fix this on our side (we're not sure how this is happening to be honest), we realised that Java and Python implementations silently corrects this issue in different ways:
Java
mO
is silently converted intoM0
Python
mO
is silently converted intoQZ
Shouldn't the python library behave as the Java one as per the Crockford's Base32 spec, converting
L
andI
to1
andO
to0
and only upper casing lower case letters instead of changing them?Thanks a lot in advance!
Eddie
The text was updated successfully, but these errors were encountered: