Posts - 89,
Articles - 54,
Comments - 714
14:51 by hyddd, ... 阅读,
　　Http定义了与服务器交互的不同方法，最基本的方法有4种，分别是GET，POST，PUT，DELETE。URL全称是资源描述符，我们可以这样认为：一个URL地址，它用于描述一个网络上的资源，而HTTP中的GET，POST，PUT，DELETE就对应着对这个资源的查，改，增，删4个操作。到这里，大家应该有个大概的了解了，GET一般用于获取/查询资源信息，而POST一般用于更新资源信息。
　　1.根据HTTP规范，GET用于信息获取，而且应该是安全的和幂等的。
　　(1).所谓安全的意味着该操作用于获取信息而非修改信息。换句话说，GET 请求一般不应产生副作用。就是说，它仅仅是获取资源信息，就像数据库查询一样，不会修改，增加数据，不会影响资源的状态。
　　* 注意：这里安全的含义仅仅是指是非修改信息。
　　(2).幂等的意味着对同一URL的多个请求应该返回同样的结果。这里我再解释一下幂等这个概念：
　　幂等（idempotent、idempotence）是一个数学或计算机学概念，常见于抽象代数中。　　幂等有一下几种定义：　　对于单目运算，如果一个运算对于在范围内的所有的一个数多次进行该运算所得的结果和进行一次该运算所得的结果是一样的，那么我们就称该运算是幂等的。比如绝对值运算就是一个例子，在实数集中，有abs(a)=abs(abs(a))。　　对于双目运算，则要求当参与运算的两个值是等值的情况下，如果满足运算结果与参与运算的两个值相等，则称该运算幂等，如求两个数的最大值的函数，有在在实数集中幂等，即max(x,x)&=&x。
看完上述解释后，应该可以理解GET幂等的含义了。
　　但在实际应用中，以上2条规定并没有这么严格。引用别人文章的例子：比如，新闻站点的头版不断更新。虽然第二次请求会返回不同的一批新闻，该操作仍然被认为是安全的和幂等的，因为它总是返回当前的新闻。从根本上说，如果目标是当用户打开一个链接时，他可以确信从自身的角度来看没有改变资源即可。
　　2.根据HTTP规范，POST表示可能修改变服务器上的资源的请求。继续引用上面的例子：还是新闻以网站为例，读者对新闻发表自己的评论应该通过POST实现，因为在评论提交后站点的资源已经不同了，或者说资源被修改了。
　　上面大概说了一下HTTP规范中GET和POST的一些原理性的问题。但在实际的做的时候，很多人却没有按照HTTP规范去做，导致这个问题的原因有很多，比如说：
　　1.很多人贪方便，更新资源时用了GET，因为用POST必须要到FORM（表单），这样会麻烦一点。
　　2.对资源的增，删，改，查操作，其实都可以通过GET/POST完成，不需要用到PUT和DELETE。
　　3.另外一个是，早期的Web MVC框架设计者们并没有有意识地将URL当作抽象的资源来看待和设计，所以导致一个比较严重的问题是传统的Web MVC框架基本上都只支持GET和POST两种HTTP方法，而不支持PUT和DELETE方法。
&　　* 简单解释一下MVC：MVC本来是存在于Desktop程序中的，M是指数据模型，V是指用户界面，C则是控制器。使用MVC的目的是将M和V的实现代码分离，从而使同一个程序可以使用不同的表现形式。
　　以上3点典型地描述了老一套的风格（没有严格遵守HTTP规范），随着架构的发展，现在出现REST(Representational State Transfer)，一套支持HTTP规范的新风格，这里不多说了，可以参考《RESTful Web Services》。
　　说完原理性的问题，我们再从表面现像上面看看GET和POST的区别：
　　1.GET请求的数据会附在URL之后（就是把数据放置在HTTP协议头中），以?分割URL和传输数据，参数之间以&相连，如：login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0%E5%A5%BD。如果数据是英文字母/数字，原样发送，如果是空格，转换为+，如果是中文/其他字符，则直接把字符串用BASE64加密，得出如：%E4%BD%A0%E5%A5%BD，其中％XX中的XX为该符号以16进制表示的ASCII。
　　POST把提交的数据则放置在是HTTP包的包体中。
　　2."GET方式提交的数据最多只能是1024字节，理论上POST没有限制，可传较大量的数据，IIS4中最大为80KB，IIS5中为100KB"？？！
　　以上这句是我从其他文章转过来的，其实这样说是错误的，不准确的：
　　(1).首先是"GET方式提交的数据最多只能是1024字节"，因为GET是通过URL提交数据，那么GET可提交的数据量就跟URL的长度有直接关系了。而实际上，URL不存在参数上限的问题，HTTP协议规范没有对URL长度进行限制。这个限制是特定的浏览器及服务器对它的限制。IE对URL长度的限制是2083字节(2K+35)。对于其他浏览器，如Netscape、FireFox等，理论上没有长度限制，其限制取决于操作系统的支持。
　　注意这是限制是整个URL长度，而不仅仅是你的参数值数据长度。[见参考资料5]
　　(2).理论上讲，POST是没有大小限制的，HTTP协议规范也没有进行大小限制，说&POST数据量存在80K/100K的大小限制&是不准确的，POST数据是没有限制的，起限制作用的是服务器的处理程序的处理能力。
　　对于ASP程序，Request对象处理每个表单域时存在100K的数据长度限制。但如果使用Request.BinaryRead则没有这个限制。
　　由这个延伸出去，对于IIS 6.0，微软出于安全考虑，加大了限制。我们还需要注意：
　　　　 1).IIS 6.0默认ASP POST数据量最大为200KB，每个表单域限制是100KB。　　　　 2).IIS 6.0默认上传文件的最大大小是4MB。　　　　 3).IIS 6.0默认最大请求头是16KB。　　IIS 6.0之前没有这些限制。[见参考资料5]
　　所以上面的80K，100K可能只是默认值而已(注：关于IIS4和IIS5的参数，我还没有确认)，但肯定是可以自己设置的。由于每个版本的IIS对这些参数的默认值都不一样，具体请参考相关的IIS配置文档。
　　3.在ASP中，服务端获取GET请求参数用Request.QueryString，获取POST请求参数用Request.Form。在JSP中，用request.getParameter(\"XXXX\")来获取，虽然jsp中也有request.getQueryString()方法，但使用起来比较麻烦，比如：传一个test.jsp?name=hyddd&password=hyddd，用request.getQueryString()得到的是：name=hyddd&password=hyddd。在PHP中，可以用$_GET和$_POST分别获取GET和POST中的数据，而$_REQUEST则可以获取GET和POST两种请求中的数据。值得注意的是，JSP中使用request和PHP中使用$_REQUEST都会有隐患，这个下次再写个文章总结。
　　4.POST的安全性要比GET的安全性高。注意：这里所说的安全性和上面GET提到的&安全&不是同个概念。上面&安全&的含义仅仅是不作数据修改，而这里安全的含义是真正的Security的含义，比如：通过GET提交数据，用户名和密码将明文出现在URL上，因为(1)登录页面有可能被浏览器缓存，(2)其他人查看浏览器的历史纪录，那么别人就可以拿到你的账号和密码了，除此之外，使用GET提交数据还可能会造成Cross-site request forgery攻击。
　　总结一下，Get是向服务器发索取数据的一种请求，而Post是向服务器提交数据的一种请求，在FORM（表单）中，Method默认为"GET"，实质上，GET和POST只是发送机制不同，并不是一个取一个发！
　　纯属hyddd个人总结，如有错漏请指出。:&
参考资料：
[1]./liuzd003/blog/item/7bfecbfa6ea94ed8b58f318c.html
[2].http://www.blogjava.net/onlykeke/archive//65285.aspx
[3]./view/2067025.htm
[4]./article.asp?id=373
[5].http://blog.csdn.net/somat/archive//158707.aspx
转载请说明出处，谢谢[hyddd(/hyddd/)]每个 Web 开发者都应该知道的关于 URL 编码的知识 - 技术翻译 - 开源中国社区
当前访客身份：游客 [
已有文章 2430 篇
当前位置：
每个 Web 开发者都应该知道的关于 URL 编码的知识
英文原文：
0人收藏此文章,
推荐于 3年前 (共 21 段, 翻译完成于 06-25) ()
参与翻译(7人)：
, , , , , ,
本文首先阐述了人们关于统一资源定位符（URL）编码的普遍的误读，其后通过阐明场景下的 来引出我们经常遇到的问题及其解决方案。本文并不特定于某类编程语言，我们在环境下阐释问题，最后从Web应用的多个层次描述如何解决URL编码的问题来结尾。
当我们每天上网冲浪时，有一些技术我们无时无刻不在面对。有数据本身（网页），数据的格式化，能够让我们获取数据的传输机制，以及让Web网络能够真正成为Web的基础及根本：从一页到另一页的链接。这些链接都是URL。
&翻译的不错哦!
通用URL语法
我敢说每个人在其一生中至少见过一次URL。比如""，就是一个URL。一个URL是一个统一资源定位器&，事实上它指向了一个网页(大多数情况下)。实际上，自从1994年的开始，URL就有了一个良好定义的结构。
我们能从"" 这个URL中读出下列详细信息:
Host address
如果我们看一个更复杂的URL，比如 "https://bob:bobby@:8080/p=1?q=2#third" 我们就能获取到下列信息:
Host address
Path parameters
Query parameters
协议&(即scheme，如上面的http和https (安全HTTP)) 定义了URL中其余部分的结构。大多数互联网&拥有通用的开头，包括用户，密码，主机名和端口，后面才是每个协议具体的部分。这个通用的部分负责处理认证，同时它也有能力知道为了请求数据应该链接到哪儿。
&翻译的不错哦!
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参数 (也叫 )，这是在path片段的最后由";"开始的一些字符。每个参数名和值由"="字符分隔，像这样："/p=1"，这定义了path片段 "file"有一个 path参数 "p"，其值为"1"。这些参数并不常用 — 这得清楚 — 但是它们确实是存在，而且从
我们能找到很好的理由去使用它们：
Matrix参数可以让程序在GET请求中可以获取部分的数据集。参考。因为matrix参数可以跟任何数据集的URI格式的path片段，它们可以在内部的path片段中被使用。
&翻译的不错哦!
在 路径(path)部分之后是 查询 (query)部分，它和 路径 之间由一个“?”隔开， 查询部分包含了一个由“&”分隔开的参数列表，每一个参数由参数名称、“=”号以及参数值组成。比如"/file?q=2"定义了一个 查询参数&"q" ，它的值是"2"。这在提交 时，或者当你使用诸如Google搜索等应用时， 用的非常多。
一个HTTP URL的最后部分是一个段落(fragment)部分，用来指向HTML文件中具体的某个部分，而不是整个HTML页面。比如说，当你点击链接时浏览器自动滚屏到某个部分而不是从页面最顶部开始展示，就说明你点击了一个拥有段落部分的URL。
&翻译的不错哦!
http URL 方案最初由
定义（实际上，在之前的 也有涉及），而在 http URL 方案被重新定义之前，整个 URL 语法就已经由了 以适应发展的进化为一套 统一资源标识符（Uniform Resource Identifiers 即 URIs)。
对于 URLs 如何拼装，各部分如何分隔有一套语法。例如："://"分隔方案和主机部分。主机同路径片段部分由"/"分隔，而查询部分紧跟在"?"之后。这意味着有些字符为语法保留。有些为整个URIs保留，而有些则被特定方案保留。所有出现在不应出现位置的 保留符（例如路径片段——以文件名为例——可能包含"?"）必须被URL 编码。
&翻译的不错哦!
URL 编码将字符转变成对 URL 解析无意义的无害形式。它将字符转化成为一种特定的字节序列，然后将字节转换为16进制形式，并将其前面加上"%"。问号的 URL 编码形式为"%3F"。
我们可以将指向 "to_be_or_not_to_be?.jpg"图片的 URL 写成："/to_be_or_not_to_be%3F.jpg"，这样就没有人会认为这儿可能由一个查询部分了。
现今多数浏览器显示 URLs 前都会对其解码（将百分号编码字节转回其原本字符），并在获取其网络资源的时候重新编码。这样一来，很多用户从未意识到编码的存在。
另一方面，网页作者，开发者必须明确认识到这一点，因为这里存在着很多陷阱。
&翻译的不错哦!
URL常见陷阱
如果你正和URL打交道，了解下能够避免的常见陷阱绝对是值得的。现在我们给大家介绍下不仅限于此的一些常见陷阱。
使用哪类字符编码?
URL编码规范并没有定义使用何种字符编码形式去编码字节。一般的字母数字字符并不需要转义，但是ASCII之外的保留字需要(例如法语单词“noeud”中的"oe")。我们必须提出疑问，应该使用哪类字符编码来编码URL字节。
当然如果只有的话，这个世界就会清净很多。因为每个字符都包含其中，但是它只是一个集合，或者说是列表如果你愿意，它本身并不是一中编码。Unicode可以使用多种方式进行编码，譬如或者（也有其它格式），但是问题并没有解决：我们应该使用哪类字符来编码URL（通常也指URI）。
标准并没有定义一个URI应该以何种方式指定其编码，所以其必须从环境信息中进行推导。对于HTTP URL，它可以是HTML页面的编码格式，或HTTP头的。这通常会让人迷惑，也是许多错误的根源。事实上， 定义了新的URI scheme将采用UTF-8，host（甚至已有的scheme）也使用UTF-8，这让我更加怀疑：难道host和path真的可以使用不同的编码方式？
&翻译的不错哦!
每一部分的保留字都是不同。
是的，他们是，是的，他们，是的，他们是。。。
对于一个httpd连接，路径片段部分中的空格被编码为"%20"（不，完全没有"+"）,而“+”字符在路径片段部分可以保持不编码。
现在，在查询部分，一个空格可能会被编码为“+”（为了向后兼容：不要试图在URI标准去搜索他）或者“%20”，当作为“+”字符（作为个统配符的结果）会被编译为“%2B”。
这意味着“blue+light blue”字串，如果在路径部分或者查询部分，将会有不同的编码。比如得到"/blue+light%20blue?blue%2Blight+blue"这样的编码形式，这样我们不需从语法上分析url结构，就可以推导这个url的整个结构是可能
&翻译的不错哦!
考虑如下组装URL的Java代码片段
String str = "blue+light blue";
String url = "/" + str + "?" +
编码URL并不是为了转义保留字而进行的简单字符迭代，我们需要确切的知道哪个URL部份有哪些保留字，而有针对性的进行编码。
这也意味着URL重写过滤器如果不考虑合适的编码细节而对URL直接进行分段转换通常是有问题的。对URL进行编码而不考虑具体的分段规则是不切实际的。
&翻译的不错哦!
保留字不是你想象的那样
大多数人不知道"+"在路径部分是被允许的并且特指正号而不是空格。其他类似的有：
"?"在查询部分允许不被转义，
"/"在查询部分允许不被转义，
"="在作为路径参数或者查询参数值以及在路径部分允许不被转义，
":@-._~!$&'()*+,;="等字符在路径部分允许不被转义，
"/?:@-._~!$&'()*+,;="等字符在任何段中允许不被转义。
& 这样下面的地址虽然看起来有点混乱:""
按照上面的规则，其实上是一个合法的地址。
不用奇怪，上面路径可以被解析为：
/:@-._~!$&'()*+,=
路径参数名
:@-._~!$&'()*+,
路径参数值
:@-._~!$&'()*+,==
查询参数名
/?:@-._~!$'()* ,;
查询参数值
/?:@-._~!$'()* ,;==
/?:@-._~!$&'()*+,;=
&翻译的不错哦!
不能分析解码后的URL
URL的语法只在它被解码前是有意义的，一旦解码就可能出现保留字。
例如"/blue%2Fred%3Fand+green" 在解码前由如下部分组成:
Path segment
blue%2Fred%3Fand+green
Decoded Path segment
blue/red?and+green
这样看来, 我们是在请求一个名为"blue/red?and+green"的文件，而不是一个位于"blue"文件夹下的名为"red?and+green"的文件。
如果我们把它解码为"/blue/red?and+green"，我们将得到如下部分:
Path segment
Path segment
Query parameter name
这明显是错误的，所以，对保留字和URL各部分的分析必须在URL解码之前完成。这意味着URL重写过滤器不应当在尝试匹配之前解码URL，当且仅当保留字允许进行URL编码时才可以(有时符合这种情形，有时不符合，这取决于你的应用)。
&翻译的不错哦!
解码后的URL不能被再编码为同样的形式
如果你解码"/blue%2Fred%3Fand+green" 为"/blue/red?and+green"，然后对它进行编码(哪怕使用一个对URL每一部分都很了解的编码器)，你将会得到"/blue/red?and+green"，这是因为它已经是一个有效的URL。它跟我们解码之前的URL非常的不同。
用Java正确处理URL
当你觉得自己已经拿到了URL的黑腰带(柔道中的最高级别--译者注)，你将会发现仍有一些Java里特有的、URL相关的陷阱。如果没有一个强大的心脏，你很难正确的处理URL。
&翻译的不错哦!
不要用java.net.URLEncoder或者java.net.URLDecoder来处理整个URL
不开玩笑。这些类不是用来编码或解码URL的，API文档中:
Utility class for HTML form encoding. This class contains static methods for converting a String to theapplication/x-www-form-urlencodedMIME format. For more information about HTML form encoding, consult the HTML specification.
这不是给URL用的。充其量它类似于查询&部分的编码方式。使用它来编码或解码整个URL是错误的。你肯定以为标准的JDK一定会有一个标准的类来正确的处理URL编码(是这样，只不过是各部分分开处理的)，但是要么是压根没有，要么是我们还没有发现。不过，这种臆测导致许多人错用了URLEncoder。
&翻译的不错哦!
在对每一部分编码之前不要拼装URL
正如我们已经讲过的:完整构建后的URL不能再被编码。
以下面的代码为例:
String pathSegment = "a/b?c";
String url = "/" + pathS
如果"a/b?c" 是一个路径片段，那么不可能把"/a/b?c" 转换回之前它的原样，因为它碰巧是一个有效的URL。之前我们已经解释过这一点。
下面是正确的代码:
String pathSegment = "a/b?c";
String url = "/"
+ URLUtils.encodePathSegment(pathSegment);
这里我们使用了一个工具类URLUtils，它是我们自己开发的，因为网络上找不到一个详尽的足够快的工具类。上面的代码会带给你正确编码的URL "/a%2Fb%3Fc"。
注意，同样的方式也适用于查询子串:
String value = "a&b==c";
String url = "/?query=" +
这会给你"/?query=a&b==c"，这是个有效的URL，而不是我们想得到的"/?query=a%26b==c"。
&翻译的不错哦!
给你结构化的数据
因为一旦一个URL被解码，句法信息就会丢失，下面这样的代码就是错误的：
URI uri = new URI("/a%2Fb%3Fc");
for(String pathSegment : uri.getPath().split("/"))
System.err.println(pathSegment);
它会先将路径 "a%2Fb%3Fc"解码为 "a/b?c",然后在不应该分割的地方将地址分割为地址片段。
正确的代码使用的是
URI uri = new URI("/a%2Fb%3Fc");
for(String pathSegment : uri.getRawPath().split("/"))
System.err.println(URLUtils.decodePathSegment(pathSegment));
注意路径参数仍然存在：如果需要的话再处理它们。
&翻译的不错哦!
不要期望 Apache Commons HTTPClient的URI类能够正确的做对
类使用了的URLCodec来做 URL编码, 正如
它是有问题的，因为它犯了和使用java.net.URLEncoder同样的错误。它不但使用了错误的编码器，还错误的 进行解码。
在web应用的每一层修复URL编码问题
近来我们已经被动修复了许多应用中的URL编码问题。从在Java中支持它，到低层次的URL重写。这里我们会列出一些必要的修改。
总是在创建的时候进行URL编码
在我们的 HTML文件中，我们将所有出现：
var url = "#{vl:encodeURL(contextPath + '/view/' + resource.name)}";
的地方替换为：
var url = "#{contextPath}/view/#{vl:encodeURLPathSegment(resource.name)}";
查询参数也是类似的。
&翻译的不错哦!
确保你的URL-rewrite过滤器正确的处理网址
Url 重写过滤器是一个重写过滤器，我们在seam中用于转化漂亮的地址去应用依赖的网址。
例如，我们用它把h转化为。
很明显，这个过程包含了一些字符串从一个地址到另一个地址，这意味着我们要从路径部分解码并且把它重新编码为另一个查询值部分。
我们起初的规则，如下所示：
&urlrewrite decode-using="utf-8"&
&from&^/view/resource/(.*)/(.*)$&/from&
&to encode="false"&/resources/details.seam?owner=$1&name=$2&/to&
&/urlrewrite&
从这我们可以看到在重写过滤器中只有两种方法处理网址重写：每一个的网址先被解码去做规则匹配（&to&模式），或者它不可用，所有规则去处理解码。在我们看来后者是比较好的选择，特别是当你要移动网址部分周围，或者想去包含URL解码路径分隔符的匹配路径部分时候。
&翻译的不错哦!
在替换模式中（&to&模式）你可以使用内建的函数escape（String）和unescape（String）处理网站转码和解码。
在撰写这个文章的时候，Url Rewrite Filter Beta 3.2有一些bugs，限制住我们提高URL-correctness：
网址解码使用java.net.URLDecoder（这是错误的），
escape(String)和unescape(String)内建函数使用java.net.URLDecoder和java.net.URLEncoder（不够强大，只能用于这个查询字串，所有的"&"或者"="不被转码）。
We therefore made a
fixing a few issues like URL decoding, and adding the inline functionsescapePathSegment(String)andunescapePathSegment(String).
我们因此做了一个大修正补丁，用于修正诸如网址解码问题以及增加内建函建escapePathSegment(String) 和 unescapePathSegment(String)
&翻译的不错哦!
我们现在可以这样写，几乎不会有错误
&urlrewrite decode-using="null"&
&from&^/view/resource/(.*)/(.*)$&/from&
&-- Line breaks inserted for readability --&
&to encode="false"&/resources/details.seam
?owner=${escape:${unescapePath:$1}}
&name=${escape:${unescapePath:$2}}&/to&
&/urlrewrite&
唯一可能出问题的地方是由于我们的补丁还不能解决以下的问题：
内建的escaping/unescaping函数应能只能编码，这已经做为下一个补丁（已经做完了），或者能从http请求来确定（还不支持），
oldescape(String)和unescape(String)内建函数被保留了，并且仍然调用java.net.URLDecoder，而这个包在由于没有解决"&"和"="的问题，所以仍然有问题，
我需要增加更多的局部特定的编码和解码函数，
我们需要增加一个方法去鉴别per-rule解码行为，对照全局在&urlrewrite&。
我们一有时间，我们就会发布第二个补丁。
&翻译的不错哦!
正确使用Apache mod-rewrite
& Apache mod-rewrite是一个Apache Web服务器的网址重写模块。例如用它来把 &
的流量代理到。
这是最后的要修正的事情，就像是Url Rewrite Filter，他默认解码网址给我们，并且从新编码重写过得网址给我们，这其实上是错误的，因为"解码的网址不能被重新编码"。
有一种方法可以避免这种行为，至少在我们的案例中我们没有转化一个网址部分到另一个网址，例如，我们不需要解码一个路径部分并且重新编码它到一个查询部分：没有加码也没有重编码。
我们通过THE_REQUEST来网址匹配来完成工作。他是完全的HTTP请求（包括HTTP方法和版本）联合解码。我们只要取host后面的URL部分，改变host和预设的/v/前缀和tada
# This is required if we want to allow URL-encoded slashes a path segment
AllowEncodedSlashes On
# Enable mod-rewrite
RewriteEngine on
# Use THE_REQUEST to not decode the URL, since we are not moving
# any URI part to another part so we do not need to decode/reencode
RewriteCond %{THE_REQUEST} "^[a-zA-Z]+ /(.*) HTTP/\d\.\d$" RewriteRule ^(.*)$ http://our-internal-server:8080/vl/%1 [P,L,NE]
&翻译的不错哦!
我希望阐明一些URL技巧和常见的错误。简而言之，能把它说明白就够了，但这不是一些人想象的那样简单的。我们展示了java常见的错误和一个web 应用部署的整个过程。现在每个读者都应该是一个URL专家了，并且我们希望不要在看见相关bugs再出现。请求SUN公司，请为URL encoding/decoding逐项的增加标准支持
&翻译的不错哦!java最简单的方式实现httpget和httppost请求 - 推酷
java最简单的方式实现httpget和httppost请求
java实现httpget和httppost请求的方式多种多样，个人总结了一种最简单的方式，只需几行代码，就可以完美的实现。
此处需要用到两个jar包，httpclient-4.3.1.jar、httpcore-4.3.jar，各位可以到网上自己下载，或者到我的附件里下载，下面先贴上httpget请求的代码：
HttpResponse response = HttpClients.createDefault().execute(request);
if(response.getStatusLine().getStatusCode()==200){
result = EntityUtils.toString(response.getEntity());
这种方式之所以简单，就是因为jar包已经为我们封装好了一些基础的东西，事半功倍。
另外，推荐一个免费的智能聊天的api——
，可以非常智能的回答各种问题，比如“你好——你也好，你妹的——我有几个妹妹，你想要哪个”，感觉还挺有意思的，这个api就是通过httpget请求的方式调用的，感兴趣的可以去试一下。
稍后贴出httppost请求的代码。
已发表评论数()
请填写推刊名
描述不能大于100个字符!
权限设置： 公开
仅自己可见
正文不准确
标题不准确
排版有问题
主题不准确
没有分页内容
图片无法显示
视频无法显示
与原文不一致