Decimen 以近 190 KB/s 的速度传输 QR 码，无需网络

Tom Hardware 介绍了一项浏览器实验，据称可通过快速变化的 QR 码，以接近 190 KB/s 的速度在手机之间传输文件。传输无需共享网络、Bluetooth 配对、专用应用或账户。一台设备显示数据，另一台则通过相机捕获数据。

这种组合正是其真正的张力所在。传统的手机传输速度要高得多，但依赖无线电连接、操作系统服务、附近设备权限或云端基础设施。Decimen Optical Transfer 则用用户可见的光学通道取代了这些依赖。

该项目仍处于概念验证阶段，并非 AirDrop 的直接替代品。其公布的性能数据也来自有利条件下的开发者测试。不过，这项实验表明，当常规连接不可用、受限或不受欢迎时，屏幕和相机能够构成一条实用的本地数据通路。

Tom Hardware 将光学传输主张置于背景中审视

关键不在于 QR 码能够容纳文件，而在于浏览器能够连续传输足够多的 QR 码，从而建立一条可用的单向连接。

开发者 bashalarmistalt 将 Decimen Optical Transfer 作为开源演示项目发布。根据项目说明，一个浏览器会显示源源不断的编码帧序列；另一个浏览器则通过相机读取这些帧，并重建原始文件。

原始报道发布于 2026 年 7 月 31 日。报道指出，在手持状态下的手机对手机传输速度约为 128 KB/s。将两台设备稳固固定后，速度据称可提升至约 186 KB/s。

这些数字是开发者测得的数据，并非独立实验室基准测试。设备位置很重要，因为移动会导致自动对焦不断调整，并使单帧画面变得模糊。项目文档称，手部抖动是影响吞吐量的最大问题。

开发者表示，这一想法源于开发一款带缓存的网页音乐播放器。当时他们希望在未连接同一网络的手机之间传输音频文件。快速闪烁的 QR 码提供了一条不依赖任一手机发现对方的通道。

这条路径传输的不只是下载链接。所选文件的二进制内容会被分割、编码、显示、捕获，并在接收设备上重建。有效载荷本身通过屏幕与相机之间的可见光传递。

已发布的概念验证采用了比母实验更保守的配置。它可传输一张 512 KB 图像，或一张可选的 2 MB 图像。仓库描述称，在一次演示中传输速度达到 129 KB/s。

更高的速度上限来自更密集的 QR 帧、堆叠码以及具备纠错能力的彩色通道。开发者在这些测试中使用了 120 Hz ProMotion 显示屏。公布的性能为手持时约 128 KB/s，设备静止时约 186 KB/s。

这一区别很重要。标题中的数字描述的是更广泛实验中取得的最佳结果，而公开的概念验证则优先考虑更易扫描的体验。读者不应假设每一种手机和浏览器组合都能立即复现 186 KB/s。

不过，即便是较低的速度，也改变了这种方案应被如何归类。单个静态 QR 码通常只是用于打开网站或导入小型凭据的快捷方式。Decimen 将 QR 码变成了连续传输介质。

以 129 KB/s 传输一张 2 MB 图像，所需时间大致符合一次短距离本地交接的预期，而非归档上传。大型视频依然不够方便。文档、音频片段、配置包、凭据和应急文件则更适合这一通道。

该项目还刻意采用单向设计。接收端不会发送确认、协商连接，也不会向发送端暴露自身身份。这简化了设置流程，但也引出了定义整个系统的技术问题。

如果接收相机漏掉一个传统的带编号数据块，发送端不会知道需要重复发送。Decimen 通过喷泉码解决这一问题，而不是采用网络式重传协议。

喷泉码将漏帧变为延迟，而非失败

Decimen 之所以可行，是因为接收端不需要获得每一帧 QR 码，甚至不需要遵循原始传输顺序。

发送端首先将文件划分为源数据块，然后持续生成编码数据块，每个数据块都组合了源数据中一个伪随机子集。接收端收集到足够多的不同组合后，便可恢复文件。

这一技术被称为喷泉码。其名称反映了接收端的行为：它可以像收集水滴一样收集编码数据，直到足以重建源文件。它不需要某一特定数据块在某一特定时刻到达。

Decimen 使用 Luby transform coding，这是一种早期实用的喷泉码设计。每一帧对应的子集由其序列号通过鲁棒孤波分布导出。据称，接收端需要约为原始数据块数量 1.15 倍的编码块才能完成恢复。

因此，漏掉一帧 QR 码带来的是时间成本，而非正确性问题。接收端可以忽略模糊、重复或无法读取的图像，继续收集后续帧。这一特性使系统很适合没有回传路径的光学通道。

项目仓库说明，每一帧都携带一个 20 字节的头部。该头部标识会话、序列号、数据块数量、数据块大小、文件长度和文件哈希值。

自描述帧使接收端可以在传输开始后加入正在进行的流。重启发送端会创建新的会话标识符，接收端据此自动重置。无需进行配对交换。

哈希值为接收端提供了验证重建文件的方式。它并不能保证发送端可信，但可以检测重建结果是否与传输的有效载荷不同。

这一机制不同于简单地循环显示带编号的数据块。对于顺序播放，漏掉一帧可能迫使接收端等待整个序列再次循环。文件越大，恢复延迟越长。

喷泉码则会持续产生有用的组合。发送端不需要知道哪些符号已经到达，接收端也不需要请求缺失的符号。这消除了可靠传输协议通常预期的反馈通道。

这一概念早于该项目。2018 年的 TXQR experiment 也将动画 QR 码与喷泉码结合。Digital Bazaar 的 qram 库后来探索了通过易丢失介质传输任意数据的 LT 编码 QR 数据流。

Decimen 的贡献在于围绕当代手机屏幕、相机、浏览器 API 和 WebAssembly 对这一思路进行封装。WebAssembly 通常简称为 WASM，可让浏览器以接近原生速度执行编译代码。

接收端使用了 ZXing-C++ 的 WASM 构建版本，这是一款成熟的条码解码库。相机帧会分配给多个 worker，使多个解码任务能够运行而不阻塞浏览器主界面。

繁忙的 worker 可以直接丢弃多余的相机帧。在普通的顺序通道中，这种行为会威胁传输；而在这里，喷泉码层能够吸收这些损失，并让下一批可读取的符号继续推进重建过程。

该实现还处理了一个不那么显眼的兼容性问题。JavaScript 引擎并不保证每一个数学函数的近似计算都在位级别完全一致。喷泉分布上的微小差异，可能使两个浏览器针对同一序列号选择不同的源数据块。

因此，项目包含基于明确定义的 IEEE 754 运算实现的确定性对数函数。这能让基于 V8 的浏览器与 Safari 的 JavaScriptCore 在生成相同分布时保持一致。

这一细节表明，“仅浏览器”不应被误解为简单的网页技巧。该页面协调了相机捕获、并行解码、确定性编码、会话管理和哈希验证。它实际上是在可见图像之上构建了一套传输栈。

这一结果也解释了为何仅提升 QR 码生成速度并不能保证更快的文件传输。发送端必须将每帧显示足够久，以便相机捕获清晰图像。接收端还需要足够的处理能力，在 worker 队列填满前完成解码。

屏幕刷新率、相机曝光、自动对焦、浏览器调度和解码速度都会影响最终速率。喷泉码无法消除这些约束，但能避免它们不可避免造成的丢失中断传输。

真正的对手是连接建立，而非 AirDrop 速度

光学传输在原始带宽上远远落后，但它避开了基于无线电的替代方案所需的发现和信任步骤。

AirDrop、Quick Share、Bluetooth、Wi-Fi Direct、WebRTC、即时通信应用和云盘都可以更快地传输文件。但如果核心问题是两台设备无法建立常规通路，它们就不是合适的性能基准。

Apple 和 Google 多年来一直在减少附近共享的可见操作摩擦。但其系统仍依赖操作系统支持、兼容设备、无线电连接、发现服务以及用户批准的访问权限。

网络服务可以使用 WebRTC 实现浏览器之间的直接通信，但对等方通常需要先完成信令才能连接。网络策略、不兼容的路由或严格的防火墙都会使这一过程复杂化。

Decimen 完全避开了发现过程。发送端在公开可见的位置显示信息，光学范围内的任何兼容接收端都可以收集数据。两台设备都不需要知道对方的地址或身份。

这一模式适合受损或孤立的设备。即使蜂窝网络、Wi-Fi、Bluetooth 或线缆连接不可用，一部手机的显示屏和浏览器可能仍能正常工作。如果相机也可用，它同样能够接收光学数据流。

气隙系统是另一个潜在应用场景。气隙会将设备与普通通信网络隔离，以降低暴露风险。管理员仍需要受控的方法，将更新、日志、密钥或其他文件跨越这一边界。

QR 数据流已被用于部分离线签名和安全工作流，因为这一通道是可观察的。用户可以看到数据何时跨越边界，尽管视觉上的感知并不能说明有效载荷本身是否安全。

浏览器方案降低了部署摩擦，因为它不需要专门安装。用户只需向接收页面授予相机访问权限，发送端则只需要一块显示屏。

这一说法需要一个限定条件：浏览器页面必须最初已能在设备上访问。Decimen 可被缓存以供日后使用，但首次访问通常仍需要服务器、本地开发主机或其他安装途径。

相机访问还需要安全的浏览器上下文。该项目在开发期间使用 HTTPS，因为浏览器通常会在不安全的远程源上阻止 getUserMedia 这一相机访问接口。

Safari 带来了额外的实现挑战，因为它尚未推出部分浏览器二维码工具所使用的 BarcodeDetector 接口。相关的 WebKit issue 仍是该项目兼容性说明的一部分。

Decimen 通过 WASM 引入自带的 ZXing 解码器来弥补这一缺口。这种设计提升了跨浏览器的可控性，但也增加了原生平台服务本可避免的代码量与处理负担。

从狭义的技术层面看，该系统具备隐私优势。开发者称，文件内容始终留在两个浏览器内，不会经过上传服务器。发送方也无法获知是谁接收了数据流。

不过，光学传输并不会天然具备隐私性。任何配备合适摄像头且能清楚看到屏幕的人，都可以尝试接收相同的数据。当前通道更像是可见的广播，而不是保密的点对点连接。

敏感传输需要在编码前进行加密。公开文档聚焦于可靠传输和文件校验，而非完整的身份、授权或密钥管理系统。

发送方也无法确认目标接收者是否完成了传输。系统没有确认回执通道。用户只能依靠视觉协调，或通过其他方式确认传输完成。

这些限制并不影响项目的核心承诺。它并非要取代所有网络栈，而是在建立连接本身成为更大障碍时提供一种备用方案。

这一差异也让 Tom Hardware 的结果更容易理解。与 Wi-Fi 相比，接近 190 KB/s 并不起眼；但对于一个由浏览器原语构建、权限要求较低的光学连接来说，这一速度仍令人意外。这项实验以带宽充裕度换取了对网络基础设施的独立性。

186 KB/s 的结果并不能证明什么

峰值速率是一项有前景的工程测量结果，并不能证明它能在普通手机和日常环境中稳定可靠地运行。

开发者指出，物理稳定性是关键变量。报告称，固定接收设备时速度可接近 186 KB/s，而手持操作时则维持在约 128 KB/s。仅这一差距就表明，移动对该通道的影响非常显著。

当用户双手移动时，自动对焦可能发生变化。滚动快门可能捕捉到一部分显示帧和另一帧的另一部分。反光、低亮度、观看角度、屏幕缩放和环境光都会降低对比度。

摄像头与显示器的帧率也会带来额外复杂性。接收端可能请求 60 FPS，却只能获得 30 FPS。项目指出，当应用提出理想请求时，iOS 可能会悄然提供更低的帧率。

其解决方案是在支持时请求精确帧率，然后检查摄像头轨道设置。即便如此，这种方法也无法让不受支持的硬件提供更多帧。

该概念验证默认以每秒 24 帧的速度传输。这使得每张二维码图像在典型显示器上至少经历两次刷新周期，从而提高被摄像头清晰捕获的概率。

每个默认帧使用版本 27 的二维码承载 1,465 字节有效载荷。根据代码仓库，在近距离手机测试中，密度更高的版本 40 帧可承载 2,953 字节。

更密集的编码在实际中并不一定更快。更小的视觉模块更难被摄像头解析，尤其是在移动或对焦不理想时。即使一帧能承载两倍数据，只要解码器将其拒绝，其价值也很有限。

发送方可以调整帧率、每帧字节数、纠错级别和显示尺寸。接收方则可调整采集宽度、摄像头帧率和解码工作线程数量。这些控制项表明，该项目尚未将性能选择收敛为通用的自动配置方案。

在文档所述的配置中，二维码纠错采用最低标准级别 L。该选择为每张图像中的数据留出了更多空间。

喷泉码和二维码纠错处理的是不同类型的失败模式。二维码纠错尝试修复已捕获符号内部的损坏；喷泉层则处理那些从未被成功解码的符号。

Decimen 倾向于丢弃坏帧，并生成更多喷泉符号。当干净帧频繁到达时，这一选择是合理的；但在光线较差的条件下，可能需要不同的平衡。

报告中的速率也没有包含更广泛的工作流成本。用户仍需准备好两个页面、授予合适权限、确保良好对齐，并留出足够内存来保存重建后的文件。对于小型传输而言，这些步骤可能主导整体体验。

大文件则带来另一类问题。以 186 KB/s 传输数百兆字节的数据仍需较长时间。持续使用摄像头、最大屏幕亮度以及不断解码都会消耗电量并产生热量。

浏览器可能会暂停后台任务，或在压力下回收内存。移动操作系统也可能随设备和版本改变摄像头行为。生产级工具需要进行广泛的兼容性测试。

安全性同样需要谨慎看待。正确的哈希值只能确认接收到的字节与发送的字节一致，不能证明这些数据由谁创建，也不能证明其不含恶意内容。

提供自动下载的页面必须将文件名、MIME 元数据、文件大小和重建缓冲区视为不可信输入。项目开源有助于审查，但不能替代正式的安全评估。

该代码仓库目前将其代码定位为最小化概念验证。其开发历史较短、测试人群有限，因此现在就作出广泛可靠性宣称还为时过早。标题中的结果尚未在公开的设备矩阵中得到独立复现。

该项目也没有针对旁观窃取的内在防护。除非有效载荷事先经过加密，否则附近观察者可以录制屏幕，并在之后解码该数据流。

对于隔离网络环境而言，这种风险具有双向性。可见的光学通道可能比不可见的无线电连接更容易监管，但它同样可能泄露给任何处于视线范围内的摄像头。

由于发送方不对接收者进行身份验证，缺乏配对降低了使用摩擦。但这一特性也消除了传输层的访问控制。

这些问题都不会否定这项实验。它们界定了其实际成就。Decimen 表明，在特定条件下，基于浏览器的光学传输可以达到有用的速度，但产品可靠性、自动调优和安全会话设计仍未解决。

早期二维码项目展现了机会，也揭示了上限

Decimen 属于更长久的光学传输实验谱系，但更好的手机硬件正在让这个旧思路变得更实用。

动态二维码传输曾出现在研究项目、开源库、加密货币钱包和隔离环境签名工具中。这些系统共享一个基本观察：一系列机器可读图像能够承载的数据远多于单个静态符号。

早期项目通常使用顺序分块。这种方式易于实现，但漏掉一个符号就可能延迟完成，直到序列再次循环。喷泉码使通道更能容忍丢失和乱序接收。

TXQR 在 2018 年将动态二维码和喷泉编码结合到 Go 中。Digital Bazaar 的 qram 库则使用 LT 码，将任意数据打包为循环播放的二维码数据包。两者都奠定了 Decimen 背后的大部分概念基础。

其他实现则完全放弃标准二维码。Libcimbar 使用专为更高光学密度设计的自定义彩色视觉编码。专用格式可以在相同屏幕面积中容纳更多信息，但会失去围绕标准二维码形成的成熟识别软件生态。

这种取舍在手机上尤为重要。二维码解码受益于数十年来在检测、透视校正、受损符号和不同光照条件方面的积累。自定义颜色系统在处理白平衡和摄像头色彩处理的同时，也必须解决这些问题。

RaptorQR 代表了另一种当前路径。其开发者称，使用 iPhone 16 和 Safari 时，6.5 MB 的传输耗时 36 秒，即 183.6 KB/s。它结合了 RaptorQ 编码、WASM 渲染和 ZXing 扫描。

RaptorQ 是 RFC 6330 中描述的标准化喷泉码。其设计目标是在低开销下高效恢复丢失的数据包。Decimen 则记录了一种采用鲁棒孤波分布的 LT 码实现。

不应将这些项目视作受控的正面对比基准。它们使用了不同的有效载荷、编码布局、设备、帧率和测试条件。不过，彼此相近的速率仍表明，基于手机的光学传输已进入实用性能区间。

社区实验也显示出它与常规网络之间仍存在距离。开发者在进行浏览器二维码传输时，曾描述速度达到每秒数 MB 的 Wi-Fi 和 WebRTC 路径。光学传输通常仍停留在每秒数百 KB 的水平。

这种比较进一步明确了真正的对手。这并非一场与本地无线共享比拼带宽的竞赛，而是一场针对连接失败、无线电不可用、平台不兼容以及禁止常规网络连接的政策的竞赛。

基于标准的二维码也为 Decimen 带来了部署优势。该项目可以依赖熟悉的视觉标记和成熟的解码库，用户无需特殊摄像头硬件。

现代手机改善了整个流程中的几乎每一个环节。高刷新率显示器可以呈现更多符号，更好的摄像头可解析更密集的编码，更快的移动处理器能够并行解码更多帧。浏览器的 WASM 支持则将优化过的原生库带入网页。

这些改进解释了为什么一个旧概念能够产生新的结果。底层信息论并未改变，消费级硬件已经达到能够交互式运行完整光学传输流程的程度。

AI 辅助开发同样影响了实现过程。开发者表示，Claude Code 帮助构建了可运行的概念验证。这一点很有意思，但相较于代码仓库中可验证的设计选择，它仍是次要因素。

AI 并未发明喷泉码、二维码识别、WASM 或浏览器摄像头采集。它帮助一名开发者围绕一个特定的个人问题，快速组合这些组件。

这种模式正在实验性软件中变得普遍。开发者可以在传统产品团队认为这项工作值得投入之前，就将标准、库和设备 API 组装成针对性原型。

由此产生的代码仍需要人工审查、硬件测试、威胁分析和维护。Decimen 的价值来自它呈现出的系统，而不是把 AI 生成的代码当作天然可靠。

因此，Tom Hardware 的读者应将该项目视为一条正在成熟的技术路径的证据，而非一次孤立的噱头。多个团队正汇聚到采用喷泉码的光学传输方案上，因为当前设备终于能够以有用的速率执行它。

三个信号将决定光学传输能否走出实验室

下一项考验在于，Decimen 能否将有利的演示转化为跨手机、浏览器和真实环境中可重复的表现。

第一个信号是独立的兼容性基准测试。该项目需要覆盖近期 iPhone、Android 手机、平板电脑和笔记本电脑的结果，并测试发送和接收两种角色。

一个有用的基准应区分手持和固定操作，并报告实际摄像头设置、显示刷新率、距离、光照、有效载荷大小、失败尝试次数以及持续吞吐量。

如果能在多台设备上复现接近 186 KB/s 的表现，核心性能主张将更有说服力。若速率波动很大或传输频繁失败，则表明光学条件仍主导着软件设计。

第二个信号是自动调优。一个可投入生产的接收端应测量自身的摄像头帧率和解码能力，然后告知发送端哪种密度和播放速度能够稳定运行。

Decimen 目前避免使用回传通道，因此这种协调需要作出设计决策。接收端可以向发送端回显一个小型控制 QR code，或者由用户手动选择检测到的配置档案。

双向视觉模式将加入确认机制、流量控制和能力协商。但这也会让其“简单单向广播”的核心承诺变得更复杂。

该项目无需支持双工传输也依然具有实用价值。不过，自动配置档案可减少失败尝试，并降低性能对专家级设置的依赖。

第三个信号是面向真实文件的安全模型。加密、发送方身份验证、载荷大小限制、安全下载处理以及清晰的会话指示，将使这一概念超越工程演示的范畴。

加密应在喷泉编码之前完成，这样录制到的帧在没有密钥的情况下不会泄露任何可用的文件数据。身份验证则可帮助接收端确认重建出的载荷确实来自预期的发送方。

这些增强必须保留该通道的主要优势。如果安全设置需要账户、云服务或繁琐的配对流程，光学传输就会重新制造它原本旨在避免的依赖。

最有说服力的结果将是提供可选的安全模式。日常传输可以保持即时性，而敏感工作流则可使用预共享密钥或简短的视觉验证码。

开发者还应关注浏览器摄像头的行为。更好地访问帧率控制和原生条码检测能力，将降低实现复杂度。移动端调度或摄像头约束方面的退化，则可能带来相反的影响。

对于普通用户而言，眼下的问题更简单：它何时会胜过现有的分享工具？答案是，当常规工具无法建立连接路径、要求不可接受的访问权限，或依赖不存在的基础设施时。

这包括孤立设备、损坏的无线硬件、跨平台恢复、受监管的空气隔离传输、网络受限的课堂，以及从大型显示屏进行的一对多广播。

这种方法仍不适合大型备份或日常视频分享。对于机密数据也需要格外谨慎，因为摄像头范围内的任何人都能观察未加密的数据流。

Tom Hardware 展示了一个可信的证明：手机屏幕和摄像头能够支持的不只是链接和支付令牌。接近 190 KB/s 的结果如今仍需要更广泛的复现、更易用的调优方式，以及明确的安全层。

不妨从其预期的失效场景来评估这个想法。如果 Wi-Fi、Bluetooth、线缆和云服务都消失了，一个可见的浏览器通道能否帮助你找回一份重要文件？这个答案将决定流式 QR codes 是继续停留在引人入胜的实验阶段，还是成为设备之间的标准应急通路。