スラッシュ (/) のURLエンコード

スラッシュ（/）はURLにおいてパスセグメントの区切り文字として機能する予約文字です。URLパスではスラッシュが階層構造を定義します（例：/users/42/profile）。スラッシュがパラメータ値や単一パスセグメント内のリテラルデータとして現れる場合は、%2Fにエンコードする必要があります。

percent-encoding形式: %2Fはスラッシュを表します（ASCIIコード47、16進数で0x2F）。エンコードすることで、URLパーサーがこれをパス区切りとして扱うのを防ぎます。

コンテキストに依存するエンコード: スラッシュのエンコードが必要かどうかは、URL内のどこに現れるかに完全に依存します：

• パス内: スラッシュはセグメントを区切るものであり、エンコードすべきではない（/api/users/42）
• パラメータ値内: スラッシュはエンコードすべき（?path=%2Fhome%2Fuser）
• 単一パスセグメント内: 値が一つのセグメントとして扱われる場合、スラッシュをエンコードする必要がある

JavaScriptでの動作:

encodeURIComponent("/home/user") // "%2Fhome%2Fuser"
encodeURI("/home/user")          // "/home/user" (スラッシュを保持)

// ファイルパスをクエリパラメータとして渡す例
const filePath = "/var/log/app.log";
const url = `/api/view?file=${encodeURIComponent(filePath)}`;
// "/api/view?file=%2Fvar%2Flog%2Fapp.log"

サーバーサイドの考慮事項: 一部のWebサーバーやフレームワークは、パスセグメント内の%2Fをリテラルの/とは異なる方法で処理します。例えば、Apacheはデフォルトでパス内の%2Fを含むリクエストを拒否する場合があり（404を返す）、AllowEncodedSlashesを有効にしない限り処理されません。Nginxはそのまま通しますが、%2Fをパス区切りとしては扱いません。この不一致はルーティングの問題を引き起こす可能性があります。

よくあるシナリオ:

• ファイルシステムパスをURLパラメータとして渡す場合
• パスのような識別子を受け入れるAPIエンドポイント（例：/repos/owner/name）
• クエリパラメータ内の01/15/2026のような日付形式
• リダイレクトURLでのリソースパスの参照

落とし穴: 一部のサーバーフレームワークがルーティング前に%2Fを自動デコードすることに注意してください。これはパストラバーサルのセキュリティ脆弱性を生む可能性があります。アプリケーションが/files/..%2F..%2Fetc%2Fpasswdを受信した場合、単純な実装では/etc/passwdに解決される可能性があります。サーバー側では常にデコードされたパスを検証・サニタイズしてください。