fix: preserve URL scheme when building file URLs

[GongHeng2017]

Changed the URL construction logic to preserve the original URL's scheme and host instead of assuming all URLs are local files. Previously, QUrl::fromLocalFile() was used which would convert any URL to a file:// scheme. Now we maintain the original scheme by creating a copy of the input URL and only modifying its path component.

This fix ensures compatibility with various URL schemes (like network protocols, custom schemes) that may be used in the file enumeration system. The change maintains the URL structure while properly constructing the path for child entries.

Log: Fixed URL scheme preservation in file enumeration

Influence:

1. Test file enumeration with different URL schemes (file://, smb://, etc.)
2. Verify that child file URLs maintain correct scheme and host information
3. Check that network file shares work correctly with the new URL construction
4. Test with custom URL schemes to ensure they are preserved
5. Verify that local file paths still work correctly

fix: 构建文件URL时保留URL方案

修改了URL构建逻辑，保留原始URL的方案和主机信息，而不是假定所有URL都是本
地文件。之前使用QUrl::fromLocalFile()会将任何URL转换为file://方案。现在 通过创建输入URL的副本并仅修改其路径组件来维护原始方案。

此修复确保与文件枚举系统中可能使用的各种URL方案（如网络协议、自定义方
案）的兼容性。该更改在正确构建子条目路径的同时维护URL结构。

Log: 修复文件枚举中的URL方案保留问题

Influence:

1. 使用不同的URL方案（file://、smb://等）测试文件枚举
2. 验证子文件URL是否保持正确的方案和主机信息
3. 检查网络文件共享是否与新的URL构建方式正常工作
4. 使用自定义URL方案测试以确保它们被保留
5. 验证本地文件路径是否仍然正常工作

Bug: https://pms.uniontech.com/bug-view-352359.htm

[deepin-ci-robot]

deepin pr auto review

这段代码修改的主要目的是在构建子文件或目录的URL时，保留原始URL的scheme（协议）和host（主机），而不是简单地将其视为本地文件（即总是使用file://）。这对于支持非本地文件系统（如网络挂载、FTP、SMB等）非常重要。

以下是对这段代码的审查意见，包括语法逻辑、代码质量、代码性能和代码安全方面的分析：

1. 语法逻辑

• 改进点：原代码直接使用 QUrl::fromLocalFile(path)，这会强制将URL的 scheme 设置为 file。如果原始 url 是 smb://server/share，原代码会将其错误地转换为 file:///server/share/...，导致后续文件操作失败。新代码通过复制原始 url 并仅修改其 path，正确保留了协议和主机信息，逻辑是正确的。
• 潜在逻辑风险：代码假设 url 的路径部分是可以被直接替换的。这在大多数情况下是成立的，但如果原始 URL 包含 Fragment（锚点，如 #section）或 Query（查询参数，如 ?id=1），setPath 可能不会按预期工作，或者需要保留这些部分。不过，对于文件枚举器（Denumerator）场景，通常处理的是目录路径，URL 中一般不包含这些额外信息，因此风险较低。

2. 代码质量

• 可读性：代码添加了注释 // 保留原始 URL 的 scheme 和 host...，这非常好，解释了为什么要进行修改，有助于后续维护。
• 健壮性：
  • 代码直接使用了 QString(fileName)。如果 fileName 是相对路径（例如 ../file.txt）或者包含 URL 编码字符（例如空格变为 %20），setPath 的行为需要确认。通常 QUrl::setPath 会自动处理编码，但最好确保传入的 path 是干净的。
  • url.userInfo() 的处理逻辑保留了下来。如果 url 是非本地协议（如 SMB），userInfo 可能包含认证信息，这里的拼接逻辑看起来是特定业务逻辑（originPath::），需确保这种拼接在非本地协议下依然有效。

3. 代码性能

• 性能影响：
  • 原代码：QUrl::fromLocalFile(path) 涉及一次 URL 解析和构造。
  • 新代码：QUrl nextUrl = url;（拷贝构造）+ nextUrl.setPath(path)。
  • QUrl 的拷贝构造通常是浅拷贝（隐式共享），开销很小。setPath 会涉及字符串处理和重新计算规范化。两者性能差异极小，可以忽略不计。新代码为了正确性牺牲微乎其微的性能是值得的。

4. 代码安全

• 路径拼接安全：
  • 上文代码片段中未展示 dirPath 的来源，但 dirPath + "/" + QString(fileName) 这种字符串拼接方式，如果 fileName 包含恶意路径（如 ../../etc/passwd），可能会导致路径遍历攻击。
  • 建议：虽然这是底层库代码，通常假设调用者传入合法的 fileName，但在安全敏感场景下，建议在使用 fileName 前进行校验，确保它不包含路径遍历字符（如 ../）。
• URL 编码：
  • QString::fromLatin1 的使用是安全的，前提是 fileName 确实是 Latin-1 编码或纯 ASCII。如果文件名包含非 Latin-1 字符（如中文），QString::fromLatin1 可能会导致乱码。
  • 建议：检查 fileName 的原始编码来源。如果它是 char* 且来自系统调用（如 readdir），在 Linux 上通常是 UTF-8，建议使用 QString::fromUtf8。如果是 Windows，可能是本地编码。如果 fileName 已经是 QString，则不需要转换。代码中使用了 QString(fileName)，这依赖于 char* 的默认转换（通常是 fromUtf8 或 fromLocal8Bit），而 userInfo 拼接时用了 fromLatin1，这里存在编码不一致的风险。

总结与改进建议

这段修改在逻辑上是正确且必要的，修复了非本地文件系统支持的问题。

改进建议：

1. 编码一致性检查：
   检查 fileName 的实际编码。如果是 UTF-8，建议统一使用 QString::fromUtf8(fileName)，避免使用 QString::fromLatin1 导致乱码。

2. 路径规范化：
   在拼接 path 之后，可以调用 QDir::cleanPath(path) 来移除多余的 . 和 ..，防止路径遍历，并确保路径格式规范。

   path = QDir::cleanPath(path);

3. 代码片段优化建议：

   // ... (前面的 path 拼接逻辑)
   
   // 规范化路径，移除冗余的分隔符和解析相对路径
   path = QDir::cleanPath(path);
   
   // 保留原始 URL 的 scheme、host、query 等，仅更新路径
   QUrl nextUrl = url;
   nextUrl.setPath(path);
   
   // 处理 userInfo
   if (url.userInfo().startsWith("originPath::")) {
       // 确保文件名编码正确，建议使用 fromUtf8 如果 fileName 是 UTF-8 字节流
       // 或者直接使用 QString(fileName) 如果构造函数能正确处理
       nextUrl.setUserInfo(url.userInfo() + "/" + QString::fromUtf8(fileName));
   }

总体来说，这是一个高质量的修复，主要注意文件名编码和路径安全性即可。

[deepin-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: GongHeng2017, Johnson-zs, max-lvs

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• debian/deepin/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[GongHeng2017]

/merge

[deepin-bot]

This pr cannot be merged! (status: unstable)

[GongHeng2017]

/forcemerge

[deepin-bot]

This pr force merged! (status: unstable)