我在 Linux 上有以下代码：-
rc = iconv_open("WCHAR_T", SourceCode);
在使用 iconv 将数据转换为宽字符串 (wchar_t) 之前。
我试图了解它实现了什么，以便将其移植到参数 1 上的选项 "WCHAR_T" 不存在的平台。
这会导致子问题，例如：
wchar_t 的单一表示？我希望得到一个类似这样的答案：“您显示的代码是执行以下 2 件事的简写......”然后我也许可以执行这两个步骤而不是简写 on iconv_open 上的 "WCHAR_T" 选项不存在的平台。
【问题讨论】：
标签： c linux character-encoding wchar-t
（非标准）WCHAR_T 编码存在的原因是为了便于将指向wchar_t 的指针转换为指向char 的指针并将其与iconv 一起使用。该编码可以理解的格式是系统原生的wchar_t。
如果您询问的是 glibc 而不是其他 libc 实现，那么在 Linux 上，wchar_t 是系统原生字节序中的 32 位类型，代表 Unicode 代码点。这与UTF-32 不同，因为UTF-32 通常有一个字节顺序标记 (BOM)，如果没有，则为大端。 WCHAR_T 始终是本地字节序。
请注意，某些系统对wchar_t 使用不同的语义。 Windows 始终使用使用 little-endian UTF-16 的 16 位类型。如果您在该平台上使用 GNU libiconv，WCHAR_T 编码将与您在 Linux 上运行时不同。
语言环境设置不会影响wchar_t，因为wchar_t 的大小必须在编译时知道，因此实际上不能根据语言环境而变化。
如果这段代码确实将一个指针投射到wchar_t 并在其对iconv 的调用中使用它，那么您需要调整代码以使用UTF-16LE、UTF-16BE、@ 编码之一987654339@，或UTF-32BE，取决于sizeof(wchar_t) 和平台的字节序。这些编码不需要（也不允许）BOM，并且假设您没有使用 PDP-11，其中一种对您的平台来说是正确的。
如果您从其他来源获取数据，那么您需要弄清楚那是什么，并使用上面列表中的适当编码。您还应该向上游发送补丁，并要求维护者使用不同的、更正确的编码来处理他们的数据格式。
【讨论】：
wchar_t 的大小，我想知道wchar_t 使用的代码页。当你说“无论系统的原生wchar_t--你是怎么发现的？
wchar_t 由 C 标准指定。这些值必须能够支持任何 Unicode 代码点，因此实际上，它们将是 UCS-4、UTF-16LE 或 UTF-16BE。在 Linux 上，它是 UCS-4。代码页是一种遗留的 Windows 现象，Unix 倾向于避开它们，转而使用 Unicode。
wchar_t 定义单个代码页，据我所知，它取决于区域设置。我正在构建一个 64 位应用程序，因此在这种情况下，wchar_t 在我的平台上是 4 个字节。有人建议我使用mbtowc，但是这个功能不允许我提供源代码页。也许我应该简化我的问题。当iconv_open 没有"WCHAR_T" 编码时，我需要从已知代码页转到wchar_t。