Помогите лучше разбирать цифры из строки в Java

Question

У меня есть строка, которая содержит цифры и буквы. Я хочу разбить строку на смежные куски цифр и смежные куски букв.

Рассмотрите строку "34A312O5M444123A".

Я хотел бы выход: [ "34", "A", "312", "O", "5", "М", "444123", "А"]

меня код, который работает и выглядит следующим образом:

List<String> digitsAsElements(String str){ 
    StringBuilder digitCollector = new StringBuilder(); 

    List<String> output = new ArrayList<String>(); 

    for (int i = 0; i < str.length(); i++){ 
    char cChar = str.charAt(i); 

    if (Character.isDigit(cChar)) 
     digitCollector.append(cChar); 
    else{ 
     output.add(digitCollector.toString()); 
     output.add(""+cChar); 

     digitCollector = new StringBuilder(); 
    }   
    } 

    return output; 
} 

Я считал ул расщепляющий дважды, чтобы получить массив, содержащий все числа ломти и массив, содержащий все буквы куски. Затем слияние результатов. Я уклонился от этого, так как это навредило бы читаемости.

Я намеренно избегаю решения этой проблемы с помощью шаблона регулярных выражений, поскольку я считаю, что шаблоны регулярных выражений являются основным препятствием для удобочитаемости.

• Отладчики плохо справляются с ними.
• Они прерывают поток кого-то, читающего исходный код.
• Регулярное выражение регулярного выражения Overtime вырастает органично и становится монстрами.
• Они глубоко не интуитивно понятны.

Мои вопросы:

• Как я мог улучшить читаемость кода выше?
• Есть ли лучший способ сделать это? Класс Util, который решает эту проблему элегантно.
• Где вы рисуете линию между использованием regEx и кодированием чего-то близкого к тому, что я написал выше?
• Как повысить читабельность/поддерживаемость regExes?

Answer 1

ли вы быть готовы использовать регулярные выражения, если это означает решение проблемы в одной строке кода?

// Split at any position that's either: 
// preceded by a digit and followed by a non-digit, or 
// preceded by a non-digit and followed by a digit. 
String[] parts = str.split("(?<=\\d)(?=\\D)|(?<=\\D)(?=\\d)"); 

С комментарием объяснить регулярное выражение, я думаю, что это более читаемым, чем любой из не регулярных выражений решений (или любой из других регулярных выражений решений по этому вопросу).

Answer 2

Для этой конкретной задачи я всегда использую регулярное выражение вместо того, чтобы писать что-то подобное. Код, который вы указали выше, по крайней мере для меня менее читабельен, чем простое регулярное выражение (которое в этом случае было бы (\d+|[^\d]+), насколько я вижу).

Возможно, вы захотите избежать написания регулярных выражений, которые превышают несколько строк. Это могут быть и обычно нечитаемы и трудно понять, , но так же, как и код, который они могут заменить! Парсеры почти никогда не красивы, и вам обычно лучше читать оригинальную грамматику, чем пытаться понять созданный (или рукописный) парсер. То же самое происходит (imho) для регулярных выражений, которые являются лишь кратким описанием регулярной грамматики.

Итак, в общем, я бы сказал, что запрещение регулярных выражений в пользу кода, как вы дали в своем вопросе, звучит как ужасно глупая идея. И регулярные выражения - это просто инструмент, не меньше, не более того. Если что-то еще лучше выполняет синтаксический анализ текста (скажем, настоящий парсер, магия подстроки и т. Д.), То используйте его. Но не выбрасывайте возможности только потому, что вам неловко с ними - у других может быть меньше проблем с ними, и все люди могут учиться.

EDIT: Обновлено regex после комментария от mmyers.

Answer 3

Я бы использовал что-то вроде этого (предупреждение, непроверенный код). Для меня это намного более читаемо, чем попытка избежать регулярных выражений. Regexps - отличный инструмент, когда он используется в правильном месте.

Комментирование методов и предоставление примеров входных и выходных значений в комментариях также помогает.

List<String> digitsAsElements(String str){ 
    Pattern p = Pattern.compile("(\\d+|\\w+)*"); 
    Matcher m = p.matcher(str); 

    List<String> output = new ArrayList<String>(); 
    for(int i = 1; i <= m.groupCount(); i++) { 
     output.add(m.group(i)); 
    } 
    return output; 
} 

Answer 4

Awww, кто-то избил меня в код. Я думаю, что регулярное выражение легче читать/поддерживать. Кроме того, обратите внимание на разницу в выходе между 2 реализациями против ожидаемого результата ...

Выход:

digitsAsElements1("34A312O5MNI444123A") = [34, A, 312, O, 5, M, , N, , I, 444123, A] 
digitsAsElements2("34A312O5MNI444123A") = [34, A, 312, O, 5, MNI, 444123, A] 
Expected: [34, A, 312, O, 5, MN, 444123, A] 

Сравнить:

DigitsAsElements.java:

import java.util.ArrayList; 
import java.util.List; 
import java.util.regex.Matcher; 
import java.util.regex.Pattern; 

public class DigitsAsElements { 

    static List<String> digitsAsElements1(String str){ 
     StringBuilder digitCollector = new StringBuilder(); 

     List<String> output = new ArrayList<String>(); 

     for (int i = 0; i < str.length(); i++){ 
      char cChar = str.charAt(i); 

      if (Character.isDigit(cChar)) 
      digitCollector.append(cChar); 
      else{ 
      output.add(digitCollector.toString()); 
      output.add(""+cChar); 

      digitCollector = new StringBuilder(); 
      }   
     } 

     return output; 
     } 

    static List<String> digitsAsElements2(String str){ 
     // Match a consecutive series of digits or non-digits 
     final Pattern pattern = Pattern.compile("(\\d+|\\D+)"); 
     final Matcher matcher = pattern.matcher(str); 

     final List<String> output = new ArrayList<String>(); 
     while (matcher.find()) { 
      output.add(matcher.group()); 
     } 

     return output; 
     } 

    /** 
    * @param args 
    */ 
    public static void main(String[] args) { 
     System.out.println("digitsAsElements(\"34A312O5MNI444123A\") = " + 
       digitsAsElements1("34A312O5MNI444123A")); 
     System.out.println("digitsAsElements2(\"34A312O5MNI444123A\") = " + 
       digitsAsElements2("34A312O5MNI444123A")); 
     System.out.println("Expected: [" + 
       "34, A, 312, O, 5, MN, 444123, A"+"]"); 
    } 

} 

Answer 5

Для класса полезности, проверьте o ut java.util.Scanner. Есть несколько вариантов в том, как вы можете решить свою проблему. У меня есть несколько комментариев по вашим вопросам.

Debuggers не обрабатывать их (регулярные выражения) ну

ли регулярных выражений работает или нет, зависит от, что там в ваших данных. Есть несколько полезных плагинов, которые вы можете использовать, чтобы помочь вам создать регулярное выражение, например QuickREx для Eclipse, действительно ли отладчик поможет вам написать правильный парсер для ваших данных?

Они прерывают поток кого-то, читающего исходный код.

Я думаю, это зависит от того, насколько вам комфортно с ними. Лично я предпочел бы прочитать разумное регулярное выражение, кроме 50 строк строкового кода синтаксического анализа, но, возможно, это личное дело.

Сверхудлинное регулярное выражение вырастает органично и становится монстрами.

Я думаю, они могут, но это, вероятно, проблема с кодом, в котором они живут, и не сосредоточиться. Если сложность исходных данных увеличивается, вы, вероятно, нужно следить, нужно ли более выразительным решение (возможно, генератор синтаксических анализаторов, как ANTLR)

Они глубоко не интуитивным.

Это язык, соответствующий шаблону. Я бы сказал, что они довольно интуитивно понятны в этом контексте.

Как я мог улучшить читаемость вышеуказанного кода?

Не уверен, кроме использования регулярного выражения.

Есть ли лучший способ сделать это? Класс Util, который решает эту проблему элегантно.

Упоминается выше, java.util.Scanner.

Где вы рисуете линию между использованием regEx и кодированием чего-то похожего на то, что я написал выше?

Лично я использую регулярное выражение для чего-либо достаточно простого.

Как повысить читаемость/ремонтопригодность регистров?

Подумайте внимательно, прежде чем расширять, проявите особую осторожность, чтобы подробно комментировать код и регулярное выражение, чтобы было ясно, что вы делаете.

Answer 6

вы могли бы использовать этот класс для того, чтобы упростить цикл:

public class StringIterator implements Iterator<Character> { 

    private final char[] chars; 
    private int i; 

    private StringIterator(char[] chars) { 
     this.chars = chars; 
    } 

    public boolean hasNext() { 
     return i < chars.length; 
    } 

    public Character next() { 
     return chars[i++]; 
    } 

    public void remove() { 
     throw new UnsupportedOperationException("Not supported."); 
    } 

    public static Iterable<Character> of(String string) { 
     final char[] chars = string.toCharArray(); 

     return new Iterable<Character>() { 

      @Override 
      public Iterator<Character> iterator() { 
       return new StringIterator(chars); 
      } 
     }; 
    } 
} 

Теперь вы можете переписать так:

for (int i = 0; i < str.length(); i++){ 
    char cChar = str.charAt(i); 
    ... 
} 

с:

for (Character cChar : StringIterator.of(str)) { 
    ... 
} 

мои 2 цента

BTW Этот раздел s также может использоваться повторно в другом контексте.

Answer 7

Я не слишком сумасшедший по поводу регулярного выражения, но это похоже на случай, когда они действительно упростят ситуацию. То, что вы, возможно, захотите сделать, это поместить их в самый маленький метод, который вы можете разработать, назвать его метко, а затем поместить весь управляющий код в другой метод.

Например, если вы закодировали метод «Grab block of numbers или letters», вызывающий объект был бы очень простым, прямолинейным, просто распечатывая результаты каждого вызова, и метод, который вы вызывали, был бы хорошо -defined, так что намерение регулярного выражения было бы ясным, даже если бы вы ничего не знали о синтаксисе, и метод был бы ограничен, поэтому люди вряд ли могли бы его испортить с течением времени.

Проблема заключается в том, что инструменты регулярных выражений настолько просты и хорошо адаптированы к этому использованию, что для этого трудно обосновать вызов метода.

Answer 8

Поскольку никто, кажется, не разместил правильный код, я дам ему выстрел.

Первая версия без регулярного выражения. Обратите внимание, что я использую StringBuilder для накопления в зависимости от того, какой тип символа был замечен последним (цифрой или без цифр). Если состояние изменяется, я выгружаю его содержимое в список и запускаю новый StringBuilder. Таким образом, последовательные не-цифры группируются так же, как и последовательные цифры.

static List<String> digitsAsElements(String str) { 
    StringBuilder collector = new StringBuilder(); 

    List<String> output = new ArrayList<String>(); 
    boolean lastWasDigit = false; 
    for (int i = 0; i < str.length(); i++) { 
     char cChar = str.charAt(i); 

     boolean isDigit = Character.isDigit(cChar); 
     if (isDigit != lastWasDigit) { 
      if (collector.length() > 0) { 
       output.add(collector.toString()); 
       collector = new StringBuilder(); 
      } 
      lastWasDigit = isDigit; 
     } 
     collector.append(cChar); 
    } 
    if (collector.length() > 0) 
     output.add(collector.toString()); 

    return output; 
} 

Теперь версия с регулярным выражением. Это в основном тот же код, который был опубликован Juha S., но регулярное выражение действительно работает.

private static final Pattern DIGIT_OR_NONDIGIT_STRING = 
     Pattern.compile("(\\d+|[^\\d]+)"); 
static List<String> digitsAsElementsR(String str) { 
    // Match a consecutive series of digits or non-digits 
    final Matcher matcher = DIGIT_OR_NONDIGIT_STRING.matcher(str); 
    final List<String> output = new ArrayList<String>(); 
    while (matcher.find()) { 
     output.add(matcher.group()); 
    } 
    return output; 
} 

Один из способов, с помощью которых я пытаюсь сохранить свои регулярные выражения, является их именами.Я думаю, что DIGIT_OR_NONDIGIT_STRING очень хорошо передает, что я (программист) думаю, что он это делает, и тестирование должно убедиться, что оно действительно делает то, что он должен делать.

public static void main(String[] args) { 
    System.out.println(digitsAsElements("34A312O5MNI444123A")); 
    System.out.println(digitsAsElementsR("34A312O5MNI444123A")); 
} 

печатает:

 
[34, A, 312, O, 5, MNI, 444123, A] 
[34, A, 312, O, 5, MNI, 444123, A]