Win8 URI Scheme ms-appx usage Daquan

ms-appdata://can reference app files from your app's local, roaming, and temporary data folders
Ms-appdata:///local/hello/logo.png

ms-appx://can reference application files from the app package
Ms-appx://[email protected]/default.html

MS-RESOURCE://can reference application resources, usually string resources

Ms-resource://[email protected]/resources/string1

You can use the URI (Uniform Resource Identifier) scheme to reference application files from an app package, data folder, or resource.

MS-APPX (-web)

Use the ms-appx and Ms-appx-web scenarios to refer to the app files from the app package (see app Packages and Deployment). These files are usually static images, data, code, and layout files. The Ms-appx-web scheme references the same file, but it is in the Web zone. For common usage, see how to load file resources.

Scheme name

This URI scheme name is the string "ms-appx"

ms-appx://

or "Ms-appx-web".

ms-appx-web://

This scenario name follows a typical URI rule (RFC 3986) to standardize the scenario and retrieve resources. This scheme name is US-ASCII, case-insensitive, and the standardized form of the scheme name is lowercase.

Layered Sections

This URI scheme defines its hierarchical section as the authority and path component of the URI in accordance with RFC 3986:

URI         = scheme ":" Hier-part ["?" query] ["#" Fragment]hier-part   = "//" authority Path-abempty            /Path-absolu Te            /path-rootless            /Path-empty

Authority

Authority is the us-ascii identifier of the entity that owns the file, not case sensitive.

The URI or IRI (internationalized resource Identifier) of the MS-APPX (-web) Scheme Authority is the package identity name defined in the package manifest (see App Package and Deployment). Therefore, it is limited to the set of characters allowed in the package identity name in IRI and URI form. The package name is limited to those names in the app package dependency graph for the app that is currently running.

ms-appx://contoso.myapp/ms-appx-web://contoso.myapp/

If any other characters are provided in the authority, the retrieval and comparison will fail.

When a given authority is empty, the value of authority is the app package that is currently running the app:

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

The standard form of authority is to use the Us-ascii lowercase package identity name, which is case-insensitive. For example

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

In this way, authority can be lowercase or uppercase during resource retrieval, but any one will point to the same resource.

User Information and Ports

Unlike other common scenarios, the MS-APPX scenario does not define user information or port components. Because "@" and ":" are not allowed as valid authority values, the lookup will fail if these characters are included. Each of the following conditions will fail:

Examples of schemes that Fail:ms-appx://[email Protected]/default.htmlms-appx://john:[email protected]/ Default.htmlms-appx://contoso.myapp:8080/default.htmlms-appx://john:[email protected]:8080/default.html

Path

The path component matches the regular RFC 3986 syntax and supports non-ASCII characters in IRI.

The logical or physical file path of the path component definition file. The file is located in the folder associated with the app package installation location for the app specified by authority.

The path component can define a logical resource, not a physical resource. In this case, the actual resource returned during the retrieval is determined at run time using content negotiation. This decision identifies the most appropriate resource based on the current state of the system. When the path component points to a physical file path instead of a logical path, no content negotiation occurs when the physical file asset is retrieved.

For example, when you determine the actual resource value to retrieve, you might consider the language of the app, the display settings for the system, and the user's contrast settings:

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

The above example might actually retrieve a file with the following name in the Contoso.myapp package

Images/fr-fr/logo.scale-100_contrast-white.png

If necessary, you can also point directly to the physical image:

For an introduction to common values, see how to load file resources.

As with the common URI, the path component of MS-APPX (-web) is case-sensitive. However, when the base file system used to access the resource is case-insensitive, for example, NTFS, the resource is not case-sensitive when it is retrieved.

The normalized form of the URI remains case-insensitive and the percentage decodes characters that are not reserved by RFC 3986.

The characters "?", "#", "/", "*", and "" (double quotation marks) must be encoded in the path to represent data, such as a file or folder name. All percent-encoded characters are decoded before they are retrieved. In this case, to retrieve a file named hello#world.html, use the

Ms-appx:///hello%23world.html

Query

The query parameter is ignored during resource retrieval. The normalized form of the query parameter remains case-sensitive. The query parameter is not ignored during the comparison.

Developers of specific components layered on this URI analysis can choose to use the query parameter as needed. For example, an app managed process can retrieve a specific HTML file and ignore the query parameters. However, code that runs on a page can still use query parameters as state to render certain content on the page.

Fragment

The fragment component is ignored for schema-specific processing of URIs. The fragment component has no meaning during resource retrieval and comparison. However, the layers above the specific implementation may interpret fragment to retrieve the secondary resources.

For example, the app managed process might handle the ms-appx URI, which navigates to Ms-appx:uri and scrolls to the anchor point of the fragment identity, but ms-appx: the specific URLMon implementation is only responsible for retrieving the HTML page, and the fragment is ignored.

Comparison

After all IRI components have been normalized, the comparison is taken by byte.

Ms-appdata

Use the Ms-appdata scheme to reference application files from your app's local, roaming, and temporary data folders. For common usage, see how to load file resources, for more information about app data, see Accessing app data using the Windows runtime.

Scheme name

This URI scheme name is the string "Ms-appdata".

ms-appdata://

This URI scheme follows the typical IRI rules to achieve the standardization of the scheme and the retrieval of resources. This scheme name is US-ASCII, case-insensitive, and the standardized form of the scheme name is lowercase.

Layered Sections

This URI scheme defines its hierarchical section as the authority and path component of the URI in accordance with RFC 3986:

URI         = scheme ":" Hier-part ["?" query] ["#" Fragment]hier-part   = "//" authority Path-abempty            /Path-absolu Te            /path-rootless            /Path-empty

Authority

The authority of the Ms-appdata URI is the package identity name defined in the package manifest (see App Package and Deployment). The package name is limited to the app package that is currently running the app.

ms-appdata://contoso.myapp/

If any other characters are provided in the authority, the retrieval and comparison will fail.

When a given authority is empty, the value of authority is the app package that is currently running the app:

ms-appdata:///

The standard form of authority is to use the Us-ascii lowercase package identity name, which is case-insensitive.

User Information and Ports

Unlike other common scenarios, the Ms-appdata scenario does not define user information or port components. Because "@" and ":" are not allowed as valid authority values, the lookup will fail if these characters are included. Each of the following conditions will fail:

Examples of schemes that Fail:ms-appdata://[email Protected]/local/data.xmlms-appdata://john:[email protected]/ Local/data.xmlms-appdata://contoso.myapp:8080/local/data.xmlms-appdata://john:[email protected]:8080/local/ Data.xml

Path

In Windows.Storage.ApplicationData , the location is the three reserved folders for local, roaming, and temporary state storage. The Ms-appdata scheme allows access to files and folders in these locations. The first paragraph of the path component must specify a specific folder in the following manner. Therefore, the "path-empty" form of "Hier-part" is illegal.

Local folder:

ms-appdata:///local/

Temp folder:

ms-appdata:///temp/

Roaming folders:

ms-appdata:///roaming/

As with the common URI, the path component of the ms-appdata is case-sensitive. However, when you access resources that use a base file system that is not case-sensitive, such as for Microsoft Windows NT file System (NTFS), retrieving resources is case-insensitive.

The normalized form of the URI remains case-insensitive and the percentage decodes characters that are not reserved by RFC 3986.

The characters "?", "#", "/", "*", and "" (double quotation marks) must be encoded in the path to represent data, such as a file or folder name. All percent-encoded characters are decoded before they are retrieved. In this case, to retrieve a file named Hello#world.xml, use the

Ms-appdata:///hello%23world.xml

Standardize at the point of Use (".. /./B/C ") to retrieve the identity of the resource and the top-level path segment after processing. Therefore, you cannot use a point in a URI to represent a folder outside of a reserved folder. Therefore, the following URIs are not allowed:

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

However, the following URIs are allowed:

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

Query

The query parameter is ignored during resource retrieval. The normalized form of the query parameter remains case-sensitive. The query parameter is not ignored during the comparison.

Developers of specific components layered on this URI analysis can choose to use the query parameter as needed. For example, an app managed process can retrieve a specific image, ignoring the query parameter, but code running on a page can use the query parameter as a state to render specific content on that page.

Fragment

The fragment component is ignored for schema-specific processing of URIs. The fragment component has no meaning during resource retrieval and comparison. However, the layers above the specific implementation may interpret fragment to retrieve the secondary resources.

Ms-resource

Use the Ms-resource scheme to reference application resources, typically string resources. This scenario is typically associated with Windows.ApplicationModel.Resources,Windows.ApplicationModel.Resources.Core , or The winjs.resources API is used in conjunction to perform lookups on resources in a PRI file (see Resource Management System). For common usage patterns, see how to load string resources.

Scheme name

This URI scheme name is the string "Ms-resource".

ms-resource://

This URI scheme follows a typical URI rule to standardize the schema and retrieve resources. This scheme name is US-ASCII, is case-insensitive, and the scheme is standardized in lowercase.

Layered Sections

This URI scheme defines its hierarchical section as the authority and path component of the URI in accordance with RFC 3986:

URI         = scheme ":" Hier-part ["?" query] ["#" Fragment]hier-part   = "//" authority Path-abempty            /Path-absolu Te            /path-rootless            /Path-empty

Authority

The authority of the Ms-resource URI is the top-level resource mapping defined in the PRI, usually corresponding to the package identity name defined in the package manifest (see App Package and Deployment). For Windows store apps, the resource mapping name is restricted to those names in the package dependency graph where the app is currently running.

ms-resource://contoso.myapp/ms-resource://microsoft.winjs.1.0/

If any other characters are provided in the authority, the retrieval and comparison will fail.

When a given host name is empty, the hostname value is the package name of the currently running app, case-sensitive:

ms-resource:///

Authority are case-sensitive and are normalized to keep their capitalization. However, finding resources is case-insensitive.

User Information and Ports

Unlike other common scenarios, the Ms-resource scenario does not define user information or port components. Because "@" and ":" are not allowed as valid authority values, the lookup will fail if these characters are included. Each of the following conditions will fail:

Examples of schemes that fail:ms-resource://[email Protected]/resources/string1ms-resource://john:[email protected ]/resources/string1ms-resource://contoso.myapp:8080/resources/string1ms-resource://john:[email protected]:8080/ Resources/string1

Path

Path identifies the Resourcemap subtree (see Resource management System) and the hierarchical location where namedresource is located. Typically, this corresponds to the file name (not including the extension) of the resource file and the name of the resource in it. For example, for a file named Resources.resjson, which contains

{    "String1": "Hello World"}

You can use the following Ms-resource URI:

Ms-resource:///resources/string1

As with the common URI, the path component of the Ms-resource is case-sensitive. However, the base search performs comparestringordinalwhen ignoreCase is set to true, and is not case-sensitive when retrieved.

The normalized form of the URI remains case-sensitive.

The characters "?", "#", "/", "*", and "" (double quotation marks) must be encoded in the path to represent data, such as a file or folder name. All percent-encoded characters are decoded before they are retrieved. In this case, to retrieve a file named Hello#world.xml, use the

Ms-appdata:///hello%23world.xml

Query

The query parameter is not ignored during the comparison. Case sensitivity when comparing query parameters. The query parameter is ignored during resource retrieval.

Developers of specific components layered on this URI analysis can choose to use the query parameter as needed.

Fragment

The fragment component is ignored for schema-specific processing of URIs. The fragment component has no meaning during resource retrieval and comparison. However, the layers above the specific implementation may interpret fragment to retrieve the secondary resources.

Related Topics

RFC 3986: Uniform Resource Identifier (URI): General syntax

How to load a file resource

How to load a string resource

Accessing app data using the Windows runtime

App Packages and deployment

Resource management System

Windows.ApplicationModel.Resources

Windows.ApplicationModel.Resources.Core

Windows.Storage.ApplicationData

Winjs.resources

Win8 URI Scheme ms-appx usage Daquan