Base64 用語集

A〜C

Alphabet（アルファベット）

エンコード方式が出力に使う文字の集合を、インデックス順に並べたものです。標準の Base64 は A-Z、a-z、0-9、+、/ を使うので、A は 0、/ は 63 を表します。アルファベット表 をご覧ください。

ASN.1

Abstract Syntax Notation One の略で、データ構造を記述するための言語です。X.509 証明書や鍵、多くの通信プロトコルで使われています。ASN.1 が定義するのは構造で、バイト列を決めるのは DER などのエンコード規則です。

Base16

16進数の RFC 4648 での呼び名です。各バイトが 0-9 A-F の 2 文字になり、サイズは 2 倍になります。Base16 ツール で試せます。

Base32

32 文字（RFC 4648 では A-Z と 2-7）を使うエンコード方式で、5 バイトを 8 文字に変換するため、入力より 60% 大きくなります。大文字と小文字を区別しないアルファベットなので、TOTP のシークレットや DNS 名に向いています。Base32 エンコーダー で試せます。

Base45

RFC 9285 で定義されており、2 バイトを、QR コードの英数字モードで格納できる 45 文字から 3 文字に変換します。EU デジタル COVID 証明書で使われていました。Base45 エンコーダー で試せます。

Base58

Bitcoin で使われる 58 文字のアルファベットで、Base64 から 0、O、I、l、+、/ を除いたものです。入力全体を 1 つの大きな数として変換し、先頭のゼロバイトはそれぞれ 1 になります。Base58 エンコーダー で試せます。

Base58Check

先頭にバージョンバイト、末尾に 4 バイトのチェックサムを付けた Base58 です。チェックサムは SHA-256 を 2 回適用した結果の先頭 4 バイトです。旧形式の Bitcoin アドレスや WIF 形式の秘密鍵で使われています。Base58Check ツール をご覧ください。

Base64

3 バイトごとに 64 文字のアルファベットから 4 文字を書き出し、末尾を = でパディングするバイナリ・テキスト変換方式です。出力は入力より約 33% 大きくなります。まずは エンコーダー と デコーダー を試すか、Base64 の仕組み を読んでみてください。

Base64URL

RFC 4648 の 5 章で定義された、+ と / の代わりに - と _ を使う Base64 です。パディングは省略されることが多く、JWT や URL で使われます。Base64 と Base64URL の違い と Base64URL エンコーダー をご覧ください。

Base85

4 バイトを 5 文字で表すエンコード方式の総称で、オーバーヘッドは 25% です。Ascii85（Adobe 製で PDF や PostScript で使用）、Z85（ZeroMQ）、git が使う RFC 1924 のアルファベットが代表的なバリアントです。Base85 ツール で試せます。

Base91

Joachim Henke が考案した basE91 は、印字可能な ASCII 文字を 91 種使い、2 文字ごとに 13 または 14 ビットを詰め込みます。そのためオーバーヘッドは約 14%〜23% と、ここで挙げた中で最も小さくなります。その代わり、アルファベットにはダブルクォートをはじめ多くの記号が含まれます。Base91 ツール で試せます。

Basic Auth

HTTP の Basic 認証（RFC 7617）は、user:password を Base64 にして Authorization ヘッダーで送ります。Aladdin:open sesame なら Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== になります。ヘッダーを見た人は誰でもデコードできるため、HTTPS が必須です。Basic Auth ジェネレーター と デコーダー で作成・読み取りができます。

Binary-to-text encoding（バイナリ・テキスト変換）

任意のバイト列を印字可能な文字だけで表す方式の総称です。これにより、メール、JSON、URL のようにテキスト向けに作られたシステムでもデータが壊れずに通ります。16進数、Base32、Base64、Base85、uuencode、quoted-printable はいずれもバイナリ・テキスト変換方式です。Base64 と 16進数・Base32・Base58・Base85 の比較 で比べられます。

BOM

バイトオーダーマーク（Byte Order Mark）の略で、テキストファイルの先頭に置かれる文字 U+FEFF です。UTF-8 では EF BB BF（Base64 では 77u/）、UTF-16LE では FF FE になります。BOM を想定していないデコーダーでは、 や見えない余計な文字として表示されます。

Canonical encoding（正規形のエンコード）

あるデータに対して唯一「正しい」とされるエンコード結果です。Base64 では、パディング直前の未使用ビットが 0 であることが求められます（RFC 4648 の 3.5 節）。SGk/Pg== は正規形です。SGk/Ph== も寛容なデコーダーでは同じバイト列にデコードされますが、正規形ではありません。

Charset（文字コード）

UTF-8、UTF-16LE、Windows-1252 のように、テキストとバイト列を対応付ける文字エンコーディングです。Base64 が保存するのはバイト列なので、Base64 をテキストにデコードするには、そのテキストがどの文字コードで保存されたかを知る必要があります。推測を誤ると Café のような文字化けが起きます。Base64 からテキストへの変換 ツールでは文字コードを切り替えられます。

CRLF

キャリッジリターンとラインフィード、つまりバイト 0D 0A です。MIME では Base64 の行間に CRLF が必要ですが、Unix のツールは通常 LF（0A）だけを出力します。寛容なデコーダーはどちらも無視し、厳格なデコーダーはどちらもエラーにします。

CSP nonce

Content-Security-Policy ヘッダー（script-src 'nonce-…'）に含めるランダムな値で、同じ nonce 属性を持つインラインスクリプトだけを実行可能にします。Base64 で書かれ、レスポンスごとに新しく生成する必要があり、少なくとも 128 ビットの乱数を含めるべきです。CSP nonce ジェネレーター で生成できます。

D〜J

Data URI

データの場所を指すのではなく、データそのものを運ぶ URL で、RFC 2397 で定義されています。例：data:image/png;base64,iVBORw0KGgo…。HTML や CSS に小さな画像やアイコンを埋め込むのに便利です。Data URI ジェネレーター、パーサー、Data URI のパフォーマンス をご覧ください。

Deflate

ZIP、gzip、zlib、PNG の中で使われている圧縮アルゴリズム（RFC 1951）です。「raw deflate」は、ヘッダーやチェックサムで包まれていない圧縮ストリームそのものを指します。zlib・deflate ツール で圧縮とエンコードができます。

DER

Distinguished Encoding Rules の略で、ITU-T X.690 で定義された ASN.1 構造の厳格なバイナリエンコード規則です。証明書や鍵は DER のバイト列です。DER 構造はたいてい 30（SEQUENCE）で始まるため、PEM の本体は M、多くの場合 MII で始まります。

gzip

deflate で圧縮したデータを 10 バイトのヘッダーと CRC-32 チェックサムで包むファイル形式（RFC 1952）です。先頭がバイト 1F 8B なので、gzip を Base64 にすると H4sI で始まります。圧縮には gzip と Base64、元に戻すには gzip Base64 のデコード を使ってください。

Hex（16進数）

各バイトを 0-9 と a-f の 2 桁で書く方式で、たとえば Hello は 48 65 6c 6c 6f になります。1 バイトずつ読みやすい反面、サイズは入力の 2 倍です。Base64 から 16進数 と 16進数から Base64 で変換できます。

JWE

JSON Web Encryption（RFC 7516）。暗号化されたトークンで、コンパクト形式ではヘッダー、暗号化された鍵、初期化ベクトル、暗号文、認証タグの 5 つの Base64URL パートで構成されます。JWS と違い、鍵がなければ中身を読めません。

JWS

JSON Web Signature（RFC 7515）。ヘッダー、ペイロード、署名の 3 つの Base64URL パートからなる署名付きメッセージです。ペイロードは誰でも読めます。署名が証明するのは、内容が改ざんされていないことだけです。

JWT

JSON Web Token（RFC 7519）。JWS または JWE の中に入れて運ぶ、JSON 形式のクレームの集合です。目にする JWT のほとんどは eyJ で始まる JWS トークンです。JWT デコーダー でデコード、JWT エンコーダー で作成でき、JWT と Base64 で詳しく解説しています。

L〜Q

Line wrapping（行の折り返し）

長い Base64 出力に改行を挿入することです。MIME は 76 文字以内、PEM はちょうど 64 文字で折り返します。GNU の base64 はデフォルトで 76 文字（-w 0 で無効）、openssl base64 は 64 文字（-A で無効）で折り返します。MIME エンコーダー なら自動で折り返してくれます。

Magic number（マジックナンバー）

ファイルの先頭にあって形式を識別する固定のバイト列で、PDF なら %PDF-、PNG なら 89 50 4E 47 です。Base64 は 3 バイトずつエンコードするため、マジックナンバーは見分けやすい Base64 の接頭辞になります。よくある Base64 の接頭辞 と Base64 からファイルへの変換 をご覧ください。

MIME

Multipurpose Internet Mail Extensions（RFC 2045〜2049）。メールで添付ファイルや非 ASCII テキストを扱えるようにする規格です。Content-Transfer-Encoding の base64 によって、テキストのみのメッセージの中で添付ファイルが運ばれます。メールと Base64 と EML デコーダー をご覧ください。

Padding（パディング）

Base64 の末尾にある = で、最後の 4 文字グループを埋めるためのものです。1 バイト余れば ==、2 バイト余れば = になります。省略する形式もあります。パディングの解説 をお読みください。

PEM

Privacy-Enhanced Mail の略で、もともとはセキュアなメールの規格（RFC 1421）でした。現在この名前は、その規格で使われていた鍵や証明書のテキスト形式を指します。DER のバイト列を Base64 にし、64 文字で折り返して -----BEGIN CERTIFICATE----- 行と -----END CERTIFICATE----- 行で挟んだものです（RFC 7468）。証明書デコーダー で中身を確認できます。

Quoted-printable

MIME のもう 1 つの転送エンコーディングです。印字可能な ASCII はそのまま残し、それ以外のバイトを = と 2 桁の 16進数で書くため、UTF-8 の Café は Caf=C3=A9 になります。ほぼ ASCII のテキストには効率的ですが、バイナリには無駄が多くなります。quoted-printable ツール で試せます。

R〜Z

Radix-64

OpenPGP の ASCII アーマーの呼び名です。標準の Base64 に、= で始まり CRC-24 を Base64 で表したチェックサム行を任意で加えたものです。Base64 の規格 をご覧ください。

SRI

Subresource Integrity の略で、ダウンロードしたスクリプトやスタイルシートを integrity 属性のハッシュと照合するブラウザの機能です。値はアルゴリズム名と Base64 のダイジェストで sha384-… のように書きます。対応アルゴリズムは SHA-256、SHA-384、SHA-512 です。SRI ハッシュジェネレーター で値を生成できます。

uuencode

Unix-to-Unix encoding の略で、MIME より古いバイナリ・テキスト変換形式です。各行は長さを表す文字で始まり、データ文字は ASCII 32〜95 から選ばれるため、MIME の Base64 が避けている記号も含まれます。uuencode ツール をご覧ください。

UTF-8

Web で主流のテキストエンコーディングです。ASCII 文字は 1 バイト、それ以外の文字は 2〜4 バイトになります。ツールが「テキストを Base64 に」と言うとき、ほぼ必ず UTF-8 のバイト列を Base64 にすることを意味します。たとえば é は C3 A9 です。UTF-8 から Base64 をご覧ください。

UTF-16LE

下位バイトを先に置く UTF-16 で、Windows と .NET の内部文字列形式です。UTF-16LE の ASCII テキストでは各文字の後にゼロバイトが入るため、Hello は A だらけの SABlAGwAbABvAA== になります。PowerShell の -EncodedCommand はこの形式を前提としています。UTF-16 から Base64 と PowerShell デコーダー をご覧ください。

Z85

ZeroMQ の Base85 バリアント（ZeroMQ RFC 32）です。4 バイトを 5 文字にエンコードし、クォートとバックスラッシュを避けているので、出力をソースコードの文字列にそのまま入れられます。入力は 4 バイトの倍数である必要があります。Z85 ツール で試せます。

zlib

deflate データを薄く包む形式（RFC 1950）で、2 バイトのヘッダーと Adler-32 チェックサムから成ります。ヘッダーはたいてい 78 で始まるため、zlib データを Base64 にすると、圧縮レベルに応じて eJ、eN、eF、eA のいずれかで始まります。zlib ツール をお使いください。

よくある質問