我何时应该使用NSURL而不是NSString,反之亦然?

时间:2022-06-18 00:14:25

This is not a question about a pertinent problem. It's a question by which I try to deepen my understanding of Objective-C or more specific Cocoa Foundation.

这不是关于相关问题的问题。这是一个我试图加深对Objective-C或更具体的Cocoa Foundation的理解的问题。

When dealing with uploading and download files from a server to my apps, I'm constantly torn between using NSURL or NSString for all things path related. Of course when there's an existing API I just use it according to the specs. But when I store my own paths or create custom classes that deal with them, I'm confused which of the two would be the better pick.

在处理从服务器上传和下载文件到我的应用程序时,我经常在使用NSURL或NSString来解决与路径相关的所有问题。当然,当有现有的API时,我只是根据规格使用它。但是当我存储自己的路径或创建处理它们的自定义类时,我很困惑这两个中哪一个会更好。

NSString is used everywhere and it has convenience methods like stringByAppendingPathComponent: and stringByAppendingPathExtension:. I can easily convert to NSURL by creating a new instance with [NSURL URLWithString:@"string"] and the other way around by calling [url path] on an NSURL instance. But the difference is there for a reason, right?

NSString在任何地方都使用,它有方便的方法,如stringByAppendingPathComponent:和stringByAppendingPathExtension:。我可以通过使用[NSURL URLWithString:@“string”]创建一个新实例,然后通过在NSURL实例上调用[url path]来轻松转换为NSURL。但差异是有原因的,对吧?

My confusion grows when I look at header files of something like NSFileManager. These two methods are pretty close together:

当我查看像NSFileManager这样的头文件时,我的困惑就会增加。这两种方法非常接近:

- (BOOL)copyItemAtPath:(NSString *)srcPath toPath:(NSString *)dstPath error:(NSError **)error;
- (BOOL)copyItemAtURL:(NSURL *)srcURL toURL:(NSURL *)dstURL error:(NSError **)error NS_AVAILABLE(10_6, 4_0);

Why would I choose to use one over the other, especially when conversions between the two are made so easily? And why does Apple go through the trouble of creating near-identical APIs for using both data types?

为什么我会选择使用一个而不是另一个,特别是当两者之间的转换如此容易时?为什么Apple要为使用这两种数据类型创建几乎相同的API?

If someone has the deeper insight for when to use NSURL instead of NSString for your own classes handling file paths and remote urls, please do share! Cheers.

如果有人对您自己的处理文件路径和远程URL的类使用NSURL而不是NSString有更深入的了解,请分享!干杯。

2 个解决方案

#1


4  

Generally for path related operations you should prefer NSURL over NSString because the path information can be stored more efficiently in NSURL (according to the class reference for NSFileManager). So I would recommend that for your APIs you use also NSURL.

通常对于路径相关的操作,您应该更喜欢NSURL而不是NSString,因为路径信息可以更有效地存储在NSURL中(根据NSFileManager的类引用)。所以我建议您使用NSURL作为API。

Also NSURL has URLByAppendingPathComponent: and URLByAppendingPathExtension: so convenience is served as well :-)

NSURL还有URLByAppendingPathComponent:和URLByAppendingPathExtension:因此也提供了便利:-)

#2


8  

NSUrl knows how to handle virtually any king of urls — not just Web-adresses and splits it into easy accessible chunks:

NSUrl知道如何处理几乎任何网址王 - 不仅仅是网址,而是将其拆分为易于访问的块:

  • protocol or scheme (http, ftp, telnet,ssh)
  • 协议或方案(http,ftp,telnet,ssh)

  • username and the password (for example for ssh: ssh://user:password@host.domain.org)
  • 用户名和密码(例如ssh:ssh:// user:password@host.domain.org)

  • host name
  • port
  • path
  • GET parameters

Now you can easily asks the url-object for this chunks, while in a string there might be the need for excessive if rules or complicated regex's.

现在你可以轻松地向url-object询问这个块,而在字符串中可能需要过多的if规则或复杂的正则表达式。

#1


4  

Generally for path related operations you should prefer NSURL over NSString because the path information can be stored more efficiently in NSURL (according to the class reference for NSFileManager). So I would recommend that for your APIs you use also NSURL.

通常对于路径相关的操作,您应该更喜欢NSURL而不是NSString,因为路径信息可以更有效地存储在NSURL中(根据NSFileManager的类引用)。所以我建议您使用NSURL作为API。

Also NSURL has URLByAppendingPathComponent: and URLByAppendingPathExtension: so convenience is served as well :-)

NSURL还有URLByAppendingPathComponent:和URLByAppendingPathExtension:因此也提供了便利:-)

#2


8  

NSUrl knows how to handle virtually any king of urls — not just Web-adresses and splits it into easy accessible chunks:

NSUrl知道如何处理几乎任何网址王 - 不仅仅是网址,而是将其拆分为易于访问的块:

  • protocol or scheme (http, ftp, telnet,ssh)
  • 协议或方案(http,ftp,telnet,ssh)

  • username and the password (for example for ssh: ssh://user:password@host.domain.org)
  • 用户名和密码(例如ssh:ssh:// user:password@host.domain.org)

  • host name
  • port
  • path
  • GET parameters

Now you can easily asks the url-object for this chunks, while in a string there might be the need for excessive if rules or complicated regex's.

现在你可以轻松地向url-object询问这个块,而在字符串中可能需要过多的if规则或复杂的正则表达式。