あらゆるテキストをURLエンコード・デコード

URLエンコード・デコードのやり方

1. テキスト、値、またはURLを入力欄に貼り付けます。
2. エンコード方式を選びます。クエリの値1つやパスの1区間なら、そのままコンポーネントで大丈夫です。空白や日本語だけを直したい完成済みのアドレスならURL全体を選びます。HTMLフォームの送信として読まれるデータならフォームを選んでください。
3. エンコードまたはデコードを押します。1行1値で処理にチェックがあると、各行が別々に処理されるので、パラメータやURLの一覧をまとめて変換できます。
4. 結果をコピーするか、結果を入力に戻すを押してもう一度処理します。たとえば、2回エンコードされた値を1枚ずつ剥がすときに使えます。

クエリ文字列を含むURLをデコードすると、各パラメータの名前と値も読める形で一覧表示します。長いトラッキングURLやリダイレクトURLを読むには、これがいちばん早い方法です。

パーセントエンコードとは

URLに使える文字はASCIIの限られた範囲だけで、その中にも役割を持つ文字があります。?はクエリの開始、&はパラメータの区切り、#はフラグメントの開始、/はパスの区切りです。それ以外の文字をURLに入れる方法がパーセントエンコードです。文字をUTF-8のバイト列に変換し、各バイトを%と16進数2桁で書きます。空白は1バイトなので%20、éは2バイトで%C3%A9、ひらがなの「あ」は3バイトで%E3%81%82、絵文字の😀は4バイトで%F0%9F%98%80になります。デコードはその逆の処理です。

ルールの出どころは、URIの構文を定めた標準規格RFC 3986の第2章（英語）です。16進数は大文字で書くこと（%3aではなく%3A）、文字は先にUTF-8のバイトにすること、同じ文字列を2回以上パーセントエンコード・デコードしてはならないことが書かれています。

予約文字と非予約文字（RFC 3986）

RFC 3986は、URLに使える文字を2つのグループに分けています。

• 非予約文字：英字A–Z a–z、数字0–9、そして- . _ ~。エンコードは不要で、エンコードしてもしなくても同じ意味です。
• 予約文字：一般的な区切り文字: / ? # [ ] @と、補助的な区切り文字! $ & ' ( ) * + , ; =。URLの構造を表すことがあるため、URLの構文ではなくデータの一部として使う場合は、必ずパーセントエンコードが必要です。

それ以外の文字は、空白、%自体、引用符、山括弧、そして日本語をはじめすべての非ASCII文字を含め、そのままではURLに使えず、常にエンコードが必要です。よく使うものを挙げます。

コンポーネント、URL全体、RFC 3986、フォームの使い分け

同じ入力でも、結果をどこに入れるかによってエンコードの形が変わります。入力がTom & Jerry's (2024)/üの場合は次のとおりです。

• コンポーネントはTom%20%26%20Jerry's%20(2024)%2F%C3%BCになります。JavaScriptのencodeURIComponentで、英数字と- _ . ! ~ * ' ( )以外をすべてエンコードします。クエリの値1つ、パスの1区間、または別のURLのパラメータに入れるURL（リダイレクト先など）に使います。
• 厳密なRFC 3986はTom%20%26%20Jerry%27s%20%282024%29%2F%C3%BCになります。encodeURIComponentが残す! ' ( ) *も、RFC 3986が補助的な区切り文字として予約しているため、追加でエンコードします。厳密なパーサーや、リクエスト署名の仕組みがRFCどおりの文字集合を求める場合に使ってください。
• フォームはTom+%26+Jerry%27s+%282024%29%2F%C3%BCになります。WHATWG URL標準のapplication/x-www-form-urlencoded形式（英語）に従い、英数字と* - . _だけをそのまま残し、空白は+にします。HTMLフォームやURLSearchParamsが送るのがこの形式です。
• URL全体はTom%20&%20Jerry's%20(2024)/%C3%BCになります。encodeURIで、完成したURLの中ですでに役割を果たしているものとして; / ? : @ & = + $ , #を残します。空白や非ASCII文字を含む完成済みのアドレスを整えるときだけ使ってください。値には絶対に使わないでください。値の中の&が、気づかないうちに新しいパラメータを始めてしまいます。

%20と+：URLの中の空白

2つの規約が並び立っています。RFC 3986のURL構文では、空白は常に%20で、+はただのプラス記号です。一方、ブラウザがGETでフォームを送信するときのフォームエンコード形式では、空白を+で書き、この形式のWHATWGのパーサーは、パーセントデコードの前にすべての+を空白に置き換えます。そのため、?q=a+bはフォームデータのパーサーには「a b」と読まれますが、パスの/a+bは「a+b」のままです。

デコーダーにデコード時に+を空白として扱うオプションがあるのは、このためです。フォーム、検索ボックス、ほとんどの解析ツールが作るクエリ文字列にはチェックを入れてください。パスや、name+tag@example.comのようなメールアドレス（name%2Btag%40example.comとエンコードされます）のように、プラスが本物の値には、チェックを外したままにします。

コードでの書き方

• JavaScript：値にはencodeURIComponent()とdecodeURIComponent()、URL全体にはencodeURI()、+で空白を表すフォーム形式のクエリ文字列にはURLSearchParamsを使います（MDNを参照）。
• Python：urllib.parse.quote()は初期設定で/をエンコードせず、空白を%20にするので、パス向きです。quote_plus()は/もエンコードして空白を+にするので、フォームの値向きです（Pythonのドキュメントを参照）。
• PHP：rawurlencode()はRFC 3986に従い、空白を%20にします。urlencode()は空白を+にします（PHPマニュアルを参照）。

URLエンコードでよくある問題

二重エンコード：%20ではなく%2520になる

URLに%2520や%253Aのような並びがある場合、すでにエンコード済みの文字列がもう一度エンコードされています。%25は、エンコードされたパーセント記号だからです。1回デコードして結果を確認してください。デコード結果にまだパーセントの並びが残っていると、このツールが警告し、結果を入力に戻すで次の層をデコードできます。コード側の直し方は、URLを組み立てる時点で、各値をちょうど1回だけエンコードすることです。

「Malformed URI sequence」というエラー

厳密なデコーダーは、後ろに16進数2桁が続かない%や、UTF-8として正しくないバイト列を拒否します。このデコーダーは寛容です。有効な並びはすべてデコードし、孤立した%はそのまま残し、不正なバイトは置換文字の�に置き換えたうえで、そのことを知らせます。何も得られずに終わるのではなく、壊れた箇所を探せます。

値が#や&で途切れる

パラメータが途中で切れて届く場合は、値にエンコードされていない#や&が含まれていたことが原因です。多くは、URLを文字列連結で組み立てたか、URL全体方式でエンコードしたときに起こります。値はコンポーネント方式でエンコードしてください。

URL全体をエンコードすると壊れる

完成したURLをコンポーネント方式に通すと、https://がhttps%3A%2F%2Fになります。それが正しいのは、そのURL自体が別のURLのパラメータの値である場合だけです。そうでなければ、差し込む部分だけをエンコードするか、URL全体方式を使ってください。

関連するURLツール

キャンペーン用のリンクはUTMビルダー、トラッキングパラメータの除去はURLクリーナー、リンクがたどる転送の経路はリダイレクトチェッカーで確認できます。スクリプトをワンクリックのブックマークにするときは、ブックマークレットメーカーがパーセントエンコードを代行します。作業中にRFCのような資料ページを保存するなら、Marqlyなら1つの検索できるライブラリにまとまります。詳しくは開発者向けのMarqlyをご覧ください。