MT
My Toolbox

URLエンコーダー＆デコーダー — URLの特殊文字を変換

特殊文字を含むURLを貼り付けてパーセントエンコード版を即座に取得、または%20%3Fだらけの文字列を読めるテキストに戻す。ブラウザ内蔵のencodeURIComponent/decodeURIComponentと同じ処理。データはブラウザから出ない。

入力テキスト
入力テキスト
エンコードするURLを入力
エンコード出力
エンコード出力
URL文字列をエンコードとデコード

URL Encoding converts special characters into a format that can be transmitted over the internet.

For example, spaces become %20, and other special characters like &, =, and ? are also encoded.

This tool uses encodeURIComponent() anddecodeURIComponent() functions, which encode all characters except:

  • Alphabetic characters (A-Z, a-z)
  • Digits (0-9)
  • Special characters: - _ . ! ~ * ' ( )

URLエンコードの仕組み（RFC 3986）

URLには限られたASCII文字セットしか含められない。それ以外——スペース、日本語、データとして使う予約区切り文字——はすべて「パーセントエンコード」が必要：%の後に2桁の16進数でバイト値を表す。スペースは%20、クエリ値内のスラッシュは%2F、日本語の「あ」は%E3%81%82（UTF-8の3バイト）になる。

これは任意ではない。クエリパラメータ値に生の&を入れると、サーバーはそれをパラメータ区切りとして解釈し、データとして扱わない。このバグは何十回もデバッグした——会社名に&が入っていてエンコードし忘れ、APIが「パラメータ不足」を返すパターン。

仕様（RFC 3986 セクション2.1）は「非予約文字」を定義している：A-Z、a-z、0-9、- _ . ~。これらはエンコード不要。それ以外は予約文字（URLで特別な意味を持つ）かエンコード必須。厄介なのは：予約文字をエンコードするかどうかはコンテキスト次第。パスの/は区切りだが、クエリパラメータ値内の/はデータなので%2Fにエンコードする必要がある。

使い方

  1. エンコードまたはデコードモードを選択。
  2. テキストを貼り付けまたは入力——完全なURL、クエリパラメータ値、またはエンコード済み文字列。
  3. 入力と同時に結果が更新。ワンクリックでコピー。
  4. エンコード時は値の部分だけ貼り付ける（URL全体ではなく）。構造まで二重エンコードしないように。

使用場面

ユーザー入力でクエリ文字列を構築

ユーザーが「靴 & バッグ」を検索——その&をエンコードしないとサーバーが2つのパラメータに分割する。encodeURIComponent("靴 & バッグ")で安全なエンコード文字列を取得し、?q=に入れる。

OAuthとリダイレクトURLのデバッグ

OAuthフローはredirect_uriをクエリパラメータとして渡す。そのURI自体に?と&が含まれる。リダイレクトURL全体をエンコードして単一パラメータ値として安全に転送する必要がある。ここでの二重エンコードバグは「invalid redirect_uri」エラーを引き起こし、追跡が困難。

トラッキングリンクとUTMパラメータのデコード

マーケティングツールが生成するURLのUTMパラメータはエンコード済みで読めない。完全なURLをここに貼り付けて、utm_campaign、utm_sourceが実際に何と書いてあるか確認。%20と%3Dを手動で解析する必要なし。

URLパラメータでJSONや特殊データを渡す

一部のAPIはクエリ文字列でJSONを受け付ける（良くない慣行だが存在する）。{ } "の文字はすべてエンコードが必要。このツールでハードコードする前にエンコード後の姿を確認できる。

よくある間違い

1.

URL全体をエンコードしない——値だけ

encodeURIComponent("https://example.com/path?q=hello")は://や?もエンコードしてURL構造を壊す。個々のパラメータ値をエンコードする。URL全体を構造を保ったままエンコードしたい場合はencodeURI()を使う。

2.

二重エンコードに注意

値がすでにエンコード済み（%20）なのに再度エンコードすると%20が%2520になる（%が%25にエンコードされる）。URL処理コードで最も多いバグ。フレームワークが自動エンコードしていないか確認してから追加のエンコードを入れること。

3.

+と%20のスペース表現——違いを知る

クエリ文字列（application/x-www-form-urlencoded）では+がスペースを意味する。パスセグメントでは%20のみ有効。JavaScriptのencodeURIComponentは常に%20を使う。デコード時に+が見えたら、先に+をスペースに置換する必要があるかも——decodeURIComponentは自動でやってくれない。

4.

UTF-8エンコードがパーセントエンコードの前に起こる

文字éはまずUTF-8バイト（0xC3 0xA9）にエンコードされ、各バイトがパーセントエンコード（%C3%A9）される。システムがUTF-8でなくLatin-1を使っていると%E9になる——2バイトでなく1バイト。この不一致が文字化けを引き起こす。常にUTF-8を使うこと。

例

特殊文字を含む検索クエリのエンコード

ユーザーが"C++ tutorials & guides"を検索——3つの特殊文字すべてエンコードが必要。

Input

C++ tutorials & guides

Output

C%2B%2B%20tutorials%20%26%20guides

トラッキングURLパラメータのデコード

マーケティングURLにエンコードされたリダイレクトが含まれている——デコードして実際の遷移先を確認。

Input

https%3A%2F%2Fexample.com%2Flanding%3Futm_source%3Dnewsletter%26utm_campaign%3Dspring

Output

https://example.com/landing?utm_source=newsletter&utm_campaign=spring

機能

  • エンコードとデコードモードを即座に切り替え
  • 標準のencodeURIComponent/decodeURIComponent使用——ブラウザと同じ
  • Unicode、絵文字、マルチバイト文字を正しく処理
  • 入力中にリアルタイムで結果表示——送信ボタン不要
  • ワンクリックでクリップボードにコピー
  • 100%ブラウザ内で動作——ネットワークリクエストゼロ、データ収集なし

よくある質問

encodeURI()とencodeURIComponent()の違いは？

encodeURI()は完全なURLをエンコードする——:、/、?、#、&はそのまま（構造的だから）。encodeURIComponent()はA-Z、0-9、- _ . ! ~ * ' ( )以外すべてエンコード。実務ではほぼ常にencodeURIComponent()を使う。値をURLの中に入れるためにエンコードするのであって、URL自体をエンコードするのではないから。

パラメータ値に&や=があるとなぜ壊れる？

&はパラメータ区切り、=はキーと値の区切りだから。値にこれらの文字がそのまま入っていると、パーサーがそこで分割する。値をエンコード："Tom & Jerry"は"Tom%20%26%20Jerry"になる。パーサーはエンコードされた&を含む1つのパラメータとして認識する。

スペースは%20と+どちらを使うべき？

コンテキスト次第。application/x-www-form-urlencoded（HTMLフォーム）のクエリ文字列では+がスペース。URLパスセグメントでは%20のみ有効。JavaScriptのencodeURIComponent()は常に%20を生成。ほとんどのサーバーはクエリ文字列で両方受け付けるが、パスセグメントを構築するなら%20を使う。

Unicode文字（絵文字、日本語）はどうエンコードされる？

文字はまずUTF-8バイトに変換され、各バイトがパーセントエンコードされる。絵文字🎉は4つのUTF-8バイト：F0 9F 8E 89で%F0%9F%8E%89になる。日本語「中」は3バイト：E4 B8 AD → %E4%B8%AD。このツールはすべて自動処理——貼り付けるだけ。

二重エンコードとは何？どう直す？

二重エンコードはエンコード済み文字列を再度エンコードすること。%20が%2520になる（%が%25にエンコードされる）。よくある原因：フレームワークが自動エンコードしているのに手動でもencodeURIComponent()を呼んでいる。修正：まずデコード（生の値を取得）してから1回だけエンコード。またはHTTPライブラリがエンコードを処理済みか確認（ほとんどする——axios、fetchとURLSearchParamsなど）。

ヒントと関連ワークフロー