wget -qO- 'http://www.youtube.com/watch?v=Dd7dQh8u4Hc' |
perl -l -0777 -ne 'print $1 if /<title.*?>\s*(.*?)\s*<\/title/si'
Puoi inviarlo a GNU recodese ci sono cose come <:
wget -qO- 'http://www.youtube.com/watch?v=Dd7dQh8u4Hc' |
perl -l -0777 -ne 'print $1 if /<title.*?>\s*(.*?)\s*<\/title/si' |
recode html..
Per rimuovere la - youtubeparte:
wget -qO- 'http://www.youtube.com/watch?v=Dd7dQh8u4Hc' |
perl -l -0777 -ne 'print $1 if /<title.*?>\s*(.*?)(?: - youtube)?\s*<\/title/si'
Per evidenziare alcune delle limitazioni:
portabilità
Non esiste un comando standard / portatile per eseguire query HTTP. Qualche decennio fa, avrei raccomandato lynx -sourceinvece qui. Ma al giorno d'oggi, wgetè più portatile in quanto può essere trovato di default sulla maggior parte dei sistemi GNU (incluso la maggior parte dei sistemi operativi desktop / laptop basati su Linux). Altri abbastanza portabili includono il GETcomando che viene fornito con perlil libwww che viene spesso installato e lynx -source, in misura minore curl. Altri comuni quelli includono links -source, elinks -source, w3m -dump_source, lftp -c cat...
Protocollo HTTP e gestione del reindirizzamento
wgetpotrebbe non avere la stessa pagina di quella visualizzata ad esempio firefox. Il motivo è che i server HTTP possono scegliere di inviare una pagina diversa in base alle informazioni fornite nella richiesta inviata dal client.
La richiesta inviata da wget / w3m / GET ... sarà diversa da quella inviata da Firefox. Se questo è un problema, puoi modificare il wgetcomportamento per cambiare il modo in cui invia la richiesta con le opzioni.
I più importanti qui a questo proposito sono:
Accepte Accept-language: questo indica al server in quale lingua e set di caratteri il client vorrebbe ottenere la risposta. wgetNon ne invia nessuna per impostazione predefinita, quindi il server in genere invia con le sue impostazioni predefinite. firefoxdall'altro lato è probabilmente configurato per richiedere la tua lingua.User-Agent: identifica l'applicazione client sul server. Alcuni siti inviano contenuti diversi in base al client (anche se ciò è principalmente per le differenze tra le interpretazioni del linguaggio javascript) e possono rifiutare di servirti se stai utilizzando un agente utente di tipo robot come wget.Cookie: se hai già visitato questo sito, il tuo browser potrebbe avere cookie permanenti per questo. wgetno.
wgetseguiranno i reindirizzamenti quando saranno eseguiti a livello di protocollo HTTP, ma poiché non guarda il contenuto della pagina, non quelli fatti da JavaScript o cose del genere <meta http-equiv="refresh" content="0; url=http://example.com/">.
Performance / efficienza
Qui, per pigrizia, abbiamo perlletto l'intero contenuto in memoria prima di iniziare a cercare il <title>tag. Dato che il titolo si trova nella <head>sezione che si trova nei primi byte del file, non è ottimale. Un approccio migliore, se GNU awkè disponibile sul tuo sistema potrebbe essere:
wget -qO- 'http://www.youtube.com/watch?v=Dd7dQh8u4Hc' |
gawk -v IGNORECASE=1 -v RS='</title' 'RT{gsub(/.*<title[^>]*>/,"");print;exit}'
In questo modo, awk smette di leggere dopo il primo </titlee, uscendo, fa wgetinterrompere il download.
Analisi dell'HTML
Qui, wgetscrive la pagina mentre la scarica. Allo stesso tempo, perlassorbe l' -0777 -nintero output ( ) in memoria e quindi stampa il codice HTML che si trova tra le prime occorrenze di <title...>e </title.
Funzionerà con la maggior parte delle pagine HTML che hanno un <title>tag, ma ci sono casi in cui non funzionerà.
Al contrario, la soluzione di coffeeMug analizzerà la pagina HTML come XML e restituirà il valore corrispondente per title. È più corretto se la pagina è garantita come XML valido . Tuttavia, non è necessario che l'HTML sia un codice XML valido (non lo erano le versioni precedenti della lingua) e poiché la maggior parte dei browser là fuori sono indulgenti e accettano codice HTML errato, c'è anche un sacco di codice HTML errato là fuori.
Sia la mia soluzione che quella di CoffeeMug falliranno per una varietà di casi angolari, a volte uguali, a volte no.
Ad esempio, il mio fallirà su:
<html><head foo="<title>"><title>blah</title></head></html>
o:
<!-- <title>old</title> --><title>new</title>
Mentre la sua volontà fallirà:
<TITLE>foo</TITLE>
(html valido, non xml) o:
o:
<title>...</title>
...
<script>a='<title>'; b='</title>';</script>
(di nuovo, parti htmlmancanti <![CDATA[e valide per renderlo XML valido).
<title>foo <<<bar>>> baz</title>
(HTML non corretto, ma ancora scoperto e supportato dalla maggior parte dei browser)
interpretazione del codice all'interno dei tag.
Tale soluzione genera il testo non elaborato tra <title>e </title>. Normalmente, non dovrebbero esserci tag HTML, potrebbero esserci dei commenti (anche se non gestiti da alcuni browser come Firefox in modo molto improbabile). Potrebbe esserci ancora della codifica 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
Di cui si occupa 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
Ma un client web ha anche lo scopo di fare più trasformazioni su quel codice quando visualizza il titolo (come condensare alcuni degli spazi vuoti, rimuovere quelli iniziali e finali). Tuttavia è improbabile che ce ne sia bisogno. Quindi, come negli altri casi, sta a te decidere se valga la pena.
Set di caratteri
Prima di UTF-8, iso8859-1 era il set di caratteri preferito sul web per i caratteri non ASCII anche se a rigor di termini dovevano essere scritti come é. Versioni più recenti di HTTP e del linguaggio HTML hanno aggiunto la possibilità di specificare il set di caratteri nelle intestazioni HTTP o nelle intestazioni HTML e un client può specificare i set di caratteri che accetta. Oggi UTF-8 tende a essere il set di caratteri predefinito.
Quindi, ciò significa che là fuori troverai éscritte come é, come é, come UTF-8 é, (0xc3 0xa9), come iso-8859-1 (0xe9), con per le ultime 2, a volte le informazioni sul set di caratteri nelle intestazioni HTTP o nelle intestazioni HTML (in diversi formati), a volte no.
wget ottiene solo i byte grezzi, non si preoccupa del loro significato come caratteri e non dice al server web il set di caratteri preferito.
recode html..si occuperà di convertire éo énella sequenza corretta di byte per il set di caratteri utilizzato nel sistema, ma per il resto è più complicato.
Se il tuo set di caratteri di sistema è utf-8, è probabile che vada bene per la maggior parte del tempo in quanto tende ad essere il set di caratteri predefinito usato al giorno d'oggi.
$ 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
Quello ésopra era un UTF-8 é.
Ma se vuoi coprire per altri set di caratteri, ancora una volta, dovrebbe essere curato.
Va anche notato che questa soluzione non funzionerà affatto per le pagine codificate UTF-16 o UTF-32.
Per riassumere
Idealmente, quello che ti serve qui, è un vero browser web per darti le informazioni. Cioè, è necessario qualcosa per eseguire la richiesta HTTP con i parametri corretti, interpretare correttamente la risposta HTTP, interpretare completamente il codice HTML come farebbe un browser e restituire il titolo.
Dato che non credo che ciò possa essere fatto sulla riga di comando con i browser che conosco (anche se vedi ora questo trucco conlynx ), devi ricorrere a euristiche e approssimazioni, e quella sopra è buona come una qualsiasi.
Potresti anche prendere in considerazione le prestazioni, la sicurezza ... Ad esempio, per coprire tutti i casi (ad esempio, una pagina web che ha un javascript estratto da un sito di terze parti che imposta il titolo o reindirizza a un'altra pagina in un onload hook), potresti dover implementare un browser di vita reale con i suoi motori dom e javascript che potrebbero dover fare centinaia di query per una singola pagina HTML, alcune delle quali cercano di sfruttare le vulnerabilità ...
Mentre l' utilizzo di regexps per analizzare l'HTML è spesso disapprovato , ecco un caso tipico in cui è abbastanza buono per l'attività (IMO).