为什么 Unicode 以它的方式实现土耳其语 I？答案

【问题标题】：Why does Unicode implement the Turkish I the way it does?为什么 Unicode 以它的方式实现土耳其语 I？
【发布时间】：2018-01-02 20:39:31
【问题描述】：

土耳其语将带点和不带点的 I 分为两个单独的字符，每个字符都有自己的大写和小写形式。

Uppercase  Lowercase
I U+0049   ı U+0131
İ U+0130   i U+0069

而在其他使用拉丁字母的语言中，我们有

Uppercase  Lowercase
I U+0049   i U+0069

现在，Unicode 联盟可以将其实现为六个不同的字符，每个字符都有自己的大小写规则，但决定只使用四个，在不同的语言环境中具有不同的大小写规则。这对我来说似乎很奇怪。 做出该决定的理由是什么？

六个不同字符的可能实现：

Uppercase  Lowercase
I U+0049   i U+0069
I NEW      ı U+0131
İ U+0130   i NEW

当前使用的代码点：

U+0049 ‹I› \N{LATIN CAPITAL LETTER I}
U+0130 ‹İ› \N{LATIN CAPITAL LETTER I WITH DOT ABOVE}
U+0131 ‹ı› \N{LATIN SMALL LETTER DOTLESS I}
U+0069 ‹i› \N{LATIN SMALL LETTER I}

【问题讨论】：

I U+0049 与 I NEW 有何不同？是不是性格不一样？英文I 和瑞典文I 有区别吗？
询问“基本原理”通常并不是一个理想的 SO 问题（即“为什么 C# 允许 null？”） - 例如有文档记录的原因，这些应该可以作为历史记录在档案中找到，并且在没有此类存档信息的地方..
@HansPassant 排版师会抱怨 Unicode 的错误是由于 30 年前由最初是程序员的人拼凑而成的。语言学家会抱怨这是因为一堆程序员和排版师想出来的。涉及的多个学科会将其归咎于遗留问题，至少在这种情况下是正确的。
@HansPassant 而且，统一的一般问题——说“这个字符是否与那个字符相同”——在任何尝试通用字符集的过程中都是经常出现的，没有完美的答案, 分裂或集总的极端都不是最优的。
即使 Unicode 为这些字符实现了单独的代码点，它也只解决了土耳其语的一个问题，留下了 a lot of other case mapping problems 并引入了一些其他问题

标签： unicode

【解决方案1】：

有一个理论原因和一个实践原因。

理论上，大多数拉丁字母的 i 与土耳其语和阿塞拜疆字母的 i 相同，同样，大多数拉丁字母的 I 和 I土耳其语和阿塞拜疆语是一样的。字母之间的关系也不同。人们可以很容易地争辩说它们实际上是不同的（正如您提议的编码对待它们一样），但这就是语言委员会在 1920 年代在土耳其定义字母表和正字法时考虑它们的方式，而 1990 年代的阿塞拜疆使用复制了这一点。

（相比之下，有一些基于拉丁文的脚本，i 在语义上应该被视为与i 相同，尽管从未用点绘制[只是为不同形状的字形使用不同的字体]，尤其是那些日期在加洛林语之前或从一个派生出来，例如盖尔语脚本是如何从岛屿脚本派生的。确实，特别重要的是永远不要用盖尔语脚本写爱尔兰语，在i 上带有一个点，可以与 sí buailte 变音符号进行比较与它一起使用的正字法。遗憾的是，许多尝试使用此脚本的字体不仅会添加一个点，而且还会导致更严重的拼写错误，使其成为笔画，因此与 fada 变音符号混淆，因为它可能出现在 @987654328 @ 而 sí buailte 不能，因此会使单词的拼写错误。可能有更多的“爱尔兰”字体有这个错误而不是没有）。

实际原因是现有的土耳其字符编码，如 ISO/IEC 8859-9、EBCDIC 1026 和 IBM 00857，它们具有与 ASCII 或 EBCDIC 相同的子集，已经将 i 和 I 视为与ASCII 或 EBCDIC（即大多数拉丁字母表中的那些）和 ı 和 İ 作为单独的字符，它们是大小写更改的等价物；就像现在的 Unicode 一样。与此类脚本的兼容性需要继续这种做法。

【讨论】：

我完全错过了一个机会来引用 Jimmy Kennedy/Nat Simon 的歌词，同时在这里保持话题。
添加到这个答案：在同一个脚本中编码两个在设计上总是在外观上 100% 相同的字符将是一个巨大的安全风险。通过禁止脚本混合，至少可以避免跨脚本同形字。
@RandomGuy32 这不是统一两个真正不同的字符的好理由，尽管两个字符是否存在比这更棘手的情况（例如，拉丁分号和希腊问号，以及很多 CJK 表意文字）。至于所讨论的历史，虽然同形字符即使在仅使用 ASCII 或 EBCDIC 中也存在已知问题，但随着消费者更多地使用互联网而出现的那种安全问题在当时并不是一个大问题。
土耳其和阿塞拜疆字母表中的大写 I 与其他所有拉丁字母表中的大写 I 有何“真正不同”？
@RandomGuy32 他们不是，但我的意思是我们不能将其应用于所有同形文字，因为我们不能使用例如T 和 Т，只要涉及安全风险。

【解决方案2】：

实施该实施的另一个实际原因是，否则会给土耳其语键盘布局用户带来极大的困惑和困难。

想象一下，它是按照您建议的方式实现的，在土耳其语键盘上按 ıI 键和 iİ 键会生成土耳其语特有的 Unicode 字符。然后，即使土耳其语键盘布局包含所有 ASCII/基本拉丁字符（例如，q、w、x 在键盘上，即使它们不在土耳其语字母表中），一个字符也会变得不可能类型。因此，例如土耳其用户将无法访问wikipedia.org，因为他们实际输入的内容是w�k�ped�a.org。也许网络浏览器可以专门为土耳其用户实施一种解决方法，但想想其他用例和堆非本地化的应用程序，这些应用程序将变得难以使用。也许土耳其键盘布局可以添加一个额外的键以再次成为 ASCII 完整键，这样就有三个键，即ıI、iİ、iI。但在已经很拥挤的布局中浪费一个键是毫无意义的，而且会更加混乱，因此土耳其用户需要考虑在每种情况下哪个是合适的：“我正在输入一个用户名，这往往需要 ASCII字符，所以在这里使用iI 键", "使用 i 字符创建密码时，我使用的是iI 键还是iİ 键？"

由于无数这样的问题，即使 Unicode 包含土耳其语特有的 i 和 I 字符，键盘布局很可能会忽略它并继续使用常规 ASCII/基本拉丁字符，因此新字符将完全未被使用并没有实际意义。除了他们仍然可能偶尔会出现在某些地方并造成混乱，所以他们没有走那条路是一件好事。

【讨论】：

这是一个我没有想到的绝妙点。