虛擬檔案生成器
在瀏覽器中生成圖片、音訊、影片、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 | 無壓縮的單條目歸檔 |
什麼是虛擬檔案生成器
開發上傳功能時，需要確認大小限制和副檔名校驗是否真的按預期運作。這就需要一份「恰好是指定位元組數、同時對該格式仍然有效」的檔案，而這樣的檔案通常很難現成找到。本工具可以生成文字、圖片、音訊、影片、PDF、ZIP 壓縮檔等多種格式，且每一份都精確符合您指定的大小。
生成的每份檔案都是符合其格式規範的有效資料。許多格式都預留了解析器可以忽略的區域，本工具正是利用這些區域來填充大小，因此開啟時不會出現錯誤。所有處理都在瀏覽器內完成，生成的內容不會被傳送到伺服器。需要注意的是，WAV 和 ZIP 因格式規範限制，上限均為 4 GiB。
虛擬檔案的生成方法
- 選擇檔案格式 選擇測試對象所接受的格式。若想測試副檔名或 MIME 型別校驗，請直接選擇對應的格式。
- 指定檔案大小 輸入數值和單位。若限制為「10MB」，需注意其邊界會因解讀為 10,000,000 還是 10,485,760 位元組而不同。
- 設定檔案名稱 可以在名稱中包含副檔名。若想測試依檔名判斷的攔截規則，可在此處修改後確認效果。
- 生成並下載 點擊「生成」即可建立檔案。較大的檔案需要更長時間，期間可隨時取消。
用好本工具的小技巧
- 上傳表單的校驗邏輯通常會分別檢查副檔名、MIME 型別、檔案大小這三項。由於本工具生成的檔案在其他方面均符合規範，因此可以單獨針對大小限制進行測試。
- "最大 10MB" 這樣的限制，在不同實現中可能是 10,000,000 位元組（106），也可能是 10,485,760 位元組（220）。單位選擇器支援這兩種進位制，因此可以同時測試恰好達到邊界值和超出 1 位元組的情況。
- Chrome 和 Edge 會直接將資料流式寫入所選驅動器，因此即使是數十 GB 規模的檔案也不會佔用大量記憶體。Firefox 和 Safari 需要先在記憶體中組裝檔案，因此大小存在實際上限。
- 在支援的瀏覽器中，影片（MP4/WebM）會使用瀏覽器內建的編碼器實際錄製數秒動畫，因此開啟後可以真正播放。除此之外的部分（佔檔案絕大部分的填充資料）以及其他圖片、音訊格式的內容均為虛擬資料。其目的僅在於測試大小、副檔名和 MIME 型別的校驗邏輯。
虛擬檔案的應用場景
上傳上限的邊界值測試
分別生成恰好達到上限和超出 1 位元組的檔案進行測試，確認錯誤提示是否在規範規定的邊界處準確出現。
副檔名與 MIME 型別判定確認
分別生成允許和禁止的格式並提交，即可分辨系統究竟是依據哪個標準進行攔截。
大容量傳輸行為驗證
使用數 GB 規模的檔案，可以驗證進度顯示、逾時處理以及中斷後恢復是否正常運作，無需準備真實資料。
儲存空間與頻寬的預估
實際放置預期大小的檔案，即可測量儲存占用量和傳輸所需時間。
檔案校驗相關術語
- MIME 型別
- 表示檔案種類的字串，寫作
image/png這樣的形式，常用於判斷是否允許上傳。 - 邊界值測試
- 一種測試方法，檢查上限或下限的確切邊界及其前後的值，因為缺陷最容易在這些位置出現。
- 填充資料
- 為達到目標大小而新增的無意義資料。由於填充在格式允許忽略的區域，檔案內容不會因此損壞。
- GiB 與 GB
- GiB 指 1,073,741,824 位元組，GB 指 1,000,000,000 位元組。這項差異是上限解讀出現偏差的常見原因。
- 串流寫入
- 將資料逐步寫入目標位置的方式，因此無需將全部內容載入記憶體即可處理體積很大的檔案。
常見問題
閒話 ― "有效檔案"與"損壞檔案"的分界線
大多數檔案格式都保留了解析器"可以跳過"的區域，例如 PNG 的未知資料塊、MP4 的 free box，以及 WebM 的 Void 元素等。這些區域最初就被設計為"為未來擴充套件保留、當前解析器應當忽略"的空間，因此即使填入無意義的資料，檔案也不會因此損壞。
對於影片，我們在填充資料之前放置真實的影像，使其能夠真正播放。由於自行編寫編解碼器的位元級編碼難以保證正確性，因此改為讓瀏覽器自身內建的編碼器（MediaRecorder API）實際錄製數秒的畫布動畫，再在其後追加填充資料。這種方式兼顧了"始終確保返回有效檔案"的原則與"使用者希望真正看到影片"的需求。
有趣的是，ZIP 檔案只需讀取末尾的"中央目錄"即可獲知全部內容列表。據說這一設計源自磁帶時代從末尾讀取的操作方式，如今這也是能夠從體積巨大的 ZIP 中快速提取單個檔案的原因。