Some alphabets have the disadvantage of generating swears, which might be a problem for your use. Applying filters is a difficult approach. Hex has the advantage there.
The official Base32 doesn't work for encoding UUID7, which is time-ordered, because its symbols for 0-31 are not in ascending ASCII order.
My own preferred format for UUID7 is one I call "id25". It's really Base35 because alphabets of 35 and 36 characters both need 25 characters to represent the 128 bits in a UUID. So I can start with Base36 and take out one of the next most ambiguous character pairs. The result looks something like '0pydgw5pifvapk5zyhmpso5tx'.
The two other advantages of using this id25 format rather than UUID7 are:
- The id25 format is quite distinct from UUID4. So if you have UUID7s being generated distributedly (rather than centrally) and the UUID7 time-ordering feature is important, it's nice to have a format that a trivial "if '-' in uuid_string..." check will spot.
- Because there are no hyphens or symbols, the whole id25 uuid can be selected in web page with a double click. Whereas a uuid will need a mouse movement to get all 5 parts.
Do many use cases need lexical ordering for the encoding of the UUID? (The UUIDs themself would still be ordered; it's just the human/URL/wire encoding that isn't.)
Most of the use cases I can think of where I'd want an ordered UUID, I probably wouldn't need to lexically compare the encoding of multiple such IDs (where I can see plenty of utility in the ability to compare the underlying IDs).
For sure yes! There are tons of situations where you need to use the string form of an ID, e.g. filenames, and you definitely want the lexical ordering of files in a directory to be correct.
I've always seen the human encoding as the main point, so you can infer things about them while working with them. A database, for example, would have a datetime column that can be used instead most of the time.
