wget -qO- 'http://www.youtube.com/watch?v=Dd7dQh8u4Hc' |
perl -l -0777 -ne 'print $1 if /<title.*?>\s*(.*?)\s*<\/title/si'
Puede canalizarlo a GNU recodesi hay cosas como <en él:
wget -qO- 'http://www.youtube.com/watch?v=Dd7dQh8u4Hc' |
perl -l -0777 -ne 'print $1 if /<title.*?>\s*(.*?)\s*<\/title/si' |
recode html..
Para quitar la - youtubeparte:
wget -qO- 'http://www.youtube.com/watch?v=Dd7dQh8u4Hc' |
perl -l -0777 -ne 'print $1 if /<title.*?>\s*(.*?)(?: - youtube)?\s*<\/title/si'
Para señalar algunas de las limitaciones:
portabilidad
No hay un comando estándar / portátil para hacer consultas HTTP. Hace unas décadas, hubiera recomendado lynx -sourceaquí. Pero hoy en día, wgetes más portátil, ya que se puede encontrar por defecto en la mayoría de los sistemas GNU (incluidos la mayoría de los sistemas operativos de escritorio / portátiles basados en Linux). Otros que son bastante portátiles incluyen el GETcomando que viene con perlla libwww que a menudo se instala lynx -source, y en menor medida curl. Otros comunes los incluyen links -source, elinks -source, w3m -dump_source, lftp -c cat...
Protocolo HTTP y manejo de redireccionamiento
wgetes posible que no obtenga la misma página que la que, por ejemplo, firefoxse mostrará. La razón es que los servidores HTTP pueden elegir enviar una página diferente en función de la información proporcionada en la solicitud enviada por el cliente.
La solicitud enviada por wget / w3m / GET ... será diferente de la enviada por firefox. Si eso es un problema, puede modificar el wgetcomportamiento para cambiar la forma en que envía la solicitud, aunque con opciones.
Los más importantes aquí a este respecto son:
Accepty Accept-language: eso le dice al servidor en qué idioma y conjunto de caracteres le gustaría al cliente obtener la respuesta. wgetno envía ninguno de manera predeterminada, por lo que el servidor generalmente enviará con su configuración predeterminada. firefoxen el otro extremo es probable que esté configurado para solicitar su idioma.User-Agent: que identifica la aplicación del cliente para el servidor. Algunos sitios envían contenido diferente basado en el cliente (aunque eso es principalmente por diferencias entre las interpretaciones del lenguaje javascript) y pueden negarse a servirle si está utilizando un agente de usuario de tipo robotwget .Cookie: si ha visitado este sitio anteriormente, su navegador puede tener cookies permanentes. wgetNo lo haré.
wgetseguirá las redirecciones cuando se realicen en el nivel de protocolo HTTP, pero dado que no analiza el contenido de la página, no las realizadas por javascript o cosas por el estilo <meta http-equiv="refresh" content="0; url=http://example.com/">.
Eficiencia en el desempeño
Aquí, por flojera, hemos perlleído todo el contenido en la memoria antes de comenzar a buscar la <title>etiqueta. Dado que el título se encuentra en la <head>sección que se encuentra en los primeros bytes del archivo, eso no es óptimo. Un mejor enfoque, si GNU awkestá disponible en su sistema podría ser:
wget -qO- 'http://www.youtube.com/watch?v=Dd7dQh8u4Hc' |
gawk -v IGNORECASE=1 -v RS='</title' 'RT{gsub(/.*<title[^>]*>/,"");print;exit}'
De esa manera, awk deja de leer después de la primera </titley, al salir, hace wgetque se detenga la descarga.
Análisis del HTML
Aquí, wgetescribe la página a medida que la descarga. Al mismo tiempo, perlsorbe su salida ( -0777 -n) completa en la memoria y luego imprime el código HTML que se encuentra entre las primeras apariciones de <title...>y </title.
Eso funcionará para la mayoría de las páginas HTML que tienen una <title>etiqueta, pero hay casos en los que no funcionará.
Por el contrario, la solución de coffeeMug analizará la página HTML como XML y devolverá el valor correspondiente para title. Es más correcto si se garantiza que la página sea XML válido . Sin embargo, no se requiere que HTML sea XML válido (las versiones anteriores del lenguaje no lo eran), y debido a que la mayoría de los navegadores son indulgentes y aceptarán códigos HTML incorrectos, incluso hay muchos códigos HTML incorrectos.
Tanto mi solución como coffeeMug fallarán en una variedad de casos de esquina, a veces lo mismo, a veces no.
Por ejemplo, el mío fallará en:
<html><head foo="<title>"><title>blah</title></head></html>
o:
<!-- <title>old</title> --><title>new</title>
Mientras que su fallará:
<TITLE>foo</TITLE>
(html válido, no xml) o:
o:
<title>...</title>
...
<script>a='<title>'; b='</title>';</script>
(de nuevo, válido html, faltan <![CDATA[partes para que sea válido XML).
<title>foo <<<bar>>> baz</title>
(HTML incorrecto, pero aún se encuentra allí y es compatible con la mayoría de los navegadores)
interpretación del código dentro de las etiquetas.
Esa solución genera el texto sin formato entre <title>y </title>. Normalmente, no debe haber ninguna etiqueta HTML allí, posiblemente puede haber comentarios (aunque algunos navegadores como Firefox no los manejan, por lo que es muy poco probable). Todavía puede haber algo de codificación 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
De lo que se ocupa 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
Pero un cliente web también está destinado a hacer más transformaciones en ese código al mostrar el título (como condensar algunos de los espacios en blanco, eliminar los iniciales y finales). Sin embargo, es poco probable que sea necesario. Entonces, como en los otros casos, depende de usted decidir si vale la pena el esfuerzo.
Conjunto de caracteres
Antes de UTF-8, iso8859-1 solía ser el juego de caracteres preferido en la web para caracteres que no son ASCII, aunque estrictamente hablando tenían que escribirse como é. Las versiones más recientes de HTTP y el lenguaje HTML han agregado la posibilidad de especificar el conjunto de caracteres en los encabezados HTTP o en los encabezados HTML, y un cliente puede especificar los conjuntos de caracteres que acepta. UTF-8 tiende a ser el juego de caracteres predeterminado en la actualidad.
Entonces, eso significa que, por ahí, encontrará éescrito como é, como é, como UTF-8 é, (0xc3 0xa9), como iso-8859-1 (0xe9), con los 2 últimos, a veces la información en el juego de caracteres en los encabezados HTTP o los encabezados HTML (en diferentes formatos), a veces no.
wget solo obtiene los bytes sin procesar, no le importa su significado como caracteres y no le dice al servidor web sobre el juego de caracteres preferido.
recode html..se encargará de convertir el éo éen la secuencia adecuada de bytes para el conjunto de caracteres utilizado en su sistema, pero para el resto, eso es más complicado.
Si el conjunto de caracteres de su sistema es utf-8, es probable que esté bien la mayor parte del tiempo, ya que tiende a ser el conjunto de caracteres predeterminado que se utiliza actualmente.
$ 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
Eso de éarriba era un UTF-8 é.
Pero si quieres cubrir otros charsets, una vez más, habrá que cuidarlo.
También debe tenerse en cuenta que esta solución no funcionará en absoluto para las páginas codificadas UTF-16 o UTF-32.
Para resumir
Idealmente, lo que necesita aquí es un navegador web real para brindarle la información. Es decir, necesita algo para hacer la solicitud HTTP con los parámetros adecuados, interpretar la respuesta HTTP correctamente, interpretar completamente el código HTML como lo haría un navegador y devolver el título.
Como no creo que se pueda hacer en la línea de comandos con los navegadores que conozco (aunque ahora vea este trucolynx ), debe recurrir a la heurística y las aproximaciones, y la anterior es tan buena como cualquiera.
También es posible que desee tener en cuenta el rendimiento, la seguridad ... Por ejemplo, para cubrir todos los casos (por ejemplo, una página web que tiene algunos javascript extraídos de un sitio de terceros que establece el título o redirige a otra página en un onload hook), puede que tenga que implementar un navegador de la vida real con sus motores dom y javascript que pueden tener que hacer cientos de consultas para una sola página HTML, algunas de las cuales intentan explotar vulnerabilidades ...
Si bien el uso de expresiones regulares para analizar HTML a menudo está mal visto , este es un caso típico en el que es lo suficientemente bueno para la tarea (IMO).