Unicode可移植性

Question

我目前正在处理一个使用std::string和char进行字符串操作的应用程序 - 这在linux上很好，因为Linux与Unicode无关（或者看起来似乎;我真的不知道，所以请纠正我如果我在这里讲故事） 这种当前样式自然会导致这种函数/类声明：

std::string doSomethingFunkyWith(const std::string& thisdata)
{
    /* .... */
}

但是，如果thisdata包含unicode字符，则它将在Windows上显示错误，因为std::string无法在Windows上保存unicode字符。

所以我想到了这个概念：

namespace MyApplication {
#ifdef UNICODE
    typedef std::wstring  string_type;
    typedef wchar_t       char_type;
#else
    typedef std::string   string_type;
    typedef char          char_type;
#endif

    /* ... */
    string_type doSomethingFunkyWith(const string_type& thisdata)
    {
        /* ... */
    }
}

这是一个在Windows上支持Unicode的好概念吗？

我目前的工具链包括Linux上的gcc / clang，以及用于Windows支持的wine + MinGW（如果重要的话，也可以通过wine进行交叉测试）。

Answer 1

如何在应用程序中存储字符串完全取决于您 - 毕竟，只要字符串保留在您的应用程序中，就没有人会知道。 当您尝试从外部世界（控制台，文件，套接字等）读取或写入字符串时，问题就开始了，这就是操作系统的重要性。

Linux是不完全“不可知”到Unicode -它确实认识统一而标准库函数假定UTF-8编码，所以Unicode字符串适合标准char数组。 另一方面，Windows使用UTF-16编码，因此您需要一个wchar_t数组来表示16位字符。

你提出的typedef应该可以正常工作，但请记住，仅凭这一点并不能使你的代码可移植。 例如，如果要以可移植的方式在文件中存储文本，则应选择一种编码并在所有平台上坚持使用 - 这可能需要在某些平台上进行编码之间的转换。

Answer 2

多平台问题来自于存在许多编码的事实，并且错误的编码选择将导致包含ssues。 一旦解决了这个问题，你应该可以在所有程序中使用std::wstring 。

通常的工作流程是：

raw_input_data = read_raw_data()
input_encoding = "???" // What is your file or terminal encoding?

unicode_data = convert_to_unicode(raw_input_data, input_encoding)

// Do something with the unicode_data, store in some var, etc.

output_encoding = "???" // Is your terminal output encoding the same as your input?
raw_output_data = convert_from_unicode(unicode_data, output_encoding)

print_raw_data(raw_data)

大多数Unicode问题来自错误地检测input_encoding和output_encoding的值。 在现代Linux发行版中，这通常是UTF-8。 在Windows YMMV上。

标准C ++不知道编码，你应该使用像ICU这样的库来进行转换。

Answer 3

Linux确实支持Unicode，它只使用UTF-8。 使系统可移植的更好方法可能是使用International Components for Unicode并将所有std::string对象视为包含UTF-8字符，并在调用Windows函数时根据需要将它们转换为UTF-16。 使用UTF-8而不是UTF-16几乎总是有意义的，因为UTF-8对一些最常用的字符（例如英语*）使用较少的空间而对于较不频繁的字符使用更多的空间，而UTF-16同样浪费空间对于所有角色，无论使用频率如何。

虽然您可以使用typedef，但这意味着您必须为每个必须处理字符串的函数编写两个副本。 我认为简单地在UTF-8中进行所有内部计算并在必要时根据需要输入/输出时将其转换为UTF-16或从UTF-16转换为更高效。

*对于使用英语作为编码一部分的HTML，XML和JSON（例如“<html>，<body>等），无论值的语言如何，这仍然可以成为外语的胜利。

Answer 4

Linux和使用Unicode的问题是所有IO和大多数系统函数都使用UTF-8，宽字符类型是32位。 然后是Java和其他需要UTF-16的程序的接口。

有关Unicode支持的建议，请参阅http://code.google.com/p/openrtl上的OpenRTL库，该库支持Windows，Linux，Osx和Ios上的所有UTF-8，UTF-16和UTF-32。 Unicode支持不仅包括字符类型，还包括Unicode排序规则，规范化，大小写折叠，标题大小写以及每个完整无符号32位字符大约64个不同的Unicode字符属性。

现在，OpenRTL代码已准备好支持新的C ++标准的char8_t，char16_t和char32_t，尽管现有的C和C ++编译器使用宏支持相同的字符类型。 我认为对于Unicode和字符串处理来说，它可能是你想要的库。

关键是如果使用OpenRTL，则可以使用OpenRTL“char_t”类型构建系统。 这支持了这样的概念：即使在Linux上，您的整个库也可以以UTF8，UTF16或UTF32模式构建，因为OpenRTL已经处理了许多系统功能（如文件和io）的所有接口。 例如，它有自己的print_f函数。

默认情况下，char_t映射到宽字符类型。 因此在Windows上它是32位而在Linux上它是32位。 但是你也可以让它在任何地方都变成8位。 它还支持使用宏在循环内进行快速UTF解码。

因此，不是在wchar_t和char之间进行ifdeff，而是使用char_t构建所有内容，而OpenRTL负责其余部分。