アスキー85

Ascii85はBase85とも呼ばれ、btoaユーティリティ用に Paul E. Rutter が開発したバイナリからテキストへのエンコード形式です。5 つのASCII文字を使用して4 バイトのバイナリ データを表すことにより(ASCII 文字あたり 8 ビットと仮定すると、エンコードされたサイズは元のサイズより1 ⁄ 4大きくなります)、 4 つの文字を使用して 3 バイトのデータを表すuuencodeやBase64よりも効率的です( ASCII 文字あたり 8 ビットと仮定すると、 1 ⁄ 3増加します)。

近年の主な用途としては、AdobeのPostScriptやPortable Document Formatファイル形式、 Gitで使用されるバイナリファイルのパッチエンコーディングなどがあります。^[1]

バイナリからテキストへのエンコードの基本的な必要性は、英語の人間が読めるテキストのみを伝送するように設計された既存の通信プロトコルを介して任意のバイナリ データを通信する必要性から生じます。これらの通信プロトコルは 7 ビット セーフのみ (およびその範囲内で特定の ASCII 制御コードを避ける) であり、特定の最大間隔で改行が必要であり、空白が維持されない場合があります。したがって、データの伝送に「安全」に使用できるのは、 印刷可能な94 のASCII 文字のみです。

85 はn ⁵ ≥ 256 ⁴となるnの最小の整数値です。したがって、少なくとも 85 個の異なるシンボルが利用可能であれば、4 バイトの任意のシーケンスを 5 つのシンボルとしてエンコードできます。(基数-85 の 5 つの数字は、0 から 4,437,053,124 までの整数を表すことができ、これは 4,294,967,296 個のすべての可能な 4 バイト シーケンスを表すのに十分です。)

エンコード時に、4 バイトの各グループは、最上位バイトが先頭の 32 ビットの 2 進数として扱われます (Ascii85 はビッグ エンディアン規則を使用します)。これは、85 で繰り返し除算して剰余をとることで、5 つの 85 基数桁に変換されます。次に、各桁 (ここでも最上位バイトが先頭) に 33 を加えて ASCII 印刷可能文字としてエンコードされ、ASCII 文字 33 ( !) から 117 ( u) が得られます。

すべてゼロのデータは非常に一般的であるため、データ圧縮のために例外が設けられ、すべてゼロのグループはzではなく単一の文字としてエンコードされます!!!!!。

2 ³² − 1より大きい値にデコードされる文字のグループ( としてエンコードs8W-!) は、グループの中央にある文字と同様に、デコード エラーを引き起こしますz。文字間の空白は無視され、行の長さの制限に合わせてどこにでも発生する可能性があります。

元の仕様では、4 バイトの倍数のストリームのみをエンコードできます。

エンコードされたデータには、左山括弧、バックスラッシュ、一重引用符と二重引用符&など、多くのプログラミング言語や一部のテキストベースのプロトコルで特別な意味を持つ文字が含まれている場合があります。Z85やRFC 1924などの他のbase85エンコードは、 ソースコード内で安全になるように設計されています。^[2]<\'"

オリジナルの btoa プログラムは常に完全なグループをエンコードし (必要に応じてソースをパディング)、プレフィックス行に "xbtoa Begin"、サフィックス行に "xbtoa End"、その後にオリジナルのファイルの長さ (10 進数と16 進数)、3 つの 32 ビットチェックサムが続きます。デコーダーは、グループがどれだけパディングされているかを確認するためにファイルの長さを使用する必要があります。btoa エンコードの最初の提案では、ASCII スペース文字から "t" までのエンコード アルファベットが使用されていましたが、これは "一部のメーラーで問題が発生する (末尾の空白が削除される)" を回避するために "!" から "u" までのエンコード アルファベットに置き換えられました。^[3]このプログラムでは、すべてゼロのグループを表す特別な " " 短縮形も導入されました。バージョン 4.2 では、すべて ASCIIスペース文字のグループ(0x20202020) に対するz" " 例外が追加されました。y

「 ZMODEM Pack-7 エンコーディング」は、4 オクテットのグループを 5 つの印刷可能な ASCII 文字のグループにエンコードします。これは Ascii85 と類似の、またはおそらく同じ方法です。ZMODEMプログラムが7 ビット データ チャネルを介して事前圧縮された 8 ビット データ ファイルを送信する場合、「ZMODEM Pack-7 エンコーディング」が使用されます。^[4]

Adobe は、基本的な btoa エンコードを採用しましたが、若干の変更を加え、Ascii85 という名前を付けました。使用される文字は、ASCII 文字 33 ( !) から 117 ( u) まで (85 進数の 0 から 84 を表す) と文字z(32 ビットの 0 値を表す特別なケース) で、空白は無視されます。Adobe は、~>Ascii85 エンコードされた文字列の終わりを示すために区切り文字 " " を使用し、最後のグループを切り捨てることで長さを表します。ソース バイトの最後のブロックに含まれるバイト数が 4 バイト未満の場合、エンコード前にブロックに最大 3 つの null バイトが埋め込まれます。エンコード後、埋め込みとして追加されたバイトと同じ数のバイトが出力の末尾から削除されます。

デコード時には逆のことが行われます。最後のブロックは Ascii85 文字で 5 バイトにパディングされu、パディングとして追加されたバイト数は出力の末尾から省略されます (例を参照)。

パディングは任意ではありません。バイナリからベース 64 に変換すると、ビットが再グループ化されるだけで、ビットや順序は変更されません (バイナリの上位ビットは、ベース 64 表現の下位ビットには影響しません)。バイナリ数をベース 85 (85 は2 の累乗ではありません) に変換すると、上位ビットは下位のベース 85 桁に影響し、その逆も同様です。エンコード時にバイナリの下位ビット (ゼロ ビット) をパディングし、uデコード時にベース 85 の上位ビット (s) をパディングすると、上位ビットが保持されます (バイナリのゼロ パディングによって十分な余地が確保されるため、小さな加算はトラップされ、上位ビットへの「繰り上がり」はありません)。

Ascii85 でエンコードされたブロックでは、5 文字のブロックの途中を含め、どこにでも空白文字や改行文字が存在する可能性がありますが、それらは黙って無視される必要があります。

Adobe の仕様ではy例外はサポートされていません。

トーマス・ホッブスの 『リヴァイアサン』からの引用：

人間は、理性だけでなく、精神の欲望であるこの特異な情熱によって他の動物と区別され、知識の継続的かつ飽くなき生成における喜びの持続によって、いかなる肉欲の喜びの短期的な激しさも超えるのです。

最初に US-ASCII を使用してエンコードされている場合は、次のように Ascii85 で再エンコードできます。

9jqo^BlbD-BleB1DJ+*+F(f,q/0JhKF<GL>Cj@.4Gp$d7F!,L7@<6@)/0JDEF<G%<+EV:2F!,O<
DJ+*.@<*K0@<6L(Df-\0Ec5e;DffZ(EZee.Bl.9pF"AGXBPCsi+DGm>@3BB/F*&OCAfu2/AKYi(
DIb:@FD,*)+C]U=@3BN#EcYf8ATD3s@q?d$AftVqCh[NqF<G:8+EV:.+Cf>-FD5W8ARlolDIal(
DId<j@<?3r@:F%a+D58'ATD4$Bl@l3De:,-DJs`8ARoFb/0JMK@qB4^F!,R<AKZ&-DfTqBG%G>u
D.RTpAKYo'+CT/5+Cei#DII?(E,9)oF*2M7/c

最後の 4 タプルは不完全なので、3 つのゼロ バイトを埋め込む必要があります。

3 バイトのパディングを追加する必要があったため、最後の 3 つの文字「YkO」は出力から省略されます。

デコードは逆に行われますが、最後の 5 タプルには 'u' 文字が埋め込まれます。

入力には 3 つの 'u' バイトを埋め込む必要があったため、出力の最後の 3 バイトは無視され、元のピリオドが残ります。

入力文には 4 つの連続するゼロ バイトが含まれていないため、例では 'z' の略語の使用は示されません。

Ascii85 エンコーディングは、 Base64よりもオーバーヘッドが少なく、7 ビットおよび 8 ビットのMIMEと互換性があります。

Ascii85 の潜在的な互換性の問題の 1 つは、使用されている文字の一部がXMLやSGMLなどのマークアップ言語で重要になることです。これらのドキュメントに ascii85 データを含めるには、引用符、山括弧、およびアンパサンドをエスケープする必要がある場合があります。

1996 年 4 月 1 日に発行された、情報提供のRFC 1924: Robert Elz による「IPv6 アドレスのコンパクトな表現」では、エイプリルフールのジョークとしてIPv6アドレスの 85 進数エンコードが提案されています。これは、85 個の ASCII 文字の異なるセットを提案し、128 ビットの数値を 4 つの 32 ビット グループに分割するのではなく、1 つの 20 桁の 85 進数に変換して (内部の空白は許可されません)、すべての演算を 128 ビットの数値に対して実行することを提案している点で、上記のスキームと異なります。

提案されている文字セットは、順に、0– 9、A– Z、a– z、そして 23 文字です!#$%&()*+-;<=>?@^_`{|}~。表現可能な最大のアドレス 2 ¹²⁸ −1 = 74×85 ¹⁹  + 53×85 ¹⁸  + 5×85 ¹⁷  + ... は としてエンコードされます=r54lj&NUUO~Hi%c2ym0。

この文字セットでは、文字 が除外されるため、 JSON文字列"',./:[\] での使用に適しています(と ではエスケープが必要です)。ただし、特に XML を含む SGML ベースのプロトコルでは、文字列のエスケープが必要になる場合があります ( 、およびに対応するため)。 "\<>&

• ベース32
• ベース36
• ベース64
• さまざまなエンコードアルゴリズムを比較するためのバイナリからテキストへのエンコード
• PostScript 標準エンコーディング

• ベースE91
• PostScript 言語リファレンス (Adobe) - ASCII85Encode フィルターを参照してください