URLエンコーダー
特殊文字をエンコードして、テキストをURLセーフ形式に変換します。
エンコードするテキストを入力してください：
URL Encoder / Decoder の使い方
- 1
テキストまたは URL を入力する
エンコードしたいテキスト、またはデコードしたい URL エンコード済みの文字列を入力ボックスに貼り付けます。
- 2
エンコードかデコードを選ぶ
テキストを URL に安全な形式に変換するには「Encode」を、パーセントエンコードされたテキストを元に戻すには「Decode」を選びます。
- 3
変換を実行する
入力を処理して、選んだ方向に即座に変換します。
- 4
結果をコピーする
エンコードまたはデコードした出力をコピーして、リンク、クエリ文字列、API リクエストで利用します。
URLエンコーディングとパーセントエンコーディングの解説
URLエンコーディングとは何か
URLエンコーディングは、より正確にはパーセントエンコーディングと呼ばれ、URLが本来表現できない文字を運べるようにする仕組みです。URLは小さなASCII文字の集合に制限されており、そのうちのいくつかは特別な構造上の意味を持っています。パーセントエンコーディングは、問題のある文字を、パーセント記号に続けてそのバイト値の16進数2桁で置き換えます。そのためスペースは %20 に、ハッシュは %23 になります。
そのルールは、URI構文を統べる規格である RFC 3986 で定義されています。目的は単純です。URLの中に置かれた値が、紛れ込んだ文字を区切り文字と取り違えられたり、途中のソフトウェアに削り落とされたりすることなく、意図したとおりに正確に伝送されパースされるようにすることです。
予約文字と非予約文字
RFC 3986 は文字をグループに分けます。非予約の集合は常に安全で、決してエンコードされません。文字 A-Z と a-z、数字 0-9、そして4つの記号、ハイフン（-）、ピリオド（.）、アンダースコア（_）、チルダ（~）です。これらは構造上の意味を持たず、URLのどこでも合法なので、手を加えられずに通過します。
予約の集合は、URLの各部分を区切る記号です。一般的な区切り文字 : / ? # [ ] @ と、サブ区切り文字 ! $ & ' ( ) * + , ; = です。これらの文字は区切りとしては合法ですが、区切りとしてではなく値の中に現れるときは、パーサーが読み違えないようにパーセントエンコードしなければなりません。たとえば、クエリの値の中のアンパサンドは %26 にならなければならず、さもなければ新しいパラメーターの始まりと読まれてしまいます。
UTF-8バイトという基盤
パーセントエンコーディングは、文字を直接ではなくバイトに対して働き、現代のURLはバイトの源としてUTF-8を使います。ASCII文字は1バイトなので、エンコードされたASCII文字は1つのパーセントエスケープです。ASCIIの外の文字は、まずそのUTF-8バイト列として表現され、それから各バイトが別々にパーセントエンコードされて、1バイトにつき1つのエスケープを生み出します。
アクセント付きの文字 é が標準的な例です。UTF-8ではそれは2つのバイト 0xC3 と 0xA9 なので、%C3%A9 にパーセントエンコードされます。1つの見える文字に対して2つのエスケープです。ユーロ記号は、UTF-8では3バイトで、%E2%82%AC になります。これが、非ラテン文字がエンコードされるときにこれほど大きくふくらむ理由です。各文字は、そのUTF-8の長さに応じて2つ、3つ、あるいは4つのパーセントエスケープに変わるからです。
実例: 検索値をエンコードする
語句 "Q&A: cats + dogs" をクエリ文字列に入れたいとしましょう。文字、数字、そしてコロンの周りのテキストは単語のまま残りますが、安全でない文字と予約文字はエスケープされます。スペースは %20 に、アンパサンドは %26 に、コロンは %3A になり、プラス記号は %2B になります。文字どおりのプラスは、さもなければフォームデータでスペースと読まれてしまうからです。
結果は Q%26A%3A%20cats%20%2B%20dogs です。?q=Q%26A%3A%20cats%20%2B%20dogs としてリンクに入れると、サーバーはそれを元の語句どおりに正確にデコードします。区切りとしてではなくデータとして意図された予約文字はすべて、移動を生き延びるためにエンコードされなければならなかったことに注目してください。
スペース: %20 とプラス記号
スペースには有名な癖があります。パスやURLのほとんどでは、スペースは %20 としてエンコードされます。しかし、HTMLフォームの送信や多くのクエリ文字列で使われる application/x-www-form-urlencoded 形式では、スペースは伝統的にプラス記号（+）としてエンコードされます。どちらの慣習も現役で使われており、これがよくある混乱の元です。
実用上の帰結は、フォーム形式のデータの中の文字どおりのプラス記号は、スペースと取り違えられないように、それ自身を %2B としてエンコードしなければならないということです。デコードするときは、その文字列をどちらの慣習が生み出したのかを知らなければなりません。フォームの値の中のプラスはスペースを意味し、一方ほかの場所のプラスはたいてい文字どおりのプラスを意味します。このツールは標準のパーセントエンコーディングを扱うので、あなたの値はきれいに往復します。
URL全体をエンコードするか、単一の値をエンコードするか
JavaScriptは2つの異なる仕事に対応する2つの関数を提供しており、間違ったほうを選ぶのは古典的なバグです。encodeURI はURL全体のためのもので、構造上の文字 : / ? # & = をそのまま残してURLが動き続けるようにし、スペースのような明らかに不正な文字だけをエンコードします。encodeURIComponent は、1つのクエリの値やパスの区間のような、単一のデータの断片のためのもので、予約された区切り文字もエスケープするので、埋め込まれたスラッシュやアンパサンドが周囲のURLを壊すことはありません。
このツールはコンポーネント形式のエンコード、つまり encodeURIComponent の挙動を行います。これは、自分が管理する区切りの間に信頼できない値を挿入するための安全な既定です。予約された区切り文字もエスケープするので、埋め込まれたスラッシュやアンパサンドが周囲のURLを壊すことはありません。その代償として、ここに完全なアドレスを貼り付けるべきではありません。構造上の : / ? # & = の文字もエスケープしてリンクを台無しにしてしまうからです。URL全体をエンコードするには、個々の値やパスの区間をそれぞれエンコードしてから、完成したアドレスを自分で組み立ててください。
二重エンコードの間違い
二重エンコードは最もよくあるパーセントエンコーディングのバグです。これは、すでにエンコードされたテキストをもう一度エンコードするときに起こります。引き金はパーセント記号そのものです。パーセントは予約文字なので、それをエンコードすると %20 が %2520 になります。先頭の % が %25 になり、20 はそのまま残るからです。2回エンコードされた値は、意図したスペースの代わりに、文字どおりのエスケープシーケンス %2520 をエンドユーザーに表示します。
これを避けるには、URLを組み立てるその瞬間にちょうど1回だけエンコードし、すでにパーセントエスケープを含む文字列を決して再度エンコーダーに通さないことです。%25 の後に別のエスケープのようなものが続いているのを見たら、ほぼ間違いなく二重エンコードされたデータを見ているので、その修正は、もう1回だけデコードするか、コードから余分なエンコードの工程を取り除くことです。
どこで使うことになるか
パーセントエンコーディングは、値がURLの中を移動するあらゆる場所にあります。検索やフィルター用のクエリ文字列の組み立て、ユーザーが入力したテキストを含むリンクの作成、REST APIへのパラメーターの受け渡し、return_url パラメーターの中へのリダイレクト先の埋め込み、そしてバイト単位で一致しなければならないリクエストの署名は、すべて正しいエンコードに依存しています。Webサーバーやフレームワークは受信したURLを自動でデコードするので、エンコードされた形は、たいてい読むものではなく自分で生み出すものです。
役立つ習慣は、完成した文字列を一度にエンコードするのではなく、URLを組み立てながら各動的な断片を別々にエンコードすることです。そうすれば区切りをそのまま保ちつつ、すべての値を安全にでき、リンクを壊す過少エンコードと、リンクを破損させる二重エンコードの両方を回避できます。
よくある質問
URL エンコードは実際に何をしますか?
このツールはエンコードとデコードの両方ができますか?
特殊文字や他の言語に対応していますか?
URL 全体をエンコードするのと、単一の値をエンコードするのとの違いは何ですか?
データのプライバシーは守られますか?ツールは無料ですか?
関連ツール
こちらの便利なツールもどうぞ