NSFileManager 使用 NSURL 不一致的原因是什么？答案

【问题标题】：What is the reason for NSFileManager's inconsistent use of NSURL?NSFileManager 使用 NSURL 不一致的原因是什么？
【发布时间】：2012-06-03 08:28:04
【问题描述】：

我在某处读到，Apple 鼓励在路径和文件位置方面使用 NSURL 而不是 NSString，这在新的（er）API 中变得越来越明显 - 如果我错了，请纠正我。这个Stack Overflow question 专门处理这个话题。

但是，我注意到某些 API 在使用 NSURL 和 NSString 方面似乎不一致 - 特别是 NSFileManager。例如，NSFileManager 有一个方法 fileExistsAtPath:（它以 NSString 作为唯一的参数），但没有等效的方法以 NSURL 作为参数。但是，要删除文件，有一个采用 NSString 的方法和一个采用 NSURL 的等效方法。

这种差异是有原因的还是这种差异在历史上有所增长？

【问题讨论】：

标签： cocoa nsstring nsurl nsfilemanager

【解决方案1】：

可能是因为他们不鼓励使用存在检查。正如标题相当外交地说的那样：

以下方法的效用有限。尝试基于文件系统的当前状态或文件系统上的特定文件来预测行为会在文件系统竞争条件下鼓励奇怪的行为。尝试操作（如加载文件或创建目录）并优雅地处理错误比尝试提前确定操作是否成功要好得多。

【讨论】：

这是一个很好的观点。检查文件是否存在确实并不总是最好的方法。
如果你急于检查文件的存在（理想情况下你不应该这样做）， -[NSURL checkResourceIsReachableAndReturnError:] 是 -fileExistsAtPath: 的继承者：

【解决方案2】：

我很确定这只是 NSString 方面的一些遗留代码，因为看起来他们正在向 NSURL 进行大致称为文件操作的操作。

此外，您引用的 SO 问题很好地说明了为什么 NSURL 更受欢迎：

NSURL 也有 URLByAppendingPathComponent: 和 URLByAppendingPathExtension: 所以也很方便:-)

【讨论】：

stringByAppendingPathComponent: 和 stringByAppendingPathExtension: 存在的时间更长。 :-)
@Ahruman 啊，好吧，是的，看起来 NSString 的东西可能是遗留的。
@Ahruman 我在阅读其他 Stack Overflow 问题时也有同样的想法。有相当多的重叠，如果 Apple 想要推动 NSURL 的使用，这并不奇怪。