テストファイルジェネレーター
アップロード上限のテストに5MBのJPGや100KBのPDFが必要ですか?サイズと拡張子を選べば即座にダウンロードできます。ブラウザ内でローカルに生成され、どこにもアップロードされません。
得られるもの
名前だけそれらしいダミーではなく、実際に有効なファイルです。
構造的に正しいファイルです。どのPDFビューアでも開け、問題なく解凍でき、あるいは本物のGIFとして表示され、指定した正確なサイズまで詰められています。
実際の極小画像を、どんな画像ビューアも無視することを知っている標準的なコメント/ブロックの仕組みを使って、指定サイズまで詰めています。
読めるダミーテキスト、ランダムバイト、あるいはゼロ埋め。正確なバイト数で選べます。
数百バイトを超えるものは正確なサイズに到達します。一部の形式(PDF、GIF、JPG、PNG、ZIP)には避けられない、ただしごく小さな構造上の最小サイズがあります。ツールは常に、要求したサイズだけでなく実際に生成されたサイズを表示します。
仕組み
各フォーマットはそれぞれの仕様に従ってバイト単位で構築され、パディングはパーサーが読み飛ばすことを義務付けられている場所に巧みに隠されています。PDFは実在する5オブジェクトの文書で、そのクロスリファレンステーブルは各オブジェクトの正確なバイトオフセットを記載しており、パディングは肥大化させたコメント行を通じて行われます。ZIPは本物のアーカイブで、ゼロ埋めされた1つのエントリを囲むようにローカルヘッダー、セントラルディレクトリ、終端レコードを備え、ペイロードに対して実際に計算された本物のCRC-32チェックサムも含まれます。これが重要なのは、解凍ツールがそのチェックサムを検証し、偽物を拒否するからです。
画像も同じ扱いを受けます。GIFは最大255バイトのコメント拡張サブブロックを通じて肥大化し、JPEGは1つあたり64KBまでのCOMセグメントを通じて、PNGはIENDの直前に挿入されるカスタムの補助チャンクを通じて肥大化します。このチャンクには独自のCRC-32があり、タイプの先頭文字を小文字にすることでデコーダーに「無視しても安全」だと伝えています。この構造的な誠実さこそが重要な点です。これらのファイルはマジックナンバーのチェックを通過し、実際のビューアーでデコードでき、チェックサム検証にも耐えるため、内容を実際に検査するアップロードパイプラインを本当の意味でテストできます。
特に画像アップロードをテストする際の注意点が一つあります。パイプラインが画像を再エンコードする場合(ほとんどのアバターや写真アップローダーがそうします)、パディングは再エンコードの過程で失われ、5MBのJPGが反対側では小さくなって出てきます。再エンコードが行われる前の時点でサイズ制限をテストするか、パイプラインがほとんど書き換えないZIPやPDFを使ってください。ファイルはどこからも取得されません。バイト列はメモリ内で組み立てられ、blobとしてブラウザに渡されるため、数百メガバイトの場合でも生成は瞬時に完了します。