目的地から始める
ツールを選ぶ前に、その値をどこで使うか確認しましょう。HTML エンティティへの変換は、HTML テキスト内でアンパサンドなどの文字を表すのに役立ちます。パーセントエンコーディングは、空白や予約文字に決まった表記が必要な URL の構成要素に値を入れるためのものです。Base64 は任意のバイト列を、テキスト中心のシステムで扱いやすい限られた文字種で表します。SHA-256 のダイジェストはデータ比較に使う固定長の指紋であり、元データの復元手段ではありません。この4つの処理はいずれも暗号化ではありません。秘密を守る必要があるなら、Base64 やハッシュで見かけを変えるのではなく、用途に合った認証付き暗号化方式を選んでください。
１つの入力、４つの異なる結果
短い文字列 A&B を例にします。通常の HTML テキストではアンパサンドを A&B と記述でき、HTML パーサーは再び A&B と表示します。URL の構成要素では、エスケープされていないアンパサンドがクエリパラメーターの区切りになり得るため、A%26B となります。UTF-8 では目に見える3文字が16進数のバイト列 41 26 42 になり、標準の Base64 では QSZC と表されます。一方、SHA-256 ツールは長い16進数のダイジェストを出力し、入力が少し変わると通常は大きく異なる値になります。これらの出力は交換可能ではありません。URL の構成要素が必要な場所に Base64 を入れると予約文字が混じる場合があり、文書にハッシュを載せても元の文字列は再現できません。
- A&B：元のテキスト
- HTML: A&B · URL: A%26B
- Base64：QSZC／SHA-256：ダイジェスト
元に戻せる処理と安全性
HTML エンティティ、パーセントエンコーディング、Base64 は、入力の文字コードと使用場面が分かっていれば元に戻せます。だからこそ秘密を守る手段にはなりません。Base64 の文字列は鍵なしで誰でもデコードできます。SHA-256 は一方向の処理として設計されていますが、推測しやすいパスワードを単にハッシュ化するだけでは安全に保管できません。それにはソルトを用いる専用のパスワードハッシュ方式が必要です。また、ダイジェストだけでは、認証されたプロトコルの中で使わない限り、誰がデータを提供したかは証明できません。ブラウザー向けコンテンツのエスケープ規則は使用場面ごとに異なります。HTML テキスト、HTML 属性、URL、JavaScript ソースで必要な処理は同じではなく、ある場面向けにエスケープした結果を別の場面に貼り付けると危険なことがあります。
実用的な変換ワークフロー
まず元のテキストと、その受け手となる形式を特定します。HTML のテキストノードを作るなら、その場所で表記を変える必要がある文字に HTML エンティティエンコーダーを使います。実運用の HTML マークアップは信頼できるテンプレートシステムに任せてください。URL の1つのパラメーターに値を入れるなら、その値を URL コンポーネント用に1回エンコードしてから、パラメーターに付け加えます。インターフェースが明示的に Base64 を要求する場合は、合意した文字コード（通常は UTF-8）でテキストをバイト列にし、そのバイト列をエンコードします。2つのバイト列の整合性を比べるなら、同じアルゴリズムで両方をハッシュ化し、ダイジェストを比較します。後で元のメッセージを表示する必要があるなら、元のバイト列も保管してください。
往復のチェック
元に戻せるはずの変換では、対応するデコーダーで結果を試しましょう。二重エンコードにも注意が必要です。A%26B をもう一度エンコードすると %25 が含まれ、1回のデコードでは1層しか戻りません。Base64 の受け手が標準の文字種、URL セーフな変種、パディング文字のどれを想定するか確認してください。ハッシュでは、使用した文字コードのほか、改行や末尾の空白が入力に含まれるかも確認します。見た目が似たテキストでもバイト列は異なることがあります。下の埋め込み Base64 変換ツールでは、元に戻せるケースをすぐ試せます。HTML、URL、SHA-256 の経路はリンク先のツールで試し、受け手のシステムが期待する意味に合う出力を選びましょう。