为何cat的终端输出与od -tx1的文件字节转储结果存在差异？

两类输出的视觉差异完全不代表cat修改了文件字节，差异本质来自终端模拟器对特殊控制字符的实时处理逻辑，和cat的工作原理没有关系。

为什么cat输出里看到的l（对应0x6C）没有出现在od转储中 #

你在终端上肉眼看到的屏幕内容，从来不是cat逐字输出的所有字节的线性拼接结果：

• 终端是带状态的交互渲染器，收到回车、退格、光标移动、清屏等控制字节时，会直接修改已经渲染在屏幕上的内容，不会把控制字节本身显示出来。
• 你看到的那个单独的l字符，本质是文件中多组带控制序列的字节经过覆盖、重叠、擦除操作后，最终残留在屏幕上的视觉效果，根本不是文件中孤立存在的0x6C字节本身。这种情况下od自然不会在对应的位置找到单独的0x6C值。

举个最常见的例子：如果文件字节序列是0x41 0x08 0x6C（也就是先输出大写A，再发退格把光标移回A的位置，再输出l把A覆盖掉），你在屏幕上最终只会看到一个单独的l，但od转储能完整看到三个字节，根本不是只有一个0x6C。

为什么od转储出的4d 52 4d 6f（对应字符串MRMo）没有出现在cat的终端输出里 #

这类情况几乎都是控制字符的覆盖效果导致的：

• 当od转储出的MRMo字节序列前面，跟着回车（0x0D）、退格等能移动光标的控制字符时，终端会先把光标移到对应位置输出MRMo，后续收到的其他可见字符会直接把MRMo所在的屏幕区域完全覆盖。
• 如果MRMo序列前面带着清屏、光标归位的控制转义序列，后续只要跟上足够长的可见乱码字符串，MRMo作为最先渲染的内容会被后续字符完全遮挡，你肉眼根本扫不到这几个字的残留，自然会觉得od的结果和cat输出对不上。

你对cat的误解主要集中在它的功能定位上：

• cat从来不会对文件字节做任何修改、转义或者渲染，它的唯一作用就是把源文件的字节流无透传式原样发送到标准输出，不会篡改任何一个字节的值。
• 想要验证这一点非常简单：你可以把cat的输出直接重定向到新文件，完全绕开终端的渲染逻辑：

cat 原文件 > cat_out_test
od -tx1 cat_out_test

对比这个od结果和直接od原文件的结果，二者会完全一致，就能证明cat本身根本没有改动字节流，所有的视觉差异全是终端的实时渲染造成的。

除了控制字符覆盖之外，还有几个终端机制会进一步放大视觉差异：

• 软件流控：终端默认开启IXON流控时，收到0x13（XOFF）字节会直接暂停输出，收到0x11（XON）才会恢复，中间的字节不会被渲染到屏幕上。
• 终端特殊模式：如果文件字节触发了终端的备用屏幕、高亮、隐藏字符等模式，部分内容甚至根本不会显示在当前可见的屏幕缓冲区里。

内容的提问来源于stack exchange，提问作者coder937