Разделитель escape-пути в регулярном выражении

Мне нужно написать регулярное выражение, которое находит файлы javascript, соответствующие

<anypath><slash>js<slash><anything>.js

Например, он должен работать для обоих:

  • c: \ mysite \ js \ common.js (Windows)
  • /var/www/mysite/js/common.js (UNIX)

Проблема в том, что разделитель файлов в Windows не экранируется должным образом:

pattern = Pattern.compile(
     "^(.+?)" + 
     File.separator +
     "js" +
     File.separator +
     "(.+?).js$" );

Метание

java.util.regex.PatternSyntaxException: Illegal/unsupported escape sequence

Есть ли способ использовать обычное регулярное выражение, которое работает как в системах Windows, так и в UNIX?

Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
Как вычислять биты и понимать побитовые операторы в Java - объяснение с примерами
Как вычислять биты и понимать побитовые операторы в Java - объяснение с примерами
В компьютерном программировании биты играют важнейшую роль в представлении и манипулировании данными на двоичном уровне. Побитовые операции...
Поднятие тревоги для долго выполняющихся методов в Spring Boot
Поднятие тревоги для долго выполняющихся методов в Spring Boot
Приходилось ли вам сталкиваться с требованиями, в которых вас могли попросить поднять тревогу или выдать ошибку, когда метод Java занимает больше...
Полный курс Java для разработчиков веб-сайтов и приложений
Полный курс Java для разработчиков веб-сайтов и приложений
Получите сертификат Java Web и Application Developer, используя наш курс.
12
0
18 338
5
Перейти к ответу Данный вопрос помечен как решенный

Ответы 5

Ответ принят как подходящий

Подходит ли Pattern.quote(File.separator)?

Обновлено: это доступно в Java 1.5 или новее. Для 1.4 вам нужно просто экранировать символ разделителя файлов:

"\\" + File.separator

Экранирование знаков препинания ничего не сломает, но экранирование букв или цифр безоговорочно либо изменит их на их особое значение, либо приведет к PatternSyntaxException. (Спасибо Алан М за указание на это в комментариях!)

Отлично, как жаль, что он доступен только с Java 1.5+ (мне все еще нужно, чтобы он работал в 1.4)

Guido 28.10.2008 13:39

начиная с Java 7, вы можете использовать FileSystems.getDefault().getSeparator() вместо File.separator

herau 14.10.2015 11:52

@herau Есть разница?

Tomalak 14.10.2015 11:56

@Tomalak В случае поставщика по умолчанию этот метод возвращает тот же разделитель, что и File.separator. Однако это может быть полезно, когда вы работаете с другим провайдером.

herau 14.10.2015 12:23

Разве вы не можете просто использовать обратную косую черту, чтобы избежать разделителя пути, например:

pattern = Pattern.compile(
     "^(.+?)\\" + 
     File.separator +
     "js\\" +
     File.separator +
     "(.+?).js$" );

Почему бы тебе не сбежать от File.separator:

... +
"\\" + File.separator +
...

чтобы соответствовать требованиям Pattern.compile? Я надеюсь, что «/» (случай unix) обрабатывается как одиночный «/».

Я протестировал ответ gimel в системе Unix - установка "\\" + File.separator работает нормально - полученный "/" в шаблоне правильно соответствует одному "/"

Is there any way to use a common regular expression that works in both Windows and UNIX systems ?

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

pattern = Pattern.compile(
    "^(.+?)" + 
    "[/\\\\]" +
    "js" +
    "[/\\\\]" +
    "(.+?)\\.js$" );

Это безопасно, потому что ни Windows, ни Unix не допускают использование этих символов в имени файла или каталога.

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

Christopher Lörken 29.01.2015 19:56

На самом деле, я думаю, что Linux не будет проблем с «посреди имени файла или каталога» (и не будет интерпретировать его как имеющее какое-либо отношение к каталогам); это некоторые комбинации пользователи и файловые системы запрещают это, AFAIK. (я определенно не хочет никаких файлов или каталогов с такими именами.)

SamB 15.06.2019 05:38

Другие вопросы по теме