欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页

Java资源文件的读取总结

程序员文章站 2022-07-12 13:28:09
...

资源文件的读取总结

 1什么是资源?

在一个稍具规模的应用程序中,经常要做的一件事,就是查找资源、读取资源的内容。这里所谓的“资源”,是指存放在某一介质中,可以被程序利用的文件、数据。例如,基于JavaWEB应用中,常用到下面的资源:

配置文件:*.xml*.properties等。

Java类文件:*.class

JSP页面、Velocity模板文件:*.jsp*.vm等。

图片、CSSJavaScript文件:*.jpg*.css*.js等。

2. 如何表示资源?

Java中,有多种形式可以表示一个资源:

可表示资源的对    象

说明

java.io.File

可代表文件系统中的文件或目录。例如:

文件系统中的文件:“c:\config.sys”。

文件系统中的目录:“c:\windows\”。

 

java.net.URL

统一资源定位符。例如:

文件系统中的文件:c:\config.sys,可以表示成URL:“file:///c:/config.sys”。

文件系统中的目录:c:\windows\,可以表示成URL:“file:///c:/windows/”。

远程WEB服务器上的文件:“http://www.springframework.org/schema/beans.xml”。

Jar包中的某个文件,可以表示成URL:“jar:file:///c:/my.jar!/my/file.txt”。

 

java.io.InputStream

输入流对象,可用来直接访问资源的内容。例如:

文件系统中的文件:c:\config.sys,可以用下面的代码来转换成输入流:

new FileInputStream("c:\\config.sys");

远程WEB服务器上的文件,可以用下面的代码来转换成输入流:

new URL("http://www.springframework.org/schema/beans.xml").openStream();

Jar包中的某个文件,可以用下面的代码来转换成输入流:

new URL("jar:file:///c:/my.jar!/my/file.txt").openStream();

 

然而,并不是所有的资源,都可以表现成上述所有的形式。比如,

Windows文件系统中的目录,无法表现为输入流。

而远程WEB服务器上的文件无法转换成File对象。

多数资源都可以表现成URL形式。但也有例外,例如,如果把数据库中的数据看作资源,那么一般来说这种资源无法表示成URL

3. 如何访问资源?

不同类型的资源,需要用不同的方法来访问。

访问CLASSPATH中的资源

将资源放在CLASSPATH是最简单的做法。我们只要把所需的资源文件打包到Jar文件中,或是在运行java时,用-classpath参数中指定的路径中。接下来我们就可以用下面的代码来访问这些资源:

: 访问CLASSPATH中的资源

URL resourceURL=getClassLoader().getResource("java/lang/String.class");

 // 取得URL

InputStream resourceContent = getClassLoader().getResourceAsStream("java/lang/String.class"); // 取得输入流

访问文件系统中的资源

下面的代码从文件资源中读取信息:

: 访问文件系统中的资源

File resourceFile = new File("c:\\test.txt"); // 取得File

InputStream resourceContent = new FileInputStream(resourceFile); // 取得输入流

访问Web应用中的资源

Web应用既可以打包成war文件,也可以展开到任意目录中。因此Web应用中的资源(JSP、模板、图片、Java类、配置文件)不总是可以用文件的方式存取。虽然Servlet API提供了ServletContext.getRealPath()方法,用来取得某个资源的实际文件路径,但该方法很可能返回null —— 这取决于应用服务器的实现,以及Web应用的布署方式。更好的获取WEB应用资源的方法如下:

: 访问Web应用中的资源

URL resourceURL = servletContext.getResource("/WEB-INF/web.xml"); // 取得URL

InputStream resourceContent = servletContext.getResourceAsStream("/WEB-INF/web.xml"); // 取得输入流

访问Jar/Zip文件中的资源

下面的代码读取被打包在Jar文件中的资源信息:

  访问Jar/Zip文件中的资源

URL jarURL = new File(System.getProperty("java.home") + "/lib/rt.jar").toURI().toURL();

URL resourceURL = new URL("jar:" + jarURL + "!/java/lang/String.class"); // 取得URL

InputStream resourceContent = resourceURL.openStream(); // 取得输入流

访问其它资源

还可以想到一些访问资源的方法,例如从数据库中取得资源数据。

4. 如何遍历资源?

有时候,我们不知道资源的路径,但希望能找出所有符合条件的资源,这个操作叫作遍历。例如,找出所有符合pattern /WEB-INF/webx-*.xml”的配置文件。

遍历文件系统

 遍历文件系统

File parentResource = new File("c:\\windows");

File[] subResources = parentResource.listFiles();

遍历WEB应用中的资源

 遍历WEB应用中的资源

Set<String> subResources = servletContext.getResourcePaths("/WEB-INF/");

遍历Jar/zip文件中的资源

 遍历Jar/zip文件中的资源

File jar = new File("myfile.jar");

ZipInputStream zis = new ZipInputStream(new FileInputStream(jar));

 

try {

    for (ZipEntry entry = zis.getNextEntry(); entry != null; entry = zis.getNextEntry()) {

        // visit entry

    }

finally {

    zis.close();

}

并非所有类型的资源都支持遍历操作。通常遍历操作会涉及比较复杂的递归算法。

5. 有什么问题?

应用程序访问资源时,有什么问题呢?

首先,资源表现形式的多样性,给应用程序的接口设计带来一点麻烦。假如,我写一个ConfigReader类,用来读各种配置文件。那么我可能需要在接口中列出所有的资源的形式:

 用来读取配置文件的接口

public interface ConfigReader {

    Object readConfig(File configFile);

    Object readConfig(URL configURL);

    Object readConfig(InputStream configStream);

}

特别是当一个通用的框架,如SpringWebx,需要在对象之间传递各种形式的资源的时候,这种多样性将导致很大的编程困难。

其次,有这么多种查找资源和遍历资源的方法,使我们的应用程序和资源所在的环境高度耦合。这种耦合会妨碍代码的可移植性和可测试性。

比如,我希望在非WEB的环境下测试一个模块,但这个模块因为要存取Web应用下的资源,而引用了ServletContext对象。在测试环境中并不存在ServletContext而导致该模块难以被测试。再比如,我希望测试的一个模块,引用了classpath下的某个配置文件(这也是一种耦合)。而我希望用另一个专为该测试打造的配置文件来代替这个文件。由于原配置文件是在classpath中,因此是难以替换的。

对于不打算重用的应用程序来说,这个问题还不太严重:大不了我预先设定好,就从这个地方,以固定的方式存取资源。然而就算这样,也是挺麻烦的。有的人喜欢把资源放在某个子目录下,有的人喜欢把资源放在CLASSPATH下,又有人总是通过ServletContext来存取Web应用下的资源。当你要把这些不同人写的模块整合起来时,你会发现很难管理。

一种可能发生的情形是,因为某些原因,环境发生改变,导致资源的位置、存取方式不得不跟着改变。比如将老系统升级为新系统。但一些不得不继续使用的老代码,由于引用了旧环境的资源而不能工作 —— 除非你去修改这些代码。有时修改老代码是很危险的,可能导致不可预知的错误。又比如,由于存储硬件的改变或管理的需要,我们需要将部分资源移到另一个地方(我们曾经将Web页面模板中的某个子目录,移动到一个新的地方,因为这些模板必须由新的CMS系统自动生成)。想要不影响现有代码来完成这些事,是很困难的。