Question Quel est le shebang / hashbang (#!) Sur Facebook et les nouvelles URL Twitter?


Je viens de remarquer que les longues URL Facebook compliquées que nous avons l'habitude de ressembler à ceci:

http://www.facebook.com/example.profile#!/pages/Another-Page/123456789012345

Autant que je me souvienne, plus tôt cette année, c'était juste une chaîne normale ressemblant à un fragment d'URL (commençant par #), sans le point d'exclamation. Mais maintenant c'est un shebang ou un hashbang (#!), que je n'avais vu auparavant que dans des scripts shell et des scripts Perl.

le nouveau Twitter Les URL comportent désormais également #! symboles Une URL de profil Twitter, par exemple, ressemble maintenant à ceci:

http://twitter.com/#!/BoltClock

Est-ce que #! jouent maintenant un rôle spécial dans les URLs, comme pour un certain framework Ajax ou quelque chose comme les nouvelles interfaces Facebook et Twitter sont maintenant largement Ajaxified? Est-ce que l'utilisation de ceci dans mes URL profiterait à mon application Web de quelque façon que ce soit?


725
2018-06-09 19:49


origine


Réponses:


Cette technique est maintenant obsolète.

Ce habitué Dites à Google comment indexer la page.

https://developers.google.com/webmasters/ajax-crawling/

Cette technique a été principalement supplantée par la possibilité d'utiliser l'API JavaScript History introduite avec HTML5. Pour une URL comme www.example.com/ajax.html#!key=value, Google vérifiera l'URL www.example.com/ajax.html?_escaped_fragment_=key=value pour récupérer une version non-AJAX du contenu.


477
2018-06-09 20:07



Le octothorpe / number-sign / hashmark a une signification particulière dans une URL, il identifie normalement le nom d'une section d'un document. Le terme précis est que le texte suivant le hachage est le ancre partie d'une URL. Si vous utilisez Wikipédia, vous verrez que la plupart des pages ont une table des matières et vous pouvez accéder aux sections du document avec une ancre, par exemple:

https://en.wikipedia.org/wiki/Alan_Turing#Early_computers_and_the_Turing_test

https://en.wikipedia.org/wiki/Alan_Turing identifie la page et Early_computers_and_the_Turing_test est l'ancre. La raison pour laquelle Facebook et d'autres applications axées sur Javascript (comme le mien Bois et pierres) utilisez les ancres, c'est qu'ils veulent faire des pages bookmarkable (comme suggéré par un commentaire sur cette réponse) ou soutenir le bouton de retour sans recharger toute la page à partir du serveur.

Afin de soutenir bookmarking et le bouton de retour, vous devez changer l'URL. Cependant, si vous changez la partie de la page (avec quelque chose comme window.location = 'http://raganwald.com';) vers une URL différente ou sans spécifier une ancre, le navigateur chargera la totalité de la page à partir de l'URL. Essayez ceci dans la console Firebug ou Javascript de Safari. Charge http://minimal-github.gilesb.com/raganwald. Maintenant dans la console Javascript, tapez:

window.location = 'http://minimal-github.gilesb.com/raganwald';

Vous verrez l'actualisation de la page à partir du serveur. Maintenant, tapez:

window.location = 'http://minimal-github.gilesb.com/raganwald#try_this';

Aha! Pas de rafraîchissement de la page! Type:

window.location = 'http://minimal-github.gilesb.com/raganwald#and_this';

Toujours pas d'actualisation. Utilisez le bouton Précédent pour voir que ces URL se trouvent dans l'historique du navigateur. Le navigateur remarque que nous sommes sur la même page mais change juste l'ancre, donc il ne recharge pas. Merci à ce comportement, nous pouvons avoir une seule application Javascript qui apparaît au navigateur pour être sur une «page», mais pour avoir beaucoup de sections bookmarkable qui respectent le bouton de retour. L'application doit changer l'ancre lorsqu'un utilisateur entre différents états, et de même si un utilisateur utilise le bouton Précédent ou un signet ou un lien pour charger l'application avec une ancre incluse, l'application doit restaurer l'état approprié.

Donc là vous l'avez: Les ancres fournissent aux programmeurs Javascript un mécanisme pour faire des applications bookmarkable, indexables, et back-button-friendly. Cette technique a un nom: c'est un Interface de page unique.

p.s. Il y a un quatrième avantage à cette technique: charger du contenu de page via AJAX et l'injecter dans le DOM courant peut être beaucoup plus rapide que de charger une nouvelle page. En plus de l'augmentation de la vitesse, d'autres astuces comme le chargement de certaines parties en arrière-plan peuvent être effectuées sous le contrôle du programmeur.

p.p.s. Compte tenu de tout cela, le «bang» ou point d'exclamation est un indice supplémentaire pour le robot d'indexation de Google que la même page peut être chargée à partir du serveur à une URL légèrement différente. Voir Ajax Ramper. Une autre technique consiste à faire pointer chaque lien vers une URL accessible par le serveur, puis à utiliser un Javascript discret pour le transformer en un SPI avec une ancre.

Voici le lien clé à nouveau: Le Manifeste de l'interface de page unique


214
2017-10-16 22:30



Tout d'abord: je suis l'auteur du Manifeste de l'interface à une page cité par raganwald

Comme Raganwald l'a très bien expliqué, l'aspect le plus important de l'approche Single Page Interface (SPI) utilisée dans FaceBook et Twitter est l'utilisation de hash # dans les URL

Le personnage ! est ajouté uniquement à des fins de Google, cette notation est un "standard" de Google pour l'exploration de sites Web intensifs sur AJAX (dans les sites Web extrêmes Single Page Interface). Lorsque le robot d'exploration de Google trouve une URL avec #! il sait qu'il existe une autre URL conventionnelle fournissant la même page "état" mais dans ce cas le temps de chargement.

Malgré #! La combinaison est très intéressante pour le référencement, n'est supportée que par Google (pour autant que je sache), avec quelques astuces JavaScript, vous pouvez construire des sites web SPI compatibles SEO pour tout crawler web (Yahoo, Bing ...).

Le Manifeste SPI et les démos n'utilisent pas le format de Google ! dans les hachages, cette notation pourrait être facilement ajoutée et l'exploration SPI pourrait être encore plus facile (UPDATE: la notation now! est utilisée et reste compatible avec les autres moteurs de recherche).

Jetez un coup d'oeil à cette Didacticiel, est un exemple d'un site ItsNat SPI simple mais vous pouvez choisir quelques idées pour d'autres frameworks, cet exemple est compatible avec SEO pour n'importe quel robot d'indexation.

Le problème est de générer n'importe quel "état de page AJAX" en HTML brut pour le référencement, ItsNat est très simple et automatique, le même site est dans le même temps SPI ou page basée pour le référencement (ou lorsque JavaScript est désactivé pour l'accessibilité). Avec d'autres frameworks web, vous pouvez toujours suivre l'approche du double site, un site est basé sur SPI et une autre basée sur le référencement, par exemple Twitter utilise cette technique de «double site».


110
2017-10-17 09:04



je serais très attentionné si vous envisagez d'adopter cette convention hashbang.

Une fois que vous hashbang, vous ne pouvez pas revenir en arrière. C'est probablement le problème le plus difficile. Le post de Ben a mis en avant le fait que lorsque pushState est plus largement adopté, nous pouvons abandonner les hashbangs et revenir aux URL traditionnelles. Eh bien, le fait est, vous ne pouvez pas. Plus tôt, j'ai déclaré que les URL sont pour toujours, ils sont indexés et archivés et généralement conservés. Pour ajouter à cela, les bonnes adresses ne changent pas. Nous ne voulons pas nous déconnecter de tous les liens utiles à notre contenu. Si vous avez implémenté des URL hashbang à tout moment, alors vous voulez les changer sans rompre les liens, la seule façon de le faire est d'exécuter du JavaScript sur le document racine de votre domaine. Pour toujours. Ce n'est pas temporaire, vous êtes coincé avec.

Tu veux vraiment utilisez pushState au lieu de hashbangs, parce que rendre vos URL moche et peut-être cassé - pour toujours - est un inconvénient colossal et permanent pour les hashbangs.


82
2018-02-24 21:34



Pour avoir un bon suivi sur tout cela, Twitter - l'un des pionniers des URL hashbang et de l'interface à une seule page - a admis que le système hashbang était lent à long terme et qu'ils avaient en fait commencé à inverser la décision et à revenir liens de la vieille école.

L'article à ce sujet est ici.


14
2018-05-31 09:51



J'ai toujours assumé le ! juste indiqué que le fragment de hachage qui a suivi correspondait à une URL, avec ! prenant la place de la racine du site ou du domaine. Cela pourrait être n'importe quoi, en théorie, mais il semble que l'API Crawling Google AJAX l'aime de cette façon.

Le hachage, bien sûr, indique simplement qu'il n'y a pas de véritable rechargement de page, alors oui, c'est pour AJAX. Edit: Raganwald fait un très bon travail en expliquant cela plus en détail.


9
2017-10-16 22:31



Les réponses ci-dessus décrivent bien pourquoi et comment il est utilisé sur Twitter et Facebook, ce que j'ai manqué est d'expliquer ce que # fait par défaut ...

Sur un 'normal' (pas une seule page d'application), vous pouvez faire l'ancrage avec hash à n'importe quel élément qui a id en plaçant cet ID d'éléments dans l'URL après le hachage #

Exemple: 

(sur Chrome) Cliquez sur F12 ou Rihgt Souris et Inspect element 

enter image description here

alors prenez id="answer-10831233" et ajouter à l'URL comme suivant

https://stackoverflow.com/questions/3009380/whats-the-shebang-hashbang-in-facebook-and-new-twitter-urls-for#answer-10831233

et vous obtiendrez un lien qui saute à cet élément sur la page

Quel est le shebang / hashbang (#!) Sur Facebook et les nouvelles URL Twitter?

En utilisant # d'une manière décrite dans les réponses ci-dessus vous présentez un comportement contradictoire ... bien que je ne voudrais pas perdre le sommeil par dessus ... depuis Angular c'est devenu un peu une norme ....


-1
2017-07-12 03:13