Transformer des URL Final Cut Pro en paths unix
muqaddar
Administrateur
Salut les gens d'ici,
Je récupère des strings "url" (je dirait plutot des fausses url) de FCP.
Comme ça :
file://localhost/Users/crooner/Documents/Final%20Cut%20Pro%20Documents/Capture%20Scratch/Untitled%20Project%201/Untitled5
Je pensais pouvoir en faire une NSURL, mais ça n'en est pas une (enfin je crois qu'elles commencent par file:///).
Je dois transformer ce path en path UNIX : /Users/etc...
Mais avec :
NSURL *url = [NSURL URLWithString:moviePathUrl];
l'url n'est pas "standard" et return nil...
Alors, je dois passer par un moulinette pour arriver à mes fins ?
Je récupère des strings "url" (je dirait plutot des fausses url) de FCP.
Comme ça :
file://localhost/Users/crooner/Documents/Final%20Cut%20Pro%20Documents/Capture%20Scratch/Untitled%20Project%201/Untitled5
Je pensais pouvoir en faire une NSURL, mais ça n'en est pas une (enfin je crois qu'elles commencent par file:///).
Je dois transformer ce path en path UNIX : /Users/etc...
Mais avec :
NSURL *url = [NSURL URLWithString:moviePathUrl];
l'url n'est pas "standard" et return nil...
Alors, je dois passer par un moulinette pour arriver à mes fins ?
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
ma finalUrlString Url est :
file:///Users/crooner/Documents/Final%20Cut%20Pro%20Documents/Capture%20Scratch/Untitled%20Project%201/Untitled5
Il me semble que ça a l'air conforme a une URL classique ! non ?
Pourtant quand je fabrique l'url, "url" renvoie nil...
Quand j'écris la string url en absolu :
@file:///Users/crooner/Documents/Final%20Cut%20Pro%20Documents/Capture%20Scratch/Untitled%20Project%201/Untitled5
j'arrive à la convertir en NSURL.
et quand je récupère la même par une clé de dico (esxctement la même), je ne peux pas la convertir en NSURL.
Quel encoding faut-il ? Je trouve rien dans la doc...
Juste pour comparer l'url générée à partir du path Unix par Cocoa lui même avec celle que tu essayes de lui donner. Le temps du débug, quoi.
Parce qu'en effet ta finalUrlString semble une URL correcte et valide, mais rien ne vaut une comparaison avec ce qu'il attend réellement...
De même, même si pour moi les "%20" sont tout ce qu'il y a de plus valide dans uen URL (ça respecte la RFC sur les URLs et tout), peut-être que Cocoa n'apprécie pas (ce qui serait un tord de la part d'Apple mais au moins on saurait d'où vient le problème)
EDIT :
Si tu mets l'url en dur dans ton code et que ça passe, comme ton fichier .m est en encodage MacRoman, la NSString le sera aussi. Alors que récupérée du dico elle est en UTF8. Essaye de convertir en MacRoman avant de convertir de URL vers Path ?
En fait, c'est dans l'étape d'avant que ça foire : méthode URLWithString ! ;-)
Mais comment je la passe en MacRoman ma string, c'est ce que je cherche dans la doc NSString depuis tout à l'heure.
Tu utilises la bonne méthode, et ton url me semble correcte.
J'ai fait un test hier soir sur mon Mac, et j'ai pû correctement récupérer un NSURL...
Peux tu nous donner l'url extact, telle que tu la passes à la méthode ?
.
Bien sûr, voilà le code :
puis :
dans le debugger, la valeur de finalURLString est :
file:///Users/crooner/Documents/Final%20Cut%20Pro%20Documents/Capture%20Scratch/Untitled%20Project%201/Untitled6
mais url renvoie nil !
et si j'écris la string url ds le code (la même), et que je fais la même chose, mon URL est bien créée !
[tt]
NSString *urlString=[[NSString alloc] initWithData:[finalUrlString dataUsingEncoding:NSMacOSRomanStringEncoding allowLossyConversion:NO] encoding:NSMacOSRomanStringEncoding];
NSURL *url=[[NSURL alloc] initWithString:urlString];
[urlString release];
[/tt]
Le problème est que file:/// représente une adresse relative, et non absolue.
Or, lorsque tu lances ton prog, par défaut, il faudrait savoir quel est le current directory...
L'adresse que fournit FCP ("file://localhost..." dans ton 1er post) est absolue et me semble bonne.
.
@ Bru :
Avec la première adresse de FCP (file://), NSURL me renvoie nil aussi ! Pas chez toi ???
ça ne marchait pas p-e au début pour la même histoire !
J'ai pensé qu'il pouvait y avoir une histoire de caractère invisibles à la fin de la chaà®ne, mais apparemment non.
Si c'est le cas, envoie le moi, je vais tester sur ma machine...
.
Je crois que j'ai trouvé.
J'ai balayé ma chaine lettre par lettre et il semble y avoir des caractères vides à la fin... (12 en fait...). A moi de la nettoyer au début (qd je la stocke) ou à la fin.
Sinon, Bru, "file:///Users" ne serait pas une URL absolue ?
Je pensais que "file://" était le protocole, et que le 3e slash faisait donc partie du "chemin", qu'on pouvait donc comprendre comme "/Users" (donc URL absolue) ?
Pour simplifier, un(e) URL a grosso modo la structure suivante :
<protocole> [size=10pt]: //[/size] <iden-reseau> [size=10pt]/[/size] <chemin>
où :
<protocole> (ou schéma) est le protocole utilisé : peut être par exemple http, file, ftp, telnet, etc.
<iden-reseau> varie en fonction du protocole. Ca peut être un nom de machine (ftp, file), un domaine (http), etc.
<chemin> est le chemin d'accès à la ressource.
le ":" est un séparateur : il permet de séparer les différentes composantes de l'URL.
Dans le cadre du protocole file, on peut avoir :
chemin absolu : file://machine/Users/machin/Documents/fichier
chemin relatif absolu : il suffit de retirer la partie "machine" donc :
file:///Users/machin/Documents/fichier.
chemin relatif pur: il suffit de retirer la partie "domaine" et le chemin à partir de la racine du domaine :
file:Documents/fichier.
.
Je me permet quand même de "rajouter une couche" : qu'appelles-tu le "relatif-absolu" (qui est justement le cas qui est traité dans ce post) ?
Relatif à la machine (pas de machine précisée donc c'est automatiquement la machine courrante, soit la même chose que "localhost"), mais Absolu au sein de la machine (quel que soit le working directory ça part de la racine du disque dur) ?
C'est ce que j'avais compris de mon côté mais tu sembles dire que ce n'est pas ça puisque tu parles justement du working dir dans ton post précédent, donc ça doit être autre chose...
Ben, c'est vrai que je me suis un peu embrouillé avec ftp (qui lui en relatif absolu part du working-dir du user).
Il apparait bien, à relire la doc RFC, qu'en protocole file, c'est la racine du disque dur qui est le départ.
.
Mon problème de caractères vides venait d'un soucis de gestion mémoire pendant mon parsing.