Base64デコーダー

Base64デコーダーは、Base64でエンコードされた入力から元のデータを復元する無料ツールです。

Base64エンコードとは？なぜ使われる？

Base64は、バイナリデータを限られた種類の印字可能な文字で表現する方法です。テキストは安全に扱えても、任意のバイト列を確実に処理できないシステムでデータをやり取りするために使われます。

標準Base64では、英大文字と英小文字、数字、プラス記号、スラッシュを使用します。末尾にはパディングとして等号が付く場合があります。入力の3バイトがBase64の4文字に変換されるため、エンコード後のデータサイズは大きくなります。

Base64は暗号化ではなく、エンコードです。エンコードされた値を入手した人は、パスワードや秘密鍵なしでデコードできます。機密性はないため、パスワード、APIキー、個人情報の安全な保管場所としてBase64を使わないでください。

Base64デコーダーの使い方は？

Base64の値をツールに貼り付けてデコードし、Base64デコード結果欄に表示された内容を確認してください。変換処理には、サーバー上でPHPのbase64_decode関数を使用します。

入力データはHTTPS経由でサーバーへ送信され、保存されません。処理はブラウザ内だけで完結せず、サーバー上で行われます。外部サービスへの送信が許可されていない機密情報は入力しないでください。

Base64が保持するのは意味ではなく、バイト列です。数字、空白、句読点も、元のバイト列の一部としてそのまま扱われます。アクセント付き文字や非ラテン文字もエンコードできますが、デコード後のバイト列は正しい文字エンコーディングで解釈する必要があります。現代のWebコンテンツでは通常、UTF-8が使われます。

具体例と形式の選び方

標準Base64の簡単な例を見てみましょう。

入力: SGVsbG8=

出力: Hello

末尾の等号はパディングです。Base64の4文字ブロックを完成させるためのもので、デコード結果に文字が1つ追加されるわけではありません。

一般的な文字セットには、次の2種類があります。

• 標準Base64では+と/を使用します。MIMEメール、データURI、多くのJSONベースのAPIで一般的です。
• Base64urlでは、代わりに-と_を使用します。+や/が扱いにくいURL、クエリパラメーター、トークン向けの形式です。パディングは省略されることがよくあります。

値を生成したシステムが指定する形式を選んでください。標準デコーダーでは、文字セットをあらかじめ変換しない限り、Base64urlの入力を誤って解釈したり拒否したりすることがあります。逆の変換が必要な場合は、Base64エンコーダーを使用してください。画像としてエンコードされたデータなら、生のバイナリをテキストとして表示するよりも、Base64を画像に変換するツールのほうが便利です。

Base64はどんな場面で使われる？

Base64は、バイナリデータをテキスト中心の形式で受け渡す必要がある場面でよく使われます。値が単独で記載されることもあれば、大きな文書の一部として含まれることもあります。

• データURIでは、多くの場合data:image/png;base64,のような接頭辞に続けて、小さな画像、フォント、その他のリソースをHTMLやCSSに埋め込みます。
• JSONにはバイナリ値の型がないため、ファイル、証明書、暗号関連データなどをBase64文字列として格納する場合があります。
• MIMEメールでは、添付ファイルや、プレーンテキストとして安全に転送できないメッセージ部分にBase64を使用します。
• クエリ文字列やWebトークンでは、URL内で特別な意味を持つ文字を避けるため、Base64urlが使われることがあります。
• 設定ファイルや環境変数には、周囲のシステムが印字可能な文字を前提としているため、Base64が含まれる場合があります。

エンコードされたように見える国際化ドメイン名には、別のデコーダーが必要です。xn--で始まるドメインラベルはBase64ではなく、Punycodeを使用しています。Base64デコーダーに入力しても、意図されたUnicodeドメイン名は復元できません。

Base64をデコードできない、または文字化けするのはなぜ？

Base64のデコードに失敗したり、読めない結果が表示されたりする主な原因は、形式の違い、入力の欠損、二重エンコード、または元のデータがテキストではなくバイナリであることです。

• 文字セットが違う: -や_を含むBase64urlを標準Base64として扱った場合、またはその逆の場合に起こります。
• パディングがない、または壊れている: 最後のブロックが不完全になることがあります。パディングの省略を受け付けるデコーダーもありますが、文字数を4で割った余りが1になる入力は、有効なBase64を構成できません。
• 二重にエンコードされている: 1回目のデコード後にも、Base64らしい文字列が表示されます。生成元が意図的にデータを2回エンコードしている場合は、もう一度デコードする必要があります。
• 出力がバイナリデータである: 画像、PDF、圧縮アーカイブ、暗号化されたバイト列では正常な結果です。これらをテキストとして開くと、記号や置換文字が表示されます。
• 文字エンコーディングが違う: 正しくデコードされたバイト列でも、誤った文字エンコーディングで表示すると文字化けします。たとえば、UTF-8のデータをWindows-1252として解釈すると、アクセント付き文字が文字化けすることがあります。
• 前後に余分な内容がある: データURIの接頭辞、引用符、JSONのエスケープ、URLのパーセントエンコーディングなどが含まれている場合は、先に取り除く必要があります。

PHPのbase64_decodeは、デフォルトでは非厳格モードで動作し、標準の文字セットに含まれない文字を破棄することがあります。この動作によってMIME形式の入力に含まれる改行を受け付けられる一方、コピー時のミスが明確なエラーとして報告されず、見過ごされる可能性もあります。想定外の結果になった場合は、元の形式と照合し、入力値を1文字ずつ確認してください。

よくある質問

Base64は大文字と小文字を区別する？

はい。Base64の文字セットでは、英大文字と英小文字がそれぞれ異なる値を表します。表記をそろえるために大文字と小文字を変更すると、デコード後のバイト列が壊れます。

Base64デコーダーでJWTをデコードできる？

JSON Web Tokenには通常、ピリオドで区切られたBase64url形式のセクションが含まれています。各セクションを個別に処理し、省略されたパディングを補う必要がある場合もあります。ペイロードを読めても、トークンの署名が検証されたことにはならず、内容が真正であることも証明できません。

Base64のデコード結果にウイルスや不正なファイルが含まれることはある？

はい。Base64は、実行可能ファイル、スクリプト、不正な文書を含む、あらゆるバイト列を表現できます。デコードしただけで内容が実行されることはありませんが、出所不明の結果を保存したり開いたりするのは危険な場合があります。バイナリ出力を扱う前に、想定されるファイル形式と入手元を確認してください。

デコード結果にヌル文字が含まれるのはなぜ？

ヌルバイトは、バイナリ形式やUTF-16でエンコードされたテキストに現れることがあります。UTF-16では、多くのラテン文字がゼロバイトと対になっています。元データがテキストとされている場合は、ヌル文字を削除するのではなく、文字エンコーディングを確認してください。削除するとデータが壊れる可能性があります。

Base64に決まったファイル拡張子はある？

いいえ。Base64はファイル形式ではなくデータの表現方法なので、必須の拡張子はありません。結果がPNG、PDF、ZIPアーカイブ、テキストファイル、または別の形式かどうかは、デコード後のバイト列によって決まります。

最後に確認すること

エンコードされた値だけをコピーしたか、標準Base64とBase64urlのどちらを使用しているか、大文字と小文字を元のまま保持しているかを確認してください。結果が読めない場合は、テキストとして表示するのではなく、ファイルとして開くべきデータかどうかを確認します。正常にデコードできた値でも、安全または機密であるとは限りません。