開発者ツール · Base64 エンコーダーおよびデコーダー
Base64 の短い歴史: uuencode と PEM から今日のアルファベットまで
· 背景
base64 エンコード
Base64 のアルファベットは、1980 年代の輸送問題の化石記録です。この投稿では、uuencode から Privacy-Enhanced Mail、MIME および RFC 4648 までの系譜をたどり、それぞれの設計上の選択について説明します。
なぜアルファベットは単純に 0–63 という明らかな順序ではないのか — 40 年前に遡る疑問
Base64 は標準として完全に形成されていませんでした。アルファベット (A-Z、a-z、0-9、+、/) は、何十年にもわたるエンコード実験の化石記録であり、それぞれが同じ問題、つまり 1970 年代と 1980 年代の電子メール、USENET、Unix ツールに生き残ったバイナリ データをテキストとして表現する方法を解決しようと試みています。物語は uuencode にまたがります。 Unix、1993 のプライバシー強化メール (RFC 1421)、1996 の MIME (RFC 2045)、そして最後に 2006 の RFC 4648 ですべてのバリアントが統合されています。
この歴史を理解すると、なぜ特定の文字がアルファベットに含まれるのか、そしてなぜ RFC が特定の選択肢を実装者に残しているのかが説明されます。 Unix-to-Unix エンコードの略である uuencode は、Unix 上の 7 ビットのトランスポート問題を解決する最初のツールでした。 1980 で作成され、各 3 バイト (24 ビット) を 64 文字のアルファベットの 4 文字にエンコードしました。 uuencode のアルファベットは ASCII 32 (スペース) から ASCII 95 (アンダースコアおよびその他の句読点) までであり、これらの文字はどの端末でも印刷できるため選択されました。リポジトリには、現在実装されているアルファベットが示されていますが、誰がその順序を選択したか、またはすべてのキャラクターが勝った理由についてのアーカイブ証拠は含まれていません。したがって、見出しは絞り込まれています。現在のレイアウトは正確に検査できますが、動機と日付については、ここには含まれていない主要な歴史的文書が必要です。
アルファベットが歴史的なものに見える理由 — このリポジトリが文書化していない境界
ただし、エンコード文字としてのスペースには問題があります。テキスト エディターやメール システムでは末尾のスペースが削除され、出力が破損します。このアルファベットは理想的ではありませんでしたが、Unix 間のファイル転送には十分に機能しました。 Privacy-Enhanced Mail (RFC 1421、1992) は、暗号化された電子メールを標準化する初期の試みでした。これには、独自の Base64 エンコーディング (MIME 用の RFC 1341、RFC 1421 は仕様としては先行していましたが、採用が遅れていました) が含まれていました。
RFC 1421 Base64 では、アルファベット A ～ Z、a ～ z、0-9、+、/ (最新の Base64 アルファベット) が使用され、行は 64 文字で折り返されていました。このアルファベットはスペースやその他の問題のある文字を避けました。すべての文字は明確に印刷可能であり、制御コードや各国の文字セットのバリエーションと混同されません。 64 文字の行の長さは 1980 年代の紙端末の幅と一致しており、可読性の実用的な妥協点でした。 Uuencode は周囲の歴史に属していますが、このツールはアルファベットの読み取りも書き込みも行いません。これを互換性のある Base64 として扱うと、フォーマット エラーになります。ここでの有用な比較は、バイトを印刷可能な文字で表現するという共通の問題に限定されます。
実装の証拠ではなく、コンテキストとしての以前のエンコーディング
RFC 1421 は暗号化電子メールには広く採用されませんでしたが、Base64 アルファベットは残りました。 MIME (MultiPurpose Internet Mail Extensions、RFC 2045、1996) は RFC 1421 Base64 アルファベットを採用しましたが、行の折り返しを 64 文字から 76 文字に変更しました。その理由は技術的なものではなく歴史的なものでした。PEM (Privacy-Enhanced Mail) ブロックは 64 文字であり、MIME は自動解析における PEM との混同を避けるためにわずかに異なる制限を選択しました。
MIME Base64 は電子メール添付ファイルの標準となり、現在最も広く使用されている Base64 のバリアントです。 RFC 2045 では、他の Content-Transfer-Encoding 値 (7 ビット、8 ビット、quoted-printable) も定義されており、コンテンツ タイプに基づいたメール システム オプションが提供されています。アルファベットの選択により、ASCII と EBCDIC (IBM メインフレームの文字エンコーディング) の間で異なる文字が回避されます。文字 A ～ Z、a ～ z、0-9、+、および / は、どちらのエンコードでも同じです。 PEM スタイルのブロックは、ラップされたエンコードされたマテリアルをラベルで囲むため、認識できます。 ToolAcre は、これらのラベルが削除された後、抽出された Base64 ボディを処理できます。どのアーカイブ仕様が特定の規則を最初に使用したかを特定することはできません。また、この記事はソース ツリーがその質問に答えているとは考えていません。
起源物語を主張しない、現代の観察可能な形式としての PEM スタイルの鎧
左括弧や右括弧などの文字は、ASCII と EBCDIC で異なるため、除外されました。これは、メインフレームから Unix へのデータ転送が一般的だった 1980 年代から 1990 年代初期には重要でした。また、アルファベットでは、C 文字列およびシェル構文で特別な意味を持つバックスラッシュ、一重引用符、および二重引用符も避けられます。 Base64 文字列は、ほぼすべての文字をエスケープすることなく、C プログラムまたはシェル スクリプトに埋め込むことができます。
RFC 3548 (2006) は、Base64、base32、および Base16 エンコーディングを統合しました。 MIME、PEM、およびその他のアプリケーションはすべて同様の概念を使用していますが、パディング ルールとアルファベットが異なることに注意しました。 RFC 4648 (2006、RFC 3548 とともに発行) が現在の標準であり、それぞれのテスト ベクトルを持つ 5 つのエンコーディング ファミリを定義しています。 RFC には、どの文書でどのエンコーディングが定義されているか、バージョン間で何が変更されたか、およびその選択が行われた理由などの履歴も記載されています。エンコーダーの 76 文字ラッピング オプションとデコーダーの空白削除により、MIME 形式のサンプルがテスト可能になります。これらの実装事実は、メール標準の完全な歴史を証明するものではありません。これらは、読者がパネルとテストで直接再現できる最新の互換性動作を示しています。
標準履歴を再構築せずに、エンコーダ オプションとして MIME スタイルのラッピングを使用
ほとんどの開発者は、RFC 4648 で Base64 と Base64url のみを目にします。古いバリアントを実装する必要がある人のために、その履歴が文書化されています。 Base64url (RFC 4648 セクション 5) は、URL 予約文字を避けるために、プラスをダッシュに、スラッシュをアンダースコアに置き換えます。 + と / を含む Base64 文字列は、URL 内でパーセント エンコードする必要があります (%2B および %2F)。 Base64url はそれを回避します。
JWT (JSON Web トークン) はパディングなしで Base64url を使用します。一部のアプリケーションでは、パディング付きのbase64urlを使用します。 RFC では両方のバリアントが定義されています。どちらを選択するかはアプリケーション次第です。この差異が、JWT デコーダーと電子メール Base64 デコーダーが同じ入力文字列に対して異なる出力を生成する可能性がある理由です (一方は Base64url を予期し、もう一方は Base64 を予期します)。アルファベット、パディング ルール、行の折り返しはすべて、実際のシステムの実際的な制約から生まれました。移植性は、各シンボルの検証された伝記ではなく、トランスポート アルファベットの制約として扱うのが最適です。文字と数字は一般的なテキスト システム全体で視覚的に見慣れたままですが、URL セーフ モードでは最後の句読点が異なります。正確な歴史的選択理論的根拠は、主要な証拠がない限り省略されています。
移植性は設計上の制約であり、個々のキャラクターの選択を検証したものではありません
64 文字セットは、エンコーディング間での表現性を考慮して選択されました。アルファベットは RFC 1341 および 1421 と MIME によって修正されました。パディング ルールは 3 バイト アライメントに基づいています。行の折り返しは電子メールの転送制限から来ていました。この履歴を無視した実装では、新しいエンコーディングが発明されたり、エッジ ケースが忘れられたりする可能性があります。 RFC 4648 テスト ベクトル (foobar は Zm9vYmFy を生成します) は、実装が標準に準拠していることを検証する方法です。
Base85 (一部のコンテキストで使用される) のような最新の代替手段は存在しますが、歴史的な勢いと十分に優れているため、依然として Base64 が主流です。 Base64 は最もコンパクトなエンコーディングではありません (base85 と Base91 の方が密度が高い) が、シンプルで汎用性があり、実証済みです。確実に言えるのは、現在のアルファベットのペアです。標準はプラスとスラッシュで終わります。 URL セーフではハイフンとアンダースコアが置き換えられます。パディングとラッピングは別のオプションです。テストは両方のモードと不足しているパディングをカバーし、推定された時間軸ではなく現在の動作の再現可能な証拠を提供します。
現在の標準アルファベットと URL セーフ アルファベットについてリポジトリが証明していること
33 パーセントのサイズ オーバーヘッドは、ほとんどの用途に許容されます。アルファベットは実装間で安定しています。 RFC は、逸脱は偶然の誤解ではなく、通常は意図的なもの (パディングの省略や空白の処理など) であることを十分に明確にしています。
Base64 の歴史を理解すると、なぜそのように見えるのかが説明されます。プラス文字とスラッシュ文字は、さまざまな文字エンコーディングでのあいまいさを避けるために意図的に選択されました。パディング ルールは、3 バイトのグループ化に基づいています。 Base85 と Ascii85 は異なるグループ サイズとアルファベットを使用するため、実装の範囲外です。それらに言及したからといって、このページが彼らにとってのコンバーターになるわけではありません。それらの密度や履歴を比較するには、このモジュールでレビューした Base64 ファイル以外のソースとテスト ベクトルが必要になります。
要点: すべての文字には理由があって選ばれています — Base64 エンコーダーとデコーダーがその結果得られた標準アルファベットをどのように実装するか
行の折り返しは電子メールからのものです。それぞれの決定は、実際のシステムに関する実際の問題を解決するために行われました。現在、Base64 は履歴が重要ではないコンテキスト (JWT、API、データ URI) で主に使用されていますが、アルファベットとパディングのルールは RFC 4648 を通じて MIME と PEM から継承されます。
RFC を一度読んで、Base64 エンコーダおよびデコーダ ツールでテスト文字列をエンコードすると、現在の標準がその歴史的なルーツにつながります。結果として得られる標準アルファベットは、入力がインデックス 62 または 63 に達するたびに表示されます。これらの位置を生成するサンプルを使用し、URL セーフ モードを切り替えて、変更された句読点のみを比較します。この実験は、その発明に関する根拠のない話に依存することなく、今日のフォーマットを実証しています。