一個空白檔案，說穿了就是一個位元組數已知、內容政策明確的檔案，而你可以用Dummy File Generator直接在瀏覽器分頁中產生一個。你輸入一個安全的檔名，選擇一個介於 1 到 52,428,800（恰好 50 MiB）之間的整數位元組數，選擇三種內容政策之一，這個工具就會在本機建立一個 Blob，讓你下載到你所要求的確切邏輯大小。因為產生過程是在本機完成的，沒有任何內容會被上傳到任何服務，經過驗證後的檔名會原封不動地當作下載屬性使用，而產生出來的位元組，正好就是大小欄位所描述的內容。這三種內容政策分別是：全零位元組（整份檔案重複填入位元組值 0x00）、安全隨機位元組（透過瀏覽器的 Web Crypto getRandomValues API，以每次最多 65,536 位元組的區塊填入），或重複的 UTF-8 文字（你的樣式會以 UTF-8 編碼並重複填滿到所要求的大小，最後一段不足的部分會以空格補齊，以確保邊界仍然有效）。這種做法能讓你在上傳限制測試、附件驗證器、儲存配額模擬、進度條計時、下載處理、封存檔行為，以及檢查碼流程與錯誤路徑測試中，取得可重現的大小與內容條件，全程都不需要離開你的瀏覽器分頁。
當你在做測試時，「空」代表什麼
在日常對話中，「空」檔案通常代表零位元組。但在開發者測試的情境中，這個詞的定義會稍微延伸一些。一個全部都是零、全部都是同一個位元組值，或是重複已知字串的檔案，就其中沒有任何真正由人撰寫的文件內容這一點而言，仍然是一個「空」檔案。Dummy File Generator 區分出三種意義，讓你能選擇符合你實際想執行的測試的那一種。全零模式會從第一個位元組到最後一個位元組，只產生位元組值 0x00，這是最接近傳統空檔案的形式，也是最容易壓縮的一種。安全隨機模式會產生一個位元組完全沒有規律可循的檔案，適合用於需要不可壓縮素材的雜湊、去重複，或抗壓縮測試。重複文字模式會產生一個內容為已知 UTF-8 字串、重複填滿所需長度的檔案，最後一段會使用能完整容納的最長碼點前綴，任何剩下的一到三個位元組則以 ASCII 空格補齊，因此即使在邊界處，檔案仍然是有效的 UTF-8。當某個驗證器會拒絕純空位元組、但你仍然想要完全掌控確切位元組數時，最後這種模式就很有用。
一覽三種內容模式
下表比較了每種模式會放進檔案中的內容，以及各自最適合的測試類型。隨機位元組是透過瀏覽器的 Web Crypto API 在本機產生的，而零位元組模式與文字模式的位元組層級內容則是確定且可重現的。
| 內容模式 | 檔案中實際的內容 | 最適合 |
|---|---|---|
| 零位元組 | 每個位元組都是 0x00，以有邊界的 Uint8Array 區段分配。 | 可重現的空檔案測試、上傳限制邊界情況、稀疏檔案與連續零值的效能測試。 |
| 安全隨機位元組 | 透過 Web Crypto getRandomValues 以不超過 65,536 位元組的區塊填入。 | 檢查碼與雜湊測試、抗壓縮測試、去重複驗證。 |
| 重複的 UTF-8 文字 | 你的樣式以 UTF-8 編碼、重複填滿至所需大小，最後一段以空格補齊。 | 需要非空內容的驗證器、MIME 偵測測試、標頭存在性測試、文字路徑編碼檢查。 |
如何在你的瀏覽器中建立確切大小的空檔案
以下確切的步驟，會產生一份位元組數由你指定的單一虛擬檔案。整個產生過程完全在目前的瀏覽器分頁中執行，在你儲存下載檔之前，不會有任何內容離開你的機器。
- 在你的瀏覽器中開啟 Dummy File Generator。
- 輸入一個安全的檔名。空白名稱、前後多餘的空白字元、點狀路徑、斜線、控制字元，以及像 CON、NUL、COM1 或 LPT1 這類 Windows 裝置名稱，都會在一開始就被拒絕；你輸入的名稱會原封不動地當作下載屬性使用。
- 輸入一個介於 1 到 52,428,800（50 MiB）之間的整數位元組數。只能是數字——不能有正負號、小數點、指數、逗號、單位字尾，或前後多餘的空白字元。
- 選擇一種內容模式：零位元組、安全隨機位元組，或重複的 UTF-8 文字。
- 如果你選擇了重複的 UTF-8 文字，請輸入一個長度不超過 10,000 個 UTF-16 code unit、且不含未配對 Unicode 代理對的非空樣式。有效的表情符號與輔助平面字元都能接受。
- 點選「Generate」。這個工具會交給瀏覽器的一個任務處理，建立 Blob 的各個區段、加總它們的長度，並驗證最終的 Blob.size 是否等於所要求的值。
- 檢視畫面上的位元組摘要。它會回報邏輯位元組數（而非檔案系統的配置區塊），以及你所選擇的內容政策。
- 點選「Download」以儲存檔案。瀏覽器會把它以你輸入的確切邏輯位元組數提供給你。
為什麼確切的位元組數很重要
一個用於測試的空檔案，只有在你能信任其大小時才有用。Dummy File Generator 接受一個介於 1 到 52,428,800 位元組之間的封閉範圍。恰好 52,428,800（也就是 50 × 1,024 × 1,024）的邊界會被接受，多一個位元組就會被明確地拒絕並顯示錯誤。大小欄位只接受數字，不能有正負號、小數點、指數、逗號、單位字尾，或前後多餘的空白字元，而輸入的值會被當作確切的十進位位元組數，而不是一個大小提示。這個工具會建構各個區段、加總它們的長度、建立 Blob，並在提供下載連結之前，驗證 Blob.size 是否等於所要求的值。這裡不存在默默四捨五入成 KB、抽樣、隱藏真實數值的超額上限，也沒有假裝輸入內容很短的 HTML 長度上限。回報的位元組摘要是邏輯位元組數，不是磁碟上壓縮後的大小，也不是檔案系統的配置區塊，因此同一份檔案實際占用的實體空間，可能比顯示的數字更小。如果你輸入的大小無法被滿足，這個工具會回報適用的錯誤，也不會讓先前成功產生的下載連結繼續顯示。
虛擬檔案能幫你省下的時間
一份精確的虛擬檔案，比到處尋找一份大小剛好的真實文件更快、更可靠。常見的使用情境包括：
- 依序串流恰好 49,999,999 位元組、接著 50,000,000 位元組、接著 52,428,800 位元組、再接著 52,428,801 位元組（這個工具會拒絕產生），來驅動一項上傳限制測試。
- 透過比對一個確定性的零位元組檔案與該服務預期的摘要值，重現一個檢查碼或雜湊不符的情況。
- 驗證一個會拒絕空上傳，或拒絕低於最小位元組數檔案的附件驗證器。
- 用可控內容為下載路徑計時——隨機模式用於不可壓縮的位元組，重複文字則用於高度可壓縮的位元組。
- 用一個已知的 MiB 數填滿目標分割區，重現儲存配額錯誤，而不需要複製一份真實文件。
- 透過從一個乾淨來源重複相同的確切位元組數，測試不同連線下的進度條與傳輸時間。
設計上就是瀏覽器本機且私密的
產生出來檔案的每一個位元組，都是在你的瀏覽器分頁中建構出來的。這個 Blob 是由本機的各個區段組成，下載用的 URL 是用瀏覽器的 URL.createObjectURL 建立的，檔案則是透過一般的瀏覽器下載流程送到你的下載資料夾中。沒有任何產生出來的位元組、檔名，或文字樣式，會被上傳到 Lizely 或傳送給任何其他服務。當你開始一次新的產生、離開這個頁面，或關閉分頁時，這個下載用的 URL 就會被撤銷，這也是為什麼重新產生沒問題，但期待同一個下載 URL 能跨越不同瀏覽階段持續存在則不行的原因。隨機模式的位元組來自瀏覽器的 Web Crypto API，無法設定種子，因此同一個隨機檔案之後無法重現，而這個工具明確地不是密碼產生器、加密系統、安全清除工具，或金鑰衍生函式。檔案系統、瀏覽器、傳輸工具，或封存格式，可能會有效率地壓縮長串的零值或重複文字，因此實際的磁碟使用量或壓縮後的傳輸大小，可能與摘要中回報的邏輯 Blob 大小不同。
若想了解在 Windows 命令列上完成同一項工作的做法，請參閱Create a Dummy File in CMD with Exact Size and Content這篇指南。