Windows下绝对不能出现在文件路径中的字符是:、*、?、"、<、>、|、、/共9个，任何位置出现即非法；Linux/macOS则需防范空字符和ASCII控制字符（– ）。
Windows下哪些字符绝对不能出现在文件路径里
Windows对文件路径的非法字符有硬性限制，:、*、?、"、、<code>>、|、、/ 这9个字符在任何位置（包括文件名、目录名）都禁止使用。哪怕只是字符串校验，只要出现其中之一就应视为非法。
注意： 和 / 在路径中常作分隔符，但若出现在文件名中间（比如 logackup.txt 中的反斜杠在末尾前），就是非法的；同理，. 和空格本身合法，但开头或结尾的空格、连续多个点（如 ...）可能被系统解析为保留名，需额外处理。
-
std::string::find_first_of(":*?"|\/") != std::string::npos是最直接的检测方式 - 不要只检查末尾或只检查文件名部分——整个路径字符串都要扫
- 路径中允许出现
+、-、_、(、)等，无需过滤
Linux/macOS路径校验的重点其实是空字符和控制字符
POSIX系统不禁止 :、? 等符号，真正危险的是 （空字符）和 ASCII 控制字符（– ，含
、
、 ）。这些字符会导致 open()、stat() 等系统调用截断或失败，且难以调试。
常见误判：把 / 当作非法字符——其实它是合法分隔符；但路径开头的 / 表示绝对路径，中间连续 // 会被忽略，这些都不算“非法”，只是规范问题。
立即学习“C++免费学习笔记（深入）”；
- 用
std::any_of(path.begin(), path.end(), [](char c) { return c == ' ' || (c >= '' && c 检测 - 避免用
strchr()或strstr()，它们遇到 - 如果路径来自用户输入（如命令行参数、HTTP头），必须做此检查——否则可能触发 silent truncation
跨平台路径字符串预处理时容易忽略的细节
同一个字符串在不同系统上合法性可能不同，比如 CON.txt 在 Windows 是设备名保留字，但在 Linux 下完全合法。所以“判断是否非法”必须绑定目标平台，不能写一次逻辑到处用。
更隐蔽的问题是编码：UTF-8 路径中若含无效字节序列（如孤立的 ），某些 C++ 标准库函数（如 std::filesystem::path 构造）会抛 std::filesystem::filesystem_error，但错误信息不提示具体哪个字节出错。
- Windows 下还需额外检查保留设备名：
CON、PRN、AUX、NUL及其带扩展名形式（大小写不敏感） - Linux 下建议用
std::filesystem::path::generic_string()获取原始字节再校验，避免 locale 相关转换干扰 - 不要依赖
std::filesystem::exists()反向验证——它需要实际访问文件系统，且对非法字符可能直接崩溃或抛异常
用 std::filesystem::path 做初步解析再校验更可靠
直接对原始字符串暴力扫描虽快，但容易漏掉语义级问题，比如路径组件为空（/a//b 中的 //）、末尾是 . 或 ..、驱动器标识格式错误（C|temp）等。用 std::filesystem::path 解析后再逐段检查，能覆盖更多边界情况。
注意：std::filesystem::path 构造本身不验证合法性，但它会把路径拆成 root_name、root_directory、relative_path 等部分，方便针对性检查。
- 先尝试构造
std::filesystem::path p{path_str}，捕获std::filesystem::filesystem_error——这通常意味着编码或结构错误 - 遍历
p.begin()到p.end()，对每个path元素调用.string()后再检查非法字符 - Windows 下特别检查
p.root_name().string()是否为有效驱动器（如"C:"），避免"C;temp"这类畸形写法
