std::filesystem::path 不能直接当 uri 用，因其是操作系统路径抽象，而 uri 需满足 file:// 协议头、绝对路径、正斜杠分隔、空格及非 ascii 字符 percent-encode 等 rfc 3986 要求，直接调用 .string() 或 .generic_string() 会遗漏编码、协议头和根处理，尤其 windows 下易生成非法 uri 如 file://c:path。
为什么 std::filesystem::path 不能直接当 URI 用
因为 std::filesystem::path 是操作系统路径抽象，而 URI（如 file:///home/user/doc.txt）有固定语法：必须以 file:// 开头、路径需为绝对路径、空格和非 ASCII 字符要 percent-encode、分隔符强制为正斜杠 /。直接调用 .string() 或 .generic_string() 会漏掉编码、协议头、根处理，尤其在 Windows 上容易生成 file://C:path 这种非法 URI（反斜杠未转义、盘符格式不合规）。
- Windows 路径
C:Users est file.txt→ 正确 URI 是file:///C:/Users/test%20file.txt（三斜杠 + 正斜杠 + 编码） - Linux 路径
/home/用户/文档.txt→ 必须 encode 成file:///home/%E7%94%A8%E6%88%B7/%E6%96%87%E6%A1%A3.txt -
std::filesystem::path的.generic_string()在 Windows 返回C:/...，但缺少协议头和编码；在 Linux 返回/...，仍缺协议头
手动构造 file:// URI 的安全步骤
别依赖第三方 URI 库（除非项目已引入），用标准库组合完成：先归一化路径，再拼协议头，最后对路径部分做 percent-encode。关键点是只对路径段（path().string() 的结果）编码，不编码协议或主机部分。
- 用
p = std::filesystem::absolute(p).lexically_normal()确保路径绝对且无../. - 对 Windows 路径，把盘符
C:转成/C:（URI 要求根路径以/开头），再将所有替换为/ - 用自定义函数对路径字符串做 percent-encode：只编码 ASCII 控制字符、空格、
%、非字母数字及-._~以外的字符（RFC 3986） - 拼接：
"file://" + (is_windows ? "/" : "") + encoded_path—— Windows 必须加开头的/，形成三斜杠结构
示例片段：
std::string to_uri(const std::filesystem::path& p) {
auto abs = std::filesystem::absolute(p).lexically_normal();
std::string path_str = abs.generic_string();
#ifdef _WIN32
if (abs.has_root_name()) {
auto root = abs.root_name().string();
if (root.size() >= 2 && root[1] == ':') { // C:
path_str = "/" + root + abs.root_directory().string() + abs.relative_path().generic_string();
}
}
std::replace(path_str.begin(), path_str.end(), '\', '/');
#endif
return "file://" + percent_encode(path_str);
}
从 URI 解析回 std::filesystem::path 的边界处理
URI 可能不规范：多斜杠、末尾斜杠、大小写混用的 FILE://、缺失 host（file:/// 合法，file:/ 不合法）。重点不是“解析协议”，而是安全提取路径并还原成本地格式。
- 先检查前缀是否为
"file://"（忽略大小写），否则返回空path - 跳过
file://后，若下一个字符是/（即file:///），说明是本地绝对路径；若没有，则是不合规 URI，拒绝处理 - 提取
file://之后的所有内容，去掉开头可能的/（Windows 盘符场景下保留第一个/后的C:） - 对路径部分做 percent-decode（注意：只解
%XX，不碰原始/） - 在 Windows 上，若解码后字符串形如
/C:/...，截去开头/再构造path；Linux 直接构造
错误示例：file:/C:/bad（少一个 /）应拒绝，而非强行补全——这会导致误判网络路径。
Windows 上 file:// URI 的盘符与 UNC 路径兼容性陷阱
标准 file:// URI 对 Windows 盘符的支持是事实标准（非 RFC 强制），但行为分裂：Chromium 和 Firefox 接受 file:///C:/x，IE 却要求 file://C:/x（双斜杠）。更麻烦的是 UNC 路径：file://server/share 是合法 URI，但它对应 \servershare，不是本地路径。
- 转换时，明确区分：本地盘符路径 →
file:///X:/...；UNC 路径 →file://server/share/...（注意只有两个斜杠） - 用
std::filesystem::path判断：p.is_absolute()且!p.has_root_name()可能是 UNC（Windows 下\servershare的root_name()是\server） - 不要对 UNC 路径加第三个
/，否则变成file:///server/share，被解释为本地目录C:servershare - percent-encode 的实现必须支持宽字符 decode（如 UTF-8 输入），否则中文路径在 Windows 控制台环境下会乱码
最易被忽略的一点：std::filesystem::path 构造函数接受 UTF-8 字符串（C++17 起），但 Windows API 内部用 UTF-16；只要输入是合法 UTF-8，标准库会正确转换——不必手动调用 MultiByteToWideChar。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
