2012-04-07 3 views
5

У меня эта картина написанаШаблон Regex, который не соответствует определенным расширениям?

^.*\.(?!jpg$|png$).+$ 

Однако есть проблема - эта модель соответствует file.name.jpg (2 точки)

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

ответ

10

Это должно работать: ^.*\.(?!jpg$|png$)[^.]+$

+0

отличная работа! отлично – yash

3

Использовать os.path для правильного разделения вверх по FilePath на компоненты для облегчения синтаксического анализа:

filepath, filename = os.path.split(str) 
basename, extension = os.path.splitext(filename) 

if exension[1:] in ['jpg', 'png']: 
    # The extension matches 

Попробуйте это регулярное выражение (не делать это делает прямо противоположное тому, что вы хотите сделать.):

\.(jpg|png)([^\.]|$) 
+0

У меня нет доступа к Python, это механизм регулярных выражений Python, но у меня есть только доступ к конфигурационному файлу JSON для размещения регулярного выражения для программы Python. Я удалил тег Python, чтобы предотвратить путаницу. –

+0

См. Мое редактирование. Я думаю, что это должно работать – Blender

+0

Ваше регулярное выражение выглядит так, будто оно пытается исключить строки, которые * содержат * '.jpg.' или' .png.', но я считаю, что идея состоит в том, чтобы исключить все, что * заканчивается * с '.jpg или '.png'. Регулярное выражение OP не работает, потому что и lookahead, и final '. + $' Могут совпадать после первого '.' В 'file.name.jpg'. Изменяя это на '[^.] + $', Как это делал @bereal, заставляет lookahead применяться только к конечной точке любой последовательности. –

0

Пожалуйста, попробуйте

 
    .*\.(jpg$|png$) 

Это будет правильно соответствовать на filename.jpg. вы пытаетесь выяснить, как сделать файлы ANY .jpg, даже если имя файла имеет 2 или более точек в нем, будет работать нормально.
При использовании скрипта python убедитесь, что вы используете правильный тип split. разный тип split viz rsplit (правый сплит) и lsplit (левый сплит).

+0

У вас есть обратное: регулярное выражение НЕ должно соответствовать 'filename.jpg' ИЛИ' file.name.png'. 'filename.txt' или' file.name.foo' в порядке, я полагаю. –

1

Похоже, вы чуть было его:

.*\.(?!jpg$|png$)[^.]+ 

По моим тестам (в Java), я получаю эти результаты:

file.jpg - false 
file.png - false 
file.name.jpg - false 
file.name.png - false 
file.gif - true 
file.name.gif - true 
file.jpg.gif - true 
file.jpge - true 

Если это не то, что вы хотели мольбы обновить ваш вопрос твои ожидания.

1

Если вы только заботиться о том, что строка не заканчивается .jpg или .png, вы можете использовать это:

^.+$(?<!\.jpg)(?<!\.png) 

^.+ не является строго необходимым, но в зависимости от того, как JSON парсер закодирован вас может потребоваться заставить регулярное выражение потреблять всю строку. Если вы используете регулярное выражение для других валидаций, а также, вы можете что-то более сложное, как:

^\w+(?:\.\w+)+$(?<!\.jpg)(?<!\.png) 

Вы, вероятно, пытались использовать (?<!\.jpg|\.png), который не будет работать, потому что регулярное выражение вкус Python является одним из самых когда дело доходит до lookbehinds. PHP и Ruby 1.9+ приняли бы это, потому что каждая из альтернатив имеет фиксированную длину. Они даже не должны быть такой же длины; (?<!\.jpg|\.jpeg|\.png) будет работать, тоже. Просто не пытайтесь разделить точку, как в (?<!\.(?:jpg|jpeg|png)); чередование должно быть на верхнем уровне lookbehind.

Java будет принимать версию с факторингом, потому что во время компиляции требуется немного больше работы, чтобы определить максимальное количество символов, которые может потребоваться для поиска. Выражение lookbehind должно быть довольно простым, но оно не может использовать кванторы + или *. Наконец, в .NET и JGSoft нет никаких ограничений на lookbehind. Но Python делает очень простомысленную попытку выяснить точное количество символов, которые нужно искать в lookbehind, генерируя это загадочное сообщение об ошибке, когда он терпит неудачу.

+0

Спасибо, отличный ответ. –