無限線形バイナリストレージがあると仮定して、0から無限大までの整数を表す適切なスキーマですか？

スキーマに0から始まる整数を制限なしで表すことを望みます（無限線形ストレージへのアクセスを想定）。

以下は、0から255までの数値を表すことができるスキーマです。

ストレージの最初のバイト（アドレス0）を使用して整数を格納します。

ここで、255より大きい数値を表現したいとします。もちろん、整数を表すために1バイト以上を使用することもできますが、それが固定数である限り、最終的に、元のスキーマ。

これは、タスクを実行できる別のスキーマですが、おそらく効率的ではありません。

ある種の一意の「数値の終わり」バイトを使用し、前のすべてのバイトを使用して数値を表します。明らかに、この「数値の終わり」バイトは数値表現のどこにも使用することはできませんが、これは（256の代わりに）255を基数とする番号付けシステムを使用して実現できます。

しかし、それは遅く、おそらく非効率的です。低い値でうまく機能し、適切にスケーリングできる、より優れたものが欲しいです。

基本的に、それはUUIDシステムです。再設計することなく、理論的に何年、何千年、何百万年も使用できるように拡張できる、高速に実行できるUUIDシステムを作成できるかどうかを知りたいです。

私が使用したアプローチ：先頭の1ビットの数を数えますn。数値のサイズは2 ^ nバイト（先頭の1ビットを含む）になります。最初の0ビットの後のビットを整数として、このエンコードを使用して数値で表すことができる最大値（プラス1）を2 ^（n-1）バイトで追加します。

したがって、

                  0 = 0b00000000
                   ...
                127 = 0b01111111
                128 = 0b1000000000000000
                   ...
              16511 = 0b1011111111111111
              16512 = 0b11000000000000000000000000000000
                   ...
          536887423 = 0b11011111111111111111111111111111
          536887424 = 0b1110000000000000000000000000000000000000000000000000000000000000
                   ...
1152921505143734399 = 0b1110111111111111111111111111111111111111111111111111111111111111
1152921505143734400 = 0b111100000000000000000000000000000000000000000000 ...

このスキームでは、負でない値を正確に1つの方法で表すことができます。

（同等に、先行する0ビットの数を使用しました。）

あなたがやろうとしていることに基づいた理論はたくさんあります。ユニバーサルコードに関するwikiページをご覧ください。整数のエンコード方式のかなり網羅的なリストがあります（その一部は実際に実際に使用されています）。

データ圧縮では、整数のユニバーサルコードは、正の整数をバイナリコードワードにマッピングするプレフィックスコードです。

または、最初の8バイトを使用して、数値の長さをいくつかの単位（ほとんどの場合はバイト）で格納し、データバイトを配置することもできます。実装は非常に簡単ですが、少数の場合は非効率的です。そして、人類が利用できるすべてのデータドライブを埋めるのに十分な長さの整数をコーディングすることができるでしょう:)

先頭の1と最初の0の数を、ビット単位の数値サイズ（numSize）のサイズ（sizeSize）としましょう。numSizeは、サイズビットを含むバイト単位の数値表現のサイズを示す2進数です。残りのビットは、バイナリの数値（num）です。正の整数スキームの場合、サンプルの数値の例をいくつか示します。

Number              sizeSize  numSize    num
63:                 0 (1)     1 (1)      111111
1048575:            10 (2)    11 (3)     1111 11111111 11111111
1125899906842623:   110 (3)   111 (7)    11 11111111 11111111 11111111 11111111 11111111 11111111
5.19.. e+33:        1110 (4)  1111 (15)  11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111

それはどうですか：1バイトの長さ、次にnバイトの数（最下位バイトが最初）。前の長さが255である限り、長さ+数を繰り返します。

これにより、任意の大きな数が可能になりますが、処理は簡単で、メモリを無駄に消費しません。

なぜ各バイトのうち7ビットを使用し、8番目のビットを使用して、次のバイトがあるかどうかを示すのではないのですか？したがって、1〜127は1バイトで、128は0x80 0x01などで表されます。

UUIDシステムは、有限（しかし大きい）宇宙における有限（しかし大きい）計算能力に基づいています。UUIDの数は、宇宙の粒子の数などの不条理に大きなものと比較した場合でも多くなります。ただし、固定ビットの数に関係なく、UUIDの数は無限大に比べて少ないです。

数値の終わりフラグを表すために0xFFFFを使用する場合の問題は、数値が大きい場合に数値エンコーディングの効率が低下することです。ただし、UUIDスキームによってこの問題がさらに悪化しているようです。256バイトのうち1バイトがスキップされる代わりに、UUIDスペース全体が無駄になりました。（空間ではなく）計算/認識の効率は、理論上のコンピューターに大きく依存します（無限大について話をしている場合は、それが想定されます）。テープと有限状態コントローラーを備えたTMの場合、UUIDスキームを効率的にスケーリングすることは不可能です（基本的に、ポンピングレンマは、固定ビット長のエンドマーカーを超えて効率的に移動できません）。有限状態コントローラーを想定していない場合、これは当てはまらない可能性がありますが、ビットがデコード/認識プロセスのどこに行くかについて考える必要があります。

256バイト中の1バイトよりも効率を上げたい場合は、UUIDスキームに使用する1のビット長を使用できます。これは、非効率の2 ^ bit-lengthのうちの1つです。

ただし、他のエンコードスキームがあることに注意してください。デリミタ付きのバイトエンコーディングは、実装が最も簡単です。

バイト（またはintまたはlong）の配列と、数値の長さを示す長さフィールドを持つことをお勧めします。

これはおおよそJavaのBigIntegerで使用されているアプローチです。これから可能なアドレス空間は巨大です-宇宙のすべての個々の原子に異なるUUIDを与えるのに十分簡単です:-)

特に理由がない限り、直接BigInteger（または他の言語では同等のもの）を使用することをお勧めします。特に大きな数字のホイールを再発明する必要はありません...

まず第一に、私の漠然とした抽象的な質問に素晴らしい答えを提供してくれた皆さんに感謝します。

他の答えを考えた後、考えていた潜在的な答えを投稿したいと思います。質問に対する直接的な回答ではありませんが、関連性があります。

一部の人々が指摘したように、64/128/256ビットサイズの整数を使用すると、UUID用の非常に大きなスペースがすでに得られます。明らかに無限ではありませんが...

おそらく、64ビットでは不十分（またはそれに近い）になるまで、固定サイズのint（たとえば、最初は64ビット）を使用することをお勧めします。次に、UUIDの以前のすべてのインスタンスにそのようなアクセス権があると仮定して、それらすべてを128ビットの整数にアップグレードし、それを整数の固定サイズにします。

システムがそのようなサービスの一時停止/中断を許可し、そのような「再構築」操作が非常にまれに発生する必要があるため、おそらく利点（非常に単純で高速で実装が簡単なシステム）が欠点（以前に割り当てられたすべての整数を再構築する必要がある）を上回ります。新しい整数のビットサイズに変換します）。