【问题标题】：performance Encoding UTF 8/16 handling Char[] /char* / std::string / BSTR性能编码 UTF 8/16 处理 Char[] /char* / std::string / BSTR
【发布时间】：2016-01-21 11:29:21
【问题描述】：

快速介绍：问题是关于 UTF-8 与 UTF-16。

*我已尽我所能保持简短和具体，请多多包涵。

我知道特定问题UTF-8/16 有无数种变体，没有提到全局编码主题，这是我提问的开始（ANSI vs UNICODE），我想这不仅仅是*我的*任务，因为它可以为许多其他（以性能为导向的）c++ 初学者提供服务。

更具体 - 切中要害：

给出以下环境参数：

WINDOWS平台
C++ 和 C#
使用一些英语 /俄语/希伯来语

*让我们说这是一个常数。

我可以使用 UTF-8（UTF-16 的一半大小）并“摆脱它”吗？

...节省空间和时间

TLDR 我最近开始使用C++，在过去的几天里，我试图决定如何处理字符串，这是要处理的最昂贵的数据类型之一，我几乎关注了所有关于编码问题的著名和不太著名的文章，虽然我越想继续搜索，我就越困惑，关于兼容性，同时保持高性能应用程序不跨越 *framework 的边界

尽管我计划通过Native c++ 完成大部分I/O，但我使用了术语框架我可以使用 UTF-8 吗？我想要UTF-8吗，我知道一件事！

windows 'blood' 类型是 UTF-16，虽然我认为 Low Level I/O 和 HTTP 使用/默认/首选/受益于 UTF-8

但是我在 Windows 上并且仍在使用 .NET

我可以使用什么来最大化我的应用程序性能，查询操作保存到数据库...

a point 我读过一个不太出名的[article]

【问题讨论】：

UTF-8 可能会节省英文文本的空间，但对于俄语或希伯来语肯定不行。您的程序中最好的部分很大程度上取决于您想要做什么。如果有一个万能的，每个人都会使用它，而你不必问。此外，如果您想与铁杆 C++ 编码员交朋友，则不应使用“非托管 C++”一词（糟糕！）。该语言只是 C++，或者可能是 native C++。
你的数据库是说 UFT-8 还是 UTF-16 还是两者都说？
@Surt 我使用 'SqlServer 2012' default language=English，主要设置为 'Hebrew_100_CI_AI' ，从未检查过 Unicode 问题
@BoPersson 抱歉，我担心 vc++ 冲突，请处理它（：

标签： c# c++ performance utf-8 character-encoding

【解决方案1】：

一点研究

这是我为回答您的问题所做的研究汇编：

Unicode 中的希伯来文和西里尔文

根据维基百科，Unicode 希伯来语块从 U+0590 延伸到 U+05FF，从 U+FB1D 延伸到 U+FB4F（我不知道比例）： https://en.wikipedia.org/wiki/Unicode_and_HTML_for_the_Hebrew_alphabet

根据维基百科，西里尔字母可以在以下区块中找到：U+0400–U+04FF、U+0500–U+052F、U+2DE0–U+2DFF、U+A640–U+A69F , U+1D2B, U+1D78, U+FE2E–U+FE2F https://en.wikipedia.org/wiki/Cyrillic_script_in_Unicode

UTF-8 与 UTF-16

UTF-16 可以用两个字节表示以下字形：U+0000 到 U+D7FF 和 U+E000 到 U+FFFF，这意味着上面的所有字符都将用两个字节表示（Windows 上的 wchar_t）。

为了表示 Herbew 和 Cyrillic，UTF-8 总是需要至少两个字节，并且可能需要三个：

U+0000 - U+007F : 1 个字节
U+0080 - U+07FF : 2 个字节
U+0800 - U+FFFF : 3 个字节

窗口

您自己说过：Windows 的 DNA 是 UTF-16。不管有什么妄想的网站声称，WinAPI 都不会更改为 UTF-8，因为从 Microsoft 的角度来看这是没有意义的（为了让 Linux 爱好者开心而破坏与以前 Windows 应用程序的兼容性？真的吗？）。

当您在 Windows 下开发时，所有 Unicode 都将针对 UTF-16 进行优化/设计。

即使 WinAPI 中的“char”API 也只是一个包装器，它会在调用 UTF-16 之前将您的 char 字符串转换为 wchar_t 字符串，无论如何您都应该直接调用。

测试！

由于您的问题似乎主要是 I/O，您应该尝试使用示例数据来查看读取/写入/发送/接收 UTF-16 与 UTF-8 之间是否存在有意义的差异。

结论

从以上所有事实来看，我看到要么是 UTF-8 和 UTF-16（俄语和西里尔字符形）(*) 之间的中立选择，要么是导致 UTF-16（Windows）的选择。

所以，除非您的测试表明，否则我自己的结论是在 Windows 上坚持使用 UTF-16。

^{(*) 您可以对您使用的所有语言中的几个字符串进行抽样，并尝试统计最常用字符的平均值。}

奖金？

现在，我将避免在 Windows 上直接使用 wchar_t。

相反，我会使用 Windows 提供的 _T()、TCHAR 和 <tchar.h> 宏/typedef/include 机制：只定义了一些宏（UNICODE 和 _UNICODE，如果有记忆的话），如除了一些智能重载，您还可以：

在 Windows 上使用 wchar_t 和 utf-16
在 Linux 上使用 utf-8

如果您切换到另一个操作系统，这将使您的代码更具可移植性。

【讨论】：

我想我忘了谢谢你，忽略了任何回复......对那个 paercebal 很抱歉，因为我想检查你所说的一切，因为并非所有内容都有意义......（ 8char*，&wchar_t，直到我接近加载除英语之外的任何其他内容......然后能够真正触摸到这个，在我的“下一章”——I/O，非常感谢博尔赫斯先生！

【解决方案2】：

请阅读这篇文章

http://www.joelonsoftware.com/articles/Unicode.html

请仔细阅读。

现在关于性能，我非常怀疑您是否会看到任何差异。你根据你的程序应该做什么来选择你的编码。

它应该与其他程序通信吗？

您是否将信息存储在数据库中以供其他人访问？

在决定使用哪种编码时，性能和磁盘空间并不是您的首要任务。

【讨论】：