URI、URL 和 URN

一直以来对于URL与URI都不太明白，这几天项目中正好用到这两个东西，因此就在网上查了下，为了避免以后继续去查，就把目前用的写下来：
JDK文档引用：

引用

URI 是统一资源标识符，而 URL 是统一资源定位符。因此，笼统地说，每个 URL 都是 URI，但不一定每个 URI 都是 URL。这是因为 URI 还包括一个子类，即统一资源名称 (URN)，它命名资源但不指定如何定位资源。上面的 mailto、news 和 isbn URI 都是 URN 的示例。如：

mailto:[email protected]
news:comp.lang.java
urn:isbn:096139210x

URI 和 URL 概念上的不同反映在此类和 URL 类的不同中。

此类的实例代表由 RFC 2396 定义的语法意义上的一个 URI 引用。URI 可以是绝对的，也可以是相对的。对 URI 字符串按照一般语法进行解析，不考虑它所指定的方案（如果有）不对主机（如果有）执行查找，也不构造依赖于方案的流处理程序。相等性、哈希计算以及比较都严格地根据实例的字符内容进行定义。换句话说，一个 URI 实例和一个支持语法意义上的、依赖于方案的比较、规范化、解析和相对化计算的结构化字符串差不多。

作为对照，URL 类的实例代表了 URL 的语法组成部分以及访问它描述的资源所需的信息。URL 必须是绝对的，即它必须始终指定一个方案。URL 字符串按照其方案进行解析。通常会为 URL 建立一个流处理程序，实际上无法为未提供处理程序的方案创建一个 URL 实例。相等性和哈希计算依赖于方案和主机的 Internet 地址（如果有）；没有定义比较。换句话说，URL 是一个结构化字符串，它支持解析的语法运算以及查找主机和打开到指定资源的连接之类的网络 I/O 操作。

引用

URL 类自身并不根据 RFC2396 中定义的转义机制编码或解码任何 URL 部分。由调用方对任何需要在调用 URL 前进行转义的字段进行编码，并对从 URL 返回的任何经过转义的字段进行解码。进一步而言，由于 URL 不懂 URL 转义，所以它不会识别同一 URL 的对等编码和解码形式。例如，对于这两个 URL：

    http://foo.com/hello world/ 和 http://foo.com/hello%20world

将被视为互不相等。

注意，URI 类在某些特定情况下对其组成字段执行转义。建议使用 URI 管理 URL 的编码和解码，并使用 toURI() 和 URI.toURL() 实现这两个类之间的转换。

也可以使用 URLEncoder 和 URLDecoder 类，但是只适用于 HTML 形式的编码，它与 RFC2396 中定义的编码机制不同。

通过上面的引用，可以看出，一般使用URI对字段参数进行转码，如有中文参数时，就需要这样：

 try {
			return new URI(url).toASCIIString();
		} catch (URISyntaxException e) {
			e.printStackTrace();
			return url;
		}

其中toASCIIString 方法返回不包含任何 other 字符的、完全引用的和经过编码的 URI 字符串。这个方法内部实际上使用的是utf-8的编码方式，所以如果uri中文参数还是为乱码，需要将服务器如tomcat中的server.xml的中加上URIEncoding="UTF-8"。从上面的引用可以看出，这个类比使用URLDecoder通用一些。
至于URL这个类，更多的是打开并获取内容，而不是定位。通过URL可以打开某个网页并提取里面的内容，非常的方便。其实这是一个非常好的想法，如果想获取另一台服务器上的某些数据，就可以这么干，可以不再写什么webservice、hession之类，当然如果数据太复杂太多，那就不能这样做了。