開発者ツール · Base64 エンコーダーおよびデコーダー
貼り付けられた Base64 がデコードできない理由: 行の折り返し、改行、スマート クォーテーション
· なぜそれが重要なのか
base64 エンコード
Base64 は輸送中に壊れることはほとんどありません。クリップボード内で壊れてしまいます。この投稿では、無効な文字と長さのエラーを引き起こすコピー＆ペーストのエラーと、それぞれを素早く特定する方法をカタログ化します。
ターミナルでは機能したが、ブラウザでは失敗したキー - 1 つの非表示文字と 2 時間の検索
エンジニアは端末から API キーをコピーして、スクリプトでテストしました。キーはターミナルでは正常に機能しましたが、ブラウザ ツールに貼り付けると無効な文字で失敗しました。 2 時間後、コード、構成、ドキュメントを検索した結果、目に見えない文字が 1 つ見つかりました。エコーによって追加されたか、端末のプロンプト ラインからコピーされたキーの末尾の改行は、Base64 デコーダーを破壊する余分な文字になりました。キーは正しかったです。クリップボードはそうではありませんでした。 Base64 データは、電子的に送信され、チェックサムが行われ、検証された場合に信頼性があります。ほとんどの場合、手動でのコピーと貼り付けの際に壊れます。
ターミナルでの行の折り返し、コマンド出力の末尾の改行、リッチ テキスト エディターでのスマート クオート置換、および異なるアプリケーション間でのコピー アンド ペーストによる隠された Unicode 文字はすべて、実際の問題はコピー方法にあるのに、Base64 が壊れているように見えるエラーを引き起こします。この投稿では、最も一般的な障害をカタログ化し、それぞれを迅速に特定して修正する方法を示します。 Base64 アルファベットは、大文字と小文字、数字、プラス記号、スラッシュ、および埋め込み文字 (等号) で構成されます。 RFC 4648 は特別です。標準の Base64 文字列には、これらの文字と、行が折り返されている場合のオプションの空白のみが含まれます。
端末、電子メール クライアント、および PEM フォーマットからの行の折り返し — 76 列の区切りが一部のデコーダでは問題なく、他のデコーダでは致命的である理由
多くのツールは逸脱を許容します。プラスとスラッシュの代わりにダッシュとアンダースコアを使用した URL セーフなバリアントを受け入れたり、改行を無視したりします。 RFC に従う厳密なデコーダは、予期される文字セット以外のものをすべて拒否し、無効な文字エラーで失敗します。エラー メッセージには通常、問題のある文字の名前が示されるか、文字列をまったくデコードできないことが示されます。電子メール、端末、チャット履歴、または書式設定されたドキュメントから Base64 を貼り付ける場合、目に見えない文字や文字置換が紛れ込み、デコードが失敗することがよくあります。データ自体は問題ありません。クリップボード転送により破損しました。
行の折り返しは、貼り付けられた Base64 エラーの最も一般的な原因であり、最も簡単に修正できるものでもあります。ターミナル ツールは、1 行あたり 76 文字、または場合によっては 80 文字で出力を折り返し、改行を挿入して次の行に続きます。一部の Base64 エンコード ライブラリを含む多くのエンコーダは、MIME 電子メールとの互換性を確保するために、出力を同じ 76 文字境界でラップします。ラップされた Base64 文字列を端末からコピーすると、改行が追加されます。
エコーおよびクリップボード ツールからの末尾の改行 — 余分な文字となる余分なバイト
一部のデコーダーは改行を自動的に受け入れ、無視します。他の人はそれらを無効な文字として拒否します。修正するには、すべての改行と空白を削除します。 Base64 文字列がターミナル内で複数行にわたって折り返されている場合は、すべての行を選択し、エディターにコピーして、すべての改行を削除します。
結果の単一行文字列をコピーし、デコーダに貼り付けます。これは、ペーストが失敗したときに最初に試みることです。エコーおよびクリップボード ユーティリティからの末尾の改行も、もう 1 つの一般的な原因です。コマンド echo $API_KEY は、キーの後に改行を出力します。これはコマンドの標準的な動作です。その出力を直接コピーすると、コピーには改行が含まれます。一部の端末ではコピー時に余分な改行が追加され、一部のクリップボード マネージャーでは改行が保存または複製されます。症状は行折り返しと同じで、Base64 に属さない文字列の末尾に余分な文字が表示されます。
スマート引用符、非改行スペース、およびゼロ幅文字 — リッチテキストエディターがプレーンテキストを書き換える方法
修正も同様に簡単です。デコードを試みる前に、エディターで貼り付けた文字列の端をトリミングします。先頭と末尾の空白、および改行のように見える文字を削除します。文字列が十分に短い場合は、手動で再度入力できますが、長いキーの場合は、慎重に手動でトリミングした方が早いです。スマート引用符、非改行スペース、その他の Unicode 置換は、巧妙な罠です。 Word などのリッチ テキスト エディターは、直線引用符を中引用符に自動的に変換し、3 つのハイフンを全角ダッシュに変換し、特定のスペース シーケンスを非改行スペースに変換します。誰かが Base64 文字列をドキュメントに貼り付け、それを書式設定されたドキュメントからツールにコピーすると、それらの置換が適用されます。
直線の二重引用符 (") は左右の波線のペアになり、どちらも有効な Base64 ではありません。非改行スペース (U+00A0) は通常のスペースと同じに見えますが、文字コードが異なるため、すべてのパーサーによって空白として認識されません。解決策は、最初にプレーン テキスト エディターに貼り付け、書式設定がすべて破棄されます。Word 文書または書式設定されたチャットから貼り付ける場合は、最初にプレーン テキスト エディターまたは HTML に貼り付けます。 textarea を開き、奇妙な文字がないか確認してから、プレーン テキスト バージョンからコピーしてツールで使用します。
切り捨てとパディングの損失 — 文字が欠落していることを通知する長さを法とする4 チェック
切り捨ては、コピーまたは貼り付け中に文字列が切り取られると発生します。非常に長い Base64 文字列は、一部のシステムではクリップボードの制限を超えたり、アプリケーションのバグによりコピーに失敗したりする可能性があります。結果は、不完全な短い文字列になります。 Base64 文字列は、パディング適用後の長さが 4 の倍数でなければなりません。長さが 4 の倍数でない場合、長さは切り捨てられるか破損します。エラー メッセージは通常、文字列の長さが無効であるか、文字が欠落していることを示します。修正するには、元に何がコピーされたかを把握する必要があります。
ソースを再度確認できる場合は、もう一度慎重にコピーしてください。そうでない場合、切り捨ては回復できません。パディングの損失は関連する問題です。数バイトを節約するために、等号を含む Base64 パディングが削除されることがあります。一部のアプリケーションではパディングが省略され、一部のアプリケーションではパディングが必要になります。文字列が元々パディングされており、パディングが失われた場合は、パディングを再度追加します。 Base64 文字列には、全長が 4 の倍数になるように、0、1、または 2 の末尾に等号が必要です。何もなく、長さが 4 の倍数でない場合は、パディングが失われている可能性があります。
うまくいった例: ラップされ切り詰められた文字列を修復する — デコードされるまで段階的にクリーニングします
作業例では、これらの修理を段階的に示しています。コピーされた API キーがエディターに次のように表示されるとします: VGhpcyBpcyBub3QgcmVhbGx5IGEgc2VjcmV0Cg==。まずは問題を特定することから始めます。末尾の Cg== は奇数です。 CG は改行文字 (16 進数 0A) の Base64 であり、余分な == は何かが追加されたことを示しています。末尾の Cg== を削除し、VGhpcyBpcyBub3QgcmVhbGx5IGEgc2VjcmV0 だけを試してください。それはまだ正しくありません。長さは 37 文字であり、4 の倍数ではありません。再度トリミングします: VGhpcyBpcyBub3QgcmVhbGx5IGEgc2VjcmV0 (35 文字、まだ間違っています)。元のソースを確認してください。正しい文字列は、適切なパディングを含む VGhpcyBpcyBub3QgcmVhbGx5IGEgc2VjcmV0 (32 文字) です: VGhpcyBpcyBub3QgcmVhbGx5IGEgc2VjcmV0。 VGhpcyBpcyBub3QgcmVhbGx5IGEgc2VjcmV0= を追加します。
デコーダでテストします。これは、「これは実際には秘密ではありません」とデコードされます。各ステップで、Base64 エンコーダとデコーダを使用して現在の文字列をテストし、特定された問題を修正して、デコードされるまで再度テストします。 Base64 バイト自体の内部の破損は、デコーダでは修復できません。実際に転送中、送信中、または保存中にバイトが破損した場合、Base64 自体はそれを検出できません。 RFC では有効な文字を指定しています。そのセットの外にある文字はすべて、デコーダのジョブでキャッチされます。 Base64 文字の途中で 0 が 1 になるなどのバイト破損は、完全に異なる文字コードを生成し、Base64 だけでは検出できません。
これでカバーされないもの — Base64 自体では検出できない、エンコードされたバイト内の破損
チェックサムまたはデジタル署名は、この種の破損を検出するために使用され、Base64 エンコードの前に元のバイナリ データに対して計算される必要があります。 Base64 文字列をデコードし、その結果がガベージであるか、期待したものと異なる場合、破損はコピー＆ペーストのステップ中ではなく、エンコード前または送信中に発生しました。実際にはこれはまれです。ほとんどの失敗は、上記のようなコピー＆ペーストの問題です。 Base64 のコピー＆ペーストの失敗をデバッグする体系的なアプローチは、潜在的な問題を順番にテストすることです。まず、すべての空白と改行を削除します。次に、先頭と末尾のスペース、およびはみ出した文字をトリミングします。
次に、長さを法 4 でチェックし、必要に応じてパディングを追加します。各バージョンを Base64 エンコーダとデコーダに貼り付けて、デコードされるかどうかを確認します。長さのチェックが失敗した場合は、文字列が切り詰められているかどうかを確認し、元のソースから文字列を取得します。アルファベットのチェックが失敗し、異常な文字が表示された場合は、スマート引用符または Unicode 置換を探して、同等の ASCII 文字に置き換えます。無効な文字を名前で表示するオンライン ツールを使用すると、無効な文字を特定して削除できます。 Base64 エンコーダとデコーダは、すべての無効な文字に対してこれを実行し、どの文字がアルファベットに含まれていないかを正確に示します。
要点: データのせいにする前に長さとアルファベットをチェックする — Base64 エンコーダーとデコーダーが各修復をテストするための高速なローカル場所をどのように提供するか
そのフィードバックを使用して各文字を修正し、文字列がデコードされるまで続行します。予防はデバッグより簡単です。 Base64 文字列が再度必要になることがわかっている場合は、書式を保持する方法で文字列をコピーします。リッチ テキスト ドキュメントに貼り付けないでください。プレーン テキスト ファイル、または置換を行わない指定されたテキスト領域に保存します。誰かがフォーマットされたメッセージで Base64 文字列を送信してきた場合は、コードフォーマットまたはプレーンテキストで再送信するように依頼してください。フォーマットされたソースからコピーする必要がある場合は、まずプレーン テキスト エディターに貼り付け、文字列を使用する前に確認してください。
文字列を入手したら、信頼する前にすぐに Base64 エンコーダーとデコーダーで文字列をテストしてください。失敗した場合は、ソースにアクセスできるうちに新しいコピーを要求できます。文字列が古くなるかソースがなくなるまで待つと、切り捨てや破損を修正することができなくなります。 Base64 エンコーダとデコーダを使用すると、文字列を使用する前にローカルで簡単にテストできる場所が得られます。コピー＆ペーストの失敗がすぐに見つかるように、早期にテストし、頻繁にテストします。