Base64をデコードできない原因と対処法

Base64をデコードしようとしても、エラーになったり、文字化けしたり、期待したファイルとして開けなかったりすることがあります。多くの場合、Base64そのものが壊れているというより、余分な文字、改行、Base64URL形式、Data URLの扱い、デコード後の文字コードが原因です。

この記事の要点

Base64文字列をすぐに確認したい方へ

標準Base64、Base64URL、Data URLをブラウザ内で安全に変換できます。

Base64変換ツールを使う

Base64をデコードできない主な症状

Base64のデコードでよくある症状は、次のようなものです。

まずは、Base64の文字列がどの形式なのか、どこからコピーしたものなのかを確認します。APIレスポンス、ログ、HTML、Data URL、URLパラメータなど、コピー元によって混ざりやすい文字が違います。

まず確認するチェックリスト

Base64をデコードできないときは、次の順番で確認すると原因を見つけやすくなります。

確認項目見るポイントよくある例
コピー漏れ途中で文字列が切れていないか長いBase64を一部だけコピーしている
余分な空白前後に空白や改行がないかメールやログからコピーした文字列
パディング末尾の = が欠けていないかSGVsbG8SGVsbG8=
Base64URL-_ が使われていないかURL内で使われるBase64
Data URLdata:image/png;base64, を含んでいないか画像をBase64化した文字列
文字コードデコード後をUTF-8で読んでよいかShift_JIS由来の日本語データ

余分な空白・改行・コピー漏れを確認する

Base64文字列は長くなりやすいため、コピー時に途中で切れたり、前後に空白が入ったりすることがあります。メールやログでは、一定の長さで改行されている場合もあります。

たとえば、次のような文字列は見た目にはBase64に見えても、余分な空白や改行が原因でツールによってはエラーになることがあります。

SGVsbG8g
V29ybGQ=

この場合は、改行を取り除いて次のように扱います。

SGVsbG8gV29ybGQ=

ただし、すべての改行が不要とは限りません。MIME形式やメールの仕様では、Base64が一定の長さで改行されることがあります。通常のデコードでは改行を無視できる場合もありますが、ツールや入力欄が厳密な形式を求める場合は整形が必要です。

末尾の「=」が足りない場合

Base64では、文字列の末尾に = または == が付くことがあります。これはパディングと呼ばれる調整用の文字です。

たとえば、次のようなBase64文字列があります。

44GT44KT44Gr44Gh44Gv

これはUTF-8で「こんにちは」を表すBase64です。末尾に必ず = が付くわけではありませんが、データによっては = が必要になります。

コピー元によっては、URLやフォームの処理で末尾の = が消えてしまうことがあります。デコードできない場合は、コピー元の完全な文字列と見比べて、末尾が欠けていないか確認してください。

Base64URL形式かどうか確認する

Base64には、URLの中で扱いやすいようにしたBase64URLという形式があります。

通常のBase64では、次の文字が使われます。

+
/
=

一方、Base64URLでは次のように置き換えられることがあります。

通常のBase64Base64URL
+-
/_
=省略されることがある

そのため、-_ が含まれている場合は、通常のBase64ではなくBase64URLの可能性があります。通常のBase64としてデコードできない場合は、Base64URL対応の設定やツールを使って確認します。

特にJWT、URLパラメータ、APIトークンの一部ではBase64URL形式が使われることがあります。

Data URLの先頭部分を確認する

画像やファイルをBase64にした場合、次のようなData URL形式になっていることがあります。

data:image/png;base64,iVBORw0KGgo...

この場合、実際のBase64部分はカンマの後ろです。

iVBORw0KGgo...

data:image/png;base64, まで含めて通常のBase64デコード欄に貼り付けると、ツールによってはエラーになることがあります。Data URLに対応していない場合は、カンマ以降のBase64部分だけを取り出してデコードします。

同じ考え方で、JPEGなら次のような形式になります。

data:image/jpeg;base64,/9j/4AAQSkZJRg...

この場合も、カンマ以降の /9j/4AAQSkZJRg... がBase64本体です。

デコード後に文字化けする場合

Base64のデコードに成功しても、日本語が文字化けすることがあります。これはBase64の問題ではなく、デコード後のバイト列をどの文字コードで読むかの問題です。

たとえば、UTF-8で作られた日本語データはUTF-8として読む必要があります。Shift_JISで作られたデータをUTF-8として読むと、文字化けしたり、正しく表示できなかったりします。

よくある判断の目安は次の通りです。

データの出どころ優先して確認する文字コード
Webページ、JSON、APIUTF-8
古いCSV、Windows系業務システムShift_JIS、Windows-31J
メール本文ISO-2022-JP、UTF-8など
海外サービスUTF-8

Base64はあくまでバイト列をテキストで表すための形式です。デコード後の内容が文字列なのか、画像なのか、PDFなのか、どの文字コードなのかを合わせて確認する必要があります。

よくある入力例と直し方

入力例起きること確認する点
SGVsbG8g V29ybGQ=空白が混ざっている空白を削除してから確認
SGVsbG8gV29ybGQ末尾のパディング不足の可能性元データと見比べる
SGVsbG8-V29ybGQ_Base64URL形式の可能性-_ の扱いを確認
data:image/png;base64,iVBORw0KGgo...Data URL全体を貼っているカンマ以降だけを使う
読めない文字が出る文字コード違いの可能性UTF-8、Shift_JISなどを切り替える

ツールで確認する方法

Base64エンコード・デコード変換ツールを使うと、文字列やファイルのBase64をブラウザ内で確認できます。

  1. Base64文字列を入力欄へ貼り付けます。
  2. 余分な空白、改行、Data URLの先頭部分が含まれていないか確認します。
  3. Base64URL形式の場合は、Base64URL対応の設定を確認します。
  4. デコード後に文字化けする場合は、元データの文字コードを確認します。
  5. 画像やファイルの場合は、文字列としてではなくファイルとして扱う必要があるか確認します。

入力内容はブラウザ内で処理されるため、機密性の高いデータや個人情報を扱う場合でも、外部サーバーへ送信しないツールを選ぶことが大切です。

よくある質問

Base64をデコードできない一番多い原因は何ですか?

コピー漏れ、余分な空白や改行、Base64URL形式の混在、Data URLの先頭部分を含めているケースが多いです。まずは入力形式を確認してください。

Base64URLは普通のBase64としてデコードできますか?

そのままでは失敗することがあります。Base64URLでは + の代わりに -/ の代わりに _ が使われ、末尾の = が省略される場合があります。

Data URLはどこからデコードすればよいですか?

data:image/png;base64, のようなData URLでは、実際のBase64部分はカンマ以降です。通常のBase64として扱う場合は、カンマより後ろだけを取り出します。

デコード後に文字化けするのはなぜですか?

Base64のデコード自体は成功していても、デコード後のバイト列を読み取る文字コードが違うと文字化けします。UTF-8、Shift_JIS、Windows-31Jなど、元データの文字コードを確認してください。

Base64は暗号化ですか?

Base64は暗号化ではありません。デコードすれば元のデータに戻せるため、パスワードや個人情報を隠す目的には向いていません。