在 Windows 上，所謂空檔案是指邏輯位元組數恰好為 0 的檔案——但在測試、驗證與基準測試的工作流程中，通常需要的是一個位元組數精確且非零的檔案，而非零位元組的佔位檔案。虛擬檔案產生器可在您目前的瀏覽器分頁中產生一個本機虛擬檔案，並提供嚴格的檔名、精確的整數位元組數（範圍 1 到 52,428,800，即 50 MiB），以及可選擇的內容模式：全零位元組、安全隨機位元組，或重複的 UTF-8 文字。每個位元組都使用標準瀏覽器 API 建構——Blob、URL.createObjectURL、Crypto.getRandomValues 以及 TextEncoder——且不會上傳至 Lizely 或傳送至其他服務。這使得本工具在 Windows 上特別實用，當您想跳過 fsutil、PowerShell 或系統管理員提示時，或當您需要一個位元組數精確的檔案，而非 4 KiB NTFS 配置單位倍數的檔案時，更是如此。建構、位元組驗證與下載皆在目前分頁中完成，因此該檔案會以您指定的名稱與確切大小，存放在您的下載資料夾中。
為何 Windows 開發人員需要精確大小的測試檔案
Windows 提供數種內建方式來建立檔案：在檔案總管中按右鍵選擇新增 → 文字文件、在 CMD 中執行 type nul > file.txt，或在 PowerShell 中呼叫 New-Item。這些方式在處理簡單的零位元組檔案時都有效，但當任務是要建立一個位元組大小精確的檔案時——例如，1,234,567 位元組以重現上傳上限的邊界情況，或 25 MiB 檔案以測試在四分之一點出錯的進度條——就會顯得笨拙。Windows 的 fsutil file createnew 指令可以產生精確位元組數的疏鬆零填檔案，但它需要系統管理員等級的命令提示字元，且路徑必須已存在於磁碟上。
基於瀏覽器的產生器迴避了這項限制。虛擬檔案產生器完全在您的瀏覽器分頁中執行，因此無需安裝程式、不需修改 PATH，也不會出現 UAC 提示。您只需提供名稱、整數位元組大小以及內容原則，該頁面就會建構一個具有精確邏輯位元組數的 Blob，驗證 Blob.size 是否符合您的要求，並發佈下載連結。您收到的檔案是一般的檔案，其位元組長度符合您所輸入的數字；之後發生的變化——壓縮、NTFS 配置區塊、重複資料刪除——皆超出產生器的掌控範圍，也非其責任所在。
如何在瀏覽器中於 Windows 建立空檔案
當您需要在 Windows 上取得精確位元組數的檔案，卻不想開啟權限提高的終端機或安裝命令列工具時，請使用以下程序。
- 在您目前的瀏覽器分頁中開啟虛擬檔案產生器。
- 在名稱欄位中輸入安全的檔名。名稱不得為空、不得包含路徑分隔符號與控制字元，且不得為 Windows 保留的裝置名稱，例如 CON、NUL、COM1 或 LPT1。
- 輸入精確的整數位元組大小，僅能使用數字——不可有正負號、小數點、單位後綴，也不可有前後空白字元。可接受的範圍為 1 到 52,428,800 位元組。
- 選擇內容模式：全零位元組（全部為 0x00）、安全隨機位元組（用於不可壓縮的測試資料），或重複的 UTF-8 文字（用於您可自行控制的決定性模式）。
- 若您選擇重複的 UTF-8 文字，請輸入至少一個字元、最多 10,000 個 UTF-16 程式碼單位的模式。可接受有效的表情符號與輔助字元。
- 點擊 generate。頁面會建構 Blob，驗證 Blob.size 是否完全等於所要求的大小，並顯示帶有位元組原則與內容原則摘要的下載連結。
- 點擊下載連結。檔案會以您輸入的精確名稱與所要求的精確邏輯位元組數，儲存至瀏覽器的下載資料夾。
整個工作流程皆在目前分頁中進行，因此關閉或重新載入頁面會撤銷記憶體中的 ObjectURL。若您編輯名稱、大小或文字，則在開始新工作之前，舊的 URL 會被撤銷，舊的成功狀態也會被清除。若要比較其他作業系統的做法，請參閱如何在任何瀏覽器中以精確大小建立空檔案。
三種內容模式及其使用時機
本產生器提供三種內容原則。每種都會產生您輸入的精確位元組數，但當下游工具進行壓縮、雜湊或封存時，這些位元組的表現差異極大。請選擇符合您想測試屬性的模式。
| 模式 | 寫入內容 | 可壓縮性 | Windows 最佳使用情境 |
|---|---|---|---|
| 全零位元組 | 每個位元組皆為 0x00，以有界的 Uint8Array 區段寫入。 | 幾乎可壓縮至無大小。 | 重現疏鬆檔案狀況、測試 NTFS 壓縮，或檢查傳輸管道回報的是邏輯位元組數而非壓縮後大小。 |
| 安全隨機位元組 | 由瀏覽器的 Web Crypto getRandomValues API 以每次最多 65,536 位元組（文件記載的單次呼叫上限）的區塊填入位元組。 | 實際上不可壓縮。 | 總和檢查碼管道、雜湊碰撞測試、傳輸時間基準測試，以及任何需要壓縮後大小符合邏輯大小的情境。 |
| 重複的 UTF-8 文字 | 您的文字模式以 UTF-8 編碼並重複填滿要求的大小；任何無法容納完整程式碼點的剩餘位元組會以 ASCII 空格填補。 | 可良好壓縮，但檔案仍保持有效的 UTF-8。 | 重現已知的文字酬載、為解析器測試產生樣板內容，以及驗證下游工具將檔案讀為 UTF-8 而非亂碼。 |
50 MiB 的邊界值正好等於 52,428,800 位元組，因為本產生器以二的冪次而非十的冪次計算位元組。逐步乘以單位：50 × 1024 = 51,200 KiB，而 51,200 × 1024 = 52,428,800 位元組。該值會被接受；下一個位元組 52,428,801 則會被拒絕並顯示錯誤。可見的摘要回報的是邏輯位元組，而非檔案系統的配置區塊，因此一旦 NTFS 壓縮或傳輸工具執行後，全零的 50 MiB 檔案實際占用的空間可能遠小於此。
Windows 的檔名安全性：哪些會被拒絕
本產生器會驗證名稱，而非靜默地清理名稱。被頁面接受的名稱會原封不動地用作瀏覽器的 download 屬性，因此您所見即 Windows 所見。之所以有這些驗證規則，是因為 Windows 與 NTFS 會將多種形式視為路徑、裝置或隱藏格式，而非一般檔名：
- 空名稱、前後空白字元，以及以點結尾的名稱會被拒絕。
- 正斜線、反斜線，以及常見檔案系統保留的 Unicode 範圍中的斜線相似字元會被拒絕，因此名稱不會意外變成目錄遍歷。
- C0 與 C1 控制字元、零寬度與雙向格式控制字元，以及 Unicode 行分隔符號會被拒絕，這可避免由右至左覆寫等偽造手法進入產生的檔名。
- Windows 裝置名稱——CON、NUL、PRN、AUX、COM1 到 COM9，以及 LPT1 到 LPT9——會被拒絕，因此本產生器不會靜默地產生與保留裝置控制代碼衝突的檔案。
- 常見檔案系統保留的標點符號，包括常用於 shell 重新導向或替代資料串流的字元，皆會被拒絕。
被接受的名稱會逐字用作 download 屬性。該屬性是對瀏覽器的提示：若下載資料夾中已有同名的檔案，或 Windows 原則拒絕該名稱，作業系統可能會在儲存時重新命名該檔案。重新命名屬於外部行為；檔案內的位元組不會改變。
Windows 上虛擬測試檔案的常見使用情境
精確大小的虛擬測試檔案在 Windows 端的開發與維運作業中反覆出現。以下列舉幾個實際情境：
- 上傳限制驗證。透過逐步調整大小（例如 1 MiB、10 MiB 以及文件記載的上限），確認伺服器會拒絕超出限制的附件，並接受低於限制的附件。
- 儲存配額測試。重現 Windows 服務或共用資料夾拒絕新寫入作業的精確位元組數，無需費心尋找恰好符合的真實文件。
- 進度指示器與傳輸基準測試。使用安全隨機位元組（壓縮效果不佳）來測量實際傳輸時間與進度條更新，而非讓壓縮串流使上傳看起來比實際更快。
- 總和檢查碼管道。將已知的隨機虛擬檔案透過 SHA-256 或其他雜湊函式進行處理，確認當位元組未變動時，總和檢查碼管道回報穩定的值，而在位元組不同時回報不同的值。
- 應用程式錯誤訊息。透過提供檔名使用常見副檔名但內容為全零、隨機位元組或重複文字的檔案，強制解析器顯示「檔案過大」或「不支援的類型」錯誤。
無論您選擇何種模式，皆適用以下兩項實務警告。首先，50 MiB 的虛擬檔案在建構期間與作為 ObjectURL 持有時，仍會在分頁中消耗實際的記憶體，因此應避免在多個平行分頁中產生多個大型檔案。其次，請勿使用產生的檔案來規避服務限制、耗盡他人的儲存空間，或探測您未擁有或未獲授權測試的系統——本工具旨在您自己的開發環境中重現檔案大小條件，並非用於對第三方進行壓力測試。
本工具不會產生的內容
本產生器會建立原始的測試位元組；僅因檔名以特定副檔名結尾，並不會自動使其成為有效的 PNG、PDF、ZIP、MP4、可執行檔或任何其他語意上有效的格式。以全零位元組建構、命名為 report.pdf 的檔案無法作為 PDF 開啟；可執行檔也無法執行。若您需要結構化的測試固定資料，請使用能建構真實格式位元組的工具——例如，JSON 格式化工具用於 JSON 形式的酬載、UUID 產生器用於識別碼固定資料，或 ASCII 表格參考用於純 7 位元文字。
本工具亦不會保留隨機模式的種子，因此日後無法重現完全相同的隨機檔案。它並非密碼產生器、加密系統、安全抹除工具、金鑰衍生函式，也無法證明下載的位元組在分享後仍保持機密。請將隨機虛擬檔案僅視為測試資料。