我想知道为什么任何开发人员都需要使用UTF-8以外的编码。
答案 0 :(得分：26)
维基百科列出了UTF-8与其他各种编码相比的优缺点：
http://en.wikipedia.org/wiki/UTF-8#Advantages_and_disadvantages
最重要的缺点是恕我直言，UTF-8可能会显着使用更多空间，尤其是亚洲语言，例如中文，日文或印地文，而并非所有代码点都具有相同的大小< / strong>这使得测量更加困难，并且搜索等许多字符串操作效率低下。
答案 1 :(得分：12)
嗯，有些人这样做是因为他们的工具过时或有缺陷。有些人这样做是因为他们认为不需要支持ASCII以外的任何东西。有些人这样做是因为他们不知道更好。
这些是不使用Unicode的常用借口。
至于不使用UTF-8具体有不同的原因。有些系统，比如Windows 1 （源自那个，.NET）和Java，正处于Unicode是严格的16位代码的时代。因此，实际上只有一种编码：UCS-2，编码代码直接指向16位字。
后来Unicode扩展到21位，因为65536代码点不再足够了。这会导致出现UTF-32和UTF-16等编码。对于以前使用UCS-2的系统，过渡到UTF-16是最简单和最明智的选择。 Windows在Windows 2000的Ye Olde Days中做了那个过渡。
因此，虽然我认为现在几乎所有应用程序都应该支持 Unicode ，但我认为他们并不完全有必要专门使用UTF-8。这有历史原因，并且将现有系统从UTF-16转换为UTF-8没有实际好处。
1 NT。
答案 2 :(得分：9)
在UTF-8中，0800和FFFF之间的代码点占用UTF-8中的三个字节，但UTF-16中仅占两个字节。有关详细信息，请参阅wikipedia comparison，但基本上如果文本大量使用此范围内的代码点（例如，如果它是中文），则UTF-8文件将大于具有相同内容的UTF-16文件。
答案 3 :(得分：8)
UTF-8在编码纯英文文本（与ASCII相同）方面非常有效。如果您的用户群可能主要是中文，那么使用UTF-16会更好。
答案 4 :(得分：5)
有时候由于历史/不支持的原因它们受到限制（我在Windows上使用Zend Studio在Linux机器上的Samba共享上进行开发：这种混合中的某些东西意味着我一直在恢复到Cp1512而不是UTF8）。 p>
有时您不需要使用UTF-8（例如，在数据库中存储md5哈希时：您只需要十六进制范围0-9 AF：为什么要将它设为UTF-8字段，这将是至少一个字节的额外存储而不是普通的ASCII）。
有时只是懒惰学习特定语言的UTF-8函数。
答案 5 :(得分：5)
因为他们不知道更好。 对utf-8唯一有效的批评是，对于常见的亚洲语言的编码超出了其他编码的范围。 UTF-8是优越的，因为
假设你有这个UTF-16字符串。
[0][1][2][F|3] [4] [5]
并且您希望在[3]和[4]之间插入代码为8的字符 你会做插入（5,8）
如果您没有检查BMP之外的字符（按照UTF-8的顺序排列，因为您无法知道您拥有多少双字符），您将获得：
[0][1][2][F|8][3][4][5]
两个新的垃圾字符。非常适合您的固定大小编码。 您当然可以完全禁止这些字符，但是当您的代码与现实世界接口时，您可能会发现您的程序为生活在rm -Rf / in .profile而不是[Classical Chinese Proverb] .profile的用户保存配置文件。
或者只是一个愤怒的用户，无法用你的软件在古典中文谚语上写论文。
答案 6 :(得分：5)
因为在英语世界之外，人们一直在使用早于Unicode的各种编码，并且已经为他们各自的语言量身定制了几十年。这些特定于语言的编码已经在各地根深蒂固，几乎是一个标准。如果您希望与遗留系统接口，则必须使用它们，因此所有系统都必须支持它们并且通常将它们用作默认值，即使它们现在也支持UTF-8。传统上可能存在多种用于不同目的的遗留编码。
示例：
最后两个例子表明，编码甚至可能是一个政治问题。
答案 7 :(得分：4)
一个合理的原因是您需要处理与Unicode不兼容的旧文档，软件或硬件。
另一个合理的原因是你需要使用不支持UTF8 / Unicode的编程语言/库......或者根本不需要。
其他答案提到UTF-16比亚洲语言/字符的UTF-8更紧凑。
当然还有短视，无知，懒惰......和截止日期等原因。
答案 8 :(得分：3)
还值得记住的是，在某些情况下（需要非拉丁字符集），UTF-8实际上可能比16位Unicode编码更大。在这些情况下，ucs-2或utf-16将是更好的选择。
答案 9 :(得分：3)
http://www.personal.psu.edu/ejp10/blogs/gotunicode/2007/02/cjk-unicode-angst-in-japan-and.html有一个很好的摘要+关于日本用户使用Unicode的难度的链接。
http://www.hastingsresearch.com/net/04-unicode-limitations.shtml
显然，由于此类投诉，Unicode正逐渐脱离统一。
答案 10 :(得分：2)
使用非Unicode 8位字符集/编码的原因都是某种类型和/或惯性的后向兼容性。就此而言，使用UTF-8的最常见原因是与XML等标准的兼容性要求或更喜欢UTF-8。
您认为文本在不同编码中占用的字节数差异，特别是在存储方面，主要是理论上的。在实际情况中，兼容性要求更为重要。如果使用压缩，则无论如何都会消除尺寸差异。即使不使用压缩，总文本大小也难以预测，并且很少是决定因素。
在转换使用非Unicode 8位编码的遗留代码时，使用UTF-16可以成为确保所有代码都已转换的工具，因为不匹配可以作为编译时类型错误捕获。许多语言，运行时和库（如Javascript，JVM，.NET，ICU）使用16位字符串和UTF-16，即使存储和Internet协议通常是8位。
答案 11 :(得分：1)
想象一下，所有要考虑的文件都在GB2312（中国大陆标准）中。然后您可以选择GB18030作为Unicode编码。它们的兼容性与所有ASCII为UTF-8的方式相同。这在中国大陆很有用！
如果您想在中国（大陆）发货，当您发现法律规定的IT产品中都需要提到GB标准（据我所知）时，您可能会更快决定。
另一个优点是GB2312，以及GB18030也是ASCII兼容的。
但是，它在算法上并不那么健壮。 - 因此，如果您没有政治原因或任何GB2312遗产，使用它是没有意义的。但如果你这样做，你就得到了答案。答案 12 :(得分：1)
与主题相关，当使用MySQL时，就好像它不够复杂，您可以选择选择要使用哪种UTF-8排序规则。那么你会用什么？
UTF-8 general ci
要么
UTF-8 unicode ci？
（我倾向于使用用于数据库连接的UTF-8变体）
答案 13 :(得分：0)
在我以前的雇主，我们使用iso-8859-1来处理我们的一些ASP页面，以匹配我们的SQL Server的整理，你可以猜到它不是Unicode。我想改变整理，但经理说要等到我们升级我们的SQL Server才能做到这一点。毋庸置疑，它从来没有发生过 - 我已经有一年多的时间没和他们在一起了，所以我不知道他们是不是最终做到了。
答案 14 :(得分：0)
许多API需要其他Unicode编码 - 主要是UTF-16。例如，Java，.NET，Win32。
答案 15 :(得分：0)
在大多数情况下，Unicode肯定是一个很好的工作场所，但开发人员应该熟悉许多不同类型的字符编码。当然，如果字符集有限，可能会使用ASCII。
如果您是开发人员并从不发送UTF-8的来源接收数据，该怎么办？如果你不理解你的输入，可能会有很多界面问题。
关于字符编码必须知道的Joel's article是好的，值得一读。
答案 16 :(得分：0)
因为您有时希望在代码点上轻松操作 - 那么您可以选择f.e. UCS-2或UCS-4。