16進数からBase64へ
このコンバータは、ブラウザ内で16進数文字列を標準的なBase64として再エンコードします。入力は大文字小文字を区せず、0x接頭辞と余分な空白は削除され、出力はRFC 4648に従ってパディングされます。奇数長の入力は明確に拒否されます：不足しているニブルを推測することはありません。何もアップロードされません。
16進数からBase64へとは
16進数は開発者がバイトを表記する方法であり、Base64はデータ伝送のためのものです。このコンバータは16進数文字列をバイト単位で読み取り、RFC 4648標準アルファベットで同じバイトを再エンコードします（パディング含む）――これは基礎データに対して適切なエンコーダが生成する正確な文字列で、ヘッダー、設定ファイル、トークンフィールドにすぐ使用できます。
現実の16進数は複雑なため、コンバータはそれに合わせて対応します：大文字と小文字の数字は同等と見なされ、0x接頭辞は現れる箇所すべてで削除され、余分な空白（カラムダンプ、スペース区切りのペア、改行）は解析前にクリーンアップされます。推測は行いません。16進数の桁数が奇数ということは、どこかで1つのニブルが欠けていることを意味し、コンバータはデータを捏造する代わりに処理を拒否します。
変換はこのサイトのどこでもそうであるように、完全にローカルです：文字列はこのブラウザのタブ内で解析・エンコードされ、リクエストは送信されず、ページのContent-Security-Policyにより送信接続は禁止されています。変換中にネットワークパネルが空のままになることが証拠で、数秒で確認できます。
手動で答えを確認するのは、逆方向で簡単です：結果をBase64から16進数へコンバータに渡すと、元の16進数文字列がバイト単位で得られます。
最初からどちらのエンコーディングを選ぶかは、このサイトのBase64と16進数の比較のテーマです。サイズ、読みやすさ、プロトコル適合性を部族的な俗説なしで比較しています。
変換の実際の仕組み
Base64のグループ化ルールが実際の作業をすべて行い、このツールが出力するものの長さとパディングの両方を説明するため、一度理解する価値があります：
- クリーン化：0xと0Xの接頭辞は削除され、すべての空白は除去され、残りの文字は0-9、a-fまたはA-Fでなければなりません；それ以外の場合は位置情報付きの名前付きエラーになります。
- ペア化：2つの16進数が1バイトに変換されます――48はバイト0x48、文字Hになります。
- グループ化：バイトは3つずつ取り出されます；各3バイトの24ビットは4つの6ビットの値に分割され、各値はRFC 4648アルファベットA-Z a-z 0-9 + /の1文字にマッピングされます。
- パディング：1バイトまたは2バイトの最終グループは、出力の長さが常に4の倍数になるように=文字で補われます。
入力は判断される前にクリーン化されます
現実の16進数は装飾された形で到達します。ハッシュダイジェストは一部のライブラリから0x接頭辞付きで来ます；パケットダンプはスペース区切りのペアのカラムとして到着します；ドキュメントでは大文字で48 65 6Lと書かれる一方、ログには小文字で48656lと出力されます。これらはすべて同じバイトを表すため、コンバータは同じように扱います：接頭辞と空白は除去され、大文字小文字の区別は無視され、クリーン化された後のみパーサーが16進数桁を要求します。1つの文字列内で大文字と小文字が混在しても――6cと6C――は問題ありません。なぜなら、2つの表記は同じニブル値を表すからです。
奇数長入力：明確なポリシー
奇数長の16進数文字列は推測なしでは解析できません。なぜなら1桁が欠けており、どちらの側が欠落した可能性も高いからです。先頭にゼロを追加するか末尾にゼロを追加するかで異なるバイトが生成されます――0x48対0x84――なので、入力を静かに修正するとランダムに1つの意味を選択し、正しく見えるデータを提供してしまいます。このコンバータのポリシーは拒否です：奇数長の入力は長さ情報付きの名前付きエラーを返し、修正は実際に桁が欠落した場所を知っている人が行うべきです。これはこのサイトの他のコンバータが適用する「破損させるより拒否する」というルールと同じです。
出力の見た目
以下の作業例は、「サンプルを読み込む」ボタンが生成する正確なペアです：装飾された16進数文字列――0x接頭辞、スペース、大文字小文字混在――が5バイトの"Hello"を表す文字列として到着し、最終グループが3バイトではなく2バイトであるため1つの=を伴う標準的なBase64「SGVsbG8=」として出力されます。出力は標準アルファベットを使用し、プラスとスラッシュを含みます。URLセーフな変種ではありません；もし宛先でこれら2文字が破損する場合は、RFC 4648のURLセーフアルファベットが文書化された置換として適用されます。
よくある質問
16進数からBase64への変換で、入力がどこかにアップロードされますか？
いいえ。解析とエンコードはページに同梱されたコードを使ってこのブラウザタブ内で実行されます。ページはアップロードエンドポイントを定義しておらず、そのContent-Security-Policyは送信接続をブロックするため、情報漏えいは単なる約束ではなく、構造的に不可能です。DevToolsで主張を検証できます：ネットワークパネルを開き、文字列を変換し、何も記録されていないのを確認してください。
なぜ奇数長の16進数は修正される代わりに拒否されるのですか？
なぜなら、すべての修正は実際の結果をもたらす推測だからです。桁数が奇数ということは1つのニブルが欠けていることを意味し、先頭にゼロをパディングするか末尾にパディングするかで異なるバイトが生成されます――48対84――なので、静かに修正すると正しく見えるデータを捏造してしまいます。コンバータは長さ情報付きの名前付きエラーを返し、実際に桁が欠落したソースをあなたが修正します。
大文字、0x接頭語、スペースは本当に受け入れられますか？
はい。大文字小文字は区別されません――4Cと4cは同じニブルです――0xと0Xの接頭辞はバイトごとに繰り返されていても削除され、すべての空白は解析前に除去されるため、貼り付けた16進ダンプのカラムは前処理なしで変換できます。クリーン化後、有効なのは0-9とa-fまたはA-Fのみです；gやカマなどの余分な文字は位置情報付きの名前付きエラーになります。
出力には常に=パディングが含まれますか？
パディングはバイト数が3の倍数でない場合にのみ表示されます――2バイトの余りに対して1つ、1バイトの余りに対して2つ――で、出力の長さは常に4の倍数です。=文字はRFC 4648の一部であり、ノイズではありません：それらを除去すると、長さに依存するデコーダを破壊します。このツールは標準形式のパディング付きを出力し、標準エンコーダが生成するものと一致します。
なぜBase64の出力は16進数の入力より短いのですか？
エンコードオーバーヘッドの計算：16進数はバイトあたり2文字、Base64は3バイトあたり4文字を使用します。同じバイトに対して、16進数は100%のオーバーヘッドで、Base64は約33%なので、64バイトのダイジェストは128文字の16進数からパディングを含む88文字のBase64に減少します。データは全く同じです――アルファベットのパック効率が変わっただけです。
Base64エンコードはデータを暗号化する方法ですか？
いいえ、それを暗号化の方法と見なすことは真のセキュリティ上の誤りです。Base64はキーのない reversible エンコードです：文字列を持つなら誰でもオフラインでミリ秒単位でデコードできます――このページはネットワークなしでそれを行います。存在意義はテキストセーフなチャネルでバイトを移動させることであり、保護することではありません。機密性が重要な場合は、まず暗号化してから、その暗号文をBase64でトランスポートしてください。