Python 官方文档:入门教程 => 点击学习
目录使用Files.readLines()处理文本中行数据被readLine()折腾了一把发数据读数据readLine()的实质(下面是从jdk源码摘出来的)小结,使用readLin
开发中遇到对数据库导出到文件里的数据进行处理,然后对处理后的数据再重新写回文件中,在这个过程中使用到了Files.readLines()方法
public void lineProcess(File file) throws ioException {
Files.readLines(file, Charset.defaultCharset(), new LineProcessor() {
File outFile = new File("outfile");//处理后的数据输出文件
List<String> lines = new ArrayList<String>();
@Override
public boolean processLine(String line) throws IOException {
String newLine = "";
//file中的 line数据格式:name,age,address -> NAME,AGE,ADDRESS,
String[] contents = line.split(",");
for (int i=0;i<contents.length;i++){
newLine.concat(contents[i].toLowerCase());
}
lines.add(newLine);
//将处理后的数写入新的文件 outFile
FileUtils.writeLines(outFile,lines,true);
lines.clear();
return true;
}
@Override
public Object getResult() {
try{
FileUtils.writeLines(outFile,lines,true);
}catch (Exception e){
e.getCause();
}
lines.clear();
return null;
}
});
}
方法中的LineProcessor()实现对每一行数据处理逻辑。
依赖guava
<dependency>
<groupId>com.Google.guava</groupId>
<artifactId>guava</artifactId>
<version>19.0</version>
</dependency>
虽然写IO方面的程序不多,但BufferedReader/BufferedInputStream倒是用过好几次的,原因是:
它有一个很特别的方法:readLine(),使用起来特别方便,每次读回来的都是一行,省了很多手动拼接buffer的琐碎;
它比较高效,相对于一个字符/字节地读取、转换、返回来说,它有一个缓冲区,读满缓冲区才返回;一般情况下,都建议使用它们把其它Reader/InputStream包起来,使得读取数据更高效。
对于文件来说,经常遇到一行一行的,特别相符情景。
这次是在蓝牙开发时,使用两个蓝牙互相传数据(即一个发一个收),bluecove这个开源组件已经把数据读取都封装成InputStream了,也就相当于平时的IO读取了,很自然就使用起readLine()来了。
BufferedWriter output = new BufferedWriter(new OutputStreamWriter(conn.openOutputStream()));
int i = 1;
String message = "message " + i;
while(isRunning) {
output.write(message+"/n");
i++;
}
BufferedReader input = new BufferedReader(new InputStreamReader(m_conn.openInputStream()));
String message = "";
String line = null;
while((line = m_input.readLine()) != null) {
message += line;
}
System.out.println(message);
上面是代码的节选,使用这段代码会发现写数据时每次都成功,而读数据侧却一直没有数据输出(除非把流关掉)。经过折腾,原来这里面有几个大问题需要理解:
误以为readLine()是读取到没有数据时就返回null(因为其它read方法当读到没有数据时返回-1),而实际上readLine()是一个阻塞函数,当没有数据读取时,就一直会阻塞在那,而不是返回null;因为readLine()阻塞后,System.out.println(message)这句根本就不会执行到,所以在接收端就不会有东西输出。要想执行到System.out.println(message),一个办法是发送完数据后就关掉流,这样readLine()结束阻塞状态,而能够得到正确的结果,但显然不能传一行就关一次数据流;另外一个办法是把System.out.println(message)放到while循环体内就可以。
readLine()只有在数据流发生异常或者另一端被close()掉时,才会返回null值。
如果不指定buffer大小,则readLine()使用的buffer有8192个字符。在达到buffer大小之前,只有遇到"/r"、"/n"、"/r/n"才会返回。
String readLine(boolean ignoreLF) throws IOException {
StringBuffer s = null;
int startChar;
synchronized (lock) {
ensureOpen();
boolean omitLF = ignoreLF || skipLF;
bufferLoop:
for (;;) {
if (nextChar >= nChars)
fill(); //在此读数据
if (nextChar >= nChars) {
if (s != null && s.length() > 0)
return s.toString();
else
return null;
}
......//其它
}
private void fill() throws IOException {
..../其它
int n;
do {
n = in.read(cb, dst, cb.length - dst); //实质
} while (n == 0);
if (n > 0) {
nChars = dst + n;
nextChar = dst;
}
}
从上面看出,readLine()是调用了read(char[] cbuf, int off, int len) 来读取数据,后面再根据"/r"或"/n"来进行数据处理。
在Java I/O书上也说了:
public String readLine() throws IOException
This method returns a string that contains a line of text from a text file. /r, /n, and /r/n are assumed to be line breaks and are not included in the returned string. This method is often used when reading user input from System.in, since most platfORMs only send the user's input to the running program after the user has typed a full line (that is, hit the Return key).
readLine() has the same problem with line ends that DataInputStream's readLine() method has; that is, the potential to hang on a lone carriage return that ends the stream . This problem is especially acute on networked connections, where readLine() should never be used.
读入的数据要注意有/r或/n或/r/n
没有数据时会阻塞,在数据流异常或断开时才会返回null
使用Socket之类的数据流时,要避免使用readLine(),以免为了等待一个换行/回车符而一直阻塞
以上为个人经验,希望能给大家一个参考,也希望大家多多支持编程网。
--结束END--
本文标题: java中使用Files.readLines()处理文本中行数据方式
本文链接: https://lsjlt.com/news/159500.html(转载时请注明来源链接)
有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341
2024-03-01
2024-03-01
2024-03-01
2024-02-29
2024-02-29
2024-02-29
2024-02-29
2024-02-29
2024-02-29
2024-02-29
回答
回答
回答
回答
回答
回答
回答
回答
回答
回答
0