不建议使用的标头<codecvt>替换

有点前景：我的任务需要将UTF-8 XML文件转换为UTF-16（当然具有正确的标头）。因此，我搜索了将UTF-8转换为UTF-16的常用方法，发现应该使用中的模板<codecvt>。

但是，现在不赞成使用它，我想知道执行相同任务的新通用方法是什么？

（完全不介意使用Boost，但除此之外，我更喜欢尽可能接近标准库。）

— login_not_failed
source

Answers:

std::codecvt<locale>不建议使用其自身的模板。对于UTF-8到UTF-16，仍然存在std::codecvt<char16_t, char, std::mbstate_t>专门化的问题。

但是，由于std::wstring_convert和和std::wbuffer_convert标准转换构面一起已被弃用，因此没有任何简单的方法可以使用构面转换字符串。

因此，正如Bolas已经回答的那样：自己实现（或者您可以像往常一样使用第三方库）或继续使用不推荐使用的API。

— 埃雷里卡
source

但是根据P0618，所有<codecvt>头均已弃用。不只是typedef；std::codecvt完全不推荐使用。

— Nicol Bolas's

@NicolBolas该提案似乎并不建议对定义标头的[locale.codecvt]codecvt_base和codecvt的位置进行任何更改<locale>。但是，阅读文档后，我发现w {string，buffer} _convert也已被弃用，据我所知，这是唯一实际使用codecvt方面的唯一标准函数。因此，即使不提倡使用codecvt，实际上也没有任何简单的方法可以使用它们。您是否认为省略std::codecvt文件是偶然的？

— eerorika

@ user2079303basic_filebuf使用它。

— TC

尽管有影响力，P0618只是标准委员会一名成员的建议。它没有说提案是否被接受；如果已经发布，它将在下一个标准（可能在2020年代中期）之前不被弃用，并且可能直到2030年左右才被删除。我想编译器将继续支持它一段时间。

— 理查德·史密斯

根据P0636R0和P0618R0的@RichardSmith被应用于C ++ 17，这意味着自该标准修订版起，折旧有效。

— eerorika

不用担心

根据相同的信息来源：

该库组件应随同淘汰至附件D， 直到将合适的替换标准化为止。

因此，在完成新的标准化，更安全的版本之前，您仍然可以使用它。

— xmllmx
source

不幸的是，那是一厢情愿的想法。弃用应用于C ++ 17。该建议显然是：“用户应改为使用专用的文本处理库。” 使用时，Visual Studio 2017将发出弃用警告。

— IInspectable '18

什么是专用的文本处理库？

— camccar

希望如此吧，因为仅弃用某些东西而不附带其他选择太容易了。

— gast128

新方法是...您自己编写。或仅依赖不推荐使用的功能。希望标准委员会在替换功能正常之前不会真正删除编解码器。

但是目前还没有。

— 尼科尔·波拉斯（Nicol Bolas）
source

问题是：我需要最便携的方式来做到这一点。当然，总会有诸如icu，iconv和其他各种lib之类的东西，但是以前有一种相当简单的方法，其中涉及三行代码，现在简直是一团糟。

— login_not_failed

@login_not_failed不是“ was”，它仍然是，因为它没有被删除（并且不会被删除一会儿）

— Cubbi