HTTP URL语法 对于HTTP URL (使用http 或 https 协议)，URL的scheme描述部分定义了数据的路径（path），后面是可选的query 和 fragment。
path 部分看上去是一个分层的结构，类似于文件系统中文件夹和文件的分层结构。path由"/"字符开始，每一个文件夹由"/"分隔，最后是文件。例如"/photos/egypt/cairo/first.jpg"有四个路径片段（segment）："photos"、"egypt"、"cairo" 和 "first.jpg"，可以由此推出："first.jpg" 文件在文件夹"cairo"中，而"egypt" 文件夹位于web站点的根文件夹"photos"里面。
每一个path片段 可以有可选的 path参数 (也叫 matrix参数)，这是在path片段的最后由";"开始的一些字符。每个参数名和值由"="字符分隔，像这样："/file;p=1"，这定义了path片段 "file"有一个path参数 "p"，其值为"1"。这些参数并不常用 — 这得清楚 — 但是它们确实是存在，而且从 Yahoo RESTful API 文档我们能找到很好的理由去使用它们：
Matrix参数可以让程序在GET请求中可以获取部分的数据集。参考数据集的分页。因为matrix参数可以跟任何数据集的URI格式的path片段，它们可以在内部的path片段中被使用。
在 路径(path)部分之后是 查询 (query)部分，它和 路径 之间由一个“?”隔开， 查询部分包含了一个由“&”分隔开的参数列表，每一个参数由参数名称、“=”号以及参数值组成。比如"/file?q=2"定义了一个 查询参数 "q" ，它的值是"2"。这在提交 HTML表单时，或者当你使用诸如Google搜索等应用时， 用的非常多。
一个HTTP URL的最后部分是一个段落(fragment)部分，用来指向HTML文件中具体的某个部分，而不是整个HTML页面。比如说，当你点击链接时浏览器自动滚屏到某个部分而不是从页面最顶部开始展示，就说明你点击了一个拥有段落部分的URL。
URL 语法 http URL 方案最初由 RFC 1738 定义（实际上，在之前的 RFC 1630也有涉及），而在 http URL 方案被重新定义之前，整个 URL 语法就已经由扩展了几次 以适应发展的规范进化为一套 统一资源标识符（Uniform Resource Identifiers 即 URIs)。
对于 URLs 如何拼装，各部分如何分隔有一套语法。例如："://"分隔方案和主机部分。主机同路径片段部分由"/"分隔，而查询部分紧跟在"?"之后。这意味着有些字符为语法保留。有些为整个URIs保留，而有些则被特定方案保留。所有出现在不应出现位置的 保留符（例如路径片段——以文件名为例——可能包含"?"）必须被URL 编码。
URL 编码将字符转变成对 URL 解析无意义的无害形式。它将字符转化成为一种特定字符编码的字节序列，然后将字节转换为16进制形式，并将其前面加上"%"。问号的 URL 编码形式为"%3F"。
现今多数浏览器显示 URLs 前都会对其解码（将百分号编码字节转回其原本字符），并在获取其网络资源的时候重新编码。这样一来，很多用户从未意识到编码的存在。
另一方面，网页作者，开发者必须明确认识到这一点，因为这里存在着很多陷阱。
URL常见陷阱 如果你正和URL打交道，了解下能够避免的常见陷阱绝对是值得的。现在我们给大家介绍下不仅限于此的一些常见陷阱。
使用哪类字符编码? URL编码规范并没有定义使用何种字符编码形式去编码字节。一般的ASCII字母数字字符并不需要转义，但是ASCII之外的保留字需要(例如法语单词“nœud”中的"œ")。我们必须提出疑问，应该使用哪类字符编码来编码URL字节。
当然如果只有Unicode的话，这个世界就会清净很多。因为每个字符都包含其中，但是它只是一个集合，或者说是列表如果你愿意，它本身并不是一中编码。Unicode可以使用多种方式进行编码，譬如UTF-8或者UTF-16（也有其它格式），但是问题并没有解决：我们应该使用哪类字符来编码URL（通常也指URI）。
标准并没有定义一个URI应该以何种方式指定其编码，所以其必须从环境信息中进行推导。对于HTTP URL，它可以是HTML页面的编码格式，或HTTP头的。这通常会让人迷惑，也是许多错误的根源。事实上，最新版的URI标准 定义了新的URI scheme将采用UTF-8，host（甚至已有的scheme）也使用UTF-8，这让我更加怀疑：难道host和path真的可以使用不同的编码方式？转载请注明来源职称论文代发http://www.400qikan.com
354
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
