URI-Schemas

  • Artikel

Es gibt mehrere URI (Uniform Resource Identifier)-Schemen, die Sie verwenden können, um auf Dateien aus Ihrem App Paket, dem App-Ordner oder der Cloud zu verweisen. Sie können auch ein URI-Schema verwenden, um auf Zeichenfolgen zu verweisen, die von den App-Ressourcendateien (.resw) geladen wurden. Sie können diese URI-Schemas in Ihrem Code, in Ihrem XAML-Markup, im App-Paketmanifest oder in den Vorlagen für Kachel- und Popupbenachrichtigungen verwenden.

Allgemeine Features der URI-Schemas

Alle in diesem Thema beschriebenen Schemas folgen typischen URI-Schemaregeln für normalisierung und Ressourcenabruf. Siehe RFC 3986 für die generische Syntax eines URI.

Alle URI-Schemas definieren den hierarchischen Teil pro RFC 3986 als Autoritäts- und Pfadkomponenten des URI.

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

Dies bedeutet, dass es im Wesentlichen drei Komponenten zu einem URI gibt. Unmittelbar nach den beiden Schrägstrichen des URI-Schemas befindet sich eine Komponente (die leer sein kann), die als Autorität bezeichnet wird. Und unmittelbar darauf folgt der Pfad. Wenn Sie den URI http://www.contoso.com/welcome.png als Beispiel verwenden, lautet das Schema "http://", die Autorität ist "www.contoso.com", und der Pfad lautet "/welcome.png". Ein weiteres Beispiel ist der URI ms-appx:///logo.png, bei dem die Autoritätskomponenten leer sind und einen Standardwert akzeptiert.

Die Fragmentkomponente wird von der schemaspezifischen Verarbeitung der in diesem Thema erwähnten URIs ignoriert. Während des Ressourcenabrufs und -vergleichs hat die Fragmentkomponente keine Lager. Ebenen über einer bestimmten Implementierung können das Fragment jedoch interpretieren, um eine sekundäre Ressource abzurufen.

Der Vergleich erfolgt nach der Normalisierung aller IRI-Komponenten für Byte.

Groß-/Kleinschreibung und Normalisierung

Alle in diesem Thema beschriebenen URI-Schemas folgen typischen URI-Regeln (RFC 3986) für die Normalisierung und den Ressourcenabruf für Schemas. Die normalisierte Form dieser URIs behält die Groß-/Kleinschreibung bei und decodiert RFC 3986 nicht reservierte Zeichen.

Bei allen in diesem Thema beschriebenen URI-Schemas werden Schema, Autorität und Pfad entweder standardmäßig zwischen Groß- und Kleinschreibung unterschieden, oder sie werden von dem System auf nicht beachtete Weise verarbeitet. Beachten Sie Die einzige Ausnahme von dieser Regel ist die Autorität der ms-resourceGroß-/Kleinschreibung.

ms-appx und ms-appx-web

Verwenden Sie das ms-appx URI-Schema, ms-appx-web um auf eine Datei zu verweisen, die aus dem Paket Ihrer App stammt (siehe Verpacken von Apps). Dateien in Ihrem App-Paket sind in der Regel statische Bilder, Daten, Code und Layoutdateien. Das ms-appx-web Schema greift auf die gleichen Dateien wie ms-appxim Webfach zu. Beispiele und weitere Informationen finden Sie unter Referenzieren eines Bilds oder einer anderen Ressource aus XAML-Markup und Code.

Schemaname (ms-appx und ms-appx-web)

Der URI-Schemaname ist die Zeichenfolge "ms-appx" oder "ms-appx-web".

ms-appx://

ms-appx-web://

Autorität (ms-appx und ms-appx-web)

Die Autorität ist der Paketidentitätsname, der im Paketmanifest definiert ist. Es ist daher sowohl im URI- als auch im IRI-Formular (Internationalized Resource Identifier) auf den Satz von Zeichen beschränkt, die in einem Paketidentitätsnamen zulässig sind. Der Paketname muss der Name eines der Pakete im Paketabhängigkeitsdiagramm der aktuellen ausgeführten App sein.

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

Wenn ein anderes Zeichen in der Autorität angezeigt wird, schlägt der Abruf und vergleich fehl. Der Standardwert für die Autorität ist das aktuell ausgeführte App-Paket.

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

Benutzerinformationen und -port (ms-appx und ms-appx-web)

Das ms-appx Schema definiert im Gegensatz zu anderen gängigen Schemas keine Benutzerinformationen oder Portkomponenten. Da "@" und ":" nicht als gültige Autoritätswerte zulässig sind, schlägt die Suche fehl, wenn sie enthalten sind. Jeder der folgenden Fehler schlägt fehl.

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

Pfad (ms-appx und ms-appx-web)

Die Pfadkomponente entspricht der generischen RFC 3986-Syntax und unterstützt Nicht-ASCII-Zeichen in IRIs. Die Pfadkomponente definiert den logischen oder physischen Dateipfad einer Datei. Diese Datei befindet sich in einem Ordner, der dem installierten Speicherort des App-Pakets für die von der Autorität angegebene App zugeordnet ist.

Wenn sich der Pfad auf einen physischen Pfad und Dateinamen bezieht, wird diese physische Dateiressource abgerufen. Wenn jedoch keine solche physische Datei gefunden wird, wird die tatsächliche Ressource, die beim Abruf zurückgegeben wird, mithilfe der Inhaltsverhandlung zur Laufzeit bestimmt. Diese Bestimmung basiert auf App-, Betriebssystem- und Benutzereinstellungen wie Sprache, Anzeigeskalierungsfaktor, Design, hohem Kontrast und anderen Laufzeitkontexten. Eine Kombination aus den Sprachen der App, den Anzeigeeinstellungen des Systems und den Einstellungen für hohen Kontrast des Benutzers kann bei der Ermittlung des tatsächlich abzurufenden Ressourcenwerts berücksichtigt werden.

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

Der obige URI kann eine Datei im Paket der aktuellen App mit dem folgenden physischen Dateinamen tatsächlich abrufen.

\Images\fr-FR\logo.scale-100_contrast-white.png

Sie können diese physische Datei natürlich auch abrufen, indem Sie direkt unter dem vollständigen Namen darauf verweisen.

<Image Source="ms-appx:///images/fr-FR/logo.scale-100_contrast-white.png"/>

Die Pfadkomponente von ms-appx(-web) ist, z. B. generische URIs, Groß-/Kleinschreibung zu beachten. Wenn jedoch das zugrunde liegende Dateisystem, mit dem auf die Ressource zugegriffen wird, die Groß-/Kleinschreibung nicht beachtet wird, z. B. bei NTFS, wird der Abruf der Ressource ohne Groß-/Kleinschreibung durchgeführt.

Die normalisierte Form des URI behält die Groß-/Kleinschreibung bei und die Prozent-Decodierung (ein "%"-Symbol gefolgt von der zweistelligen hexadezimalen Darstellung) RFC 3986 nicht reservierte Zeichen. Die Zeichen "?", "#", "/", "*" und """ (das doppelte Anführungszeichen) müssen in einem Pfad prozentcodiert sein, um Daten wie Datei- oder Ordnernamen darzustellen. Alle prozentcodierten Zeichen werden vor dem Abruf decodiert. Verwenden Sie daher diesen URI, um eine Datei namens "Hello#World.html" abzurufen.

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

Abfrage (ms-appx und ms-appx-web)

Abfrageparameter werden beim Abrufen von Ressourcen ignoriert. Die normalisierte Form von Abfrageparametern behält die Groß-/Kleinschreibung bei. Abfrageparameter werden während des Vergleichs nicht ignoriert.

ms-appdata

Verwenden Sie das ms-appdata URI-Schema, um auf Dateien zu verweisen, die aus den lokalen, Roaming- und temporären Datenordnern der App stammen. Weitere Informationen zu diesen App-Datenordnern finden Sie unter Store und Abrufen von Einstellungen und anderen App-Daten.

Das ms-appdata URI-Schema führt keine Laufzeitinhaltsverhandlung durch, die ms-appx und ms-appx-web ausführen. Sie können jedoch auf den Inhalt von ResourceContext.QualifierValues reagieren und die entsprechenden Ressourcen aus App-Daten mithilfe ihres vollständigen physischen Dateinamens im URI laden.

Schemaname (ms-appdata)

Der URI-Schemaname ist die Zeichenfolge "ms-appdata".

ms-appdata://

Autorität (ms-appdata)

Die Autorität ist der Paketidentitätsname, der im Paketmanifest definiert ist. Es ist daher sowohl im URI- als auch im IRI-Formular (Internationalized Resource Identifier) auf den Satz von Zeichen beschränkt, die in einem Paketidentitätsnamen zulässig sind. Der Paketname muss der Name des pakets der aktuellen ausgeführten App sein.

ms-appdata://Contoso.MyApp/

Wenn ein anderes Zeichen in der Autorität angezeigt wird, schlägt der Abruf und vergleich fehl. Der Standardwert für die Autorität ist das aktuell ausgeführte App-Paket.

ms-appdata:///

Benutzerinformationen und -port (ms-appdata)

Das ms-appdata Schema definiert im Gegensatz zu anderen gängigen Schemas keine Benutzerinformationen oder Portkomponenten. Da "@" und ":" nicht als gültige Autoritätswerte zulässig sind, schlägt die Suche fehl, wenn sie enthalten sind. Jeder der folgenden Fehler schlägt fehl.

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

Pfad (ms-appdata)

Die Pfadkomponente entspricht der generischen RFC 3986-Syntax und unterstützt Nicht-ASCII-Zeichen in IRIs. Innerhalb des Speicherorts "Windows.Storage.ApplicationData " befinden sich drei reservierte Ordner für den lokalen, Roaming- und temporären Zustandsspeicher. Das ms-appdata Schema ermöglicht den Zugriff auf Dateien und Ordner an diesen Speicherorten. Das erste Segment der Pfadkomponente muss den bestimmten Ordner auf folgende Weise angeben. Daher ist die "pfadleere" Form von "hier-part" nicht legal.

Lokaler Ordner.

ms-appdata:///local/

Temporärer Ordner.

ms-appdata:///temp/

Roamingordner.

ms-appdata:///roaming/

Die Pfadkomponente von ms-appdata ist, z. B. generische URIs, Groß-/Kleinschreibung zu beachten. Wenn jedoch das zugrunde liegende Dateisystem, mit dem auf die Ressource zugegriffen wird, die Groß-/Kleinschreibung nicht beachtet wird, z. B. bei NTFS, wird der Abruf der Ressource ohne Groß-/Kleinschreibung durchgeführt.

Die normalisierte Form des URI behält die Groß-/Kleinschreibung bei und die Prozent-Decodierung (ein "%"-Symbol gefolgt von der zweistelligen hexadezimalen Darstellung) RFC 3986 nicht reservierte Zeichen. Die Zeichen "?", "#", "/", "*" und """ (das doppelte Anführungszeichen) müssen in einem Pfad prozentcodiert sein, um Daten wie Datei- oder Ordnernamen darzustellen. Alle prozentcodierten Zeichen werden vor dem Abruf decodiert. Verwenden Sie daher diesen URI, um eine lokale Datei namens "Hello#World.html" abzurufen.

ms-appdata://local/Hello%23World.html

Das Abrufen der Ressource und die Identifizierung des Pfadsegments der obersten Ebene werden nach der Normalisierung von Punkten (".. /./b/c"). Daher können URIs sich nicht aus einem der reservierten Ordner entfernen. Daher ist der folgende URI nicht zulässig.

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

Dieser URI ist jedoch zulässig (wenn auch redundant).

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

Abfrage (ms-appdata)

Abfrageparameter werden beim Abrufen von Ressourcen ignoriert. Die normalisierte Form von Abfrageparametern behält die Groß-/Kleinschreibung bei. Abfrageparameter werden während des Vergleichs nicht ignoriert.

ms-resource

Verwenden Sie das ms-resource URI-Schema, um auf Zeichenfolgen zu verweisen, die aus den Ressourcendateien Ihrer App (.resw) geladen wurden. Beispiele und weitere Informationen zu Ressourcendateien finden Sie unter Lokalisieren von Zeichenfolgen in Der Benutzeroberfläche und im App-Paketmanifest.

Schemaname (ms-resource)

Der URI-Schemaname ist die Zeichenfolge "ms-resource".

ms-resource://

Autorität (ms-resource)

Die Autorität ist die im Paketressourcenindex (PRI) definierte Ressourcenzuordnung der obersten Ebene, die normalerweise dem Im Paketmanifest definierten Paketidentitätsnamen entspricht. Siehe Packen von Apps). Es ist daher sowohl im URI- als auch im IRI-Formular (Internationalized Resource Identifier) auf den Satz von Zeichen beschränkt, die in einem Paketidentitätsnamen zulässig sind. Der Paketname muss der Name eines der Pakete im Paketabhängigkeitsdiagramm der aktuellen ausgeführten App sein.

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

Wenn ein anderes Zeichen in der Autorität angezeigt wird, schlägt der Abruf und vergleich fehl. Der Standardwert für die Autorität ist der Name des Pakets mit Groß-/Kleinschreibung der aktuell ausgeführten App.

ms-resource:///

Bei der Autorität wird die Groß-/Kleinschreibung beachtet, und das normalisierte Formular behält die Groß-/Kleinschreibung bei. Bei der Suche nach einer Ressource wird die Groß-/Kleinschreibung jedoch nicht beachtet.

Benutzerinformationen und Port (ms-resource)

Das ms-resource Schema definiert im Gegensatz zu anderen gängigen Schemas keine Benutzerinformationen oder Portkomponenten. Da "@" und ":" nicht als gültige Autoritätswerte zulässig sind, schlägt die Suche fehl, wenn sie enthalten sind. Jeder der folgenden Fehler schlägt fehl.

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

Pfad (ms-resource)

Der Pfad identifiziert die hierarchische Position der ResourceMap-Unterstruktur (siehe Ressourcenverwaltungssystem) und die NamedResource darin. In der Regel entspricht dies dem Dateinamen (mit Ausnahme der Erweiterung) einer Ressourcendateien (RESW) und dem Bezeichner einer Zeichenfolgenressource darin.

Beispiele und weitere Informationen finden Sie unter Lokalisieren von Zeichenfolgen in Der Ui- und App-Paketmanifest und Kachel- und Popupbenachrichtigungsunterstützung für Sprache, Skalierung und hohen Kontrast.

Die Pfadkomponente von ms-resource ist, z. B. generische URIs, Groß-/Kleinschreibung zu beachten. Beim zugrunde liegenden Abruf wird jedoch ein CompareStringOrdinal mit ignoreCase festgelegt.true

Die normalisierte Form des URI behält die Groß-/Kleinschreibung bei und die Prozent-Decodierung (ein "%"-Symbol gefolgt von der zweistelligen hexadezimalen Darstellung) RFC 3986 nicht reservierte Zeichen. Die Zeichen "?", "#", "/", "*" und """ (das doppelte Anführungszeichen) müssen in einem Pfad prozentcodiert sein, um Daten wie Datei- oder Ordnernamen darzustellen. Alle prozentcodierten Zeichen werden vor dem Abruf decodiert. Verwenden Sie daher diesen URI, um eine Zeichenfolgenressource aus einer Ressourcendatei namens Hello#World.reswabzurufen.

ms-resource:///Hello%23World/String1

Abfrage (ms-resource)

Abfrageparameter werden beim Abrufen von Ressourcen ignoriert. Die normalisierte Form von Abfrageparametern behält die Groß-/Kleinschreibung bei. Abfrageparameter werden während des Vergleichs nicht ignoriert. Abfrageparameter werden mit Groß-/Kleinschreibung verglichen.

Entwickler bestimmter Komponenten, die über dieser URI-Analyse angeordnet sind, können die Abfrageparameter nach Bedarf verwenden.