URLエンコーダー

URLエンコーダーは、文字列をURLのクエリパラメーターや、テキストベースのWebデータで使われるフォームエンコード形式に変換する無料ツールです。

URLエンコードとは何ですか？ なぜ必要ですか？

URLエンコードでは、URL内で特別な意味を持つ文字を、パーセント記号と16進数の組み合わせに置き換えます。これにより、使用できる文字が制限されたシステムでもテキストを受け渡せます。

たとえば、アンパサンドはクエリパラメーターの区切りに使われるため、値の一部として含める場合は%26にエンコードする必要があります。スペースにも特別な処理が必要です。このツールはPHPのurlencode関数を使用し、スペースをプラス記号に変換します。

変換前: tea and cake

変換後: tea+and+cake

URLエンコードされたテキストは、次のような場所で使われます。

• Webフォームから送信されるクエリ文字列
• そのまま記述できないテキストを含むデータURI
• メール本文に含まれるリンク
• JSONペイロードに保存されるURL値
• Webアプリケーションで使われるリダイレクトパラメーターやコールバックパラメーター
• 国際化ドメインに関連するURL。ただし、ドメイン名自体にはパーセントエンコードではなくPunycodeが必要な場合があります

URLエンコードは暗号化ではなく、内容を秘密にするものではありません。パーセントエンコードされたURL値を見られる人なら、誰でもデコードできます。

URLエンコーダーの使い方は？

エンコードする文字列を入力してツールを実行し、URLエンコード済みの結果欄に表示された変換後の値を確認してください。値を囲む引用符や説明文は含めず、値そのものだけをエンコードします。

処理はサーバー上で行われます。入力内容はHTTPS経由でサーバーに送信され、保存されません。それでも、パスワード、セッショントークン、非公開の個人情報はURLに含めないでください。URLはブラウザーの履歴、アクセス解析システム、サーバーログに残る可能性があります。

元に戻すにはURLデコーダーを使います。エンコード時とデコード時に同じ文字エンコーディングとフォームエンコードの規則を使用していれば、正しくデコードされた値は元のテキストと一致します。

URL全体とパラメーター値のどちらをエンコードすればよいですか？

通常はURL全体ではなく、各パラメーターの値だけをエンコードします。URL全体をエンコードすると、コロン、スラッシュ、疑問符、等号など、URLの構造を示す文字まで置き換えられてしまいます。

検索値がgreen tea & coffeeだとします。エンコード後はgreen+tea+%26+coffeeとなり、パラメーター名の後に配置できます。URL全体をエンコードすると、ブラウザーがスキーム、ホスト、パス、クエリ文字列を識別するために必要な区切り文字まで判別できなくなります。

このツールが使用するurlencodeは、HTMLフォーム形式のクエリパラメーターに適しています。一方、一部のAPIやパスセグメントではRFC 3986の規則が使われ、スペースは+ではなく%20で表されます。送信先のシステムが、+を使うフォームエンコードと、RFC 3986形式の%20のどちらを想定しているか確認してください。

URLエンコードの具体例

ASCIIの英字と数字は読み取れる形のまま残ります。スペースはプラス記号に変換され、予約済みの記号や非ASCIIテキストはエンコードされたバイトで表されます。

• hello worldはhello+worldになります。
• tea & cakeはtea+%26+cakeになります。
• email=test@example.comはemail%3Dtest%40example.comになります。
• 100% readyは100%25+readyになります。
• 元のテキストがUTF-8の場合、caféはcaf%C3%A9になります。

アクセント付き文字やラテン文字以外の文字は、まず文字エンコーディングによってバイト列に変換されます。Webでは通常UTF-8が使われます。その後、許可された範囲外の各バイトが個別にパーセントエンコードされます。そのため、目に見える1文字が、%で始まる複数の組み合わせになることがあります。

数字に特別な処理は必要ありません。入力が空なら、エンコード後の内容も空になります。エンコード対象の各バイトは3文字で表されるため、入力が非常に長いと変換後のデータ量が大幅に増えることがあります。

URLをデコードできない、または文字化けするのはなぜですか？

多くの場合、異なる規則でエンコードされている、複数回エンコードされている、または想定した文字セットのテキストではないことが原因です。

• スペースの扱いが異なる。フォームデコーダーは+をスペースとして扱いますが、厳密なパーセントデコーダーではプラス記号のまま残ることがあります。
• 二重にエンコードされている。%26内のパーセント記号自体が%25に変換され、%2526になることがあります。この場合、1回デコードしても元のアンパサンドではなく%26が返されます。
• 文字エンコーディングが違う。UTF-8のバイト列を別の文字セットとしてデコードすると、置換文字が表示されたり文字化けしたりすることがあります。
• テキストではなくバイナリデータである。デコード後のバイト列が画像、アーカイブ、その他のファイルである場合、テキストとして表示すると意味不明な文字になります。
• 形式や文字体系が違う。URLセーフBase64、標準Base64、パーセントエンコードは、それぞれ異なる形式です。Base64テキストにURLデコーダーを使っても、意図した値には戻りません。

URLエンコードにはパディング文字がありません。デコーダーでパディング不足のエラーが出る場合、入力データはパーセントエンコードされたテキストではなく、Base64などパディングを使用する別の形式である可能性があります。

よくある質問

パーセントエンコードの16進数は大文字でも小文字でも同じですか？

はい。パーセントエンコード内の16進数の英字は大文字と小文字を区別しないため、%2Fと%2fはどちらもスラッシュを表します。表記を統一するには、大文字の16進数が推奨されます。

URLエンコードで国際化ドメイン名を変換できますか？

いいえ。éを含む名前などのドメインラベルには、通常、国際化ドメイン名の処理と、xn--で始まるASCII形式のPunycodeが必要です。パーセントエンコードはURLのほかの構成要素に使うもので、国際化ドメイン名の変換を代替するものではありません。

改行やタブはどう変換されますか？

タブと改行のバイトは一般的なURL値にそのまま記述できないため、パーセントエンコードされます。タブは通常%09で表されます。改行コードは、元のデータがLFとCRLFのどちらを使用しているかによって異なります。

エンコードしたURLをアプリに貼り付けても動かないのはなぜですか？

アプリ側が未加工の値を受け取り、独自にエンコードする仕様の場合、二重エンコードが発生することがあります。また、URL全体の長さ制限を超えている場合や、URLの構造部分にある予約文字がエンコードされている場合も拒否されることがあります。エンコードする前に、アプリがURLのどの構成要素を求めているのか確認してください。

エンコードしたクエリ文字列は共有しても安全ですか？

いいえ。URLのパーセントエンコードは表現形式を変えるだけで、ブラウザーや開発者ツールを使えば元の値を確認できます。リンクを共有する前に、クエリパラメーターにメールアドレス、アカウントの識別情報、アクセストークンなど、公開すべきでないデータが含まれていないか確認してください。