wprintf 输出可以在 Windows 上正确重定向到 UTF-16 吗？答案

【问题标题】：Can wprintf output be properly redirected to UTF-16 on Windows?wprintf 输出可以在 Windows 上正确重定向到 UTF-16 吗？
【发布时间】：2015-11-05 10:45:23
【问题描述】：

在 C 程序中，我使用 wprintf 在 Windows 控制台中打印 Unicode (UTF-16) 文本。这工作正常，但是当程序的输出被重定向到日志文件时，日志文件的 UTF-16 编码已损坏。在 Windows 命令提示符中完成重定向时，所有换行符都被编码为窄 ASCII 换行符 (0d0a)。在 PowerShell 中完成重定向时，会插入空字符。

是否可以将输出重定向到正确的 UTF-16 日志文件？

示例程序：

#include <stdio.h>
#include <windows.h>
#include <fcntl.h>
#include <io.h>

int main () {

  int prevmode;

  prevmode = _setmode(_fileno(stdout), _O_U16TEXT);
  fwprintf(stdout,L"one\n");
  fwprintf(stdout,L"two\n");
  fwprintf(stdout,L"three\n");
  _setmode(_fileno(stdout), prevmode);


  return 0;
}

在命令提示符中重定向输出。查看 0d0a 应该是 0d00 0a00：

c:\test>.\testu16.exe > o.txt

c:\test>xxd o.txt
0000000: 6f00 6e00 6500 0d0a 0074 0077 006f 000d  o.n.e....t.w.o..
0000010: 0a00 7400 6800 7200 6500 6500 0d0a 00    ..t.h.r.e.e....

在 PowerShell 中重定向输出。查看所有插入的 0000。

PS C:\test> .\testu16.exe > p.txt
PS C:\test> xxd p.txt
0000000: fffe 6f00 0000 6e00 0000 6500 0000 0d00  ..o...n...e.....
0000010: 0a00 0000 7400 0000 7700 0000 6f00 0000  ....t...w...o...
0000020: 0d00 0a00 0000 7400 0000 6800 0000 7200  ......t...h...r.
0000030: 0000 6500 0000 6500 0000 0d00 0a00 0000  ..e...e.........
0000040: 0d00 0a00                                ....

【问题讨论】：

显然第一个示例中的错误是L"\n" 的输出为0D 0A 00 而不是0D 00 0A 00。不知道第二个示例中的问题是什么；它看起来有点像 UTF-32，除了 BOM 和换行符。嗯。
@MrLister 如果是这种情况，那么这将是一个编译器错误。您必须检查二进制文件才能确定。 OP，你用的是什么编译器？
Hans Passant 昨天给出了正确答案，但他的答案被删除了。 Hans Passant，如果你转发你的答案，我会给你赏金。如果没有，我会发布你的答案。
@coladict，我使用的是 mingw-w64 和 Visual Studio 2013。两者的结果相同。
@MrLister，第二个例子是双重编码的 UTF-16。 PowerShell 修改流。请参阅下面的答案。

标签： redirect encoding utf-16

【解决方案1】：

">" 将始终将您的控制台 UTF16 重定向为可打印的“ASCII”，即使您在输出中放置了 BOM 或使用 prevmode = _setmode(_fileno(stdout), _O_BINARY);。我对 windows7 有同样的问题，没有办法用 fwprintf 做到这一点。

【讨论】：

【解决方案2】：

我从Hans Passant 得到了这个答案。谢谢汉斯。

错误的换行符是标准输出缓冲的结果。在将模式设置回原始模式之前，我们需要刷新流。

prevmode = _setmode(_fileno(stdout), _O_U16TEXT);
fwprintf(stdout,L"one\n");
fwprintf(stdout,L"two\n");
fwprintf(stdout,L"three\n");
fflush(stdout);               /* flush stream */
_setmode(_fileno(stdout), prevmode);

在命令提示符 (cmd.exe) 中重定向输出会创建一个正确的 UTF-16 文件，没有 BOM。

c:\test>.\testu16 > o.txt

c:\test>xxd o.txt
0000000: 6f00 6e00 6500 0d00 0a00 7400 7700 6f00  o.n.e.....t.w.o.
0000010: 0d00 0a00 7400 6800 7200 6500 6500 0d00  ....t.h.r.e.e...
0000020: 0a00                                     ..

在 powershell 中输出仍然是错误的。

PS C:\test> .\testu16 > p.txt
PS C:\test> xxd p.txt
0000000: fffe 6f00 0000 6e00 0000 6500 0000 0d00  ..o...n...e.....
0000010: 0a00 0000 0d00 0a00 0000 7400 0000 7700  ..........t...w.
0000020: 0000 6f00 0000 0d00 0a00 0000 0d00 0a00  ..o.............
0000030: 0000 7400 0000 6800 0000 7200 0000 6500  ..t...h...r...e.
0000040: 0000 6500 0000 0d00 0a00 0000 0d00 0a00  ..e.............
0000050: 0000 0d00 0a00                           ......

这是因为 PowerShell 不会保持流不受影响。它试图解释它并将其转换为 UTF-16。它猜测输入流编码是ANSI。 PowerShell 添加了一个 UTF-16 BOM，其余的是双编码的 UTF-16。这解释了额外的零。

即使使用输出文件并指定编码也无济于事。

PS C:\test> .\testu16.exe | out-file p.txt -encoding unicode
PS C:\test> xxd p.txt
0000000: fffe 6f00 0000 6e00 0000 6500 0000 0d00  ..o...n...e.....
0000010: 0a00 0000 0d00 0a00 0000 7400 0000 7700  ..........t...w.
0000020: 0000 6f00 0000 0d00 0a00 0000 0d00 0a00  ..o.............
0000030: 0000 7400 0000 6800 0000 7200 0000 6500  ..t...h...r...e.
0000040: 0000 6500 0000 0d00 0a00 0000 0d00 0a00  ..e.............
0000050: 0000 0d00 0a00                           ......

PowerShell 需要被告知编码，这是通过首先打印一个 UTF-16 BOM 来完成的：

prevmode = _setmode(_fileno(stdout), _O_U16TEXT);
fwprintf(stdout, L"\xfeff");  /* UTF-16LE BOM */
fwprintf(stdout,L"one\n");
fwprintf(stdout,L"two\n");
fwprintf(stdout,L"three\n");
fflush(stdout);               /* flush stream */
_setmode(_fileno(stdout), prevmode);

现在我们得到一个正确的 UTF-16 文件。

PS C:\test> .\testu16 > p.txt
PS C:\test> xxd p.txt
0000000: fffe 6f00 6e00 6500 0d00 0a00 7400 7700  ..o.n.e.....t.w.
0000010: 6f00 0d00 0a00 7400 6800 7200 6500 6500  o.....t.h.r.e.e.
0000020: 0d00 0a00

【讨论】：