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

URLは元々インターネット上でASCIIテキストを送信するために設計されました。URL仕様（RFC 3986）は特定の文字を特殊目的のために予約しています：'?'はパスとクエリ文字列を分離し、'&'はパラメータを分離し、'='はキーと値を分離し、'#'はフラグメントをマークし、'/'はパスセグメントを分離します。これらの文字がURLのデータ部分（検索クエリやパラメータ値など）に現れる場合、構造的区切りとして解釈されないようにエンコードする必要があります。

URLエンコード（パーセントエンコード）は、予約文字または非ASCII文字をパーセント記号（%）とその文字のバイト値を表す2桁の16進数で置き換えます。例えば、スペースは%20、アンパサンドは%26、スラッシュは%2Fになります。予約されていないセットの文字（A-Z、a-z、0-9、ハイフン、アンダースコア、ピリオド、チルダ）はエンコードされません。JavaScript関数encodeURIComponent()がこのエンコードを処理し、decodeURIComponent()が逆の処理を行います。

現代のURLはUnicode文字（絵文字、CJK文字、アクセント付き文字）も処理する必要があります。これらはまずUTF-8バイトとしてエンコードされ、その後各バイトがパーセントエンコードされます。例えば、コーヒーの絵文字☕（U+2615）はUTF-8バイトE2 98 95としてエンコードされ、URLでは%E2%98%95になります。ブラウザとサーバーはURLを入力したりフォームを送信したりする際にこのエンコードを自動的に処理しますが、開発者はAPIエンドポイント、リダイレクトURL、データURIを構築する際に手動でURLをエンコードまたはデコードする必要がよくあります。

URLエンコーディングは、ウェブアプリケーションでURLを通じてデータを渡す際に不可欠です。一般的なシナリオには、APIクエリパラメータの構築（検索語、フィルタ値のエンコード）、元のURLをパラメータとして含むリダイレクトURLの作成（例：/login?redirect=%2Fdashboard）、埋め込み画像やフォント用のデータURIの生成、件名と本文パラメータ付きのメールリンクのエンコード（mailto:?subject=...&body=...）があります。OAuthフローもstateパラメータとコールバックURLのURLエンコーディングに大きく依存しています。

よくあるバグは二重エンコード — すでにエンコードされた文字列をさらにエンコードすることです。例えば、'%20'をエンコードすると'%2520'になります（パーセント記号自体が%25にエンコードされます）。文字列の現在の状態が不明な場合は、再エンコード前に必ずデコードしてください。もう一つの一般的な問題は、encodeURIComponent()の代わりにencodeURI()を使用することです — encodeURI()は?、&、=などの予約文字をエンコードしないため、パラメータ値のエンコードには適していません。個別のパラメータ値にはencodeURIComponent()を使用し、完全なURLにのみencodeURI()を使用してください。