为什么Unicode以这种方式实现Turkish I？

土耳其语中有点和无点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

与土耳其和阿塞拜疆字母的

i

是相同的，同样，大多数拉丁字母的

i

与土耳其和阿塞拜疆字母的

i

是相同的。字母表之间的关系也不同。人们可以很容易地争辩说，它们实际上是不同的（正如你提议的编码对待它们的那样），但语言委员会在20世纪20年代土耳其定义字母表和正字法时就是这样考虑的，而阿塞拜疆在20世纪90年代的使用也复制了这一点

（相比之下，有一些基于拉丁语的脚本，

i

在语义上应被视为与

i

相同，尽管从未使用点绘制[只需对不同形状的字形使用不同的字体即可]尤其是那些日期早于加洛林王朝或源自加洛林王朝的文字，例如盖尔语文字是如何从岛屿文字衍生而来的。事实上，尤其重要的是，不要用盖尔语书写爱尔兰语，在

i

上加上一个点，这可以与当时使用的正字法中的锡伯尔特变音相比较。悲哀许多尝试使用这种脚本的字体不仅会增加一个点，而且会造成更严重的拼写错误，使其成为一个笔划，因此会与fada变音符号混淆，因为它可能出现在

i

上，而síbuailte不能，因此会使单词的拼写出现错误。可能还有更多的“爱尔兰语”有此错误的字体比没有此错误的字体多）

---

实际原因是，现有的土耳其字符编码，如ISO/IEC 8859-9、EBCDIC 1026和IBM 00857，它们与ASCII或EBCDIC有共同的子集，已将

i

和

i

视为与ASCII或EBCDIC中的相同（也就是说，大多数拉丁字母表中的子集）和

ı

和

İ

作为单独的字符，它们是大小写变化的等价物；就像现在的Unicode一样。与这些脚本兼容需要继续这种做法。

实现这种做法的另一个实际原因是，如果不这样做，将给土耳其键盘布局用户带来极大的困惑和困难

想象一下，它是按照您建议的方式实现的，按土耳其键盘上的

I

键和

Iİ

键可以生成土耳其特有的Unicode字符。然后，即使土耳其语键盘布局包含所有ASCII/基本拉丁字符（例如，

q

，

w

，

x

在键盘上，即使它们不在土耳其语字母表中），一个字符将无法键入。例如，土耳其用户将无法访问

wikipedia.org

，因为他们实际上键入的是

w�K�ped�a、 org

。也许web浏览器可以专门为土耳其用户实施一种变通方法，但想想其他用例和大量难以使用的非本地化应用程序。也许土耳其键盘布局可以添加一个额外的键以再次成为ASCII完整键，这样就有三个键，即

i

，

iİ

，

iI

。但是，在已经拥挤的布局中使用一个键是毫无意义的浪费，而且会更加令人困惑，因此土耳其用户需要考虑哪一个键在每个上下文中都是合适的：“我正在键入一个用户名，它往往需要ASCII字符，所以在这里使用

iI

键”，“使用i字符创建密码时，我是使用了

iI

键还是

iİ

键？”

---

由于存在大量此类问题，即使Unicode包含土耳其语特有的i和i字符，键盘布局很可能会忽略它，继续使用常规的ASCII/基本拉丁字符，因此这些新字符将完全未被使用且毫无意义。但它们仍可能偶尔出现并造成混淆因此，他们没有走那条路是件好事。

I U+0049与I NEW有何不同？它是一个不同的字符吗？英语的I与瑞典语的I有何不同？询问“基本原理”通常不是一个理想的so问题（即“为什么C允许空值？”）-如有记录的原因，则应作为历史记录在档案中查找，且没有此类存档信息。@HansPassant排字员会抱怨Unicode的错误是由于30年前由首先是程序员的人拼凑而成。语言学家会抱怨这是因为“一群程序员和排字员想出了这个主意。涉及的多个学科会把它归咎于遗留问题，在这种情况下，至少是正确的。@HansPassant，还有，统一的一般问题——说“这个角色和那个角色是一样的。”“或否-在任何通用字符集的尝试中都是反复出现的，没有完美的答案，并且拆分或集中的两个极端都不是最优的。即使Unicode为这些字符实现了单独的代码点，它只解决了土耳其语的一个问题，并引出了其他一些问题。我完全错过了引用吉米·克的话的机会