Webブラウザやサーバーは、URL内の文字を厳密なルールに従って解釈します。RFC 3986という国際標準では、URLで直接使える「予約されていない文字」（英数字や一部記号）と、特別な意味を持つ「予約文字」（/ ? & = #など）が定義されています。例えば、「東京&大阪」という文字列をクエリパラメータにそのまま入れると、&が区切り文字として解釈され、意図せず2つのパラメータに分割されてしまいます。このような問題を防ぐため、URLエンコードは特殊文字やスペース、日本語などの非ASCII文字を%記号を使った安全な形式（例：%E6%9D%B1%E4%BA%AC）に変換します。特に日本語を含むURLや、商品名に記号が含まれるECサイトのUTMリンク作成時などに必須です。正しいエンコードにより、ユーザーが期待通りのページにアクセスできるようになります。詳細はURLデコードの仕組みも参照してください。
URLエンコードには「コンポーネントモード」と「フルURLモード」の2種類があります。これはJavaScriptのencodeURIComponent()とencodeURI()に対応しており、用途によって使い分けが必要です。コンポーネントモードは、URLの一部（たとえばクエリパラメータの値やパスのセグメント）をエンコードする際に使用します。このモードでは、/ ? & =などの予約文字も%エンコードされ、完全にデータとして扱われます。一方、フルURLモードは全体が有効なURLであることを前提とし、スキーム（https:）やホスト（example.com）、そして/ ? & =といった構造を形成する記号はそのまま残されます。例えば、「https://example.com/検索?q=カフェ&lang=ja」をフルURLモードでエンコードすると、「検索」「カフェ」のみがエンコードされ、?や&は維持されます。誤ってコンポーネントモードでフルURLを処理すると、/が%E3%81%ABなり、リンクが壊れる可能性があります。UTMパラメータ作成時は、通常コンポーネントモードを使用します。URLデコードで逆変換も確認できます。
URL中のスペースは、歴史的経緯により2通りの方法でエンコードされます。「%20」と「+」です。RFC 3986準拠の標準的なURLエンコードでは、スペースは常に「%20」となります。しかし、HTMLフォーム（application/x-www-form-urlencoded）で送信されるデータでは、スペースが「+」に置き換えられます。これは古い仕様に由来し、現在でも多くのウェブアプリケーションでサポートされています。そのため、クエリ文字列の値をエンコードする際は、用途に応じて選択が必要です。たとえば、Google AnalyticsのUTMパラメータやAPIリクエストでは「%20」が推奨されます。一方、HTMLフォーム経由で送信されるデータや、一部のレガシーシステムとの連携では「+」を使う必要があります。CallculationのURLエンコードツールでは、オプションで「スペースを+に変換」を選べるため、状況に応じて柔軟に対応可能です。誤って混在させると、サーバー側で正しくデコードされず、検索結果が空になるなどのトラブルが発生します。
現代のURLには日本語や絵文字（😊、🎉など）を含めるケースが増えていますが、これらはUTF-8に変換された後、バイト単位で%エンコードされます。たとえば、「東京」はUTF-8でE6 9D B1 E4 BA ACの6バイトとなり、URLエンコードすると「%E6%9D%B1%E4%BA%AC」となります。同様に、「café」の「é」は%C3%A9、「münchen」の「ü」は%C3%BCになります。絵文字も同様で、「🍣」はF0 9F 8D A3の4バイトからなり、「%F0%9F%8D%A3」とエンコードされます。この処理は、すべてのモダンブラウザとサーバーで標準的にサポートされています。ただし、古いシステムではUTF-8以外のエンコーディング（Shift_JISなど）を想定している場合があり、文字化けの原因となることがあります。そのため、国際化対応された環境では必ずUTF-8ベースのエンコードを使用してください。CallculationのURLエンコードはRFC 3986準拠で、Unicode文字を正確に処理します。エンコード結果はワンクリックでコピー可能で、SNSやメールでの共有にも便利です。URL QRコード生成と組み合わせれば、日本語を含むURLを簡単にQR化できます。
UTMタグやAPIリクエストでよく使われるクエリパラメータ（?key=valueのvalue部分）は、常にコンポーネントモードでURLエンコードする必要があります。なぜなら、valueに含まれる&や=、#などの文字が、URLの構造を壊す可能性があるからです。例えば、キャンペーン名に「A&Bセール」と入れたい場合、そのままでは「A」と「Bセール」が別パラメータと解釈されます。これを防ぐには、「A%26B%E3%82%BB%E3%83%BC%E3%83%AB」とエンコードします。ここで注意すべきは、キー（key）とイコール（=）自体はエンコードしてはいけない点です。また、複数のパラメータを連結する際は、各valueを個別にエンコードし、その後で&でつなぐのが正しい手順です。CallculationのURLエンコードツールでは、モードを「コンポーネント」に設定し、必要に応じてスペースを%20または+に変換することで、安全なクエリ文字列が作成できます。エンコード漏れによるトラッキングエラーを防ぐため、必ずこの手順を守りましょう。逆変換が必要な場合はURLデコードをご利用ください。
URLエンコード（パーセントエンコーディング）は、URLに直接使えない文字を「%」記号と16進数の組み合わせに変換する仕組みです。RFC 3986で定められており、例えばスペースは「%20」、日本語や絵文字はUTF-8バイト列に変換されたうえでエンコードされます。これにより、URLが正しく解釈され、通信エラーを防げます。
クエリパラメータの値（例：?q=検索語 の「検索語」部分）をエンコードする場合は、「コンポーネント」モードを使ってください。このモードは「/」「?」「&」「=」などのURL構成文字もエスケープするため、パラメータ値に含まれていてもURL構造を壊しません。一方、「フルURL」モードはこれらの文字をそのまま残すため、パラメータ値には不向きです。
「&」はクエリパラメータの区切り文字として使われるため、値の中にそのまま含めると、ブラウザやサーバーが誤って新しいパラメータの始まりと解釈してしまいます。このような文字は必ずURLエンコードで「%26」に変換してください。特にUTMパラメータなどマーケティングリンクを作成する際は注意が必要です。
通常のURLエンコードではスペースは「%20」になります。ただし、HTMLフォームの送信時（application/x-www-form-urlencoded）のように「フォームスタイル」が指定されている場合は、「+」に変換されます。CallculationのURLエンコードでは、オプションでこの挙動を選べるので、用途に応じて切り替えてください。
日本語や絵文字などのUnicode文字は、まずUTF-8バイト列に変換され、その後各バイトがパーセントエンコーディングされます。たとえば「東京」は「%E6%9D%B1%E4%BA%AC」に、😊は「%F0%9F%98%8A」になります。これは現代のWeb標準（RFC 3986）に準拠しており、国際化ドメイン名（IDN）とは異なる処理です。
URLエンコードはURL内で安全に文字を使うためのもので、対象は主に非ASCII文字や予約文字です。一方、Base64 Encodeはバイナリデータをテキスト形式に変換する汎用的なエンコーディングで、URLに直接使うと「+」「/」「=」などの問題文字を含むことがあります。目的と使いどころが全く異なるので、混同しないでください。
エンコード済みのURLを元のテキストに戻すには、URL Decodeツールをご利用ください。パーセントエンコーディングされた文字列を自動でデコードし、日本語や特殊記号も正しく復元します。
