À quoi sert le shebang / hashbang (#!) Dans Facebook et les nouvelles URL Twitter?


743

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

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

Pour autant que je me souvienne, au début de cette année, c'était juste une chaîne normale de type fragment d'URL (commençant par #), sans le point d'exclamation. Mais maintenant c'est un shebang ou hashbang ( #!), que je n'ai vu auparavant que dans les scripts shell et les scripts Perl.

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

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

Joue-t-il #!maintenant un rôle spécial dans les URL, 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 cela dans mes URL bénéficierait à mon application Web de quelque manière que ce soit?


130
Hmm. J'ai dû chercher ce qui shebangétait ... en.wikipedia.org/wiki/Shebang_%28Unix%29
JYelton

32
FWIW, ce ne sont pas seulement des scripts shell et perl, mais tout script exécuté sur un système de type Unix. Le #! ligne indique au shell ce que l'interprète de ce script est ... bien sûr, mon commentaire n'a rien à voir avec facebook ou twitter
bluesmoon

3
Merci, Hacker News! (en laissant un commentaire pour ne pas cogner ma question, je ne vois pas la nécessité)
BoltClock

15
Le hashbang est glorifié pour toutes les mauvaises raisons, il rompt les meilleures pratiques et détruit les chances d'amélioration progressive et de dégradation gracieuse. Veuillez utiliser les autres solutions disponibles.
balupton

2
Notez qu'en octobre 2015, Google a déprécié le hashbang qu'il avait introduit en 2009 ! Ainsi, pour les nouvelles applications, vous ne devriez plus avoir à le faire pour le référencement. À l'heure actuelle, il n'y a qu'une remarque subtile en blanc en haut des pages de spécifications de Google: "Cette recommandation est officiellement obsolète depuis octobre 2015."
Bart

Réponses:


483

Cette technique est désormais obsolète .

Cela indiquait à 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 qui a été 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=valuepour récupérer une version non AJAX du contenu.


16
Etes-vous sûr que c'est tout ce qu'il y a à faire? Je trouve souvent que le chargement de la page se bloque sur une URL shebang sur facebook (même après de nombreux rechargements), mais si vous supprimez manuellement le # !, cela fonctionne. Sans oublier que vous obtenez souvent «1,5 URL» (c'est-à-dire que l'ancienne URL reste, et que la nouvelle partie y est ajoutée (par exemple, photo.php? Id = ... deux fois, mais avec des identifiants différents). Sans parler de cela » #! "est également ajouté aux URL de Facebook, qui ne sont probablement pas (et ne devraient pas être) indexables. En tout cas, je trouve le shebang extrêmement ennuyeux car il semble être la raison de tant de défauts de page sur mon lent ligne de la maison.
Pedery

11
Le fait que Facebook ait des bogues ne fait pas de ces bogues la faute de deux caractères dans l'URL. Si le site est codé correctement pour les comprendre et les générer, les URL AJAX explorables sont assez pratiques. De nombreuses autres choses sur Facebook se révèlent également.
ceejayoz

15
@Pedery: Je n'ai jamais vu ce problème qu'avec Facebook. Je suis d'accord, cela me fait monter le mur (non-Facebook) tout le temps.
BoltClock

5
Quant aux moteurs de recherche, avoir une URL AJAX indexable ne fait pas indexer la page plus que d'avoir une URL non AJAX indexable . Facebook utilise ce format d'URL pour plus que le simple avantage de Google - il rend également les pages accessibles via AJAX sur Facebook marquables alors qu'elles ne le seraient pas autrement.
ceejayoz

13
Pour quelques mises en garde intéressantes, lisez également cet article: isolani.co.uk/blog/javascript/BreakingTheWebWithHashBangs
Michael Stum

215

L'octothorpe / numéro-signe / 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 qui suit le hachage est la partie d' ancrage d'une URL. Si vous utilisez Wikipedia, vous verrez que la plupart des pages ont une table des matières et vous pouvez passer aux sections du document avec une ancre, telles que:

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

https://en.wikipedia.org/wiki/Alan_Turingidentifie la page et Early_computers_and_the_Turing_testconstitue l'ancre. La raison pour laquelle Facebook et d'autres applications Javascript (comme mes propres Wood & Stones ) utilisent des ancres est qu'elles veulent rendre les pages marquables (comme suggéré par un commentaire sur cette réponse) ou soutenir le bouton de retour sans recharger la page entière à partir du serveur .

Afin de prendre en charge les signets et le bouton de retour, vous devez modifier l'URL. Cependant, si vous modifiez 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 page entière à partir de l'URL. Essayez ceci dans Firebug ou la console 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 la page s'actualiser à partir du serveur. Tapez maintenant:

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

Ah! Pas de rafraîchissement de page! Type:

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

Toujours pas de rafraîchissement. Utilisez le bouton de retour pour voir que ces URL sont dans l'historique du navigateur. Le navigateur remarque que nous sommes sur la même page mais que nous changeons simplement l'ancre, donc il ne se recharge pas. Grâce à ce comportement, nous pouvons avoir une seule application Javascript qui apparaît au navigateur comme étant sur une 'page' mais ayant de nombreuses sections pouvant être mises en signet qui respectent le bouton de retour. L'application doit changer l'ancre lorsqu'un utilisateur entre dans différents `` états '', et de même si un utilisateur utilise le bouton de retour ou un signet ou un lien pour charger l'application avec une ancre incluse, l'application doit restaurer l'état approprié.

Donc, vous l'avez: les ancres fournissent aux programmeurs Javascript un mécanisme pour créer des applications pouvant être mises en signet, indexables et compatibles avec les boutons de retour. Cette technique a un nom: il s'agit d'une interface à page unique .

ps Il existe un quatrième avantage à cette technique: charger le contenu d'une page via AJAX puis l'injecter dans le DOM actuel 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.

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

Voici à nouveau le lien clé: le manifeste d'interface à page unique


14
"Cependant, une application sans cette optimisation est toujours explorable si le robot d'indexation souhaite l'indexer." Pas vraiment. Le hachage n'est pas envoyé au serveur.
Chris Broadfoot

7
juste pour information: self.document.location.hashfournit la valeur de ce hachage
Kevin

12
Le hachage n'est pas envoyé au serveur. Bonne prise!
raganwald

36
Toute cette réponse, à l'exception du seul paragraphe «pps», est redondante.
Courses de légèreté en orbite le

21
@imaginonic: Je suis en retard, mais aussi parfaitement conçu comme il est, 90% de celui - ci ne touche pas à l' #!aspect de ma question du tout . C'est pourquoi il a dit que c'était redondant. Le nombre de votes positifs ici est probablement dû au trafic élevé lorsque ma question est parvenue à Hacker News, couplée à la seule longueur de cette réponse.
BoltClock

111

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

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

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

Malgré la #!combinaison est très intéressante pour le référencement, est uniquement pris en charge par Google (pour autant que je sache), avec quelques astuces JavaScript, vous pouvez créer des sites Web SPI compatibles avec le référencement SEO pour n'importe quel robot d'exploration (Yahoo, Bing ...).

Le manifeste SPI et les démos n'utilisent pas le format de !hachage de Google , cette notation pourrait être facilement ajoutée et l'exploration SPI pourrait être encore plus facile (MISE À JOUR: maintenant! La notation est utilisée et reste compatible avec d'autres moteurs de recherche).

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

Le problème difficile est de générer n'importe quel (ou sélectionné) "état de page AJAX" en HTML simple pour le référencement, dans ItsNat est très facile et automatique, le même site est en même temps SPI ou page basée sur 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 page est basée sur le référencement, par exemple Twitter utilise cette technique de "double site".


3
Qu'en est-il du principe d'amélioration progressive? Le site Web ne devrait pas tomber en panne en raison du JavaScript désactivé. Et croyez-moi, javascript est désactivé non seulement dans les navigateurs obsolètes, mais aussi par de nombreux utilisateurs soucieux de la sécurité qui n'aiment pas exécuter JS au hasard.
Roman Royter

88

Je serais très prudent si vous envisagez d'adopter cette convention de hashbang.

Une fois que vous avez hashbang, vous ne pouvez pas revenir en arrière. C'est probablement le problème le plus délicat. Le billet de Ben a souligné que lorsque pushState est plus largement adopté, nous pouvons laisser les hashbangs et revenir aux URL traditionnelles. Eh bien, le fait est que vous ne pouvez pas. Plus tôt, j'ai déclaré que les URL sont éternelles, qu'elles sont indexées et archivées et généralement conservées. Pour ajouter à cela, les URL sympas ne changent pas. Nous ne voulons pas nous déconnecter de tous les liens précieux vers notre contenu. Si vous avez implémenté des URL de hachage à un moment donné, vous souhaitez les modifier 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 en aucun cas temporaire, vous êtes coincé avec ça.

Vous voulez vraiment utiliser pushState au lieu de hashbangs , car rendre vos URL laides et éventuellement cassées - pour toujours - est un inconvénient colossal et permanent des hashbangs.


Je pense que votre critique des hashbangs est valide, mais en utilisant simplement pushState comme substitut, nous perdrions la possibilité de charger du contenu dans une application d'une seule page en fonction de l'URL. Les URL ne peuvent donc pas être partagées.
Luke

J'ai eu un problème similaire dans mon travail - nous avons utilisé l'utilisation de Page.js (qui utilise pushState) pour la navigation sur une seule page, alors que nous utilisions auparavant Hasher et Crossroads (hash-bashed). En conséquence, nous devions sauver des chemins comme /blah#foo/feep/baz?stuff=nonsense. Le nouveau chemin équivalent serait /blah/foo/feep/baz?stuff=nonsense(note # remplacée par /). Je l'ai fait simplement en ayant un itinéraire dans ma configuration qui a attrapé /blahet vérifié s'il avait un, si oui, en ajoutant le contenu de ce hachage après une barre oblique. Sauvé.
Gert Sønderby

16

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

L'article à ce sujet est ici.


9

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

Le hachage, bien sûr, indique simplement qu'aucun rechargement de page réel ne se produit, donc oui, c'est à des fins AJAX. Edit: Raganwald fait un beau travail en expliquant cela plus en détail.


-2

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

Sur une application `` normale '' (pas une seule page), vous pouvez ancrer avec hashn'importe quel élément qui a id en plaçant cet élément id dans l'url après le hachage#

Exemple:

(sur Chrome) Cliquez sur F12ou Rihgt MouseetInspect element

entrez la description de l'image ici

puis prenez id="answer-10831233"et ajoutez à l'url comme suit

/programming/3009380/whats-the-shebang-hashbang-in-facebook-and-new-twitter-urls-for#answer-10831233

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

À quoi sert le shebang / hashbang (#!) Dans Facebook et les nouvelles URL Twitter?

En utilisant #d'une manière décrite dans les réponses ci-dessus, vous introduisez un comportement conflictuel ... bien que je ne perdrais pas le sommeil dessus ... depuis Angular, il est devenu quelque peu une norme ...


2
La réponse de Raganwald contient l'explication que vous avez dit avoir manquée. Même ainsi, je ne vois pas comment la question bénéficie d'un tutoriel sur le fonctionnement de # - la question suppose que le lecteur est déjà familier avec les fragments d'URL, et que cette fonctionnalité n'est pas vraiment pertinente ici de toute façon, à l'exception de votre remarque sur les comportements conflictuels .
BoltClock

@BoltClock Salut BoltClock, mais sans expliquer quel est le comportement par défaut en disant `` ça va entrer en conflit '' ne donne aucune idée au lecteur de ce qui est en jeu, quel type de fonctionnalité est potentiellement perdu ... J'aime juste donner de jolies réponses avec des photos si Je vois qu'il manque quelque chose d'aussi complet que je peux les faire ...
Matas Vaitkevicius
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.