Windows路径中绝对禁止的字符是:、*、?、"、<、>、|、、/及空字符 和ASCII 0x00–0x1F控制字符，这些字符在任何位置都会导致API校验失败并返回ERROR_INVALID_NAME（123）。
Windows下哪些字符绝对不能出现在文件路径中
Windows对路径字符有硬性限制，:、*、?、"、、<code>>、|、、/ 这9个字符在任何位置（包括文件名和路径各段）都非法。哪怕只是出现在字符串里，就无法创建或访问对应路径。
注意： 和 / 在路径中是分隔符，但单独作为文件名的一部分（比如 "a.txt" 中的 b.txt 本身含 ）会直接触发系统拒绝——这不是编码问题，是Win32 API层面的校验失败。
-
CreateFileW或std::filesystem::create_directories遇到这些字符会返回错误，GetLastError()通常是ERROR_INVALID_NAME（123） - 空字符
- 控制字符（ASCII 0x00–0x1F）同样被禁止，例如
（响铃）
如何用C++17 std::filesystem 做初步校验
std::filesystem 不提供“是否合法”的直接接口，但它会在操作时抛出 std::filesystem::filesystem_error，且 .code().value() 可映射到系统错误码。但提前校验更安全，避免副作用。
推荐写一个轻量函数，只扫描字符串内容：
立即学习“C++免费学习笔记（深入）”；
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
bool has_invalid_path_char(const std::wstring& path) {
static const std::unordered_set<wchar_t> illegal = {
L'\', L'/', L':', L'*', L'?', L'"', L'<', L'>', L'|'
};
for (wchar_t c : path) {
if (c == L' ' || c <= 0x1F || illegal.count(c)) {
return true;
}
}
return false;
}
- 必须用
std::wstring（而非std::string）处理宽字符路径，尤其在Windows上 - 不要依赖
std::filesystem::path::generic_string()转换后再检查——它可能把转成/，掩盖原始非法字符 - 该函数不检查长度限制（MAX_PATH=260）、保留名（如
CON、AUX）或末尾空格/点，那些需额外逻辑
Linux/macOS路径校验的关键差异
POSIX系统几乎不限制字符，唯一禁止的是 （路径分隔符 / 本身合法，但不能出现在文件名内——因为它是分隔符，不是“非法”，而是语义冲突）。
所以跨平台代码里，/ 和 是唯二真正需要统一拦截的：
- Linux下
mkdir("a:b")完全合法，:只是普通字符 - 但如果你的程序最终要在Windows上生成路径，就得按Windows规则提前过滤，不能等运行时才报错
- 注意：某些shell或工具（如git）会对
~、$、空格等做特殊处理，但这属于应用层约定，不是系统路径非法
容易被忽略的边界情况
很多人只扫可见字符，却漏掉三类隐性非法：
- 路径末尾的空格或
.：Windows会自动截断，"file.txt "等价于"file.txt"，但"con."会被识别为保留设备名，直接失败 - Unicode控制字符：如
U+202E（右向覆盖），可能造成显示欺骗，虽不触发系统错误，但属于安全风险 - 长路径前缀
\?下的规则变化：启用此前缀后，不再是转义符，但\?C:invalid<char> ile.txt</char>中的非法字符仍无效
实际项目中，如果路径来自用户输入或网络，建议在解析阶段就调用校验函数，并明确告知用户哪个字符违规——而不是等到 std::filesystem::create_directories 失败再提示“路径无效”。
