As expressões regulares podem ser usadas em URLs durante a navegação?

Question

Estou ciente do Google Dorks que usa operadores avançados para pesquisar palavras-chave na Web, e o Google Dorks não é o Regex de qualquer maneira.

Por curiosidade tentei colocar caracteres curingas em URLs principalmente para imagens em vários sites que não funcionaram. A maioria deles mostrou vários códigos de erro HTTP, com exceção de 2 a 3 que foram redirecionados para outra página do site.

Alguns exemplos que não funcionaram:

• Pesquisando PDFs. Obteve 404 : Page Not Found

• Procurandoporimagens.Obteve500:InternalServerError

• ProcurandoportodasaspáginasHTMLnosite.Páginasimplesmenteerro

• OYouTubeconvertecaracteresemcaractereshexadecimaisseguros.

Umexemploquefuncionou(NoIdeahow):

• link

• link

VejaaseçãoQuestionTaggedàdireitadapáginaparavertodasaspesquisasdapalavralin*

PeçodesculpasSeaperguntativermuitosdetalhes,masconsideroapropriadodaralgunsexemplos.Então,aquiconcluominhapergunta:

1. AsexpressõesregularespodemserusadasdealgumaformaemURLsduranteanavegação?

2. Sesim,quaissãoasregrasoumétodosparausá-las?

3. Alémdisso,a seção Usos na página da Wikipédia para expressões regulares cita isso:

   While regexes would be useful on Internet search engines, processing them across the entire database could consume excessive computer resources depending on the complexity and design of the regex. Although in many cases system administrators can run regex-based queries internally, most search engines do not offer regex support to the public. Notable exceptions: Google Code Search, Exalead. Google Code Search has been shut down as of January 2012.[39] It used a trigram index to speed queries.[40]

   Então, é como se pudéssemos fazer uma pesquisa Regex nos mecanismos de pesquisa, mas não em páginas da Web?

Answer 1

Geralmente, não. (Também curingas e expressões regulares não são a mesma coisa.)

Cada site decide completamente por seu como o caminho e a consulta devem ser interpretados. Os caminhos podem corresponder aos arquivos reais ou podem mapear recursos abstratos como "perguntas" ou "postagens". (por exemplo, SuperUser na verdade não tem uma pasta chamada questions cheia de subpastas numeradas - o caminho apenas informa a resposta a ser gerada.)

Isso também significa que cada site decide se ele suportará curingas (ou expressões regulares ou qualquer outro método de filtragem) ou não. Geralmente, adicionar esse recurso precisaria de programação adicional no site.

Como você descobriu, o Super User implementou curingas para a navegação de tags - é útil encontrar todas as perguntas relacionadas ao Windows (e provavelmente foi mais fácil implementá-las do que as tags hierárquicas).

Mas, por exemplo, os IDs de vídeos do YouTube são totalmente aleatórios, então não adianta tentar listar todos os vídeos cujos IDs começam com RgK... ou qualquer outro prefixo. O YouTube não implementou isso.

Webservers "simples", que servem apenas arquivos .html comuns, poderiam implementar esse recurso, pois geralmente eles têm listas automáticas de diretórios. No entanto, muitos proprietários de sites não querem isso - eles podem ter páginas "não listadas" que são conhecidas apenas por algumas pessoas, por exemplo.

(Existe um recurso semelhante no Apache httpd, que permite obter uma lista completa de diretórios mesmo se um arquivo index.html estiver presente. Mas ele deve ser desativado por padrão, porque muitas pessoas na verdade, confie em index.html como um método confiável para desativar essas listagens.)