wget -qO- 'http://www.youtube.com/watch?v=Dd7dQh8u4Hc' |
perl -l -0777 -ne 'print $1 if /<title.*?>\s*(.*?)\s*<\/title/si'
Sie können es an GNU weiterleiten, recodewenn es Dinge wie <diese gibt:
wget -qO- 'http://www.youtube.com/watch?v=Dd7dQh8u4Hc' |
perl -l -0777 -ne 'print $1 if /<title.*?>\s*(.*?)\s*<\/title/si' |
recode html..
So entfernen Sie das - youtubeTeil:
wget -qO- 'http://www.youtube.com/watch?v=Dd7dQh8u4Hc' |
perl -l -0777 -ne 'print $1 if /<title.*?>\s*(.*?)(?: - youtube)?\s*<\/title/si'
Um auf einige der Einschränkungen hinzuweisen:
Portabilität
Es gibt keinen Standardbefehl für HTTP-Abfragen. Vor ein paar Jahrzehnten hätte ich lynx -sourcestattdessen hier empfohlen . Aber heutzutage wgetist es portabler, da es standardmäßig auf den meisten GNU-Systemen (einschließlich der meisten Linux-basierten Desktop- / Laptop-Betriebssysteme) zu finden ist. Andere ziemlich portable sind der GETBefehl perllibwww, der häufig lynx -sourceund in geringerem Umfang installiert wird curl. Andere gemeinsam diejenigen umfassen links -source, elinks -source, w3m -dump_source, lftp -c cat...
HTTP-Protokoll und Umleitungsbehandlung
wgeterhält möglicherweise nicht die gleiche Seite wie die, die zum Beispiel firefoxangezeigt werden würde. Der Grund dafür ist, dass HTTP-Server basierend auf den Informationen in der vom Client gesendeten Anforderung möglicherweise eine andere Seite senden.
Die von wget / w3m / GET ... gesendete Anfrage unterscheidet sich von der von firefox. Wenn dies ein Problem ist, können Sie das wgetVerhalten ändern, um die Art und Weise zu ändern, in der die Anforderung mit Optionen gesendet wird.
Die wichtigsten in dieser Hinsicht sind:
Acceptund Accept-language: Hiermit wird dem Server mitgeteilt, in welcher Sprache und in welchem Zeichensatz der Client die Antwort erhalten möchte. wgetStandardmäßig wird keine Antwort gesendet, sodass der Server normalerweise mit den Standardeinstellungen sendet. firefoxam anderen Ende ist wahrscheinlich konfiguriert, um Ihre Sprache anzufordern.User-Agent: Gibt die Clientanwendung gegenüber dem Server an. Einige Websites senden unterschiedliche Inhalte basierend auf dem Client (obwohl dies hauptsächlich auf Unterschiede zwischen den Interpretationen der Javascript-Sprache zurückzuführen ist) und lehnen es möglicherweise ab, Sie zu bedienen, wenn Sie einen Benutzeragenten vom Robotertyp wie verwenden wget.Cookie: Wenn Sie diese Seite schon einmal besucht haben, verfügt Ihr Browser möglicherweise über permanente Cookies. wgetwird nicht.
wgetwird den Weiterleitungen folgen, wenn sie auf der HTTP-Protokollebene durchgeführt werden, aber da es nicht um den Inhalt der Seite geht, nicht um die von Javascript oder ähnlichen Dingen <meta http-equiv="refresh" content="0; url=http://example.com/">.
Leistungsfähigkeit
Hier haben wir aus Faulheit perlden gesamten Inhalt im Speicher gelesen, bevor wir nach dem <title>Tag gesucht haben. Da sich der Titel in dem <head>Abschnitt befindet, der sich in den ersten Bytes der Datei befindet, ist dies nicht optimal. Ein besserer Ansatz, wenn GNU awkauf Ihrem System verfügbar ist, könnte sein:
wget -qO- 'http://www.youtube.com/watch?v=Dd7dQh8u4Hc' |
gawk -v IGNORECASE=1 -v RS='</title' 'RT{gsub(/.*<title[^>]*>/,"");print;exit}'
Auf diese Weise hört awk nach dem ersten Lesen auf </titleund führt beim Verlassen dazu, dass wgetder Download abgebrochen wird.
Analyse des HTML
Hier wird wgetdie Seite beim Herunterladen geschrieben. Gleichzeitig perlschlürft output ( -0777 -n) als Ganzes in den Speicher und druckt dann den HTML-Code, der zwischen den ersten Vorkommen von <title...>und gefunden wird </title.
Das funktioniert für die meisten HTML-Seiten mit einem <title>Tag, aber es gibt Fälle, in denen es nicht funktioniert.
Im Gegensatz dazu analysiert die Lösung von coffeeMug die HTML-Seite als XML und gibt den entsprechenden Wert für zurück title. Richtiger ist es, wenn garantiert wird, dass die Seite gültiges XML ist . HTML muss jedoch kein gültiges XML sein (ältere Sprachversionen waren dies nicht), und da die meisten Browser mild sind und falschen HTML-Code akzeptieren, gibt es sogar viele falsche HTML-Codes.
Sowohl meine Lösung als auch die von coffeeMug scheitern bei einer Vielzahl von Eckfällen , manchmal gleich, manchmal nicht.
Zum Beispiel wird meine am scheitern:
<html><head foo="<title>"><title>blah</title></head></html>
oder:
<!-- <title>old</title> --><title>new</title>
Während sein wird scheitern:
<TITLE>foo</TITLE>
(gültiges HTML, nicht XML) oder:
oder:
<title>...</title>
...
<script>a='<title>'; b='</title>';</script>
(wieder gültige html, fehlende <![CDATA[Teile, um es als gültiges XML zu kennzeichnen).
<title>foo <<<bar>>> baz</title>
(Falsches HTML, aber immer noch bekannt und von den meisten Browsern unterstützt)
Interpretation des Codes innerhalb der Tags.
Diese Lösung gibt den Rohtext zwischen <title>und aus </title>. Normalerweise sollten keine HTML-Tags enthalten sein, möglicherweise sind Kommentare vorhanden (obwohl dies von einigen Browsern wie Firefox nicht so wahrscheinlich ist). Möglicherweise ist noch eine HTML-Codierung vorhanden:
$ 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
Um was kümmert sich 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
Ein Web-Client ist jedoch auch dazu gedacht, den Code beim Anzeigen des Titels stärker zu transformieren (z. B. einige der Leerzeichen zu komprimieren, die führenden und nachfolgenden zu entfernen). Es ist jedoch unwahrscheinlich, dass dies erforderlich sein wird. Wie in den anderen Fällen müssen Sie entscheiden, ob sich die Mühe lohnt.
Zeichensatz
Vor UTF-8 war iso8859-1 der bevorzugte Zeichensatz im Web für Nicht-ASCII-Zeichen, obwohl genau genommen geschrieben werden musste é. Neuere Versionen von HTTP und der HTML-Sprache haben die Möglichkeit hinzugefügt, den Zeichensatz in den HTTP-Headern oder in den HTML-Headern anzugeben, und ein Client kann die Zeichensätze angeben, die er akzeptiert. UTF-8 ist heutzutage der Standardzeichensatz.
Das bedeutet also, dass Sie dort draußen éals é, als é, als UTF-8 é, (0xc3 0xa9), als iso-8859-1 (0xe9), mit den 2 letzten, manchmal die Informationen auf dem Zeichensatz finden in den HTTP-Headern oder den HTML-Headern (in verschiedenen Formaten) manchmal nicht.
wget Erhält nur die Rohbytes, kümmert sich nicht um deren Bedeutung als Zeichen und informiert den Webserver nicht über den bevorzugten Zeichensatz.
recode html..kümmert sich darum, das éoder éin die richtige Folge von Bytes für den auf Ihrem System verwendeten Zeichensatz umzuwandeln , aber im übrigen ist das schwieriger.
Wenn Ihr Systemzeichensatz utf-8 ist, ist dies wahrscheinlich die meiste Zeit in Ordnung, da dies in der Regel der Standardzeichensatz ist, der heutzutage verwendet wird.
$ 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
Das éoben war ein UTF-8 é.
Aber wenn Sie noch einmal andere Zeichensätze abdecken möchten, müssten Sie sich darum kümmern.
Es sollte auch beachtet werden, dass diese Lösung für UTF-16- oder UTF-32-codierte Seiten überhaupt nicht funktioniert.
Um zusammenzufassen
Idealerweise benötigen Sie hier einen echten Webbrowser, der Ihnen die Informationen liefert. Das heißt, Sie müssen die HTTP-Anforderung mit den richtigen Parametern ausführen, die HTTP-Antwort richtig interpretieren, den HTML-Code vollständig interpretieren, wie es ein Browser tun würde, und den Titel zurückgeben.
Da ich glaube, dass dies mit den Browsern, die ich kenne, auf der Kommandozeile nicht möglich ist (obwohl ich diesen Tricklynx jetzt sehe ), muss man auf Heuristiken und Annäherungen zurückgreifen, und die obige ist so gut wie jede andere.
Vielleicht möchten Sie auch Leistung, Sicherheit usw. berücksichtigen, um alle Fälle abzudecken (z. B. eine Webseite, auf der Javascript von einer Website eines Drittanbieters abgerufen wurde, auf der der Titel oder die Weiterleitung zu einer anderen Seite in einer Website festgelegt ist) onload hook) müssen Sie möglicherweise einen realen Browser mit dom- und javascript-Modulen implementieren, der möglicherweise Hunderte von Abfragen für eine einzelne HTML-Seite ausführen muss, von denen einige versuchen, Schwachstellen auszunutzen ...
Während die Verwendung von regulären Ausdrücken zum Parsen von HTML häufig verpönt ist , ist hier ein typischer Fall, in dem es für die Aufgabe (IMO) gut genug ist.