У меня есть сценарий, который анализирует имена файлов телевизионных эпизодов (например, show.name.s01e02.avi), берет имя эпизода (из API www.thetvdb.com) и автоматически переименовывает их во что-то более приятное (Show Name - [01x02 ] .avi)
Скрипт работает нормально, пока вы не попробуете использовать его для файлов с отображаемыми именами Unicode (о чем я никогда особо не задумывался, поскольку все файлы, которые у меня есть, на английском языке, так что в основном почти все попадают в [a-zA-Z0-9'\-])
Как разрешить регулярным выражениям совпадать с акцентированными символами и т.п.? В настоящее время раздел конфигурации регулярного выражения выглядит так ..
config['valid_filename_chars'] = """0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ!@£$%^&*()_+=-[]{}"'.,<>`~? """
config['valid_filename_chars_regex'] = re.escape(config['valid_filename_chars'])
config['name_parse'] = [
# foo_[s01]_[e01]
re.compile('''^([%s]+?)[ \._\-]\[[Ss]([0-9]+?)\]_\[[Ee]([0-9]+?)\]?[^/]*$'''% (config['valid_filename_chars_regex'])),
# foo.1x09*
re.compile('''^([%s]+?)[ \._\-]\[?([0-9]+)x([0-9]+)[^/]*$''' % (config['valid_filename_chars_regex'])),
# foo.s01.e01, foo.s01_e01
re.compile('''^([%s]+?)[ \._\-][Ss]([0-9]+)[\.\- ]?[Ee]([0-9]+)[^/]*$''' % (config['valid_filename_chars_regex'])),
# foo.103*
re.compile('''^([%s]+)[ \._\-]([0-9]{1})([0-9]{2})[\._ -][^/]*$''' % (config['valid_filename_chars_regex'])),
# foo.0103*
re.compile('''^([%s]+)[ \._\-]([0-9]{2})([0-9]{2,3})[\._ -][^/]*$''' % (config['valid_filename_chars_regex'])),
]






Используйте поддиапазон [\u0000-\uFFFF] по своему усмотрению.
Вы также можете использовать флаг компиляции re.UNICODE. Документы говорит, что если UNICODE установлен, \w будет соответствовать символам [0-9_] плюс все, что классифицируется как буквенно-цифровое в базе данных свойств символов Unicode.
См. Также http://coding.derkeiler.com/Archive/Python/comp.lang.python/2004-05/2560.html.
\ X, кажется, доступен как общий символ слова в некоторых языках, он позволяет вам сопоставлять один символ независимо от того, сколько байтов он занимает. Может быть полезно.
В «Освоении регулярных выражений» от Джеффри Фридла (отличная книга) упоминается, что вы можете использовать \ p {Letter}, который будет соответствовать материалу Unicode, который считается буквой.
Модуль Python re не поддерживает \ p {Letter} или \ X. Однако новая реализация регулярного выражения на PyPI делает.
\X этого модуля сломан; они неправильно поняли стандарт. Вы не можете просто использовать \PM\pM*, иначе вы ошибетесь. Рассмотрим строку "\r\r\n\x{301}A\x{301}". соответствующее приложение находит следующие 4 совпадения для \X: 1 CP U + 000D, 2 CP U + 000D U + 000A, 1 CP U + 0301 и 2 CP U + 0041 U + 0301. Сломанный \PM\pM* также находит 4 совпадения, но неправильные: 1 CP U + 000D, 1 CP U + 000D, 2 CP U + 000A U + 0301 и 2 CP U + 0041 U + 0301. Вы ДОЛЖЕН не разбиваете CRLF и не размещаете Знаки на каких-либо кодовых точках \P{Grapheme_Base}.
Определение \ X было основано на содержимом этого: regular-expressions.info/unicode.html Я посмотрю, смогу ли я это исправить.
Первоначальная идея кластера графем была немного запутана в нескольких вещах, поэтому первые люди, которые перешли на \X, в конечном итоге сделали это немного неправильно. Текущие реализации ICU и Perl все делают правильно и даже используют расширенные определения кластеров графем: попробуйте perl5.12.0 -le 'printf "%d %v04X\n", length, $_ for "\r\r\n\x{301}A\x{301}" =~ /\X/g' или более позднюю версию, чтобы увидеть улучшенные ответы.
@tchrist: Кажется, сейчас это исправлено (или никогда не ломалось). python -c'import regex as re; print(re.findall(u"\X", u"\r\r\n\u0301A\u0301"))' печатает ожидаемые результаты: [u'\r', u'\r\n', u'\u0301', u'A\u0301']
@ J.F.Sebastian Я знаю, что это исправили. Я долго переписывался с автором. Он классный.
\p{Letter}поддерживается не всеми механизмами регулярных выражений, а в случае Python он не поддерживается в модулеreпо умолчанию. Поддерживается только в пакетеregex.