所以我读过Joel's article,并查看了SO,似乎从ASCII切换到Unicode的唯一原因是国际化。作为一项政策,我所工作的公司只会发布英文软件,即使我们的客户遍布全球。由于我们所有的客户都是科学家,因此他们具有足够的英语功能,可以将我们的软件用作非母语人士。或者逻辑如此。由于这个策略,没有迫切需要切换到Unicode以支持其他语言。
但是,我正在开始一个新项目,并希望使用Unicode(因为这是一个负责任的程序员应该做的,对吧?)。为此,我们必须开始将我们编写的所有库转换为Unicode。这不是一项小任务。
如果程序本身的国际化不被认为是一个正当理由,那么如何将重新编码库和程序所花费的时间用于转换为Unicode? p>
答案 0 :(得分:31)
这显然取决于您的应用实际上做了什么,但仅仅因为您只有英文版本绝不意味着国际化不是问题。
如果我想存储使用非英文字符的客户名称该怎么办?或者是另一个国家/地区的名称?
作为一个额外的好处(因为你说你的目标是科学家)是各种科学符号和符号作为Unicode的一部分得到支持。
最终,我发现保持一致更容易。无论您在哪台计算机上运行应用程序,Unicode的行为都相同。非unicode意味着您默认使用某些与语言环境相关的字符集或代码页,因此在您的计算机上看起来很好的文本可能会在其他人的文本中充满垃圾字符。
除此之外,您可能不需要一次性将所有库转换为Unicode。根据需要编写包装器,以便在Unicode和您使用的任何编码之间进行转换。
如果您使用UTF-8作为Unicode文本,您甚至可以读取纯ASCII字符串,这可以为您节省一些转换问题。
答案 1 :(得分:16)
他们说他们现在总会把它用英语,但你承认你有全球客户。一位客户说,国际化是一个交易破坏者,他们真的会拒绝他们吗?
澄清一点,我试图让你说他们不会接受这种推理,但这是合理的。
总是更安全而不是抱歉,IMO。
答案 2 :(得分:15)
扩展的科学,技术和数学字符集规则。
除此之外,你还可以说⟦∀c|c∈Unicode⟧和类似的技术内容。
答案 3 :(得分:12)
超出7位ASCII范围的字符在英语中也很有用。有没有人使用你的软件甚至需要写下€标志?还是£?区分“简历”和“简历”怎么样?你说它被世界各地的科学家所使用,他们的名字可能是“Jörg”或“Guðmundsdóttir”。在科学环境中,将λ等波长,Å等单位或角度Θ说成是有用的,即使是英文也是如此。
其中一些字符,如“ö”,“£”和“€”可能有8位编码,如ISO-8859-1或Windows-1252,所以看起来你可能只是使用那些编码并完成它。问题在于,许多人经常使用这些范围之外的字符,因此许多现有数据以UTF-8编码。如果您的软件在导入数据时不理解,它可能会将UTF-8中的“£”字符解释为2个Windows-1252字符的序列,并将其渲染为“£”。如果这种错误检测不到足够长的时间,你可以开始让你的数据严重乱码,因为多次误解会改变你的数据,直到它变得无法恢复。
在程序设计的早期考虑这些问题是很好的。由于字符串往往是非常低级的概念,贯穿整个程序,并且有很多关于它们如何隐式使用它们的假设,如果以后向程序添加Unicode支持可能会非常困难和昂贵。你从来没有想过这个问题。
我的建议是尽可能使用支持Unicode的字符串类型和库,并确保处理字符串的任何测试(无论是单元,集成,回归或任何其他类型的测试)都尝试传递一些Unicode通过你的系统串起来确保它们工作并且没有受到伤害。
如果你不处理Unicode,那么我建议确保系统接受的所有数据都是7位干净的(也就是说,7位US-ASCII范围之外没有字符)。这有助于避免ISO-8859系列和UTF-8等8位传统编码之间出现不兼容问题。
答案 4 :(得分:11)
假设你的程序允许我把我的名字放在它,表格,对话框等等,而且我的名字不能用ascii字符书写......即使你的程序是英文的,数据可能是用其他语言......
答案 5 :(得分:10)
您的软件未翻译无关紧要,如果您的用户使用国际字符,那么您需要支持unicode才能进行正确的大小写,排序等。
答案 6 :(得分:5)
一方面,您的用户可能会了解并理解英语,但他们仍然可以拥有“本地”名称。如果您允许用户对您的应用程序进行任何类型的输入,他们可能希望使用不属于ascii的字符。如果您不支持unicode,则无法使用这些名称。你会强迫你的用户采用一个更简单的名称,因为应用程序不够聪明,无法处理特殊字符。
另一件事是,即使现在的标准是应用程序只会以英文发布,你也阻止了使用ASCII进行国际化的可能性,增加了公司政策决定时需要完成的工作。翻译是件好事。公司政策很好,但也有所改变。
答案 7 :(得分:5)
如果您没有业务需要切换到unicode,那么就不要这样做。我的基础是你认为你需要更改与你需要更改的组件无关的代码,以使其全部使用Unicode。如果您可以制作组件/功能,那么您就可以使用“Unicode ready”而不会将代码扩展到许多其他组件(特别是没有良好测试覆盖率的其他组件),那么请继续使用unicode。但是,如果没有业务需求,不要浪费整个代码库。
如果以后出现业务需求,请先解决。否则,你不会需要它。
此线程中的人可能会假设它成为业务需求的场景。在考虑这些方案值得解决之前,请由产品经理运行这些方案。当你提问时,确保他们知道解决问题的成本。
答案 8 :(得分:4)
我会说这种态度表达了天真,但我无法用ASCII语言表达天真。
ASCII仍适用于某些仅限计算机的代码,但对机器和用户之间的外观不利。
即使没有纽约人的老式合作风格,如果她的雇主使用这样的系统,那么一个名叫Zoë的可怜女人会如何应对呢?
唉,她甚至不会寻求其他工作,因为更新她的简历是不可能的,而且她必须恢复。她怎么去向她的未婚妻解释那个?答案 9 :(得分:4)
我工作的公司**作为政策**,只会发布英文软件,即使我们的客户遍布全球。
仅限1个原因:政策发生变化,当它们发生变化时,它们将破坏您现有的代码。期。
Design for evil,您很有可能不会很快破坏您的代码。在这种情况下,请使用Unicode。发生在巴西特定的股票市场遗产系统上。
答案 10 :(得分:3)
这是一个非常好的问题。我能想到的与I18n或非英文文本无关的唯一原因是Unicode特别适合作为可能被称为集线器字符集的东西。如果您将系统视为具有外部依赖关系作为辐条的集线器,则需要将字符编码转换与辐条隔离,以便您的集线器系统与所选编码一致。使Unicode成为系统中枢的理想字符集的原因在于它承认其他字符集的存在,它定义了它自己的字符和那些外部字符集中的字符之间的等价,并且有一个持续的过程,它将自身扩展到保持随着外部字符集的创新和发展。有各种奇怪的编码:即使文档确保外部系统或库使用纯ASCII,它通常会变成像IBM775或HPRoman8这样的变体,而Unicode的优点在于无论是什么编码向您抛出,很有可能在unicode.org上有一个表,它确切地定义了如何将该数据转换为Unicode并再次退出而不会丢失信息。然后,a-z的等价物在每个字符集中都相当明确,因此如果您的数据实际上仅限于标准英文字母,则ASCII可能与集线器字符集一样。
关于编码的决定是关于两件事的决定 - 允许哪些字符集以及如何表示这些字符。 Unicode允许您使用几乎所有发明的角色,但您可能有自己的理由不想要或需要这么多选择。例如,您可能仍会将用户名限制为az和下划线的组合,可能是因为您必须将它们放入外部LDAP系统中,这些外部LDAP系统的字符集受到限制,可能是因为您需要使用不支持的字体将它们打印出来覆盖所有的Unicode,可能是因为它关闭了由相似的字符打开的安全问题。如果您使用的是ASCII或ISO8859-1,存储/传输层会实现许多限制;使用Unicode,存储层不会限制任何内容,因此您可能必须在应用程序层实现自己的规则。这是更多的工作 - 更多的编程,更多的测试,更多可能的系统状态。额外工作的权衡更灵活,应用程序级规则比系统编码更容易更改。
答案 11 :(得分:3)
使用unicode的原因是为了尊重设计中的正确抽象。
习惯于正确对待文字的概念。这并不难。即使您的用户是英语,也没有理由创建破损的设计。
答案 12 :(得分:3)
许多语言(Java [因此大多数基于JVM的语言实现],C#[因此大多数基于.NET的语言实现],Objective C,Python 3,...)优先支持Unicode字符串甚至(几乎) )(你必须用你的方式来处理字节的“字符串”而不是Unicode字符)。
如果您工作的公司打算使用这些语言和平台中的任何一种,那么开始规划Unicode支持策略是非常明智的。特别是一个试点项目可能不是一个坏主意。
答案 13 :(得分:2)
想想一个客户想要使用SchrödingersCat这样的名字来表示他使用你的软件保存的文件。或者想象一些本地化的Windows,其中包含使用非ASCII字符的 My Documents 的翻译。这将是国际化,尽管你根本不支持国际化,但它会对你的软件产生影响。
此外,选择以后支持国际化总是一件好事。
答案 14 :(得分:1)
国际化不仅仅是不同语言的文本。我敢打赌,这是IT世界未来的利基。哎呀,它已经是。已经说了很多,只是想我会添加一些小东西。即使您的客户现在对英语感到满意,但未来可能会发生变化。等待的时间越长,转换代码库就越困难。他们甚至可能在今天遇到问题。您在应用程序中保存/加载的文件名或其他类型的数据。
答案 15 :(得分:1)
您还没有说过您正在使用的语言。在某些语言中,从ASCII更改为Unicode可能非常简单,而在其他语言(不支持Unicode)中,它可能非常难以实现。
那就是说,也许在你的情况下你不应该支持Unicode:你不能想到一个令人信服的理由,为什么你应该这样做,并且有一些理由(即改变现有库的成本)反对。我的意思是,或许'理想'你应该,但在实践中可能会有一些其他的,更重要或更紧急的事情,现在花费你的时间和精力。
答案 16 :(得分:1)
如果程序从用户那里获取文本输入,它应该使用unicode;你永远不知道用户将使用什么语言。
答案 17 :(得分:1)
Unicode就像cooties。一旦它“感染”了一个区域,由于依赖关系的互连性,通常很难包含它。迟早,您可能必须绑定一个符合unicode的库,因此将使用wchar_t等。不是在字符类型之间进行编组,而是始终保持一致的字符串。
因此,保持一致是件好事。否则,您将最终得到类似于Windows API的东西,其中包含大多数API的“A”版本和“W”版本,因为它们一开始并不一致。 (在某些情况下,微软有abandoned creating "A" versions altogether。)
答案 18 :(得分:0)
您的潜在客户可能已经使用非英语语言运行非unicode应用程序,并且无法在不同时来回切换Windows unicode语言环境的情况下运行您的程序,这将是一个巨大的痛苦。
答案 19 :(得分:0)
因为互联网绝大多数都使用Unicode。网页使用unicode。文本文件(包括客户的文档和剪贴板上的数据)是Unicode。
其次,Windows本身是Unicode,而ANSI API是遗留的。
现代应用程序应该在适用的地方使用Unicode,几乎无处不在。
答案 20 :(得分:0)
当使用Unicode时,如果要求发生变化并且您需要使用除英语之外的其他语言的文本,它将为国际化打开大门。
此外,在您的新项目中,您总是可以为内部在ASCII和Unicode之间转换的库编写包装器,反之亦然。