POSIX文件名合法字符范围是除/和\0外的任意字节，且非空、不等于.或..；需逐字节检查，禁止使用c_str()或find()等易失效方法，避免依赖编码转换。
POSIX文件名合法字符范围是什么
POSIX标准对文件名只做了极简约束：. 和 .. 是保留名，其余任何字节只要不是 /（路径分隔符）和 \0（空字节），都算合法。也就是说，foo bar、test\0x（含空字节则非法）、file:name、?.txt 全部符合POSIX命名标准——只要它们不出现在路径组件里包含 / 或结尾是 \0。
注意：这不是“推荐命名”，而是“系统允许创建”。很多工具链（如make、shell glob）在遇到空格、冒号、控制字符时会出问题，但内核层面不拦你。
-
/绝对不能出现在文件名中——它只用于分隔路径组件 -
\0会导致C字符串截断，open()等系统调用会直接失败，且无法通过常规字符串操作检测（需检查原始字节流） -
.和..是特殊目录项，作为独立文件名时虽可创建（如touch .会报错，但touch './.'在某些挂载下可能成功），但行为不可靠，应主动拒绝
如何用C++安全检查一个std::string是否为合法POSIX文件名
核心是逐字节扫描，而不是依赖locale或宽字符转换——POSIX文件名是字节序列，与编码无关。别用 std::wstring 或 std::codecvt_utf8，那只会引入误判。
示例检查逻辑：
立即学习“C++免费学习笔记（深入）”；
bool is_valid_posix_filename(const std::string& name) {
if (name.empty()) return false;
if (name == "." || name == "..") return false;
for (unsigned char c : name) {
if (c == '/' || c == '\0') return false;
}
return true;
}
- 必须用
unsigned char遍历——避免符号扩展导致0xFF被当成-1错判 - 不要调用
strnlen(name.c_str(), ...)——如果字符串含\0，c_str()会提前截断，检测失效 - 不要用
find()查'/'——它只找第一个，而你需要确认整个字符串都不含非法字节
为什么stat()或access()不能代替字符串检查
它们查的是文件是否存在或是否有权限，不是命名合法性。比如：name = "a/b" 是非法文件名（含 /），但 stat("a/b", &st) 实际查的是子目录 a 下的文件 b，完全绕过校验；又比如 name = "foo\0bar"，传给 open() 时只看到 "foo"，后续字节被丢弃，根本不会报“非法名称”错误。
-
open()失败原因可能是权限、目录不存在、磁盘满……不一定是名字非法 - 即使名字非法，只要路径存在且有写权限，
open("illegal/name", O_CREAT)可能创建出两个文件：illegal目录和name文件——因为斜杠被解释为路径分隔 - 真正暴露非法字符的系统调用是
mkdir()或creat()对单个组件的操作，但代价高、副作用大，不适合预检
实际项目中该不该强制过滤非ASCII字符
POSIX没禁止UTF-8或多字节字符，Linux ext4、XFS都支持，但Windows（通过WSL或Samba）和旧版macOS（HFS+）可能损坏或静默转码。如果你的程序要跨平台或对接遗留脚本，建议额外限制：
- 若目标环境明确是纯Linux服务器，放行所有非
/\0字节即可 - 若要兼容shell脚本（
for f in *）、Makefile或Git，避开空格、$、(、)、>、<、|、;、`、~、*、?、[、]更稳妥 - 拒绝控制字符（
\x00-\x1F、\x7F）是通用好习惯——它们在终端里可能触发乱码或命令注入
最常被忽略的点：检查必须在构造完整路径前做，而不是对 basename(path) 提取后再验——因为提取过程本身可能因非法字节崩掉或出错。
