Windows下std::filesystem读中文路径失败因窄字符串按ANSI码页解码，应改用std::wstring或手动UTF-8→UTF-16转换；Linux/macOS可直接用u8string构造path；u8string()返回平台原生UTF-8编码。
Windows 下 std::filesystem 读中文路径直接失败？因为默认用窄字符窄编码
在 Windows 上，std::filesystem::path 构造函数接收 const char* 或 std::string 时，会按当前系统 ANSI 代码页（如 GBK）解释字节——但你的源文件保存为 UTF-8、字符串字面量是 UTF-8 编码的 u8"中文.txt"，两者不匹配，路径就乱码或找不到。这不是 filesystem 的 bug，而是 C++ 标准库在 Windows 上对窄字符串路径的“约定俗成”行为。
实操建议：
- 避免用
std::string或裸const char*构造含中文的std::filesystem::path - 改用宽字符：用
std::wstring+L"中文.txt"，Windows API 原生支持，最稳 - 若坚持用 UTF-8 字符串（比如从网络、JSON 或跨平台代码来），必须显式转成
std::wstring再喂给path
怎么把 u8string 安全转成 std::filesystem::path（Windows）
不能直接写 std::filesystem::path{u8str}，因为标准没规定它如何解释 UTF-8 字节——MSVC 当前会按当前 ANSI 页解码，GCC/Clang 在 Windows 上行为未定义。必须手动 UTF-8 → UTF-16 转换。
推荐用 Windows API MultiByteToWideChar（轻量、无依赖）：
立即学习“C++免费学习笔记（深入）”；
std::wstring utf8_to_wstring(std::string_view u8str) {
if (u8str.empty()) return {};
int len = MultiByteToWideChar(CP_UTF8, 0, u8str.data(), (int)u8str.size(), nullptr, 0);
std::wstring wstr(len, L'\0');
MultiByteToWideChar(CP_UTF8, 0, u8str.data(), (int)u8str.size(), &wstr[0], len);
return wstr;
}
// 使用：
std::u8string u8path = u8"测试文件夹/文档.txt";
std::filesystem::path p{utf8_to_wstring(u8path)};
注意点：
- 别用
std::codecvt_utf8<wchar_t></wchar_t>：C++20 已弃用，且 MSVC 实现有缺陷 - 别用第三方库（如 ICU）除非项目已依赖——小需求引入大依赖得不偿失
- 转换失败时
MultiByteToWideChar返回 0，应加错误检查（生产环境必需）
Linux/macOS 下 u8string 可以直接构造 path 吗？
可以，而且推荐。POSIX 系统的文件系统接口（open、stat 等）本身只认字节序列，不关心编码；只要你的终端、locale 是 UTF-8（现代发行版默认），std::filesystem::path 拿到 std::string 或 std::u8string 都只是原样传给系统调用——所以 std::filesystem::path{u8str} 完全安全。
但要注意：
- 确保编译器把
u8"..."当作 UTF-8 字节串（C++17 起保证），别用"..."加 BOM 或手动拼接 - 如果程序要跨平台，不要在 Linux 上偷懒写
path{"中文"}，而应统一走u8string→path流程，Windows 侧补转换逻辑 - 某些旧版 glibc 对超长路径或嵌入 \0 的 UTF-8 处理不严谨，但日常中文路径基本无感
std::filesystem::path::u8string() 返回的是什么编码？
返回 std::u8string，内容是该路径在**当前平台原生表示的 UTF-8 编码字节**——但这个“原生表示”有陷阱：
- Windows：内部用 UTF-16 存储，
u8string()是调用WideCharToMultiByte(CP_UTF8, ...)转出来的，结果可靠 - Linux/macOS：内部就是 UTF-8 字节，直接返回副本，也可靠
- 但如果你之前是用
std::string（非u8string）构造的 path，且该 string 是 GBK 编码的中文，那u8string()返回的就是 GBK 字节被当 UTF-8 解释后的乱码——根源在构造阶段就错了
所以关键不在 u8string() 方法本身，而在你最初怎么把中文放进 path 的。路径一旦构造错误，后续所有转换都救不回来。
