spec icon indicating copy to clipboard operation
spec copied to clipboard

Is ULID actually case insensitive?

Open freak4pc opened this issue 5 months ago • 3 comments

We've noticed an edge case related to Base32 where the same ULID in lowercase and upercase could be invalid in one case and valid in the other case:

Image Image

The spec does indicate prominently that ULID is case insensitive, but this doesn't seem to be the case?

Would appreciate your thoughts 🙏

freak4pc avatar Jul 07 '25 18:07 freak4pc

Crockford's Base32 is supposed to be case-insensitive and has even alias characters (Like I, i, L, l and 1 all are number 1). The website you are using, is not working according to the standard.

Seramis avatar Jul 14 '25 17:07 Seramis

Image

If the case is sensitive in a single direction, I don't think the spec can be published as "case insensitive" wholesale, as that creates a false understanding of what assumption can be made about working with ULIDs.

Also, it does seem many implementations (major ones like Swift and JS) are actually case sensitive (this isn't the spec's problem, but quite surprising).

freak4pc avatar Jul 14 '25 19:07 freak4pc

In the end, it's just a well-defined mapping for 5-bit values. And during decoding, there are some "aliases" defined in addition.

The simple bullet-point list in this ULID spec here could be more precise, true. At the same time, it does mention specifically Crockford's Base32 and when you usually care about case-(in)sensitive-ness, it's the scenarios where the string representation is the input data. Considering those aspects, the spec isn't really wrong or missing any crucial information. It isn't even misleading, IMO.

As for those implementations that don't implement Crockford's Base32 properly, I would personally say they are gravely violating the spec and their implementation is just plain wrong/non-functional.

NB! I manage my own ULID implementation for C#: https://github.com/ByteAether/Ulid

Seramis avatar Jul 14 '25 19:07 Seramis