URLエンコーダー / デコーダー

インターネットの構造上、Uniform Resource Locator (URL) は標準の US-ASCII 文字セットを使用して HTTP 経由で送信する必要がありす。URL にスペース、絵文字、その他の特殊文字など、この厳格な文字セットに含まれない文字が含まれている場合、Web ブラウザやサーバーがクラッュしたり、ルートを誤認したりする可能性があります。

URL クエリ文字列内で複雑なデータを安全に送信するには、URLエンコード（パーセントエンコーディングとも呼ばれます）を適用する必要があります。このアルゴリズムは、安全でない文字を % 記号と、その文字の ASCII/UTF-8 値を表す 16 進数表記に変換します。

たとえば、通常のスペース文字は %20 になり、アパサンド（&）は %26 になります。これにより、データがバックエンドサーバーに完全にそのまま届くことが保証されます。

JavaScript による Web 開発でよくあるバグは、誤った URL エンコード関数を使用することです。この違いを理解することは、404 エラーや壊れた API リクエストを防ぐために不可欠です。

• encodeURI(): この関数は、完全で有効な URL を渡していることを前提とします。スペースや外国語文字はエンードされますが、?、=、&、/、: など、URL 内で特別な構造的意味を持つ文字はエンードされません。
• encodeURIComponent(): この関数は、URL クエリ文字列内部に挿入する特定のデータ部分をエンコードしていることを前提とします。スラッシュやアンパサンドを含め、ほぼすべての文字を積極的にエンコードします。ユーザー入力を取得して URL パラメータとして追加する場合は、この関数を使用する必要があります。

Utiliome の URL エンコーダーは、開発者のペイロードをエスケープする際に最大限の安全性を確保するため、厳格に encodeURIComponent() の動作を利用しています。

開発者は、OAuth リダイレクトや Webhook ペイロド（例: ?email=user%40example.com&token=abc%3D%3D）のデバッグのために、雑多な URL 文字列をデコードすることが日常的にあります。

この文字列を一般的なオンライン SEO ツールに貼り付けると、その URL は HTTP POST リクエスト経由でリモートサーバーに送信されます。サーバー管理者は、機密性の高い OAuth トークン、セッション ID、および PII（個人識別情報）を簡単にログに記録できてしまいます。

Utiliome は、ゼロトラストのローカルファーストアーキテクチャで動作します。デコード計算はお使いのブラウザのローカル RAM 内でのみ実されます。データが外部ネットワークに送信されないため、本番環境の API キーも安心して安全にデコードできます。

インターネットの初期には、URL は厳格に英語の ASCII のみでした。現在では、URL に多言語の文字や絵文が含まれることが一般的です。

現代の URL エンコード標準（RFC 3986）では、外国語文字はまず UTF-8 バイトシーケンスに変されることが規定されています。その後、それらの個々のバイトがそれぞれパーセントエンコードされます。

たとえば、ケットの絵文字（🚀）は UTF-8 で 4 バイトを必要とします。Utiliome の URL エンコーダーを通すと、計算によって %F0%9F%9A%80 に換されます。これにより、バックエンドサーバーの言語アーキテクチャに関係なく、絵文字を安全にルーティングおよびデコードできるようなります。

URL エンコードをマスターするには、RFC 3986 仕様における文字の分類を理解する必要があります

• 非予約語文字（Unreserved Characters）: A-Z, a-z, 0-9, -, _, ., ~。これらの文字は本質的に安全です。URL エンコーダーはこれらを無視してそのままします。
• 予約語文字（Reserved Characters）: ! * ' ( ) ; : @ & = + $ , / ? # [ ]。これらの文字はイターネットの「文法」として機能します。たとえば、& 記号は変数を区切ります。実際の変数データにアンパサンドが含まている場合（例: 「M&M Candy」）、サーバーがデータを途中で分割しないように %26 にエンコードする必要があります。

よくある混乱の原因は、スペース文字が %20 にエンコードされる場合と + 記号になる場合があることです。

これは従来のインターネットアーキテクチャに起因します。application/x-www-form-urlencoded 仕様（HTML フォームが送信される際に使用）では、歴史的に帯域幅を節約するためにスペースをプラス記号に変換するこが定められていました。

ただし、標準の URL パスや現代の API クエリ文字列では、スペース文字は厳格に %20 にパセントエンコードされる必要があります。Utiliome は現代の encodeURIComponent() 仕様に標準化されており、現代の REST API でのサバー側デコードエラーを防ぐために、スペースが安全に %20 に変換されることを保証します。