粗体，斜体，下标，上标，下划线，~~删除线~~ —— 我发现这些文本的表现属性与引号和感叹号一样，并非可有可无。我的意思是，如果目标是极简主义，我们可以用字母、空格和换行符来编写用于电子传输的散文，并丢弃所有显式的标记。当它存在超过五十年时，我们不称之为“标记”，而是称之为标点符号，但本质上是同一件事。

书面文字以这种方式呈现出相当强烈的视觉效果

虽然正如我上一篇文章所述，它在细微之处有所欠缺

它也缺乏灵活性

当他们没有逗号、括号和其他分隔符作为支撑时，必须以更加清晰的方式构建他们的陈述

但没有人想生活在那个世界里。我们都认识到逗号、星号、连字符和斜线等小工具箱所带来的表达上的可能性。而且，粗体文本和下划线等表现属性在清晰性和表达性方面的效用也同样受到重视。事实上，现在人们已经理所当然地认为在计算机上撰写文本时可以使用它们——以至于我甚至无法在 Gmail 中撰写纯文本消息了(1)。

但这些属性在计算机上存储方式存在问题。早在 20 世纪 60 年代，当 American Standard Code for Information Interchange (美国信息交换标准代码) 被制定出来，并且决定在代码中微薄的 7 位地址空间中编码什么内容时，没有足够的空间来存储关于每个字符的额外表现信息，因此这些信息必然被排除在外。只有基础内容被纳入：字母、数字、标点符号和一些控制代码。

将表现信息添加到文本中的唯一方法是开始在信息中嵌入关于信息的信息。也就是说，在字节流中，某些字节代表消息，而某些字节代表如何呈现该消息。 ANSI 在 20 世纪 70 年代在硬件层面上使用转义序列实现了这一点，并且几十年来已经出现了无数种使用软件实现此目的的方案。

这种方法的问题在于它用非文本信息污染了文本流。 Ted Nelson 在他的文章 Embedded Markup Considered Harmful 中解释了这方面的更大影响。

我对使用嵌入式标记来实现这些表现属性的进一步反对意见是，通过从字符编码方案中省略它们，它们被否认为语言元素，并且用 Nelson 的术语来说，它们被视为包装而不是内容。

我坚持认为，它们与感叹号一样，都是语言内容。

在 20 世纪 80 年代，当 Joe Becker 提出 Unicode，“宽体 ASCII”，以包含世界上所有的字母、音节和表意文字时，没有为编码表现属性做出规定。事实上，Unicode 88 proposal 明确 不 支持这种“花哨文本”。我根本不同意这种方法。 Unicode 后来偏离了其“与世界书写系统的字符固定的一对一对应关系”的目标，转而支持多字符组合来为字形添加变音符号——这与 ANSI 转义序列的方法完全不同——但它仍然没有用于无处不在的、跨语言的表现惯例（例如粗体文本）的标准化编码。

如果我可以掌控世界，我只需将所有内容都迁移到 32 位编码方案，并保留最高 8 位用于表现属性。较低的 24 位将保留给人们梦想填满该空间的 1670 万个字符。

—L.D29

后记

在写完这篇文章一年后回顾它，它看起来有点……仓促？虽然我认为将“标记”和“标点符号”混为一谈有点过分，特别是在过去约 20 年里，前一个术语积累了相当多的内涵包袱，但我确实认为值得研究正字法（或书写学？）和风格的边界；语言仅仅是我们所做的标记，还是也可以是我们_制作_它们的方式？

—L. E17

注释

1。肯定有人抱怨了，因为这个选项又回来了 ——L. E17 comments powered by Disqus ©2013 - 2014 LÆMEUR. Most rights reserved.