我做了一个黑白方块文件传输工具

最近用 AI 做了一个小工具：把文件变成一段像老式黑白电视没信号时的“雪花视频”，再从画面里把文件还原出来。

起因很实际。有些环境里，把文件复制进去很方便，想把里面生成的日志、配置拿出来查看，却没那么顺手。

这让我想起之前在阮一峰老师博客里看到过的类似思路：把文件编码成黑白画面，连起来做成视频，需要的时候再解码。GitHub 上也有这样的项目，比如 InfinityVault，它提供文件转视频、视频转文件和从 YouTube 下载视频的功能，探索把 YouTube 当作文件存储空间。

文件变成视频之后，B 站、YouTube 岂不就成了我们的“网盘”？😝

我沿着这个思路，做了现在这个项目：xxx-file-trans。

它的原理其实不难理解。文件本来就是一串 0 和 1 ，把黑色方块当作 1 ，白色方块当作 0 ，就能把数据画出来。一张画面装不下，就拆成很多张，按顺序播放。

于是，一份文件就变成了不停变化的黑白方块，看起来就像小时候黑白电视机雪花块，程序读到的却是文件分片。

完整过程是这样：

文件 → 压缩、分片 → 黑白方块画面 → 播放或制成视频

                                             ↓

还原文件 ← 拼接、解压 ← 校验、识别 ← 抓屏或读取视频

目前可以用两种玩法。

一种是直接通过屏幕传。发送端只有一个 sender.html，用浏览器打开，选好文件，就可以在窗口里循环播放。接收端框选这块画面，持续抓屏、识别，收齐之后自动还原文件。

发送端不需要安装 Python ，也不需要启动服务器。对于“页面能复制进去，文件不好复制出来”的场景，这种形式比较方便。

另一种是先把文件做成 MP4 。制作端选好文件，生成一段黑白方块视频或者自己录制一段发送端播放的视频；接收方拿到视频后，用接收端逐帧读取，再还原成原始的文件。

如果把这段 视频上传到 B 站或者 YouTube ，视频平台就成了中间的载体。接收方可以尝试从播放器画面接收，或者取得视频文件后离线解码。项目里已经放了两段可以看看这种“文件视频”到底长什么样。B 站测试视频

• https://www.bilibili.com/video/BV1Euan6zEL8


• https://www.bilibili.com/video/BV1Euan6zEL8

不过，把字节画出来只是第一步。真正麻烦的是：画面可能被缩放，抓屏可能漏帧，视频平台还会重新压缩。

对普通视频来说，边缘模糊一点通常不影响观看；对文件来说，一个方块读错，就可能把数据弄坏。所以这个项目也做了一些处理：

• 每帧带编号和 CRC32 校验，读错的帧丢弃，收到的分片按编号归位。


• 加入前向纠错，在条件满足时恢复少量缺失的数据帧。


• 浏览器循环播放，MP4 重复完整帧序列，给接收端更多补齐机会。


• 保存已接收的进度，中断后可以继续接收同一文件，发送参数需要保持一致。

接收端不必向发送端逐帧回复“收到了”。它记住已经收到的部分，遇到重复帧跳过，遇到缺失帧再补进来。最后检查 gzip 完整性，并显示还原文件的 SHA-256 ，方便与原文件核对。

速度方面，仓库里有一轮 2026 年 10 月 1 日的真实桌面闭环测试：浏览器以 30 FPS 播放，接收端使用 DXGI 抓屏，画面清晰且无遮挡。

这轮测试的六个样本都通过了 SHA-256 和逐字节比对。文本通常能压缩得更小，所以即使原始文件更大，也可能传得更快。具体条件和完整结果见实测报告。

这里的耗时是本机桌面测试，每个样本正式测了一次，不包含视频上传、平台转码和下载时间，也不能直接当作远程桌面或视频平台上的速度，大家可以自己测试下。

目前比较适合的是日志、配置、报表和小型资料包情景。另外，黑白编码本身不等于加密，当前项目没有内置文件加密（也许是以后的扩展方向）。

Windows 用户可以从 Release 下载制作端和接收端 EXE ，无需配置 Python ；制作 MP4 仍需要安装 FFmpeg 。浏览器发送端则直接打开 HTML 就能用。

做完这个项目后，我觉得最大的收获是 AI 能快速的把我们的想法做出来并落地，打磨细节真的很费时间! 项目可能还会很多不完善的地方，但还是觉得先发出来，欢迎交流。

项目地址：wubh2012/xxx-file-trans