系统与基础设施dkriesel.com
Xerox 扫描仪和复印机会随机篡改扫描文档中的数字
Xerox scanners and photocopiers randomly alter numbers in scanned documents
2013 — 2021，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇博客披露 Xerox WorkCentre 扫描仪/复印机在扫描文档时会随机改掉数字：扫描图像乍看正常，但其中的数值可能已经错误。作者强调这不是 OCR 问题，而是像素数据被以不易察觉的方式替换；评论进一步指出这与 JBIG2 有损符号压缩有关。该问题引发了对扫描件能否作为凭证、归档和证据使用的广泛担忧。
为什么经久不衰：它打破了“扫描/复印就是忠实复制”的直觉，揭示了有损压缩可能悄悄篡改关键数字，对数字化归档和证据信任仍有持久警示。
HN 评论精选
JBIG2 符号压缩可能造成文字替换，扫描仪不应使用，Xerox 属于配置错误。
这类错误我称为“contoot”：很久以前我为 Google Books 的 PDF 写 JBIG2 压缩器时，第一个例子是一本书的目录页。标题“Contents”用了很粗的字体，恰好成为分类器的意外边缘情况，它把“o”和“e”“n”匹配，输出成了“Contoots”。调整分类器后这类错误基本消失。Xerox 这里显然是配置错了。Google Books 还保留高分辨率原图，PDF 下载并非记录副本，可以调整分类并重新生成；但对扫描仪来说，我认为根本不应使用符号压缩，单页 JBIG2 通用区域编码通常和符号压缩一样好。
agl查看英文原文
This class of error is called (by me, at least) a "contoot" because, long ago, when I was writing the JBIG2 compressor for Google Books PDFs, the first example was on the contents page of book. The title, "Contents", was set in very heavy type which happened to be an unexpected edge case in the classifier and it matched the "o" with the "e" and "n" and output "Contoots". The classifier was adjusted and these errors mostly went away. It certainly seems that Xerox have configured things incorrectly here. Also, with Google Books, we held the hi-res original images. It's not like the PDF downloads were copies of record. We could also tweak the classification and regenerate all the PDFs from the originals. For a scanner, I don't think that symbol compression should be used at all for this reason. For a single page, JBIG2 generic region encoding is generally just as good as symbol compression. More than you want to know about this topic can be found here: https://www.imperialviolet.org/binary/google-books-pdf.pdf
JBIG2 的概率匹配本质上可能出错，用于复印和归档危险，且原件销毁后无法校验。
这是可预料的。JBIG2 对文档处理、归档等场景根本不安全：图像被切成小块，概率匹配器找出相似区域，相似区域只存一次。但相似不等于相等；只要概率小于 1，就存在概率大于 0 的相反事件。哪个蠢货想到把这种算法用在复印机里？JBIG2 只能用在出错不会导致世界末日的地方，而复印机本应忠实复制。若用于数字归档，税务审计时很多公司会有大麻烦。用这种有损压缩的数字档案不仅无用而且危险；纸质原件通常在冗余存储后被粉碎，届时无法判断归档数据是否正确，未来的诉讼会很有得看。
linohh查看英文原文
This was predictable. JBIG2 is in no way secure for document processing, archiving or whatsoever. The image is sliced into small areas and a probabilistic matcher finds other areas that are similar. This way similar areas only have to be stored once. Yeah right, you get it, don't you? They are similar, not equal. Whenever there's a probability less than 1, there's a complementary event with a probability larger than 0. I wonder which prize idiot had the idea of using this algorithm in a copier. JBIG2 can only be used where mistakes won't mean the world is going to end. A photocopier is expected to copy. If the machines were used for digital document archiving, some companies will face a lot of trouble when the next tax audit is due. Digital archives using this kind of lossy compression are not only worthless, they are dangerous. As the paper trail is usually shredded after successful redundant storage of the images, there will be no way of determining correctness of archived data. This will make lawsuits a lot of fun in the future.
普通用户担忧无法判断自家扫描设备是否采用同类有损压缩。
> 这不是 OCR 问题（我们特意关闭了 OCR），而是更糟：像素数据的补丁被以非常细微且危险的方式随机替换。扫描图像乍看正确，但数字实际上可能错误。我习惯把发票、对账单、手册等扫描成 PDF，看到这段话非常震惊。虽然我不用 Xerox（我的扫描仪是 Epson Perfection V39），但我从没想过扫描文档可能导致数字被改。如果我的扫描仪用了类似的底层软件或设置，我怎么知道它是否也会受影响？
noisy_boy查看英文原文
> This is not an OCR problem (as we switched off OCR on purpose), it is a lot worse – patches of the pixel data are randomly replaced in a very subtle and dangerous way: The scanned images look correct at first glance, even though numbers may actually be incorrect. I have a habit of scanning invoices/statements/manuals etc to pdf and found the above quite alarming. Though I don't use Xerox (my scanner is Epson Perfection V39), I never considered the possibility that a scan of a document can result in altered numbers. How do I know if my scanner could also be affected in case it uses similar underlying software/setup?
此类扫描失真事件会加剧公众对数字证据和技术处理的不信任。
有意思的是，上周 Rittenhouse 审判中出现了一个例子：法官对技术采取极度怀疑的立场，不信任缩放功能，因为缩放可能加入原图中不存在的信息。这容易招人嘲笑，我也认为那位法官的思路源于无知而非合理偏执；但不难看出，像 Xerox 这个 bug 会如何在非技术人群中播下不信任的种子。“扫描副本可能和原图不同”与“放大版本可能和原图不同”之间，其实没有多少明确界限。
jl6查看英文原文
Interestingly, we have seen in the last week in the Rittenhouse trial an example of a judge taking a hyper-skeptic position on technology - namely, distrusting the zoom feature because it might add in extra information not present in the original image. It’s easy to ridicule this, and I do think that particular judge’s thought process was rooted in ignorance rather than plausible paranoia, but it’s not hard to see how cases like this Xerox bug sow the seeds of distrust in the non-tech populace. There really isn’t a lot of clear daylight between “the scanned copy might be different to the original” and “the zoomed version might be different to the original”.
历次讨论
同类还值得读
TTY 揭秘（2008）
The TTY demystified (2008)
经典文章深入剖析了 Unix/Linux 中 TTY 子系统的工作原理，包括线路规程、终端驱动、信号与控制字符等机制。
系统与基础设施上首页 11 次 · 2009–2025linusakesson.net编辑精选为什么 GNU grep 这么快
Why GNU grep is Fast
FreeBSD 邮件列表上一篇广为流传的帖子，解释 GNU grep 为什么快：核心在于 Boyer-Moore 字符串搜索算法配合精心优化的内部循环和 I/O，让程序在搜索时“…
系统与基础设施上首页 9 次 · 2010–2022lists.freebsd.orgXplain：为普通人讲解 X11
Xplain – Explaining X11 for the rest of us
《Xplain》是作者（HN 用户 Jasper_）写的一系列 X11 长文，用他在浏览器中重建的 X11 绘图模型做交互演示，讲解 X11 的绘图模型与窗口系统设计。
系统与基础设施上首页 6 次 · 2013–2020magcius.github.io编辑精选旋风教程：为 Linux 创建极小 ELF 可执行文件（1999）
A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux (1999)
breadbox 写于 1999 年的经典教程，主题是如何为 Linux 手工构造并裁剪出体积极小的 ELF 可执行文件。
系统与基础设施上首页 6 次 · 2007–2025muppetlabs.comPostgreSQL 内部原理
The internals of PostgreSQL
《The Internals of PostgreSQL》是一本免费在线书籍，系统讲解 PostgreSQL 的内部实现，包括查询处理、并发控制、WAL、缓冲区管理等核心机制。
系统与基础设施上首页 5 次 · 2017–2025interdb.jp编辑精选