wget -qO- 'http://www.youtube.com/watch?v=Dd7dQh8u4Hc' |
perl -l -0777 -ne 'print $1 if /<title.*?>\s*(.*?)\s*<\/title/si'
Вы можете передать его в GNU, recodeесли есть такие вещи <:
wget -qO- 'http://www.youtube.com/watch?v=Dd7dQh8u4Hc' |
perl -l -0777 -ne 'print $1 if /<title.*?>\s*(.*?)\s*<\/title/si' |
recode html..
Чтобы удалить - youtubeчасть:
wget -qO- 'http://www.youtube.com/watch?v=Dd7dQh8u4Hc' |
perl -l -0777 -ne 'print $1 if /<title.*?>\s*(.*?)(?: - youtube)?\s*<\/title/si'
Чтобы указать на некоторые из ограничений:
портативность
Не существует стандартной / переносимой команды для выполнения HTTP-запросов. Несколько десятилетий назад я бы рекомендовал lynx -sourceвместо этого здесь. Но в настоящее время wgetон более переносим, поскольку его можно найти по умолчанию в большинстве систем GNU (включая большинство операционных систем для настольных компьютеров / ноутбуков на базе Linux). Другие довольно переносимые включают GETкоманду, которая поставляется с perllibwww, которая часто устанавливается lynx -source, и в меньшей степени curl. Другие распространенные из них включают в себя links -source, elinks -source, w3m -dump_source, lftp -c cat...
HTTP протокол и обработка перенаправления
wgetможет не получить ту же страницу, что и та, которая, например, firefoxбудет отображаться. Причина в том, что HTTP-серверы могут выбрать отправку другой страницы на основе информации, предоставленной в запросе, отправленном клиентом.
Запрос, отправленный wget / w3m / GET ..., будет отличаться от запроса, отправленного firefox. Если это проблема, вы можете изменить wgetповедение, чтобы изменить способ отправки запроса с помощью параметров.
Наиболее важными здесь в этом отношении являются:
Acceptи Accept-language: сообщает серверу, на каком языке и кодировке клиент хотел бы получить ответ. wgetПо умолчанию он не отправляется, поэтому сервер обычно отправляет с настройками по умолчанию. firefoxна другом конце, скорее всего, настроен на запрос вашего языка.User-Agent: идентифицирует клиентское приложение на сервере. Некоторые сайты отправляют разный контент на основе клиента (хотя это в основном из-за различий между интерпретациями языка javascript) и могут отказаться обслуживать вас, если вы используете пользовательский агент типа роботаwget .Cookie: если вы посещали этот сайт раньше, в вашем браузере могут быть постоянные файлы cookie для него. wgetне буду.
wgetбудет следовать перенаправлениям, когда они будут выполнены на уровне протокола HTTP, но так как он не смотрит на содержимое страницы, а не на содержимое javascript или тому подобное <meta http-equiv="refresh" content="0; url=http://example.com/">.
Производительность / эффективность
Здесь, из-за лени, мы perlпрочитали весь контент в памяти, прежде чем начать искать <title>тег. Учитывая, что заголовок находится в <head>разделе, который находится в первых нескольких байтах файла, это не оптимально. Лучший подход, если GNU awkдоступен в вашей системе, может быть:
wget -qO- 'http://www.youtube.com/watch?v=Dd7dQh8u4Hc' |
gawk -v IGNORECASE=1 -v RS='</title' 'RT{gsub(/.*<title[^>]*>/,"");print;exit}'
Таким образом, awk прекращает чтение после первого </titleи, выйдя, вызывает wgetостановку загрузки.
Разбор HTML
Здесь wgetпишет страницу, как она загружает его. В то же время, perlslus свой output ( -0777 -n) целиком в памяти, а затем печатает HTML-код, найденный между первыми вхождениями <title...>и </title.
Это будет работать для большинства HTML-страниц, имеющих <title>тег, но в некоторых случаях это не сработает.
В отличие от этого решение coffeeMug будет анализировать HTML-страницу как XML и возвращать соответствующее значение для title. Более правильно, если на странице гарантированно указан правильный XML . Тем не менее, HTML не обязательно должен быть действительным XML (более ранние версии языка не были), и поскольку большинство браузеров проявляют снисходительность и будут принимать неправильный HTML-код, существует даже много неправильного HTML-кода.
И моё решение, и CoffeeMug не удастся для разных угловых случаев, иногда одинаковых, иногда нет.
Например, у меня не получится:
<html><head foo="<title>"><title>blah</title></head></html>
или же:
<!-- <title>old</title> --><title>new</title>
Пока его не получится
<TITLE>foo</TITLE>
(действительный HTML, а не XML) или:
или же:
<title>...</title>
...
<script>a='<title>'; b='</title>';</script>
(опять же, допустимые html, недостающие <![CDATA[части, чтобы сделать его действительным XML).
<title>foo <<<bar>>> baz</title>
(неверный html, но все еще обнаруживается и поддерживается большинством браузеров)
интерпретация кода внутри тегов.
Это решение выводит необработанный текст между <title>и </title>. Обычно там не должно быть никаких HTML-тэгов, там могут быть комментарии (хотя они не обрабатываются некоторыми браузерами, такими как Firefox, что очень маловероятно). Там все еще может быть некоторая кодировка 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
О чем позаботится 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
Но веб-клиент также предназначен для выполнения большего количества преобразований в этом коде при отображении заголовка (например, сжатие некоторых пробелов, удаление начальных и конечных). Однако вряд ли в этом будет необходимость. Так что, как и в других случаях, вам решать, стоит ли это усилий.
Набор символов
До UTF-8 iso8859-1 раньше был предпочтительным набором символов в сети для символов, не относящихся к ASCII, хотя, строго говоря, они должны были быть записаны как é. Более поздние версии HTTP и язык HTML добавили возможность указывать набор символов в заголовках HTTP или в заголовках HTML, и клиент может указывать кодировки, которые он принимает. UTF-8 сегодня является набором символов по умолчанию.
Таким образом, это означает , что там, вы найдете éнаписанные , как é, так éкак UTF-8 é, (0xC3 0xa9), в ISO-8859-1 (0xe9), с за 2 последних из них, иногда информацию о кодировке в заголовках HTTP или в заголовках HTML (в разных форматах), иногда нет.
wget он получает только необработанные байты, не заботится об их значении в качестве символов и не сообщает веб-серверу о предпочтительной кодировке.
recode html..позаботится о том, чтобы преобразовать éили éв правильную последовательность байтов для набора символов, используемого в вашей системе, но в остальном это сложнее.
Если ваша системная кодировка UTF-8, скорее всего, в большинстве случаев она будет в порядке, так как обычно она используется по умолчанию.
$ 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
Это éвыше было UTF-8 é.
Но если вы хотите прикрыть другие кодировки, еще раз об этом нужно позаботиться.
Следует также отметить, что это решение не будет работать вообще для страниц в кодировке UTF-16 или UTF-32.
Подводить итоги
В идеале, то, что вам нужно здесь, это настоящий веб-браузер, чтобы дать вам информацию. То есть вам нужно что-то сделать для HTTP-запроса с правильными параметрами, правильно интерпретировать HTTP-ответ, полностью интерпретировать HTML-код, как браузер, и вернуть заголовок.
Поскольку я не думаю, что это можно сделать в командной строке с браузерами, которых я знаю (хотя теперь посмотрите на этот трюкlynx ), вам придется прибегнуть к эвристике и аппроксимациям, и приведенный выше вариант хорош как любой.
Вы также можете принять во внимание производительность, безопасность ... Например, чтобы охватить все случаи (например, веб-страницу, на которой есть некоторый JavaScript, извлеченный из стороннего сайта, который устанавливает заголовок или перенаправляет на другую страницу в onload hook), вам, возможно, придется реализовать реальный браузер с его механизмами dom и javascript, которым, возможно, придется выполнять сотни запросов для одной HTML-страницы, некоторые из которых пытаются использовать уязвимости ...
Хотя использование регулярных выражений для анализа HTML часто вызывает недовольство , здесь приведен типичный случай, когда этого достаточно для выполнения задачи (IMO).