Existem soluções sofisticadas que envolvem a utilização do próprio navegador para tentar analisar o texto, identificando se algum nó DOM foi construído, o que será ... lento. Ou expressões regulares que serão mais rápidas, mas ... potencialmente imprecisas. Existem também duas questões muito distintas decorrentes deste problema:
Q1: uma string contém fragmentos HTML?
A string é parte de um documento HTML, contendo marcação de elemento HTML ou entidades codificadas? Isso pode ser usado como um indicador de que a string pode exigir branqueamento / higienização ou decodificação de entidade:
/</?[a-z][^>]*>|(\&(?:[\w\d]+|#\d+|#x[a-f\d]+);/
Você pode ver esse padrão em uso em todos os exemplos de todas as respostas existentes no momento em que este livro foi escrito, além de alguns ... hediondos textos de amostra gerados por WYSIWYG ou Word e uma variedade de referências a entidades de caracteres.
P2: A string é um documento HTML?
A especificação HTML é chocantemente frouxa quanto ao que considera um documento HTML . Os navegadores vão a extremos para analisar quase qualquer texto lixo como HTML. Duas abordagens: ou apenas considerar tudo HTML (já que se entregue com um text/htmlContent-Type, grande esforço será despendido para tentar interpretá-lo como HTML pelo agente do usuário) ou procurar o marcador de prefixo:
<!DOCTYPE html>
Em termos de "boa formação", isso e quase nada mais é "necessário". A seguir está um documento HTML 100% completo e totalmente válido, contendo todos os elementos HTML que você acha que estão sendo omitidos:
<!DOCTYPE html>
<title>Yes, really.</title>
<p>This is everything you need.
Sim. Existem regras explícitas sobre como formar elementos "perdidos", como <html>, <head>, e <body>. Embora eu ache bastante divertido que o realce de sintaxe do SO não tenha detectado isso corretamente sem uma dica explícita.