開発者ツール · Base64 エンコーダーおよびデコーダー
Base64、hex、base32: バイトをテキストとして書き込む 3 つの方法の比較
· 背景
base64 エンコード
Hex、base32、Base64 は、サイズ、可読性、安全性の異なるトレードオフを伴いながら、同じ問題を解決します。この記事では、密度、大文字と小文字の区別、URL の安全性、人的エラーに関してそれらを比較します。
l、1、I、O によりタイプミスされた API キー - hex では発生しなかった具体的な可読性の障害
バイトをテキストとして表す一般的な方法は、16 進数、base32、base64 の 3 つです。それらはすべて同じ問題 (印刷可能な ASCII で任意のバイトを表現する) を解決しますが、サイズ、可読性、およびエラー耐性のトレードオフが異なります。 16 進数は 1 バイトあたり 2 文字 (F3 A2 B1 ...) であるため、16 バイトは 32 文字になります。 Base32 は 1 バイトあたり 1.6 文字 (3 バイトあたり約 5 文字) であるため、16 バイトは 26 文字になります。
Base64 は 1 バイトあたり 1.33 文字 (正確には 3 バイトあたり 4 文字) なので、16 バイトは 24 文字以下になります。ファイル サイズが重要な場合は、base64 が最もコンパクトです。人間による転写が重要な場合は、hex と Base32 の方が安全です。読みやすさの違いは、値を入力、コピー、または読み上げるときに重要です。 Hex では、0-9 および a ～ f (ほとんどのコンテキストでは大文字と小文字が区別されません) が使用されます。機械向けに最適化された表現は人間にとって扱いにくい場合があるため、転写チャネルによって決定が変わります。 Base64 では大文字と小文字が区別され、2 つの句読点記号が使用されます。 hex は、より小さな視覚的語彙を使用します。ここでの実装では、人的エラー率ではなく正確な文字列をテストするため、人為的に作成された確率は付加されません。
密度: 2×、1.6×、および 1.33× — 各エンコーディングでバイトごとに必要な文字数とその理由
Base32 は A ～ Z および 2 ～ 7 を使用し、紙上で混同しやすい 0、1、O、および I を回避します。 Base64 は、大文字と小文字の両方を含む A-Z、a-z、0-9、+、および /, を使用するため、大文字と小文字が区別され、類似した数字が混合されます (0 と O、1 と I と小文字の l)。 16 進数の API キーは f3a2b1e4 となる場合があります。同じバイトが、base64 では 86KrvE== (パディングあり)、base32 では 6VEV7FI= (パディングあり) になる可能性があります。
ユーザーが値を手で入力する必要がある場合は、base64 よりも 16 進数または Base32 の方が安全です。 URL 内の予約文字は重要です。 Hex と Base32 は URL として安全です。どちらも英数字のみを使用します (16 進数では 0-9 も使用され、base32 では 2-7 も使用されます)。 Base64 では、URL で予約されているプラスとスラッシュを使用します (プラスはフォームエンコードされたデータ内のスペースを表し、スラッシュはパス区切り文字です)。 Base64 密度は、出力シンボルあたり 6 有効ビットと 4 文字ブロックへのパディングから直接決まります。 16 進数は 1 シンボルあたり 4 ビットを伝送し、1 バイトあたり 2 文字になります。 Base32 は、このリポジトリが出力を検証するためのアルファベットもエンコーダも提供していないため、比較コンテキストとしてのみ説明されています。
ビット幅からの密度 - Base32 を比較コンテキストとして扱う、正確な Base64 および 16 進算術
URL パラメーター内の Base64 文字列はパーセント エンコードする必要があり (プラスは %2B、スラッシュは %2F になります)、出現するたびに 4 の追加文字が追加されます。 Base64url (RFC 4648 セクション 5) では、プラスがダッシュに、スラッシュがアンダースコアに置き換えられ、パーセント エンコーディングなしで URL セーフになります。 URL で Base64 を使用するほとんどの API は、実際には Base64url を使用しますが、その区別がドキュメントで明示されていないことがよくあります。
TOTP シークレット (認証アプリで使用されるコード) は通常、base32 として配布されます。 TOTP 登録画面には、base64 または 16 進数の同じバイトよりも入力と転写が容易なため、base32 シークレットが表示されます。 SHA ハッシュ ダイジェストは、従来の形式であり、16 進数では大文字と小文字が区別されないため、タイプミスが起こりにくいため、多くの場合 16 進数で表示されます。 1 つの文字の大文字と小文字を変更するとインデックスが変更されるため、値を読み上げたり再入力したりする場合には、大文字と小文字の区別が重要になります。 ToolAcre は大文字と小文字を正確に保持し、人間が転写エラーを起こしたことを知らずに、結果として生じるさまざまなバイトをデコードします。表現自体にはチェックサムがありません。
予約文字と URL の安全性 - + と / バイトの場所、および Base32 と Hex が問題を回避する方法
JWT は Base64url を使用します。ファイルのチェックサムは 16 進数または Base64 である場合があります。どちらも一般的です。この選択は歴史的な慣習によるものであり、技術的な必要性によるものではありません。エラー耐性は微妙ですが重要な違いです。 Base32 は、数字 0、1、8、および 9 (文字のように見える) を回避し、転記エラーを減らします。 Base64 にはすべての数字が含まれるため、1 は曖昧になります (文字の I、小文字の l、または数字の 1 ですか?)。
16 進数はさらにエラーが発生しやすくなります。0 は O のように見え、l は 1 のように見えます。入力または印刷出力から読み取る必要があるチェックサムは、base32 の方が安全です。コンピューターから直接貼り付けられた API キーは、どの形式でも安全です。可読性は人間の目が関係する場合にのみ重要です。バイトは同じですが、エンコーディングが異なります: 16 バイト シーケンス [0xf3, 0xa2, 0xb1, ...] は f3a2b1 になります... 標準 Base64 のプラスとスラッシュはチャネルを意識した処理が必要です。 URL セーフ モードでは、これらはハイフンとアンダースコアに置き換えられます。 Hex では、数字と文字のみを使用してこれらの区切り文字を回避します。 Base32 の規則はさまざまであるため、この記事では、リポジトリが実装またはテストしていない安全性のプロパティを約束することは避けます。
動作した例: 3 つのエンコーディングすべてで同じ 16 バイト — 長さの比較と視覚的検査
、base32 の 6VEV7FI=...、base64 の 86KrvE==。これらの文字列はどれも交換可能ではありません。 f3a2b1... を受信するアプリケーションは 16 進数を期待しており、16 進数として解析しようとします。アプリケーションが 16 進数を期待している場合、86KrvE== の受信は失敗します。エンコード形式はデータの契約の一部です。送信者と受信者は、どのエンコードが使用されるかについて合意する必要があります。パディングも別の違いです。
16 進数はパディングを使用しません (4 バイトは常に 8 16 進数文字であり、例外はありません)。 Base32 と Base64 は両方とも、等号パディングを使用して出力を複数の文字に揃えます (base32 の場合は 8、base64 の場合は 4)。パディングは数学的に必要です。すべての n バイト入力で確定的な文字数が生成されることが保証されます。パディングのルールはさまざまです。アプリケーションによってはパディングが必要な場合もあれば、パディングを省略できる場合もあります。作業された比較では、固定バイト シーケンスが使用され、Base64 と 16 進数が機械的に計算されます。 Base32 の長さは 5 ビットのグループ化から議論できますが、正確な Base32 テキスト値はレビューされた実装で生成されていないため省略されています。長さの計算と出力の検証は区別されます。
ここで、それぞれは従来通りです。ハッシュは 16 進数、TOTP シークレットは Base32、JWT とデータ: URI は Base64 です。
Base32 または Base64 値をパディングなしで貼り付ける場合、デコーダーは実装に応じてそれを受け入れるか拒否することがあります。暗号化キーとトークンはエンコーディングの違いを示します。
HMAC キーは 32 バイトで、64 16 進文字、52 Base32 文字 (パディングあり)、または 44 Base64 文字 (パディングあり) になります。キーを配布するときは、エンコーディングを文書化する必要があります。ドキュメントにはキーが 44 Base64 文字であると記載されているのに、52 文字が返される場合は、何かが間違っています。慣習は読者を導くことはできますが、適切であることを証明するものではありません。ハッシュ ダイジェストは通常 16 進数で表示されますが、JWT セグメントは Base64url を使用します。正しい選択は、チャネル ルール、ユーザーが値をコピーするかどうか、および別のプロトコルがその表現をすでに修正しているかどうかによって決まります。
これでカバーされないもの — Base58、base85、およびチェックサムエンコーディング
短い Base64 エンコーディングにより、文字制限のあるシステム (QR コードや URL など) にトークンを適合させることが若干容易になります。値のエンコーディングの選択は、その値が由来するエコシステムによって設定されます。 Web API では、多くの場合、base64url が使用されます。暗号化ドキュメントでは、多くの場合 16 進数が使用されます。認証アプリはbase32を使用します。システムを構築するときは、エンコーディングを 1 つ選択し、明確に文書化して、それを使い続けてください。
エンコーディング (base64 または Base32 など) を混在させると混乱が生じます。デバッグ時の最初のステップは、値がどのエンコーディングを使用しているかを特定することです。 Base64 エンコーダおよびデコーダ ツールは、複数の方法でデコードを試み、どれが適切な出力を生成するかを確認することで役立ちます。一般的には、エンコードを行わない方が優れています。 Base64 は、RAW ストレージとしては最もコンパクトです。 Hex は暗号学者にとって最もよく知られており、小さなシーケンスであれば人間が最も読みやすいものです。 Base58、Base85、およびチェックサムエンコーディングは異なるトレードオフを生み、ToolAcre の Base64 パネルには存在しません。それらのアルファベット、曖昧性ルール、チェックサムは、このツールのテストされた動作から推定するのではなく、専用のソースと実装を使用して評価する必要があります。
要点: チャネルとリーダーのエンコーディングを選択する — Base64 エンコーダーとデコーダーが同じ製品の SHA ハッシュ計算機と並行して、ブラウザーで Base64 のケースをどのようにカバーするか
Base32 は、転記エラーに対する耐性が最も優れています。選択は、値がどこに存在するか、どのように共有されるか、どのシステムがそれを使用するかなどのコンテキストによって異なります。
トレードオフを理解すると、API またはシステムを設計するときに賢明な選択を行うことができます。 Base64 エンコーダおよびデコーダ ツールは、Base64 エンコードを示します。これを hex または Base32 ツールと併用すると、3 つのフォーマットすべてで同じバイトを表示し、そのサイズと可読性の違いを理解できます。 Base64 の場合は、サンプルをエンコードし、正確な UTF-8 バイトと出力文字数を記録し、標準の句読点と URL セーフな句読点をテストします。ダイジェスト作業には、別の SHA パネルを使用します。これらの操作を区別しておくことで、エンコードの選択がハッシュや整合性保護と間違われるのを防ぎます。