Boost C++ 库

...世界上最受推崇和专业设计的 C++ 库项目之一。 Herb SutterAndrei Alexandrescu,《C++ 编码标准

Boost.Nowide
Boost.Nowide

更新日志

目录

什么是 Boost.Nowide

Boost.Nowide 是一个最初由 Artyom Beilis 实现的库,它使跨平台 Unicode 感知编程变得更容易。

该库提供了标准 C 和 C++ 库函数的实现,使其在 Windows 上能够感知 UTF-8 输入,而无需使用 Wide API。在非 Windows/POSIX 平台上,StdLib 等效项被别名化,因此在那里不执行转换,因为 UTF-8 已被普遍使用。

因此,您可以在所有平台上使用与 std 对应项同名的 Boost.Nowide 函数和窄字符串,并且它可以正常工作。

理由

问题

考虑一个简单的应用程序,它将一个大文件分割成块,以便可以通过电子邮件发送。它需要执行一些非常简单的任务

  • 访问命令行参数:int main(int argc,char **argv)
  • 打开一个输入文件,打开几个输出文件:std::fstream::open(const char*,std::ios::openmode m)
  • 在发生故障时删除文件:std::remove(const char* file)
  • 在控制台上打印进度报告:std::cout << file_name

不幸的是,如果文件名包含非 ASCII 字符,则不可能用纯 C++ 实现这个简单的任务。

这个简单的程序在使用 UTF-8 作为内部编码的系统上可以工作——绝大多数 Unix-Like 操作系统:Linux、Mac OS X、Solaris、BSD。但它在 Microsoft Windows 下对于诸如 War and Peace - Война и мир - מלחמה ושלום.zip 这样的文件会失败,因为原生的 Windows Unicode 感知 API 是 Wide-API – UTF-16。

这个极其简单的任务在跨平台方式下非常难以实现。

解决方案

Boost.Nowide 提供了一组标准库函数,这些函数在 Windows 上是 UTF-8 感知的,并使 Unicode 感知编程更容易。

该库提供

  • 易于使用的 UTF-8 与 UTF-16 相互转换的函数
  • 一个使 mainargcargcenv 参数使用 UTF-8 的类
  • UTF-8 感知函数
    • cstdio 函数
      • fopen
      • freopen
      • remove
      • rename
    • cstdlib 函数
      • system
      • getenv
      • setenv
      • unsetenv
      • putenv
    • fstream
      • filebuf
      • fstream/ofstream/ifstream
    • iostream
      • cout
      • cerr
      • clog
      • cin

所有这些函数都可以在 Boost.Nowide 中以相同名称的头文件中找到。因此,与其包含 cstdio 并使用 std::fopen,不如简单地包含 boost/nowide/cstdio.hpp 并使用 boost::nowide::fopen。这些函数接受与其 std 对应项相同的参数,实际上在非 Windows 构建中,它们只是这些函数的别名。但在 Windows 上,Boost.Nowide 会施展其魔法:窄字符串参数被解释为 UTF-8,转换为宽字符串 (UTF-16),并传递给正确处理特殊字符的 Wide API。

如果传递的字符串中存在非 UTF-8 字符,转换将用替换字符(默认值:U+FFFD)替换它们,类似于 NT 内核的做法。这意味着无效的 UTF-8 序列不会从 narrow->wide->narrow 往返,从而导致例如,如果文件名格式不正确,则无法打开文件。

为什么不使用窄字符和宽字符?

为什么不提供宽字符和窄字符两种实现,以便开发人员可以选择在类 Unix 平台上使用宽字符?

有几个原因

  • wchar_t 并非真正可移植,它可以是 2 字节、4 字节甚至 1 字节,这使得 Unicode 感知编程更加困难
  • C 和 C++ 标准库使用窄字符串进行操作系统交互。该库遵循相同的通用规则。标准库中没有 fopen(const wchar_t*, const wchar_t*) 这样的东西,因此最好坚持标准,而不是以“Microsoft Windows 风格”重新实现 Wide API

替代方案

自 2019 年 5 月的更新以来,Windows 10 通过清单文件支持窄字符串的 UTF-8。因此,将“UTF-8”设置为活动代码页将允许在没有任何其他更改的情况下使用窄 API 和 UTF-8 编码的字符串。有关详细信息,请参阅 文档

自 2018 年 4 月起,Windows 10 中提供了一个(Beta)功能,可以通过用户设置默认使用 UTF-8 代码页。

这两种方法都有效,但有一个主要的缺点:对于应用程序开发人员来说,它们并非完全可靠。通过清单方法的代码页在使用低于 1903 的旧 Windows 版本时会回退到旧版代码页。因此,它仅在目标系统是 2019 年 5 月之后的 Windows 10 时才可用。
第二种方法依赖于在程序启动之前用户交互。显然,当期望代码中只有 UTF-8 时,这是不可靠的。

此外,自 Windows 10 1803(即自 2018 年 4 月起)以来,可以使用例如 setlocale(LC_ALL, ".UTF8"); 以编程方式将当前代码页设置为 UTF-8。这使得许多函数接受或生成 UTF-8 编码的字符串,这对于 std::filesystem::path 及其 string() 函数尤其有用。有关详细信息,请参阅 文档。虽然这适用于大多数函数,但它不适用于例如程序参数(mainargvenv 参数)。

因此,在某些情况下(并希望在未来的某个时候总是如此),将不再需要此库,甚至 Windows I/O 也可以与 UTF-8 编码的文本一起使用。

延伸阅读

使用库

构建库

Boost.Nowide 通常作为 Boost 的一部分通过 b2 构建。
它需要 C++11 功能,如果缺少任何功能,则不会构建该库。

如果发生意外情况,请查看配置检查输出中是否有类似 cxx11_constexpr : no 的内容。
这意味着您的编译器不使用 C++11(或更高版本),例如,因为它默认为 C++03。您可以将 cxxstd=11 传递给 b2 以在 C++11 模式下构建。

也提供了对使用 Boost CMake 构建系统进行构建的实验性支持。
为此,运行例如 cmake -DBOOST_INCLUDE_LIBRARIES=nowide <path-to-boost-root> <other options>

标准功能

作为开发人员,您应该使用 boost::nowide 函数而不是 std 命名空间中可用的函数。

例如,这是一个 Unicode 无感知的行计数器实现

#include <fstream>
#include <iostream>
int main(int argc,char **argv)
{
if(argc!=2) {
std::cerr << "用法:文件名" << std::endl;
return 1;
}
std::ifstream f(argv[1]);
if(!f) {
std::cerr << "无法打开 " << argv[1] << std::endl;
return 1;
}
int total_lines = 0;
while(f) {
if(f.get() == '\n')
total_lines++;
}
f.close();
std::cout << "文件 " << argv[1] << " 有 " << total_lines << " 行" << std::endl;
return 0;
}

为了使这个程序正确处理 Unicode,我们进行以下更改

#include <boost/nowide/args.hpp>
#include <boost/nowide/fstream.hpp>
#include <boost/nowide/iostream.hpp>
int main(int argc,char **argv)
{
boost::nowide::args a(argc,argv); // 修复参数 - 使它们成为 UTF-8
if(argc!=2) {
boost::nowide::cerr << "用法:文件名" << std::endl; // Unicode 感知控制台
return 1;
}
boost::nowide::ifstream f(argv[1]); // argv[1] - 是 UTF-8
if(!f) {
// 控制台可以显示 UTF-8
boost::nowide::cerr << "无法打开 " << argv[1] << std::endl;
return 1;
}
int total_lines = 0;
while(f) {
if(f.get() == '\n')
total_lines++;
}
f.close();
// 控制台可以显示 UTF-8
boost::nowide::cout << "文件 " << argv[1] << " 有 " << total_lines << " 行" << std::endl;
return 0;
}
args 是一个类,它临时将标准 main() 函数参数替换为它们的等效项,...
定义 args.hpp:57
与 std::basic_ifstream<char> 相同,但在 Windows 下接受 UTF-8 字符串。
定义 fstream.hpp:73
detail::winconsole_ostream cerr
与 std::cerr 相同,但使用 UTF-8。
detail::winconsole_ostream cout
与 std::cout 相同,但使用 UTF-8。

这种非常简单直接的方法有助于编写 Unicode 感知程序。

注意 boost::nowide::argsboost::nowide::ifstreamboost::nowide::cerr/cout 的使用。在非 Windows 系统上,它不执行任何操作,但在 Windows 上,会发生以下情况

  • boost::nowide::args 从 Windows API 检索 UTF-16 参数,将它们转换为 UTF-8,并在实例的生命周期内临时将原始 argv(以及可选的 env)替换为指向这些内部存储的 UTF-8 字符串的指针。
  • boost::nowide::ifstream 将传递的文件名(现在是有效的 UTF-8)转换为 UTF-16,并调用 Windows Wide API 以打开文件流,然后可以像往常一样使用该文件流。
  • 类似地,boost::nowide::cerrboost::nowide::cout 使用底层流缓冲区,该缓冲区将 UTF-8 字符串转换为 UTF-16,并使用另一个 Wide API 函数将其写入控制台。

自定义 API

当然,这组简单的函数不能满足所有需求。如果您需要从内部使用 UTF-8 的 Windows 应用程序访问 Wide API,则可以使用函数 boost::nowide::widenboost::nowide::narrow

例如

CopyFileW( boost::nowide::widen(existing_file).c_str(),
boost::nowide::widen(new_file).c_str(),
TRUE);
wchar_t * widen(wchar_t *output, size_t output_size, const char *begin, const char *end)
定义 convert.hpp:48

转换在最后阶段完成,您在其他任何地方继续使用 UTF-8 字符串。您仅在粘合点切换到 Wide API。

boost::nowide::widen 返回 std::string。有时,防止分配并使用堆栈缓冲区会很有用。Boost.Nowide 为此目的提供了 boost::nowide::basic_stackstring 类。

上面的示例可以重写为

boost::nowide::basic_stackstring<wchar_t,char,64> wexisting_file(existing_file), wnew_file(new_file);
CopyFileW(wexisting_file.c_str(), wnew_file.c_str(), TRUE);
一个类,允许从宽或窄 UTF 源创建临时的宽或窄 UTF 字符串。
定义 stackstring.hpp:32
注意
有一些方便的 typedef:stackstringwstackstring 使用 256 字符缓冲区,以及 short_stackstringwshort_stackstring 使用 16 字符缓冲区。如果字符串更长,它们会回退到堆内存分配。

windows.h 头文件

该库不包含 windows.h,以防止命名空间被众多定义和类型污染。相反,该库定义了 Win32 API 函数的原型。

但是,您可以通过在包含任何 Boost.Nowide 头文件之前定义 BOOST_USE_WINDOWS_H 来请求使用 windows.h 头文件

与 Boost.Filesystem 集成

Boost.Filesystem 支持选择窄编码。不幸的是,Windows 上的默认窄编码不是 UTF-8。但是,您可以通过在程序开始时调用 boost::nowide::nowide_filesystem() 来启用 UTF-8 作为 Boost.Filesystem 上的默认编码,这会赋予区域设置一个 UTF-8 转换 facet,以在 charwchar_t 之间进行转换。这会将传递给和来自 boost::filesystem::path 的所有窄字符串解释为 UTF-8,并在将它们转换为宽字符串时(根据内部存储的需要)。在 POSIX 上,这通常没有效果,因为由于窄字符串被用作存储格式,因此不执行转换。

对于自 C++17 起可用的 std::filesystem::path,无法赋予区域设置。但是,u8string() 成员函数可用于从 path 获取 UTF-8 编码的字符串。要从 UTF-8 编码的字符串获取 path,您可以使用 std::filesystem::u8path,或者自 C++20 起,可以使用采用 char8_t 类型输入的 path 构造函数之一。

要从流中读取/写入 std::filesystem::path 实例,您通常会使用例如 os << path。然而,这实际上将作为 os << std::quoted(path.string()) 运行,这意味着可能转换为可能不是 UTF-8 编码的窄字符串。为此,可以使用 quoted

#include <boost/nowide/quoted.hpp>
#include <filesystem>
#include <sstream>
std::string write(const std::filesystem::path& path)
{
std::ostringstream s;
s << boost::nowide::quoted(path);
return s.str();
}
std::experimental::path read(std::istream& is)
{
std::filesystem::path path;
is >> boost::nowide::quoted(path);
return path;
}

技术细节

Windows 与 POSIX

对于 Microsoft Windows,该库在 boost::nowide 命名空间中提供了某些 std:: 函数的 UTF-8 感知变体。例如,std::fopen 变为 boost::nowide::fopen

在 POSIX 平台上,boost::nowide 中的函数是其标准库对应项的别名

namespace boost {
namespace nowide {
#ifdef BOOST_WINDOWS
inline FILE *fopen(const char* name, const char* mode)
{
...
}
#else
using std::fopen
#endif
} // nowide
} // boost
FILE * fopen(const char *file_name, const char *mode)
与 fopen 相同,但 file_name 和 mode 是 UTF-8 字符串。

还为 Windows 提供了一个与 std::filebuf 兼容的实现,该实现支持 UTF-8 文件路径用于 open,并且在其他方面行为相同(API 方面)。

在所有系统上,都提供了 std::fstream 类及其友元作为自定义实现,支持 std::string*::filesystem::path 以及 wchar_t*(仅限 Windows)重载,用于构造函数和 open。这样做是为了用户可以使用例如 boost::filesystem::pathboost::nowide::fstream,而无需依赖 C++17 支持。此外,如果任何类似路径的类与 std::filesystem::path 的接口“足够”匹配,则都支持。

请注意,boost::nowide::filebuf 中没有对 pathstd::string 的通用支持。这是因为在非 Windows 系统上使用了 std 变体,这在某些情况下可能更快。由于 filebuf 很少被用户代码直接使用,而是通过 fstream 间接使用,因此没有字符串或路径支持似乎是一个很小的代价,特别是 C++11 添加了 std::string 支持,C++17 添加了 path 支持,并且通过 string_or_path.c_str() 的使用仍然是可能的且可移植的。

控制台 I/O

当流转到“真实”控制台时,控制台 I/O 实现为 ReadConsoleW/WriteConsoleW 的包装器。当流被管道传输/重定向时,将改用标准 cin/cout

这种方法消除了手动代码页处理的需要。如果使用 TrueType 字体,则 Unicode 感知输入和输出可以按预期工作。

问答

问:通过 Boost.Nowide 传递的无效 UTF 会发生什么情况?例如,Windows 使用 UCS-2 而不是 UTF-16。

答:Boost.Nowide 的策略是始终生成有效的 UTF 编码字符串。因此,无效的 UTF 字符将替换为替换字符 U+FFFD

这在两个方向都发生
当将(假定的)UTF-8 编码的字符串传递给 Boost.Nowide 时,它会将其转换为 UTF-16,并在将其传递给操作系统之前替换每个无效字符。
在从操作系统检索值时(例如,通过 boost::nowide::argsboost::nowide::getenv 或命令行参数),该值被假定为 UTF-16 并转换为 UTF-8,替换任何无效字符。

这意味着,如果有人设法在 Windows 中创建无效的 UTF-16 文件名,则不可能使用 Boost.Nowide 处理它。但由于 Microsoft 在 Windows 2000 中从 UCS-2(又名具有任意 2 字节值的字符串)切换到 UTF-16,因此在大多数环境中不会成为问题。

问:使用哪种类型的错误报告?

答:实际上有 3 种

  • 无效的 UTF 编码字符串通过用替换字符 U+FFFD 替换无效字符来使用
  • 镜像标准 API 的 API 调用使用与其相同的错误报告,例如,通过在失败时返回非零值
  • 不可继续的错误通过标准异常报告。主要示例是通过 WinAPI 获取命令行参数失败

问:为什么该库不将字符串转换为/从区域设置的编码(而不是 UTF-8)在 POSIX 系统上?

答:在 POSIX 平台上将字符串转换为/从区域设置编码在本质上是不正确的。

您可以创建一个名为“\xFF\xFF.txt”(无效 UTF-8)的文件,将其删除,将其名称作为参数传递给程序,无论当前区域设置是否为 UTF-8,它都可以工作。此外,将区域设置从例如 en_US.UTF-8 更改为 en_US.ISO-8859-1 不会神奇地更改操作系统中的所有文件或用户可能传递给程序的字符串(这在 Windows 上是不同的)

POSIX 操作系统将字符串视为 NULL 终止的 cookie。

因此,根据区域设置更改其内容实际上会导致不正确的行为。

例如,这是一个标准程序“rm”的幼稚实现

#include <cstdio>
int main(int argc,char **argv)
{
for(int i=1;i<argc;i++)
std::remove(argv[i]);
return 0;
}

它可以在任何区域设置下工作,更改字符串会导致不正确的行为。

区域设置在 POSIX 和 Windows 平台下的含义不同,并且具有非常不同的效果。

独立版本

可以在不依赖庞大的 Boost 项目的情况下使用 Nowide 库。有一个独立版本,它在 nowide 命名空间而不是 boost::nowide 中具有所有功能。上面的示例将如下所示

#include <nowide/args.hpp>
#include <nowide/fstream.hpp>
#include <nowide/iostream.hpp>
int main(int argc,char **argv)
{
nowide::args a(argc,argv); // 修复参数 - 使它们成为 UTF-8
if(argc!=2) {
nowide::cerr << "用法:文件名" << std::endl; // Unicode 感知控制台
return 1;
}
nowide::ifstream f(argv[1]); // argv[1] - 是 UTF-8
if(!f) {
// 控制台可以显示 UTF-8
nowide::cerr << "无法打开文件 " << argv[1] << std::endl;
return 1;
}
int total_lines = 0;
while(f) {
if(f.get() == '\n')
total_lines++;
}
f.close();
// 控制台可以显示 UTF-8
nowide::cout << "文件 " << argv[1] << " 有 " << total_lines << " 行" << std::endl;
return 0;
}

源代码和下载

上游源代码可以在 GitHub 上找到:https://github.com/boostorg/nowide

您可以在那里下载最新的源代码