UTF-8000がUTF-8の限界を突破、任意長の符号単位を実現
UTF-8000: Unlimited UTF-8
UTF-8を拡張し、任意の大きさのcodepointを符号化できる「UTF-8000」が提案された。ASCIIとUTF-8を完全に包含しつつ、複数のstart byteをcontinuation byteに分散させることで、理論上無制限の長さのcode unitを実現。self-synchronizationやself-punctuationといったUTF-8の利点をすべて継承し、overlong encodingも防止する。参照実装はpipxでインストール可能。Unicode Consortiumとは無関係の独立したfun projectだ。
UTF-8000の仕様の主な貢献は、UTF-8のcode unitの最初のバイトの最上位ビットをself-synchronizationビットとstartビットに分割し、必要に応じてstartビットをcontinuation byteにストライプ配置して、任意の大きさのcode unitを実現する方法を明確にしたことにある。
HNでの議論
118- 2shortplanks
実際的な問題として、任意のバイト数を取れるコードポイントがあるというのは悪いアイデアに思えます。これはバッファオーバーフローの問題を引き起こすとしか思えません。
だから実際には、これに任意の制限を設けたくなるでしょう（記事もそう示唆しています）。しかし制限を設けると、ある実装は特定の文字をデコードでき、別の実装はできないということになります。バイト数に厳格な制限を設けた標準と、より多くのバイトを使う別の標準、といった具合に分けた方が良いでしょう。
- sph
> UTF-8000はUnicode Consortiumによって承認されたものでも、その代表でもありません。
絵文字の範囲を拡張し、過去と未来のすべての架空言語、さらには鳥のさえずりや犬の鳴き声のためのスペースを割り当てるまではね。
Consortiumの誰かは、新たに見つかったスペースに手をこすり合わせて喜んでいることでしょう。
でも正直に言って、クールなハックです！大きな数をバイトにエンコードする方法を発明したのなら、なぜ24ビットの数に限定する必要があるのでしょうか？
- Sharlin
UTF-8はもともと最大6バイトのエンコーディングをサポートしていました（例えばRFC 2279を参照）が、2003年にUTF-16の制約に合わせるために4バイトに制限されてしまいました :(
- stbenjam
> 特殊ケースは導入されていません。すべての特性が保持されています。
これがLLMによって生成されたものかどうかは実際には分かりませんが、こういう言い回しは今の私には妙に引っかかります。
- zahlman
Unicode Consortiumが実際にそれらのコードポイントを割り当てることはないので、これは機能的には可変長整数をエンコードするためのスキームにすぎず、多かれ少なかれ恣意的にUTF-8の拡張として設計されたものです。
こうした設計には長い歴史があり（https://en.wikipedia.org/wiki/Variable-length_integer）、著者は興味を持つかもしれません。私自身もこれらのことを考えたことがあります。符号付き値のための「ジグザグエンコーディング」も含めてです（難しいアイデアではありません。この「驚くべき全単射写像」は、整数が可算であることを示すために数学の授業で使われる標準的なもので、その優れた実装特性は、最初に0から-1へ「ジグ」するという選択と、2の補数の仕組みの組み合わせから生じるものです）。
- yyyk
単に8バイトに制限すれば、最初のバイトから続くバイト数が常に分かるようになります。
4.47兆文字以上必要とする人はいません。（有名な最後の言葉）
- bastawhiz
ある時点で、それは可能なすべての4096ビット埋め込みベクトルのハフマン符号化のようなものに崩壊してしまいます。
- achille
> Ken Thompson: 「...私は本当にそれが有用だとは思わない。IPv6をIPv50に置き換えるようなものだ」