Base64から16進数へ
このコンバータはRFC 4648に準拠してBase64をデコードし、同じバイトを小文字の16進数としてブラウザで再エンコードします。パディングは処理され、URLセーフなアルファベットも受け付け、各バイトは出力順にちょうど2つの16進数にマッピングされます。接頭辞も区切り文字もありません。アップロードもありません。
Base64から16進数へとは
Base64と16進数は同じバイトの異なる表記法であり、このコンバータはその間を変換します：Base64をRFC 4648が規定する通りにデコードし、各デコードされたバイトを2桁の小文字16進数として出力します。その間で何も再解釈されることはありません――得られる結果は16進数エディタが表示するバイト列と、1文字ずつ一致します。
興味深いのは、通常のコンバータがスキップする部分です。パディング：末尾の=文字は処理され、パイプラインでパディングが削除された入力も受け付けます。アルファベット：標準のA-Z a-z 0-9 + / セットはデコードされ、同じRFCで定義されるURLセーフな-_バリアントはデコード前に正規化されます。バイトオーダー：保持されます――1バイトを2つの16進数に、常に上位ニブルを先頭にして。
このサイトのすべてのツールと同様に、変換はこのブラウザタブ内で実行されます：テキストがこの端末の外に出ることはありません。リクエストは送信されず、Content-Security-Policyはページが外部に接続することを禁止します。変換中にDevToolsのNetworkパネルが空のままであること、それが証拠です。約束ではなく、確かめられる事実です。
逆の変換――ヘッダーやトークンフィールド向けに16進数として表示されたバイト――は、姉妹ページである16進数からBase64へ変換が実行します。同じRFC 4648のアルファベットと同じローカル処理を使用しています。
グループ化とパディングルールが任意に思える場合は、Base64の実際の動作方法のガイドが3つの短い段落で仕組みを基本的な原理から構築します。
変換の実際の仕組み
変換は、その間に何も隠されていない2つの明確な段階で構成され、各段階には守るべきポリシーがあります：
- 標準化：空白、改行（MIMEでラップされた入力）、先頭の?は削除されます。URLセーフな文字-と_はRFC 4648の第2のアルファベットに従って+と/にマッピングされます。
- デコード：残りの文字はRFC 4648のアルファベットを通じてマッピングされます――4文字が3バイトに。=パディングは最後のクォンタムで消費されます。
- 検証：アルファベット外の文字は名前付きのエラーとして、その位置情報とともに報告されます。長さが4の倍数より1長い場合は拒否されます。なぜなら、余った1文字だけでは正しいバイトを構成できないためです。
- 出力：各バイトが2桁の小文字16進数に変換され、上位ニブルを先頭にして、区切り文字も0x接頭辞もなく連結されます。
パディングとアルファベット、正確に
RFC 4648の標準アルファベットはA-Z、a-z、0-9、+、/で、=パディングはバイト数が3の倍数でない場合に最後のクォンタムに追加されます。パディングは意味を持ちます――最後のクォンタムが1バイトなのか2バイトなのかを区別するためですが、デコーダは長さからクォンタムが明確な場合（2または3 mod 4の長さ）パディングなしの入力も受け付けます。1 mod 4の長さはパディングの有無にかかわらず無効です――1つのBase64文字が完全なバイトを生成することはできないため、ゼロで埋める代わりに拒否されます。
同じRFCで定義されるURLセーフなバリアント――プラスとスラッシュの代わりにハイフンとアンダースコア――は受け付けられ標準化されます。これは実際に重要です。なぜなら、JWTやURLパラメータは通常パディングなしでURLセーフな形式で出力されるからです。1つの入力に両方のアルファベットを混在させることは拒否されます：+と-の両方を含む文字列は一貫した読み取り方ができません。
出力の見た目
以下の作業例は、「例を読み込む」ボタンが生成する正確なペアです：「Hello world」のBase64が22桁の小文字16進数に変換されたもの――バイトあたり2桁、合計11バイト。出力は連続した1つの文字列です――0x接頭辞も、スペースも、改行もありません。なぜなら、16進数エディタ、ディセクタ、コードのすべてがプレーン形式を好むからです。長さの計算：Base64は3バイトに4文字を使い、16進数は1バイトに2文字を使うため、16進数の出力はパディングなしのBase64の約1.5倍の長さになります――これはデータではなく、エンコーディングの特性です。
バイトオーダーについて、一度だけはっきり述べておくと
エンディアンは関係ありません。その理由を説明する価値があります。Base64はバイト列にデコードされ、列には自然な順序があります：最初にデコードされたバイトが最初です。16進数の出力はその順序を正確に反映します――バイトnは位置2nと2n+1の16進数文字になります――そのため、結果はオフセットなしの16進数エディタが表示する文字列と同じになります。単語の入れ替えも、リトルエンディアンでの再解釈もなく、xxdと比較しても驚きはありません。
よくある質問
Base64を16進数に変換する際、データはどこかにアップロードされますか？
いいえ。デコードと再エンコードはこのブラウザタブ内で、ページと一緒に読み込まれたJavaScriptで実行されます。ページのコードにはアップロードのルートがなく、サイトのContent-Security-Policyは外部への接続を禁止しています。自分で確認するには：DevToolsを開き、ネットワークパネルをクリアまたは監視し、変換してリクエストが現れないことを観察してください――このツールはネットワークケーブルが抜かれた状態でも動作します。
16進数の出力は大文字ですか、それとも小文字ですか？
常に小文字です――xxdやほとんどの16進数エディタが表示するのと同じ規則です。大文字と小文字の16進数は同じバイトを表し、システムで大文字が必要な場合は大文字への変換は損失ありません。出力には0x接頭辞、区切り文字、改行がないため、コード、ディセクタ、テストフィクスチャにきれいに貼り付けることができます。
なぜ16進数の文字列はBase64の入力より長いのですか？
2つのエンコーディングの性質：Base64は3バイトを4文字に詰め込みます（約33%のオーバーヘッド）、一方16進数は各バイトに2文字使います（100%のオーバーヘッド）。両者の比を取ると、16進数の長さは同じバイトに対してパディングなしのBase64の約1.5倍になります。どちらのエンコーディングも何も圧縮していない――両者とも同じバイト列のアルファベットにすぎません。
入力に=パディングは必要ですか？
いいえ。パディングされた入力はそのままデコードされ、一部のパイプラインで削除されたパディングは長さから再構成されます――2または3 mod 4の長さは最後のクォンタムを一意に特定します。常に無効なのは1 mod 4の長さです。パディングの有無にかかわらず、Base64の1文字だけでは完全なバイトを構成できないためです。その入力は明確なエラーで拒否され、推測されることはありません。
Base64から16進数への変換は、一種の復号ですか？
いいえ、その区別は重要です。Base64と16進数の両方ともエンコーディングです：同じバイトの可逆的な表記法で、プロセスのどこにも鍵はありません。このページを含め、誰でもオフラインでデコードできます。もしあなたのBase64が暗号文をエンコードしていた場合、それを16進数に変換しても表現が変わるだけです――データは以前とまったく同じように読めるか、または保護されています。
-と_文字を含むURLセーフなBase64はどうですか？
受け付けられ処理されます。RFC 4648はURLセーフなアルファベット――プラスの代わりにハイフン、スラッシュの代わりにアンダースコア――を、JWTやURLパスセグメントのように+と/が壊される可能性があるコンテキストのために定義しています。コンバータはデコード前にこれらの文字を標準アルファベットに正規化するため、Authorizationヘッダーから直接コピーされたトークンは変更せずに動作します。両方のアルファベットを混在させる場合のみ拒否されます。