エンコーディングは、両端が同意する場合にのみ役に立ちます。受信者が使い慣れたアルファベットを必要とする場合、ペイロードを人が入力する必要がある場合、または周囲の構文が特定の文字を特別に扱う場合、最小の表現が必ずしも最良の選択であるとは限りません。受信プロトコルから始めます。
Hex は冗長ですが検査は簡単です
16 進数では、各バイトを 2 桁として書き込みます。バイトシーケンス FF 00 41 は次のようになります。 ff0041。すべてのペアには目に見えるバイト境界があり、ファイルの署名、チェックサム、プロトコル パケットを検査するときに役立ちます。文字数は 2 倍になりますが、小さなアルファベットなので通常はログやデバッグ ツールに簡単に収まります。
Base64 サイズと相互運用性のバランスをとる
Base64 は 4 文字で 3 バイトを表します。これは、テキストベースの形式内のバイナリ フィールドによく適合します。標準 Base64 にはプラスとスラッシュが含まれます。 Base64URL は、プロトコルで別のアルファベットが必要な場合に、これらの文字を置き換えます。パディングと空白のルールについては依然として合意が必要です。どちらの形式でも、デコードされたバイトがテキストであるか、画像であるか、圧縮されたコンテンツであるかは受信者にわかりません。
パーセントエンコーディングは URL コンポーネントに属します
パーセントエンコーディングは、エスケープされたバイトを次のように書き込みます。 %HH。これは、単に Base64 の一括代替品ではありません。コンポーネントはどの文字をエスケープする必要があるかを決定し、テキストは最初に UTF-8 としてエンコードされる必要があります。スラッシュでパス セグメントを区切ることができ、疑問符でクエリを開始することもできます。 URL 全体を 1 つの不透明なコンポーネントとして扱うと、その意味が変わります。
console.log(encodeURIComponent('a+b / 中文'));
// a%2Bb%20%2F%20%E4%B8%AD%E6%96%87Base85 には正確なバリアントが必要です
多くの Base85 スキームは 5 文字で 4 バイトを表しますが、アルファベット、区切り文字、特殊なケースが異なります。 ASCII85 と Z85 は互換性があると想定できません。 Z85 ではブロック サイズ要件も課されます。高密度のアルファベットには句読点が含まれている可能性があり、周囲の形式で再度エスケープする必要があるため、見かけ上の利点が減少します。
これらのバイトエンコーディングを、整数 255 を基数間で変換することと混同しないでください。ファイルはゼロバイトで始めることができますが、整数表現では先頭のゼロが破棄される場合があります。可逆ファイル コーデックでは、長さと先頭のゼロを保持する方法を定義する必要があります。
バイト検査には 16 進数、相互運用可能なバイナリ トランスポートには指定された Base64 バリアント、URL には URL コンポーネント エンコーディング、および両当事者が同じコントラクトを実装する場合にのみ特殊なスキームを使用します。エスケープと圧縮後のエンドツーエンドのサイズを比較します。 RFC 4648 標準の Base16、Base32、および Base64 ファミリと、それらの個別のアルファベットを定義します。