我知道这个问题在这里已经被问过很多次了，我确实阅读了一些答案，但是有一些建议的解决方案，我试图找出其中最好的解决方案。
我正在编写一个 C99 应用程序，它基本上接收以 UTF-8 编码的 XML 文本。
它的部分工作是复制和操作该字符串（查找 substr，cat it，例如..）
因为我现在不想使用外部的非标准库，所以我尝试使用 wchar_t 来实现它。
目前，我使用 mbstowcs 将其转换为 wchar_t 以便于操作，对于一些我尝试使用不同语言的输入 - 它工作正常。
事实是，我确实读过一些人对 UTF-8 和 mbstowcs 有一些问题，所以我想知道这种使用是否被允许/可接受。
我面临的另一个选择是使用带有 WCHAR_T 参数的 iconv。事实是，我在一个平台（而不是 PC）上工作，它的语言环境非常仅限于 ANSI C 语言环境。那个怎么样？
我也遇到过一些非常流行的 C++ 库。但我仅限于 C99 实现。
此外，我将在另一个平台上编译此代码，wchar_t 的 sizeof 是不同的（在我的机器上是 2 个字节与 4 个字节）。我怎样才能克服它？使用固定大小的字符容器？但是，我应该使用哪些操作函数呢？
很高兴听到一些想法。谢谢。
在本文中,摘自"Linux内核开发"一书:http:
//www.makelinux.net/books/lkd2/ch19lev1sec2
它说:
C long类型的大小保证是机器的字大小.然而,在缺点方面,代码不能假设标准C类型具有任何特定大小.此外,无法保证int与long的大小相同
问题是,我认为int与单词大小相同,不长,我找不到任何定义这个说法的官方标准.
有什么想法吗？
实际问题 - 我正在研究一个在2个独立硬件平台上运行的应用程序.
编译方法及其配置由我定义和控制.
我的应用程序收到UTF-8/ISO-8859文本,并应对字符串执行一些基本操作(复制,搜索等).
事实上,一个编译器是GCC(sizeof(wchar_t)== 4),另一个是Mingw(sizeof(wchar_t)== 2).
为了支持所有UTF-8的可能性,我想在我的代码中wchar_t中的"typedef"是uint32_t类型,因此这将强制Mingw编译器在同一行,并覆盖所有UTF-8选项.
我正计划使用标准库提供的宽字符操作函数(mbstowcs,wcscmp,wcscpy,ex ..)
问题是,"强迫"编译器使用更多空间,可能会对库函数产生一些不良影响(除了性能)(mbtowcs甚至会在更改后在这里工作吗？)
我尝试使用ICU,但它是一个非常大的库,因此打破了这笔交易.我需要它小而可靠.
谢谢