URLエンコーダー＆デコーダー

URL / パーセントエンコーディングは、URL内で安全でないまたは曖昧な文字を%とそのUTF-8バイト値をhexで続けたもので置き換えます。コンポーネントモードはencodeURIComponent()を使用し、予約されたすべての文字をエンコードします — クエリ文字列やパスに埋め込む値に正しい。完全URLモードはencodeURI()を使用し、:/?#&=のようなURL構造的文字を保持します。

例

入力:

hello world & café / 日本語

コンポーネントとしてエンコード:

hello%20world%20%26%20caf%C3%A9%20%2F%20%E6%97%A5%E6%9C%AC%E8%AA%9E

完全URLとしてエンコード:

hello%20world%20&%20caf%C3%A9%20/%20%E6%97%A5%E6%9C%AC%E8%AA%9E

完全URLは&と/を放置しています、URL内で構造的な意味があるから。

よくあるエラーと落とし穴

ほとんどのエンコーディング問題は、間違ったモードを選ぶか、同じ入力でツールを2回実行することから来ます。以下の項目は最も頻繁に見るケースをカバーします。

• クエリ値にencodeURIを使用。 encodeURI("a&b=c")はa&b=cを返します (変更なし)、これはクエリ文字列を壊します。値にはコンポーネントモード (encodeURIComponent) を使用。
• ダブルエンコーディング。 hello%20worldを2度目にエンコードするとhello%2520worldが生成されます。先にデコードするか、1つのレイヤーをスキップ。
• #を忘れる。 クエリ値内の#は%23としてエンコードされない限りフラグメント開始として扱われます。
• プラス記号の混乱。 +はフォームエンコードされたbodyではスペースを意味しますが、URLパスまたはクエリではリテラルな+です。クエリ値で本物のプラス記号を送るには、%2Bとしてエンコード。
• 不正なパーセントシーケンス。 エンコードされたことのないリテラル%はdecodeURIComponentにURI malformedをスローさせます。%を%25としてエンコードするか、デコード前に単独のパーセントを除去。
• UTF-8 vs Latin-1レガシーサーバー。 このツールは常にUTF-8を使用します。一部の非常に古いシステムはLatin-1 / windows-1252を期待します — そこではéは%E9であり、%C3%A9ではありません。mojibakeが見えたら、もう一方のエンドはUTF-8ではありません。

encodeURIとencodeURIComponentの違いは何ですか?

encodeURIComponentは文字、数字、または-_.!~*'()のいずれかではないものをエスケープするので、個々のクエリ値やパスセグメントに安全です。encodeURIは:/?#&=のようなURL予約文字を放置するので、すでに構造を持つ全URLをエンコードするためのものです。95%の時間はコンポーネントを使用。完全URLは、散発的なスペースやUnicodeを持つほぼ有効なURLがあるときのみ使用。

クエリ文字列で実際にエンコードが必要な文字は?

クエリ文字列の区切り文字&と=は値内でエンコードする必要があります (そうしないと区切り文字のように見える)。スペースは%20または+になります。#フラグメントマーカーはエンコードする必要があります。加えて: /、?、非ASCIIのもの、制御文字。encodeURIComponentはこれらすべてを処理します; encodeURIは&、=、/、?、#をエンコードせず放置します、それらがURL構造的だから。

なぜ私のURLがダブルエンコードされているのか?

ダブルエンコーディングは、すでにエンコードされた値をエンコードすると発生します。スペースが%20になり、次に%自体が%25になり、%2520を与えます。通常、すでにエンコードされたURLをencodeURIComponentに再度渡すか、手動エンコードの上に自動エンコードするフレームワークによって引き起こされます。一度デコードしてクリーンに再エンコードするか、1つのレイヤーをスキップ。

絵文字やアクセント付き文字のような非ASCII文字をどう処理しますか?

JavaScriptのエンコーダーは非ASCII文字を最初にUTF-8バイトに変換し、次に各バイトをパーセントエンコードします。そのためéは%C3%A9 (2バイト) になり、😀のような絵文字は%F0%9F%98%80 (4バイト) になります。デコーディングはプロセスを逆にします。これは標準RFC 3986の動作で、すべての現代のサーバーで動作します。

なぜデコードが「URI malformed」で失敗するのか?

decodeURIComponentは無効なパーセントシーケンスを見るとスローします — 2つのhex桁が続かない単独の% (例えば%ZZや単に%)、または有効でないUTF-8バイトシーケンス (例えば有効な継続バイトなしの%C3)。一般的な原因: 入力中のエンコードされなかったリテラル%、またはすでに一度デコードされていてまだパーセント記号を持つ文字列。

スペースは+になるべきか%20か?

両方が実際に見られます。%20はどこでも正しい — パス、クエリ文字列、フラグメントで。+ショートカットはHTMLフォーム送信で使用されるapplication/x-www-form-urlencoded形式内でのみ「スペース」を意味します。このツールは%20を使用します、encodeURIComponentがそうするから。具体的に+が必要な場合、エンコード後に%20を+に置き換えてください。