プレーンテキスト

パーセントエンコード

URLエンコーダーとは？

左のパネルに文字列を入れると、右のパネルにパーセントエンコード版が表示されます。内部では encodeURIComponent が動いていて、URL内で特別な意味を持つ文字をすべてエスケープします — スペースは %20、アンパサンドは %26、アットマークは %40、といった具合です。クエリパラメータの「値」、パスセグメント、その他URLの中に文字列をそのまま流し込んでも壊さない必要があるところで、これが必要なエンコーディングです。

エンコーディングには2種類あって、その違いは重要です。encodeURIComponent（このページ）は ?、#、&、=、/ を含む特別な文字をすべてエスケープします — 値レベルでは、これらの文字がURLの意味を変えてしまうからです。encodeURI はもう少し緩く、構造的な文字はそのままにします。すでに完成済みのURL全体をエンコードする想定だからです。詳細が必要なら MDNが予約文字の表を載せています。パーツからURLを組み立てているなら、このページではなくURL Builderの方を使ってください。

実際のエンコード規則は RFC 3986 §2.1 によります。安全でない各バイトは % に続けてUTF-8バイトの16進2桁で書きます。だからロケットのような絵文字はパーセント3つ組が4つ並びます（UTF-8で4バイトだから）。一方 ! のようなASCIIは1組のままです。WHATWG URL標準がモダンブラウザの実装を定式化していて、手元で照合したいなら Wikipediaのパーセントエンコーディングの記事に綺麗な参照表があります。すべてブラウザ内で完結します。アップロードもログ取得もありません。

URLエンコーダーの使い方

3ステップ。入力するたびにページが更新されます — Convertボタンはありません。

文字列を貼り付けるか、サンプルをクリック

左のパネルに任意のテキストを入力するか貼り付けます。サンプルをクリックすると、実際に出くわすような文字を含んだ文字列が読み込まれます — スペース、アンパサンド、メールアドレス、パーセント記号など。入力例:

Ava Chen & friends? [email protected]  100% off!

Unicodeも絵文字も問題なく動きます — エンコーダーはUTF-8のバイト列を使うので、日本語の名前や絵文字はマルチバイトのパーセント列にエンコードされ、標準準拠のデコーダーならきれいにラウンドトリップします。

エンコード結果を読む

右のパネルにパーセントエンコード版が表示されます。スペースは %20、& は %26、? は %3F、@ は %40、% 自体は %25 になります。入力すると同時に更新されます。

コピーまたはダウンロード

コピーをクリックするとエンコード後の文字列がクリップボードに入ります。ダウンロードを押すと .txt ファイルとして保存されます。最初からやり直すには入力パネルのクリアを使ってください。逆方向の変換は URLデコーダーへどうぞ。

こういう時に実際使う

クエリ文字列の値を手で組み立てる

curlでのちょっとしたテストやディープリンクのために ?customer=Ava%20Chen&status=active を作る必要がある？それぞれの値をここでエンコードしてURLに貼り付けるだけです。& を含む値（「Smith & Co.」のような顧客名）のエンコードを忘れる、これが「APIにパラメータの半分しか届いてない」という謎バグの定番の原因です。

リダイレクト先URLをエンコードする

OAuthフローやSSOリダイレクトは、行き先のURLをクエリパラメータの中に入れて渡します（例: ?return_to=...）。その行き先URL自体に :、/、?、& が含まれていて、それぞれパーセントエンコードしないと外側のURLが整形式でなくなります。RFC 6749 §3.1.2 がOAuthのリダイレクトURIについてはっきりこれを書いています。

スラッシュを含むパスセグメントをエンコードする

REST APIに /repos/:owner/:name のようなルートがあって、name にスラッシュが入る場合（珍しいですが一部のカタログでは合法）、スラッシュを %2F にエンコードしないとルーターがパスの区切りとして解釈してしまいます。ダウンロードURLに含まれるスペースやアクセント付きのファイル名でも同じ理屈です。

URLに渡る前にユーザー入力をサニタイズする

HTMLフォーム、検索ボックス、CSVインポートなどからURLに入る文字列は、エンコードが必要です。エンコードされていないユーザー入力こそが、リンク切れ、パラメータ・インジェクション、ASCIIユーザーには動くのに他の人には黙って失敗するURLの原因です。OWASPのパストラバーサルに関するノートは、このステップをスキップする代償をよく思い出させてくれます。

よくある質問

encodeURIComponentを使うべき？それともencodeURI？

ほぼ常に encodeURIComponent です — このページが使っているのもそれです。クエリパラメータの値、パスセグメント、その他URLの「ピース」として文字列を入れたい場面ではこれが正解です。encodeURI は構造的にすでに完成しているURLをエンコードするためのものです（実務では珍しい — 普通はパーツから組み立てるので）。上にリンクしたMDNのリファレンスに、それぞれが何をエスケープするかの表が載っています。

スペースが+になる時と%20になる時があるのはなぜ？

2つのエンコーディングの伝統が並存しているからです。application/x-www-form-urlencoded（HTMLフォーム送信の ?key=value ボディ）はスペースに + を使います。RFC 3986 の一般的なURLパーセントエンコーディングは %20 を使います。encodeURIComponent は常に %20 を出します。たいていのサーバーは両方受け付けますが、下流のデコーダーがフォーム形式に厳格なら、エンコードした後で .replace(/%20/g, "+") で置き換えてください。

絵文字や非ASCIIテキストは正しく扱えますか？

はい。エンコーダーはまず入力をUTF-8でシリアライズし、それから各バイトをパーセントエンコードします。なので絵文字はマルチバイトのパーセント列になり、標準準拠のデコーダーならきれいに元に戻ります。Latin-1や他のレガシーエンコーディングを使うシステムと連携しているなら別の問題です — 上流のシステムを変えるべきで、UTF-8でないエンコーダーを自作するのはやめましょう。

encodeURIComponentがエンコードしない文字は？

英字 A-Z と a-z、数字 0-9、それと非予約文字 - _ . ! ~ * ' ( ) です。それ以外はすべてパーセントエンコードされます。リストは元の仕様そのままで、モダンなJavaScriptエンジンすべてで固定です — 厳密な根拠が欲しければ ECMAScript仕様のencodeURIComponent を見てください。

ここに貼り付けた入力はどこかに送信されますか？

いいえ。エンコードはJavaScriptエンジン経由で完全にブラウザ内で動きます。ネットワーク呼び出しもサーバーもログもありません。シークレットでもトークンでも何でも貼り付けてください — マシンの外には出ません。

ここでエンコードできる文字列の最大サイズは？

入力には256 KBの上限があります。実世界のURL値はせいぜい数キロバイトです。数MBのデータをエンコードする必要があるなら、ほぼ間違いなくPOSTのボディに入れるべきものをURLに埋め込もうとしています — サーバー側でエンコードして、ブラウザを経由するのはやめましょう。

その他のURL・エンコーディングツール

エンコーディングは1つの操作です。自然に組み合わさるツールはこちら: