Base64 エンコード & デコード
無料オンライン Base64 エンコード & デコード ツール。100% ローカル処理 — データは端末の外に出ません。
結果がここに表示されます...
入力 → エンコード
Usage Guide
Base64について
Base64は64個の印刷可能な文字を使用してバイナリデータを表すエンコード方式で、テキストプロトコルでバイナリデータを転送する必要があるシナリオで広く使用されています。Base64はA-Z、a-z、0-9、+、/（合計64文字）とパディング文字として=を使用します。3バイト（24ビット）のバイナリデータを4つのBase64文字にエンコードし、エンコードされたデータは元のサイズの約133%になります。Base64は暗号化アルゴリズムではなく、誰でもデコードできるエンコード方式です。
使用手順
Base64のエンコードとデコードは非常に簡単です：
エンコードの原理
Base64エンコードは以下のプロセスでバイナリデータをASCII文字に変換します：
Base64のバリアント
Base64には異なるシナリオ向けのいくつかの一般的なバリアントがあります：
アプリケーションシナリオ
Base64はテキストプロトコルでバイナリデータを転送する必要があるシナリオで広く使用されています：
FAQ
Q: Base64エンコードはデータサイズを増加させますか？
A: はい、Base64エンコードはデータサイズを約33%増加させます。理由：Base64は3バイト（24ビット）を4文字（32ビット）にエンコードし、8ビット追加されます。例えば、100KBのファイルはエンコード後に約133KBになります。影響：1) ネットワーク転送時間が増加。2) ストレージスペースが増加。3) エンコード/デコードのCPUオーバーヘッドが増加。最適化：1) 大きなファイルの場合、エンコード前に圧縮（gzipなど）を検討。2) URLセーフBase64を使用してパディングを省略すると、サイズをわずかに削減できる。3) Webリソースの場合、Data URLの代わりに直接バイナリ転送（Blob URLなど）の使用を検討。
Q: Base64と暗号化の違いは何ですか？
A: Base64はエンコードであり、暗号化ではありません。根本的に異なります。Base64エンコード：1) 目的：バイナリデータを転送用のテキスト形式に変換。2) 可逆性：誰でもキーなしでデコードできる。3) セキュリティ：セキュリティなし、データの機密性を保護できない。暗号化：1) 目的：データの機密性を保護し、不正アクセスを防止。2) 可逆性：復号化にキーが必要。3) セキュリティ：データ保護を提供。 正しいアプローチ：データ保護が必要な場合は、まず AES などのアルゴリズムで暗号化し、その後転送のためにBase64でエンコードしてください。
Q: Base64文字列が=記号で終わるのはなぜですか？
A: =はBase64のパディング文字で、エンコード長を揃えるために使用されます。理由：Base64は3バイトを4文字にエンコードします。元のデータ長が3の倍数でない場合、最後のグループは3バイト未満になり、=パディングが必要です。ルール：1) 1バイト残り：2文字 + 2 =にエンコード。2) 2バイト残り：3文字 + 1 =にエンコード。3) ちょうど3バイト：パディング不要。 例：“A” → “QQ==”、“AB” → “QUI=”、“ABC” → “QUJD”。 URLセーフ：URLでは=を省略できます（URLセーフBase64）、デコード時に自動的に追加されます。
Q: Base64とHexエンコードの違いは何ですか？
A: Base64と Hex はどちらもバイナリデータのテキスト表現ですが、異なる特性があります。Base64：1) 64文字を使用（A-Z、a-z、0-9、+、/）。2) エンコードサイズは元のデータの約133%。3) よりコンパクトで転送に適している。Hex（16進数）：1) 16文字を使用（0-9、A-F）。2) エンコードサイズは元のデータの200%。3) より読みやすく、デバッグに適している。選択アドバイス：1) コンパクトな転送が必要：Base64を使用。2) 読みやすさとデバッグが必要：Hexを使用。3) 暗号化アルゴリズムの出力：通常Hexを使用（ SHA-256など）。
Q: Data URLとは何ですか？どのように使用しますか？
A: Data URLはBase64エンコードを使用してデータをURLに直接埋め込む方法です。フォーマット： data:[メディアタイプ];base64,[Base64データ]。例：data:image/png;base64,iVBORw0KGgoAAAANS...。 利点：1) HTTPリクエストを削減し、ページ読み込み速度を向上。2) 追加ファイル不要で、共有と埋め込みが簡単。 欠点：1) HTML/CSSファイルサイズが増加。2) ブラウザキャッシュを利用できない。3) 大きなファイルには不適切。 ユースケース：1) 小さなアイコン、ロゴ（< 10KB）。2) インラインSVG画像。3) フォントファイル（小さなフォント）。4) CSSバックグラウンド画像。 ベストプラクティス：10KB未満のリソースにのみData URLを使用し、大きなファイルは別ファイルを使用してCDNとキャッシュを活用してください。
Q: JavaScriptでBase64を使用するには？
A: JavaScriptにはBase64エンコードとデコードの組み込みメソッドがあります。エンコード：btoa(string) - 文字列をBase64にエンコード。デコード：atob(base64String) - Base64を文字列にデコード。注意：btoaと atobはASCII文字のみサポートします。UTF-8文字列の場合は最初に変換が必要です：// UTF-8をエンコード
const base64 = btoa(unescape(encodeURIComponent('中文')));
// UTF-8をデコード
const text = decodeURIComponent(escape(atob(base64)));
モダンな方法：UTF-8を処理するためにTextEncoderとTextDecoder APIを使用。ファイルエンコード：FileReader.readAsDataURL()を使用してファイルをData URLとしてエンコード。
Use Cases
推奨：小さな画像のData URL
Data URLを使用してHTMLとCSSに小さな画像（アイコンやロゴなど）を埋め込むことで、HTTPリクエストを削減しページ読み込み速度を向上させることができます。10KB未満の画像に推奨し、大きな画像は別ファイルを使用してCDNとブラウザキャッシュを活用してください。Data URLはインラインSVG画像に特に適しています。SVGはテキスト形式であり、Base64エンコード後も読みやすいままです。
- ✅ 小さなアイコン、ロゴ（< 10KB）
- ✅ インラインSVG画像
- ✅ CSSバックグラウンド画像（小さいもの）
- ❌ 大きな画像を避ける（> 50KB）
- 💡 自動変換のためにビルドツール（Webpackなど）を使用
推奨：JWT（JSON Web Token）
JWTはクライアントとサーバー間で安全に情報を転送するためにHeaderとPayloadのエンコードにBase64を使用します。JWTはHeader、Payload、Signatureの3つの部分で構成され、ドットで区切られています。HeaderとPayloadはBase64エンコードを使用し、Signatureは HMAC-SHA256 またはRSA署名を使用します。
- ✅ ユーザー認証と認可
- ✅ シングルサインオン（SSO）
- ✅ APIアクセストークン
- ❌ JWTに機密情報を保存しない（Base64はデコード可能）
- 💡 JWTの転送にHTTPSを使用
推奨：HTTP Basic Authentication
HTTP Basic Authenticationはユーザー名とパスワードをBase64でエンコードし、Authorization: Basic [Base64(ユーザー名:パスワード)]の形式で使用します。Base64エンコードはセキュリティを提供しませんが、HTTPSと組み合わせることで転送中の認証情報を保護できます。HTTP Basic Authenticationはシンプルで使いやすく、内部システムや認証の迅速な実装が必要なシナリオに適しています。
- ✅ 内部システム、管理パネル
- ✅ API認証（HTTPSと組み合わせて）
- ✅ シンプルなユーザー認証
- ❌ 平文転送を避けるためにHTTPSを使用する必要がある
- 💡 より安全なOAuth 2.0またはJWTを検討
推奨：メール添付ファイル（MIME）
MIME（Multipurpose Internet Mail Extensions）プロトコルはメール添付ファイルをBase64でエンコードし、バイナリファイルをメールシステムで転送するためのテキスト形式に変換します。MIME Base64はメールプロトコルの行長制限に準拠するために76文字ごとに改行（CRLF）を挿入します。現代のメールクライアントはユーザーの手動介入なしにBase64エンコードとデコードを自動的に処理します。
- ✅ メール添付ファイルのエンコード
- ✅ メール本文への画像の埋め込み
- ✅ RFC 2045標準に準拠
- 💡 自動処理のためにメールライブラリ（Nodemailerなど）を使用
推奨：APIバイナリデータ転送
JSONやXMLなどのテキスト形式のAPIでバイナリデータ（画像やファイルなど）を転送する場合、Base64エンコードを使用できます。これにより、multipart/form-dataなどの複雑なバイナリ転送形式の処理を避けられます。ただし、大きなファイルの場合は、より良いパフォーマンスのために専用のファイルアップロードAPI（multipart/form-dataやオブジェクトストレージへの直接アップロードなど）が推奨されます。
- ✅ 小さなファイル転送（< 1MB）
- ✅ JSON APIへのバイナリデータの埋め込み
- ✅ 設定ファイルへの証明書とキーの保存
- ❌ 大きなファイルの転送を避ける（> 10MB）
- 💡 大きなファイルにはmultipart/form-dataまたはオブジェクトストレージを使用
推奨：設定ファイルへのバイナリデータの保存
設定ファイル（JSON、YAML、XMLなど）にバイナリデータ（SSL証明書、キー、小さな画像など）を保存する場合、Base64エンコードを使用できます。これにより、外部ファイルパスとファイル読み取りの問題を処理する必要がなくなり、設定ファイルが自己完結型になります。DockerイメージやKubernetes ConfigMapsなどのパッケージ化された設定が必要なシナリオに特に適しています。
- ✅ SSL証明書、秘密鍵
- ✅ APIキー、トークン
- ✅ 小さな画像、アイコン
- ✅ Docker、Kubernetes設定
- 💡 機密情報を含む設定ファイルを保護
ベストプラクティスの推奨事項
- Base64はエンコードであり暗号化ではなく、データの機密性を保護できません。データ保護が必要な場合は、まず暗号化してからエンコードしてください。
- Base64エンコードはデータサイズを約33%増加させます。大きなファイルの場合は、エンコード前に圧縮することを検討してください。
- Data URLは10KB未満のリソースに適しています。大きなファイルは別ファイルを使用してCDNとキャッシュを活用してください。
- HTTP Basic AuthenticationはHTTPSと組み合わせて使用し、転送中の認証情報の盗難を防いでください。
- JWT PayloadはBase64エンコードを使用しており、誰でもデコードできます。機密情報を保存しないでください。
- UTF-8文字列の場合は、TextEncoder/TextDecodeまたはencodeURIComponent/decodeURIComponentを使用して処理してください。