UTF-16应该被认为有害吗？

#1 楼

这是一个旧答案。
有关最新更新，请参见UTF-8。


意见：是的，应该将UTF-16视为有害。它存在的根本原因是因为一段时间以前，人们曾经误导了Widechar将成为现在的UCS-4。它应被视为唯一有用的文本编码。可以认为，程序，网页和XML文件，OS文件名以及其他计算机对计算机文本接口的源代码应该永远都不存在。但是，当这样做的时候，文本不仅适合人类读者。

另一方面，UTF-8开销是一笔不小的代价，同时具有明显的优势。诸如与仅通过char*传递字符串的无意识代码兼容的优点。这是一件了不起的事。与UTF-8中相比，UTF-16中的SHORTER有用的字符很少。

我相信所有其他编码最终都会消失。这涉及到MS-Windows，Java，ICU，python停止使用它们作为收藏夹。经过长期的研究和讨论，我公司的开发约定禁止在OS API调用之外的任何地方使用UTF-16，尽管这对我们的应用程序中性能的重要性以及我们使用Windows的事实也是如此。开发转换函数是为了将始终假定的UTF8 std::string转换为Windows本身不正确支持的本机UTF-16。说：在所有地方使用相同的编码有很大的优势，我认为没有足够的理由这样做。特别是，我认为将wchar_t添加到C ++中是一个错误，对C ++ 0x的Unicode添加也是如此。但是，STL实现必须要求将每个std::string或char*参数都视为与unicode兼容。

我也反对“使用您想要的”方法。我认为没有这种自由的理由。文本主题上有足够的混乱，导致所有这些损坏的软件。综上所述，我坚信程序员必须最终就UTF-8达成共识，这是一种正确的方法。 （我来自一个不讲阿拉伯语的国家，并且在Windows上长大，所以我最后一次基于宗教理由会攻击UTF-16。）

我想分享更多有关如何在Windows上执行文本以及为编译时检查的unicode正确性，易用性和更好的多平台性向其他所有人的推荐的信息。该建议与通常推荐的在Windows上使用Unicode的正确方法大不相同。然而，对这些建议的深入研究得出了相同的结论。这样就可以：


不要在接受UTF-16的API的相邻点以外的任何地方使用wchar_t或std::wstring。
请勿使用_T("")或L"" UTF-16文字（作为UTF-16弃用的一部分，应将IMO从标准中删除）。
请勿使用类型，函数或其派生类。对_UNICODE常数敏感的变量，例如LPTSTR或CreateWindow()。
但是，始终定义_UNICODE，以避免将char*字符串传递给WinAPI进行静默编译。

std::strings和char*被认为在程序中的任何地方UTF-8（如果未另外说明）
尽管您可以将char *或字符串文字传递给std::string，但我所有的字符串都是convert(const std::string &)。绝不要接受LPWSTR或LPTSTR的那些。以这种方式传递参数：

::SetWindowTextW(Utils::convert(someStdString or "string litteral").c_str())

（该策略使用下面的转换函数。）


使用MFC字符串：

CString someoneElse; // something that arrived from MFC. Converted as soon as possible, before passing any further away from the API call:

std::string s = str(boost::format("Hello %s\n") % Convert(someoneElse));
AfxMessageBox(MfcUtils::Convert(s), _T("Error"), MB_OK);

在Windows上使用文件，文件名和fstream：


切勿将LPSTR或std::string文件名参数传递给const char*系列。 MSVC STL不支持UTF-8参数，但具有非标准扩展名，应按以下方式使用： br />
当MSVC对fstream的态度发生变化时，我们将必须手动删除转换。

此代码不是多平台的，将来可能需要手动更改
有关详细信息，请参阅std::string Unicode研究/讨论案例4215。如有必要，请使用上述std::wstring和WinAPI约定。

std::ifstream ifs(Utils::Convert("hello"),
                  std::ios_base::in |
                  std::ios_base::binary);

#2 楼

Unicode代码点不是字符！有时它们甚至都不是字形（视觉形式）。 （一个看起来像“ iii”的单个字符。）
像“á”这样的带重音符号的字符可以表示为单个组合字符“ \ u00e1”，也可以表示为字符和分隔的变音符号“ \ u0061 \ u0301”。
像希腊小写字母sigma这样的字符，其单词位置的中间（“σ”）和结尾（“ς”）具有不同的形式，但应将其视为搜索的同义词。
Unicode任意连字符U + 00AD，它可能会或可能不会在视觉上显示出来（取决于上下文），并且在语义搜索中会被忽略。成为专家，自己写一个。如果您只是在计数代码点，那您就处于犯罪状态。

#3 楼

使用哪种Unicode转换形式（UTF）有一个简单的经验法则：
-utf-8用于存储和通信
-utf-16用于数据处理
-您可能会喜欢utf-32（如果您使用的大多数平台API是utf-32（在UNIX世界中很常见）。）

当今大多数系统都使用utf-16（Windows，Mac OS，Java，.NET，ICU） ，Qt）。
也请参见此文档：http://unicode.org/notes/tn12/

回到“ UTF-16有害”，我会说：绝对不是。

害怕代理人的人（认为他们将Unicode转换为可变长度编码）不理解其他（更大的）复杂性，这些复杂性使得字符和Unicode代码点之间的映射非常复杂：结合字符，连字，变体选择器，控制字符等。

只需在此处阅读本系列文章http://www.siao2.com/2009/06/29/9800913.aspx并查看UTF如何-16变成一个简单的问题。

#4 楼

是的，绝对。

为什么？

如果您查看汤姆·克里斯蒂安森（Tom Christiansen）大型语料库上的这些代码点使用情况统计信息，您会发现跨8位BMP代码点的使用量要高出几个级别。 -BMP代码点：

 2663710 U+002013 ‹–›  GC=Pd    EN DASH
 1065594 U+0000A0 ‹ ›  GC=Zs    NO-BREAK SPACE
 1009762 U+0000B1 ‹±›  GC=Sm    PLUS-MINUS SIGN
  784139 U+002212 ‹−›  GC=Sm    MINUS SIGN
  602377 U+002003 ‹ ›  GC=Zs    EM SPACE

 544 U+01D49E ‹𝒞›  GC=Lu    MATHEMATICAL SCRIPT CAPITAL C
 450 U+01D4AF ‹𝒯›  GC=Lu    MATHEMATICAL SCRIPT CAPITAL T
 385 U+01D4AE ‹𝒮›  GC=Lu    MATHEMATICAL SCRIPT CAPITAL S
 292 U+01D49F ‹𝒟›  GC=Lu    MATHEMATICAL SCRIPT CAPITAL D
 285 U+01D4B3 ‹𝒳›  GC=Lu    MATHEMATICAL SCRIPT CAPITAL X

采用TDD格言：“未经测试的代码已损坏代码”，并将其改写为“未执行的代码已损坏代码”，并考虑使用频率程序员必须处理非BMP代码点。

与不处理UTF-16有关的错误比起UTF-8中的等效错误，更容易引起人们的注意。某些编程语言仍然不能保证为您提供UTF-16而不是UCS-2，并且某些所谓的高级编程语言提供对代码单元而不是代码点的访问（甚至C也应允许您访问代码点（如果您使用wchar_t，则不管某些平台可能做什么）。

#5 楼

我建议认为UTF-16可能被认为有害，这意味着您需要对Unicode有了更深入的了解。 。您对UTF-16的困扰到底是什么？您是否希望所有内容都以UTF-8编码？ UTF-7？还是UCS-4呢？当然，某些应用程序并非旨在处理其中的每个字符代码，但是它们对于在国际边界之间进行通信是必需的，尤其是在当今的全球信息领域。

但是，如果您觉得UTF-16，应该被认为是有害的，因为它令人困惑或可能被不正确地实现（当然可以使用unicode），那么什么字符编码方法将被认为是无害的？标准反映了标准本身的质量？正如其他人随后指出的那样，仅仅是因为应用程序不当使用工具，并不意味着该工具本身就有缺陷。如果是这种情况，我们可能会说诸如“认为var关键字有害”或“认为线程有害”之类的内容。我认为这个问题使标准的质量和性质与许多程序员在正确实施和使用它时遇到的困难混淆了，我觉得这更多是由于他们缺乏对unicode的工作原理而不是unicode本身的理解。

#6 楼

Utf-16编码没有问题。但是，将16位单元视为字符的语言可能应该被认为设计错误。具有不总是代表字符的名为“ char”的类型非常令人困惑。由于大多数开发人员都希望char类型表示一个代码点或字符，因此当暴露于BMP以外的字符时，很多代码可能会中断。位代码点将始终代表一个字符。由于组合了字符，实际字符可能包含几个代码点。 Unicode从来都不是小事。

顺便说一句。平台和应用程序可能存在同一类错误，它们期望字符为8位，并由Utf-8提供。

#7 楼

我个人的选择是始终使用UTF-8。这是Linux几乎所有内容的标准。它与许多旧版应用程序向后兼容。与其他UTF格式相比，用于非拉丁字符的额外空间的开销非常小，并且大大节省了拉丁字符的空间。在网络上，拉丁语言占主导地位，我认为它们将在可预见的将来。为了解决原始帖子中的一个主要论点：几乎每个程序员都知道UTF-8有时会包含多字节字符。并不是每个人都正确地处理了这个问题，但是他们通常都知道，这远远超过了UTF-16的说法。但是，当然，您需要选择一种最适合您的应用程序。这就是为什么首先要有多个的原因。

评论

---

UTF-16对于BMP内部的任何内容都更简单，这就是为什么它被如此广泛地使用。但是我也是UTF-8的粉丝，它在字节顺序方面也没有问题，这对它的优势很有用。

–马尔科姆
09-6-26 at 16:57

---

从理论上讲，是的。实际上，存在诸如UTF-16BE之类的东西，这意味着大尾数中的UTF-16没有BOM。这不是我整理的，这是ID3v2.4标签允许的实际编码（ID3v2标签很烂，但是不幸的是，被广泛使用）。在这种情况下，您必须在外部定义字节顺序，因为文本本身不包含BOM。 UTF-8始终以一种方式编写，它没有这样的问题。

–马尔科姆
2010-4-2 15:33

---

不，UTF-16并不简单。很难。它误导并欺骗您以为它是固定宽度的。所有此类代码都已损坏，更重要的是，您要等到为时已晚才注意到。案例要点：昨天我在Java核心库中发现了另一个愚蠢的UTF-16错误，这次是在String.equalsIgnoreCase中，该错误留在了UCS-2的大脑缺陷中，因此在16/17有效的Unicode代码点上失败了。该代码存在多长时间了？没有借口成为越野车。 UTF-16导致纯粹的愚蠢和等待发生的事故。从UTF-16尖叫。

–基督
2011年8月11日14:42

---

@tchrist必须是一个非常无知的开发人员，才能不知道UTF-16的长度不是固定的。如果您从Wikipedia开始，则将在最上方阅读以下内容：“它产生的可变长度结果是每个代码点一个或两个16位代码单元”。 Unicode常见问题解答也是如此：unicode.org/faq//utf_bom.html#utf16-1。我不知道，如果UTF-16到处都是可变长度的，它怎么会欺骗任何人。至于该方法，它从来都不是为UTF-16设计的，因此不应该被认为是Unicode。

–马尔科姆
11年8月13日在10:30

---

@tchrist您有统计资料的来源吗？尽管如果缺少优秀的程序员，我认为这很好，因为我们变得更有价值。 :)至于Java API，基于char的部分最终可能会被弃用，但这不能保证它们不会被使用。而且出于兼容性考虑，它们绝对不会被删除。

–马尔科姆
11年8月16日在8:29

---

#8 楼

嗯，有一种使用固定大小符号的编码。我当然是指UTF-32。但是每个符号4个字节浪费了太多空间，为什么我们要在日常情况下使用它？不能迅速纠正这种情况。 Opera，Windows，Python，Qt-所有这些都在UTF-16广为人知甚至出现之前就出现了。我可以确认，但是，在Opera，Windows资源管理器和记事本中，BMP之外的字符不再存在问题（至少在我的PC上）。但是无论如何，如果程序无法识别代理对，那么它们就不会使用UTF-16。处理此类程序会产生任何问题，但它们与UTF-16本身无关。 BMP之外的字符仅在非常特定的情况和区域才会遇到。根据Unicode官方常见问题解答的说法，“即使在东亚文本中，代理对的发生率也应平均少于所有文本存储的1％”。当然，不应忽略BMP之外的字符，因为否则程序将不符合Unicode，但是大多数程序都不打算用于包含此类字符的文本。这就是为什么如果他们不支持它，那将是令人不快的，但不会造成灾难性后果。如果不存在UTF-16，那么我们将没有一种非常适合非ASCII文本的编码，并且为UCS-2创建的所有软件都必须完全重新设计以保持与Unicode兼容。后者很可能只会减慢Unicode的采用。同样，我们也无法像UTF-8那样相对于ASCII保持与UCS-2中文本的兼容性。

现在，撇开所有遗留问题，反对编码本身的参数是什么？我真的怀疑现在的开发人员不知道UTF-16是可变长度的，它随处可见，写在Wikipedia上。如果有人指出复杂性是一个可能的问题，那么与UTF-8相比，UTF-16的解析难度要小得多。认为仅在UTF-16中确定字符串长度很容易搞乱也是错误的。如果您使用UTF-8或UTF-32，则仍应注意，一个Unicode代码点不一定表示一个字符。除此之外，我认为编码没有任何实质性的内容。

因此，我不认为编码本身就是有害的。 UTF-16是简单性和紧凑性之间的折衷方案，在需要的地方使用所需的东西没有任何危害。在某些情况下，您需要保持与ASCII的兼容性，并且需要UTF-8；在某些情况下，您需要使用Han表意文字，并使用UTF-16节省空间；在某些情况下，您需要通用字符表示形式，长度编码。使用更合适的方法，然后正确执行即可。

#9 楼

多年的Windows国际化工作，尤其是在东亚语言中，可能使我败坏了，但是我倾向于使用UTF-16来表示程序内部的字符串，而倾向于使用UTF-8来存储类似明文的文档的网络或文件。但是，通常可以在Windows上更快地处理UTF-16，这就是在Windows中使用UTF-16的主要好处。文本。只有少数几种情况需要考虑代理对（基本上是删除，插入和换行），平均情况主要是直通。与JIS变体之类的早期编码不同，UTF-16将代理对限制在非常窄的范围内，因此检查确实非常快捷，并且可以向前和向后进行。 UTF-8也是如此。但是，还有许多损坏的UTF-8应用程序将代理对错误地编码为两个UTF-8序列。因此，UTF-8也不能保证得到挽救。

自2000年左右以来，IE可以很好地处理代理对，即使它通常将其从UTF-8页面转换为内部UTF-16表示形式也是如此。我相当确定Firefox也可以正确使用，因此我不太在意Opera的功能。

UTF-32（又名UCS4）对大多数应用程序毫无意义，因为它对空间的要求很高，因此几乎是一个入门者。

#10 楼

UTF-8绝对是必经之路，可能需要在需要高性能随机访问的算法内部使用UTF-32（但忽略组合字符）。 32（以及它们的LE / BE变体）存在字节性问题，因此切勿在外部使用它们。

#11 楼

UTF-16？绝对有害。这只是我的事，但是程序中确实有三种可接受的文本编码：


ASCII：当处理不能处理的低级内容（例如微控制器）时< brafford更好的方法
UTF8：存储在文件等固定宽度的介质中
整数代码点（“ CP”？）：方便编程的最大整数数组语言和平台（在低分辨率的范围内衰减为ASCII）。在较旧的计算机上应为int32，在具有64位
寻址的任何计算机上应为int64。
显然，与旧代码的接口使用了使旧代码正常工作所需的编码。

#12 楼

Unicode定义的代码点最大为0x10FFFF（1,114,112个代码），所有在多语言环境中运行的处理字符串/文件名等的应用程序都应正确处理。

utf-16：仅涵盖1,112,064个代码。尽管Unicode末尾的内容来自15-16平面（专用区域）。除了打破Utf-16的概念，它在未来无法进一步发展。

Utf-8：理论上涵盖了2,216,757,376个代码。 Unicode代码的当前范围可以由最多4个字节的序列表示。它不存在字节顺序问题，它与ascii“兼容”。Utf-32：理论上涵盖2 ^ 32 = 4,294,967,296个代码。目前，它不是可变长度编码的，可能将来也不会。

这些事实是不言而喻的。我不赞成提倡使用Utf-16。它是可变长度编码的（无法通过索引访问），即使在目前也存在覆盖整个Unicode范围的问题，必须处理字节顺序等。我看不到任何优势，除了它在Windows和其他操作系统中本地使用其他地方。即使在编写多平台代码时，最好原生使用Utf-8并仅以依赖于平台的方式在端点进行转换（如已建议的那样）。当必须通过索引直接访问并且内存不是问题时，应使用Utf-32。

主要问题是许多处理Windows Unicode = Utf-16的程序员甚至都不知道或忽略它是可变长度编码的事实。

它在* nix平台中通常使用的方式非常好，c字符串（char *）解释为Utf-8编码，宽c字符串（wchar_t *）解释为Utf-32。

#13 楼

将其添加到列表中：


呈现的场景很简单（我将在这里展示它比起原来的更加简单！）：
1。 WinForms文本框位于窗体上，为空。它的MaxLength设置为20。

2.用户在TextBox中键入文本，或者将文本粘贴到其中。

3.无论您键入或粘贴什么内容在TextBox中，您只能使用20个字符，尽管它会同情地在20个字符之外发出提示音（此处是YMMV
；我更改了音效以达到那种效果！）。

4。然后将一小包文本发送到其他地方，以开始令人兴奋的冒险。

现在，这是一个简单的方案，任何人都可以
在业余时间写下来。我只是使用WinForms用多种编程语言自己编写了代码，因为我很无聊，并且以前从未尝试过。并使用多种实际语言的文本
，因为我采用这种方式接线，并且键盘布局要比整个怪异世界中的任何人都要多。

我什至将
命名为Magic Carpet Ride，以帮助缓解这种无聊感。

这没有用，因为它值得。

因此，我改为在我的“魔毯骑行”表单中输入以下20个
字符：

嗯。

最后一个字符是U + 20000，这是Unicode的第一个扩展B
表意符号（又名U + d840 U + dc00，对于他的亲密朋友来说，他并不感到羞耻...）。



现在我们有了一个球类游戏。

因为TextBox.MaxLength谈论
关于

获取或设置可以手动输入到文本框中的最大字符数。

真正的意思是

获取或设置
可以在文本框中手动输入的最大UTF-16 LE代码单元数，
将无情地截断生活
从试图用
玩可爱游戏的任何字符串中剔除掉语言字符的概念是，只有如此痴迷的人会感到反感（天才，他需要进一步努力！）。

我将尝试了解如何对文档进行更新。 ...
经常记住我的UCS-2至UTF-16系列的读者会注意到我的
不满意，它带有TextBox.MaxLength的简单概念以及它应该如何处理在这种情况下，其苛刻的行为
创建了一个非法序列，.NET
框架的其他部分可能会抛出一个非法序列。 ：无法
将索引0处的Unicode字符\ uD850转换为指定的代码
页面。*

如果将此字符串传递到.Net的其他地方，则为例外
Framew ork（就像我的同事Dan Thompson所做的那样）。

现在好了，
也许从许多UCS-2到UTF-16的完整系列都无法实现。
但是，期望TextBox.Text是不合理的不会产生不会导致.Net Framework的另一部分抛出
的
System.String？我的意思是，这并不是像控件上的某些
事件形式会告诉您即将出现的截断，您可以在其中轻松地添加更智能的验证-验证<控件本身并不介意这样做。我什至可以说，
如果您可以分类导致意外的异常，从而导致应用程序
终止，则该朋克控件将破坏甚至可能导致安全问题的安全契约。拒绝服务。为什么
任何WinForms进程，方法，算法或技术
都将产生无效结果？


来源：Michael S. Kaplan MSDN博客

评论

---

谢谢，很好的链接！我已将其添加到问题的问题列表中。

– Artyom
2010-12-21在6:28

---

#14 楼

我不一定要说UTF-16是有害的。它虽然不优雅，但其目的是与UCS-2向后兼容，就像GB18030与GB2312和UTF-8与ASCII一样。

但是对Unicode的结构进行了根本性的改变在中间阶段，在Microsoft和Sun建立了围绕16位字符的巨大API之后，这是有害的。未能传播对变更的认识更加有害。

#15 楼

UTF-16是处理和空间之间的最佳折衷方案，这就是为什么大多数主要平台（Win32，Java，.NET）都将UTF-16用于内部字符串表示。

#16 楼

我从来不了解UTF-16的要点。如果您想要最节省空间的表示形式，请使用UTF-8。如果希望能够将文本视为固定长度，请使用UTF-32。如果您都不想要，请使用UTF-16。更糟糕的是，由于UTF-16中的所有常见（基本多语言平面）字符都位于单个代码点中，因此假设UTF-16是固定长度的错误将很难发现，而如果您尝试这样做，使用UTF-8时，一旦您尝试进行国际化，您的代码就会快速响亮。

#17 楼

由于无法发表评论，因此将其发布为答案，因为似乎无法以其他方式联系utf8everywhere.org的作者。可惜我没有自动获得评论特权，因为我在其他stackexchanges上有足够的声誉。
这是对意见的评论：是的，应该将UTF-16视为有害答案。
一项更正：
为防止将UTF-8 char*意外传递到Windows API API函数的ANSI字符串版本中，应定义UNICODE而不是_UNICODE。 _UNICODE映射类似_tcslen到wcslen的函数，而不是MessageBox到MessageBoxW的函数。而是由UNICODE定义处理后者。
为证明起见，此消息来自MS Visual Studio 2005的WinUser.h标头：
一个建议：
也许指南应该包含一个显式使用数据结构的宽字符串版本的示例，以减少丢失/忘记它的难度。在使用函数的宽字符串版本的基础上再使用宽字符串版本的数据结构，可以减少意外调用此类函数的ANSI字符串版本的可能性。
示例示例：

#ifdef UNICODE
#define MessageBox  MessageBoxW
#else
#define MessageBox  MessageBoxA
#endif // !UNICODE

#18 楼

有人说UCS4和UTF-32是相同的。不，但是我知道你的意思。不过，其中之一是另一种的编码。我希望他们从一开始就考虑指定字节序，这样我们就不会在这里进行字节序之争。他们难道没有看到那件事吗？至少所有地方的UTF-8都是一样的（除非有人遵循原始的6字节规范）。

如果使用UTF-16，则必须包括对多字节字符的处理。您无法通过将2N索引到字节数组中来进入第N个字符。您必须步行，或具有字符索引。否则，您可能会写一个错误。

当前的C ++规范草案指出UTF-32和UTF-16可以具有little-endian，big-endian和未指定的变体。真？如果Unicode规定每个人都必须从一开始就做小尾数法，那么这将变得更加简单。 （使用big-endian也会很好。）相反，有些人以一种方式实现了它，而另一些则以另一种方式实现了，现在我们陷入了无聊的愚蠢之中。有时候成为一名软件工程师会很尴尬。

#19 楼

如果开发人员足够小心，我认为这没有什么害处。
如果他们也很了解，他们应该接受这种折衷。

作为一名日本软件开发人员，我发现UCS-2足够大，并且限制空间显然简化了逻辑并减少了运行时内存，因此在UCS-2限制下使用utf-16就足够了。

有些文件系统或其他应用程序假定代码点和字节成比例，因此可以确保原始代码点号适合某些固定大小的存储。

一个示例是NTFS和VFAT，它们将UCS-2指定为其文件名存储编码。

如果这些示例确实想要扩展以支持UCS-4，无论如何我都同意使用utf-8，但是固定长度具有以下优点： />可以按长度保证大小（数据大小和代码点长度成比例）
可以使用编码号进行哈希查找
非压缩数据的大小合理（与utf-32 / UCS-4相比） ）

将来，即使在任何嵌入式设备中，内存/处理能力仍然很便宜，我们可能会接受该设备因缓存丢失或页面错误以及内存使用量过慢而有点慢，但这不会发生我想在不久的将来...

#20 楼

“应该认为最流行的编码之一UTF-16是有害的吗？”


很有可能，但是替代方法不一定被认为是更好的方法。

基本问题是关于字形，字符，代码点和字节序列有许多不同的概念。即使在归一化库的帮助下，它们之间的映射也不是简单的。 （例如，某些欧洲语言的字符是使用基于拉丁语的脚本编写的，而不是使用单个Unicode代码点编写的。这只是复杂性的简单体现！）这意味着使所有内容正确无比是非常令人惊讶的难;可以预料到会有奇怪的错误（而不是在这里抱怨，而是告诉相关软件的维护者）。

唯一的方法可以认为UTF-16有害而不是也就是说，UTF-8的编码方式不同于BMP（作为一对代理），它具有不同的编码方式。如果代码希望按代码点进行访问或迭代，则意味着它需要意识到它们之间的区别。 OTOH确实意味着，假设“字符”的现有代码主体可以始终装入两个字节的数量中（一个相当普遍的假设，如果错误的话，假设）至少可以继续工作而无需重新构建所有代码。换句话说，至少您会看到那些处理不正确的字符！每个人都应该使用8位编码，除非我看到（过去20年来）会导致以下问题：各种ISO 8859编码，用于西里尔字母的整个编码集以及EBCDIC套件都令人震惊，而且…嗯，Unicode的所有缺点都胜过了。如果不是在不同国家的误解之间做出如此令人讨厌的妥协。