Java-字符文件的文件处理

Java-字符文件的文件处理,java,Java,我有一个文件的字符如下:ABCD…hhccchh..BC 现在,如果两个H之间的间距小于20个字符,我想删除两个H之间的字符。并将输出写入新文件。因此,新文件将如下所示: ABCD…HH..BC 这能以一种快速的方式完成吗?如果文件可以很容易地放入内存,并且您可以使用Apache commons io String input = FileUtils.readFileToString(new File("inputFile"), "UTF-8"); Pattern p = Pattern.com

我有一个文件的字符如下:
ABCD…hhccchh..BC

现在,如果两个
H
之间的间距小于20个字符,我想删除两个
H
之间的字符。并将输出写入新文件。因此,新文件将如下所示:

ABCD…HH..BC


这能以一种快速的方式完成吗?

如果文件可以很容易地放入内存,并且您可以使用Apache commons io

String input = FileUtils.readFileToString(new File("inputFile"), "UTF-8");
Pattern p = Pattern.compile("H[^H]{1,19}H");
Matcher m = p.matcher(input);
String output = m.replaceAll("HH");
FileUtils.writeStringToFile(new File("outputFile"), output, "UTF-8");

如果文件可以很容易地放入内存,您可以使用ApacheCommonsIO

String input = FileUtils.readFileToString(new File("inputFile"), "UTF-8");
Pattern p = Pattern.compile("H[^H]{1,19}H");
Matcher m = p.matcher(input);
String output = m.replaceAll("HH");
FileUtils.writeStringToFile(new File("outputFile"), output, "UTF-8");
纯Java代码

public static void main(String[] args) throws Exception {

    BufferedReader in=new BufferedReader(new FileReader("d:\\data1.txt"));
    StringBuilder sb=new StringBuilder();
    String line=null;
    while((line=in.readLine())!=null)
        sb.append(line);

    String alteredData=sb.toString().replaceAll("H.{1,19}H", "HH");

    BufferedWriter out=new BufferedWriter(new FileWriter("d:\\data2.txt"));
    out.write(alteredData);

    in.close();
    out.close();

}
纯Java代码

public static void main(String[] args) throws Exception {

    BufferedReader in=new BufferedReader(new FileReader("d:\\data1.txt"));
    StringBuilder sb=new StringBuilder();
    String line=null;
    while((line=in.readLine())!=null)
        sb.append(line);

    String alteredData=sb.toString().replaceAll("H.{1,19}H", "HH");

    BufferedWriter out=new BufferedWriter(new FileWriter("d:\\data2.txt"));
    out.write(alteredData);

    in.close();
    out.close();

}

我会把这个作为对约翰·瓦茨答案的评论,但它有点太长了

缓冲I/O是非常有效的。为了获得良好的性能,不需要将整个文件加载到内存中。假设它是一个面向行的文件,并且模式不跨越行边界,这就足够了:

import java.io.BufferedReader;
import java.io.FileReader;
import java.io.FileWriter;
import java.util.regex.Pattern;
import java.util.regex.Matcher;

...

BufferedReader r = new BufferedReader(new FileReader(inputFile));
FileWriter w = new FileWriter(outFile);
String line;
Pattern p = Pattern.compile("HH.{1,19}HH");

while (((line = r.readLine()) != null)
{
    Matcher m = p.matcher(line);
    w.write(m.replaceAll("HHHH"));
    w.write('\n');
}

w.close();
r.close();

...

我会把这个作为对约翰·瓦茨答案的评论,但它有点太长了

缓冲I/O是非常有效的。为了获得良好的性能,不需要将整个文件加载到内存中。假设它是一个面向行的文件,并且模式不跨越行边界,这就足够了:

import java.io.BufferedReader;
import java.io.FileReader;
import java.io.FileWriter;
import java.util.regex.Pattern;
import java.util.regex.Matcher;

...

BufferedReader r = new BufferedReader(new FileReader(inputFile));
FileWriter w = new FileWriter(outFile);
String line;
Pattern p = Pattern.compile("HH.{1,19}HH");

while (((line = r.readLine()) != null)
{
    Matcher m = p.matcher(line);
    w.write(m.replaceAll("HHHH"));
    w.write('\n');
}

w.close();
r.close();

...

为什么图案的开头和结尾都有
HH
?是否应该改为
H
。更新。原始措辞令人困惑,但原始版本和编辑版本都明确要求替换H之间的所有内容,而不是双H之间的所有内容。20是一个排他性上限,但在regex中20是包容性的。19.除了读和写文件部分,我们现在已经得出了相同的答案。当然,这篇文章有很多选择。哦,我想我在编辑的时候犯了一个错误。我认为OP的意思是
H
,而不是
HH
,他错写了
HH
。我还不确定我的判断是否正确,我以后肯定会更加小心。为什么这个模式在开头和结尾都有
HH
?是否应该改为
H
。更新。原始措辞令人困惑,但原始版本和编辑版本都明确要求替换H之间的所有内容,而不是双H之间的所有内容。20是一个排他性上限,但在regex中20是包容性的。19.除了读和写文件部分,我们现在已经得出了相同的答案。当然,这篇文章有很多选择。哦,我想我在编辑的时候犯了一个错误。我认为OP的意思是
H
,而不是
HH
,他错写了
HH
。我还不确定我说的对不对,我以后一定会更加小心。@MarkoTopolnik但OP想将
ABCD…hhccchh..BC
更改为
ABCD…HH..BC
,所以在
hhccchh
中捕捉内部
H
应该可以。OP没有指定外部HH之间的字符要求。您的模式可以匹配“HAAHBBH”整体而言,吞下内心的H,因为这是一个贪婪的匹配。。。。这显然不是OP想要的。您可能对短语“两个HH之间的差距”有一个创造性的解释,以弥补您的解决方案,但这没有多大帮助。@MarkoTopolnik在我看来,如果它不是贪婪匹配,那么
hhccchh
无法生成
HH
。OP给了我们一个很好的例子,他不在乎外部
H
s之间是否有其他
H
。至少我是这么看的。无论如何,争论这件事是没有意义的。我们100%不知道OP想要什么:)@MarkoTopolnik,但OP想要将
ABCD…hhccchh..BC
更改为
ABCD…HH..BC
,因此在
hhccchh
中捕获内部
H
应该是可以的。OP没有指定外部HH之间的字符的任何要求。您的模式可以完全匹配“HAAHBBH”,吞下内心的H,因为这是一个贪婪的匹配。。。。这显然不是OP想要的。您可能对短语“两个HH之间的差距”有一个创造性的解释,以弥补您的解决方案,但这没有多大帮助。@MarkoTopolnik在我看来,如果它不是贪婪匹配,那么
hhccchh
无法生成
HH
。OP给了我们一个很好的例子,他不在乎外部
H
s之间是否有其他
H
。至少我是这么看的。无论如何,争论这件事是没有意义的。我们100%不知道OP想要什么:)