一目で：
JSONの「ノイズ」と「信号対雑音比」
ノイズ量の理論上の上限、逆ポーランド式
情報理論と圧縮技術：文字列とバイト文字列
最高の二分木、FPS / 2.0
ハフマンコーディング
メッセージパック
メッセージパックのハフマンツリー
プレフィックスVSセパレータ
メッセージパックの欠陥、ホスト環境のバグ
シリアライゼーションの限界、2つの基本的な公理
UTF-8極端な圧縮
有理数：可変長型シフト
辞書圧縮方式
尾部切除
ウルトラパックと時空交換の原理
V8エンジンの形而上学（内部で何が起こっているのか）
「 ここではテクノロジーについて話さず、考えているだけです。」
いくつかのナンセンス。
もともと、このpptは同社のFEConf会議で表示されることを意図していたが、年初の新しいコロナウイルスの流行により鳩にこれが与えられた。16XX年の春にロンドン地域で悲惨な疫病が発生し、その後偉大な神ニュートンが家庭で孤立すると二項定理や計算を含む一連の最高の学業成果を生み出したと言われ、これが最初の人間の理論につながりました。物理爆発...
人間の理論物理学は100年近く進歩しておらず、すべてのアプリケーションは前世紀の初めの相対性理論と量子力学の理論に基づいています。そのため、WeiboとMomentsでの「理論的予備緊急」キャンペーンに励まされて、私や他の社会的動物も家庭で孤立した時間を利用して、科学、特にアプリケーションの興味をそそる理論的研究に従事するふりをしようとしました。
私の研究の方向性は、シャノンの情報理論です（ステーションBの進化のセクションから、進化は情報理論に基づいていると言われていますか????）。情報、エントロピー、および生命についての理解を深め、学習を通じて自分自身を減らしたい情報とエントロピーの関係についての情報エントロピーについては、前の記事「情報とエントロピー[パート1]情報に関する生命のフィード」を参照してください。この記事はシリーズの2番目です。トピックは、情報理論における情報圧縮アルゴリズムについてです。1年前に会社のスピーチのために準備されたpptは完全に記事に翻訳され、内容はコンピュータソフトウェアに戻っています。
01
—
JSONノイズ
テーマ：シリアライゼーションの限界を探します。
シリアル化とは何ですか？シリアル化は、多次元データを1次元の線形データに可逆的に変換する一種です。これはエンコード方式です。1次元に変換されるのは、より良い保存と送信のためです。シリアル化の知識については、この記事を参照してください。
情報理論では、「エンコード」は情報をある形式または形式から別の形式に変換するプロセスであると考えています。たとえば、文字エンコードはテキスト形式の情報をバイトコード形式に変換することです。逆に、base64エンコードはバイトコード形式を変換するプロセスです。テキスト形式に変換します。「デコード」は、エンコードの逆のプロセスです。
用語の説明：コーディング
そうすると、JSONはよく使われるシリアル化形式です。JSONは、実数、文字列、ブール値、nullの4つの基本タイプと、リストと辞書の2つの複合タイプをサポートします。非常に使いやすく、もちろん欠点があります。JSON 「信号対雑音比」は非常に低いですが、どれほどかを言うのは難しいです。
情報理論の見解によれば、データ=情報+ノイズ。テキストベースのシリアル化形式でのこの理論の公式は、JSON = type bit + information bitです。情報ビットは、jsonに含まれる有効な情報量であり、タイプビットは、二重引用符、コンマ、角かっこ、中かっこなど、残りのすべてのノイズです。
jsonのノイズは圧縮可能であり、一部の最適化を一目で確認できます。Key-Valueペアの「key」の二重引用符を削除する場合は、trueとfalseを文字tとfに置き換えます。あいまいさを生み出します。
よりハイエンドなゲームプレイがあります。jsonのすべての括弧を逆ポーランド式で置き換えます。また、音量を下げる効果的な方法でもあります。
さらに、実数型は小数点文字の形式で格納されるため、多くのノイズが発生するだけでなく、変換の時間が長くなります。
注意深く見ると、jsonに多くの冗長データがあり、継続的に圧縮できますが、この圧縮の限界はどこにありますか？制限がある必要があります。jsonを無限に圧縮することはできません。
02
—
データ圧縮に制限はありますか？
スペインのゴンザレスという老人が、テキストベースのjson圧縮アルゴリズムを設計しました。これは、深くネストされたjsonを55％に圧縮できると言われています。たとえば、次のようなjsonがあります。
{
"type": "world",
"name": "earth",
"children": [
{
"type": "continent",
"name": "America",
"children": [
{
"type": "country",
"name": "Chile",
"children": [
{
"type": "commune",
"name": "Antofagasta"
}
]
}
]
},
{
"type": "continent",
"name": "Europe"
}
]
}
この文字列は、「圧縮アルゴリズム」を通じて取得されます。
type|world|name|earth|children|continent|America|country|Chile|commune|Antofagasta|Europe^^^$0|1|2|3|4|@$0|5|2|6|4|@$0|7|2|8|4|@$0|9|2|A]]]]]|$0|5|2|B]]]
そして、圧縮率は驚くべきものであり、後で説明するMessagePackをも上回りますが、慎重に調査した結果、実際にはjsonを使用して圧縮するという習慣を使用していることがわかりました。同様に、リスト内のオブジェクトの属性は制限されており、ゴンザレス兄弟は、名前、ID、子など、頻繁に出現する同じキー名を収集して使用するため、カップリングが減少し、ボリュームが減少します。
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/TypedArray
TypedArrayの概要
しかし、習慣を使用するこの種の圧縮アルゴリズムは、習慣が変わるため、結局持続するわけではないため、推奨されません。特定の状況、または固定されたチームでは、このアルゴリズムは依然として有用です。
しかし、今日この形式を使用し、明日より良い圧縮アルゴリズムを考え、新しい形式に変更すること、これがどれほど優れているか、どのように数量化するか、そして上限が何であるかは、情報理論の懸念事項であるとは言えません。この制限を見つけるには、情報の「基本的な」形式であるバイナリ形式を検討する必要があります。バイナリ形式に基づくテキスト形式ではありません。テキスト形式の改善と最適化が情報圧縮の限界に達することは決してありません。したがって、シリアライゼーションフォーマットの進化における主な矛盾は、テキストフォーマットとデジタルフォーマットです。
要するに、テキスト形式は時代の発展における「怠惰な」移行形式です。テキスト形式のシンプルで拡張可能な特性により、多くの初期のシリアル化形式、http、さらにはipプロトコルファミリーでもテキスト形式を保持しています。特に、インターネットトラフィックの90％以上を占めるhttp / 1.Xプロトコル。http/ 1.1のヘッダーと本文（json）はすべてテキスト形式であるため、httpは時間の観点から、httpテキストのコンパイルと分析でパフォーマンスのボトルネックに遭遇しました時間の浪費、スペースに関しては、httpヘッダーの多数のフィールドがスペースを浪費します。
03
—
情報理論と圧縮技術
しかし、http / 2.0（以降、h2と呼びます）以降、この不健康な雰囲気は変化し始めており、h2は頭と体に異なる圧縮アルゴリズムを使用して効率を向上させています。静的ヘッダーの場合、h2は固定長エンコーディングを使用して圧縮します。つまり、content-type：text / htmlなどの一般的に使用される各ヘッダーに固定番号を割り当てます。動的ヘッドの場合、ヘッドと値の値をカスタマイズできます。h2は、ASCII可変長エンコーディングであるハフマンエンコーディングを使用します。
これまでのところ、httpのヘッド部分は完全にデジタル化されており、ボディ部分はユーザー定義であり、jsonのテキスト形式を保持していますが、w3cはjsonの代替を使用することを誰にでも呼びかけていますが、どの代替について直接の声明はありません。バイナリシリアル化形式を自由に選択してください。
注：バイナリ形式は「デジタル形式」に似ているため、テキスト形式をバイナリ形式に変更するプロセスは「デジタル化」と呼ばれます。
04
—
最適な二分木
w3cはハフマン符号化バイナリシリアル化形式の使用を推奨しているため、ハフマンのデータ構造、つまり最適なバイナリツリーを理解する必要があります。
コードのセットを設計する最も直接的な方法は、固定長エンコーディングです。つまり、ASCIIエンコーディング固定長8ビットのように、各タイプ/文字の長さが固定されています。図に示すように、固定長エンコーディングで5種類の文字を設計するには、少なくとも3ビットのエンコーディング長が必要です。図では、深さ3の完全なバイナリツリーの各リーフが文字ですが、残りの3つのリーフは使用されていないため無駄になっています。
この時点で、最も頻繁に使用される文字の長さは3から1に圧縮できます。これの意味は、意味のないコードの数を犠牲にして、意味のあるコードの長さを節約することです。使用頻度が最も高い文字に1ビットのコーディング長を割り当てた後、最適なバイナリツリーが生成されます。
05
—
ハフマンコーディング
この「最適なバイナリツリーコーディング」は、実際には「ハフマンコーディング」の同義語です。ハフマン符号化は可変長符号化です。つまり、各符号化オブジェクトの長さは異なりますが、配置や組み合わせによって曖昧さが生じることはありません。ただし、固定長エンコーディングから可変長エンコーディングに切り替えるコストは、ボリュームの増加（葉の全体的な深さの損失）です。したがって、すべてのオブジェクトの使用頻度が一定である（または頻度が予測できない）場合は、固定長コーディングを使用する方が効率的です。つまり、「特定の周囲と最大の正方形領域」を意味します。
もちろん、ハフマンツリー自体の生成アルゴリズムは、リーフからツリーのルートまでのさまざまなオブジェクトの使用頻度に基づいているため、バイナリツリーが最適であり、アルゴリズムの詳細は省略されています。
<つづく>
次のエピソードのプレビュー：「シリアル化の限界を探す」