嘿，这个问题问得挺戳点的！我给你唠明白：

首先，你写的wchar_t myChar = L'\u00C6';这种写法，C标准里对\u开头的Unicode转义序列是有明确说法的——它代表的是对应Unicode码点的字符，但关键来了：这个字符最终存在wchar_t变量里的具体数值，是不是就等于码点本身（也就是你说的十六进制C6），其实是实现定义的。

为啥这么说呢？因为C标准从来没强制要求wchar_t必须用UTF-16或者UTF-32这种和Unicode码点直接对应的编码。给你举俩实际场景：

• 要是你的编译器/系统把wchar_t实现成UTF-32（比如大部分类Unix系统），那L'\u00C6'存到myChar里的数值就确实是0x000000C6，和码点完全一致；
• 但像Windows系统，wchar_t通常用UTF-16编码，对于基本平面的码点（比如0x00C6），编码值和码点是一样的，但这只是实现的选择，不是标准强制要求的！换句话说，理论上某个奇葩实现完全可以用其他编码来表示宽字符，这时候Unicode转义序列对应的wchar_t数值就可能和码点不匹配。

再抠下标准的细节：C标准规定，宽字符常量里的\u转义序列会被转换为当前宽字符编码集中对应的编码值——而宽字符编码集是由实现来决定的，标准只要求它能覆盖当前环境里的所有扩展字符集。所以本质上，没有跨所有实现的通用保证，说wchar_t的数值一定等于Unicode码点。

最后给你划个重点：

• 你写的L'\u00C6'肯定能正确表示Æ这个字符，但它在wchar_t里存的具体数值是不是0xC6，得看你的编译器/系统怎么实现wchar_t的编码；
• 只有当实现明确把wchar_t的编码设置成和Unicode码点一一对应的类型（比如UTF-32）时，数值才会完全匹配，否则就不一定。

备注：内容来源于stack exchange，提问作者NikS