java中获取资源

 　　在开发java程序的过程中，我们经常要做的一件事就是获取资源。那么什么是资源呢？说白了，在计算机里那就是一堆数据。只是这堆数据对我们的java程序有多种表现形式，一般来说有File，URL，InputStream等等。而单就文件这一项就有很多种：配置文件，java类文件，jps文件，图片、css、js文件等等。面对这林林总总的资源，我们在设计一个读取资源的接口时，就需要针对不同形式的资源提供方法，这样就导致我们的接口还是与实际的资源形式绑定在一起，未能完全的抽象。另外，在java程序中资源的存放位置也是各异的。有的存放在classpath中，有的存放在文件系统中，有的存放在web应用中。而对于不同位置的资源，java程序获取这些资源的方法各有不同。

    A、获取classpath中的资源：

 URL url = this.getClass().getResource("resource_name");

    URL url = this.getClass().getClassLoader().getResource("resource_name");

    URL url = Thread.currentThread().getContextClassLoader().getResource("resource_name");

    那么在jdk中为什么又提供了三种方式来获取classpath下的资源呢？这其中是有些来头的。

    第一行代码中是利用Class类的实例来获取，第二行代码是使用加载当前类的classloader来获取。看下jdk中的源代码会发现class类的实例最后还是委托加载他的classloader来获取资源的。

    public java.net.URL getResource(String name) {

    name = resolveName(name);

    ClassLoader cl = getClassLoader0();

    if (cl==null) {

    // A system class.

    return ClassLoader.getSystemResource(name);

    }

    return cl.getResource(name);

    }

　　从上面的代码中可以看出，对于资源的加载并没有像类加载所采用的双亲委托机制。而是当前类的classloader不为null的情况下先从当前类的classloader中加载资源。而只有当前类的classloader为null的时候才从system classloader中去加载资源。这样可以方便我们自定义配置类覆盖一些默认配置。当然，j2se应用中如果没有特别定制classloader时，我们自己写的类都是被system classloader加载的。到底利用class去获取资源和利用classloader去获取资源有什么区别呢？区别就在 resolveName(name)这个方法中。两种方式对于资源名称的表示方式不同。下面是一个简单的包结构，/表示类路径的根

    /

    |-com.cn.test

    |-Test.class

    |-test2.txt

    |-test1.txt

    Java代码

    // 获取与当前类在同一个包下的资源

  URL url1 = this.getClass().getResource("test2.txt");

    // 获取com.cn.test包下的资源,需加/

    URL url2 = this.getClass().getResource("/com/cn/test/test2.txt");

    // 获取类路径根下的资源

URL url3 = this.getClass().getClassLoader().getResource("test1.txt");

    // 获取包com.cn.test包下的资源

   URL url4 = this.getClass().getResource("com/cn/test/test2.txt");

   　　装载类的过程非常简单：查找类所在位置，并将找到的Java类的字节码装入内存，生成对应的Class对象。Java的类装载器专门用来实现这样的过程，JVM并不止有一个类装载器，事实上，如果你愿意的话，你可以让JVM拥有无数个类装载器，当然这除了测试JVM外，我想不出还有其他的用途。你应该已经发现到了这样一个问题，类装载器自身也是一个类，它也需要被装载到内存中来，那么这些类装载器由谁来装载呢，总得有个根吧？没错，确实存在这样的根，它就是神龙见首不见尾的Bootstrap ClassLoader. 为什么说它神龙见首不见尾呢，因为你根本无法在Java代码中抓住哪怕是它的一点点的尾巴，尽管你能时时刻刻体会到它的存在，因为java的运行环境所需要的所有类库，都由它来装载，而它本身是C++写的程序，可以独立运行,可以说是JVM的运行起点,伟大吧。在Bootstrap完成它的任务后，会生成一个AppClassLoader(实际上之前系统还会使用扩展类装载器ExtClassLoader，它用于装载Java运行环境扩展包中的类),这个类装载器才是我们经常使用的，可以调用ClassLoader.getSystemClassLoader() 来获得，我们假定程序中没有使用类装载器相关操作设定或者自定义新的类装载器，那么我们编写的所有java类通通会由它来装载，值得尊敬吧。AppClassLoader查找类的区域就是耳熟能详的Classpath，也是初学者必须跨过的门槛，有没有灵光一闪的感觉，我们按照它的类查找范围给它取名为类路径类装载器。还是先前假定的情况，当Java中出现新的类，AppClassLoader首先在类传递给它的父类类装载器，也就是Extion ClassLoader，询问它是否能够装载该类，如果能，那AppClassLoader就不干这活了，同样Extion ClassLoader在装载时，也会先问问它的父类装载器。我们可以看出类装载器实际上是一个树状的结构图，每个类装载器有自己的父亲，类装载器在装载类时，总是先让自己的父类装载器装载(多么尊敬长辈),如果父类装载器无法装载该类时，自己就会动手装载，如果它也装载不了，那么对不起，它会大喊一声：Exception，class not found。有必要提一句，当由直接使用类路径装载器装载类失败抛出的是NoClassDefFoundException异常。如果使用自定义的类装载器loadClass方法或者ClassLoader的findSystemClass方法装载类，如果你不去刻意改变，那么抛出的是ClassNotFoundException。

　　如果一个类是通过bootstrap 载入的，那我们通过这个类去获得classloader的话，有些jdk的实现是会返回一个null的，比如说我用 new Object().getClass().getClassLoader()的话，会返回一个null，这样的话上面的代码就会出现NullPointer异常．所以保险起见我们最好还是使用我们自己写的类来获取classloader（"this.getClass().getClassLoader()“），这样一来就不会有问题。

    B、获取文件系统中的资源

    Java代码

    // 1、获得File对象

  File file = new File("test.txt");

    // 2、获得File对象的字节流

    InputStream in = new FileInputStream(file);

    值得注意的是在File的构造函数File(String name) 中的name参数可以是相对路径和绝对路径。相对路径是相对于System.getProperties("user.dir")的。

    C、获取web应用中的资源

servletContext.getResourceAsStream(resource_name);

    resource_names为相对于webroot的路径表示。例如获取web.xml，resource_name表示为"/WEB-INF/web.xml"

    面对上面介绍的各种资源表现形式和存放位置，难道java中就没有提供一个统一处理方式吗？有，java.net.URL。

    从名称上来看 URL(Uniform Resource Locator) 统一资源定位器。看起来很好很强大。但很多时候使用它并不能定位到我们需要的资源。

    首先，它jdk中体统的URL能访问的协议非常有限（当然可以进行扩展，不过很麻烦）；常用的有http,file,ftp等等。并没有提供对classpath和servletContext中的资源的获取方法。

    另外，它没有提供判断资源是否存在的方法。每次只有等我们真正去获取资源的时候抛出异常才能知道资源无法获取。

    其次，URL这个类的职责未划分清楚，既用来表示资源有用来获取其资源。

 

　　在jsp和class文件中调用的相对路径不同。在jsp里，根目录是WebRoot 在class文件中，根目录是WebRoot/WEB-INF/classes 当然你也可以用System.getProperty("user.dir")获取你工程的尽对路径。
1.jsp中取得路径:
以工程名为TEST为例
(1)得到包含工程名确当前页面全路径：

　request.getRequestURI()  

结果：/TEST/test.jsp 
(2)得到工程名：

request.getContextPath() 

结果：/TEST
(3)得到当前页面所在目录下全名称：

request.getServletPath()  

结果：假如页面在jsp目录下 /TEST/jsp/test.jsp 
(4)得到页面所在服务器的全路径：

application.getRealPath("test.jsp")   

结果：D:\resin\webapps\TEST\test.jsp
(5)得到页面所在服务器的尽对路径：

absPath=new java.io.File(application.getRealPath(request.getRequestURI())).getParent();  

结果：D:\resin\webapps\TEST
2.在类中取得路径：
(1)类的尽对路径：

Class.class.getClass().getResource("/").getPath()   

(2)得到工程的路径：

System.getProperty("user.dir")  

结果：D:\TEST 
3.在Servlet中取得路径：
(1)得到工程目录：

request.getSession().getServletContext().getRealPath("")//参数可具体到包名。  

结果：E:\Tomcat\webapps\TEST 
(2)得到IE地址栏地址：

request.getRequestURL()   

结果：http://localhost:8080/TEST/test 
(3)得到相对地址：

request.getRequestURI()   

结果：/TEST/test