Hacker News Reader

Comment by declan_roberts | Hacker News Reader

It’s 2023. Why aren’t we using more characters from the utf-8 keyspace to make things like UUIDs use less characters?

You could, if you are only optimizing for display size. UUIDs are very infrequently presented as user-facing data, and pretty much every sensible system will be storing them as a 128-bit value, not the ASCII representation you see.

So really, what are you trying to optimize?

UUIDs show up absolutely everywhere as strings in logs.

They're also often used as part of a URL parameter:

http://myservice/orders/<uuid> etc etc

UUIDs are 128-bits, not characters. The string representation is just for humans.

I think the parent is saying that we can make UUIDs more human-readable by displaying the underlying 128 bits with a larger set of characters.

Base58 and Base64 exist in pure-ASCII space. Expanding into non-ASCII characters would probably just be confusing.

We could make the string representation more compact with more characters, but I’m not sure compactness and readability are the same, especially any compactness that takes more than the ASCII character set (sure, just the hexadecimal digits may be fewer than ideal.)

I think it's a fair question, because yes you should store them as numbers, but they are still often sent in text formats and urls. Wanting a shorter representation is reasonable.

The easiest is probably to just base64 the binary representation of the 128 bit number, which results in a 128/6=22 character string, which is a bit smaller.

If glyph-length and not byte-length is more important you could go even smaller but I'm less sure if that's a good idea.

This is the way. Look not at the characters but at the hex.

Base8192: https://alicecengal.github.io/uuid-hangul/

That's awesome. "Aesthetic, Cosmopolitan" LOL

Not very useful. Always decodes to 00NaN-0NaN-0NaN-0NaN-000000NaN.

The decode input needs to be exactly ten hangul character, and must be the first 8192 hangul characters in the unicode set. Obviously I didn't put too much effort into making this robust, it was just a fun toy project.

Firstly, "it's current year" is never a good argument, but you seem to be confusing things (UTF-8 vs Unicode). UTF-8 can take as much as 6 bytes to encode a Unicode codepoint.

If you want to store UUIDs as compactly as possible you'd use 16 bytes.

If you want to store them as text, mapping them to Unicode would be a terrible idea because: many characters are from scripts you've never heard of, many characters look identical (Α vs A), many characters are decomposed and it can change the encoding if they're decomposed[1], &c.

[1]: https://en.wikipedia.org/wiki/Precomposed_character

Because it's 2023. You're looking at the UUID through a giant pile of interpreters and renderers and buffers... plenty of opportunity to give each one a tartan without changing it in the data.

Or better yet, only decorate one after it has been clicked by the user, that way when it appears again elsewhere, it stands out. If you make each one pretty you'll have made all of them ugly when viewed together.

UUIDs are 128 bits, or 16 bytes. They have infinitely many possible string representations. Those strings are not the value, they're a transformation of the value.

The strings are how HUMANS not machines interact with the UUID. When your java stacktrace spits out a log with an UUID it's going to spit out a STRING because it's written for you and not the computer.

When you take that UUID and go start sniffing around internal systems you're going to copy the UTF-8 string representation.

OK, but you don't store the string representation in your DB, or on disk, etc.

we should display them as a monochrome block of 8*16 pixels.

Reply on news.ycombinator.com