💔 壊れたファイル

ケース	何が起きるか	どうする
例外は出ているのに利用者には何も伝わらない	`try / catch` でまとめて握りつぶし、空の結果や 500 だけを返す実装が非常に多いパターンです。ログにも「失敗した」としか残りません。	どのファイルの何行目で何が起きたかを利用者に返します。壊れたファイルを投げたときの画面を実際に見て、そこから次の行動が取れるかで判断してください。
途中で切れたファイルがサイズ検査を通る	サイズ上限より小さければ検査は通ります。「小さすぎる」ほうを見ていないため、0 バイトや数十バイトのファイルもそのまま保存されます。	下限も設けます。加えて、形式ごとの終端を確認します。PDF なら末尾の `%%EOF`、ZIP なら End of Central Directory (`50 4B 05 06`) の有無で切断を検出できます。
ヘッダだけ見て中身を信じてしまう	マジックバイトが正しくても、その先が壊れていることはあります。`header-corrupted` のファイルはその逆で、中身は読めるのに先頭だけ違う形です。	検査は入口だけでなく実際に読む処理でも行います。画像なら実際にデコードしてみる、ZIP なら一覧を取ってみる、が確実です。
列数の合わない CSV が黙って通る	多くの CSV パーサは行ごとに配列を返すだけで、列数が揃っているかは検査しません。足りない列は `null` になり、そのまま保存されます。	ヘッダ行の列数を基準に、1 行ずつ照合して行番号つきで弾きます。区切り文字や引用符の問題を先に潰したい場合は CSV クリーナーで整えてから読み込むのが早いです。

ここで想定しているのは事故による破損です。意図的に作られた ZIP 爆弾、極端な入れ子の XML、巨大な解凍後サイズといった攻撃向けの入力は含まれていません。それらは展開前にサイズと深さの上限で止める設計が必要です。