虚拟文件生成器
在浏览器中生成图片、音频、视频、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 中快速提取单个文件的原因。