Windows路径中绝对禁止的字符是<、>、:、"、/、、|、?、*，且末尾空格和点非法，CON等设备名大小写不敏感亦禁用。
Windows 下哪些字符绝对不能出现在路径里
Windows 文件系统（NTFS/FAT）有明确禁止的字符，不是“不推荐”，而是内核直接拒绝创建。这些字符一旦出现在 std::string 或 std::wstring 路径中，后续调用 CreateFile、fopen、std::filesystem::create_directories 等都会失败，错误码通常是 ERROR_INVALID_NAME（123）或 EINVAL。
必须过滤的 9 个 ASCII 控制字符和保留名符号：
-
'<'、'>'、':'、'"'、'/'、'\'、'|'、'?'、'*' - 还要额外排除末尾空格和点（
' '和'.'），否则\?路径或某些 API 会静默截断 - 保留设备名如
"CON"、"PRN"、"AUX"、"NUL"及其带扩展名形式（"CON.txt"）也非法 —— 注意大小写不敏感
std::filesystem::path 本身不校验非法字符
std::filesystem::path 是纯字符串容器，构造时不会检查内容合法性。你可以放心地写 std::filesystem::path("foo<bar>，它不会报错，但后续 <code>.make_preferred() 或 .string() 后传给系统 API 就会崩。
所以清洗必须在构建 path 之前，或在调用 create_directories/open 前主动做：
立即学习“C++免费学习笔记（深入）”；
- 不要依赖
path.generic_string()自动转义 —— 它只处理分隔符，不清理非法字符 - 不要用
path.filename().string()直接当文件名用 —— 如果原始输入含:，它照样原样返回 - 若用
std::wstring（推荐 Windows），需遍历每个wchar_t，ASCII 判断逻辑不变，但注意L'\'和L'/'都要拦
一个轻量但完整的清洗函数（支持 Unicode 文件名）
以下函数只清理非法字符，不重命名冲突（比如去重后为空），也不处理保留名 —— 那需要额外判断。重点是快、可嵌入、无外部依赖：
std::wstring sanitize_filename(const std::wstring& name) {
std::wstring out;
out.reserve(name.size());
for (wchar_t c : name) {
if (c == L'<' || c == L'>' || c == L':' || c == L'"' ||
c == L'/' || c == L'\' || c == L'|' || c == L'?' ||
c == L'*') {
continue; // 直接跳过
}
if (c == L' ' || c == L'.') {
// 末尾空格/点要删，但中间的可以留（如 "my file.txt" 合法）
if (&c != &name.back()) out += c;
continue;
}
out += c;
}
// 再检查是否变成空或只剩点（如 ".." → ""）
if (out.empty() || out == L"." || out == L"..") {
out = L"_";
}
return out;
}
注意：&c != &name.back() 不是万能解法（对 string_view 不适用），生产环境建议改用索引遍历 + i == name.size()-1 判断末尾。
Linux/macOS 的差异很小，但别忽略
POSIX 路径只禁止 '\0' 和 '/' —— 前者是 C 字符串终结符，后者是路径分隔符。其他如 ':'、'*' 在 ext4/HFS+ 上完全合法。
但实际开发中仍建议统一清洗，原因很实在：
- 跨平台代码（比如用
std::filesystem）若某处硬编码了"config:dev"，在 Windows 下直接崩溃，Linux 下却跑得欢，容易漏测 - 用户上传文件名常来自 Windows，前端 JS 也可能未过滤，服务端不做兜底就存了非法名，后续同步到 Windows 机器时出问题
-
'\0'很危险：如果输入来自网络或二进制解析，没做 null 截断，std::string构造时可能提前终止，导致路径被截短
真正麻烦的从来不是字符表本身，而是“这个路径最终会在哪跑”——只要有一环是 Windows，就得按 Windows 规则洗。
