Nommage de fichiers

Venez ici afin d'enrichir la documentation de nos suites bureautiques préférées. Déposez une demande ou y répondre par la création ou la traduction d'un tutoriel.

Modérateur : Vilains modOOs

Avatar de l’utilisateur
Churay
ManitOOu
ManitOOu
Messages : 2668
Inscription : 30 avr. 2009 06:54
Localisation : CATALUNYA
Contact :

Nommage de fichiers

Message par Churay »

Bonjour,

Traduction rapide de Be Careful with file URLs

Différentes façons de nommer les fichiers

Il existe (au moins) cinq façons de nommer les fichiers :

La notation spécifique à la plate-forme, appelé ici chemins d'accès (par exemple, /abc/def/ghi.txt sur Unix, a:\bcd\efg\hij.txt sur DOS et Windows, et abc:def:ghi.txt sur Macintosh).

La notation de type UNC, appelée ici noms UNC (par exemple, //./Abc/def/ghi.txt ou //,/A
:/bcd/EFG/hij.txt). La couche osl était utilisée pour en faire un usage intensif comme notation indépendante de plateforme, mais depuis osl a opté pour les URL de fichiers comme notation indépendante de plateforme (voir ci-dessous), les noms UNC ont été dépréciés et sont devenus à peu près inutiles (et ne sont mentionnés ici par souci d'exhaustivité).

Les URL de fichiers utilisées par la couche osl comme notation indépendante de plateforme, appelée ici URL osl ici (par exemple, file:///abc/def/ghi.txt ou file:///a:/bcd/EFG/hij.txt ). Lisez la suite pour savoir pourquoi il est important de nommer explicitement ces URL de fichiers en tant que URL osl.

Les URL de fichiers utilisées par le fournisseur de contenu du fichier (FCP - File Content Provider) au sein de la Universal Content Broker (UCB), appelées URL FCP (par exemple, file:///home/usr123/work/abc.txt ou file:///user/work/abc.txt). Normalement, les URL et les URL osl du FCP sont les mêmes (après tout, le FCP utilise OSL pour accéder aux fichiers). Mais le FCP possède une fonctionnalité appelée points de montage qui lui permet de restreindre l'accès à uniquement certains fichiers (ceux qui se trouvent ci-dessous un ensemble donné de points de montage dans la hiérarchie du système de fichiers), et de donner des noms à ces fichiers qui cachent leurs emplacements réels.

Par exemple, si vous avez un point de montage nommé user à l'URL osl ficle:///home/usr123, l' URL osl file:///home/usr123/work/abc.txt correspond à l'URL FCP file:///user/work/abc.txt. Si vous ne disposez que d'un point de montage simple, l'URL osl file:///home/usr567/work/def.txt n'a pas d'URL FCP correspondante (et ne peut être accessible via le FCP).

Les URLs utilisées par l'UCB, appelées ici UCB URL (par exemple, ffile:///a:/bcd/efg/hij.txt ou vnd.sun.star.wfs:///user/work/abc.txt). Normalement, les URLs FCP et les URLs UCB sont les mêmes, parce que le fichier UCB manipule les URL de fichiers directement au FCP. Mais il existe un fournisseur de contenu spécial, le fournisseur de contenu d'accès à distance (Remote Access Content Provider - RAP), qui permet de réécrire les URLs avant de les transmettre à d'autres fournisseurs de contenu. Il est utilisé, par exemple, dans le Sun ONE Webtop (S1W), où il existe généralement deux systèmes de fichiers : un système de fichiers client accessible via l'URL normale (FCP) du fichier (c-à-d, il n'y a pas de réécriture RAP entre l'UCB et le client FCP), et un système de fichiers serveur accessible via les URLs (FCP) où le système de fichiers a été remplacé par vnd.sun.star.wfs (c.-à-d, avec une réécriture RAP entre l'UCB et le serveur (FCP).

Les deux dernières notations (URL FCP et URL UCB) sont relativement peu connues, parce que dans une installation simple/normale d'OpenOffice ni les points de montage, ni la RAP ne sont utilisés, de sorte que les URL OSL, les URL FCP et les URL UCB sont tous identiques. Mais quand vous voulez écrire du code correct qui fonctionne également dans les déploiements inhabituels (ou dans le S1W, qui ne devrait pas être considérée comme trop inhabituel), vous devez être bien conscients de ces différentes notations toutes nommées comme «URLs».


Où sont utilisées ces différentes notations

Comme mentionné précédemment, l'utilisation de noms UNC est obsolète. En outre, puisque la plupart du code n'accède au FCP directement, mais par l'intermédiaire de l'UCB, les URLs FCP n'sont d'intérêt que pour les utilisateurs du hard core UCB (qui, de toutes façons, devraient savoir ce qu'ils font). Donc, dans ce qui suit nous pouvons nous concentrer sur trois notations différentes : chemins d'accès, URLs osl et URLs UCB.

Où sont utilisés les chemins d'accès

Les chemins d'accès sont utilisés seulement dans quelques endroits, parce que la notation par défaut utilisé par OSL (le plus bas niveau de préoccupation pour nous) sont déjà des URLs osl (un niveau en-dessus des chemins d'accès). On peut faire valoir que les interfaces qui utilisent des chemins d'accès doivent utiliser plutôt des URL osl, et que les chemins d'accès n'ont d'intérêt que lors de la communication avec le monde extérieur (autres processus ou utilisateur humain).

Les chemins d'accès sont utilisés dans la classe utl::fic_temp.

Où sont utilisées les URLs osl

Maintenant, les fonctions du système de fichiers (OSL en osl/file.h et OSL/file.hxx) utilisent généralement des URLs osl dans leurs interfaces.

Il devrait y avoir peu d'endroits au-dessus d'osl où les URLs osl sont utilisées au lieu des URLs UCB (parce que généralement tous les accès aux fichiers doit être fait par le biais de l'UCB, et non pas directement par l'intermédiaire d'OSL). Une exception notable est la manipulation des fichiers temporaires (voir ci-dessus).

Où sont utilisées les URLs UCB

En règle générale, toutes les interfaces qui sont conçues pour communiquer les noms de ressources dans le cadre OpenOffice devrait utiliser des URLs UCB, et toutes les implémentations qui accèdent aux ressources par ces noms devraient le faire par l'intermédiaire de l'UCB. Un autre avantage est que, sans aucun effort supplémentaire non seulement des ressources fichier peuvent être consultées, mais aussi d'autres ressources telles que HTTP et FTP (en utilisant les URLs appropriées, mais ces URLs peuvent être opaque au code, interprété uniquement par l'UCB).

Conversion entre différentes notations

Parfois, il peut être nécessaire de convertir entre les différentes notations, et les routines pour le faire sont disponibles :

Les méthodes osl::FileBase::getFileURLFromSystemPath() et osl::FileBase::getSystemPathFromFileURL() (voir osl/file.h) convertissent les chemins d'accès (appelés ici "chemins système") et les URLs osl.

Les méthodes utl::LocalFileHelper::ConvertSystemPathToURL() et utl::LocalFileHelper::ConvertURLToSystemPath() convertissent les chemins d'accès (encore appelés ici "chemins système") et les URLs UCB.

Parce qu'il peut exister des scénarii où vous avez des FCP multiples sur des systèmes de fichiers différents, il peut être ambiguë de comment convertir un chemin d'accès (qui ne contient aucune information d'identification d'un système de fichier spécifique) en une URL UCB. Par conséquent, ConvertSystemPathToURL() nécessite un paramètre supplémentaire qui BaseURL qui identifie le FCP à utiliser.

Il existe la commodité des méthodes utl::LocalFileHelper::ConvertPhysicalNameToURL() et utl::LocalFileHelper::ConvertURLToPhysicalName() qui choisissent le FCP local comme BaseURL puis les méthodes LocalFileHelper ci-dessus.

Pour que cela fonctionne, l'UCB maintient une notion de localité des fournisseurs de contenu. Il s'agit d'un algorithme heuristique basée sur la façon dont le UCB accède aux fournisseurs de contenu (dans le même processus, par l'intermédiaire d'un pipe sur la même machine, via un socket prise sur un réseau). L'effet est que l'UCB devrait toujours choisir comme le plus local le FCP fonctionnant sur la même machine que l'UCB, et en utilisant ces méthodes LocalFileHelper il convertira toujours URLs UCB et les arborescences qui sont valides sur cette machine.

ConvertURLToPhysicalName() s'assure également de faire la conversion uniquement si l'URL UCB donnée correspond à un chemin d'accès local (et non pas à un chemin d'accès sur un système de fichiers non-local).

Il n'existe aucun moyen direct pour convertir les URLs osl et les URLs UCB. Pour convertir à partir d'une URL osl en une URL UCB, utilisez osl::FileBase::getSystemPathFromFileURL()suivie de utl::LocalFileHelper::ConvertPhysicalNameToURL(). Pour convertir une URL UCB en une URL OSL, utilisez utl::LocalFileHelper::ConvertURLToPhysicalName() suivie de osl::FileBase::getFileURLFromSystemPath.
Mais soyez conscient que cela ne fonctionnera que si l'URL osl et l'URL UCB désignent des fichiers dans le même système de fichiers.

[Notes personnelles]
Dans le cadre d'une utilisation Basic, on peut résumer à :
pour bâtir une URL qui ait des chances de fonctionner correctement, l'utilisation des méthodes convertToURL et convertFromURL est peut-être judicieuse (éviter par exemple une utilisation excessive du /).

Pour les notions de Fournisseur de contenu (Content Provider), voir le Developer'sGuide :
http://wiki.services.openoffice.org/wik ... _Providers
http://wiki.services.openoffice.org/wik ... t_Provider
etc... pour les Content Providers de type HCP | FTP | WebDA | Package | Help
 Ajout : à l'attention des modos
Je n'arrive pas à me décider sur la balise à utiliser... 
cOOordialement
---
AOO 4.0.1 W7-PRO & LO 5.1.6.2 Debian 7.8 & Ubuntu 16.04 LTS
---
F1 : ça aide...
XRay + SDK :super:
---
Quand le NOT CONFIRMED sera corrigé (OOo et LO) , je serai heureux...
Répondre