为什么不是我们用Unicode做的一切？

Question

鉴于Unicode已经存在了18年,为什么仍有应用程序没有Unicode支持？甚至我对某些操作系统和Unicode的经验至少可以说是痛苦的.正如Joel Spolsky在2003年指出的那样,并不难.那是什么交易？为什么我们不能把它放在一起？

Answer 1

从几个问题开始

多常...

• 你需要编写一个处理ascii以外的东西的应用程序吗？
• 你需要写一个多语言的应用程序吗？
• 你编写的应用程序必须是第一版的多语言吗？
• 你听说过Unicode用来表示非ascii字符吗？
• 你读过Unicode是一个字符集吗？那个Unicode是一种编码？
• 你看到人们混淆UTF-8编码的字节串和Unicode数据吗？

你知道排序规则和编码之间的区别吗？

您最初在哪里听说过Unicode？

• 在学校？(真的吗？)
• 工作中？
• 在一个时髦的博客？

在您年轻的时候,您是否曾经历过从语言环境A中的系统到系统B中的系统的移动源文件,编辑了系统B上的拼写错误,保存了文件,以及所有非ascii评论和...最终浪费了很多时间试图了解发生了什么？(你的编辑器混合了什么？编译器？系统？......？)

您最终决定再也不会使用非ascii字符对您的代码进行评论吗？

看看其他地方正在做什么

蟒蛇

我是否提到我喜欢Python？没有？我喜欢Python.

但是在Python3.0之前,它的Unicode支持很糟糕.并有所有这些新秀的程序员,谁在那个时候知道勉强如何写一个循环,得到UnicodeDecodeError和UnicodeEncodeError设法应付非ASCII字符时,不知从何处.好吧,他们基本上受到Unicode怪物的生命创伤,我知道很多非常有效/经验丰富的Python编码器,今天仍然害怕必须处理Unicode数据的想法.

使用Python3,Unicode和字节串之间有明显的区别,但是......看看如果你以前不关心分离/将Python应用程序从Python 2.x移植到Python 3.x有多麻烦如果你不真正明白Unicode是什么.

数据库,PHP

您是否知道一个流行的商业网站将其国际文本存储为Unicode？

你会(可能)会惊讶地得知,维基百科的后端并没有使用Unicode存储其数据.所有文本都以UTF-8编码,并作为二进制数据存储在数据库中.

这里的一个关键问题是如果将文本数据存储为Unicode代码点,如何对其进行排序.这是Unicode 排序规则,它定义了Unicode代码点上的排序顺序.但是对数据库中的排序规则的适当支持缺失/正在积极开发中.(也可能存在许多性能问题. - IANADBA)此外,还没有广泛接受的归类标准:对于某些语言,人们不同意如何对单词/字母/单词组进行排序.

你听说过Unicode规范化吗？(基本上,您应该在存储之前将Unicode数据转换为规范表示)当然,这对数据库存储或本地比较至关重要.但是,例如,PHP自2007年8月发布的5.2.4以来仅提供了对规范化的支持.

事实上,PHP还没有完全支持Unicode.我们必须等待PHP6才能在任何地方获得与Unicode兼容的功能.

那么,为什么不是我们用Unicode做的一切？

1. 有些人不需要Unicode.
2. 有些人不在乎.
3. 有些人不明白他们以后会需要Unicode支持.
4. 有些人不懂Unicode.
5. 对于其他一些人来说,Unicode有点像webapps的可访问性:你从没有开始,并将在以后添加对它的支持
6. 许多流行的库/语言/应用程序缺乏正确的,完整的Unicode支持,更不用说校对和规范化问题了.在开发堆栈中的所有项目完全支持Unicode之前,您无法编写干净的Unicode应用程序.

互联网显然有助于传播Unicode趋势.这是件好事.Python3等突破性变革等举措有助于教育人们解决问题.但我们必须耐心等待更多地看到所有地方的Unicode和新程序员本能地使用Unicode而不是字符串.

对于这个轶事,因为联邦快递显然不支持国际地址,谷歌要求Google夏季代码 '09学生提供仅限ascii的名称和地址.如果您认为大多数业务参与者理解Unicode支持背后的利害关系,那么您就错了.联邦快递不理解,他们的客户并不在乎.然而.

Answer 2

• 许多产品开发人员不认为他们的应用程序在亚洲或其他需要Unicode的地区使用.
• 将现有应用程序转换为Unicode是昂贵的,通常由销售机会驱动.
• 许多公司都在遗留系统上维护产品,迁移到Unicode意味着一个全新的开发平台.
• 你会惊讶于有多少开发人员不理解Unicode在多语言环境中的全部含义.这不仅仅是使用宽字符串的情况.

底线 - 成本.

Answer 3

可能是因为人们习惯使用ASCII,很多编程都是由母语为英语的人完成的.

IMO,它是集体习惯的一种功能,而不是有意识的选择.

Answer 4

用于处理Unicode的开发工具的广泛可用性可能是比您想象的更新的事件.直到几年前,使用Unicode是一种痛苦的任务,即在字符格式之间进行转换以及处理不完整或错误的实现.你说它并不那么难,而且随着工具的改进变得更加真实,但除非好的语言和图书馆隐藏你的细节,否则有很多方法可以解决.在几年前,只是切割和粘贴unicode角色可能是一个值得怀疑的命题.开发人员教育也花了一些时间,你仍然看到人们犯了很多真正的基本错误.

Unicode标准重约10磅.即使只是概述它也必须讨论字符,字形,代码点等之间的微妙区别.现在考虑ASCII.这是128个字符.我可以在大约5分钟内向知道二进制文件的人解释整个事情.

我相信现在几乎所有的软件都应该用完全的Unicode支持编写,但是通过编码实现真正的国际字符集以实现各种目的已经走了很长的路,并且它还没有结束.

Answer 5

懒惰,无知.

Answer 6

一个重要的因素是编程语言支持,其中大多数使用符合8位(如ASCII)的字符集作为字符串的默认值.Java的String类使用UTF-16,还有其他支持Unicode的变体,但许多语言选择简单.如今,太空是如此微不足道的关注,那些坚持"节省空间"字符串的程序员应该被打耳光.大多数人根本就没有在嵌入式设备上运行,甚至像手机这样的设备(不久的将来的大计算浪潮)也可以轻松处理16位字符集.

另一个因素是许多程序只是用英语编写,而开发人员(1)不计划(甚至不知道如何)为多种语言本地化他们的代码,(2)他们通常甚至不考虑处理非罗马语言的输入.英语是程序员所说的主要自然语言(至少是彼此之间的交流),并且在很大程度上已经延续到我们生产的软件中.然而,冷漠和/或无知肯定不会永远持续下去......鉴于亚洲移动市场完全超过世界其他大部分地区的事实,程序员将不得不很快处理Unicode,无论他们是否喜不喜欢.

对于它的价值,我认为Unicode标准的复杂性并不是程序员的重要因素,而是那些必须实现语言支持的人.当用已经完成艰苦工作的语言编程时,没有理由不使用手头的工具.C'est la vie,旧习惯很难受.

Answer 7

直到最近,所有操作系统都是基于字符是一个字节的假设而构建的.它的API是这样构建的,工具是这样构建的,语言是这样构建的.

是的,如果我写的所有东西都已经好了......那就错了...... UTF-8？UTF-16？UTF-7？UTF-32？呃......嗯......似乎无论你选择什么,你都会惹恼别人.而且,事实上,这是事实.

如果你选择UTF-16,那么你的所有数据,就像在西方世界的整个经济中一样,都会停止无缝读取,因为你失去了ASCII兼容性.除此之外,一个字节不再是一个字符,它严重打破了今天的软件构建的假设.此外,一些国家不接受UTF-16.现在,如果您选择任何可变长度编码,您可以打破许多软件的基本前提,例如不需要遍历字符串以找到第n个字符,能够从任何点读取字符串.

然后,UTF-32 ......好吧,这是四个字节.10年前的平均硬盘大小或内存大小是多少？UTF-32太大了!

因此,唯一的解决方案是改变一切 - 软件,实用程序,操作系统,语言,工具 - 同时具有i18n感知能力.好.祝你好运"同时".

如果我们不能同时做所有事情,那么我们总是要留意那些不是i18n的东西.这导致恶性循环.

对于最终用户应用程序而言,它比中间件或基本软件更容易,并且正在以这种方式构建一些新语言.但是......我们仍然使用60年代编写的Fortran库.这一遗产,它不会消失.

Answer 8

因为UTF-16在UTF-8之前变得流行,而UTF-16是一个可以使用的猪.恕我直言