UTF-8000: Unlimited UTF-8

sph

> UTF-8000 is in no way endorsed by or representative of the Unicode Consortium. Not until they decide to expand the emoji range, allocate space for all past and future fictional languages, as well as birdsong and dog barks. Someone at the consortium is rubbing their hands with glee with all the newfound space. But honestly, cool hack! If you invent a method to encode large numbers into bytes, why limit yourself to 24-bit numbers?

Dwedit

FF bytes are an easy way to identify an invalid UTF-8 file. This idea doesn't have that property.

achille

> Ken Thompson: "...i really dont think it is useful. it is like replacing ipv6 with ipv50"

snvzz

No project is ever safe from complicators. This is why we need the KISS enforcers.

flohofwoe

Phew, and I was worried that we'd be running out of UNICODE space for new emojis ;)

mrlonglong

I love it. Some day we'll need this when we finally realise we are not alone in the universe. Alien glyphs ftw.

Grimeton

More like WTF-8. https://xkcd.com/1953/

Sharlin

UTF-8 originally supported up to six-byte encodings (see eg. RFC 2279), but it was restricted to four bytes in 2003 in order to match UTF-16 constraints :(

2shortplanks

On a practical matter, it seems like a bad idea to have codepoints that can take up to an arbitrary number of bytes - this just screams buffer overflow problems. So in practicality, you’re going to want an arbitrary limit on this (the article suggests as much). But if you place a limit on it then you’ve got one implementation of the standard that can decode certain characters and another that can’t. Better to have one standard that puts a hard limit on the number of bytes and another standard that uses more bytes and so on.

jibal

The letter from Ken Thompson is spot on: "your first 2 extensions (5 and 6 bytes) were clearly envisioned. the standard (up to 4 bytes) was created to cover the size of unicode. i thought any more description would be a waste of paper. i think your extension from 7 to 8 bytes is a little hoaky. i requires reading the whole string rather than "knowing" the number of follow on bytes. so, i think the only thing new is the 7 byte version. i appreciate the mail, but i really dont think it is useful. it is like replacing ipv6 with ipv50."

yyyk

Just limit it to 8 bytes at which point you always do 'know the number of follow on bytes' from the first byte. Nobody needs more than 4.47 trillion characters. (famous last words)

rsanheim

This is like TIME CUBE ( https://en.wikipedia.org/wiki/Time_Cube ) but for encoding nerds. edit: replaced false prophet site with wiki link for the original one and true timecube.com...lost to the sands of ...time.

beeforpork

It would be nice if the first paragraph gave a motivation for this. Why did you start this? I mean, I can derive from the text that this can encode arbitrarily large integers. So what? What's the point? I also understand that this is for fun.

mqus

Some ideas of what to do with this space: - fully-customizable emojis (think of a RPG-like character customization screen) - heck, why not full jpegs/gifs? - some unicode programming script (running Doom) - ? That said, some very minor (HN-style) nitpick: > Otherwise for an n byte code unit this is (5n+1) / 8n, that is 5n+1 content bits out of a total of 8n bits from n bytes. We can rewrite this as (5/8) + 1/(8n) which moderately quickly approaches 5/8 = 62.5%. It is nice that this limit is nonzero and does not depend on n. Isn't a limit by definition no longer dependent on n?

lukasgelbmann

Self-synchronization in UTF-8 is intuitively a great thing to have, yet I don’t remember actively relying on it ever. Does anyone have a good example of when it‘s useful? Another related nice property that UTF-8 has: substring search reduces to bytestring substring search. I.e. given two Unicode strings in UTF-8 encoding, you can check if one is a substring of the other by just treating them as bytestrings and checking if one bytestring is a substring of the other bytestring. This is a stronger property than self-synchronization: UTF-8 has it, but UTF-8000 doesn’t.

lifthrasiir

I was about to immediately suggest UCS-X, and then pleased that the author offers a fair comparison to UCS-X and many other alternatives. Great. Too bad UCS-X is possibly more memorable name.

etatoby

Finally, an ASCII-safe way to encode all the vectors of Neuralese.

avadodin

IIRC UTF-8 proposal used to go to 6 bytes as they already felt that not having part of the code point in the first byte was an issue somehow. I think at least 7 should be allowed. 42 bits could contain all sorts of information. "UTF-8000" is still ANSI-safe and although it loses some of the properties such as a header code only appearing once in a byte sequence, it is perfectly viable to encode arbitrarily sized unsigned integers.

imhoguy

Alright, so now we can fit an entire LLM model into one character.

stbenjam

> No special cases introduced. All properties preserved. I don’t actually know if this is LLM-generated, but phrasing like this is weirdly triggering to me now