Windows路径中绝对禁止的字符是:、*、?、"、<、>、|、、/及ASCII控制字符（0x00–0x1F）和DEL（0x7F），而.和..是保留名，非非法字符。
Windows下哪些字符绝对不能出现在路径里
Windows文件系统（NTFS/FAT）对路径字符有硬性限制，:、*、?、"、、<code>>、|、、/ 这9个字符在任何位置（包括文件名、目录名、扩展名）都非法。另外，ASCII控制字符（0x00–0x1F）和DEL（0x7F）也不允许。. 和 .. 是保留名，但作为路径组件出现时不是“非法字符”，而是语义特殊——这点常被误判。
用std::string逐字符检查的可靠写法
别依赖正则或第三方库做基础校验——简单路径检查没必要引入复杂度。直接遍历字符串，对照非法字符表即可：
bool is_path_valid_on_windows(const std::string& path) {
static const std::string illegal = ":*?"<>|\/";
for (char c : path) {
if (c < 0x20 || c == 0x7F || illegal.find(c) != std::string::npos) {
return false;
}
}
return true;
}
注意：0x20是空格，它本身合法（Windows允许含空格路径），所以判断范围是 c （即0x00–0x1F），不包含空格；<code>0x7F单独排除。
- 不要用
std::isprint判断——它把DEL（0x7F）当作可打印字符，会漏判 - 路径中允许出现
+、=、[、]等符号，无需过滤 - 这个函数只检查字符合法性，不验证路径是否存在或长度是否超限（MAX_PATH=260）
Linux/macOS路径校验要谨慎得多
POSIX系统几乎不限制字符（除 <p>POSIX系统几乎不限制字符（除 <code> 和 /），/ 是路径分隔符，不能出现在文件名内； 是C字符串终止符，根本无法存入 std::string（除非手动构造含嵌入空字节，但这种路径在实际I/O中会截断）。所以对非Windows平台，真正需要拦截的只有：
/），/ 是路径分隔符，不能出现在文件名内；<p>POSIX系统几乎不限制字符（除 <code> 和 /），/ 是路径分隔符，不能出现在文件名内； 是C字符串终止符，根本无法存入 std::string（除非手动构造含嵌入空字节，但这种路径在实际I/O中会截断）。所以对非Windows平台，真正需要拦截的只有： 是C字符串终止符，根本无法存入 std::string（除非手动构造含嵌入空字节，但这种路径在实际I/O中会截断）。所以对非Windows平台，真正需要拦截的只有：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
-
path.find(' ') != std::string::npos检查 -
/出现在非分隔位置 —— 例如"foo/bar/baz"合法，但"file/name.txt"中的/若在末尾或开头之外的位置，就属于非法文件名（实际是路径组件分割）
更现实的做法是：**不对Linux路径做字符级预检**，因为用户可能有意使用 emoji、Unicode符号甚至控制字符（只要不碰 和 /）。真正出错往往在 open() 或 stat() 系统调用时，那时再处理 errno 更合理。
跨平台代码里容易忽略的细节
同一个路径字符串，在不同平台含义可能完全不同。比如 "C: emp ile.txt" 在Windows是绝对路径，在Linux会被当成相对路径（C: 是目录名， 被解释为制表符）。所以：
- 不要在跨平台逻辑里混用
\和/—— 统一用/作为内部表示，仅在调用系统API前转换 - 检查前先 normalize 路径：去掉冗余
./、../，避免因路径结构问题掩盖字符问题 -
std::filesystem::path的native()返回的是平台原生格式，但它的构造函数不会拒绝含非法字符的字符串——它只是存储，不校验
最稳妥的方式是：按目标平台选择校验逻辑，且校验必须在路径拼接完成之后、实际 I/O 之前执行。否则，一个看似合法的片段拼起来可能产生非法字符序列（比如用户输入 "a<b> + <code>".txt" 得到 "a<b.txt>）。</b.txt>
