3分钟上手libcimbar：断网环境下，用屏幕和摄像头把文件“传过去“

3分钟上手libcimbar：断网环境下，用屏幕和摄像头把文件"传过去"

【免费下载链接】libcimbarOptimized implementation for color-icon-matrix barcodes项目地址: https://gitcode.com/GitHub_Trending/li/libcimbar

深夜十一点，某保密机房的工程师老周盯着两台物理隔离的电脑发愁：U盘被封禁、网络被拔线，一份 8MB 的配置文件却必须在两套系统间流转。打印成二维码？一张最多几 KB，得打几百页纸。就在他准备用最原始的办法——对着屏幕一个字一个字抄——时，同事发来一个项目：libcimbar。

这是一个基于彩色图标矩阵条形码（Color Icon Matrix Barcodes）的视觉传输库。它把文件编码成一组不断跳动的彩色方格动画，发送端放动画，接收端拿手机摄像头一扫，最高能以106KB/s的速度把数据"隔空"传过去。全程不碰网络、蓝牙、NFC，数据只走镜头这一条路。这不是科幻，是已经跑起来的开源项目。

它到底在屏幕上画了什么？打个比方就懂了

先忘掉那些专业术语。把 libcimbar 想象成一本"会翻页的彩色密码书"：每一帧画面就是一页，页面上是密密麻麻的彩色小方格（官方叫 tile，瓦片）。每个格子选什么图案、涂什么颜色，组合起来就代表 6 个比特（4 位图案 + 2 位颜色）。一整页塞下约 7500 字节的有效数据——相当于一页纸装下两页半《新华字典》的压缩包。

解码端则是"翻书人"。它靠画面三个角上的锚点图案定位（就是下图这种回字形方块，类似二维码的"回"字定位符），再做透视校正，然后逐格识别图案和颜色，把二进制流还原出来。

这里有个反直觉的巧思：cimbar 判断某个格子是什么图案，靠的不是像素级比对，而是"图像哈希"——把 8x8 的格子压成一个 64 位数字，再与 16 个标准图案的哈希做距离比对，取最接近的那个。即使画面模糊、轻微形变，哈希距离依然稳定，这就是它在手机镜头下依然能读准的底气。看，就是这些标准图案在来回切换：

不过单页再能装，也装不下整份 8MB 文件，而且镜头难免漏拍几帧。于是 libcimbar 又叠了两层保险：Reed-Solomon 纠错处理单帧内的坏格子；喷泉码（wirehair 实现）处理帧与帧之间的关系——只要收到足够多的"水滴"（帧），哪怕顺序打乱、丢了几帧，整条"河"（文件）都能完整复原。文件最多支持到压缩后 33MB，先 zstd 压缩再编码，文本类文件能再省一大截传输量。

一台电脑 + 一部手机：把第一条"光缆"架起来

上手路径有两条，我推荐先走命令行，因为它把整个链路摊开给你看。源码在src/exe/下，发送端cimbar_send、接收端cimbar_recv一眼就能找到。

第一步，把库编出来。依赖就三个系统包，其余第三方库（zstd、wirehair、libcorrect 等）全部内嵌在src/third_party_lib/里，clone 下来直接编：

git clone https://gitcode.com/GitHub_Trending/li/libcimbar cd libcimbar # Ubuntu/Debian 需先装三个依赖：OpenCV、GLFW、OpenGL ES 头文件 sudo apt install libopencv-dev libglfw3-dev libgles2-mesa-dev cmake . && make -j$(nproc) && make install

产物默认落在./dist/bin/，cimbar_send和cimbar_recv都在这里。

第二步，发送端开播。把文件丢给它，屏幕上会弹出一个满屏彩色格子的窗口，像一堆有节奏跳动的"雪花"——那就是你的数据正在一帧帧地"广播"：

./cimbar_send -i report.pdf

第三步，接收端对准屏幕。手机或另一台电脑插上摄像头，运行解码器，把镜头对准那片跳动的格子，保持 30–50cm 距离、正对不要斜：

./cimbar_recv -i 0 -o ./received_files

看到终端里不断刷新的[23%, 57%, 100%]进度列表了吗？那是每个文件的喷泉码接收进度。等它全部到 100%，received_files目录里就是完好无损的原始文件。是不是比你想象的简单？

三个"别人不知道"的进阶玩法

玩法一：参数黄金组合，肉眼可见地提速。默认 15fps 偏保守，如果你的屏幕和摄像头都够劲，试试这套组合——把-f提到 30、-e降到 16（更少纠错字节意味着更多数据位），-z 0关掉对已压缩媒体的二次压缩：

./cimbar_send -i photo.jpg -m B -f 30 -e 16 -z 0

前提是发送端和接收端的-m模式必须一致（默认 B 模式），否则谁也认不出谁。

玩法二：零安装的 Web 发送端。不想编译？项目把编码器编译成了 wasm，web/目录下就是完整的浏览器实现。用python3 package-cimbar-html.py -i your_file.txt -o send_page.html生成一个单文件 HTML，任何现代浏览器打开即用，连应用都不用装。接收端同样有纯浏览器的recv.html——两台没装任何软件的电脑也能互传，这在机房应急时是救命招。

玩法三：打破 33MB 上限。官方喷泉码把单流文件封顶在 33MB，但社区工具 cimbar-bigfile 通过把大文件切成多个 10–15MB 的并行encode_id流，再配一份 SHA256 校验的manifest.json，轻松支持 100MB+ 文件。大文件传输不再是禁区。

我踩过的坑，你绕着走

• 屏幕亮度调满，但环境光才是主角。官方性能文档里原话是"screen brightness on the sender is good, but ambient light is better"——只靠屏幕发光容易过曝，开盏台灯、用白色背景，帧捕获质量立竿见影。
• 别贪 8 色模式。8 色（8C 模式）理论速度更快，但官方自己都标注"实验性、一直不稳定"，0.6.0 起已移除。老老实实用 B 模式（8x8、4 色），它是可靠性与速度的最佳平衡点。
• 镜头歪一点，ECC 就救不回来。斜着拍会导致画面一部分格子密集变形，错误聚集在局部，30/155 的纠错等级扛不住。宁可把手机放低一点正对屏幕，也别图省事斜着架。
• 提防反光和手抖。灯管反射会让整片格子"失明"，手抖则让锚点定位飘移。支架一夹，问题少一半。

一张表看懂各模式真实速度

换算成体感：1MB 文件约 10–15 秒，10MB 约 1.5–2.5 分钟。作为参考，单帧 barcode 是 1024x1024 像素，每帧在纠错后还能扛住 7500 字节净数据，这个密度在视觉传输里相当能打。

参数速查对照表

想看更深的实现细节？编码器的喷泉码逻辑在src/lib/fountain/，Reed-Solomon 纠错在src/lib/encoder/，摄像头提取链路在src/lib/extractor/，官方文档DETAILS.md和PERFORMANCE.md把每一条性能数据都交代得清清楚楚。

这项目最迷人的地方在于：它把"传输"这件事从网络协议里剥离出来，退回到一束光、一个镜头这样最原始的物理介质。数据可以被隔离，但从未停止流动——这就是 libcimbar 给出的答案。现在，去把你的第一份文件"发"到屏幕对面吧，整个过程不会超过 10 分钟。

【免费下载链接】libcimbarOptimized implementation for color-icon-matrix barcodes项目地址: https://gitcode.com/GitHub_Trending/li/libcimbar