Я хочу проанализировать массив из пользовательского протокола "ключ-значение". Это похоже на это
RESPONSE GAMEINFO OK
NAME: "gamelobby"
PLAYERS: "alice", "bob", "hodor"
FLAGS: 1, 2, 3
В Java строка выглядит так (в ней используется CRLF как разрыв строки):
RESPONSE GAMEINFO OK\\r\\nNAME: \"gamelobby\"\\r\\nPLAYERS: \"alice\", \"bob\", \"hodor\"FLAGS: 1, 2, 3\\r\\n
Я хочу запечатлеть "alice", "bob", "hodor"
как есть. Поэтому я использовал это регулярное выражение, которое было протестировано в Sublime Text и на regex101.com (ключи нечувствительны к регистру)
(?<=(?i:PLAYERS): )([A-Za-z0-9\s\.,:;\?!\n"_-]*)(?=\r\n)
Это снимок экрана из Sublime Text (примечание: я не упомянул здесь \ r):
Когда я пытаюсь захватить группу, я тоже получаю следующую строку:
Pattern p = Pattern.compile("(?<=(?i:"+key+"): )([A-Za-z0-9\\s\\.,:;\\?!\\n\"_-]*)(?=\\r\\n)");
Matcher matcher = p.matcher(message);
matcher.find();
String value = new String();
try {
value = matcher.group(); // = "\"alice\", \"bob\", \"hodor\"\\r\\nFLAGS: 1, 2, 3"
} ...
ПРИМЕЧАНИЕ: \"
или \\\"
, похоже, не имеют значения.
Почему FLAGS: 1, 2, 3
записывается до \\r\\n
, но не в строке выше? Возможен ли позитивный взгляд назад и вперед? Какой просмотр вперед / назад оценивается в первую очередь?
РЕДАКТИРОВАТЬ: определение строкового массива
values = string*("," WSP string)
string = DQUOTE *(ALPHA / DIGIT / WSP / punctuation / "\n") DQUOTE
punctuation = "." / ":" / "," / ";" / "?" / "!" / "-" / "_"
PLAYERS
, вам следует удалить\s
и\n
из вашего регулярного выражения и, вероятно, заменить на\h
, если вы используете Java 8. - person nhahtdh   schedule 03.02.2015\n
и строковых массивов. - person joschuck   schedule 03.02.2015\\r\\n
. - person joschuck   schedule 03.02.2015,\s
- person joschuck   schedule 03.02.2015\s
, кстати, содержит новую строку. Пожалуйста, составьте правильный список пробелов. - person nhahtdh   schedule 03.02.2015\s
и\n
.(?<=(?i:PLAYERS): )([A-Za-z0-9\n \.,:;\?!"_-]*)(?=\r\n)
правильно.\s
захвачено\r\n
до положительного просмотра. Интересный. Вам также не нужен предложенный @bgoldst не жадный множитель, который не был бы изящным решением думаю. - person joschuck   schedule 03.02.2015