疑問符 (?) のURLエンコード

疑問符（?）はURLにおいて最も構造的に重要な文字の一つです。パスとクエリ文字列の間の区切り文字として機能します。リテラルの疑問符がパラメータ値やパスセグメント内に現れる必要がある場合は、%3Fにエンコードしなければなりません。

percent-encoding形式: %3Fは疑問符を表します（ASCIIコード63、16進数で0x3F）。エンコードすることで、URLパーサーがこれを新しいクエリ文字列の開始として解釈するのを防ぎます。

URL構造のおさらい: https://example.com/path?key=valueにおいて、?はクエリパラメータの開始を示します。URL内で最初の?のみがこの特別な意味を持ち、クエリ文字列内の後続のエンコードされていない疑問符は技術的には有効ですが、実装間で一貫性のない解析を引き起こす可能性があります。

JavaScriptでの動作:

encodeURIComponent("What is this?") // "What%20is%20this%3F"
encodeURI("What is this?")          // "What%20is%20this?" (? をエンコードしない)

これもencodeURI()とencodeURIComponent()が大きく異なるケースです。encodeURI()は完全なURIを対象に設計されているため、?を構造要素として保持します。疑問符を含む可能性のある値をエンコードする場合はencodeURIComponent()を使用してください。

エンコードが必要なよくあるシナリオ:

• 自然言語の質問を検索クエリとして渡す場合：/search?q=How%20do%20I%20encode%3F
• あるURLを別のURLのパラメータとして埋め込む場合：/redirect?url=https%3A%2F%2Fexample.com%2Fpage%3Fid%3D5
• 疑問符を含むファイル名やリソース識別子
• ユーザー生成コンテンツから構築されるURL（予期しない?の出現）

落とし穴: リダイレクトURLを構築する際、開発者はしばしば遷移先URLをクエリパラメータとして渡します。遷移先URL自体がクエリ文字列（?と&を含む）を持つ場合、遷移先全体を単一の値としてエンコードする必要があります。これを怠ると、外側のURLパーサーが内側のURLのパラメータを吸収し、リダイレクトの失敗やオープンリダイレクト脆弱性につながる可能性があります。