翻译-为什么纯文本仍然是我们拥有的最佳技术之一

Unicode 标准基本上将纯文本定义为一串字符编码，不包含与富文本相关的附加格式信息。字体、颜色、布局以及类似的呈现细节属于别处。

从用户的角度来看，重要的部分更简单：文件包含文本本身，而不需要某个特定应用才能理解它。我可以在 Linux 上创建一个文本文件，把它复制到 Windows 机器上，放到 Web 服务器上，在终端中打开它，用命令行工具搜索它，用任意数量的程序编辑它，或者把它发送给使用完全不同系统的人。这个文件几乎没有多少东西取决于它是如何创建的。

这与许多文档格式不同，在那些格式中，信息与理解该格式的应用或应用系列紧密绑定。有时这无伤大雅。有时该格式有完善的文档并得到广泛支持。在其他情况下，打开一个旧文件意味着寄希望于仍然存在合适的软件。

纯文本几乎没有这些包袱。

纯文本并不是某种需要拯救的被遗忘的技术。它仍然是计算基础设施的一部分。

源代码通常是文本。配置文件通常是文本。日志文件通常是文本。Unix 和 Linux 系统中充满了文本文件。Web 背后的许多机制也以某种形式涉及文本。HTML、XML、JSON、CSS、shell 脚本、编程语言、配置格式以及许多其他东西都围绕人类可以检查的字符构建。

当然，这些是结构化格式，而非普通散文。HTML 文档与 .txt 文件中的笔记不是一回事。相似之处在于内容仍然可见。用基本的文本编辑器打开文件，你就能看到里面有什么，即使你并不理解其中的每一部分。

这具有实际价值。当文本配置文件出了问题时，我可以直接检查它、复制它、比较版本、搜索特定设置，或进行备份，而不需要创建它的那个程序。在其正常应用程序之外仍然可理解的数据，要容易排查和保存得多。

纯文本最大的优势之一是，大量工具已经知道如何处理它。

在类 Unix 系统上，文本文件可以交给 grep 、 sed 、 awk 、 sort 、 diff 以及许多其他已经存在了几十年的实用工具。脚本可以处理数千个文件，而无需假装成人类在菜单中点击。

这种优势并不局限于命令行。图形编辑器、编程环境、笔记应用、文件管理器、搜索工具、浏览器以及无数其他程序也能处理文本。真正的优势在于，信息并不与某一个界面紧密耦合。

现代软件往往采取相反的做法。一个应用可能决定你的信息存放在哪里、如何组织、如何同步、如何搜索，以及允许哪些其他软件访问它。这些系统可以提供有用的功能，但它们也让应用对数据变得越来越核心。

纯文本把更多这类选择权留给了用户。

纯文本显而易见的弱点是格式。标题、强调、链接、列表、引用以及其他结构能让文档更易读，而基本的 .txt 文件并没有提供表达其中大多数内容的标准方式。

Markdown 是一种实用的折中方案。它是一种用于结构化文档的纯文本格式，借鉴了电子邮件和 Usenet 中早已为人熟悉的惯例。它于 2004 年推出，如今其各种变体被用于软件文档、网站、笔记、书籍以及许多其他类型的写作。

它真正的优势在于，即使 Markdown 处理器消失了，源文件仍然有用。标题看起来仍然像标题。项目符号列表仍然像列表。链接仍然同时包含其描述和目标地址。格式语法是可见的，而不是埋在二进制结构里。

这是一个很好的例子，说明如何在不放弃纯文本主要优势的情况下增加有用的能力。渲染后的输出可能很方便，但源文件仍然是普通文本。

长久可用或许是纯文本最有力的理由。

计算机历史充满了被遗弃的文件格式和应用程序。有时，恢复一份旧文档意味着要找到过时的软件、找到导入过滤器、运行模拟器，或者经过多种中间格式进行转换。

文本文件并非完全不受兼容性问题影响。较旧的文件可能存在字符编码问题，而行尾符的差异多年来也一直令人头疼。不过，与试图从某种晦涩的专有格式中恢复信息相比，这些问题通常还是可以处理的。

如果我找到一份旧的文本文件，当前计算机上的某个程序很有可能可以打开它。即使格式粗糙或编码需要注意，文字本身通常也是可以恢复的。

现代 Unicode 也让纯文本的能力远超旧时 ASCII 文本的概念-–—那种文本几乎只包含英文字母、数字和标点符号。如今的纯文本可以表示世界各地的书写系统和字符，同时仍保留相同的基本理念：文件包含的是编码字符，而不是专有的呈现格式。

简单并不一定意味着原始。

随着软件越来越转向账户、云存储、同步服务和订阅制，纯文本的优势变得更加明显。

一个文本文件可以直接存在于我电脑上的某个目录中。我可以把它和其他文件一起备份，按自己的方式同步，把它纳入版本控制，复制到另一台机器，或者存储在我自己控制的服务器上。所有这些都不需要制作我编辑器的公司继续经营，或继续支持某项服务。

这并不意味着每个笔记服务或云应用都是坏主意。专用应用提供了纯文本本身难以轻松提供的功能。协作、数据库、嵌入式媒体、复杂格式，以及不同类型信息之间的关系，都有正当的用途。

强行把每一种数据都塞进 .txt 文件并没有什么好处。真正有用的区分在于，额外的复杂性究竟是解决了实际问题，还是只是变成了又一个依赖。

当纯文本已经足够时，它会消除数量惊人的、日后可能成为阻碍的东西。

纯文本并非万能答案。

我不想用一段对像素的文字描述来取代一张照片，也不想把一份财务工作簿变成一堆数字，让我不得不手动重建所有公式。富文档之所以存在，是因为呈现方式和结构有时确实很重要。

应用程序也提供了有用的抽象。数据库可以强制执行一个装满文本文件的目录无法做到的关系约束。文字处理器可以处理手动重现起来十分繁琐的页面布局。专用软件的存在是有充分理由的。

问题不在于使用更丰富的工具。而在于即便任务并不需要，也认定更丰富的工具理所当然更好。在多得令人意外的情形中，最简单且够用的表示方式反而最持久。

纯文本就是这样一种技术：它可靠得几乎让人察觉不到它的存在。没有公司试图用它提升参与度，没有账号要求，没有订阅层级，也没有那种会因商业模式变化而被停掉的服务。

它便于移植、可检查、可搜索、可脚本化、易于备份，而且极其不易过时。这些特性并不令人兴奋，但很实用，尤其是在漫长的时间跨度上。

在数十年间看着软件和文件格式来来去去之后，我对那些做得更少、却存活更久的技术产生了相当的敬意。纯文本并不能解决所有问题，也不应该。它真正提供的，是一种稳定的信息存储方式，而且对周围软件的要求极低。

对于如此基础的东西来说，这已是相当了不起的成就。