纯文本仍然是我们拥有的最佳技术之一

原文 ↗ Hacker News 讨论 ↗

纯文本被赞为存储信息最耐久、最可移植的方式之一，但评论者也指出它在实践中其实很混乱：从不兼容的换行符和编码（ASCII vs. Unicode/UTF-8），到数字、日期和语言约定上的歧义。许多人认为，尽管有这些缺点，基于文本的格式仍然远比专有格式或二进制格式更容易检查、保存、解析和进行版本控制，而后者往往会让数据随着时间推移变得不可访问。除此之外，讨论还涉及围绕纯文本构建的工具和格式（用于会计、脚本和写作）、关于 Unicode 复杂性和表情符号的争论，以及人们对 AI 生成写作和不可靠检测工具日益加剧的疲劳感。

对 AI 生成内容的担忧

  • 多位评论者怀疑这篇文章，甚至整个博客，都是由 LLM 辅助或由 LLM 撰写的。
  • 他们引用的证据包括：发帖频率很高、文章长度/结构相似、主题聚焦狭窄、作者照片看起来像 AI 生成，以及一个 GitHub 仓库里有很多带有“co-authored by Claude”的提交。
  • 也有人反驳：这篇文章读起来像人写的，包含一些小错误，而且没有明显的 LLM“特征”。几位评论者指出，AI 检测器（例如 Pangram）误报率很高，尤其对 ESL 写作者和文笔好的文章更是如此。
  • 有人表示已经对 AI 垃圾内容感到疲惫；也有人警告说，“这是 AI 写的”正在变成一种懒惰的否定方式，用来回避对内容本身的讨论。
  • 还有人提到（记忆中的说法不太明确）HN 可能正在使用 AI 工具来惩罚 LLM 内容。

纯文本的优势与隐藏复杂性

  • 大家普遍认同纯文本是耐久、可移植的，而且很可能在几十年后仍然可读，这主要得益于 ASCII 和（越来越多地）UTF‑8。
  • 不少人指出，“纯”这个词承担了太多工作：换行符有不同变体（CR、LF、CRLF，甚至历史上的其他变种），编码各不相同，而日期/数字格式或语言等元数据并不是文本本身固有的。
  • 有人认为这种歧义是可以接受的，甚至是一种特性；也有人希望能有标准化的元数据（字符集、换行方式），并遗憾文件系统的扩展属性并没有被用来解决这些问题。
  • 讨论还涉及历史上的设备和操作系统围绕 CR/LF 形成的惯例，以及工具如何适应这些惯例。

Unicode、ASCII 与文本语义

  • 讨论的焦点在于，ASCII 是否才是唯一真正“纯”的字符集，还是 Unicode 才是当代真正的标准。
  • 解释了编码相关概念：Unicode 作为抽象码点，UTF‑8、UTF‑16、UTF‑32 的区别，以及跨越多个码点的字形簇（grapheme clusters）。
  • 有人把 Unicode 形容为“一团乱麻”，尤其是在表情符号、CJK 统一，以及那些无法捕捉全部文化细微差别的排序规则方面（例如德语变音符号与法语分音符）。
  • 也有人认为，要支持全人类书写系统，复杂性本来就不可避免；表情符号则被视为对糟糕文本假设的压力测试，并推动了 Unicode 的普及。

纯文本生态：工具、格式与解析

  • 举例提到了一些以纯文本为中心的工具：会计系统（ledger、hledger、beancount）、剧本格式（Fountain），以及使用文本场景描述的引擎。
  • 一种新格式 Brashtag 被介绍为比 Markdown 更简单、更可编程的替代方案，更接近“人类可写的树形数据”而不是 JSON。
  • 有些人觉得 Brashtag 与现有格式功能重叠；其创建者则强调可组合性和易于构建工具，而不是内建渲染。
  • 讨论中还提到：有哪些好工具可以把文本加语法转换成解析器；有人推荐了若干 Python 和面向语言的解析库。
  • 大家也承认，文本需要付出解析成本，但与不透明的二进制块相比，它更容易检查和逆向工程。

取舍：文本 vs 富格式/二进制，以及未来的持久性

  • 纯文本被赞为几乎通用，但也有人认为，如今二进制格式没那么可怕了，因为 AI 代理可以推断结构、解压归档并编写自定义工具。
  • 在科学归档中，文本对表格很合适，但对于大型二维图像数据则显得笨重；而一个优雅的长期解决方案仍在寻求中。
  • 有人认为，由于没有单一实体真正“拥有”文本，它因此更具韧性，尽管 ASCII/Unicode 仍由标准组织控制。
  • 还提到一个更广泛的媒体趋势：尽管文本更紧凑、消费速度更快，许多用户和出版者还是更偏好视频而不是文本。