在WWW上使用UTF-8对非英文文本有多广泛？我对统计数据和特定国家的情况感兴趣。
我知道ISO-8859-1（或15）在德国已经根深蒂固 - 但是对于那些你必须使用多字节编码的语言，比如日本或中国呢？我知道几年前，日本几乎只使用各种JIS编码。
鉴于这些观察结果，UTF-8是最常见的多字节编码甚至是真的吗？或者更确切地说，它基本上只在内部用于专门针对国际市场和/或必须使用多语言文本的新应用程序中？现在是否可以使用仅在其输出中使用UTF-8的应用程序，或者每个国家市场都希望输出文件采用不同的遗留编码，以便其他应用程序可以使用。
修改： 我不是在问UTF-8是否有用或为何如此有效。我知道这一切。我问的是它是否真的被广泛采用并取代旧的编码。
答案 0 :(得分：15)
我们几乎完全在面向服务的网络服务领域使用UTF-8 - 即使只使用“西方”欧洲语言，使用各种ISO-8859-X格式让我们的头脑旋转还有足够的“怪癖” - UTF-8真的完全解决了这个问题。
因此，无论何时何地，我都会投票 BIG 投票使用UTF-8！ :-)我想在面向服务的世界以及.NET和Java环境中，这不再是一个问题或潜在的问题。
它只解决了很多问题，你真的不需要一直处理......
马克
答案 1 :(得分：9)
答案 2 :(得分：5)
我认为只接受UTF-8是不可接受的 - 您需要接受UTF-8以及之前在您的目标市场中流行的任何编码。
好消息是，如果你来自德国的情况，你主要有8859-1 / 15和ASCII，另外接受8859-1并将其转换为UTF-8基本上是零成本。它很容易检测：例如，使用8859-1编码的ö或ü是无效的UTF-8，甚至没有进入易于检测的无效对。使用字符128-159不太可能有效8859-1。在第一个高字节的几个字节内，通常可以非常好地了解正在使用的编码。一旦你知道编码，无论是通过规范还是猜测，你都不需要转换表来将8859-1转换为Unicode - U + 0080到U + 00FF与8859-1中的0x80-0xFF完全相同
答案 3 :(得分：5)
我倾向于经常访问Runet个网站。他们中的许多人仍使用Windows-1251编码。它也是Yandex Mail和Mail.ru（独联体国家中两个最大的网络邮件服务）的默认编码。当从俄罗斯的ip地址下载它时，它也被设置为Opera浏览器中的默认内容编码（在该地区受欢迎的Firefox之后的第二个）。我不太确定其他浏览器。
原因很简单：UTF-8需要两个字节来编码西里尔字母。非unicode编码仅需要1个字节（与大多数东方字母不同，西里尔字母非常小）。它们也是固定长度的，可以通过旧的纯ASCII工具轻松处理。
答案 4 :(得分：4)
现在是否可以接受 仅在其中使用UTF-8的应用程序 输出，或将每个国家市场 期望输出文件在 不同的遗留编码为了 可以被其他应用程序使用。
嗯，取决于我们正在谈论的应用程序和输出类型......在许多情况下（例如大多数基于Web的东西）你当然可以使用UTF-8，但是，例如，在桌面上允许用户在纯文本文件中保存一些数据的应用程序，我认为UTF-8只有不足。
Mac OS X广泛使用UTF-8，它是用户文件的默认编码，大多数（所有？）主要Linux发行版也是如此。但在Windows上...是Windows-1252（关闭但与ISO-8859-1不相同）仍然是许多语言的默认编码？至少在Windows XP中它是，但我不确定这是否已经改变了？在任何情况下，只要大量（大多数是Windows）用户在Windows-1252中编码的计算机上的文件（或接近该文件），支持UTF-8只会给许多人带来悲伤和困惑。
某些国家特定信息：芬兰ISO-8859-1（或15）同样仍然根深蒂固。举个例子，芬兰的IRC频道使用afaik，主要是拉丁语-1。 （这意味着使用UTF-8作为系统默认使用基于文本的客户端（例如irssi）的Linux人员需要做一些变通/调整设置。）
答案 5 :(得分：3)
CJK字符的用户自然会偏向于UTF-8，因为它们的字符变为3个字节而不是2个字节。显然，在中国，首选的是他们自己的2字节GBK编码，而不是UTF-16。
编辑以回应@Joshua的评论：
事实证明，对于大多数网络工作来说，无论如何，UTF-8中的页面会更小，因为HTML和javascript字符现在编码为一个字节。
响应：
GB。+编码和其他东亚编码是可变长度编码。值最大为0x7F的字节主要映射到ASCII（有时会有微小的变化）。高位设置的某些字节是2到4个字节序列的前导字节，其他字节是非法的。就像UTF-8一样。
由于“HTML和javascript字符”也是ASCII字符，因此它们在这些编码和UTF-8中始终为1个字节。
答案 6 :(得分：3)
以下是我能够找到的一些统计数据：
这两个页面似乎都遇到了重大问题：
更重要的是，统计信息仅适用于可通过网络访问的内容。似乎无法获得更广泛的统计数据（例如，用于用户硬盘驱动器上的文档编码）。 （考虑到在许多国家进行必要的研究是多么困难/昂贵，这并不让我感到惊讶。）
简而言之，您的问题不能客观地回答。您可以在某处找到关于UTF-8应用程序可能在特定国家/地区“可接受”的研究，但我无法找到任何研究。
对我而言，最好的做法是将您的应用程序编写为与字符编码无关，并让用户决定使用哪种字符编码来存储文档。在Java和C＃等现代语言中，这相对容易。
答案 7 :(得分：2)
UTF-8很受欢迎，因为它通常比UTF-16更紧凑，具有完全保真度。它也不会受到UTF-16的字节序问题的影响。
这使它成为交换格式的绝佳选择，但由于字符编码为不同的字节运行（每个字符从1到4个字节），因此使用它并不总是很好。因此，保留UTF-8进行数据交换通常更为清晰，并在进入和退出点使用转换。
对于系统内部存储（包括磁盘文件和数据库），使用本机UTF-16，UTF-16和其他压缩或一些8位“ANSI”编码可能更简洁。后者当然会限制您使用特定的代码页，如果您正在处理多语言文本，您可能会受到影响。为了在本地处理数据，您可能需要一些“ANSI”编码或本机UTF-16。通过这种方式，字符处理成为一个很多更简单的问题。
所以我建议UTF-8很受欢迎外部，但内部却很少见。除了静态文本blob之外，UTF-8内部似乎是一个噩梦。
有些DBMS似乎总是选择将文本blob存储为UTF-8。这提供了压缩（过度存储UTF-16）的优点，而不试图设计另一种压缩方案。因为转换到UTF-8或从UTF-8转换是如此常见，所以它们可能会使用已知可以高效可靠地工作的系统库。
“ANSI”方案的最大问题是绑定到一个小字符集，需要处理具有大字母的语言的多字节字符集序列。
答案 8 :(得分：2)
虽然它没有专门解决这个问题 - 但UTF-8是唯一必须在所有IETF跟踪协议中实现的字符编码。
答案 9 :(得分：2)
您可能对this问题感兴趣。我一直在努力建立一个关于各种语言的unicode支持的CW。
答案 10 :(得分：2)
我对统计感兴趣 数据和具体情况 国家。
在W3Techs上，我们拥有所有这些数据，但它可能并不容易找到：
例如，您首先选择语言来获取日语网站的字符编码分布：Content Languages＆gt;日语，然后选择Segmentation＆gt;字符编码。这会带您进入此报告：Distribution of character encodings among websites that use Japanese。你看：日本网站使用49％SHIFT-JIS和38％UTF-8。您可以对每个顶级域名执行相同操作，例如所有.jp站点。
答案 11 :(得分：1)
Java和C＃都在内部使用UTF-16，可以轻松转换为其他编码;他们在企业界非常根深蒂固。
我认为现在只接受UTF作为输入并不是那么重要;去吧。
答案 12 :(得分：1)
我对统计感兴趣 数据和具体情况 国家。
我认为这更依赖于问题域及其历史，然后是使用应用程序的国家/地区。
如果您正在构建一个所有竞争对手正在输出的应用程序，例如ISO-8859-1（或过去10年中的大部分时间），我认为您所有（潜在的）客户都希望您能够毫不费力地打开这些文件。
那就是说，我不认为大多数时候仍然需要输出除UTF-8编码文件以外的任何东西。大多数项目都应对这些天，但YMMV再次取决于您的目标市场。