Quick Calculators

URLエンコード・デコード

URL向けにテキストをパーセントエンコードするか、`%HH` 列を文字に戻します。コンポーネントモードとフルURIモードを比較し、`%20` と `+` が同じではない理由を確認できます。

すべての計算はブラウザ内で実行されます。入力内容がサーバーに送信されることはありません。

01 計算機

入力すると結果が更新されます。Ctrl/Cmd+Enterで主な結果をコピー。

結果

—

    途中式を表示
      —

      URLエンコード・デコードは RFC 3986 のパーセントエンコードをテキストに適用し、%HH 列を文字に戻します。コンポーネントモードでは /、?、& などの予約文字をエンコードし、単一のクエリパラメータ内に安全に置けます。フルURIモードでは構造的な区切り文字を保持し、完全なアドレスが使えるリンクのまま残ります。スペースは %20 とフォームエンコードのプラス記号の両方に対応します。

      エンコードとデコードはすべてブラウザ内で実行されます。貼り付けた内容がサーバーに送られることはありません。

      URLで安全に使うためにテキストをエンコードする

      Concept diagram: 入力 leads to URLで安全に使うためにテキストをエンコードする leads to 結果入力URLで安全に使うためにテキストをエンコードする結果
      URLで安全に使うためにテキストをエンコードする.

      パーセントエンコードは、安全でないバイトや予約バイトを、パーセント記号と2桁の16進数に置き換えます。桁は通常 UTF-8 のバイト値です。文字列を入力し、コンポーネントまたはフルURIモードを選び、エンコード結果をクエリ文字列、パスセグメント、リダイレクト先にコピーします。

      非予約セットに含まれる文字はそのまま通過します。それ以外はコンポーネントモードで %HH 列になります。デコード時に同じ規則を使えば可逆です。フォームエンコードのプラス記号とパス向け %20 を混ぜるのが、往復が壊れる典型的な原因です。

      パーセントエンコードされた文字列をデコードする

      Scale bar: 1 入力単位 equals 1.8 出力単位1 入力単位1.8 出力単位
      パーセントエンコードされた文字列をデコードする.

      デコードは % の後に2桁の16進数がある箇所を見つけ、その組をバイトに変換し、選んだ文字エンコーディングで元のテキストを再構築します。単独の % や16進以外の桁はエラーです。入力が application/x-www-form-urlencoded 本体由来なら、プラス記号をスペースとして扱うこともできます。

      ネストされたエンコードは、値が2回エンコードされたときに現れます。1回デコードしても、リテラル % を表す %25 列が残ることがあります。2層目が意図的なときだけ再度デコードしてください。盲目的な二重デコードは、本物の % を含むデータを壊します。

      予約文字と非予約文字を理解する

      Concept diagram: 入力 leads to reserved and unreserved characters leads to 結果入力reserved and unreservedcharacters結果
      予約文字と非予約文字を理解する.

      RFC 3986 は ASCII を、URI内でエンコード不要な非予約文字と、区切り文字など構造上の意味を持つ予約文字に分けます。非予約の英字、数字、-_.~ はリテラルのままです。/, ?, & などの予約記号は、URLを枠組む構文ではなくデータとして現れるときはパーセントエンコードが必要です。

      非予約: A から Z, a から z, 0 から 9, ハイフン -, アンダースコア _, ピリオド ., チルダ ~

      予約 (gen-delims): `: / ?

      予約 (sub-delims): ! $ & ' ( ) * + , ; =

      非予約文字はリテラルのままです。予約文字は区切りではなくデータとして現れるときにエンコードが必要です。パラメータ値内の疑問符はデータです。クエリ文字列を始める疑問符は構造です。モード選択により、計算機は各文字がどちらの役割かを判断します。

      URL全体と単一パラメータのエンコード

      Comparison chart of 選択肢 A versus 選択肢 B across Case 1, Case 2, Case 3Case 1Case 2Case 3選択肢 A選択肢 B
      URL全体と単一パラメータのエンコード.

      フルURIエンコードは JavaScript の encodeURI に近く、構造文字をそのままにして https:// やパスのスラッシュを残します。コンポーネントエンコードは encodeURIComponent に近く、それらの文字をエンコードして値を周囲のURLを壊さずパラメータ内に置けます。モードを誤るとリンクが壊れるか、クエリを誤って分割する区切り文字が残ります。

      入力フルURIスタイルコンポーネントスタイル
      https://example.com/a bhttps://example.com/a%20bhttps%3A%2F%2Fexample.com%2Fa%20b
      red&bluered&bluered%26blue
      a=ba=ba%3Db

      コンポーネントモードでURL全体をエンコードするとリンクとして壊れます。スキームのコロンとスラッシュが %3A と %2F になります。フルURIモードで単一パラメータをエンコードすると & と = がそのまま残り、クエリが誤って分割されます。文字列が占める位置に合うモードを選んでください。

      スラッシュと疑問符をエンコードする

      Concept diagram: 入力 leads to スラッシュと疑問符をエンコードする leads to 結果入力スラッシュと疑問符をエンコードする結果
      スラッシュと疑問符をエンコードする.

      フィクスチャ文字列 / and ? はコンポーネントモードで %2F%20and%20%3F になります。スラッシュと疑問符は予約区切り文字ですが、ここではペイロードテキストとして扱われるため、それぞれエスケープされます。スペースは %20 になり、and の文字は非予約のため左から右へそのまま通過します。

      文字理由エンコード後
      /予約パス区切り%2F
      スペース非予約ではない%20
      a, n, d非予約の文字変更なし
      ?予約クエリ区切り%3F

      左から右へ: / をエンコード、スペースをエンコード、and は通過、スペースをエンコード、? をエンコード。結果 %2F%20and%20%3F は、例えば q という名前のクエリパラメータに安全に置けます。同じ文字列をフルURIモードにすると / と ? がリテラルのまま残り、それらが構造を意図するときだけ正しいです。

      %20 とプラス記号の違いを理解する

      Comparison chart of 選択肢 A versus 選択肢 B across Case 1, Case 2, Case 3Case 1Case 2Case 3選択肢 A選択肢 B
      %20 とプラス記号の違いを理解する.

      スペースは URI パスと RFC 3986 に従う現代のクエリ文字列では %20 としてエンコードされます。application/x-www-form-urlencoded として送信する HTML フォームでは、歴史的にスペースを + でエンコードしてきました。両方の慣習が本番トラフィックに現れ、同一視することが混在入力をデコードするときの最も多いスペースエンコードのバグです。

      文脈スペースのエンコード
      パスセグメント%20
      RFC 3986 クエリ%20
      フォーム本体 / レガシークエリ+

      データ内のリテラルプラスは %2B としてエンコードする必要があります。そうしないとフォームデコーダがスペースとして扱います。計算機はどのスペース規則が有効かを表示し、フォームモードではデコードされた + をプラス文字と混同せず、パスモードでは %20 を拒否しません。

      URLを構成要素に分解する

      Concept diagram: 入力 leads to URLを構成要素に分解する leads to 結果入力URLを構成要素に分解する結果
      URLを構成要素に分解する.

      典型的な URL にはスキーム、ホスト、任意のポート、パス、クエリ文字列、フラグメントがあり、エンコード規則は部分ごとに異なります。://, /, ?, &, =, # などの構造区切りは、アドレスを枠組むときはリテラルのままです。

      パラメータ名、パラメータ値、データを運ぶパスセグメントは、区切り文字で結合する前にコンポーネントモードで個別にエンコードします。

      https://example.com:443/search?q=a%20b&lang=en#top
└─┬─┘   └─────┬─────┘ └─┬──┘ └───────┬───────┘ └┬┘
scheme       host     path        query      fragment
      部分役割
      スキームhttps などのプロトコル
      ホストドメインまたは IP、任意のポート付き
      パスリソース位置、スラッシュ区切り
      クエリ? の後のパラメータ一覧、& で結合
      フラグメント# の後のクライアント側位置、リクエスト URI としてサーバーに送られる方式とは異なる

      パラメータ名と値をコンポーネントモードで個別にエンコードし、リテラルの & と = で結合します。パスセグメントにスペースや予約文字が含まれる場合は個別にエンコードし、セグメントを分けるスラッシュはリテラルのままにします。

      文字エンコード表を読む

      Concept diagram: 入力 leads to character encoding table leads to 結果入力character encodingtable結果
      文字エンコード表を読む.

      下の表は、UTF-8 バイトエンコードでの一般的な予約文字と安全でない文字と、そのパーセント形式を示します。スペースは %20、アンパサンドは %26、ハッシュは %23 になります。非 ASCII 文字は、抽象グリフ1つではなく各 UTF-8 バイトを個別にエンコードするため、複数の %HH 単位に展開されます。

      文字パーセント備考
      スペース%20フォームエンコードでは + も
      !%21
      #%23フラグメント区切り
      $%24
      &%26クエリペア区切り
      '%27
      (%28
      )%29
      +%2Bリテラルプラス
      ,%2C
      /%2Fパス区切り
      :%3Aスキーム / ホスト区切り
      ;%3B
      =%3Dパラメータ代入
      ?%3Fクエリ開始
      @%40ユーザー情報区切り
      [%5B
      ]%5D

      非 ASCII テキストはまず UTF-8 バイトとして表現され、各バイトがパーセントエンコードされます。1文字が2つまたは3つの %HH 単位に展開されることがあります。Shift JIS などレガシーセットの文字エンコーディングの詳細は Base64 ツール側にあり、このページはカタログを繰り返さずリンクします。

      よくある質問

      パーセントエンコードとは?

      パーセントエンコードは、バイトをそのバイト値の2桁16進数に続く % で置き換えます。予約文字や非 ASCII 文字を構文として読まれず URL 内を通過させます。デコードは置換を逆にします。

      コンポーネントエンコードはいつ使う?

      単一のパラメータ名または値、純粋なデータのパスセグメント、構造区切りの隣に挿入する任意の文字列に使います。/, ?, &, = をエンコードして URL を分割できないようにします。

      フルURIエンコードはいつ使う?

      入力がすでに完全な URL で、スペースなどの不正文字だけを変えたいときに使います。構造上のコロンとスラッシュはリテラルのままで、結果がクリック可能なアドレスとして残ります。

      / and ? はなぜ %2F%20and%20%3F になる?

      コンポーネントモードではスラッシュと疑問符がデータとして扱われ、%2F と %3F にエンコードされます。スペースは %20 になり、and の文字は非予約のためそのままです。

      + は %20 と同じ?

      いいえ。%20 は RFC 3986 におけるスペースのエンコードです。+ がスペースを意味するのは application/x-www-form-urlencoded データだけです。リテラルプラスは %2B にする必要があり、そうしないとフォームデコーダがスペースに変えます。

      エンコード不要な文字は?

      非予約セット: 英字、数字、ハイフン、アンダースコア、ピリオド、チルダです。これらは両モードでリテラルのままです。エンコードしても動きますが、不要な長さが増えます。

      非 ASCII 文字はどうエンコードされる?

      まず UTF-8 バイトに変換し、各バイトをパーセントエンコードします。表示上1文字が複数の %HH 列になることがあります。デコードは UTF-8 を使って元のテキストを再構築する必要があります。

      2回デコードすると壊れた URL は直る?

      値が意図的に2回エンコードされたときだけです。それ以外では2回目がデータの一部だったリテラル % 列を壊します。1回デコードして確認し、%25 パターンで2層目が見えるときだけ再度デコードしてください。

      Base64 と同じ?

      いいえ。パーセントエンコードは URI 向けに文字をエスケープします。Base64 は任意のバイトをテキストプロトコル輸送用の64文字アルファベットに写像します。用途ごとに使い分けてください。

      貼り付けた URL はアップロードされる?

      いいえ。エンコードとデコードはブラウザ内だけで実行されます。トークンやセッションフラグメントを含むクエリ文字列も、このツールからサーバーに送信されません。

      まとめ

      URLエンコード・デコードは RFC 3986 規則の下でテキストをパーセントエンコードおよびデコードし、フル URI と個別コンポーネント向けに別モードを提供します。フィクスチャ / and ? はコンポーネントモードで %2F%20and%20%3F になります。スペースは URI 文脈では %20 を使い、フォームエンコードでは + を使う別慣習があります。

      予約文字は構造としてリテラルに残すときだけ意味を保ち、ペイロードとして現れるときはエンコードします。作業はすべて端末上で完結します。

      関連計算機

      Base64エンコード・デコード · IPサブネット計算機 · 十六進数計算機

      その他の開発者