link URLエンコード/デコード star

仕組み

URLが安全に運べるのは、ごく限られた文字集合だけです — 英字、数字、そして予約されていない4つの記号- _ . ~です。それ以外の文字はすべて%XXという3文字の並びに書き換えられます。ここでXXはその文字のバイト値を16進数で表したものです — これがRFC 3986のパーセントエンコーディングです。URLの構造を成す文字(? # / : @ & =、いわゆる「予約文字」)も、区切り記号としてではなく値の内部に現れる場合はエンコードされます。そうしないと、クエリの値の中にある素の&が次のパラメータの開始として読み取られてしまうからです。

ASCII以外の文字は、見た目の文字単位ではなくバイト単位でエンコードされます。このツールはまず文字列をUTF-8に変換し、その結果得られた各バイトを16進数化します。トルコ語の文字「ç」はUTF-8で2バイト(0xC3 0xA7)なので、単一のコードではなく2つのパーセントブロック、%C3%A7になります。具体例として、İstanbul çayı & simitをエンコードすると%C4%B0stanbul%20%C3%A7ay%C4%B1%20%26%20simitになります。スペースが%20に、予約文字の&が%26になり、アクセント付きの各文字がそれぞれ複数バイトの並びに展開されている点に注目してください。

実務でこの違いが最も重要になるのは、リクエストを手作業で組み立てるときです — 誰かから送られてきたクエリ値付きのウェブフックURLを貼り付けるとき、マーケティングメールのトラッキングパラメータをデコードするとき、あるいはエンコードされていない生の&や#が値の中に紛れ込み、データではなく区切り記号として読まれてAPI呼び出しが失敗する原因を突き止めるときなどです。まず値をエンコードしてから、その結果をURLテンプレートに差し込むことで、まさにこの種のバグを避けられます。

知っておくべきこと

• %20か+か: RFC 3986のパーセントエンコーディングでは、スペースには常に%20を使います。+という慣習は別の、より古い規格 — HTMLフォームがデータを送信する際に使われるapplication/x-www-form-urlencoded — に属するものであり、そのボディ形式の中だけで通用します。パスや正しくパーセントエンコードされたクエリ値の中では決して使われません。この2つを取り違えるのは典型的なバグの原因です — フォームエンコーディングを期待するサーバーは、パーセントエンコード済みの文字列に紛れ込んだ+をスペースではなく文字通りのプラス記号として読み取ってしまいます。
• URL全体ではなく単一のコンポーネントをエンコードする: このツールは単一のクエリ値やパスセグメントのために作られています。アドレス全体(https://を含む)をエンコーダーに通すと、URLを有効にしているスラッシュやコロンまでエスケープされ、URLが完全に壊れてしまいます。
• ブラウザと同じエンジン: ブラウザ標準のencodeURIComponent/decodeURIComponentを呼び出しているため、結果は実際のブラウザやJavaScriptのfetch呼び出しが生成するものと完全に一致します — 近似ではありません。
• 往復変換は無損失: 文字列をエンコードしてから結果をデコードすると、常に元のバイト列が正確に返ってきます。これにより、手作業でのエンコード結果をデコードして元のテキストと比較するだけで、簡単に正しさを確認できます。
• 何もブラウザの外に出ません: エンコードとデコードはすべてクライアント側で、アップロードなしに即座に実行されます。