是否有带有字母大小写修饰符的字符编码或标记语言?

Is there a character encoding or a markup language with a lettercase modifier?

不确定这是否适合这里。如果有像“计算机历史和未来”之类的东西,请把我带到那里。

问题

自从计算机兴起以来,是否有任何字符编码(或在此之上的标记语言)区分大写和小写字母,而不是通过两次定义整个字母表(一次大写一次小写)字母),而是通过添加修饰符或关键字来指定特定大小写的字符。

为什么有人会这样做?

可能用更少的 space 编码文本,或者仅仅是因为作者考虑了 ABCabc 之间的选择装饰性大于意义,这让我想到了一个冗长的哲学背景解释,请参阅下一节:


如果您对我如何提出这个问题不感兴趣,请跳过这里的所有内容。

表示和含义

像 ASCII 和 UTF-8 这样的“现代”编码通过为每个字母分配单独的代码点来区分大写和小写。这个基本决定在今天如此普遍,以至于区分大小写 等概念对我们来说显得 相当自然。但是当比较摩尔斯电码、ASCII 和 Unicode 时,有很多传统上存储在纯文本编码之上的标记语言(例如 rtf、tex、html、doc)的区别,但是 今天可以以纯文本形式存储:

像盲文和摩尔斯电码这样非常古老的编码不对字母大小写进行编码,但 ASCII 编码。事实上,它会强制您选择大写字母或小写字母。如果您不在乎,没有明确的默认样式。

Unicode 及其 UTF 编码经常沿用这条路线,迫使您不仅要区分字母大小写,还要区分常规、斜体、粗体;无衬线体,衬线体;脚本,Fraktur;和更多。但 Unicode 也支持修饰符。而不是再次定义整个字母表,只有 underlined/colored/...,有组合字符,其行为类似于标记语言中的关键字。一个特殊的(序列)代码点表示下一个符号应该有下划线/有不同的颜色/ ... .

Unicode 旨在编码意义,而不是表示。我们在 Unicode 中拥有所有这些看似装饰性的变体,因为它们向某人传达了不同的含义。然而,越是“有意义”的区分,我就越觉得没有表示就不可能标准化意义。一些例子:

成为标准化意义的纯装饰性表示

根据表示法改变的标准化含义

两者的模糊组合

在平行宇宙中...

我想知道历史是否可以再次转向,人们看着这些问题并思考:你知道吗?我们无法区分装饰品和意义。因此,让我们尝试为最简单的纯文本创建一种编码,您甚至无法区分大写和小写。然后在上面添加另一种编码或标记语言,提供大量修饰符或关键字来表达您喜欢的任何化妆品。

在这样的世界中,“纯文本” 可能意味着 “一系列“常规”击键,其中计算机键盘发送标准化和国际唯一扫描码。

were there any character encodings (or markup languages on top of that), that differentiate between uppercase and lowercase letters, but not by defining the entire alphabet twice (once in capitals and once in lowercase letters), but by adding a modifier or keyword that specifies a character to be in a specific case.

这几乎就是 ASCII 的工作原理。字母“A”是 bit-sequence 1x0 0001。x 定义了您想要的 letter-case。同样,000 0001 是“Control-A”。 001 0001 是数字 1(相当于“A”的数字)也不是偶然的。 ASCII 序列的前两位确定接下来的 5 位标识的字符类型。您描述的那种修饰符在每个字节中发送。这完全是故意的。它允许极其高效的硬件实现来在电传打字机上打印字符。

这对于规范化搜索中的字母非常有用。你可以直接把bit 6设为0(或者忽略bit 6),那么大小写字母就一样了。

以不同的方式,TTS (Teletypesetting) systems 也有您所描述的内容。这是一个修改后的 Baudot 代码,带有一个额外的导轨,允许对 upper-vs-lower 大小写字母和 standard-vs-italic.

进行编码

Baudot 代码的主要特征是它使用 LTRS 和无花果代码转换模式。 (在研究 Baudot 代码时要非常小心。“小写”通常表示“大写字母”,“大写”通常表示数字。这些可以追溯到“大小写”的更字面意思。)

6-unit TTS 通过添加额外的栏杆来扩展它,允许“double-shift”设置 letter-case 和格式(斜体)。这与您所描述的非常接近。

“转变”方法的最大缺点是它不是 self-synchronizing。如果你跳到一个流的中间,你不知道如何显示字符,因为你不知道你处于什么模式。所以直接在代码上发送修饰符是非常好的。但这会使代码变大。

您在有关 Unicode 的问题中描述的许多事情并不完全出于您所建议的原因。比如是MATHEMATICAL SCRIPT CAPITAL A,明明是不是的文体,而是传达特定的语义。 ("The characters in this block are intended for use only in mathematical or technical notation, and not in nontechnical text.") 的存在是为了向后兼容以前的日本标准。这并不表示 Unicode 打算对化妆品进行编码。 (“几乎所有 Unicode 标准中的封闭符号和方块符号都被认为是兼容字符,编码是为了与其他字符集的互操作性。”)

So lets try to create an encoding for the plainest of plain texts where you cannot even distinguish between uppercase and lowercase.

这可能是一个有趣的爱好项目,并且可能非常有教育意义。祝你好运。我建议研究 Han unification 的历史和争议,以了解这些主题在实践中变得多么复杂。需要思考的一些入门问题:

  • 某些形式的 Romanized Arabic(也是克林贡语,虽然目前不是 Unicode 的一部分)使用字母大小写来区分完全不同的字母。这会改变您的编码吗?

  • 在 AZERTY 键盘上 é 有自己的键。在您的编码中 é 是单个“字母”还是 e 的变体? “常规击键”如何适用于此?

  • “扫码”是什么意思?通常扫描码只代表键盘上的一个位置,那么它如何适用于 AZERTY 或 Dvorak 等其他键盘布局?

我还会研究 UTF-16 的历史,以及为什么 UTF-8 如此成功。创建一种不向后兼容 Latin-1 并且需要更多 space 来存储英语的新编码将需要一些主要优势才能实际部署。 (另请参阅 IPv6。)但这种不切实际不应阻止您探索它。