标签:substr 细节 swap 对象 sof 有用 复制 XML 好的
Commons IO是针对开发IO流功能的工具类库。
主要包含六个区域:
工具类——使用静态方法运行共同任务
输入——用于InputStream和Reader实现
输出——用于OutputStream和Writer实现
过滤器——各种文件过滤器实现
比較器——各种文件的java.util.Comparator实现
文件监听器——监听文件系统事件的组件
Commons IO包括工具类、endian classes, line iterator, file filters, file comparators and stream implementations.
很多其它具体描写叙述见javadocs。
IOUtils包括处理读、写和复制的工具方法。
方法对InputStream、OutputStream、Reader和Writer起作用。
比如。从一个URL读取字节的任务。而且打印它们:
InputStream in = new URL( "http://commons.apache.org" ).openStream(); |
使用IOUtils:
InputStream in = new URL( "http://commons.apache.org" ).openStream();
|
在某些应用领域,这些IO操作是常见的,而这个类能够节省大量的时间。你能够依靠经过良好測试的代码。
这种有用程序代码,灵活性和速度是最重要的。可是你也应该理解这个方案的局限性。使用上述技术读取一个1 gb文件将导致试图创建一个1 gb的字符串对象!
FileUtils类包括使用File对象的工具方法。
包括读写、复制和比較稳健。
读取整个文件行:
File file = new File("/commons/io/project.properties");
|
FilenameUtils类包括工具方法不须要使用File对象就能够操作文件名称。该类致力于屏蔽Unix和Windows之间的不同,避免这些环境之间的转换(比如。从开发到生产)。
比如。规范文件删除双点片段:
String filename = "C:/commons/io/../lang/project.xml"; 返回 |
FileSystemUtils类包括使用JDK不支持的文件系统訪问功能的工具方法。
当前,仅仅有获取驱动的空间大小的方法。注意。这是使用的命令行,而不是本地代码。
long freeSpace = FileSystemUtils.freeSpace("C:/"); |
不同的计算机体系採用不同的字节排序约定。
在所谓的“Little Endian”的体系结构中(比如Intel),低位字节存储在内存中较低地址,兴许字节在较高地址。
对于“Big EndIan”体系结构,(比如Motorola),情况恰好相反。
在关联包中有两个类:
EndianUtils类包括交换Java原始和流的Endian-ness的静态方法。
SwappedDataInputStream类是DataInput接口的实现。
使用它,我们能从非本地EndIan-ness的文件读取数据。
很多其它细节见http://www.cs.umass.edu/~verts/cs32/endian.html。
org.apache.commons.io.LineIterator类提供灵活的方式使用一个基于行的文件。
能够直接。或通过FileUtils或IOUtils的工厂方法创建实例。
推荐使用模式:
处理行 } finally {
} |
org.apache.commons.io.filefilter包定义一个接口(IOFileFilter)包括java.io.FileFilter和java.io.FilenameFilter。此外,包提供一系列随时可用的IOFileFilter接口实现,包括同意你组合其他过滤器的实现。这些过滤器能用于列出文件。
org.apache.commons.io.comparator包提供一系列java.io.File的java.util.Comparator实现。这些比較器能用于排序文件列表和数组。
org.apache.commons.io.input和org.apache.commons.io.output包括各种实用的流实现。
空输出流——默默的吸收发给它的全部数据。
Tee输出流——发送输出数据到两个流。
字节输出输出流——更便捷的JDK类版本号。
计算流——统计传递的字节数。
代理流——托付恰当的方法代理。
可锁定的Writer——使用文件锁提供同步的Writer。
该文档在IO领域出现一系列“最佳实践”。
通常,你必须使用文件和文件名称。
有非常多事情可能出错:
一个类能够在Unix上工作但不能在Windows上工作(反之亦然)
因为双重或丢失路径分隔符的无效路径
UNC文件名称(在Windows上)不使用我的本地文件名称功能函数
等等
这些都是非常好的理由不使用文件名称作为字符串。使用java.io.File而不是处理上面的非常多中情况。因此,我们最好的实践推荐使用java.io.File而不是文件名称字符串避免平台依赖。
Commons-io 1.1包含一个专注于文件名称处理的类——FilenameUtils。这处理很多这些文件名称问题,然而,任然推荐,尽可能,使用java.io.File对象。
public static String getExtension(String filename) {
|
足够简单?对的,但假设传入一个完整路径而不是一个文件名称会发生什么?请看以下,全然合法的路径:“C:\Temp\documentation.new\README”。定义在上面的方法返回“new\README”,肯定不是你想要的。
请使用java.io.File而不是字符串。
在FileUtils你将看到环绕java.io.File的功能函数。
不推荐:
String tmpdir = "/var/tmp";
InputStream in = new java.io.FileInputStream(tmpfile); |
推荐:
File tmpdir = new File("/var/tmp");
|
IO性能依赖于缓冲策略。通常。读取大小为512或1024字节的数据包速度非常快。由于这些大小匹配使用在硬盘上的文件系统或文件系统缓冲中的数据包大小。但仅仅要你多次仅仅读取几个字节。性能肯定下降。
当你读取或输出流尤其是处理文件时确保你正确的缓冲流。仅仅是使用BufferedInputStream装饰你的FileInputStream。
InputStream in = new java.io.FileInputStream(myfile);
} |
注意。不要缓冲已经缓冲的流。一些组件像XML解析器能够做自己的缓冲。因此不须要装饰InputStream传入XML解析器,但减慢你的代码。假设你使用CopyUtils或IOUtils不须要使用额外的缓冲流
标签:substr 细节 swap 对象 sof 有用 复制 XML 好的
原文地址:http://www.cnblogs.com/gccbuaa/p/7397433.html