wget -qO- 'http://www.youtube.com/watch?v=Dd7dQh8u4Hc' |
perl -l -0777 -ne 'print $1 if /<title.*?>\s*(.*?)\s*<\/title/si'
Możesz przesłać go do GNU, recodejeśli są <w nim takie rzeczy :
wget -qO- 'http://www.youtube.com/watch?v=Dd7dQh8u4Hc' |
perl -l -0777 -ne 'print $1 if /<title.*?>\s*(.*?)\s*<\/title/si' |
recode html..
Aby usunąć - youtubeczęść:
wget -qO- 'http://www.youtube.com/watch?v=Dd7dQh8u4Hc' |
perl -l -0777 -ne 'print $1 if /<title.*?>\s*(.*?)(?: - youtube)?\s*<\/title/si'
Aby wskazać niektóre ograniczenia:
ruchliwość
Nie ma standardowego / przenośnego polecenia do wykonywania zapytań HTTP. Kilka dekad temu poleciłbym lynx -sourcezamiast tego tutaj. Ale obecnie wgetjest bardziej przenośny, ponieważ można go domyślnie znaleźć w większości systemów GNU (w tym w większości systemów operacyjnych Linux / stacjonarnych / laptopów). Inne dość przenośne obejmują GETpolecenie, które jest dostarczane z perllibwww, które jest często instalowane lynx -source, i w mniejszym stopniu curl. Inne popularne z nich to links -source, elinks -source, w3m -dump_source, lftp -c cat...
Protokół HTTP i obsługa przekierowań
wgetmoże nie uzyskać tej samej strony, co na przykład firefoxwyświetlana strona. Powodem jest to, że serwery HTTP mogą wybrać wysłanie innej strony na podstawie informacji podanych w żądaniu przesłanym przez klienta.
Żądanie wysłane przez wget / w3m / GET ... będzie inne niż żądanie wysłane przez firefox. Jeśli to jest problem, możesz zmienić wgetzachowanie, aby zmienić sposób, w jaki wysyła żądanie, z opcjami.
Najważniejszymi tutaj w tym zakresie są:
Accepti Accept-language: informuje serwer, w którym języku i zestawie znaków klient chce uzyskać odpowiedź. wgetDomyślnie nie wysyła żadnego, więc serwer zwykle wysyła ustawienia z domyślnymi ustawieniami. firefoxna drugim końcu jest prawdopodobnie skonfigurowany do żądania twojego języka.User-Agent: która identyfikuje aplikację kliencką na serwerze. Niektóre witryny wysyłają różne treści w zależności od klienta (chociaż są to głównie różnice między interpretacjami języka javascript) i mogą odmówić obsługi, jeśli używasz agenta użytkownika typu robotwget .Cookie: jeśli odwiedziłeś tę stronę wcześniej, Twoja przeglądarka może mieć do niej trwałe pliki cookie. wgetnie będzie.
wgetbędzie podążał za przekierowaniami, gdy zostaną wykonane na poziomie protokołu HTTP, ale ponieważ nie patrzy on na zawartość strony, nie na te wykonane przez javascript lub coś podobnego <meta http-equiv="refresh" content="0; url=http://example.com/">.
Wydajność / wydajność
Tutaj, z lenistwa, perlprzeczytaliśmy całą zawartość w pamięci, zanim zaczęliśmy szukać <title>tagu. Biorąc pod uwagę, że tytuł znajduje się w <head>sekcji znajdującej się w pierwszych kilku bajtach pliku, nie jest to optymalne. Lepszym podejściem, jeśli GNU awkjest dostępny w twoim systemie, może być:
wget -qO- 'http://www.youtube.com/watch?v=Dd7dQh8u4Hc' |
gawk -v IGNORECASE=1 -v RS='</title' 'RT{gsub(/.*<title[^>]*>/,"");print;exit}'
W ten sposób awk przestaje czytać po pierwszym </title, a po wyjściu powoduje wgetzatrzymanie pobierania.
Analiza kodu HTML
Tutaj wgetzapisuje stronę podczas jej pobierania. W tym samym czasie perlslurps swoje wyjście ( -0777 -n) w całości, a następnie drukuje kod HTML znaleziony między pierwszymi wystąpieniami <title...>i </title.
Będzie to działać na większości stron HTML z <title>tagiem, ale są przypadki, w których nie będzie działać.
Dla kontrastu rozwiązanie coffeeMug parsuje stronę HTML jako XML i zwraca odpowiednią wartość dla title. Bardziej poprawne jest, jeśli strona ma gwarancję poprawności XML . Jednak HTML nie musi być poprawnym XML (starsze wersje języka nie były), a ponieważ większość przeglądarek jest łagodna i akceptuje niepoprawny kod HTML, istnieje nawet wiele niepoprawnych kodów HTML.
Zarówno moje rozwiązanie, jak i CoffeeMug's zawiodą w różnych przypadkach narożnych, czasem takich samych, a czasem nie.
Na przykład mój nie powiedzie się:
<html><head foo="<title>"><title>blah</title></head></html>
lub:
<!-- <title>old</title> --><title>new</title>
Podczas gdy jego zawiedzie:
<TITLE>foo</TITLE>
(ważny HTML, nie XML) lub:
lub:
<title>...</title>
...
<script>a='<title>'; b='</title>';</script>
(ponownie, poprawne html, brakujące <![CDATA[części, aby uczynić go prawidłowym XML).
<title>foo <<<bar>>> baz</title>
(niepoprawny HTML, ale nadal się tam znajduje i obsługiwany przez większość przeglądarek)
interpretacja kodu wewnątrz tagów.
To rozwiązanie generuje nieprzetworzony tekst pomiędzy <title>i </title>. Zwykle nie powinno być tam żadnych tagów HTML, mogą być tam komentarze (choć nie są obsługiwane przez niektóre przeglądarki, takie jak Firefox, więc jest to bardzo mało prawdopodobne). Nadal może być trochę kodowania 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
Tym zajmuje się 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
Ale klient WWW ma również na celu wykonanie większej liczby transformacji tego kodu podczas wyświetlania tytułu (np. Zagęszczenie niektórych odstępów, usunięcie wiodących i końcowych). Jest jednak mało prawdopodobne, że będzie to potrzebne. Tak jak w innych przypadkach, to Ty decydujesz, czy warto.
Zestaw znaków
Przed UTF-8, iso8859-1 był preferowanym zestawem znaków w sieci dla znaków spoza ASCII, choć ściśle mówiąc, musiały być napisane jako é. Nowsze wersje HTTP i języka HTML dodają możliwość określenia zestawu znaków w nagłówkach HTTP lub w nagłówkach HTML, a klient może określić akceptowane przez siebie zestawy znaków. UTF-8 jest obecnie domyślnym zestawem znaków.
Oznacza to, że na zewnątrz znajdziesz ézapisany jako é, jako é, jako UTF-8 é, (0xc3 0xa9), jako iso-8859-1 (0xe9), dla dwóch ostatnich, czasem informacje o zestawie znaków w nagłówkach HTTP lub HTML (w różnych formatach), czasem nie.
wget pobiera tylko nieprzetworzone bajty, nie dba o ich znaczenie jako znaków i nie informuje serwera WWW o preferowanym zestawie znaków.
recode html..zadba o konwersję élub éna odpowiednią sekwencję bajtów dla zestawu znaków używanego w systemie, ale dla reszty jest to trudniejsze.
Jeśli twój systemowy zestaw znaków to utf-8, są szanse, że będzie w porządku przez większość czasu, ponieważ zwykle jest to domyślny zestaw znaków używany obecnie.
$ 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
Że éwyżej był UTF-8 é.
Ale jeśli chcesz ukryć inne zestawy znaków, po raz kolejny trzeba będzie się tym zająć.
Należy również zauważyć, że to rozwiązanie w ogóle nie będzie działać na stronach kodowanych w UTF-16 lub UTF-32.
Podsumowując
Idealnie, czego potrzebujesz tutaj, jest prawdziwa przeglądarka internetowa zapewniająca informacje. Oznacza to, że potrzebujesz czegoś, aby wykonać żądanie HTTP z odpowiednimi parametrami, poprawnie zinterpretować odpowiedź HTTP, w pełni zinterpretować kod HTML tak jak przeglądarka i zwrócić tytuł.
Ponieważ nie sądzę, że można tego dokonać w wierszu poleceń za pomocą przeglądarek, które znam (choć teraz widzę tę sztuczkęlynx ), musisz uciekać się do heurystyki i przybliżeń, a powyższa jest równie dobra jak każda inna.
Możesz również wziąć pod uwagę wydajność, bezpieczeństwo ... Na przykład, aby objąć wszystkie przypadki (na przykład stronę internetową, na której pobierany jest skrypt javascript z witryny innej firmy, która ustawia tytuł lub przekierowuje na inną stronę w onload hook), być może będziesz musiał wdrożyć prawdziwą przeglądarkę z jej silnikami dom i javascript, które mogą wymagać setek zapytań dla pojedynczej strony HTML, z których niektóre próbują wykorzystać luki ...
Podczas gdy używanie wyrażeń regularnych do analizowania HTML jest często odrzucane , tutaj jest typowy przypadek, w którym jest wystarczająco dobry do zadania (IMO).