虛擬檔案生成器
在瀏覽器中生成圖片、音訊、影片、PDF、文本等指定位元組數的虛擬檔案，用於測試上傳表單的大小限制。檔案內容絕不會上傳到伺服器。
格式
| 格式 | 副檔名 | MIME 型別 | 規範上限 | 備註 |
|---|---|---|---|---|
| 文本 (TXT) | .txt |
text/plain |
實質上無限制 | 使用可讀的重複文本填充 |
| CSV | .csv |
text/csv |
實質上無限制 | 帶表頭的虛擬表格資料 |
| JSON | .json |
application/json |
實質上無限制 | 填充在單個字串欄位中 |
| 二進位制 (BIN) | .bin |
application/octet-stream |
實質上無限制 | 迴圈 0x00～0xFF 的任意位元組序列 |
| 圖片 (PNG) | .png |
image/png |
實質上無限制 | 有效的 1x1 圖片 + 填充資料塊 |
| 音訊 (WAV) | .wav |
audio/wav |
4 GiB | 靜音 PCM 資料（可實際播放） |
| 影片 (MP4) | .mp4 |
video/mp4 |
實質上無限制 | 支援的瀏覽器中為真實錄制，不支援時為僅結構有效的佔位檔案 |
| 影片 (WebM) | .webm |
video/webm |
實質上無限制 | 真實錄制的數秒動畫（僅限支援的瀏覽器） |
.pdf |
application/pdf |
實質上無限制 | 有效的空白單頁 PDF | |
| ZIP | .zip |
application/zip |
4 GiB | 無壓縮的單條目歸檔 |
虛擬檔案生成小技巧
- 上傳表單的校驗邏輯通常會分別檢查副檔名、MIME 型別、檔案大小這三項。由於本工具生成的檔案在其他方面均符合規範，因此可以單獨針對大小限制進行測試。
- "最大 10MB" 這樣的限制，在不同實現中可能是 10,000,000 位元組（106），也可能是 10,485,760 位元組（220）。單位選擇器支援這兩種進位制，因此可以同時測試恰好達到邊界值和超出 1 位元組的情況。
- Chrome 和 Edge 會直接將資料流式寫入所選驅動器，因此即使是數十 GB 規模的檔案也不會佔用大量記憶體。Firefox 和 Safari 需要先在記憶體中組裝檔案，因此大小存在實際上限。
- 在支援的瀏覽器中，影片（MP4/WebM）會使用瀏覽器內建的編碼器實際錄製數秒動畫，因此開啟後可以真正播放。除此之外的部分（佔檔案絕大部分的填充資料）以及其他圖片、音訊格式的內容均為虛擬資料。其目的僅在於測試大小、副檔名和 MIME 型別的校驗邏輯。
常見問題
不會。生成過程完全在瀏覽器內完成，內容絕不會發送到伺服器。
是的，在支援的瀏覽器（如 Chrome）中，會使用瀏覽器內建的編碼器實際錄製數秒動畫，因此開啟後即可播放。檔案的大部分內容是為了精確匹配指定大小而填充的資料。MP4 在不支援錄製的瀏覽器中會自動切換為"僅容器結構有效的佔位檔案"，因此生成本身不會失敗。WebM 僅在支援錄製的瀏覽器中可以選擇。
這兩種格式記錄檔案大小的欄位在規範上固定為 32 位（最大約 4.29 GB）。這並非我們實現上的限制，而是格式規範本身的上限。
TXT、CSV、JSON、BIN、PNG、PDF、MP4、WebM 在格式規範上沒有上限，因此使用支援直接寫入磁碟的最新版 Chrome 或 Edge，即可生成非常大的檔案。
閒話 ― "有效檔案"與"損壞檔案"的分界線
大多數檔案格式都保留了解析器"可以跳過"的區域，例如 PNG 的未知資料塊、MP4 的 free box，以及 WebM 的 Void 元素等。這些區域最初就被設計為"為未來擴充套件保留、當前解析器應當忽略"的空間，因此即使填入無意義的資料，檔案也不會因此損壞。
對於影片，我們在填充資料之前放置真實的影像，使其能夠真正播放。由於自行編寫編解碼器的位元級編碼難以保證正確性，因此改為讓瀏覽器自身內建的編碼器（MediaRecorder API）實際錄製數秒的畫布動畫，再在其後追加填充資料。這種方式兼顧了"始終確保返回有效檔案"的原則與"使用者希望真正看到影片"的需求。
有趣的是，ZIP 檔案只需讀取末尾的"中央目錄"即可獲知全部內容列表。據說這一設計源自磁帶時代從末尾讀取的操作方式，如今這也是能夠從體積巨大的 ZIP 中快速提取單個檔案的原因。