- 主题:请教UTF8和ANSI 转换问题，要抓狂了。
中文string literal用L就转为wchar_t了，MSVC支持
static const WCHAR s[] = L"中文字符串";
【 在 hgoldfish 的大作中提到: 】
: 不是这么简单
: 1. cpp 源代码在中文平台是默认 GBK 编码的。几种编译器一般不做转化，直接存储到 exe 里面。
: 2. cpp11 以后有 u8"", u"" 这样的字符串形式，但是不普及。开源软件很多不用。
: ...................
--
修改:z16166 FROM 123.118.185.*
FROM 123.118.185.*
这个在标准里面并没有说明是存储在 EXE 里面的是 GBK 还是 UTF16，
跟编译器的实现有关。跟源代码也有关。
【 在 z16166 (Netguy) 的大作中提到: 】
: 中文string literal用L就转为wchar_t了，MSVC支持
: static const WCHAR s[] = L"中文字符串";
--
FROM 112.47.122.*
1 windows下源代码默认用utf-16的也见过，这个本质上是ide配置问题，不过vc默认确实是acp的编码，而c#居然不是…
2 也可以编译器选项设置 exec encoding，gcc 和 vc 都行。
3 统一用 wchar_t 取 utf-16 内码是个办法，我觉得在 windows 下面比用 utf-8 内码然后转换省事些。但跨平台不好。
4 源代码加bom就问题不大，太老的管不着。
【 在 hgoldfish 的大作中提到: 】
: 不是这么简单
:
: 1. cpp 源代码在中文平台是默认 GBK 编码的。几种编译器一般不做转化，直接存储到 exe 里面。
: ...................
--
FROM 114.249.193.*
主流编译器就是 utf-16 和 utf-32 两种，和实现有关，但和源代码编码无关。
c++主流实现的 input encoding 和 exec encoding 是解耦的，也都可以通过选项改，编译器内码都是某种 unicode。比方说 msvc，只要带 bom，编译器就自动识别 utf-8 和 utf-16，不带就默认 acp，但对 char[] 字面量就都默认 acp 除非设置 exec enc，而 L 字面量都是 utf-16，u8 当然都是 utf-8，都和源代码编码无关。
【 在 hgoldfish 的大作中提到: 】
: 这个在标准里面并没有说明是存储在 EXE 里面的是 GBK 还是 UTF16，
:
: 跟编译器的实现有关。跟源代码也有关。
: ...................
--
FROM 114.249.193.*
这个在 exe 里只能是 UTF-16
编译器需要知道源代码的编码，VS 里面有配置，GCC 有 -finput-charset
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 这个在标准里面并没有说明是存储在 EXE 里面的是 GBK 还是 UTF16，
: 跟编译器的实现有关。跟源代码也有关。
--
修改:vonNeumann FROM 183.60.88.*
FROM 183.60.88.*
程序字面量可以根据需要用 u8 前缀或者 L 前缀，用资源存储串一般是选 wchar_t，配置文件主要看 io 时编码转换（有些工具库可以帮助），文件 io 显式指定编码，控制台用 wchar_t 保险，gui 看框架一般是 wchar_t 或者某个 utf。
一般大原则是内码避免用非 unicode 编码，具体选 utf-8、utf-16 还是 utf-32 各有利弊。然后 IO 的编码转换就用编码转换的 api（windows 就是前面 z16166 提到的 WideCharToMultiByte，MultiByteToWideChar），别用 locale 搞这个。
【 在 speedboy2998 的大作中提到: 】
: 做转换之前需要调用 setlocale 设置 locale, 我的问题是，对于不同的语言的ANSI字符串，有没有一种万能locale设置可以把他们统统转成UTF8，以及再从UTF8转换成ansi字符串？
: --
: FROM 113.246.192.*
--
修改:milksea FROM 114.249.193.*
FROM 114.249.193.*
个人觉得 win msvc 的做法是不对的。c++11 的标准引入 u8, u 这些做法也是自讨苦吃。
我的做法是所有的源代码都要求是 utf-8，直接用 "" 普通字符串表达式，在 windows 底下，要求 msvc 使用 utf-8 编码:
add_compile_options("$<$<C_COMPILER_ID:MSVC>:/utf-8>")
add_compile_options("$<$<CXX_COMPILER_ID:MSVC>:/utf-8>")
https://docs.microsoft.com/en-us/cpp/build/reference/utf-8-set-source-and-executable-character-sets-to-utf-8
utf-8 早就是趋势了。异端都应该被吊死。
【 在 milksea (肥了，又肥了 >>>_<<<) 的大作中提到: 】
: 主流编译器就是 utf-16 和 utf-32 两种，和实现有关，但和源代码编码无关。
: c++主流实现的 input encoding 和 exec encoding 是解耦的，也都可以通过选项改，编译器内码都是某种 unicode。比方说 msvc，只要带 bom，编译器就自动识别 utf-8 和 utf-16，不带就默认 acp，但对 char[] 字面量就都默认 acp 除非设置 exec enc，而 L 字面量都是 utf-1
--
FROM 110.81.40.*
我们之前有些代码积极拥抱新标准，用了 u8"..." 来强调字符串是 UTF-8 编码（其实源代码也是 UTF-8，加个 u8 只是为了强调）
结果 C++20 把 u8"..." 的类型从 const char[] 改成 const char8_t[]，而且 const char8_t* 还不能隐式转为 const char*，一堆地方要改，一种吃了屎的感觉
如果说标准建议凡是 Unicode 字符串都用 char8_t/char16_t/char32_t，想要 deprecate 掉 char/wchar_t，那也行，我都能接受这种阵痛。但尼玛他们又不把支持搞全，std::locale 不支持也就算了，连 C++20 才新增的 std::format 也只有 char/wchar_t 的版本，没有 char8_t/char16_t/char32_t 的版本，真是不知道他们想给我们什么导向。
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 个人觉得 win msvc 的做法是不对的。c++11 的标准引入 u8, u 这些做法也是自讨苦吃。
: 我的做法是所有的源代码都要求是 utf-8，直接用 "" 普通字符串表达式，在 windows 底下，要求 msvc 使用 utf-8 编码:
: add_compile_options("$<$<C_COMPILER_ID:MSVC>:/utf-8>")
: ...................
--
FROM 183.60.88.*
忍不住笑了。。哈哈哈～～
【 在 vonNeumann (劣币驱逐良币 | 少灌水) 的大作中提到: 】
: 我们之前有些代码积极拥抱新标准，用了 u8"..." 来强调字符串是 UTF-8 编码（其实源代码也是 UTF-8，加个 u8 只是为了强调）
: 结果 C++20 把 u8"..." 的类型从 const char[] 改成 const char8_t[]，而且 const char8_t* 还不能隐式转为 const char*，一堆地方要改，一种吃了屎的感觉
: 如果说标准建议凡是 Unicode 字符串都用 char8_t/char16_t/char32_t，想要 deprecate 掉 char/wchar_t，那也行，我都能接受这种阵痛。但尼玛他们又不把支持搞全，std::locale 不支持也就算了，连 C++20 才新增的 std::format 也只有 char/wchar_t 的版本，没有 char8_t/
: ...................
--
FROM 110.81.40.*
QT的QString有相关的函数
--
FROM 117.119.72.*