摘要

  • RFC 1314 为类传真黑白图像指定 TIFF-B 交换配置：多页文件、每页一条 TIFF strip、尽可能采用 MMR，并允许明确限定的其他压缩方式。
  • 文档明确把图像文件格式与文件如何通信分开。FTP 或 SMTP 可以承载同一文件，但不是文件字节本身的属性。
  • 扫描、创建、保存、处理、通信、显示、打印和传真输出是不同操作。格式合规不证明这些后续操作已发生。

纸张离开实时会话

传统传真把一连串动作压缩成一个日常动词：纸张进入机器，图像被编码，两端机器进行实时协商，另一端再输出纸张。人们说“传真发出去了”，常会把输入、传输、解码和输出都当成一个事实。

RFC 1314 给出另一种排列。图像可以从纸张扫描进文件，也可以由软件生成；文件随后可以被保存、处理或通信，之后才可能显示或打印。RFC 列出扫描仪、软件和传真机三种来源，也列出共享、复制、显示、打印和传真等可能行为。这不是同义词，也不是必经步骤，而是一组可分离的边界。

因此，传真机可被视为纸张与文件之间的输入/输出设备，而不是网络本身。一个文件可以在存储中等待，可以经不同载体传播，也可以在完全不同的设备上输出。随之而来的并非更弱的证据，而是更准确的证据：存在文件不等于已经传输；传输不等于已经解码；显示也不等于有人看见或理解。

TIFF-B 所约定的范围

RFC 没有从零发明图像语言，而是采用 TIFF 作为框架，规定交换用的 TIFF-B：支持多页，每页一条 strip。文档建议在可能时使用 MMR；MH、MR 和不压缩也被允许，若使用 MH 或 MR，扫描线应按字节对齐。为获得较高互操作性，文档建议 600、400 或 300 dpi，或给出的 Group 3 分辨率。

这些条件定义的是接口上的共同文件形态。它们能够说明一个文件的页面组织或编码选择，却不能生成成功回执。TIFF-B 不标识原始扫描仪，不证明某人控制发送端，不告诉我们采用了何种传输服务，也不能确认接收端支持该压缩、每一页被正确转换，或纸张真的从某台设备出来。

RFC 对本地存储同样谨慎。主机不必以指定交换格式保存自己的图像；它可以在本地表示与交换表示之间转换。如果接收方无法处理某种压缩，可能需要转换。谁应转换、采用何种算法，RFC 并未指定。那不是可以用想象补齐的空白：格式规范定义了交界处提供什么，而不是每个参与者内部任务的完成史。

载体在文件之外

RFC 直说，图像文件格式与文件如何通信是两回事。FTP 和 SMTP 都只是可能的方式。同一个 TIFF-B 可以经不同机制移动，文件结构不变，而承载者的日志、保证和失败模式不同。

文档提到当时 SMTP 对二进制材料和文件大小的困难。这是 1992 年的讨论背景，不是后来所有邮件附件的结论。更不能因为 RFC 列出 FTP 或 SMTP，就认定某份文件实际走过其中之一。那需要相应的传输记录，必要时还需要完整性和接收方记录。文件类型不能取代这些证据。

存储也如此。本地主机留存的图像、对外交换的图像和在网络中传送的字节可以相关，却未必相同。把三者混为一谈，就会把“可能互操作”的能力误写成“已经保管、送达、完成”的历史。

拆开“传真”这个词

RFC 1314 把传统传真捆在一起的四件事拆开：数据呈现与压缩、数据传输、纸张图像输入、纸张图像输出。软件生成的页面可以先存档再通信；扫描图像可以复制到多个位置；文件可以显示而非打印。文件形式正确，并不强迫任何一条路径发生。

文档还指出，传真板卡或调制解调器可能与接收传真机协商；若对方不能处理该压缩，可能要先转换。协商、转换和物理输出都是后续事件，有各自的条件。不能反过来把它们塞进文件，仿佛一组稳定字节已经见证了全部过程。

可靠的记录链应分开保存：文件创建、选择交换、尝试传输、字节被接受或拒绝、图像解码、图像渲染、设备任务、后续响应。有些记录可能缺失。缺失并不授予邻近记录更大的证明力。

来源与证据边界

本文依据 RFC 1314《A File Format for the Exchange of Images in the Internet》（1992 年 4 月）。它支持 TIFF-B 配置、压缩和分辨率建议、格式/通信/存储的分离，以及“扫描或创建—保存/处理/通信—显示或打印”的模型。它不证明任何具体传输、发件人、接收人、转换、显示、打印、传真、阅读、当前部署或商业结果。