Muitos navegadores CLI / TUI possuem recursos de visualização de código-fonte integrados. No Lynx ou Links, a função de atalho para exibir a origem é \ . No w3m é v . Para outros navegadores, consulte a documentação relevante.
Eu já ouvi falar de lynx e links e outros navegadores baseados em texto e eles são bons, mas eu quero obter as mesmas informações que eu veria executando View Page Source no Firefox, por exemplo. (O IE e o Chrome têm suas próprias funcionalidades semelhantes.)
É possível visualizar essa fonte via Terminal (ou CLI) navegando até a página em um aplicativo baseado em terminal ou usando comandos? Isso não é tão simples quanto usar wget em uma página, pois isso não preencherá informações com script (.cgi, .php, .js, etc.).
Muitos navegadores CLI / TUI possuem recursos de visualização de código-fonte integrados. No Lynx ou Links, a função de atalho para exibir a origem é \ . No w3m é v . Para outros navegadores, consulte a documentação relevante.
Existem duas maneiras fáceis de obter o que você deseja (o texto retornado por, por exemplo, view-source: )
wget (disponível no Windows com o GnuWin32 wget package ).
Python com terceiros Solicita o módulo (que também funciona no Windows).
Supondo que o Python esteja instalado, você pode obter Solicitações usando pip (com algo como python -m pip install requests ) ou pode visitar os Solicita a página do PyPi .
Observe que, em ambos os casos, você deve reservar um momento para escolher uma string User-Agent adequada. Você pode "Qual é minha string de agente de usuário?" do Google em qualquer navegador que você deseja emular para ver a string atual do User-Agent associada ao seu navegador da GUI.
wget
Como sugerido por @Attie e @ivanivan, wget pode recuperar a mesma fonte exibida por um navegador da GUI com ex. :
wget -O pagesource.html -U "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:54.0) Gecko/20100101 Firefox/54.0" --no-check-certificate https://www.google.com
No exemplo acima, -O (a opção do arquivo de saída) e -U (a opção de string User-Agent) são a chave para recuperar o mesmo formato que você pode ter, digamos, no Firefox. Este método tem a pequena desvantagem de que você precisará para exibir ex. pagesource.html na linha de comando você mesmo.
Python
Sua outra opção é usar o Python com solicitações, como já mencionado.
Para obter a origem da página atual, como visto com, por exemplo, view-source: , crie um script semelhante ao seguinte:
import requests
user_agent = {'User-Agent': 'Mozilla/5.0 (Windows NT 6.1; WOW64; rv:54.0) Gecko/20100101 Firefox/54.0'}
url = 'https://www.google.com'
response = requests.get(url, headers = user_agent)
print(response.text)
Você salva este script como algo como pagesource.py , em seguida, o chama na linha de comando ex. :
python pagesource.py | more
more simplesmente impede que a página inteira seja descartada de uma só vez. Vale a pena mencionar que os objetos de resposta têm um atributo content (que é muito semelhante a text para nossos propósitos), mas text neste caso emula mais de perto o que é retornado por um navegador da GUI ao visualizar o código-fonte de uma página. / p>
Processamento de páginas
This isn't as simple as using
wgeton a page, as that won't fill scripted info (.cgi,.php,.js, etc.).
As páginas renderizadas por meio de scripts do lado do servidor ( .cgi / .php em sua pergunta) têm seu código-fonte gerado como texto (ou seja, .html e JavaScript) antes sendo entregue ao navegador.
Com JavaScript, o navegador processa qualquer Javascript em uma página renderizada final (não há um formulário "intermediário"). O navegador realmente altera o código da página nesses casos (modifica o que você vê em view-source: ). Da mesma forma, o navegador toma medidas extras para seguir os links e baixar os recursos necessários (por exemplo, .css , arquivos de mídia, etc.) para exibição final.
O que isto significa é que o que você vê na "origem da página" do navegador é (em geral) exatamente o que o navegador usa para renderizar a página inicialmente. Se um link .html para um item (digamos, uma imagem ou vídeo) não existir, ele não existe (embora isso não exclua necessariamente que qualquer código JavaScript seja informativo).
Dito isso, você pode anotar e experimentar diferentes strings do User-Agent. Servidores que geram dinamicamente conteúdo geralmente o fazem com base nessas cadeias. Portanto, pelo menos teoricamente, é possível que uma página gere mais links de recursos tradicionais versus código JavaScript com base, por exemplo, em um navegador para dispositivos móveis em vez de em uma cadeia de caracteres do navegador da área de trabalho.