code Base64エンコード/デコード star

仕組み

Base64は、64種類の印字可能な文字——A–Z、a–z、0–9、それに+と/——からなるアルファベットを使って、バイナリデータを平文のテキストに変換します(64はちょうど2⁶であり、これがBase64と呼ばれる理由です)。エンコーダーは入力を3バイト(24ビット)ずつ読み取り、その24ビットを4つの6ビットのかたまりに分割し、それぞれの6ビットのかたまりをアルファベットの1文字に対応させます——そのため、3バイトのバイナリは常にちょうど4文字のテキストになります。入力の長さが3の倍数できれいに割り切れない場合、出力の長さを4の倍数に保つため、最後のグループは1つまたは2つの=文字でパディングされます。

具体的に見てみましょう:「Man」という文字列を構成する3バイト(77、97、110——2進数で01001101 01100001 01101110)は、4つの6ビットのかたまり(010011、010110、000101、101110)に再編成され、それぞれが1文字に対応づけられてTWFuになります。入力の3バイトが常に出力の4文字に拡張されるため、Base64エンコードされたデータは元のデータより確実に約33%大きくなります——300 KBの画像はおよそ400 KBのBase64文字列になり、これは画像をdata: URIとして埋め込んだり、バイナリファイルをJSONやメールに添付したりする際に重要な意味を持ちます。

このツールは、まずテキストを正しくUTF-8エンコードすることでUnicodeを適切に処理するため、マルチバイト文字や絵文字(「çğü 😀」)も壊れることなく往復できます——単純なJavaScriptのbtoa()呼び出しは、1文字につき1バイトを想定しているため、こうした文字に対してはエラーを投げてしまいます。処理はすべてブラウザ内でローカルに実行され、入力した内容がどこかに送信されることはありません。

Base64は、ほとんどの人が気づかないところで絶えず使われています:HTMLの<img src="data:image/png;base64,...">タグは、ファイルにリンクする代わりに画像全体をそのままページに埋め込みます。Authorization: BasicというHTTPヘッダーは、Base64エンコードされた「ユーザー名:パスワード」の文字列を運びます(これはあくまで形式を整えているだけで保護ではありません——通信中の実際の秘匿性を担保しているのはTLSです)。メールの添付ファイルは、元のMIME標準の頃からBase64でエンコードされてきました。SMTPが生のバイナリではなく7ビットのテキストを送るために設計されていたからです。そしてJSON Web Token(JWT)は、署名付きのバイナリ構造をドットで区切られた3つのテキスト部分に詰め込むために、URLセーフな変種を使用しています。

知っておくべきこと

• Base64は暗号化ではありません——秘匿性が一切ない、誰もが知っている可逆的な表現方法です。同じアルファベットを使えば誰でも即座にデコードできます。存在する理由は、バイナリデータをテキストのみを扱えるチャネル(メールのMIME添付ファイル、data URI、JSONフィールド、HTTP Basic認証ヘッダーなど)を通しても安全に運べるようにするためであり、内容を隠すためでは決してありません。
• URLセーフな変種: +と/はURLの中で特別な意味を持つため、「URLセーフ」なBase64アルファベットではこれらを-と_に置き換え、多くの場合=のパディングも省略します。このツールはどちらの変種も自動的にデコードします。
• サイズのコストは固定で予測可能です: 約33%の増加(4/3の比率)は、データそのものにとって正確な値です——これが、生のバイナリアップロードを受け付けるAPIが、Base64で包んだJSONボディを要求するAPIよりも一般に帯域効率が良い理由です。
• パディングは余りを教えてくれます: =が1つあれば、元のデータの長さが3の倍数より2バイト多かったことを意味し、=が2つあれば1バイト多かったことを意味します。パディングがまったくなければ、入力がちょうど3の倍数バイトだったことを意味します。