空白檔案其實就是一個位元組數已知且內容策略明確的檔案，你可以直接在瀏覽器分頁中透過 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。
- 輸入一個安全的檔名。空白的檔名、前後空白、點路徑、斜線、控制字元，以及 Windows 裝置名稱(例如 CON、NUL、COM1 或 LPT1)會在一開始就被拒絕;你輸入的檔名會原封不動地用作下載屬性。
- 輸入一個介於 1 到 52,428,800 (50 MiB)之間的整數位元組數。僅限數字 — 不接受正負號、小數點、指數、逗號、單位後綴，或前後空白。
- 挑選一種內容模式:零位元組、安全隨機位元組，或重複的 UTF-8 文字。
- 如果你選擇重複的 UTF-8 文字，請輸入一個非空白、長度不超過 10,000 個 UTF-16 碼位、且不含未配對 Unicode 代理項的樣式。可接受有效的表情符號與輔助字元。
- 點擊「產生」。工具會交由瀏覽器任務處理，建構 Blob 區段，加總其長度，並驗證最終的 Blob.size 是否等於所要求的值。
- 讀取螢幕上的位元組摘要。它會回報邏輯位元組數(而非檔案系統配置區塊)，以及你所選擇的內容策略。
- 點擊「下載」來儲存檔案。瀏覽器會以你所輸入的精確邏輯位元組數來遞送該檔案。
為什麼精確的位元組數很重要
用於測試的空白檔案，只有在能信任其大小時才有用。Dummy File Generator 接受介於 1 到 52,428,800 位元組之間的封閉範圍。52,428,800 這個邊界，正好等於 50 × 1,024 × 1,024，可以接受，但只要再多一個位元組，就會以明確的錯誤訊息拒絕。大小欄位僅接受數字，不含正負號、小數點、指數、逗號、單位後綴，或前後空白，該值會被視為精確的十進位位元組數，而不是大小提示。工具會建構區段、加總其長度、建立 Blob，並在下載連結發布之前，驗證 Blob.size 是否等於所要求的值。這裡不會默默四捨五入到千位元組，沒有抽樣、沒有隮藏實際值的預算上限，也沒有假裝輸入很短的 HTML 長度上限。所回報的位元組摘要是邏輯位元組數，不是磁碟上的壓縮大小，也不是檔案系統的配置區塊，所以同一個檔案實際占用的空間可能會小於顯示的數字。如果你輸入的大小無法被滿足，工具會回報對應的錯誤，而且不會讓先前成功的下載連結繼續顯示。
虛擬檔案能為你節省時間的情境
與其費心尋找一個大小剛好的真實文件，一個精確的虛擬檔案會更快也更可靠。常見的使用情境包括:
- 分別串流 49,999,999 位元組、50,000,000 位元組、52,428,800 位元組，以及 52,428,801 位元組(工具會拒絕產生)，藉此驅動上傳限制測試。
- 將確定性的零位元組檔案與服務預期的摘要進行比較，藉此重現總和檢查碼或雜湊不符的情況。
- 驗證一個會拒絕空白上傳或低於最小位元組數之檔案的附件驗證器。
- 使用受控內容來為下載路徑計時 — 隨機模式用於不可壓縮位元組，重複文字模式用於高度可壓縮位元組。
- 以已知的 MiB 數量填滿目標分割區，藉此重現儲存配額錯誤，而不需要複製真實文件。
- 透過從乾淨的來源重複相同的精確位元組數，測試不同連線下的進度條與傳輸時間。
這些情境正好是本地端產生的檔案優於第三方範例的時候，因為你可以從頭到尾完全掌控位元組內容，而且工具絕不會上傳該檔案、檔名，或你所選擇的文字樣式。50 MiB 的上限算是保守的設定，但這麼大的虛擬檔案仍然會消耗記憶體與磁碟空間;請避免一次在多個分頁中產生多個大型檔案。
天生就在瀏覽器本地端且注重隱私
所產生檔案的每一個位元組都是在你的瀏覽器分頁中建構的。Blob 由本地區段組成，下載 URL 是透過瀏覽器的 URL.createObjectURL 產生，檔案則透過一般的瀏覽器下載機制遞送到你的下載資料夾。沒有任何產生的位元組、檔名或文字樣式會被上傳到 Lizely 或送到其他服務。下載 URL 會在你開始新的一次產生、卸載頁面，或關閉分頁時被撤銷，這就是為什麼重新產生沒問題，但期望同一個下載 URL 在不同工作階段之間仍然有效則不可行。隨機模式的位元組來自瀏覽器的 Web Crypto API，且無法設定種子，所以同一個隨機檔案之後無法再次重現，而且這個工具明確不是一個密碼產生器、加密系統、安全清除工具，或金鑰衍生函式。檔案系統、瀏覽器、傳輸工具或封存檔可能會有效率地壓縮長串的零位元組連續區段或重複文字，所以實體磁碟使用量或壓縮後的傳輸大小，可能會與摘要中回報的邏輯 Blob 大小有所不同。
如果想用 Windows 命令列方式完成相同的工作，請參考 Create a Dummy File in CMD with Exact Size and Content(在 CMD 中以精確大小與內容建立虛擬檔案)指南。
如果想進一步了解，請參考 How to Get a Linear Gradient in Canva with Exact CSS(如何在 Canva 中以精確 CSS 取得線性漸層)。