Windows路径非法字符包括: " / | ? *、ASCII控制字符（0x00–0x1F）及结尾空格/点，设备名如CON/PRN/AUX/NUL（不区分大小写，含扩展名或尾部空格）也非法；std::filesystem不校验字符合法性，需手动预检。
Windows 下 C++ 判断路径是否含非法字符
Windows 对文件名和路径有明确的保留字符集，CreateFile、std::filesystem::create_directories 等调用失败时，往往不是因为权限或磁盘满，而是路径里混入了系统禁止使用的字符。这些字符不报“非法字符”错误，只返回 ERROR_INVALID_NAME 或抛出 std::filesystem::filesystem_error，排查起来很隐晦。
核心非法字符包括： <code>> : " / | ? *，以及 ASCII 控制字符（0x00–0x1F）和结尾空格/点（如 "file. " 或 "con." 这类设备名变体）。
- 使用
std::filesystem::path时，path::string()或path::u8string()返回的字符串需逐字符检查，不能依赖path::has_filename()等接口判断合法性 - 注意
std::filesystem在 C++17 中不校验字符合法性，它只做路径解析；真正触发校验的是系统 API 调用（如exists()、create_directories()） - 设备名如
"CON"、"PRN"、"AUX"、"NUL"及其加扩展名或后缀空格的形式（"CON.txt"、"CON "）也属于非法，需额外比对（不区分大小写）
跨平台文件名有效性检查函数怎么写
Linux/macOS 对文件名限制极小（仅禁止 / 和 ），但为统一行为、避免 Windows 上静默失败，建议在所有平台都执行 Windows 风格的预检——尤其当程序目标是双平台部署或生成用户可下载的文件时。
一个轻量、无依赖的检查函数示例：
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
bool is_valid_filename(const std::string& name) {
if (name.empty()) return false;
// 检查控制字符和 Windows 非法字符
for (unsigned char c : name) {
if (c == 0 || c <= 0x1F || c == '"' || c == '<' || c == '>' ||
c == '|' || c == '?' || c == '*' || c == ':' || c == '/' || c == '\') {
return false;
}
}
// 检查结尾空格或点（Windows 会截断，导致重名）
if (name.back() == ' ' || name.back() == '.') return false;
// 检查设备名（不区分大小写，忽略扩展名和尾部空格）
static const std::vector<std::string> reserved = {"con", "prn", "aux", "nul",
"com1", "com2", "com3", "com4",
"com5", "com6", "com7", "com8",
"com9", "lpt1", "lpt2", "lpt3",
"lpt4", "lpt5", "lpt6", "lpt7",
"lpt8", "lpt9"};
std::string lower = name;
std::transform(lower.begin(), lower.end(), lower.begin(), ::tolower);
size_t dot_pos = lower.find('.');
std::string base = dot_pos != std::string::npos ? lower.substr(0, dot_pos) : lower;
// 去除 base 末尾空格
base.erase(base.find_last_not_of(' ') + 1);
if (std::find(reserved.begin(), reserved.end(), base) != reserved.end()) {
return false;
}
return true;
}
该函数不检查路径长度（MAX_PATH）、驱动器前缀或 UNC 路径结构，仅聚焦于「单个文件名片段」的字符有效性。若用于完整路径，需先用 std::filesystem::path::filename() 提取最后一段再传入。
std::filesystem::path::has_filename() 为什么不能代替字符检查
has_filename() 只判断路径对象是否包含非空文件名组件（即是否有类似 "foo.txt" 的部分），完全不涉及内容合法性。例如：std::filesystem::path("a<b.txt> 会成功构造，<code>.has_filename() 返回 true，但后续调用 .exists() 就会抛异常。
-
std::filesystem::path构造函数不做任何验证，它只是字符串切分器 -
path::native()或path::generic_string()输出的字符串仍含非法字符，直接传给CreateFileA必然失败 - 想提前发现风险，必须在构造
path后、调用 IO 函数前，对其filename().string()执行独立字符扫描
实际项目中容易漏掉的三个点
很多团队在做文件保存逻辑时，只校验空值或长度，却忽略这些细节：
- 用户输入的文件名可能带 Unicode BOM 或零宽空格（
u200B），它们不可见但属于非法控制字符，需在检查前用std::erase_if(str, [](char c) { return static_cast<unsigned char>(c) 清理</unsigned> - Web 表单提交的文件名经过 URL 解码后可能还原出
%00或%2F，服务端未 decode 就拼接路径，会导致看似合法实则含/ - 日志或配置中硬编码的路径模板（如
"logs/{date}.log"）若{date}插入了非法字符（如用户可控的日期格式含冒号），整个路径就失效——这类问题不会在编译期暴露，只能靠运行时检查
最稳妥的做法：所有外部输入的文件名，在组装进 std::filesystem::path 前，强制过一遍字符白名单过滤（只保留字母、数字、下划线、短横、点），而不是依赖事后异常捕获。毕竟，文件操作失败的成本远高于一次字符串扫描。
