Entre os programadores de qualquer experiência, isso é geralmente considerado uma má ideiatm para tentar analisar o HTML com expressões regulares. A ideia é ruim? Aparentemente levou um usuário do Stack Overflow à beira da loucura:
O senhor não pode analisar [X]HTML com regex. Porque o HTML não pode ser analisado pelo regex. A regex não é uma ferramenta que possa ser usada para analisar corretamente o HTML. Como já respondi muitas vezes em perguntas sobre HTML e regex aqui, o uso de regex não permitirá que o senhor consuma HTML.
As expressões regulares são uma ferramenta que não é suficientemente sofisticada para entender as construções empregadas pelo HTML. O HTML não é uma linguagem regular e, portanto, não pode ser analisado por expressões regulares. As consultas Regex não estão equipadas para decompor o HTML em suas partes significativas. tantas vezes, mas não estou conseguindo. Mesmo as expressões regulares irregulares aprimoradas usadas pelo Perl não estão à altura da tarefa de analisar o HTML. O senhor nunca me fará ceder. O HTML é uma linguagem de complexidade suficiente para não ser analisada por expressões regulares.
Nem mesmo Jon Skeet consegue analisar HTML usando expressões regulares. Toda vez que o senhor tenta analisar o HTML com expressões regulares, a criança profana chora o sangue de virgens e os hackers russos derrubam seu aplicativo da Web. A análise de HTML com regex convoca almas contaminadas para o reino dos vivos. HTML e regex andam juntos como amor, casamento e infanticídio ritual. O <center> não pode segurar, é tarde demais. A força da regex e do HTML juntos no mesmo espaço conceitual destruirá sua mente como se fosse massa de vidraceiro. Se o senhor analisar o HTML com regex, estará cedendo a Eles e a seus modos blasfemos que nos condenam a um trabalho desumano para Aquele cujo Nome não pode ser expresso no Plano Básico Multilíngue, ele vem.
(O unicode action in the post, não mostrada aqui, é a melhor parte da brincadeira).
É isso mesmo, se o senhor tentar analisar HTML com expressões regulares, estará sucumbindo às tentações do deus das trevas Cthulhu’s … er … código.
Tudo isso é muito divertido, mas a advertência aqui é apenas parcialmente irônica e nasceu do uma frustração muito real.
Já ouvi esse argumento antes. Normalmente, eu o ouço como justificativa para ver algo como o código a seguir:
# pull out data between <td> tags ($table_data) = $html =~ /<td>(.*?)</td>/gis;“Mas ele funciona!”, dizem.
“É fácil!”
“É rápido!”
“Ele fará o trabalho muito bem!”
Eu os repreendo por não serem preguiçosos. Como programador, o senhor precisa ser preguiçoso. A análise de HTML é um problema resolvido. O senhor não precisa resolvê-lo. O senhor só precisa ser preguiçoso. Seja preguiçoso, use o CPAN e use HTML::Sanitizer. Isso tornará sua codificação mais fácil. Isso deixará seu código mais fácil de manter. O senhor não precisará ficar sentado codificando expressões regulares à mão. Seu código será mais robusto. O senhor não precisará corrigir bugs toda vez que o HTML quebrar sua regex de baixa qualidade
Para muitos programadores novatos, há algo extraordinariamente sedutor em analisar o HTML à maneira de Cthulhu, em vez de, sabe, usar uma biblioteca como uma pessoa sã. Isso significa que essa discussão é reaberta quase todos os dias no Stack Overflow. A postagem acima, de cinco anos atrás, poderia ser uma discussão do ontem. Acho que podemos perdoar um lapso momentâneo de razão, dadas as circunstâncias.
Como eu disse, esse é um fenômeno bem compreendido na maioria dos círculos de programação. No entanto, fiquei surpreso ao ver alguns programadores experientes nos comentários do metafilter na verdade defende o uso de expressões regulares para analisar HTML. Ou seja, eles atenderam ao pedido do Chamado de Cthulhu … e gostou isso.
Muitos programas não precisarão, nem deverão, antecipar todo o universo do HTML durante a análise. Na verdade, projetar um programa para fazer isso pode muito bem ser uma abordagem completamente equivocada, se isso mudar um programa de um script de poucas linhas para um programa de nível comercial à prova de balas, que leva muito mais tempo para ser codificado e suportado adequadamente. O gasto de recursos deve ser sempre (ops, com muita frequência, eu também generalizei demais) considerado ao criar uma solução programática.
Além disso, os limites rígidos nem sempre precisam ser uma limitação orientada por HTML. Eles podem ser tão simples quanto “trabalhe com esses conjuntos de páginas da Web”, “trabalhe com esses dados dessas páginas da Web”, “trabalhe para 98% dos usuários 98% do tempo” ou até mesmo “OMG, temos que fazer isso funcionar na próxima hora, faça o melhor que puder”.
Vivemos em um mundo repleto de desenvolvedores de PHP novatos que fazem a primeira coisa que lhes vem à cabeça, com mais surgindo todos os dias. O que temos aqui é um problema de educação contínua. O verdadeiro inimigo não são as expressões regulares (ou, por falar nisso, goto), mas sim a ignorância. O único crime que está sendo cometido é não saber quais são as alternativas.
Portanto, embora eu possa tentar de analisar HTML usando expressões regulares em determinadas situaçõesEu entro sabendo disso:
- Geralmente é uma má ideia.
- A menos que o senhor tenha disciplina e imponha condições muito rígidas ao que está fazendo, a correspondência de HTML com expressões regulares rapidamente se transforma em loucura, exatamente como Cthulhu gosta.
- Eu tinha motivos bons, racionais e (semi) defensáveis para escolher expressões regulares nesse cenário específico.
É considerado uma boa forma exigir que as expressões regulares sejam consideradas proibidas, totalmente fora dos limites para o processamento de HTML, mas acho que isso é tão errado quanto exigir que o todas as tarefas triviais de processamento de HTML sejam tratadas por um mecanismo de análise completo. É mais importante entender as ferramentas, seus pontos fortes e fracos, do que se submeter a um dogmatismo instintivo.
Portanto, sim, de modo geral, o é uma má ideia usar expressões regulares ao analisar HTML. Deveríamos estar ensinando isso aos desenvolvedores neófitos, com certeza. Mesmo que esse seja um trabalho aparentemente interminável. Mas também deveríamos ensinar a eles a diferença real entre análise de HTML e a simples conveniência de processar algumas cadeias de caracteres. E como saber qual é a abordagem correta para a tarefa em questão.
Seja qual for o método que o senhor escolher, apenas não deixe a tag <cthulhu> aberta, pelo bem da humanidade.