7298人阅读
java（21）

request.getRequestURI() /jqueryWeb/resources/request.jsp
request.getRequestURL() http://localhost:8080/jqueryWeb/resources/request.jsp
request.getContextPath()/jqueryWeb
request.getServletPath()/resources/request.jsp
注： resources为WebContext下的目录名
jqueryWeb 为工程名
-----------------------------------------------------
&%=request.getRequestURI() %&&br/&
& %=request.getRequestURL() %&&br/&
& %=request.getContextPath()%&&br/&
& %=request.getServletPath() %&&br/&
& %=request.getPathInfo() %&&br/&
/test-struts.jsp
http://127.0.0.1:8080/test-struts.jsp
/test-struts.jsp
&action name=&test& class=&testStrutsAction& method=&test&&&
&&&&result&/test-struts.jsp&/result&
& /action&
假定你的web application
名称为news,你在浏览器中输入请求路径：
http://localhost:8080/news/main/list.jsp
则执行下面向行代码后打印出如下结果：
1、 System.out.println(request.getContextPath());
打印结果：/news
2、System.out.println(request.getServletPath());
打印结果：/main/list.JSP
&3、 System.out.println(request.getRequestURI());
打印结果：/news/main/list.JSp
&4、 System.out.println(request.getRealPath(&/&));
打印结果：F:\tomcat 6.0\webapps\news\test
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：181364次
积分：2156
积分：2156
排名：第17138名
原创：37篇
转载：56篇
评论：11条
(1)(1)(1)(17)(1)(10)(6)(2)(4)(5)(10)(3)(8)(3)(1)(1)(8)(9)(2)(1)难经2：URL.getFile()，是你让老虎落入陷阱？ - liuu - ITeye博客
博客分类：
由于开发需要，编写了一个简单的单元测试框架，在基类中从类路径加载资源，并执行初始化动作（类似Spring测试基类），利用ClassLoader，加载资源自是驾轻就熟。我自己通过继承这个测试基类，编写了不少测试类，感觉还算方便，也没有出过什么问题。不过，近日其他同事Z在用这个测试基类时，却经常出现加载不到资源的问题，很奇怪。
既然是加载不到资源，还是第一反应，肯定是资源路径有问题，可是我的环境下并没有报这个错啊，看看Z同事的测试类，要加载的资源文件明明就在那，类路径指定也没有问题啊；扫了一眼，看见资源文件的命名是中文的，不过我并没有在意，因为我用中文测过，没有问题。
不是中文问题，那可能是其他什么原因呢？苦思不得其解，回到自己的机器上，调试了一下程序，本机运行依然没有问题，重新审查加载资源的方法实现，用的ClassLoader定位取得URL，再用URL.getFile()取得实际路径，最后new File()读取文件，没什么问题啊？
要真有问题，难道是URL.getFile()不正确？想到这一点，再想想Z君的开发环境，他是在Java5下开发，而我还是坚守者1.4.2阵地，难道？难道Java5下会有问题？我飞快的抓起鼠标，把编译环境改为Tiger，运行，出错！Java5下确实找不到资源！断点调试发现，在Java5下，URL.getFile()返回的资源位置是未解码的，空格和中文成了URL转码格式。URL.getFile()，真的是你让Tiger老虎落入陷阱么？
为了确认问题，我单独建了一个测试项目，写了一个测试类，分别在Java1.4.2、Java5、Java6下运行， 结果确实让我惊讶：
public class URLTest {
public static void main(String[] args) {
URL url1 = URLTest.class.getResource("te st.txt");
URL url2 = URLTest.class.getResource("中文.txt");
System.out.println("te st.txt =& " + url1.getFile() + ", exist =& " + new File(url1.getFile()).exists());
System.out.println("中文.txt =& " + url2.getFile() + ", exist =& " + new File(url2.getFile()).exists());
其中“te st.txt”和"中文.txt"是和测试类放在一起的测试文件。
Java1.4.2下输出：
te st.txt =& /E:/CODE/Test/bin/url/te st.txt, exist =& true
中文.txt =& /E:/CODE/Test/bin/url/中文.txt, exist =& true
Java5和Java6均输出：
te st.txt =& /E:/CODE/Test/bin/url/te%20st.txt, exist =& false
中文.txt =& /E:/CODE/Test/bin/url/%e4%b8%ad%e6%96%87.txt, exist =& false
看来，原来URL.getFile()是在1.4.2下能自动解码的，到了老虎和野马那里却不灵了，从而导致找不到资源文件。找到了问题，我长舒了一口气。
既然问题已经找到，答案呼之欲出，不过，为什么Java5以后要修改URL的行为，不再自动解码呢？我还是有些疑惑。
接下来，我一不做二不休，不就是类路径么，我再改，把编译路径从“bin”改成“bin all”，中间加空格，再次运行。。。。。。
Java1.4.2下输出：
te st.txt =& /E:/CODE/Test/bin%20all/url/te st.txt, exist =& false
中文.txt =& /E:/CODE/Test/bin%20all/url/中文.txt, exist =& false
Java5和Java6均输出：
te st.txt =& /E:/CODE/Test/bin%20all/url/te%20st.txt, exist =& false
中文.txt =& /E:/CODE/Test/bin%20all/url/%e4%b8%ad%e6%96%87.txt, exist =& false
哈哈，Java1.4.2的URL终于露馅了，原来它的解码是不完全的！原来URL.getFile()本身就是陷阱啊！即使是在1.4.2下，它也只是给我们一个迷惑的假相。
回头想想，为什么Sun要冒着版本不兼容的危险，也要修改URL的行为呢？这或许就是其深层次的原因。
搞清楚了问题的症结，按方抓药即可。URLDecoder正是用来干这个活的，同时祭出Google，看看同志们是不是早就搞定这个问题了，放眼望去，URL.getFile()搜出来的结果还真不少啊，连带上URL.getPath()也受到牵连，而且URL.getFile()和URL.getPath()得到的路径还可能不一致！又是一个陷阱啊。
终解，用URLDecoder：
System.out.println("te st.txt =decode=& " + URLDecoder.decode(url1.getFile(), "UTF-8"));
System.out.println("中文.txt =decode=& " + URLDecoder.decode(url2.getFile(), "UTF-8"));
另外，URI也是可以自动解码的：
System.out.println("te st.txt =uri=& " + new URI(url1.getFile()).getPath());
System.out.println("te st.txt =uri=& " + new URI(url2.getFile()).getPath());
在Java5和Java6下运行，二者皆输出正常：
te st.txt =& /E:/CODE/Test/bin%20all/url/te%20st.txt, exist =& false
中文.txt =& /E:/CODE/Test/bin%20all/url/%e4%b8%ad%e6%96%87.txt, exist =& false
te st.txt =decode=& /E:/CODE/Test/bin all/url/te st.txt
中文.txt =decode=& /E:/CODE/Test/bin all/url/中文.txt
te st.txt =uri=& /E:/CODE/Test/bin all/url/te st.txt
te st.txt =uri=& /E:/CODE/Test/bin all/url/中文.txt
不过，1.4.2下，URI又可能是一个陷阱：
te st.txt =& /E:/CODE/Test/bin/url/te st.txt, exist =& true
中文.txt =& /E:/CODE/Test/bin/url/中文.txt, exist =& true
te st.txt =decode=& /E:/CODE/Test/bin/url/te st.txt
中文.txt =decode=& /E:/CODE/Test/bin/url/中文.txt
java.net.URISyntaxException: Illegal character in path at index 24: /E:/CODE/Test/bin/url/te st.txt
at java.net.URI$Parser.fail(URI.java:2752)
at java.net.URI$Parser.checkChars(URI.java:2925)
at java.net.URI$Parser.parseHierarchical(URI.java:3009)
at java.net.URI$Parser.parse(URI.java:2967)
at java.net.URI.&init&(URI.java:574)
at url.URLTest.main(URLTest.java:24)
Exception in thread "main"
URI对于不完整解码的路径，会抛语法异常。
看来，还是Decoder.decode()是最终正解啊，用URI的同学要小心了，请保证你的应用跑在Java5上。
另，看到JavaEye里有兄弟自己替换"%20"为空格，来解决临时这个问题，这样很不好吧，有中文怎么办？
浏览: 119693 次
来自: 北京
不过想要在@Transactional(&accou ...
嗯嗯，感谢LZ，成功解决问题
偶尔浏览到这个帖子，觉得其实可以这样处理的：public in ...
非常感谢，终于解决啦
太牛了，膜拜2016年1月 Java大版内专家分月排行榜第一2015年12月 Java大版内专家分月排行榜第一2015年9月 Java大版内专家分月排行榜第一2015年8月 Java大版内专家分月排行榜第一
2016年3月 Java大版内专家分月排行榜第二2016年2月 Java大版内专家分月排行榜第二2015年11月 Java大版内专家分月排行榜第二2015年10月 Java大版内专家分月排行榜第二
匿名用户不能发表回复！|
每天回帖即可获得10分可用分！小技巧：
你还可以输入10000个字符
(Ctrl+Enter)
请遵守CSDN，不得违反国家法律法规。
转载文章请注明出自“CSDN（www.csdn.net）”。如是商业用途请联系原作者。