PathCchValidate是Windows 8+验证路径合法性的首选API，检查控制字符、保留设备名、非法结尾与字符、长度超限；不检查文件存在性，需链接Pathcch.lib。
Windows下用 PathCchValidate 检查路径合法性
Windows API 提供了专门验证路径字符串安全性的函数，PathCchValidate 是最直接的选择——它不仅检查非法控制字符（如 、– ），还会识别保留设备名（CON、AUX 等）、无效结尾（. 或 ..）、非法字符（ : " | ? *）以及长度超限问题。
注意：该函数要求 Windows 8+ 或引入 PathCch.h 并链接 Pathcch.lib；若目标系统较老，需降级使用 PathIsValid（仅基础检查，不防控制字符）。
示例调用：
#include <PathCch.h>
HRESULT hr = PathCchValidate(L"C:\test.txt", PATHCCH_ALLOW_LONG_PATH);
if (FAILED(hr)) {
// hr == HRESULT_FROM_WIN32(ERROR_INVALID_NAME) 表示含非法字符或格式错误
}
-
PATHCCH_ALLOW_LONG_PATH允许 \? 前缀长路径，不加则默认限制 MAX_PATH - 返回
ERROR_INVALID_NAME通常意味着存在控制字符、非法符号或空字符截断 - 该函数不检查文件系统实际是否存在，只做字符串层面合规性判断
跨平台手动扫描控制字符的通用做法
如果不能依赖 Windows API，或需在 Linux/macOS 下保持一致行为，就得自己遍历字符串检测 ASCII 控制字符（U+0000–U+001F）和删除符 U+007F。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
关键点不是“哪些字符非法”，而是“哪些必须禁止”：路径中出现 会提前截断 C 字符串；
、
、 在日志、shell 解析或 GUI 显示时极易引发歧义； （垂直制表）、 （换页）虽少见，但 POSIX 路径规范明确禁止非打印字符。
示例逻辑（C++17）：
bool hasControlChar(const std::wstring& path) {
for (wchar_t c : path) {
if (c == L' ' || (c >= L' ' && c <= L' ') || c == L'') {
return true;
}
}
return false;
}
- 用
std::wstring处理宽路径（Windows 默认），Linux 下可用std::string+unsigned char判断 - 不要只过滤
（响铃）或（ESC）在终端里可能触发意外行为 - 注意：Unicode 中的控制字符（如 ZWSP U+200B）不属于此范围，但若业务涉及文件名展示，也应单独考虑
为什么 std::filesystem::path 不报错不代表路径安全
std::filesystem::path 构造函数接受任意字符串，包括含控制字符的——它只是封装，不做校验。调用 .string() 或 .wstring() 后，这些字符依然存在；一旦传给系统调用（如 CreateFile、open），结果取决于底层 OS 行为：Windows 直接拒绝，Linux 可能创建出不可见/难删除的文件。
- 构造
std::filesystem::path成功 ≠ 路径可创建或可访问 -
std::filesystem::exists(p)对含控制字符的路径可能返回false（即使文件存在），因为内核层已拒绝解析 - 若需兼容性，应在构造前先用前述方法过滤或拒绝，而非依赖
filesystem的异常抛出（它通常不抛）
常见误判场景：空格、点、Unicode 分隔符
开发者常把“看起来奇怪”等同于“非法”，但空格、点、Unicode 连字符（如 U+2010）本身是合法路径字符；真正危险的是控制类、不可见、易被 shell 或 API 截断的字符。
- 路径末尾空格或点（
C:dir或C: ile.）在 Windows 上会被自动修剪，导致意外交互——这不是控制字符问题，但属于路径规范化盲区 - Linux 下
/tmp/abc def实际传给open()时，/tmp/abc，极易造成路径穿越或覆盖 - 别用正则匹配 “非法字符列表” 来代替逐字节/码点检查——多字节 UTF-8 中，控制字符不会跨字节，但正则引擎若未设
u标志，可能漏判或误判
最稳妥的做法是：Windows 优先用 PathCchValidate，其他平台走手动控制字符扫描，并始终把 和 当作硬性红线——它们在任何上下文中都没有正当用途。其他边界情况（如保留名、长度）视目标平台和部署环境决定是否叠加检查。
