URLエンコードとデコードのイメージ

URLの「%E3%81%82」は何を表しているのか

URLを扱っていると、%E3%81%82 や %20 のような記号混じりの文字列を見ることがあります。これはURLエンコードされた文字列です。日本語、空白、記号など、URLの中でそのまま使いにくい文字を安全に送るために変換されています。

DevToolKitsの URLエンコード・デコードツール を使うと、文字列を貼り付けるだけでエンコード前後の形を確認できます。

実例：日本語検索キーワードをURLに入れる

たとえば、検索キーワードとして 東京 駅 カフェ をURLに入れたいとします。空白と日本語をそのまま扱うと、環境によって表示やコピー時に崩れることがあります。

東京 駅 カフェ

URLエンコードすると、次のような文字列になります。

%E6%9D%B1%E4%BA%AC%20%E9%A7%85%20%E3%82%AB%E3%83%95%E3%82%A7

これをクエリパラメータに入れると、共有しやすいURLになります。

https://example.com/search?q=%E6%9D%B1%E4%BA%AC%20%E9%A7%85%20%E3%82%AB%E3%83%95%E3%82%A7

デコードして元の文字列に戻ることまで確認しておくと、検索条件の取り違えや文字化けを見つけやすくなります。

エンコードが必要になる場面

検索キーワード、キャンペーン名、日本語のファイル名、コールバックURLなどをURLに含める場合、文字を正しくエンコードしないとリンクが途中で切れたり、別の値として解釈されたりします。

たとえば hello world の空白は %20 や + として扱われることがあります。APIやフォームによって期待する形式が違うため、実際に送るURLを確認しておくと安心です。

実例：コールバックURLを二重に扱わない

OAuthや外部連携では、URLの中に別のURLを値として入れることがあります。

https://app.example.com/callback?next=/dashboard?tab=billing

このような値を redirect_uri に入れる場合、値として渡すURL部分をエンコードします。

redirect_uri=https%3A%2F%2Fapp.example.com%2Fcallback%3Fnext%3D%2Fdashboard%3Ftab%3Dbilling

ここで注意したいのは、すでにエンコード済みの値をもう一度エンコードしてしまうケースです。% が %25 に変わっていたら二重エンコードの可能性があります。デコード結果を確認し、期待したURLに戻るかを見ると原因を切り分けやすくなります。

クエリ文字列もあわせて確認する

URL全体が長くなると、どのキーにどの値が入っているか分かりにくくなります。UTMやAPIパラメータを確認するときは、URLパラメータJSON変換ツール でキーと値を整理すると、入力ミスや不要なパラメータを見つけやすくなります。

まとめ

URLエンコードは地味ですが、リンク共有、API検証、広告計測でよく事故が起きる部分です。日本語や記号を含むURLを扱うときは、公開前にエンコード結果とパラメータ構造を確認しておくと、あとからの調査がかなり楽になります。