wget -qO- 'http://www.youtube.com/watch?v=Dd7dQh8u4Hc' |
perl -l -0777 -ne 'print $1 if /<title.*?>\s*(.*?)\s*<\/title/si'
Você pode canalizar para o GNU recodese houver coisas como <:
wget -qO- 'http://www.youtube.com/watch?v=Dd7dQh8u4Hc' |
perl -l -0777 -ne 'print $1 if /<title.*?>\s*(.*?)\s*<\/title/si' |
recode html..
Para remover a - youtubepeça:
wget -qO- 'http://www.youtube.com/watch?v=Dd7dQh8u4Hc' |
perl -l -0777 -ne 'print $1 if /<title.*?>\s*(.*?)(?: - youtube)?\s*<\/title/si'
Para apontar algumas das limitações:
portabilidade
Não há comando padrão / portátil para fazer consultas HTTP. Algumas décadas atrás, eu recomendaria lynx -sourceaqui. Atualmente, porém, wgeté mais portátil, pois pode ser encontrado por padrão na maioria dos sistemas GNU (incluindo a maioria dos sistemas operacionais de desktop / laptop baseados em Linux). Outros razoavelmente portáveis incluem o GETcomando que vem com perla libwww que é frequentemente instalada e lynx -source, em menor grau curl. Outros comuns aqueles incluem links -source, elinks -source, w3m -dump_source, lftp -c cat...
Protocolo HTTP e manipulação de redirecionamento
wgetpode não ter a mesma página que a que, por exemplo, firefoxseria exibida. O motivo é que os servidores HTTP podem optar por enviar uma página diferente com base nas informações fornecidas na solicitação enviada pelo cliente.
A solicitação enviada pelo wget / w3m / GET ... será diferente da enviada pelo firefox. Se esse é um problema, você pode alterar o wgetcomportamento para alterar a maneira como ele envia a solicitação, com opções.
Os mais importantes aqui a esse respeito são:
Accepte Accept-language: informa ao servidor em que idioma e conjunto de caracteres o cliente gostaria de receber a resposta. wgetnão envia nenhum por padrão; portanto, o servidor normalmente envia com suas configurações padrão. firefoxdo outro lado, provavelmente está configurado para solicitar seu idioma.User-Agent: que identifica o aplicativo cliente para o servidor. Alguns sites enviam conteúdo diferente com base no cliente (embora seja principalmente devido a diferenças entre interpretações de linguagem javascript) e podem se recusar a atendê-lo se você estiver usando um agente de usuário do tipo robôwget .Cookie: se você já visitou este site antes, seu navegador pode ter cookies permanentes para ele. wgetnão vou.
wgetseguirá os redirecionamentos quando forem feitos no nível do protocolo HTTP, mas como ele não analisa o conteúdo da página, não os que são feitos por javascript ou coisas do tipo <meta http-equiv="refresh" content="0; url=http://example.com/">.
Desempenho / Eficiência
Aqui, por preguiça, perllemos todo o conteúdo na memória antes de começar a procurar a <title>tag. Dado que o título é encontrado na <head>seção que está nos primeiros bytes do arquivo, isso não é o ideal. Uma abordagem melhor, se o GNU awkestiver disponível no seu sistema, pode ser:
wget -qO- 'http://www.youtube.com/watch?v=Dd7dQh8u4Hc' |
gawk -v IGNORECASE=1 -v RS='</title' 'RT{gsub(/.*<title[^>]*>/,"");print;exit}'
Dessa forma, o awk para de ler após o primeiro </titlee, ao sair, faz wgetcom que o download seja interrompido.
Análise do HTML
Aqui, wgetescreve a página enquanto a baixa. Ao mesmo tempo, perlinverte toda a saída ( -0777 -n) na memória e depois imprime o código HTML encontrado entre as primeiras ocorrências de <title...>e </title.
Isso funcionará para a maioria das páginas HTML que possuem uma <title>tag, mas há casos em que ela não funciona.
Por outro lado, a solução do coffeeMug analisará a página HTML como XML e retornará o valor correspondente para title. É mais correto se é garantido que a página é XML válida . No entanto, não é necessário que o HTML seja XML válido (as versões mais antigas da linguagem não eram) e, como a maioria dos navegadores existentes é branda e aceita códigos HTML incorretos, há muitos códigos HTML incorretos por aí.
Tanto a minha solução como a do coffeeMug falharão em vários casos de canto, às vezes iguais, às vezes não.
Por exemplo, o meu falhará:
<html><head foo="<title>"><title>blah</title></head></html>
ou:
<!-- <title>old</title> --><title>new</title>
Enquanto o dele falhará:
<TITLE>foo</TITLE>
(html válido, não xml) ou:
ou:
<title>...</title>
...
<script>a='<title>'; b='</title>';</script>
(novamente, partes htmlausentes e válidas <![CDATA[para torná-lo XML válido).
<title>foo <<<bar>>> baz</title>
(html incorreto, mas ainda encontrado e suportado pela maioria dos navegadores)
interpretação do código dentro das tags.
Essa solução gera o texto bruto entre <title>e </title>. Normalmente, não deve haver nenhuma tag HTML, pode haver comentários (embora não sejam tratados por alguns navegadores como o Firefox tão improvável). Ainda pode haver alguma codificação HTML:
$ wget -qO- 'http://www.youtube.com/watch?v=CJDhmlMQT60' |
perl -l -0777 -ne 'print $1 if /<title.*?>\s*(.*?)\s*<\/title/si'
Wallace & Gromit - The Cheesesnatcher Part 1 (claymation) - YouTube
O que é tratado pelo GNU recode:
$ wget -qO- 'http://www.youtube.com/watch?v=CJDhmlMQT60' |
perl -l -0777 -ne 'print $1 if /<title.*?>\s*(.*?)\s*<\/title/si' |
recode html..
Wallace & Gromit - The Cheesesnatcher Part 1 (claymation) - YouTube
Mas um cliente da Web também deve fazer mais transformações nesse código ao exibir o título (como condensar alguns espaços em branco, remover os principais e os finais). No entanto, é improvável que haja uma necessidade disso. Assim, como nos outros casos, cabe a você decidir se vale a pena o esforço.
Conjunto de caracteres
Antes do UTF-8, iso8859-1 costumava ser o conjunto de caracteres preferido na Web para caracteres não ASCII, embora estritamente falando eles precisassem ser escritos como é. Versões mais recentes do HTTP e da linguagem HTML adicionaram a possibilidade de especificar o conjunto de caracteres nos cabeçalhos HTTP ou HTML, e um cliente pode especificar os conjuntos de caracteres que aceita. Atualmente, o UTF-8 é o conjunto de caracteres padrão.
Então, isso significa que lá fora, você vai encontrar éescrito como é, como é, como UTF-8 é, (0xC3 0xA9), como iso-8859-1 (0xE9), com os 2 últimos, por vezes, as informações sobre o charset nos cabeçalhos HTTP ou HTML (em diferentes formatos), às vezes não.
wget obtém apenas os bytes brutos, não se importa com o significado deles como caracteres e não informa o servidor da web sobre o conjunto de caracteres preferido.
recode html..tomará o cuidado de converter éou éna seqüência adequada de bytes para o conjunto de caracteres usado em seu sistema, mas, quanto ao resto, isso é mais complicado.
Se o seu conjunto de caracteres do sistema for utf-8, é provável que esteja tudo bem na maioria das vezes, pois esse tende a ser o conjunto de caracteres padrão usado hoje em dia.
$ wget -qO- 'http://www.youtube.com/watch?v=if82MGPJEEQ' |
perl -l -0777 -ne 'print $1 if /<title.*?>\s*(.*?)\s*<\/title/si'
Noir Désir - L'appartement - YouTube
Isso éacima foi um UTF-8 é.
Mas se você deseja cobrir outros conjuntos de caracteres, mais uma vez, isso deve ser resolvido.
Também deve ser observado que esta solução não funcionará de maneira alguma para páginas codificadas em UTF-16 ou UTF-32.
Resumindo
Idealmente, o que você precisa aqui é um navegador da Web real para fornecer as informações. Ou seja, você precisa de algo para fazer a solicitação HTTP com os parâmetros adequados, interpretar a resposta HTTP corretamente, interpretar completamente o código HTML como um navegador faria e retornar o título.
Como não acho que isso possa ser feito na linha de comando com os navegadores que conheço (embora veja agora esse truquelynx ), você precisa recorrer a heurísticas e aproximações, e a acima é tão boa quanto qualquer outra.
Você também pode levar em consideração desempenho, segurança ... Por exemplo, para cobrir todos os casos (por exemplo, uma página da Web que tenha algum javascript extraído de um site de terceiros que define o título ou redireciona para outra página em um onload hook), pode ser necessário implementar um navegador da vida real com seus mecanismos dom e javascript que podem precisar fazer centenas de consultas para uma única página HTML, algumas das quais tentando explorar vulnerabilidades ...
Embora o uso de regexps para analisar HTML geralmente seja desaprovado , este é um caso típico em que é bom o suficiente para a tarefa (IMO).