虛擬檔案是一種具備精確預設位元組長度、並填入指定內容模式的檔案 — 內容可以是零、安全隨機位元組，或重複的 UTF-8 文字 — 整個檔案在本機端產生，用於測試檔案處理程式碼，而無需上傳任何資料。開發人員會使用這些佔位檔案來重現上傳上限錯誤、驗證附件大小規則、在高負載下量測進度條、計算跨網路的傳輸吞吐量、檢驗總和檢查碼管線，以及重現磁碟配額條件，而無需費心尋找恰好符合所需大小的真實文件。這類檔案最適合被理解為受控的測試素材：長度可預測、內容政策可預測，且在測試執行完畢後即可丟棄。Dummy File Generator 將這個概念轉化為一個單一頁面的工作流程，完全在您的瀏覽器分頁中執行 — 每個位元組皆使用瀏覽器的 Web Crypto API 以 JavaScript 建構亂數，並以一般的 Blob 形式下載，您可以驗證其邏輯位元組數量，且整個過程絕不經過網路傳輸。這種本機優先的設計讓您能視需求產生特定的檔案名稱、精確的大小（最高可達 50 MiB），以及可壓縮或不可壓縮的內容；這在測試環境禁止將真實客戶資料、甚至連看似虛構的資料上傳到遠端服務時尤其重要。
虛擬檔案的內容與非內容
虛擬檔案是一種受控的測試產物，其內容本身並無語意意義。這些位元組的選擇，是為了讓大小可預測、壓縮行為可預測，以及跨次執行的特性可重現，而不是為了讓它們可讀或具備意義。當您將檔名設定為類似 report.pdf 或 photo.png 的形式時，副檔名會原封不動地傳遞到下載屬性中，但檔案主體仍會維持您所選的內容模式。換句話說，一個以零位元組產生的 photo.png 並不是一個有效的 PNG 檔案，即使副檔名是 .png — 它是一個由 0x00 值組成、具有可辨識檔名的 100 位元組串流；正因為如此，它非常適合用於測試應用程式在副檔名看似合理、但格式錯誤的情況下會如何反應。
在重現錯誤路徑時，檔名、副檔名與實際內容之間的分離至關重要。真實的測試照片往往過於逼真，無法上傳到預備環境；而真實的 PDF 可能帶有會被正式環境驗證器拒絕的中繼資料。虛擬檔案則巧妙地避開了這兩個問題：它具備您指定的大小，並遵循您選擇的內容政策，且不包含任何嵌入式中繼資料、MIME 提示，或任何可能誤觸不相關驗證器的隱藏結構。
三種內容模式及其權衡
| 模式 | 內容 | 易於壓縮？ | 適用情境 |
|---|---|---|---|
| 零 | 每個位元組皆為 0x00，寫入有界定的 Uint8Array 區塊中 | 是，壓縮效果極為顯著 | 重現上傳上限、配額錯誤、低熵酬載的大小量測 |
| 安全隨機 | 以最多 65,536 位元組為單位區塊的 Crypto.getRandomValues 位元組 | 否，無法壓縮 | 最壞情況的傳輸時間、總和檢查碼管線、雜湊值的確定性 |
| 重複 UTF-8 文字 | 將輸入的模式以 TextEncoder 編碼後重複填滿至精確大小，在不完整的 UTF-8 邊界處以 ASCII 空格填補 | 是，壓縮率極高 | 可重現的內容形狀、以行為基礎的剖析器、文字測試固定資料 |
這些模式之間的選擇，會改變檔案在網路上與磁碟上的行為。零位元組與重複文字皆能積極壓縮；一個 50 MiB 的零位元組檔案，若傳輸端套用 gzip 或類似的編碼器，可能僅以數 KB 的大小進行傳輸。相較之下，安全隨機位元組本質上即無法壓縮 — 每個區塊在加入 Blob 之前，皆已由 Web Crypto API 填入對應的值，因此最終檔案能如實反映傳輸吞吐量，並為 MD5、SHA-1 與 SHA-256 等總和檢查碼演算法提供可靠的輸入。
若您需要相同的邏輯大小但位元組可預測（例如用於跨次執行比較總和檢查碼），零位元組模式是最具重現性的選擇。若您需要相同的邏輯大小但具備高熵特性，則安全隨機模式是正確的選擇。重複文字模式則介於兩者之間：它提供一個可辨識的位元組序列，同時仍能填補至精確的要求大小；這在您希望掃描日誌行或比對連續測試下載結果時相當實用。
建構並下載檔案
產生器接受三項輸入，以一系列有界定的區塊建構檔案，接著發布一個 Blob，其大小會在下載連結啟用前與您要求的位元組數進行核對。整個建構流程會以延遲的瀏覽器任務形式執行，以確保在位元組建構開始前先呈現忙碌狀態。
- 輸入一個安全的檔名。檔名會經過驗證，而非默默進行清理 — 空字串、前後空白字元、正斜線或反斜線、以相似字元偽裝的斜線、C0 與 C1 控制碼、零寬度與雙向格式化字元、Unicode 行分隔符（如 CON、NUL、COM1、LPT1 等 Windows 裝置名稱），以及以句點結尾的名稱，皆會遭到拒絕，讓錯誤立即顯示出來，而非在稍後產生不安全的下載。
- 輸入位元組大小，必須是介於 1 與 52,428,800 之間的整數十進位數字（即 50 MiB 的精確上限）。僅接受數字 — 不接受正負號、小數點、指數、逗號、單位後綴或前後空白字元。邊界值 52,428,800 會被接受；下一個位元組 52,428,801 則會被拒絕。超出預算的數字會保留在輸入欄位中而不會被 HTML 長度上限截斷，這使得產生器能明確回報拒絕的結果。
- 選擇內容模式。若選擇零位元組，則無需其他輸入。若選擇安全隨機位元組，同樣無需其他輸入 — 產生器會以每次呼叫最多 65,536 位元組的區塊，從瀏覽器的 Web Crypto API 提取亂數。若選擇重複 UTF-8 文字，則需輸入一個不為空、且最多 10,000 個 UTF-16 字碼單位的模式，且不得包含未配對的代理項；表情符號與輔助平面字元可接受，因為 TextEncoder 會將其轉為多位元組的 UTF-8 表示。
- 產生 Blob。位元組區塊會在記憶體中進行加總，最終 Blob 的大小會經過驗證，確保與要求的數值完全相符，並將一個 ObjectURL 發布至當前的下載連結。連結的 download 屬性會設定為經驗證的檔名，確保瀏覽器本機的儲存對話框接收到與您輸入相同的名稱。
- 確認顯示於下載按鈕旁的位元組摘要。摘要會回報邏輯位元組數（即 Blob.size 的值），而非檔案系統的 配置區塊 — 即使經過檔案系統層級的壓縮，長串的零位元組在實體磁碟上所占用的空間可能遠少於 50 MiB，邏輯位元組數仍維持不變。
若您在成功產生後變更了檔名、大小、內容模式或文字模式，先前的 ObjectURL 將會被撤銷，舊的成功與錯誤狀態會被清除，並根據更新後的輸入重新執行一次產生作業。編輯任何欄位皆會遞增作業世代編號，使得在替換後才完成的過時任務能被識別並撤銷，而非被發布。下載連結永遠僅指向目前由該世代所擁有的 Blob。
大小邊界與 UTF-8 填補規則
50 MiB 的上限會被嚴格執行：恰好 52,428,800 位元組的要求會通過；52,428,801 位元組的要求會被拒絕。大小以十進位位元組表示，絕不使用千位元組或 mebibyte，且驗證器不會默默進位。這表示像 49,000,000 位元組這樣的大小會產生一個 49,000,000 位元組的檔案，而非 47 MiB 或 48 MiB 的近似值。在正式環境強制非整數限制（例如「檔案大小上限 49 MB」）的測試情境中，輸入 49,000,000 位元組即是重現邊界行為的精確方式。
重複文字模式加入了一項純零位元組與隨機模式所沒有的複雜性：每個字元所占的位元組數並不固定。ASCII 字母每個佔 1 位元組，帶腔調的拉丁字母（例如「é」）佔 2 位元組，CJK 字元通常佔 3 位元組，而表情符號與輔助平面字元則佔 4 位元組。產生器會將輸入的模式以 TextEncoder 編碼為 UTF-8，重複產生的位元組序列直到達到要求的大小，接著以特定的規則處理剩餘的位元組。
以下是一個具體的邊界範例。輸入模式「é」，其在 UTF-8 中編碼為兩位元組序列 C3 A9，並要求大小為 5 位元組。兩次完整重複會消耗 2 × 2 = 4 位元組。剩餘的 1 位元組無法容納另一個「é」，因為該字元需要 2 位元組 — 該模式下沒有任何前綴可置入 1 位元組之中，因為模式中最小的完整碼點本身就佔 2 位元組。因此產生器會以恰好一個 ASCII 空格 (0x20) 填補剩餘部分，產生 4 + 1 = 5 位元組的總大小，並構成一個有效的 UTF-8 檔案。若要求為 6 位元組，產生器則會產生三次完整的「é」重複且不進行填補，因為第三次重複能完整容納。測試確認在每個填補邊界上，致命的 UTF-8 驗證皆能成功，因此位元組必定能通過嚴格的 UTF-8 解碼器進行完整往返。
同一規則亦可讓您從僅含表情符號的模式建立一個單一位元組的檔案。以四位元組的表情符號 🚀（U+1F680，編碼為 F0 9F 9A 80）進行 1 位元組的要求，連表情符號的前綴都無法容納，因此該檔案會變成單一 ASCII 空格，而非無效的位元組片段。可見的摘要會揭露重複文字的政策，說明文字也會解釋最後的填補方式，因此這並非默默進行的替換。
留在您瀏覽器中的內容
位元組建構、Blob 組裝、ObjectURL 建立與下載皆於當前的瀏覽器分頁中執行。不會有任何產生的位元組、所選的檔名或輸入的文字模式被傳送至遠端服務或 Lizely 的伺服器。隨機模式的產生器會從瀏覽器的 Web Crypto API 提取數值，每次呼叫最多以 65,536 位元組的區塊進行 — 這是底層 API 所遵守的大小 — 之後該緩衝區會被附加至 Blob。
由於驗證器不會重寫不安全的字元，僅會予以拒絕，因此檔名驗證相當嚴格。通過驗證的檔名會原封不動地作為下載屬性，這能防止類似 ../report.pdf 的請求默默變成相對路徑。即便經過驗證，若作業系統拒絕該檔名，瀏覽器自身的下載處理程序仍可能重新命名或拒絕該檔名 — 此類外部行為並不會改變已產生的位元組。
關閉頁面或編輯輸入欄位會撤銷記憶體中的下載 URL，因此若您將產生器長時間保持開啟，請在任何下載前重新產生檔案，切勿依賴過時的 ObjectURL。50 MiB 的上限已屬保守，但產生器在建構檔案時仍會配置真實的記憶體，因此請避免同時開啟數十個大型產生的分頁。隨機模式產生的檔案在磁碟上也較難壓縮；零位元組與重複文字的檔案則能大幅壓縮。請勿使用產生的檔案來規避服務限制、耗盡他人的儲存空間，或在未經授權的情況下測試系統。對於結構化的開發者資料（例如 JSON 酬載或唯一識別碼），JSON Formatter 與 UUID Generator 會比原始位元組檔案更為合適。
Matching the File to a Testing Scenario
The content mode you choose should match what the system under test actually does with the bytes. Compression-aware upload pipelines, checksum pipelines, and progress-bar timing tests behave very differently on highly compressible zero streams than on incompressible random streams, so the qualitative row below points you to the right mode and the generator confirms the exact figures.
| Scenario | Recommended mode | Why |
|---|---|---|
| Validate an upload size limit at the application layer | Zero | Logical size is exact; file compresses cheaply through HTTP |
| Reproduce a customer "file too large" error message | Zero | Fastest generation, predictable block alignment |
| Time transfer throughput on a saturated link | Secure random | Incompressible payload reflects real-world timing |
| Generate a known hash for a checksum test | Secure random | Entropy is uniform; checksums match the byte stream exactly |
| Reproduce a quota-error message at exactly N MiB | Zero or repeated text | Easy to step through multiple boundary values |
| Feed a line-based parser a recognisable fixture | Repeated UTF-8 text | Lines are predictable and diff-able; padding lands on character boundaries |
| Compare a "valid PNG by extension" path against a real PNG validator | Any mode with a .png name | The bytes are not a real PNG; the extension is just the download name |
For developers who want a single source of reproducible test material across machines, repeated text is the easiest option — every run produces the same bytes for the same size and pattern. For developers who need entropy, secure random is the only choice. For developers who need a file shaped exactly like an upload limit, zero is the smallest, fastest, and most predictable. All three modes run through the same Dummy File Generator workflow, and switching modes never requires re-uploading a reference file or seeding an external dependency.