URI-Schemas

Applies to Windows and Windows Phone

Sie können URI (Uniform Resource Identifier)-Schemas verwenden, um auf App-Dateien zu verweisen, die aus dem Paket, den Datenordnern oder Ressourcen der App stammen.

ms-appx(-web)

Verwenden Sie die Schemas "ms-appx" und "ms-appx-web", um auf App-Dateien zu verweisen, die aus dem App-Paket (siehe App-Pakete und -Bereitstellung) stammen. Bei diesen Dateien handelt es sich in der Regel um statische Bilder, Daten, Code und Layoutdateien. Das Schema "ms-appx-web" verweist auf dieselben Dateien, allerdings im Webdepot. Informationen zur allgemeinen Verwendung finden Sie unter So wird's gemacht: Laden von Dateiressourcen.

Schemaname

Die Zeichenfolge "ms-appx"

ms-appx://

oder "ms-appx-web" stellt den URI-Schemanamen dar.

ms-appx-web://

Der Schemaname folgt den typischen URI-Regeln (RFC 3986) für die Normalisierung und den Ressourcenabruf für Schemas. Der Schemaname setzt sich aus US-ASCII-Zeichen (ohne Berücksichtigung der Groß-/Kleinschreibung) zusammen, die normalisierte Form des Schemanamens enthält nur Kleinbuchstaben.

Hierarchischer Teil

Bei diesem URI-Schema wird der hierarchische Teil gemäß RFC 3986 als die Autoritäts- und Pfadkomponenten des URI definiert:

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

Autorität

Bei der Autorität handelt es sich um einen Bezeichner aus US-ASCII-Zeichen (ohne Berücksichtigung der Groß-/Kleinschreibung) der Entität, die als Besitzer der Dateien fungiert.

Die URI- oder IRI (Internationalized Resource Identifier)-Autorität für das Schema "ms-appx(-web)" ist der im Paketmanifest definierte Paketidentitätsname (siehe App-Pakete und -Bereitstellung). Sie ist daher sowohl in der IRI- als auch der URI-Form auf den für den Paketidentitätsnamen zulässigen Zeichensatz beschränkt. Der Paketname ist auf die Zeichen des aktuellen Paketabhängigkeitsdiagramms der ausgeführten App beschränkt.

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

Werden in der Autorität andere Zeichen angegeben, schlagen Abruf und Vergleich fehl.

Wenn die angegebene Autorität leer ist, ist der Wert für die Autorität das Paket der derzeit ausgeführten App:

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

Die normale Form der Autorität ist der Paketidentitätsname. Dieser wird in Kleinbuchstaben gemäß der US-ASCII-Schreibweise (ohne Berücksichtigung der Groß-/Kleinschreibung) angegeben. Beispiel:

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

Folglich kann beim Abrufen der Ressource die Autorität in Groß- oder Kleinbuchstaben angegeben sein. Beide Schreibweisen verweisen auf dieselbe Ressource.

Benutzerinformationen und Port

Das Schema "ms-appx" definiert im Gegensatz zu anderen beliebten Schemas keine Benutzerinformationen oder Portkomponente. Da "@" und ":" nicht als gültige Autoritätswerte zulässig sind, schlägt die Suche fehl, wenn diese Zeichen enthalten sind. Folgende Beispiele schlagen fehl:

// 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

Pfad

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 ist in einem Ordner enthalten, der mit dem Installationsort des Pakets einer von der Autorität angegebenen App verknüpft ist.

Die Pfadkomponente kann anstelle einer physischen eine logische Ressource definieren. In diesem Fall wird die tatsächlich während des Abrufs zurückgegebene Ressource zur Laufzeit mittels Inhaltsaushandlung ermittelt. Die Ermittlung basiert auf dem aktuellen Zustand des Systems, damit die am besten geeignete Ressource identifiziert werden kann. Wenn die Pfadkomponente stattdessen nicht auf einen logischen, sondern einen physischen Dateipfad verweist, wird das physische Dateiobjekt ohne Inhaltsaushandlung abgerufen.

Die Sprachen der App, die Anzeigeeinstellungen des Systems und die Kontrasteinstellungen des Benutzers werden beispielsweise vielleicht berücksichtigt, wenn der tatsächliche abzurufende Ressourcenwert ermittelt wird:

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

Im obigen Beispiel kann tatsächlich eine Datei im Contoso.myapp-Paket mit folgendem Namen abgerufen werden:

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

Sie können ggf. auch direkt auf das physische Bild verweisen:

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

Eine Einführung zu häufig verwendeten Werten finden Sie unter So wird's gemacht: Laden von Dateiressourcen.

Bei der Pfadkomponente von "ms-appx(-web)" muss wie bei generischen URIs die Groß-/Kleinschreibung beachtet werden. Wenn beim zugrunde liegenden Dateisystem, von dem auf die Ressource zugegriffen wird, wie bei NTFS die Groß-/Kleinschreibung nicht berücksichtigt wird, wird auch beim Abrufen der Ressource die Groß-/Kleinschreibung ignoriert.

Bei der normalisierten Form des URI bleibt die Groß-/Kleinschreibung erhalten, und von nicht reservierten RFC 3986-Zeichen werden die Prozentzeichen entfernt.

Die Zeichen "?", "#", "/", "*" und '”' (doppelte Anführungszeichen) müssen in einem Pfad mit einem Prozentzeichen versehen werden, um Daten wie Datei- oder Ordnernamen anzugeben. Alle mit Prozentzeichen versehenen Zeichen werden vor dem Abrufen decodiert. Verwenden Sie daher zum Abrufen der Datei "Hello#World.html" folgende Zeichenfolge:

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

Abfrage

Abfrageparameter werden während des Abrufens von Ressourcen ignoriert. Bei der normalisierten Form von Abfrageparametern wird die Groß-/Kleinschreibung erhalten. Abfrageparameter werden beim Vergleich nicht ignoriert.

Entwickler bestimmter Komponenten, die sich in Ebenen über dieser URI-Analyse befinden, können die Abfrageparameter flexibel verwenden. Der App-Host kann z. B. eine bestimmte HTML-Datei abrufen und dabei die Abfrageparameter ignorieren. Der in der Seite ausgeführte Code kann die Abfrageparameter aber weiterhin als Zustand verwenden, um bestimmte Elemente auf der Seite zu rendern.

Fragment

Die Fragment-Komponente wird bei der schemaspezifischen Verarbeitung von URIs ignoriert. Beim Ressourcenabruf und Vergleich hat die Fragment-Komponente keine Bedeutung. Ebenen über einer bestimmten Implementierung können die Fragment-Komponente jedoch so interpretieren, dass sie eine sekundäre Ressource abruft.

Der App-Host kann beispielsweise ms-appx-URIs verarbeiten, wobei zum URI "ms-appx:" navigiert und ein Bildlauf zum von der Fragment-Komponente angegebenen Ankerpunkt durchgeführt wird, doch die spezielle URLMon-Implementierung von "ms-appx:" ist nur für das Abrufen der HTML-Seite verantwortlich und ignoriert dabei die Fragment-Komponente.

Vergleich

Der Vergleich findet byteweise nach der Normalisierung aller IRI-Komponenten statt.

ms-appdata

Verweisen Sie mithilfe des Schemas "ms-appdata" auf App-Dateien, die aus den lokalen und temporären Datenordnern sowie Roamingdatenordnern stammen. Informationen zur allgemeinen Verwendung finden Sie unter So wird's gemacht: Laden von Dateiressourcen, und weitere Details zu App-Daten finden Sie unter Zugreifen auf App-Daten mit der Windows-Runtime.

Schemaname

Die Zeichenfolge "ms-appdata" stellt den URI-Schemanamen dar.

ms-appdata://

Das URI-Schema folgt den typischen IRI-Regeln für die Normalisierung und den Ressourcenabruf für Schemas. Der Schemaname besteht aus US-ASCII-Zeichen (ohne Berücksichtigung der Groß-/Kleinschreibung), und die normalisierte Form des Schemanamens enthält nur Kleinbuchstaben.

Hierarchischer Teil

Bei diesem URI-Schema wird der hierarchische Teil gemäß RFC 3986 als die Autoritäts- und Pfadkomponenten des URI definiert:

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

Autorität

Die Autorität für den URI "ms-appdata" ist der Paketidentitäsname (siehe App-Pakete und -Bereitstellung), der im Paketmanifest definiert wird. Der Paketname ist auf das aktuelle Paket der ausgeführten App beschränkt.

ms-appdata://Contoso.MyApp/

Werden in der Autorität andere Zeichen angegeben, schlagen Abruf und Vergleich fehl.

Wenn die angegebene Autorität leer ist, ist der Wert für die Autorität das Paket der derzeit ausgeführten App:

ms-appdata:///

Die normale Form der Autorität ist der Paketidentitätsname. Dieser wird in Kleinbuchstaben gemäß der US-ASCII-Schreibweise (ohne Berücksichtigung der Groß-/Kleinschreibung) angegeben.

Benutzerinformationen und Port

Das Schema "ms-appdata" definiert im Gegensatz zu anderen beliebten Schemas keine Benutzerinformationen oder Portkomponente. Da "@" und ":" nicht als gültige Autoritätswerte zulässig sind, schlägt die Suche fehl, wenn diese Zeichen enthalten sind. Folgende Beispiele schlagen fehl:

// 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

Pfad

Am Speicherort Windows.Storage.ApplicationData befinden sich drei reservierte Ordner für lokale und temporäre Statusspeicher sowie für Roamingstatusspeicher. Das Schema "ms-appdata" ermöglicht den Zugriff auf Dateien und Ordner an diesen Speicherorten. Im ersten Segment der Pfadkomponente muss der bestimmte Ordner in folgendem Format angegeben werden. Daher ist die Form "path-empty" von "hier-part" nicht zulässig.

Lokaler Ordner:

ms-appdata:///local/

Temporärer Ordner:

ms-appdata:///temp/

Roamingordner:

ms-appdata:///roaming/

Bei der Pfadkomponente von "ms-appdata" muss wie bei generischen URIs die Groß-/Kleinschreibung beachtet werden. Wenn beim zugrunde liegenden Dateisystem, von dem auf die Ressource zugegriffen wird, wie bei NTFS die Groß-/Kleinschreibung nicht berücksichtigt wird, wird auch beim Abrufen der Ressource die Groß-/Kleinschreibung ignoriert.

Bei der normalisierten Form des URI bleibt die Groß-/Kleinschreibung erhalten, und von nicht reservierten RFC 3986-Zeichen werden die Prozentzeichen entfernt.

Die Zeichen "?", "#", "/", "*" und '”' (doppelte Anführungszeichen) müssen in einem Pfad mit einem Prozentzeichen versehen werden, um Daten wie Datei- oder Ordnernamen anzugeben. Alle mit Prozentzeichen versehenen Zeichen werden vor dem Abrufen decodiert. Verwenden Sie daher zum Abrufen der Datei "Hello#World.xml" folgende Zeichenfolge:

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

Der Abruf der Ressource und die Identifikation des Segments für den Pfad auf oberster Ebene werden nach der Normalisierung von Punkten behandelt (".././b/c"). Daher können bei URIs keine Punkte für die reservierten Ordner verwendet werden. Die folgenden URI sind also nicht zulässig:

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

Dieser URI ist jedoch zulässig:

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

Abfrage

Abfrageparameter werden während des Abrufens von Ressourcen ignoriert. Bei der normalisierten Form von Abfrageparametern wird die Groß-/Kleinschreibung erhalten. Abfrageparameter werden beim Vergleich nicht ignoriert.

Entwickler bestimmter Komponenten, die sich in Ebenen über dieser URI-Analyse befinden, können die Abfrageparameter flexibel verwenden. Der App-Host kann z. B. ein bestimmtes Bild abrufen und dabei die Abfrageparameter ignorieren, während der in der Seite ausgeführte Code die Abfrageparameter als Zustand zum Rendern bestimmter Elemente auf der Seite verwendet.

Fragment

Die Fragment-Komponente wird bei der schemaspezifischen Verarbeitung von URIs ignoriert. Beim Ressourcenabruf und Vergleich hat die Fragment-Komponente keine Bedeutung. Ebenen über einer bestimmten Implementierung können die Fragment-Komponente jedoch so interpretieren, dass sie eine sekundäre Ressource abruft.

ms-resource

Verweisen Sie mithilfe des Schemas "ms-resource" auf App-Ressourcen, bei denen es sich in der Regel um Zeichenfolgenressourcen handelt. Dieses Schema wird normalerweise zusammen mit der Windows.ApplicationModel.Resources-, Windows.ApplicationModel.Resources.Core- oder WinJS.Resources-API zum Suchen von Ressourcen in PRI-Dateien verwendet (siehe Ressourcenverwaltungssystem). Informationen zu allgemeinen Verwendungsmustern finden Sie unter So wird's gemacht: Laden von Zeichenfolgenressourcen.

Schemaname

Die Zeichenfolge "ms-resource" stellt den URI-Schemanamen dar.

ms-resource://

Das URI-Schema folgt den typischen URI-Regeln für die Normalisierung und den Ressourcenabruf für Schemas. Der Schemaname setzt sich aus US-ASCII-Zeichen (ohne Berücksichtigung der Groß-/Kleinschreibung) zusammen, die normalisierte Form des Schemas enthält nur Kleinbuchstaben.

Hierarchischer Teil

Bei diesem URI-Schema wird der hierarchische Teil gemäß RFC 3986 als die Autoritäts- und Pfadkomponenten des URI definiert:

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

Autorität

Bei der Autorität für den URI "ms-resource" handelt es sich um die im PRI definierte Ressourcenzuordnung der obersten Ebene, die in der Regel dem Paketidentitätsnamen entspricht (siehe App-Pakete und -Bereitstellung), der im Paketmanifest festgelegt ist. Bei Windows Store-Apps ist der Name der Ressourcenzuordnung auf die Namen im Paketabhängigkeitsdiagramm der momentan ausgeführten App beschränkt.

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

Werden in der Autorität andere Zeichen angegeben, schlagen Abruf und Vergleich fehl.

Wenn der angegebene Hostname leer ist, ist der Wert für den Hostnamen der Paketname (unter Berücksichtigung der Groß-/Kleinschreibung) der momentan ausgeführten App:

ms-resource:///

Bei der Autorität wird die Groß-/Kleinschreibung berücksichtigt und bei der normalisierten Form die Groß-/Kleinschreibung erhalten. Bei der Suche nach einer Ressource wird die Groß-/Kleinschreibung jedoch ignoriert.

Benutzerinformationen und Port

Das Schema "ms-resource" definiert im Gegensatz zu anderen beliebten Schemas keine Benutzerinformationen oder Portkomponente. Da "@" und ":" nicht als gültige Autoritätswerte zulässig sind, schlägt die Suche fehl, wenn diese Zeichen enthalten sind. Folgende Beispiele schlagen fehl:

// 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

Pfad

Der Pfad gibt den hierarchischen Ort der ResourceMap-Unterstruktur (siehe Ressourcenverwaltungssystem) und das darin enthaltene NamedResource-Element an. Dies entspricht in der Regel dem Dateinamen (ohne Erweiterung) der Ressourcendatei und dem Namen der darin enthaltenen Ressource. Beispiel: Für die Datei "resources.resjson", die

{
    "String1" : "Hello World"
}

enthält, kann der folgende ms-resource-URI verwendet werden:

ms-resource:///resources/String1

Bei der Pfadkomponente von "ms-resource" muss wie bei generischen URIs die Groß-/Kleinschreibung beachtet werden. Beim zugrunde liegenden Abruf wird allerdings ein CompareStringOrdinal-Vorgang ausgeführt, bei dem ignoreCase als Abruf ohne Berücksichtigung der Groß- und Kleinschreibung festgelegt ist.

Bei der normalisierten Form des URI wird die Groß-/Kleinschreibung erhalten.

Die Zeichen "?", "#", "/", "*" und '”' (doppelte Anführungszeichen) müssen in einem Pfad mit einem Prozentzeichen versehen werden, um Daten wie Datei- oder Ordnernamen anzugeben. Alle mit Prozentzeichen versehenen Zeichen werden vor dem Abrufen decodiert. Verwenden Sie daher zum Abrufen der Datei "Hello#World.xml" folgende Zeichenfolge:

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

Abfrage

Abfrageparameter werden beim Vergleich nicht ignoriert. Beim Vergleichen von Abfrageparametern wird die Groß-/Kleinschreibung berücksichtigt. Abfrageparameter werden während des Abrufens von Ressourcen ignoriert.

Entwickler bestimmter Komponenten, die sich in Ebenen über dieser URI-Analyse befinden, können die Abfrageparameter flexibel verwenden.

Fragment

Die Fragment-Komponente wird bei der schemaspezifischen Verarbeitung von URIs ignoriert. Beim Ressourcenabruf und Vergleich hat die Fragment-Komponente keine Bedeutung. Ebenen über einer bestimmten Implementierung können die Fragment-Komponente jedoch so interpretieren, dass sie eine sekundäre Ressource abruft.

Verwandte Themen

RFC 3986: Uniform Resource Identifier (URI): Allgemeine Syntax
So wird's gemacht: Laden von Dateiressourcen
So wird's gemacht: Laden von Zeichenfolgenressourcen
Zugriff auf App-Daten mit der Windows-Runtime
App-Pakete und -Bereitstellung
Ressourcenverwaltungssystem
Windows.ApplicationModel.Resources
Windows.ApplicationModel.Resources.Core
Windows.Storage.ApplicationData
WinJS.Resources

 

 

Anzeigen:
© 2014 Microsoft