HTTPダウンロード名：Content-Dispositionとfilename*
応答の扱い、多言語ファイル名の指定、受信側が提案された名前を安全に制限する責任を区別する。
発行・訂正窓口：infostoa · 編集基準
この記事の個別の執筆者・専門査読者の情報は提供されていません。
HTTPのContent-Dispositionは応答の扱いと、保存時に使うファイル名を提案する。attachmentはダウンロード処理を求め、inlineは既定の処理に任せる。名前は受信側への提案であり、サーバーが決める絶対保存パスではない。多言語の文字化けと安全な保存位置は、同じヘッダーの異なる課題だ。
実際の保存結果ではなく概念図です。
応答の扱いと名前を分けて読む
RFC 6266はattachmentを、通常のメディア型処理ではなく保存を促す用途として説明する。inlineは既定の処理を意味し、ファイル名などの付加情報と共に使える。同じPDFでも、表示方法の要求と保存名の提案を分けて理解したい。名前を付けるだけでattachmentになるわけではない。
ブラウザーが自身の規則と画面で保存を進めるので、サーバーが利用者のディレクトリーを直接選ばない。ここではHTTP応答の名前を扱い、multipartフォームの各フィールド名とは区別する。同じヘッダー名でも文脈が異なれば、応答用の規則をそのままアップロードへ適用すべきではない。 応答の扱い
多言語の名前にはfilename*を使う
RFCはfilenameとfilename*を区別し、後者が拡張エンコードでより多くの文字を表せると説明する。その形式でUTF-8データを送れば日本語や韓国語の名前も表現できる。通常のfilenameへパーセント表記の文字を入れるだけとは異なる形式だ。どちらの値を作っているかを明確にする。
両方を送る場合、対応する受信側はfilename*を選びfilenameを無視するよう規格が勧める。同じファイルの名前を、対応の異なる受信側向けに二つの形で提供できる。読みやすいASCIIの代替名と、拡張形式の元の名前を組み合わせるのが実務的だ。別の文書に見えないよう意味を揃える。
たとえば代替名をreport.pdf、拡張名を報告書.pdfにできる。同じ内容と拡張子を維持し、名前の言語表現だけを変える比較例になる。
構文例は filename="report.txt"; filename*=UTF-8''%EB%B3%B4%EA%B3%A0%EC%84%9C.txt だ。二つのアポストロフィの間の言語欄は空で、エスケープは보고서.txtのUTF-8バイトを表す。拡張値自体は引用符付き文字列ではない。RFC 8187は生成側のUTF-8と拡張構文を規定する。説明用の名前であり実際の取得やブラウザー試験ではない。 拡張構文 名前の選択
専門的視点：エンコードとブラウザー差
MDNの専門案内は互換性のため両方を提供する方法を説明する。またfilenameのパーセント表記をブラウザーが異なる方法で処理すると注意する。名前全体へURLエンコードを無条件に適用する前に、どのパラメーター形式を生成するのかを判断する必要がある。
ASCIIの名前、空白を含む名前、多言語の名前を対象ブラウザーで保存して確かめる。表示名と実際に保存された名前も比較する。MDNは、ファイルシステムの要求に合わせて区切り文字を変更するなど、ブラウザーによる変換があると説明する。サーバーの文字列が常にそのまま保持されるとは限らない。 受信環境の説明
受信側は名前をパスとして信用しない
RFCは提案名を助言として扱うことを強調する。パス区切りを含む名前が来ても、許可された場所以外へ保存できてはいけない。文書が示す方法の一つはフォルダー情報を信用せず最後の名前部分だけ使うことだ。提案名は保存権限を広げる根拠にならない。
拡張子も確認する。拡張子で保存ファイルを解釈する環境では、サーバーの指定をそのまま信頼すると危険な処理を誘うことがある。RFCは安全な拡張子を要求し、受信したメディア型との一致を最適な選択として説明し、制御文字や紛らわしい空白の整理も勧める。読みやすさだけでなく保存後の動作を扱う問題である。 提案名の安全境界
ダウンロード契約を順に確認する
最初に扱い方、多言語の表示名、代替名を決める。二つの表現の意味が合うかを調べ、対象環境の実際の保存結果を見る。受信プログラムを作るなら、保存位置と名前の検査を別の段階にするのが実務的な適用方法だ。
このヘッダーは内容の真正性やダウンロード権限を証明しない。名前が正しく表示されることと、内容が安全であることは別だ。送信側の正しい処理指定とエンコード、受信側の保存制限を一緒に考えると、多言語ダウンロードの責任が明確になる。
送信側にはフィールド生成時の別の境界もある。RFC 9110は値のCR、LF、NULを無効で危険と扱う。未確認の元の名前をヘッダーへ連結する問題と、受信側が復号名を保存パスに使う問題は別だ。名前の符号化だけで両方を安全に処理したとは保証できない。 HTTPフィールド値
仮の点検表では元の表示名、生成した二つのパラメーター、表示結果、最終保存位置を別の欄に書ける。一つの成功が次の安全性を証明するわけではない。生成の誤りと保存制限を別の質問として残すための比較練習だ。