std:：iostream类缺少char16_t和char32_t的专门化，boost:：format取决于流。对于utf16字符串，用什么来替换流（最好有本地化支持）？
流处理的基本实体是字符，而不是编码字符。对于Unicode，决定将一个字符拆分为多个实体，这使得它与流抽象本质上不兼容。
添加新的字符类型旨在以标准的方式处理Unicode字符，但人们认为它太复杂了，无法同时重做IOStreams和区域设置的行为来满足增加的复杂性。这部分是因为人们不太喜欢流，部分是因为它是一项艰巨而非琐碎的任务。我认为可以定义所需的方面来处理简单的情况，但我不确定这是否会带来快速的解决方案，也不确定它是否会涵盖需要Unicode的语言：我可以看到如何使其适用于欧洲文本，但我也不知道它是否真的适用于亚洲文本。
这很好。编码的争论已经结束，并且基本上已经解决了。您不希望utf16字符串出现在程序中的任何位置，除非是在与传统API通信时，也就是在转换整个格式化字符串时，最好通过boost:：窄和宽来完成。当然，除非您正在进行一些罕见的边缘案例优化。
请参阅http://utf8everywhere.org.
当前流通常是作为模板实现的（我这里没有标准的副本，但我很确定它们必须作为模板实现），所以让它们具有宽字符串意识应该只是用适当的字符类型实例化模板的简单问题。
最有可能的是，您的实现已经具有针对宽字符串的预定义专业化。看看类似std:：wstringstream的东西。
也就是说，C++中的各种字符类型不会对您放入其中的字符串的编码做出任何假设，所以您应该以"按约定"的方式处理这一问题——就像在中一样，您的宽字符串按约定编码为utf16，但库中没有强制执行此约定的内容。