マルチパート POST をサポートするために、HTTP サーバーに RFC 2388 を実装しようとしています。
特に content-disposition の「name」パラメータの仕様を見ています。
RFC 2388 のセクション 3 では、次のように述べられています。
RFC 2047 で説明されている標準的な方法を使用して、元は非 ASCII 文字セットのフィールド名を「name」パラメータの値内にエンコードできます。
現在、フォーム コントロール名で RFC2047 をサポートしている UA はないと「聞いた」ことがあります。彼らは単にテキストを元のエンコーディングで送信します。(つまり、フォーム コントロールの名前が UTF-8 を使用した日本語の場合、UTF-8 の日本語テキストを含むマルチパート POST 要求が送信されます)
ただし、これがいつか解決されることを「忠実」にするために。私はRFCに固執することを好みます。
ただし、問題は RFC 2047 自体にあります。セクション5（3）の下で、次のように述べています。
- 「コード化された単語」は、「addr-spec」のどの部分にも現れてはなりません。
- 'encoded-word' は 'quoted-string' 内に現れてはなりません (MUST NOT)。
- 「コード化された単語」は、Received ヘッダー フィールドで使用してはなりません。
- 「コード化された単語」は、MIME Content-Type または Content-Disposition フィールドのパラメータ、または「コメント」または「フレーズ」以外の構造化フィールド本体で使用してはなりません。
競合は 4 番目の箇条書きにあります。「name」パラメーターが「content-disposition」フィールドの一部であるとします。仕様が私たち実装者に何を求めているのか、私は迷っています。
「現実」で何が機能するか機能しないかに関係なく。誰かがこれも矛盾していると思うかどうか尋ねたい.
RFC 2388 が「name」パラメータについて RFC 2047 を参照しているのに、数段落後に「filename」パラメータのエンコーディング仕様として RFC 2231 を参照している理由についても疑問に思います。RFC 2047 は「パラメータ値」に使用できないため、RFC 2231 が作成されたようです。「name」パラメーターが RFC 2231 を利用するように、RFC 2388 も更新されていないはずです。
肝心なのは、RFC 2388 の機能を実現するために RFC 2047 AT ALL を実装することを気にする必要があるのか、それともしないのかということです。また、「ファイル名」パラメータについて RFC 2231 も気にする必要がありますか? RFC 2231 が現在 UA で非 ASCII ファイル名をアップロードするために使用されているかどうかを知っている人はいますか?