Win8 URI 方案 ms-appX 用法大全

ms-appdata://可以引用来自应用的本地、漫游和临时数据文件夹中的应用文件
ms-appdata:///local/hello/logo.png

ms-appx://可以引用来自应用包的应用文件
ms-appx://[email protected]/default.html

ms-resource://可以引用应用资源，通常是字符串资源

ms-resource://[email protected]/Resources/String1

可以使用 URI（统一资源标识符）方案引用来自应用包、数据文件夹或资源的应用文件。

ms-appx(-web)

使用 ms-appx 和 ms-appx-web 方案可以引用来自应用包的应用文件（请参阅应用包和部署）。这些文件通常为静态图像、数据、代码和布局文件。ms-appx-web 方案引用相同的文件，但它是在 Web 区域。有关常见用法，请参阅如何加载文件资源。

方案名称

此 URI 方案名称是字符串 "ms-appx"

ms-appx://

或 "ms-appx-web"。

ms-appx-web://

此方案名称遵循典型 URI 规则 (RFC 3986) 来实现方案的标准化和资源检索。此方案名称采用 US-ASCII，不区分大小写，方案名称的标准化形式是小写。

分层部分

此 URI 方案按照 RFC 3986 将其分层部分定义为 URI 的 authority 和 path 组件：

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

Authority

authority 是拥有文件的实体的 US-ASCII 标识符，不区分大小写。

ms-appx(-web) 方案的 URI 或 IRI（国际化资源标识符）authority 是包清单中定义的包标识名称（请参阅应用包和部署）。因此，它在 IRI 和 URI 形式中都限制到在包标识名称中允许的字符集。包名称限制到当前所运行应用的应用包依存关系图中的那些名称。

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

如果在 authority 中提供任何其他字符，则检索和比较将失败。

当给定 authority 为空时，authority 的值是当前正在运行应用的应用包：

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

authority 的标准形式是采用 US-ASCII 的小写包标识名称，不区分大小写。例如，

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

这样，在检索资源期间，authority 可以是小写或大写，但是任何一种都将指向相同的资源。

用户信息和端口

与其他常见方案不同，ms-appx 方案不定义用户信息或端口组件。由于不允许将 "@" 和 ":" 作为有效 authority 值，因此如果包含这些字符，查找将失败。以下每个情况都将失败：

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

Path

path 组件匹配常规 RFC 3986 语法并支持 IRI 中的非 ASCII 字符。

path 组件定义文件的逻辑或物理文件路径。该文件位于与 authority 指定的应用的应用包安装位置关联的文件夹中。

path 组件可以定义一个逻辑资源，而不是物理资源。这种情况下，在检索期间返回的实际资源是在运行时使用内容协商确定的。这个决定基于系统的当前状态来识别最适合的资源。如果 path 组件指向物理文件路径而不是逻辑路径，则检索该物理文件资产时不会进行任何内容协商。

例如，在确定要检索的实际资源值时，可能会考虑应用的语言、系统的显示设置和用户的对比度设置：

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

上面的示例实际上可能检索 Contoso.myapp 包中以下名称的文件

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

如有必要，你也可以直接指向物理图像：

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

有关常用值的介绍，请参阅如何加载文件资源。

与通用 URI 相同，ms-appx(-web) 的 path 组件区分大小写。但是，当访问资源所用的基本文件系统不区分大小写时，例如对于 NTFS，检索资源时将不区分大小写。

URI 的标准化形式保持大小写并百分比解码 RFC 3986 未保留的字符。

字符 "?"、"#"、"/"、"*" 和 ‘"‘（双引号）在路径中必须进行百分比编码才能表示数据，例如文件或文件夹名称。在检索之前，将对所有百分比编码的字符进行解码。这样，要检索名为 Hello#World.html 的文件，请使用

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

Query

在检索资源期间，将忽略 query 参数。query 参数的标准化形式保持大小写。在比较期间不会忽略 query 参数。

在此 URI 分析上分层的特定组件的开发人员可以根据需要选择使用 query 参数。例如，应用托管进程可以检索特定的 HTML 文件，而忽略查询参数。但是，在页面中运行的代码仍然可以将查询参数用作状态来在页面上呈现某些特定内容。

Fragment

对 URI 的方案特定处理将忽略 fragment 组件。在资源检索和比较期间，fragment 组件没有任何意义。但是，在特定实现上方的各层可能会解释 fragment 以检索辅助资源。

例如，应用托管进程可能处理 ms-appx URI，其中导航到 ms-appx: URI 并滚动到 fragment 标识的定位点，但是 ms-appx: 的具体 URLMon 实现仅负责检索 HTML 页，将忽略 fragment。

比较

在所有 IRI 组件标准化后，将逐字节发生比较。

ms-appdata

使用 ms-appdata 方案可以引用来自应用的本地、漫游和临时数据文件夹中的应用文件。有关常见用法，请参阅如何加载文件资源，有关应用数据的详细信息，请参阅使用 Windows 运行时访问应用数据。

方案名称

此 URI 方案名称是字符串 "ms-appdata"。

ms-appdata://

此 URI 方案遵循典型 IRI 规则来实现方案的标准化和资源检索。此方案名称采用 US-ASCII，不区分大小写，方案名称的标准化形式是小写。

分层部分

此 URI 方案按照 RFC 3986 将其分层部分定义为 URI 的 authority 和 path 组件：

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

Authority

ms-appdata URI 的 authority 是包清单中定义的包标识名称（请参阅应用包和部署）。包名称限制到当前所运行应用的应用包。

ms-appdata://Contoso.MyApp/

如果在 authority 中提供任何其他字符，则检索和比较将失败。

当给定 authority 为空时，authority 的值是当前正在运行应用的应用包：

ms-appdata:///

authority 的标准形式是采用 US-ASCII 的小写包标识名称，不区分大小写。

用户信息和端口

与其他常见方案不同，ms-appdata 方案不定义用户信息或端口组件。由于不允许将 "@" 和 ":" 作为有效 authority 值，因此如果包含这些字符，查找将失败。以下每个情况都将失败：

// Examples of schemes that fail:
ms-appdata://[email protected]/local/data.xml
ms-appdata://john:[email protected]/local/data.xml
ms-appdata://contoso.myapp:8080/local/data.xml
ms-appdata://john:[email protected]:8080/local/data.xml

Path

在 Windows.Storage.ApplicationData 中，位置是用于本地、漫游和临时状态存储的三个保留文件夹。ms-appdata 方案允许访问这些位置的文件和文件夹。path 组件的第一段必须以下列方式指定特定文件夹。 因此，"hier-part" 的 "path-empty" 形式非法。

本地文件夹：

ms-appdata:///local/

临时文件夹：

ms-appdata:///temp/

漫游文件夹：

ms-appdata:///roaming/

与通用 URI 相同，ms-appdata 的 path 组件区分大小写。但是，当访问资源所用的基本文件系统不区分大小写时，例如对于 Microsoft Windows NT 文件系统 (NTFS)，检索资源时将不区分大小写。

URI 的标准化形式保持大小写并百分比解码 RFC 3986 未保留的字符。

字符 "?"、"#"、"/"、"*" 和 ‘"‘（双引号）在路径中必须进行百分比编码才能表示数据，例如文件或文件夹名称。在检索之前，将对所有百分比编码的字符进行解码。这样，要检索名为 Hello#World.xml 的文件，请使用

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

在使用点进行标准化 (".././b/c") 后处理对资源和顶级路径段标识的检索。因此，在 URI 中不能使用点来表示保留文件夹外的文件夹。因此，不允许使用以下 URI：

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

但允许使用以下 URI：

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

Query

在检索资源期间，将忽略 query 参数。query 参数的标准化形式保持大小写。在比较期间不会忽略 query 参数。

在此 URI 分析上分层的特定组件的开发人员可以根据需要选择使用 query 参数。例如，应用托管进程可以检索特定图像，而忽略 query 参数，但是在页面中运行的代码可以使用 query 参数作为状态来呈现该页面上的特定内容。

Fragment

对 URI 的方案特定处理将忽略 fragment 组件。在资源检索和比较期间，fragment 组件没有任何意义。但是，在特定实现上方的各层可能会解释 fragment 以检索辅助资源。

ms-resource

使用 ms-resource 方案可以引用应用资源，通常是字符串资源。此方案通常与Windows.ApplicationModel.Resources、Windows.ApplicationModel.Resources.Core 或 WinJS.Resources API 结合使用以对 PRI 文件中的资源执行查找（请参阅资源管理系统）。有关常见使用模式，请参阅如何加载字符串资源。

方案名称

此 URI 方案名称是字符串 "ms-resource"。

ms-resource://

此 URI 方案遵循典型 URI 规则来实现方案的标准化和资源检索。此方案名称采用 US-ASCII，不区分大小写，并且方案的标准化形式是小写。

分层部分

此 URI 方案按照 RFC 3986 将其分层部分定义为 URI 的 authority 和 path 组件：

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

Authority

ms-resource URI 的 authority 是在 PRI 中定义的顶级资源映射，通常对应于包清单中定义的包标识名称（请参阅应用包和部署）。对于 Windows 应用商店应用，资源映射名称限制到当前正在运行应用的包依存关系图中的那些名称。

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

如果在 authority 中提供任何其他字符，检索和比较将失败。

当给定主机名为空时，主机名的值是当前正在运行的应用的包名称，区分大小写：

ms-resource:///

authority 区分大小写，并且标准化形式保持其大小写。但是，查找资源时不区分大小写。

用户信息和端口

与其他常见方案不同，ms-resource 方案不定义用户信息或端口组件。由于不允许将 "@" 和 ":" 作为有效 authority 值，因此如果包含这些字符，查找将失败。以下每个情况都将失败：

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

Path

path 标识 ResourceMap 子树（请参阅资源管理系统）及其中 NamedResource 的分层位置。通常，这对应于资源文件的文件名（不包括扩展名）及其中资源的名称。例如，对于名为 resources.resjson 的文件，其中包含

{
    "String1" : "Hello World"
}

则可以使用以下 ms-resource URI：

ms-resource:///resources/String1

与通用 URI 相同，ms-resource 的 path 组件区分大小写。但是，基本检索在 ignoreCase 设置为 true 时执行 CompareStringOrdinal，检索时不区分大小写。

URI 的标准化形式保持大小写。

字符 "?"、"#"、"/"、"*" 和 ‘"‘（双引号）在路径中必须进行百分比编码才能表示数据，例如文件或文件夹名称。在检索之前，将对所有百分比编码的字符进行解码。这样，要检索名为 Hello#World.xml 的文件，请使用

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

Query

在比较期间不会忽略 query 参数。比较 query 参数时区分大小写。在检索资源期间，将忽略 query 参数。

在此 URI 分析上分层的特定组件的开发人员可以根据需要选择使用 query 参数。

Fragment

对 URI 的方案特定处理将忽略 fragment 组件。在资源检索和比较期间，fragment 组件没有任何意义。但是，在特定实现上方的各层可能会解释 fragment 以检索辅助资源。

相关主题

RFC 3986：统一资源标识符 (URI)：通用语法

如何加载文件资源

如何加载字符串资源

使用 Windows 运行时访问应用数据

应用包和部署

资源管理系统

Windows.ApplicationModel.Resources

Windows.ApplicationModel.Resources.Core

Windows.Storage.ApplicationData

WinJS.Resources