よくある Base64 の接頭辞：先頭の文字でファイルを見分ける

接頭辞の一覧表

各行は、その形式の実際のマジックバイトをエンコードして確認しました。「固定の接頭辞」は、その形式で常に変わらない部分です。その後に続く文字はファイルの残りの内容によって変わります。

いくつかの行には補足が必要です。

• RIFF はコンテナです。形式名はバイト 8〜11 にあり、バイト 9〜11 が 13〜16 文字目にエンコードされます。WebP（EBP）なら RUJQ、WAV（AVE）なら QVZF、AVI（VI ）なら Vkkg です。形式名の最初の 1 文字はファイルサイズと同じ 3 バイトのグループに入るため、固定の文字にはなりません。
• zlib には単一の接頭辞がありません。2 バイト目に圧縮レベルが記録されるからです。Python の zlib が書き出す場合、デフォルトのレベルなら eJ、レベル 7〜9 なら eN、2〜5 なら eF、0 と 1 なら eA になります。
• JSON が eyJ で始まるのは、最初の 2 文字が空白なしの {" の場合だけです。{ "a": 1 } は eyAi で始まり、整形された { と改行は ewo で始まり、配列の [ は W で始まります。
• DER の構造は SEQUENCE タグ 30 で始まり、これは必ず M になります。長さが 2 バイト（30 82）なら MII になり、次の文字は長さによって変わります。RSA 2048 の公開鍵は MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA、一般的な証明書は MIIC、MIID、MIIE です。短い構造は 1 バイトの長さを使い、Ed25519 の秘密鍵は MC4C、P-256 の公開鍵は MFkw で始まります。
• SSH 公開鍵は 4 バイトのビッグエンディアンの長さで始まるので、ブロブは AAAA で始まります。その後の文字が鍵の種類を表し、AAAAC3NzaC1lZDI1NTE5 は ssh-ed25519、AAAAB3NzaC1yc2E は ssh-rsa、AAAAE2VjZHNh は ecdsa です。SSH 以外では、A が続くのは単にゼロバイトが続いているという意味です。
• MP3 のうち ID3 タグのないファイルは、いきなりフレームヘッダーから始まります。その同期ビット FF Fx によって先頭が // になり、たとえば FF FB 90 は //uQ です。
• Base64URL では + と / が置き換わるので、JPEG の接頭辞は _9j_ になります。表の他の接頭辞はどちらの文字も含まないので、どちらのアルファベットでも同じ見た目です。

接頭辞が変わらない理由

Base64 は 3 バイト単位で処理します。3 バイトのグループはそれぞれちょうど 4 文字になり、その 4 文字はその 3 バイトだけで決まります。ファイルの後ろの内容が前に影響することはありません。つまり、ある形式が常に同じ 3 バイトで始まるなら、その Base64 は常に同じ 4 文字で始まります。

bytes:   FF       D8       FF
bits:    11111111 11011000 11111111
groups:  111111 111101 100011 111111
index:   63     61     35     63
chars:   /      9      j      /

固定のマジックが 3 バイトの倍数でない場合、最後のグループには既知のビットとファイルの残りのビットが混ざります。5 バイトの %PDF- で考えてみましょう。最初の 3 バイトで固定の 4 文字（JVBE）、次の 2 バイトでさらに 2 文字（Ri）が決まり、7 文字目は - の下位 4 ビットとバージョン番号の上位 2 ビットが混ざります。数字はすべて 00 というビットで始まるので、実際にはこの文字は常に 0 です。JVBERi0 の後にはバージョンが現れます。JVBERi0xLjQ は %PDF-1.4、JVBERi0xLjc は %PDF-1.7、JVBERi0yLjA は %PDF-2.0 です。

PNG のシグネチャは 8 バイトなので、固定の文字は 10 文字です。11 文字目はシグネチャの最後のバイトと IHDR チャンクの長さの最初のバイトが混ざりますが、後者は常に 0 なので iVBORw0KGgo が成り立ちます。どの PNG もその後に IHDR チャンクが続くため、実際の PNG はさらに長い iVBORw0KGgoAAAANSUhEUg という接頭辞を共有しています。

接頭辞がずれる場合

接頭辞が使えるのは、マジックバイトがオフセット 0、3、6…にある場合だけです。先頭に 1 バイト加えるとすべてのグループがずれ、文字がまったく変わってしまいます。

余分なバイトが 3 つならアラインメントが戻り、おなじみの接頭辞が 4 文字後ろに現れます。接頭辞がずれたり消えたりするよくある原因は次のとおりです。

• バイトオーダーマーク（BOM）。 BOM 付きの UTF-8 テキストは 77u/（EF BB BF）で始まります。BOM は 3 バイトなので、その後の JSON は 77u/eyJ… のように引き続き eyJ が見えます。BOM 付きの UTF-16 テキストは //4 か //5（リトルエンディアン）、または /v8（ビッグエンディアン）で始まります。
• UTF-16 のテキスト。 UTF-16LE で保存したテキストは ASCII 文字ごとにゼロバイトが入るため、A が大量に現れます。Hello は SABlAGwAbABvAA== になります。PowerShell の -EncodedCommand はこの形です。PowerShell デコーダーか Base64 から UTF-16 へを使ってください。
• 圧縮や暗号化。 gzip で圧縮された PNG は H4sI で始まり、暗号化されたファイルには見分けのつく接頭辞がまったくありません。
• Data URI。 data:image/png;base64, はヘッダーで、Base64 はカンマの後から始まります。Data URI パーサーで分割できます。
• 改行や空白。 バイト列はずれませんが、文字列が改行や引用符で始まっていると、startswith による接頭辞の検索は失敗します。先にトリムするか、Base64 の修復ツールに通してください。

コードで接頭辞を確認する

先頭の文字を文字列として照合することもできますが、デコードしたバイト列を比較するほうが間違いが起きにくくなります。マジックナンバーは各形式の仕様からそのまま取れますし、どの文字が固定かを考える必要もありません。先頭の 12 文字だけをデコードすれば最初の 9 バイトが得られ、ほとんどのシグネチャにはこれで足ります。

import base64

SIGNATURES = {
    b"\x89PNG\r\n\x1a\n": "png",
    b"\xff\xd8\xff": "jpeg",
    b"%PDF-": "pdf",
    b"PK\x03\x04": "zip",
    b"\x1f\x8b": "gzip",
}

def sniff(b64: str) -> str:
    head = base64.b64decode(b64.strip()[:12])
    for magic, name in SIGNATURES.items():
        if head.startswith(magic):
            return name
    return "unknown"

print(sniff("iVBORw0KGgoAAAANSUhEUgAAAAEAAAAB"))  # png
print(sniff("JVBERi0xLjcKJcfsj6IK"))              # pdf

Base64 をファイルに変換ツールは、もっと長いリストで同じ確認を行い、ブラウザが表示できる形式ならプレビューも表示します。6 ビットのグループがどのように文字に対応するかは、Base64 の仕組みとアルファベット表をご覧ください。

よくある質問