为什么 C++ 中的宽文件流会这样？默认情况下缩小写入数据？

Question

老实说，我只是没有在 C++ 标准库中得到以下设计决策。将宽字符写入文件时，wofstream 会将 wchar_t 转换为 char 字符：

#include <fstream>
#include <string>

int main()
{
    using namespace std;

    wstring someString = L"Hello StackOverflow!";
    wofstream file(L"Test.txt");

    file << someString; // the output file will consist of ASCII characters!
}

我知道这与标准 有关>编解码器。 提升。此外，还有 马丁约克在这里。问题是为什么标准codecvt转换宽字符？为什么不按原样写人物呢！

另外，我们是否会使用 C++0x 获得真正的 unicode 流 还是我在这里遗漏了一些东西？

Answer 1

第一个问题的非常部分的答案：文件是字节序列，因此，在处理wchar_t时，至少一些转换必须出现在 wchar_t 和 char 之间。 “智能”地进行此转换需要了解字符编码，因此这就是为什么通过在流的区域设置中使用切面，允许此转换与区域设置相关的原因。

然后，问题是如何在标准所需的唯一语言环境中进行转换：“经典”语言环境。对此没有“正确”的答案，因此标准对此非常模糊。我从你的问题中了解到，你认为在 wchar_t[] 和 char[] 之间盲目转换（或 memcpy()-ing）将是一个好方法。这并非不合理，而且实际上在某些实现中就是（或至少是）所做的。

另一个观点是，由于 codecvt 是一个语言环境方面，因此可以合理地期望使用“语言环境的编码”进行转换（我在这里很犹豫，因为这个概念非常模糊）。例如，人们希望土耳其语言环境使用 ISO-8859-9，或者希望日语语言环境使用 Shift JIS。通过相似性，“经典”语言环境将转换为该“语言环境的编码”。显然，微软选择简单地修剪（如果我们假设 wchar_t 代表 UTF-16 并且我们停留在基本的多语言平面上，这会导致 IS-8859-1），而我所知道的 Linux 实现决定坚持使用 ASCII。

对于你的第二个问题：

另外，我们是否会使用 C++0x 获得真正的 unicode 流，还是我在这里遗漏了一些东西？

在 n2857（我手头最新的 C++0x 草案）的 [locale.codecvt] 部分中，可以读到：

专业化 codecvt 在 UTF-16 和 UTF-8 编码方案之间进行转换，专业化 codecvt codecvt code> 在 UTF-32 和 UTF-8 编码方案之间进行转换。 codecvt 在窄字符和宽字符的本机字符集之间进行转换。

在 [locale.stdcvt] 部分中，我们发现：

对于方面codecvt_utf8：
— 方面应在程序内的 UTF-8 多字节序列和 UCS2 或 UCS4（取决于 Elem 的大小）之间进行转换。
[...]

对于方面codecvt_utf16：
— 方面应在程序内的 UTF-16 多字节序列和 UCS2 或 UCS4（取决于 Elem 的大小）之间进行转换。
[...]

对于方面codecvt_utf8_utf16：
— Facet 应在程序内的 UTF-8 多字节序列和 UTF-16（一个或两个 16 位代码）之间进行转换。

所以我猜这意味着“是”，但是您必须更准确地了解“真正的 unicode 流”的含义才能确定。

Answer 2

C++ 使用的字符集模型继承自 C，因此至少可以追溯到 1989 年。

有两个要点：

• IO 是根据字符完成的。
• 区域设置的工作是确定序列化字符的宽度
• 默认区域设置（名为“C”）非常小（我不记得标准的限制，这里它只能处理 7 位 ASCII窄字符集和宽字符集）。
• 有一个环境确定的区域设置名为“”，

因此要获取任何内容，您必须设置区域设置。

简单程序

#include <locale>
#include <fstream>
#include <ostream>
#include <iostream>

int main()
{
    wchar_t c = 0x00FF;
    std::locale::global(std::locale(""));
    std::wofstream os("test.dat");
    os << c << std::endl;
    if (!os) {
        std::cout << "Output failed\n";
    }
}

如果我使用使用环境区域设置并将代码 0x00FF 的宽字符输出到文件的 。如果我要求使用“C”语言环境，我会得到

$ env LC_ALL=C ./a.out
Output failed

该语言环境无法处理宽字符，并且我们会收到有关该问题的通知，因为 IO 失败。如果我运行询问 UTF-8 语言环境，我会得到

$ env LC_ALL=en_US.utf8 ./a.out
$ od -t x1 test.dat
0000000 c3 bf 0a
0000003

（od -t x1 只是转储以十六进制表示的文件），这正是我对 UTF-8 编码文件的期望。

Answer 3

我不知道wofstream。但 C++0x 将包含保证宽度和符号（无符号）的新离散字符类型（char16_t、char32_t），可移植用于 UTF-8、UTF-16 和 UTF-32。此外，还将有新的字符串文字（例如，u"Hello!" 表示 UTF-16 编码的字符串文字）

查看最新的 C++0x 草案 (N2960)。

Answer 4

对于你的第一个问题，这是我的猜测。

IOStreams 库是在几个有关编码的前提下构建的。例如，对于 Unicode 和其他不常见的编码之间的转换，假设是这样的。

• 在您的程序中，您应该使用（固定宽度）宽字符编码。
• 只有外部存储才应使用（可变宽度）多字节编码。

我相信这就是 std::codecvt 的两个模板专业化存在的原因。一种在 char 类型之间映射（也许您只是使用 ASCII），另一种在 wchar_t（程序内部）和 char（外部设备）之间映射。因此，每当您需要执行到多字节编码的转换时，您应该逐字节进行。请注意，当您从多字节编码读取/写入每个字节时，您可以编写一个处理编码状态的方面。

以这种方式思考 C++ 标准的行为是可以理解的。毕竟，您使用的是宽字符 ASCII 编码（假设这是您平台上的默认设置并且您没有切换区域设置）字符串。 “自然”转换是将每个宽字符 ASCII 字符转换为普通（在本例中为一个字符）ASCII 字符。 （转换存在并且很简单。）

顺便说一句，我不确定您是否知道，但您可以通过创建一个为转换返回 noconv 的方面来避免这种情况。然后，您的文件将包含宽字符。

Answer 5

看看这个：
Class basic_filebuf

您可以更改默认值通过使用 pubsetbuf 设置宽字符缓冲区来实现行为。
一旦你这样做了，输出将是 wchar_t 而不是 char。

换句话说，对于您的示例，您将拥有：

wofstream file(L"Test.txt", ios_base::binary); //binary is important to set!  
wchar_t buffer[128];  
file.rdbuf()->pubsetbuf(buffer, 128);  
file.put(0xFEFF); //this is the BOM flag, UTF16 needs this, but mirosoft's UNICODE doesn't, so you can skip this line, if any.  
file << someString; // the output file will consist of unicode characters! without the call to pubsetbuf, the out file will be ANSI (current regional settings)