URLデコーダー

URLデコーダーは、パーセントエンコードされたURLのテキストを元の文字列に戻す無料ツールです。

URLデコードでは何が行われますか？

URLデコードは、空白、句読点、その他のバイトをURLやパーセントエンコード対応の構文で扱うために施されたエスケープを元に戻します。パーセントエンコードでは、1バイトをパーセント記号と2桁の16進数で表します。フォーム形式のURLエンコードでは、空白を表すために+も使われます。たとえば、空白は%20、アンパサンドは%26と記述できます。

簡単な変換例を示します。

エンコードされた入力: red%20%26%20blue

デコード結果: red & blue

このエンコードが必要なのは、一部の文字がURL内で構造上の意味を持つためです。疑問符はURLのクエリの開始位置を示し、フォーム形式のクエリデータでは通常、アンパサンドがフィールドの区切りとして使われます。これらの文字をエンコードすれば、区切りではなくデータとして渡せます。

URLエンコードは暗号化ではなく、内容を秘匿する機能もありません。エンコードされた値を読める人なら、誰でもデコードできます。パーセントエンコードされたパスワード、アクセストークン、個人情報を保護済みのデータとして扱わないでください。

URLデコーダーの使い方は？

エンコードされたテキストを貼り付けるか入力して処理し、URLデコード済みの結果欄で復元された値を確認します。このツールはPHPのurldecode関数を使用しているため、有効な%HH形式を変換し、プラス記号を空白として扱います。

1. クエリパラメーターの値など、エンコードされた部分をコピーします。
2. 引用符が実際の値に含まれている場合を除き、引用符を追加せずにURLエンコードされた値を入力します。
3. URLの入力を処理し、URLデコード済みの結果を確認します。
4. 出力に%2Fや%20のような文字列が残っている場合は、もう一度デコードする前に、元のデータが複数回エンコードされていないか確認してください。

処理はサーバー上で行われます。入力内容はHTTPS経由でサーバーへ送信され、保存はされませんが、処理中は端末の外に送られます。サーバー側で処理しても問題ないデータでない限り、このURLデコーダーに機密情報を貼り付けないでください。

URLエンコードはどこで使われますか？

URLエンコードは、クエリ文字列、フォーム送信、リンクに埋め込まれた値でよく使われます。また、制約のあるテキスト形式を通じてデータを渡す必要がある、やや分かりにくい場所でも使われています。

• クエリ文字列: "tea & cake"という検索語は、q=tea+%26+cakeと表されることがあります。
• データURI: メディアタイプの後にテキストデータをパーセントエンコードできます。Base64も一般的な表現方法です。
• メールリンク: mailtoリンクでは、件名や本文のパラメーターに含まれる空白、改行、句読点がエンコードされることがあります。メール本文内で使われるMIME転送エンコーディングは別の形式です。
• JSONペイロード: JSON自体には独自のエスケープ規則がありますが、JSON文字列にエンコード済みのURLやクエリ値が含まれている場合は、別途デコードする必要があります。
• 国際化ドメイン: 非ASCII文字を含むドメインラベルでは、通常、パーセントエンコードではなくPunycodeが使われます。パスやクエリの構成要素には、パーセントエンコードされたUTF-8バイトが含まれることがあります。

エンコードされたテキストがxn--で始まるドメインラベルなら、IDN Punycode コンバーターを使用してください。URLデコーダーは、Punycodeの変換ではなく、パーセントエンコードされたURL構成要素をデコードするためのツールです。

URLデコードの変換例

一般的な入力と、それに対応するURLデコード後のテキストを示します。

• hello%20worldはhello worldになります。
• name=Tom+Jonesはname=Tom Jonesになります。
• fish%26chipsはfish&chipsになります。
• バイトがUTF-8テキストを表している場合、%C2%A3は£になります。
• UTF-8として解釈すると、%E6%9D%B1%E4%BA%ACは東京になります。
• 100%25は100%になります。

通常、エンコードされていない英字、数字、句読点は入力されたまま残ります。入力が空なら、URLデコード済みの結果も空になります。非常に長い入力にも同じデコード規則が適用されますが、ブラウザー、サーバー、受信側のシステムには、リクエストやURLの長さに独自の上限が設けられている場合があります。

アクセント付き文字や非ラテン文字は通常、UTF-8のバイト列としてエンコードされ、各バイトが個別に記述されます。元のシステムで別の文字エンコーディングが使われていた場合、デコードしたバイトが置換文字や意味不明に見えるテキストとして表示されることがあります。

URLデコードに失敗したり文字化けしたりするのはなぜですか？

パーセント形式が不完全、複数回エンコードされている、誤った文字セットで解釈されている、または入力がそもそもURLエンコードされたデータではない場合、URLデコードの結果が変わらなかったり、予想外の内容になったりします。PHPのurldecodeは不正なパーセント形式をそのまま残します。二重にエンコードされた入力は、1回の処理では中間結果になります。何度もデコードする前に、元のデータを確認してください。

• 二重にエンコードされた入力: %2520を1回デコードすると%20になり、2回目のデコードで初めて空白になります。別のエンコード層が存在すると分かっている場合に限り、もう一度デコードしてください。
• 不完全なパーセント形式: エンコードされた各バイトには、2桁の16進数が必要です。末尾の%や%2のような値は不正で、完全なエンコード済みバイトを表せないため、PHPのurldecodeではそのまま残ります。
• 誤った文字エンコーディング: パーセントデコードで復元されるのはバイトです。たとえばISO-8859-1のバイトをUTF-8として解釈すると、パーセント形式が正しくても文字化けすることがあります。
• テキストではなくバイナリデータ: デコードされたバイトが、画像、圧縮ファイル、その他のバイナリデータを表している場合があります。このような出力は、読めるテキストとして表示されるものではありません。
• エンコード方式の違い: URLデコード後の結果を続けてBase64デコーダーへ渡す場合、標準アルファベットとURLセーフアルファベットの違い、=パディングの欠落、入力の破損などが原因でデコードに失敗することがあります。URLのパーセントエンコードにはパディングもBase64アルファベットも使われません。また、URLデコードでは、こうしたBase64の問題を検証したり修復したりできません。

値に含まれるプラス記号には注意してください。フォーム形式のURLエンコードでは、+は空白を意味します。実際のプラス記号は通常、デコード前に%2Bとしてエンコードされている必要があります。

よくある質問

URL全体をデコードしてもいいですか？

できる限り、個別のパスセグメントまたはクエリパラメーターの値だけをデコードしてください。URL全体をデコードすると、%26、%3F、%2Fなどのエンコードされた予約文字が区切り文字に変わり、URLの解析方法が変わることがあります。

小文字の16進数もURLデコードできますか？

はい。パーセント形式内の16進数は大文字と小文字を区別しないため、%2fと%2Fはどちらも同じバイトを表します。大文字と小文字が混在した形式も有効です。

同じ値を繰り返しデコードしますか？

いいえ。urldecodeを1回呼び出すと、デコード処理も1回だけ実行されます。%252Fが%2Fになった後、スラッシュにするにはもう一度処理する必要があります。ただし、繰り返しデコードすると、リテラルのパーセント形式を含むことが意図されたデータまで変わる可能性があります。

壊れたテキストをURLデコードで復元できますか？

いいえ。有効なパーセントエンコードは元に戻せますが、欠けた16進数を復元したり、元の文字セットを確実に特定したりすることはできません。デコード後のバイトが正しく表示されない場合は、元のシステム、HTTPヘッダー、ドキュメントを確認してください。

xn--で始まる値はどう処理すればいいですか？

通常のパーセントエンコードされたテキストではなく、Punycodeのドメインラベルとして扱ってください。IDN Punycode コンバーターを使用し、変換後のドメインを慎重に確認してください。見た目がよく似たUnicode文字でも、異なる文字体系に属している場合があります。