Schémas URI
Réduire la table des matières
Développer la table des matières

Schémas URI

[ Cet article est destiné aux développeurs de Windows 8.x et Windows Phone 8.x qui créent des applications Windows Runtime. Si vous développez une application pour Windows 10, voir la Documentation ]

Vous pouvez recourir à des schémas d’URI (Uniform Resource Identifier) pour faire référence aux fichiers d'application issus du package de l'application, des dossiers de données ou des ressources.

ms-appx(-web)

Les schémas ms-appx et ms-appx-web vous permettent de faire référence aux fichiers d'application issus du package de l'application (voir Packages et déploiement d’applications). Ces fichiers sont généralement des fichiers de disposition, de code, de données et d'images statiques. Le schéma ms-appx-web fait référence à ces mêmes fichiers, mais dans le compartiment Web. Voir Comment charger des ressources de fichiers pour une utilisation courante.

Nom du schéma

Le nom du schéma URI est la chaîne "ms-appx"

ms-appx://

ou "ms-appx-web".

ms-appx-web://

Le nom du schéma suit les règles URI classiques (RFC 3986) pour la standardisation et l'extraction des ressources des schémas. Le nom du schéma ne respecte pas la casse US-ASCII et la forme standardisée du nom du schéma utilise les minuscules.

Partie hiérarchique

Ce schéma URI définit sa partie hiérarchique selon RFC 3986 comme l'autorité et les composants du chemin d'accès de l'URI :

URI         = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
hier-part   = "//" authority path-abempty
            / path-absolute
            / path-rootless
            / path-empty

Autorité

L'autorité est un identificateur qui ne respecte pas la casse US-ASCII de l'entité qui détient les fichiers.

L’autorité URI ou IRI (Internationalized Resource Identifier) du schéma ms-appx(-web) est le nom d’identité du package (voir Packages et déploiement d’applications) défini dans le manifeste du package. Il est donc limité sous sa forme IRI et URI au jeu de caractères autorisés dans un nom d’identité de package. Le nom du package est limité au jeu contenu dans le graphique de dépendance du package de l'application en cours d'exécution.

ms-appx://Contoso.MyApp/
ms-appx-web://Contoso.MyApp/

Si d'autres caractères figurent dans l’autorité, l’extraction et la comparaison échoueront.

La valeur de l’autorité, lorsque l’autorité donnée est vide, correspond au package de l’application en cours d’exécution :

ms-appx:///
ms-appx-web:///

La forme normale de l’autorité est le nom d’identité du package en minuscules conformément à la règle de non-respect de la casse pour les caractères US-ASCII. Par exemple,

document.location // Returns ms-appx://contoso.myapp/default.html

Ainsi, lors de l’extraction de la ressource, l’autorité peut apparaître en minuscules ou en majuscules, mais elle fait référence dans les deux cas à la même ressource.

Port et informations utilisateur

Le schéma ms-appx, contrairement à d'autres schémas courants, ne définit pas de composant de port ou informations utilisateur. Comme "@" et ":" ne sont pas autorisés comme valeurs d'autorité valides, la recherche n'aboutit pas si ces derniers sont inclus. Chacun des processus suivants échouera :

// Examples of schemes that fail:
ms-appx://john@contoso.myapp/default.html
ms-appx://john:password@contoso.myapp/default.html
ms-appx://contoso.myapp:8080/default.html
ms-appx://john:password@contoso.myapp:8080/default.html

Chemin d'accès

Le composant de chemin correspond à la syntaxe générique RFC 3986 et prend en charge des caractères non ASCII dans les IRI.

Le composant de chemin définit le chemin d'accès du fichier physique ou logique d'un fichier. Ce fichier est contenu dans un dossier associé à l’emplacement d’installation du package d’une application spécifiée par l’autorité.

Le composant du chemin d’accès peut définir une ressource logique plutôt que physique. Dans ce cas, la ressource réelle renvoyée au cours de l’extraction est déterminée par négociation du contenu au moment de l’exécution. Cette détermination est effectuée d’après l’état actuel du système afin d’identifier la ressource la plus appropriée. Si le composant du chemin d’accès fait référence plutôt à un chemin d’accès physique du fichier et non logique, la ressource du fichier physique est extraite sans négociation du contenu.

Par exemple, les langues de l'application, les paramètres d'affichage du système, les paramètres de contraste de l'utilisateur peuvent être pris en compte pour déterminer la valeur de la ressource réelle à extraire :

ms-appx://contoso.myapp/images/logo.png

Les informations mentionnées ci-dessus peuvent permettre d’extraire un fichier dans le package Contoso.myapp nommé

images/fr-FR/logo.scale-100_contrast-white.png

Vous pouvez aussi faire référence directement à l'image physique si nécessaire :

<img src="/images/fr-FR/logo.scale-100_contrast-white.png" />

Voir Comment charger des ressources de fichiers pour une introduction aux valeurs courantes.

Comme les URI génériques, le composant de chemin d'accès de ms-appx(-web) respecte la casse. Cependant, lorsque le système de fichiers sous-jacent qui permet d'accéder à la ressource ne respecte pas la casse, comme pour NTFS, l'extraction de la ressource s'effectue sans tenir compte de la casse.

La forme standardisée de l'URI conserve la casse et décode en pourcentage les caractères non réservés RFC 3986.

Les caractères "?", "#", "/", "*" et '”' (guillemets doubles) doivent être codés en pourcentage dans un chemin d'accès pour représenter des données telles que des noms de dossier ou de fichier. Tous les caractères codés en pourcentage sont décodés avant l'extraction. Ainsi, pour extraire un fichier nommé Hello#World.html, utilisez

ms-appx:///Hello%23World.html

Requête

Les paramètres de requête sont ignorés au cours de l'extraction des ressources. La forme standardisée des paramètres de requête conserve la casse. Les paramètres de requête ne sont pas ignorés au cours de la comparaison.

Les développeurs des composants donnés placés en couche au-dessus de cette analyse URI peuvent choisir d'utiliser les paramètres de requête selon leurs besoins. Par exemple, l’hôte de l’application peut extraire un fichier HTML en particulier tout en ignorant les paramètres de requête. Mais le code exécuté dans la page peut toujours exploiter les paramètres de requête comme état pour effectuer un rendu particulier sur la page.

Fragment

Le composant fragment est ignoré par le traitement spécifique au schéma des URI. Au cours de la comparaison et de l'extraction de la ressource, le composant fragment n'a pas de repère. Cependant, les couches situées au-dessus de l'implémentation spécifique peuvent interpréter le fragment pour extraire une ressource secondaire.

Par exemple, l'hôte d'application peut traiter des URI ms-appx, où une navigation se dirige vers un URI ms-appx: et défile vers un point d'ancrage identifié par le fragment, mais l'implémentation URLMon spécifique de ms-appx: est seulement chargée d'extraire la page HTML ; elle ignore le fragment.

Comparaison

La comparaison s'effectue octet par octet après standardisation de tous les composants IRI.

ms-appdata

Le schéma ms-appdata vous permet de faire référence à des fichiers d'application issus des dossiers de données temporaires, itinérants et locaux de l'application. Voir Comment charger les ressources de fichiers pour une utilisation courante, et Accès aux données de l’application à l’aide de Windows Runtime pour plus d'informations sur les données d'application.

Nom du schéma

Le nom du schéma URI est la chaîne "ms-appdata".

ms-appdata://

Le schéma URI suit les règles IRI classiques pour la standardisation et l'extraction des ressources des schémas. Le nom du schéma ne respecte pas la casse US-ASCII et la forme standard du nom du schéma utilise les minuscules.

Partie hiérarchique

Ce schéma URI définit sa partie hiérarchique selon RFC 3986 comme l'autorité et les composants du chemin d'accès de l'URI :

URI         = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
hier-part   = "//" authority path-abempty
            / path-absolute
            / path-rootless
            / path-empty

Autorité

L'autorité de l'URI ms-appdata est le nom d'identité du package (voir Packages et déploiement d’applications) défini dans le manifeste du package. Le nom du package est limité au package de l'application en cours d'exécution.

ms-appdata://Contoso.MyApp/

Si d'autres caractères figurent dans l’autorité, l’extraction et la comparaison échoueront.

La valeur de l’autorité, lorsque l’autorité donnée est vide, correspond au package de l’application en cours d’exécution :

ms-appdata:///

La forme normale de l’autorité est le nom d’identité du package en minuscules conformément à la règle de non-respect de la casse pour les caractères US-ASCII.

Port et informations utilisateur

Le schéma ms-appdata, contrairement à d'autres schémas courants, ne définit pas de composant de port ou informations utilisateur. Comme "@" et ":" ne sont pas autorisés comme valeurs d'autorité valides, la recherche n'aboutit pas si ces derniers sont inclus. Chacun des processus suivants échouera :

// Examples of schemes that fail:
ms-appdata://john@contoso.myapp/local/data.xml
ms-appdata://john:password@contoso.myapp/local/data.xml
ms-appdata://contoso.myapp:8080/local/data.xml
ms-appdata://john:password@contoso.myapp:8080/local/data.xml

Chemin d'accès

L'emplacement Windows.Storage.ApplicationData contient trois dossiers réservés pour le stockage d'état temporaire, local et itinérant. Le schéma ms-appdata permet l'accès aux fichiers et aux dossiers à ces emplacements. Le premier segment du composant chemin d'accès doit spécifier le dossier particulier comme suit. Ainsi, la forme "chemin-vide" de "hier-part" est illégale.

Dossier local :

ms-appdata:///local/

Dossier temporaire :

ms-appdata:///temp/

Dossier itinérant :

ms-appdata:///roaming/

Comme les URI génériques, le composant de chemin d'accès de ms-appdata respecte la casse. Cependant, lorsque le système de fichiers sous-jacent qui permet d'accéder à la ressource ne respecte pas la casse, comme pour NTFS, l'extraction de la ressource s'effectue sans tenir compte de la casse.

La forme standardisée de l'URI conserve la casse et décode en pourcentage les caractères non réservés RFC 3986.

Les caractères "?", "#", "/", "*" et '”' (guillemets doubles) doivent être codés en pourcentage dans un chemin d'accès pour représenter des données telles que des noms de dossier ou de fichier. Tous les caractères codés en pourcentage sont décodés avant l'extraction. Ainsi, pour extraire un fichier nommé Hello#World.xml, utilisez

ms-appdata:///Hello%23World.xml

L'extraction de la ressource et l'identification du segment du chemin d'accès de niveau supérieur sont traitées au terme de la standardisation des points (".././b/c"). Par conséquent, les URI ne peuvent pas utiliser de points en dehors de l'un des dossiers de réserve. Ainsi, les URI suivants ne sont pas autorisés :

ms-appdata:///local/../hello/logo.png

mais cet URI est autorisé :

ms-appdata:///local/../roaming/logo.png

Requête

Les paramètres de requête sont ignorés au cours de l'extraction des ressources. La forme standardisée des paramètres de requête conserve la casse. Les paramètres de requête ne sont pas ignorés au cours de la comparaison.

Les développeurs des composants donnés placés en couche au-dessus de cette analyse URI peuvent choisir d'utiliser les paramètres de requête selon leurs besoins Par exemple, l’hôte d’application peut extraire une image particulière et ignorer les paramètres de requête mais le code en cours d’exécution dans la page peut utiliser les paramètres de requête comme état pour effectuer un rendu particulier sur la page.

Fragment

Le composant fragment est ignoré par le traitement spécifique au schéma des URI. Au cours de la comparaison et de l'extraction de la ressource, le composant fragment n'a pas de repère. Cependant, les couches situées au-dessus de l'implémentation spécifique peuvent interpréter le fragment pour extraire une ressource secondaire.

ms-resource

Utiliser le schéma ms-resource pour faire référence à des ressources d'application qui sont généralement des ressources de chaîne. Ce schéma s'utilise généralement conjointement avec les API Windows.ApplicationModel.Resources, Windows.ApplicationModel.Resources.Core, ou WinJS.Resources pour effectuer des recherches de ressources dans les fichiers PRI (voir Système de gestion des ressources). Voir Comment charger les ressources de chaîne pour des utilisations courantes.

Nom du schéma

Le nom du schéma URI est la chaîne "ms-resource".

ms-resource://

Le nom du schéma suit les règles URI classiques pour la standardisation et l'extraction des ressources des schémas. Le nom du schéma ne respecte pas la casse US-ASCII et la forme standardisée du schéma utilise les minuscules.

Partie hiérarchique

Ce schéma URI définit sa partie hiérarchique selon RFC 3986 comme l'autorité et les composants du chemin d'accès de l'URI :

URI         = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
hier-part   = "//" authority path-abempty
            / path-absolute
            / path-rootless
            / path-empty

Autorité

L'autorité pour l'URI ms-resource est le mappage des ressources de niveau supérieur définies dans le PRI qui correspond généralement au nom d'identité du package (voir Packages et déploiement d’applications) défini dans le manifeste du package. Pour les applications du Windows Store, le nom de mappage des ressources est limité aux noms contenus dans le graphique de dépendance du package de l’application en cours d’exécution.

ms-resource://Contoso.MyApp/
ms-resource://Microsoft.WinJS.1.0/

Si d'autres caractères figurent dans l'autorité, l'extraction et la comparaison échoueront.

La valeur du nom d’hôte, lorsque le nom donné est vide, est le nom qui respecte la casse du package de l’application en cours d’exécution :

ms-resource:///

L'autorité respecte la casse et la forme standardisée conserve sa casse. Toutefois, la recherche d'une ressource s'effectue sans respecter la casse.

Port et informations utilisateur

Le schéma ms-resource, contrairement à d'autres schémas courants, ne définit pas un composant de port ou informations utilisateur. Comme "@" et ":" ne sont pas autorisés comme valeurs d'autorité valides, la recherche n'aboutit pas si ces derniers sont inclus. Chacun des processus suivants échouera :

// Examples of schemes that fail:
ms-resource://john@contoso.myapp/Resources/String1
ms-resource://john:password@contoso.myapp/Resources/String1
ms-resource://contoso.myapp:8080/Resources/String1
ms-resource://john:password@contoso.myapp:8080/Resources/String1

Chemin d'accès

Le chemin d'accès identifie l'emplacement hiérarchique de la sous-arborescence ResourceMap (voir Système de gestion des ressources) et le NamedResource qu'il contient. Généralement, il correspond au nom de fichier (sans l'extension) du fichier de ressource et le nom de la ressource qu'il contient. Par exemple, pour un fichier nommé resources.resjson qui contient

{
    "String1" : "Hello World"
}

l'URI ms-resource suivant peut être utilisé :

ms-resource:///resources/String1

Comme les URI génériques, le composant de chemin d'accès de ms-resource respecte la casse. Cependant, l'extraction sous-jacente effectue un CompareStringOrdinal avec ignoreCase défini comme une vraie extraction qui ne respecte pas la casse.

La forme standardisée de l'URI conserve la casse.

Les caractères "?", "#", "/", "*" et '”' (guillemets doubles) doivent être codés en pourcentage dans un chemin d'accès pour représenter les données telles que des noms de dossier ou de fichier. Tous les caractères codés en pourcentage sont décodés avant l'extraction. Ainsi, pour extraire un fichier nommé Hello#World.xml, utilisez

ms-appdata:///Hello%23World.xml

Requête

Les paramètres de requête ne sont pas ignorés au cours de la comparaison. Les paramètres de requête sont comparés en respectant la casse. Les paramètres de requête sont ignorés au cours de l'extraction des ressources.

Les développeurs des composants donnés placés en couche au-dessus de cette analyse URI peuvent choisir d'utiliser les paramètres de requête selon leurs besoins

Fragment

Le composant fragment est ignoré par le traitement spécifique au schéma des URI. Au cours de la comparaison et de l'extraction de la ressource, le composant fragment n'a pas de repère. Cependant, les couches situées au-dessus de l'implémentation spécifique peuvent interpréter le fragment pour extraire une ressource secondaire.

Rubriques associées

RFC 3986 : URI (Uniform Resource Identifier) : syntaxe générique
Comment charger des ressources de fichiers
Comment charger des ressources de type chaîne
Accès aux données de l’application à l’aide de Windows Runtime
Packages et déploiement d’applications
Système de gestion des ressources
Windows.ApplicationModel.Resources
Windows.ApplicationModel.Resources.Core
Windows.Storage.ApplicationData
WinJS.Resources

 

 

Afficher:
© 2017 Microsoft