关于正则表达式的问题，会者请进，up有分。

最近在做正则表达式的时候出现了点问题，我是用apache的ORO来做的，但我估计这个和正则表达式的解析包没什么关系。
拿一个简单例子来说：
比如对于一个html文件，假设我想取出<html></html>之间的所有代码（不包括<html>和</html>），我的匹配模式书写如下：String regexp = "<html>((.|\n)*?)</html>";结果运行后错误错误，错误是这样的：
 Exception in thread "main" java.lang.StackOverflowError
        at org.apache.oro.text.regex.Perl5Matcher.__match(Unknown Source)
        at org.apache.oro.text.regex.Perl5Matcher.__match(Unknown Source)
        at org.apache.oro.text.regex.Perl5Matcher.__match(Unknown Source)
我分析了一下，这个是堆栈溢出异常，应该是我取的的内容太大，超过了限制所导致的。后来我把<html>和</html>中的内容减少了之后，发现的确是可以正常取出数据的，但是数据量大就出现了上面的问题。当然这只是一个例子，我想知道，对于匹配结果非常大的时候，各位是如何解决的？偶对正则表达式研究一般，还请各位不惜赐教。

解决方案 »

  1.   

    还有就是java自带的正则表达式你为什么不用呢？你可以试试那个啊import java.util.regex.*;
      

  2.   

    感觉正则表达式不太适合处理这种超文本文件，刚才看了一下oro的源码，发现为了实现匹配的效率而大量使用了递归，在处理这种超文本文件时，由于内容过大而导致递归太深，避免不了出现堆栈溢出！
      

  3.   

    不用，java 的正则表达式 中提供了防止回溯的模式。
    Pattern p=Pattern.compile("<html>(.*+)</html>",Pattern.DOTALL);
    Matcher m=p.matcher(dddddddd);  //dddddd表示你的html文件内容
    if (m.matches())
       System.out.println(m.group());
      

  4.   

    晕， dotall模式是这个意思吗？Enables dotall mode. 
    In dotall mode, the expression . matches any character, including a line terminator. By default this expression does not match line terminators. Dotall mode can also be enabled via the embedded flag expression (?s). (The s is a mnemonic for "single-line" mode, which is what this is called in Perl.) 
      

  5.   

    如果是按照jFresH_MaN说的话，那我觉得正则表达式的局限性似乎有点太大了，匹配结果稍微大一点，正则就无能为力了，而这似乎有些说不过去，虽然事实如此。如果按照传统方式来读的话，效率怎么样，我觉得可能要大打折扣吧？具体怎么做，用indexOf来进行字符查找，然后substring(start,end)来实现吗？刚才又想了一下，如果我的html文件很大，而indexOf的返回值是int型，如果我查找的结果超过了int的范围，那后果是什么样子？变成了负数吗？这样就很可笑了。那就只能是按行读取才能避免这个问题了吧。
      

  6.   

    不是dotall, dotall是匹配行结尾而已
    占有的模式  是. *+
      

  7.   

    jFresH_MaN(Contributing to Eclipse) 
    楼主用的是.*?这是勉强的，能够保证最后只匹配一个，但是中间可是要反复回溯的。
      

  8.   

    晕，我可没有说你的这个问题和正则表达式有关系。
    你这个明显就是因为html文件过大，赋给字符串之后内存溢出了。这样的话只能逐个字符读取数据了。事实上正则表达式的效率确实很低，相反indexOf()和substring()的效率是最高的，
    如果楼主觉得我说的没道理，我也没得说了。
      

  9.   

    呵呵，没有，我不是那个意思，正相反，我觉得你说的很有道理。我是认为匹配结果大的情况下，正则的group就吃不消了，这有点过分。但是indexOf效率比正则高，这个我到是抱着怀疑的态度，我记得似乎它也是基于正则表达式的原理吧？replace也是基于正则的原理。
      

  10.   

    准备结贴了，我已经准备用分析字符串的方法了，看来正则的限制还真的蛮大的，对于匹配结果比较大的时候功能实在有限，而且感觉写了正则就相当于把模式固定死了，如果文本稍微不匹配就无法返回结果，要么就出现我贴的这种问题，还是有些局限性的，感觉只适用于模式比较固定的地方比如email，分析链接，图片等这种比较简单的地方。