無料URLエンコーダー/デコーダー

URLとURIコンポーネントを即座にエンコードまたはデコードします。

データがデバイスから出ることはありません

encodeURIComponent encodeURI

入力

出力

URLエンコーディングについて

URLエンコーディング（パーセントエンコーディングとも呼ばれる）は、URLで許可されていない文字を安全に送信できる形式に変換します。特殊文字はパーセント記号（%）に続く、その文字のバイト値を表す2桁の16進数に置き換えられます。

エンコーディングルールの簡単な歴史

パーセントエンコーディングの慣習は RFC 1738("Uniform Resource Locators (URL)"、Tim Berners-Lee、Larry Masinter、Mark McCahill、1994年12月)、IETF が公開した最初の正式な URL 仕様にさかのぼります。RFC 1738 はオリジナルの「reserved」文字セット(URL で構造的意味を持ち、データとして機能するときエンコードされなければならない文字)とオリジナルの「unreserved」セット(エンコーディングを必要としない文字)を定義しました。仕様は RFC 2396(Berners-Lee、Fielding、Masinter、1998年8月)で大幅に改訂され、その後決定的に RFC 3986("Uniform Resource Identifier (URI): Generic Syntax"、Berners-Lee、Fielding、Masinter、2005年1月)で改訂されました、これは今日でも正式な URI 仕様のままです。RFC 3986 は unreserved セットを拡張してチルダ(~)を含め、UTF-8 を IRI で非 ASCII 文字のエンコーディングとして正式化し、reserved 文字がパーセントエンコードされるべきかそのままにすべきかのルールを厳しくしました。非 ASCII URI には、RFC 3987("Internationalized Resource Identifiers"、Duerst と Suignard、2005年1月)が URL がネイティブ Unicode 文字を含むことを許可する IRI 拡張を定義し、UTF-8 + パーセントエンコーディングを介して IRI 形式を標準 URI 形式にマッピングします。ドメイン名特に、RFC 3492 は Punycode(Costello、2003年3月)を定義しました、DNS で Unicode ドメインラベル(xn--exmpla-...)を表現するために使用されるエンコーディングで、構造的に類似しているが異なるアルゴリズムに基づいています。現代の web の事実上の URL 仕様は WHATWG URL Living Standard、Anne van Kesteren が編集、これは実際のブラウザ動作をエンコードし、URL が実際にどう動作するかとの後方互換性のために RFC 3986 から時々分岐します。

Reserved、unreserved、そして常にエンコードされる文字

スペースは%20に、アンパサンドは%26に、等号は%3Dになり、アクセント付き文字や絵文字などの非ASCII文字はUTF-8バイトシーケンスにエンコードされます。文字、数字、そして - _ . ~ の文字は決してエンコードされません（非予約文字）。

encodeURI と encodeURIComponent、いつどちらを使うか

JavaScript は2つの組み込みエンコーダを提供します、両方とも1999年(ES3)以降 ECMAScript で標準化されています。2つの間の選択は web コードで最も一般的な URL エンコーディング決定で、間違えるとシンプルな入力でテストを通過するが、& 記号、# 記号、または / を含む実際のユーザーデータで壊れる微妙なバグを生成します。

encodeURIComponent、unreserved セット以外のすべてをエンコードします。単一のデータ片を URL に挿入するためにエンコードするときに使用します、クエリパラメーターの値、パスセグメント、フラグメント識別子、フォームフィールド値。文字列 hello world&more は hello%20world%26more になります、内部の & 記号がエンコードされているので、URL が後で読まれるときクエリパラメーター区切り文字として解釈されません。「ユーザー入力があり、それを安全に URL に置きたい」のための適切なツールです。
encodeURI、URL のどこでも違法な文字のみをエンコードします。reserved 文字(: / ? # [ ] @ ! $ & ' ( ) * + , ; =)を意図的にそのままにします、それらが構造的役割を果たす可能性があるからです。構造が既に整っている URL 全体をエンコードするときに使用します、独自の ? と & 区切り文字を含む URL、URL の文法を破壊せずにエンコードする必要があるパスやクエリの非 ASCII 文字を持つ URL。文字列 https://example.com/search?q=hello world は https://example.com/search?q=hello%20world になります、スラッシュと疑問符は保持され、スペースのみがエンコードされます。

メンタルルール:データには encodeURIComponent、URL には encodeURI。間違ったものを使うと、URL 構造を壊すか(URL 全体に encodeURIComponent を使うと必要なスラッシュと & 記号がエスケープされる)、ユーザー入力エスケープを壊すか(クエリ値に encodeURI を使うと & 記号がすり抜けてデータが複数のパラメーターとしてパースされる)のどちらかです。

application/x-www-form-urlencoded、もう1つのエンコーダ

HTML フォーム送信に特に使用される、関連する2つ目のエンコーダがあります、application/x-www-form-urlencoded。1つの詳細を除いて URL パーセントエンコーディングとほぼ同じです、スペースは %20 ではなく + としてエンコードされます。この慣習は元の HTML フォーム仕様から来ており、URL Living Standard では application/x-www-form-urlencoded シリアライザに特に保持されています。フォームエンコードデータのデコーダはこの慣習を反転しなければなりません、フォームデータ内のリテラル + は %2B としてエンコードされ、エンコードされた文字列内の + はスペースにデコードされます。JavaScript の URLSearchParams API はこの慣習を自動的に処理します、encodeURIComponent はそうしません、常にスペースを %20 としてエンコードします。HTML フォームアクションのために手動で組み立てられたクエリ文字列には、各値で個別に encodeURIComponent を呼び出すのではなく URLSearchParams を使用してください。

このツールが実際に必要な場合

API 呼び出しのデバッグ。 スペースや特殊文字を含むクエリパラメーターで REST エンドポイントをクエリし、400 エラーや予期しない結果を取得します。ここでパラメーター値をエンコードし、結果をリクエストに貼り付け、API が入力を正しく扱うことを確認します。
共有可能な URL を手動で構築する。 検索結果ページへのディープリンクを構成する、SaaS ダッシュボードのフィルタービュー、または事前入力されたフォーム、検索クエリや選択状態を URL に埋め込む必要がある場所ならどこでも。
キャプチャされた URL を実際に何を含んでいるかを読むためにデコードする。 ログされた URL に %E2%9C%93%20done が含まれます、デコードすると何ですか? 貼り付け、Decode をクリック、✓ done を見ます。
OAuth と webhook URL。 OAuth フローの redirect_uri パラメーターは正確にパーセントエンコードされなければなりません、間違えると不透明な「redirect_uri mismatch」エラーが生成されます。ユーザーデータを含むパラメーターを含む webhook URL は慎重なエンコーディングを要求します。
ダウンロードリンクの非 ASCII 文字ファイル名。 café-menu.pdf という名前のファイルへの直接リンクは、リンクがすべてのブラウザとシェルツールで機能するように é をパーセントエンコードする必要があります。
データベース接続文字列。 PostgreSQL、MySQL、その他類似のデータベースの URL(postgres://user:p@ssw0rd@host/db)は、URL パーサーを混乱させる @、:、/、その他の reserved 文字を含む場合、パスワードをパーセントエンコードする必要があります。

セキュリティ、エンコーディングが美学を超えて重要な理由

正しくない URL エンコーディングは古い web 脆弱性の源です。HTTP response splitting は HTTP ヘッダーに反映される URL パラメーターのエンコードされていない改行(CR、LF、%0D%0A)を悪用し、攻撃者が任意のヘッダーまたは完全なレスポンスさえ注入することを許します。Open redirect はリダイレクトする前にユーザー提供 URL を正しくデコードして検証しない素朴な URL 処理を悪用します。Server-side request forgery (SSRF) はエンコードされた文字を悪用して URL ホワイトリストをバイパスする可能性があります、「http://internal」をブロックする正規表現は、サーバーがフィルタリング後にデコードする場合「http://%69nternal」を見逃します。URL パラメーターを介した SQL インジェクションはそれ自体は URL エンコーディングの問題ではありませんが、単一引用符と他の SQL メタ文字がデータベースクエリまで生き延びると悪化します。OWASP の2000年代初頭からの推奨は:入力境界でエンコードし、出力境界でデコードし、同じバッファでエンコードされた形式とデコードされた形式を決して混合しません。このツールはエンコード/デコードのステップそのものを実行します、結果で何をするかはあなた次第で、セキュリティの責任はアプリケーション層にあります。

二重エンコーディング、最も一般的なバグ

二重エンコーディングは既にエンコードされた文字列が再びエンコードされたときに発生します。既にエンコードされた URL のスペース文字は %20 です、再びエンコードすると %2520 になります(% 自体が %25 としてエンコードされます)。受信者が一度デコードすると、スペースの代わりに %20 を取り戻します。二度デコードすると(二重デコードがサポートされる稀なケース)、スペースを取得します、しかしほとんどのパーサーはそうしません、URL は静かにアドレスバーに表示される %20 を含みます。修正は常に:入力が既にエンコードされているかどうか不明な場合は最初にデコードし、それから正確に1回エンコードします。同じパターンがコードに適用されます、同じ文字列で encodeURIComponent を二度呼び出さないでください。あるコンテキストから別のコンテキストに値を転送する必要がある場合、新しいコンテキストのために再エンコードする前に前のエンコーディングをデコードします。このツールの Swap ボタンは診断サイクルを助けます、疑わしい URL を貼り付け、Decode をクリックして何を含むかを見て、Swap をクリックし、Encode をクリックして標準のエンコードされた形式を取り戻します。

プライバシー、ブラウザ内のみで実行

URL は機密データをしばしば埋め込みます、クエリパラメーターの認証トークン、パスセグメントのユーザー識別子、個人的なコンテキストを含む検索クエリ、OAuth state 値、API キーを含む webhook URL。サーバー側 URL エンコーダは貼り付けるすべての URL のコピーをログに保持します。このツールは JavaScript の組み込み関数 encodeURIComponent、encodeURI、decodeURIComponent、decodeURI をブラウザタブ内でローカルに実行して使用します。アップロードステップなし、テレメトリなし、ログなし、Encode をクリックする間に DevTools の Network タブを確認(リクエストは出ません)するか、読み込み後にページをオフライン(機内モード)にしてもエンコーダはまだ動作します。トークン、API キー、内部エンドポイントを含む URL、または見知らぬ人のハードドライブにコピーされたくない URL に安全です。

よくある質問

いつテキストをURLエンコードすべきですか？

ユーザー入力をURLに含める場合は必ずテキストをURLエンコードすべきです, 例えば、クエリ文字列内の検索クエリ、パス内のファイル名、APIリクエストパラメータ内のデータなど。エンコーディングがなければ、特殊文字がURL構造を壊したり、セキュリティ上の脆弱性をもたらしたりする可能性があります。

二重エンコーディングとは何で、どうすれば避けられますか？

二重エンコーディングは、すでにエンコードされたテキストが再度エンコードされるときに発生し、%20が%2520になります。これは通常、コードがすでにエンコードされた文字列をエンコードするときに起こります。テキストがすでにエンコードされているかどうか不明な場合は、常に最初にデコードしてから一度だけエンコードしてください。

このツールは機密URLに対して安全ですか？

はい。このツールはJavaScriptの組み込みエンコーディング関数を使用して、完全にブラウザ内で実行されます。サーバーにデータは送信されません。インターネットから切断して確認できます, ツールは引き続き動作します。

なぜフォームデータには %20 ではなくプラス記号があるのですか?

HTML フォーム送信は application/x-www-form-urlencoded と呼ばれる別の関連エンコーディングを使用し、歴史的慣習によりスペースを %20 ではなく + としてエンコードします。両方の形式は URL クエリ文字列で有効です、現代のパーサーはどちらも受け入れます。JavaScript の URLSearchParams API はフォーム慣習を使用します、encodeURIComponent は常に %20 を使用します。データが古いフォーム処理コードと相互運用する必要がある場合、URLSearchParams を使用してください、そうでない場合、どちらの形式も問題ありません。

非 ASCII 文字と絵文字はどうですか?

現代の URL エンコーディングは UTF-8 を使用します、各非 ASCII 文字はマルチバイト UTF-8 表現に変換され、各バイトはパーセントエンコードされます。ユーロ記号(€、3バイト UTF-8)は %E2%82%AC になります、ロケット 🚀(4バイト)のような絵文字は %F0%9F%9A%80 になります。RFC 3987(IRI)と WHATWG URL Standard は両方とも UTF-8 ファースト慣習を正式化します。古いシステムは時々 Latin-1 や他のエンコーディングを使用しました、古い URL をデコードして結果が文字化けして見える場合、ソースはパーセントエンコーディングの前に異なる文字エンコーディングを使用したかもしれません。