Percorso NSURL vs absoluteString

Ho visto molte domande su SO riguardo la conversione tra NSURL e NSString . Tutti implicano l’utilizzo di NSString *path = [myURL absoluteString]; o NSString *path = [myURL path]; . Qual è la differenza effettiva tra questi metodi? C’è un tempo in cui uno dovrebbe essere usato rispetto all’altro? Ho provato a consultare i documenti Apple , ma l’ho trovato meno che utile.

Sono abituato al fatto che gli URL vengano citati solo nelle discussioni relative a siti Web e altri argomenti relativi all’invio di informazioni tra macchine diverse e non vengano mai menzionati quando si tratta solo della struttura dei file su una singola macchina. Forse è da qui che parte della mia confusione proviene, dal momento che NSURL sembra essere il modo preferito per accedere ai file, indipendentemente dal fatto che quel file esista su una rete o sul dispositivo locale. O forse questo è un argomento totalmente non correlato. Non sono nemmeno sicuro.

Domanda 1:

Qual è la differenza effettiva tra questi metodi?

Analizziamo questa scrittura 6 righe di codice – 3 per un URL locale e 3 per http – e giochiamo un po ‘con loro.

Creiamo un NSURL usando il file:// scheme. Se ti chiedi perché ci sono file: 3 / dopo file: dovresti ricordare che esiste un URL completo di uno schema ( file:// e percorso assoluto o relativo (puoi trovare maggiori informazioni sulla creazione di URL in RFC 1808 a pagina 3 ). Usiamo un percorso assoluto che inizia con un / così che finiamo con /// .

 NSURL *aLocalURL = [NSURL URLWithString:@"file:///Users/dennis/Desktop/"]; NSLog(@"absolute string: %@", aLocalURL.absoluteString); NSLog(@"path: %@", aLocalURL.path); 

Produzione:

stringa assoluta: file: /// Users / dennis / Desktop /
percorso: / Users / dennis / Desktop

Quindi vediamo che absoluteString conosce ancora il suo schema mentre il path non ha più questa informazione.

Nota: path è un URL di file (directory) e, come lo stato dei documenti , la barra finale viene rimossa.


Ora diamo un’occhiata agli URL remoti. Con questo tipo di URL la maggior parte delle persone è più familiare. Lo creiamo usando la stessa procedura degli URL locali. Il nostro schema è ora http:// e il nostro path è www.apple.com/ .

 NSURL *anHTTPURL = [NSURL URLWithString:@"http://www.apple.com/"]; NSLog(@"absolute string: %@", anHTTPURL.absoluteString); NSLog(@"path: %@", anHTTPURL.path); 

Produzione:

stringa assoluta: http://www.apple.com/
sentiero: /

Di nuovo, vediamo che la stringa assoluta conosce ancora il suo schema, ma il path è ora / . Quindi il path sembra non essere un modo appropriato quando si lavora con URL remoti.

Tuttavia, quando abbiamo un URL come http://www.apple.com/index.html otteniamo

stringa assoluta: http://www.apple.com/index.html
percorso: /index.html

Leggere i documenti aiuta anche qui:

Per RFC 3986, la barra iniziale dopo la parte dell’autorità (nome host e porta) viene considerata parte del percorso.

Quindi il path è tutto all’inizio (e compreso) alla barra dopo l’ authority che è www.apple.com nel nostro caso.


Domanda 2

C’è un tempo in cui uno dovrebbe essere usato rispetto all’altro?

Dalla documentazione : (metodo: path )

Se questo object URL contiene un URL di file (come determinato con isFileURL), il valore di ritorno di questo metodo è adatto per l’input nei metodi di NSFileManager o NSPathUtilities.

A mio avviso, la frase indica chiaramente che è necessario utilizzare il path quando si lavora con NSFileManager o NSPathUtilities .


Conclusione:

Quando lavori con URL remoti tu (in generale) usi absoluteString , altrimenti il ​​risultato non è ciò che desideri (in generale).
Quando lavori con URL locali usa il path .

fonti:
http://www.ietf.org/rfc/rfc1808.txt
http://www.ietf.org/rfc/rfc3986.txt
Riferimento di class NSURL

Aggiungendo alla risposta di HAS – i documenti Apple menzionano che gli URL basati sul percorso sono in qualche modo più semplici, tuttavia gli URL di riferimento dei file hanno il vantaggio che il riferimento rimane valido se il file viene spostato o rinominato mentre la tua app è in esecuzione.

Dalla documentazione di “Accesso a file e directory”:

“Gli URL basati sul percorso sono più facili da manipolare, facili da eseguire il debug e sono generalmente preferiti da classi come NSFileManager. Un vantaggio degli URL di riferimento dei file è che sono meno fragili degli URL basati sul percorso mentre l’app è in esecuzione. sposta un file nel Finder, qualsiasi URL basato sul percorso che fa riferimento al file diventa immediatamente non valido e deve essere aggiornato al nuovo percorso, tuttavia, a condizione che il file venga spostato in un’altra posizione sullo stesso disco, il suo ID univoco non modifica e qualsiasi URL di riferimento per i file rimane valido. ”

https://developer.apple.com/library/content/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/AccessingFilesandDirectories/AccessingFilesandDirectories.html