Windows路径中绝对禁止的字符是:、<、>、|、?、、"、 共8个；/和可作分隔符，.和..合法，空格也合法；扩展路径（?）和UWP有额外限制，跨平台需统一禁用:<>|? 及非分隔符位置的/和。
Windows下哪些字符绝对不能出现在路径里
Windows文件系统对路径字符有硬性限制，:、<、>、|、?、*、"、 （空字符）这8个字符在任何位置都非法——哪怕只是出现在字符串里，还没传给CreateFile或std::filesystem::path，就已经注定无法构成有效路径。
注意：/ 和 在Windows上都可作路径分隔符，但是默认；. 和 .. 是合法的相对路径成分，不是非法字符； （空格）完全合法，别误判。
-
\?前缀路径（即“扩展长度路径”）仍受同样字符限制，只是绕过了260字符限制 - UWP应用还额外禁止
#、%等，但传统桌面程序不在此列 - 不要用正则匹配“所有非法字符”，直接查表更可靠、更高效
用std::string_view快速扫描非法字符
C++17起推荐用std::string_view避免拷贝，配合std::find_first_of做一次遍历即可。别写循环逐个switch，也别用std::regex——开销大且易漏边界。
bool has_invalid_win_char(std::string_view path) {
static constexpr std::string_view invalid = ":<>|?*";
return path.find_first_of(invalid) != std::string_view::npos;
}
- 没检查
std::string_view构造时已截断到首个find_first_of自然不会看到它；若原始输入是C风格字符串，需先确认是否含内嵌 - Linux/macOS不用此函数——它们只禁止
/，但/是路径分隔符，本就不该出现在文件名中 - 如果路径来自用户输入，建议在调用此函数前先
trim首尾空格和
跨平台判断：别只盯着Windows
真正需要跨平台时，不能只过滤Windows非法字符。Linux/POSIX系统实际只禁止<p>真正需要跨平台时，不能只过滤Windows非法字符。Linux/POSIX系统实际只禁止<code> 和/，但/在文件名里出现就等于路径被意外分割，逻辑上不可接受；macOS还额外拒绝:（因HFS+历史原因，虽APFS已支持，但API层仍普遍拦截）。
/，但/在文件名里出现就等于路径被意外分割，逻辑上不可接受；macOS还额外拒绝:（因HFS+历史原因，虽APFS已支持，但API层仍普遍拦截）。
立即学习“C++免费学习笔记（深入）”；
- 统一策略：把
:<>|?*列为绝对禁止；/和在非分隔符位置出现即视为非法（如"a/b.txt"中/是分隔符，但"file/name.txt"中/在文件名里就是错的） -
std::filesystem::path构造时会静默截断.或 - 第三方库如Boost.Filesystem也同理，底层仍是调用系统API，提前校验比事后捕获
std::filesystem::filesystem_error更可控
容易被忽略的边界情况
路径合法性不是纯字符串问题，还牵扯编码和API行为。比如UTF-8编码的路径在Windows API中需转为UTF-16，而某些代理对（surrogate pair）若被拆开，可能产生看似合法实则无法创建的路径；又比如CON、AUX这类设备名，在Windows中无论加不加扩展名都非法。
- 仅检查字符不够：还需用
std::filesystem::exists()或GetFileAttributes确认父目录是否存在——否则"C:missing oo.txt"字符全合法，但路径整体无效 - 不要忘了长路径前缀：
"\\?\C:\..."开头的路径，其后的:仍非法，但开头的\?本身是合法前缀，不能当成非法字符误杀 - 用户可能输入
"../foo"，..本身合法，但拼接后可能越权访问上级目录——这是权限问题，不属于“字符非法”范畴，别混为一谈
字符校验只是第一道关卡，后面还有编码、长度、权限、保留名三重校验要跟上。单靠一个find_first_of解决不了全部问题。
