Используя регулярные выражения для парсинга HTML: почему нет?
Согласно источникам обертки ( https://bitbucket.org/snakemake/snakemake-wrappers/src/bd3178f4b82b1856370bb48c8bdbb1932ace6a19/bio/picard/markduplicates/wrapper.py?at=master-ampffile_view) ), он использует cmdline:
from snakemake.shell import shell
shell("picard MarkDuplicates {snakemake.params} INPUT={snakemake.input} "
"OUTPUT={snakemake.output.bam} METRICS_FILE={snakemake.output.metrics} "
"&> {snakemake.log}")
Таким образом, вы можете передать любые параметры, используя раздел params: "smth".
Если вы проверите picard исключаемые источники сценариев:
cat `which picard`
Вы найдете:
...
pass_args=""
for arg in "$@"; do
case $arg in
'-D'*)
jvm_prop_opts="$jvm_prop_opts $arg"
;;
'-XX'*)
jvm_prop_opts="$jvm_prop_opts $arg"
;;
'-Xm'*)
jvm_mem_opts="$jvm_mem_opts $arg"
;;
*)
if [[ ${pass_args} == '' ]] #needed to avoid preceeding space on first arg e.g. ' MarkDuplicates'
then
pass_args="$arg"
else
pass_args="$pass_args \"$arg\"" #quotes later arguments to avoid problem with ()s in MarkDuplicates regex arg
fi
;;
esac
done
...
Так что я предполагаю, что это должно работать:
rule markdups:
input:
"in.bam",
output:
bam = "out.bam",
metrics = "metrics.tmp",
params:
"-Xmx10000m"
wrapper:
"0.31.0/bio/picard/markduplicates"
10 ответов
Весь парсинг HTML не возможен с регулярными выражениями, так как он зависит от соответствия открытию и закрывающему тэгу, который не возможен с regexps.
Регулярные выражения могут только соответствовать регулярные языки , но HTML контекстно-свободный язык и не регулярный язык (Как @StefanPochmann указанный, регулярные языки также контекстно-свободны, таким образом контекстно-свободный не обязательно означает не регулярный). Единственной вещью, которую можно сделать с regexps на HTML, является эвристика, но это не будет работать над каждым условием. Должно быть возможно представить файл HTML, который будет подобран неправильно любым регулярным выражением.
Регулярные выражения не достаточно мощны для такого языка как HTML. Несомненно, существуют некоторые примеры, где можно использовать регулярные выражения. Но в целом это не подходит для парсинга.
"Это зависит" все же. Это верно, что regexes не делают и не могут проанализировать HTML с истинной точностью по всем причинам, приведенным здесь. Если, однако, последствия понимания превратно это (такие как не обработка вложенных тегов) незначительно, и если regexes суперудобны в Вашей среде (такой как тогда, когда Вы взламываете Perl), идти вперед.
предположим Вы, о, возможно, анализируете веб-страницы, которые связываются с Вашим сайтом - возможно, Вы нашли их с поиском ссылки Google - и Вы хотите быстрый способ добраться, общее представление о контексте окружают Вашу ссылку. Вы пытаетесь выполнить немного отчета, который мог бы предупредить Вас для соединения спама, чего-то как этот.
В этом случае, misparsing некоторые документы не будет грандиозным предприятием. Никто, но Вы будете видеть ошибки, и если Вы очень удачливы, что будут немногие достаточно, что можно продолжить индивидуально.
я предполагаю, что говорю, что это - компромисс. Иногда реализация или использование корректного синтаксического анализатора - столь легкий, как это может быть - не могли бы стоить проблемы, если точность не очень важна.
Просто быть осторожным с Вашими предположениями. Я могу думать о нескольких способах, которыми может иметь неприятные последствия regexp ярлык, при попытке проанализировать что-то, что покажут на публике, например.
Я полагаю, что ответ заключается в теории вычисления. Чтобы язык был проанализирован с помощью regex, это должно быть по определению "регулярным" ( ссылка ). HTML не является регулярным языком, поскольку он не соответствует многим критериям для регулярного языка (очень, чтобы сделать со многими уровнями вложения, свойственного от кода HTML). Если бы Вы интересуетесь теорией вычисления, я рекомендовал бы этот книга.
Регулярные выражения не были разработаны для обработки вложенной структуры тегов, и она на высоте сложная (в худшем случае, невозможна) для обработки всех возможных пограничных случаев, которые Вы получаете с реальным HTML.
Проблема состоит в том, что большинство пользователей, которые задают вопрос, который имеет отношение к HTML и regex, делает это, потому что они не могут найти собственный regex, который работает. Тогда нужно думать, было ли все легче при использовании DOM или синтаксического анализатора SAX или чего-то подобного. Они оптимизированы и созданы в целях работы с подобным структурам документа XML.
Несомненно, существуют проблемы, которые могут быть решены легко с регулярными выражениями. Но акцент находится на легко .
, Если Вы просто хотите найти все URL, которые похожи http://.../, Вы соглашаетесь с regexps. Но если Вы хотите найти все URL, которые находятся в элемент, который имеет класс 'mylink' Вы, вероятно, лучшее использование соответствующий синтаксический анализатор.
Поскольку существует много способов "завинтить" HTML, который браузеры будут рассматривать довольно либеральным способом, но он приложил бы некоторые усилия для репродуцирования либерального поведения браузера покрыть все случаи регулярными выражениями, таким образом, regex неизбежно перестанет работать на некоторых особых случаях, и это возможно представило бы серьезные разрывы безопасности в системе.
Насколько парсинг идет, регулярные выражения могут быть полезными в "лексическом анализе" (лексический анализатор) этап, где вход разломан на маркеры. Это менее полезно в фактической "сборке дерево синтаксического анализа" этап.
Для синтаксического анализатора HTML, я ожидал бы, что это только примет правильно построенный HTML, и это требует возможностей снаружи, что регулярное выражение может сделать (они не могут "рассчитать" и удостовериться, что данное число вводных элементов сбалансировано тем же числом заключительных элементов).
Две быстрых причины:
- запись regex, который может противостоять злонамеренному входу, трудна; путь тяжелее, чем использование предварительно созданного инструмента
- запись regex, который может работать со смешной разметкой, с которой Вы неизбежно застрянете, тверд; путь тяжелее, чем использование предварительно созданного инструмента
Относительно пригодности regexes для парсинга в целом: они не подходят. Вы когда-либо видели виды regexes, необходимо ли было бы проанализировать большинство языков?
Для quickВґnВґdirty regexp сделает прекрасный. Но фундаментальная вещь знать состоит в том, что это невозможно для построения regexp, который будет правильно HTML синтаксического анализа.
причина состоит в том, что regexps can’t обрабатывают arbitarly вложенные выражения. См. , регулярные выражения могут использоваться для соответствия вложенным шаблонам?