Windows路径中直接被系统拒绝的字符是<、>、:、"、/、、|、?、*共9个，且空字符（ ）必须一并过滤；Linux/macOS仅禁止 和/，但需额外排除ASCII控制字符（0x00–0x1F）及DEL（0x7F）。
Windows路径中哪些字符会被系统直接拒绝
Windows在创建文件或目录时，会直接拒绝包含 <、>、:、"、/、、|、?、* 这9个字符的路径（无论出现在哪一级目录名中）。哪怕只是字符串检查，只要含其中任意一个，CreateFileA 或 std::filesystem::create_directories 就会失败并返回 ERROR_INVALID_NAME。注意： （空字符）虽未列在官方禁用列表里，但C风格字符串遇到它就截断，实际路径被截短，必须一并过滤。
如何安全地逐字节扫描路径字符串
C++标准库不提供“跨平台路径合法性校验”接口，得自己遍历。关键点不是“是否打印”，而是“是否被OS内核拒绝”。推荐用 unsigned char 强制转换后比较，避免符号扩展问题：
bool has_invalid_win_char(const std::string& path) {
for (unsigned char c : path) {
if (c == 0 || c == '<' || c == '>' || c == ':' || c == '"' ||
c == '/' || c == '\' || c == '|' || c == '?' || c == '*') {
return true;
}
}
return false;
}
注意：/ 在Windows上虽能被API接受（内部转为 ），但某些旧工具链或网络共享路径中仍可能出问题，建议统一视为非法；\? 前缀路径是例外，但那是绕过API限制的特殊模式，普通路径校验不考虑。
Linux/macOS下真正要防的是什么
Linux和macOS对路径字符限制极松——除 <p>Linux和macOS对路径字符限制极松——除 <code> 和 / 外，其余字符（包括控制字符、emoji、Unicode符号）都允许。但实际使用中，以下情况会出问题：
/ 外，其余字符（包括控制字符、emoji、Unicode符号）都允许。但实际使用中，以下情况会出问题：
立即学习“C++免费学习笔记（深入）”；
-
open()传入的路径被截断 -
/是路径分隔符，不能出现在文件名中（否则解析成多级目录） - 终端显示异常或脚本解析失败：如
等ASCII控制字符（0x00–0x1F，不含/） - 某些备份/同步工具（如rsync、Time Machine）对UTF-8非法序列敏感，需额外验证编码
所以Linux路径校验重点不是“禁止字符”，而是“确保无嵌入NUL、无斜杠、无控制字符”——用 std::isprint(static_cast<unsigned char>(c))</unsigned> 不够，因为它把 0x7F（DEL）也判为可打印，而DEL在部分shell中会触发删除行为，建议显式排除 0x00–0x1F 和 0x7F。
跨平台校验函数怎么写才不踩坑
别试图用同一套规则覆盖所有系统。最稳妥做法是按目标平台分流：
- 编译期确定平台：用
#ifdef _WIN32分支 - 运行时不确定？优先按Windows规则严查（因为它的限制最硬性），再对非Windows补上
/检查 - 不要依赖
std::filesystem::path::has_filename()等接口——它们只做语法解析，不校验OS级合法性 - 注意宽字符路径（
std::wstring）：Windows API常用UTF-16，需对每个wchar_t做同样判断，且L' '同样致命
真实项目里，路径校验常被忽略，直到用户上传含 CON.txt 或 AUX.log 这类保留名的文件才暴露——这些名字本身合法，但Windows禁止创建，属于另一层限制，不在字符级校验范围内。
