Analisadores HTML e XML em Ruby: Uma comparação com base na carga de trabalho

As versões atuais e as versões de Ruby suportadas não foram verificadas em tempo real para este rascunho, pelo que as recomendações sensíveis ao estado requerem uma verificação no momento da publicação.

• Escolha o Nokogiri como ponto de partida prático para HTML estático ou imperfeito e para trabalho geral com árvores XML.
• Escolha o Ox quando a análise de XML, a escrita, o processamento ao estilo SAX ou a serialização de objetos forem fundamentais.
• Escolha o LibXML Ruby quando o seu pipeline de XML necessitar de XPath, além de validação ou capacidades XSLT.
• Considere o Oga e o Hpricot como alternativas que exigem uma análise especialmente cuidadosa em termos de compatibilidade e manutenção.
• Utilize o Selenium apenas quando a renderização, cliques, deslocamento, formulários ou o estado do navegador façam parte da tarefa.

Essa divisão baseada na carga de trabalho é mais útil do que declarar um conjunto de analisadores HTML e XML em Ruby como universalmente o melhor.

Os mesmos critérios aplicam-se a todas as seis ferramentas. Um asterisco indica evidência fornecida que ainda necessita de confirmação na documentação oficial atual.

A categoria de análise de HTML do Ruby Toolbox oferece um contexto útil sobre os pacotes, mas os dados do diretório, por si só, não permitem determinar a compatibilidade atual nem estabelecer uma classificação universal.

Classifique os dados de entrada antes de comparar APIs. Verifique se se trata de HTML ou XML, se necessita de recuperação tolerante ou de falha estrita, se cabe na memória e quais as funcionalidades de consulta ou transformação necessárias.

Adicione restrições operacionais: compilação nativa, bibliotecas do sistema, tempo de execução do Ruby, imagem do contentor e destino de implementação. Por fim, verifique se os bytes contêm os dados pretendidos. Caso contrário, a recuperação, a autenticação ou a renderização no navegador têm de ocorrer antes de os analisadores HTML e XML do Ruby poderem extraí-los.

O HTML da Web é frequentemente imperfeito. Um analisador HTML em Ruby deve recuperar uma árvore utilizável a partir de tags em falta, aninhamentos irregulares e fragmentos, mantendo as consultas previsíveis. O Nokogiri é suportado pelo código-fonte para CSS e XPath e para lidar com HTML mal formado, tornando-o uma primeira experiência sensata.

O XML tem um contrato diferente. A estrutura, os namespaces e as regras de validação podem ser requisitos de negócio, pelo que uma recuperação silenciosa pode ser pior do que uma falha evidente. Escolha um modo focado em XML e defina como os erros são apresentados.

A recuperação de dados é um processo separado. Cookies, autenticação, redirecionamentos e Ajax determinam qual o código de marcação que recebe. Se a resposta contiver o nó alvo, analise-o diretamente. Se o JavaScript criar esse nó posteriormente, renderize primeiro e analise o DOM resultante.

Uma árvore DOM carrega o documento num grafo de nós na memória. É conveniente para a navegação entre pais, irmãos ou descendentes e para consultas repetidas. O uso de memória aumenta com o tamanho do documento e com a representação em árvore do analisador.

Uma interface do tipo SAX ou «reader» emite eventos à medida que o analisador avança. É adequada para feeds de grande dimensão, transformações do tipo «apenas acrescentar» e pipelines que podem produzir registos sem reter o documento na íntegra. A desvantagem é a gestão do estado: o seu manipulador deve acompanhar explicitamente o contexto, os namespaces e os registos parciais.

Entre estes analisadores Ruby de HTML e XML, os dados fornecidos indicam que o processamento SAX é atribuído ao Ox e várias interfaces não-DOM ao Nokogiri e ao LibXML Ruby. Verifique as APIs exatas e avalie o pico de memória residente com fixtures antes de projetar em torno delas.

Para a extração, decida se a equipa prefere seletores CSS, XPath ou ambos. O CSS é conciso para padrões de classes e atributos; o XPath é frequentemente melhor para condições de texto, eixos e XML sensível a namespaces. Uma análise focada no XPath em comparação com os seletores CSS pode impedir que o estilo dos seletores se torne uma arquitetura acidental.

No caso do XML, verifique separadamente o registo do espaço de nomes, a validação da DTD ou do esquema, o XSLT e a comunicação de erros. Não deduza uma funcionalidade a partir de outra. A instalação merece o mesmo rigor: as extensões nativas podem melhorar a capacidade, mas podem acrescentar trabalho ao compilador, às bibliotecas do sistema ou à compilação de imagens.

Registe a versão da gem, a versão do Ruby, as versões das bibliotecas nativas e a data da revisão na decisão. Volte a executar os testes de fixture durante as atualizações, em vez de considerar «instalado com sucesso» como prova de compatibilidade.

O Nokogiri é o ponto de partida mais abrangente, apoiado em código-fonte, neste conjunto de analisadores HTML e XML para Ruby. Analisa HTML e XML, disponibiliza consultas CSS e XPath e consegue construir uma árvore útil a partir de HTML imperfeito. Essa combinação adapta-se à extração de dados da Web comum em Ruby, à limpeza de feeds, à inspeção de documentos e a transformações que necessitam de acesso aleatório aos nós.

require "nokogiri"

html = "<article><h1>Parser choice</h1><a href='/next'>Next</a></article>"
doc = Nokogiri::HTML.parse(html)

title = doc.at_css("article h1")&.text&.strip
next_url = doc.at_xpath("//a[normalize-space()='Next']")&.attr("href")

As chamadas de navegação segura são importantes porque os seletores falham em produção, mesmo quando funcionaram numa amostra. Decida se um campo em falta significa nilum registo ignorado ou um erro grave e, em seguida, codifique essa escolha nos testes.

O Nokogiri não recupera páginas nem executa JavaScript do site. Combine-o com um cliente HTTP quando a resposta já contiver os dados. Amplie a camada de recuperação quando a autenticação ou a renderização do lado do cliente alterar o documento devolvido.

As fontes fornecidas também atribuem ao Nokogiri o suporte a SAX, análise Push, XSLT e vários backends de analisadores nativos. Trate essas funcionalidades como capacidades sujeitas a verificação, especialmente ao escolher entre o MRI e outros ambientes de execução ou ao criar contentores mínimos.

O Ox e o LibXML Ruby resolvem problemas diferentes em contextos «XML-first». O Ox abrange a entrada e saída de XML baseadas em árvores, a serialização de objetos Ruby e o consumo SAX orientado por eventos. Vale a pena considerá-lo quando um analisador XML em Ruby precisa de serializar objetos ou consumir documentos de grande dimensão sem consultas complexas.

O LibXML Ruby envolve a libxml2 e adapta-se a pipelines com muitas consultas, onde a pesquisa XPath, as verificações de esquema ou as transformações XSLT são importantes. O instantâneo do diretório também atribui interfaces de árvore, evento, leitor pull e gravador à gem, juntamente com a validação DTD, RelaxNG e XSD. Verifique esses detalhes em relação à versão exata que planeia implementar.

xml = "<person><name>Ada</name></person>"

require "ox"
ox_tree = Ox.parse(xml)

require "xml"
libxml_doc = XML::Parser.string(xml).parse
name = libxml_doc.find("//name").first&.content

Não transforme um benchmark antigo numa lenda do tipo «Nokogiri vs Ox». Um teste justo tem em conta o Ruby, os parâmetros do compilador, as versões das bibliotecas nativas, a estrutura do documento, a codificação, o aquecimento, as repetições e se o que está a ser medido é a construção da árvore, a consulta, a serialização ou o streaming. Relate o débito, a latência, as alocações e o pico de memória separadamente.

O material fornecido relata possíveis limitações do Ox em relação a XPath, namespaces e XSLT, bem como uma cadeia de dependências nativas para o LibXML Ruby. Verifique ambos antes da seleção, particularmente para integrações com uso intensivo de namespaces e compilações de contentores portáteis.

O Oga e o Hpricot pertencem a um ramo da árvore de decisão sensível ao estado. O Oga mantém a maior parte da sua implementação em Ruby, utiliza uma pequena extensão e lida com HTML e XML através de XPath, além de consultas XML sensíveis a namespaces. O foco principal do Hpricot é o HTML, embora as evidências fornecidas indiquem que ele aceita XML e oferece seletores CSS e XPath.

As evidências também descrevem uma atividade recente escassa do Oga e indicam que o Hpricot já não é mantido, mas essas não são verificações oficiais atuais. Antes de adotar qualquer um deles, verifique a versão mais recente, o suporte a Ruby, as questões de compatibilidade e se o seu alvo consegue compilar a respetiva extensão.

Para aplicações existentes, o risco da substituição pode justificar a utilização de um adaptador protegido por fixtures. Para uma nova aplicação, é necessário garantir que os testes de compatibilidade sejam bem-sucedidos e que haja um responsável pela manutenção explicitamente definido antes de escolher qualquer uma delas como alternativa ao Nokogiri.

O Selenium é uma ferramenta de automação de navegadores, não um analisador HTML comum em Ruby. Utilize-o quando o JavaScript criar o DOM necessário, ou quando o fluxo de trabalho tiver de clicar, percorrer, enviar formulários ou preservar o estado do navegador. A documentação oficial do Selenium WebDriver explica o seu modelo de controlo do navegador.

Comece com a recuperação HTTP e um analisador. Se uma resposta guardada não tiver dados visíveis num navegador, transfira apenas a renderização ou a interação para o Selenium. Em seguida, extraia com localizadores ou passe o código-fonte da página renderizada para o Nokogiri para processamento CSS ou XPath.

Isto acrescenta processos do navegador, gestão de controladores, tempos de espera e mais modos de falha. A semântica atual dos tempos de espera e a configuração dos controladores dependem da versão, por isso verifique-as em vez de repetir orientações mais antigas. Não assuma essa sobrecarga para marcação estática que um cliente HTTP já devolve.

Para a análise de dados de produção, utilize um contrato explícito de entrada e saída:

1. Receba ou obtenha bytes e, em seguida, registe o URL final, o estado, o tipo de conteúdo e o conjunto de caracteres declarado.
2. Resolva a codificação antes de os seletores serem executados. Mantenha os bytes originais, caso a transcodificação ou uma entrada malformada possam necessitar de investigação.
3. Analise no modo escolhido para tolerância HTML, XML estrito ou streaming.
4. Extraia campos com seletores que lidem deliberadamente com nós em falta.
5. Valide os campos obrigatórios, tipos, espaços de nomes ou esquemas antes de emitir um registo.
6. Guarde fixtures representativos, incluindo marcação malformada, layouts alterados, campos vazios e amostras não UTF-8.
7. Execute testes de seletores nestes fixtures em cada atualização do analisador ou das dependências.

def extract_title(html)
  doc = Nokogiri::HTML.parse(html)
  title = doc.at_css("article h1")&.text&.strip
  raise KeyError, "article h1 missing" if title.to_s.empty?
  { title: title }
end

Registe erros de análise com um contexto seguro para os fixtures, em vez de registar documentos sensíveis na íntegra. Trate o XML não confiável como uma revisão de segurança separada, em vez de assumir que as predefinições do analisador são seguras.

Antes de padronizar estes analisadores Ruby de HTML e XML, responda:

• A entrada é HTML estático, HTML malformado, XML estrito ou um DOM renderizado pelo navegador?
• O documento cabe na memória ou os registos devem ser transmitidos em fluxo?
• São necessários CSS, XPath, namespaces, validação ou XSLT?
• A serialização de objetos faz parte da carga de trabalho?
• Que bibliotecas nativas, compiladores, navegadores ou controladores devem ser fornecidos?
• A gem específica já foi testada com o Ruby e o SO de destino?
• A ferramenta é uma dependência legada que deve ser utilizada através de um adaptador?
• Os fixtures guardados abrangem a codificação, entradas malformadas, seletores ausentes e atualizações?

O melhor analisador XML ou HTML para Ruby é aquele que satisfaz essas restrições com o menor tempo de execução fiável.

• Classifique a carga de trabalho antes de escolher uma gem: HTML estático, XML estrito, XML transmitido, serialização de objetos e páginas renderizadas requerem ferramentas diferentes.
• Mantenha a recuperação, a autenticação, a renderização e a análise como etapas separadas do pipeline, para que as falhas sejam atribuídas à camada correta.
• Verifique as versões atuais, as dependências nativas e o suporte à plataforma com a versão exata do Ruby e a imagem de implementação que irá utilizar.
• Faça testes de desempenho com fixtures representativos e teste seletores, nós em falta, codificações e entradas malformadas antes de considerar qualquer analisador pronto para produção.

Não. O Nokogiri analisa a cadeia de caracteres HTML ou XML que lhe é fornecida e não executa scripts da página. Recupere o DOM renderizado com uma ferramenta do navegador quando o JavaScript criar o elemento alvo e, em seguida, interroga esse DOM diretamente ou passa o código-fonte da página para o Nokogiri. Se um ponto final devolver os mesmos dados como JSON ou HTML, utilizar essa resposta é normalmente mais simples do que controlar o navegador.

Utilize streaming ou SAX quando os documentos forem demasiado grandes para uma construção confortável da árvore ou quando cada registo puder ser processado uma vez por ordem. Funciona bem para feeds, exportações e transformações que emitem resultados de forma incremental. Dê preferência a um DOM quando a extração necessitar de navegação arbitrária, consultas repetidas ou modificações em partes distantes do documento.

Considere ambas como escolhas dependentes do contexto, em vez de predefinições automáticas. Antes da adoção, verifique se existe uma versão recente, se há suporte para a sua versão do Ruby, se a compilação é bem-sucedida em todos os alvos de implementação e se a resposta a problemas é aceitável. Um pequeno teste de compatibilidade deve analisar os vossos fixtures reais e testar os namespaces, entradas malformadas e seletores. O código existente pode justificar a sua manutenção por trás de um adaptador, mesmo que uma nova compilação optasse por uma solução diferente.

Uma comparação justa requer, em primeiro lugar, uma saída e um comportamento de falha idênticos, uma vez que uma recuperação mais rápida não faz sentido se os analisadores construírem árvores diferentes. Utilize grupos de fixtures separados para documentos pequenos, documentos grandes, namespaces, entradas malformadas, streaming e serialização. Relate as distribuições dos resultados em vez de um único melhor resultado, inclua os efeitos da recolha de lixo e publique o conjunto de testes para que outro engenheiro possa reproduzir o teste.

A escolha entre analisadores HTML e XML em Ruby torna-se muito mais simples assim que a carga de trabalho for explicitada. O Nokogiri é o ponto de partida prático e de uso geral para HTML e trabalhos baseados em árvores mistas. O Ox merece ser avaliado para a serialização de XML e o processamento de eventos, enquanto o LibXML Ruby é adequado para pipelines de XML que necessitem de funcionalidades de XPath, validação ou transformação. O Oga e o Hpricot exigem uma manutenção mais rigorosa e verificações de compatibilidade, e o Selenium só se justifica quando a renderização ou a interação são genuinamente necessárias.

Seja qual for a sua escolha, mantenha o analisador atrás de uma interface restrita. Preserve os fixtures em bruto, teste os seletores e o comportamento em caso de nós em falta, registe os pressupostos de codificação e identifique os detalhes de tempo de execução que afetam as extensões nativas. Faça testes de desempenho com os seus próprios documentos, em vez de herdar a classificação de velocidade de outrem.

A recuperação pode, eventualmente, tornar-se mais difícil do que a análise. Se pedidos bloqueados, CAPTCHAs ou rotação de proxies estiverem a consumir o orçamento de engenharia, a API Scraper da WebScrapingAPI pode devolver HTML bruto enquanto lida com esse trabalho na camada de pedidos, deixando o seu código Ruby focado numa fase de extração pequena e testável. Essa é a separação mais clara: a recuperação produz uma marcação fiável e o analisador selecionado transforma-a em dados validados.