цифры - регулярные выражения java таблица




Почему \ R ведет себя по-разному в регулярных выражениях между Java 8 и Java 9? (2)

Следующий код компилируется в Java 8 и 9, но ведет себя по-разному.

class Simple {
    static String sample = "\nEn un lugar\r\nde la Mancha\nde cuyo nombre\r\nno quiero acordarme";

    public static void main(String args[]){
        String[] chunks = sample.split("\\R\\R");
        for (String chunk: chunks) {
            System.out.println("Chunk : "+chunk);
        }
    }
}

Когда я запускаю его с Java 8, он возвращает:

Chunk : 
En un lugar
de la Mancha
de cuyo nombre
no quiero acordarme

Но когда я запускаю его с Java 9, результат будет другим:

Chunk : 
En un lugar
Chunk : de la Mancha
de cuyo nombre
Chunk : no quiero acordarme

Зачем?


Документация Java не соответствует стандарту Unicode. Javadoc ошибается, что \R должен соответствовать. Это читает:

\R Любая последовательность \u000D\u000A|[\u000A\u000B\u000C\u000D\u0085\u2028\u2029] строки в Юникоде, эквивалентна \u000D\u000A|[\u000A\u000B\u000C\u000D\u0085\u2028\u2029]

Эта документация Java содержит ошибки. В своем разделе о переносе строк R1.6 Технический стандарт Unicode № 18 на регулярные выражения четко гласит:

Настоятельно рекомендуется использовать метасимвол регулярного выражения, например "\ R", для сопоставления всех символов окончания строки и последовательностей, перечисленных выше (например, в # 1). Это будет соответствовать чему-то эквивалентному следующему выражению. Это выражение немного усложняется необходимостью избегать резервного копирования.

 (?:\u{D A}|(?!\u{D A})[\u{A}-\u{D}\u{85}\u{2028}\u{2029}]

Другими словами, он может соответствовать только двум последовательностям CR + LF (возврат каретки + перевод строки) или только одной кодовой точке из этого набора, при условии, что за ним следует не только возврат каретки, за которым следует перевод строки. , Это потому, что не разрешено делать резервные копии . CRLF должен быть атомарным, чтобы \R работал правильно.

Так что Java 9 больше не соответствует тому, что настоятельно рекомендует R1.6. Более того, теперь он делает то, что он НЕ должен был делать и не делал в Java 8.

Похоже, мне пора снова кричать Шерману (читай: Сюэмин Шен). Я работал с ним раньше над этими мелкими вопросами формального соответствия.






java-9