Je viens de remarquer que les longues URL compliquées de Facebook ressemblent à ceci:
http://www.facebook.com/example.profile#!/pages/Another-Page/123456789012345
Pour autant que je puisse m’en souvenir, au début de cette année, il ne s’agissait que d’une chaîne normale ressemblant à un fragment d’URL (commençant par #
), sans le point d’exclamation. Mais maintenant c’est un shebang ou hashbang ( #!
), Que j’ai déjà vu auparavant dans les scripts shell et les scripts Perl.
Les nouvelles URL Twitter comportent désormais également le #!
symboles. Par exemple, une URL de profil Twitter ressemble maintenant à ceci:
http://twitter.com/#!/BoltClock
Est-ce que #!
jouer maintenant un rôle particulier dans les URL, comme pour un certain framework Ajax ou quelque chose depuis que les nouvelles interfaces Facebook et Twitter sont maintenant largement Ajaxifiées? Est-ce que l’utilisation de cette fonctionnalité dans mes URL serait bénéfique pour mon application Web?
Cette technique est maintenant obsolète .
Cela indiquait à Google comment indexer la page.
https://developers.google.com/webmasters/ajax-crawling/
Cette technique a surtout été supplantée par la possibilité d’utiliser l’API d’historique JavaScript qui a été introduite avec HTML5. Pour une URL telle que www.example.com/ajax.html#!key=value
, Google vérifie l’URL www.example.com/ajax.html?_escaped_fragment_=key=value
pour récupérer une version non-AJAX du contenu.
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 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 que vous pouvez accéder 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_Turing
identifie la page et Early_computers_and_the_Turing_test
est l’ancre. La raison pour laquelle Facebook et d’autres applications basées sur Javascript (comme mes propres Wood & Stones ) utilisent des ancres est qu’ils veulent rendre les pages marquables (comme suggéré par un commentaire sur cette réponse) ou supporter le bouton Retour sans recharger la page entière. serveur .
Afin de prendre en charge le signet et le bouton Retour, vous devez modifier l’URL. Toutefois, si vous modifiez la partie de page (avec quelque chose comme window.location = 'http://raganwald.com';
) sur une URL différente ou sans spécifier une ancre, le navigateur chargera la page entière à partir de l’URL. Essayez ceci dans la console Javascript de Firebug ou Safari. Chargez http://minimal-github.gilesb.com/raganwald
. Maintenant dans la console Javascript, tapez:
window.location = 'http://minimal-github.gilesb.com/raganwald';
Vous verrez la page rafraîchir à partir du serveur. Maintenant tapez:
window.location = 'http://minimal-github.gilesb.com/raganwald#try_this';
Aha! Aucune page à rafraîchir! Type:
window.location = 'http://minimal-github.gilesb.com/raganwald#and_this';
Toujours pas de rafraîchissement. Utilisez le bouton Précédent pour vérifier que ces URL se trouvent dans l’historique du navigateur. Le navigateur remarque que nous sums 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 apparaissant au navigateur sur une seule page, mais avec de nombreuses sections pouvant être mises en signet qui respectent le bouton Retour. L’application doit changer l’ancre lorsqu’un utilisateur entre différents «états», et 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 créer des applications qui peuvent être mises en signet, indexables et avec un bouton arrière. Cette technique a un nom: c’est une interface de page unique .
ps Cette technique présente un quasortingème avantage: charger du contenu de 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 «bang» ou point d’exclamation est un indice supplémentaire pour le robot d’indexation de Google selon lequel la même page 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 par le serveur, puis à utiliser un Javascript non intrusif pour le transformer en SPI avec une ancre.
Voici à nouveau le lien clé: le manifeste de l’interface à page unique
Tout d’abord: je suis l’auteur du Manifeste d’interface The Single Page cité par raganwald
Comme l’explique très bien Raganwald, l’aspect le plus important de l’approche par interface de page unique utilisée dans FaceBook et Twitter est l’utilisation de hash #
dans les URL.
Le personnage !
est ajouté uniquement à des fins Google, cette notation est un «standard» Google pour l’exploration de sites Web intensifs sur AJAX (dans les sites Web extrêmes de l’interface à une seule page). Lorsque le robot d’exploration de Google trouve une URL avec #!
il sait qu’une alternative URL classique existe fournissant la même page “state” mais dans ce cas au temps de chargement.
Malgré #!
la combinaison est très intéressante pour le référencement, elle est uniquement supscope par Google (pour autant que je sache), avec quelques astuces JavaScript, vous pouvez créer des sites Web SPI compatibles avec tout robot d’indexation Web (Yahoo, Bing …).
Le Manifeste SPI et les démonstrations n’utilisent pas le format de Google !
dans les hachages, cette notation pourrait être facilement ajoutée et l’parsing de SPI pourrait être encore plus facile (la notation UPDATE: now! est utilisée et rest compatible avec les autres moteurs de recherche).
Jetez un coup d’œil à ce tutoriel , est un exemple de site ItsNat SPI simple, mais vous pouvez choisir des idées pour d’autres frameworks, cet exemple est compatible avec le référencement pour tout robot d’indexation Web.
Le problème difficile est de générer n’importe quel (ou sélectionné) “état de la page AJAX” en tant que HTML simple pour le référencement, dans ItsNat est très simple et automatique, le même site est à la fois SPI ou page 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 page basée sur le référencement, par exemple Twitter utilise cette technique de “double site”.
Je ferais très attention si vous envisagez d’adopter cette convention du hashbang.
Une fois que vous avez hashbang, vous ne pouvez pas revenir en arrière. C’est probablement le problème le plus grave. Le post de Ben a mis en avant le fait que lorsque pushState est plus largement adopté, nous pouvons laisser des hashbangs et retourner aux URL traditionnelles. Eh bien, le fait est que vous ne pouvez pas. Plus tôt, j’ai déclaré que les URL étaient éternelles, qu’elles étaient indexées et archivées et généralement conservées. Pour append à cela, les URL cool ne changent pas. Nous ne voulons pas nous déconnecter de tous les liens utiles vers notre contenu. Si vous avez implémenté des URL hashbang à un moment donné, vous pouvez les changer sans casser les liens. La seule façon de le faire est d’exécuter du code JavaScript sur le document racine de votre domaine. Pour toujours. Ce n’est pas temporaire, vous êtes coincé avec ça.
Vous voulez vraiment utiliser pushState au lieu de hashbangs , car rendre vos URL moche et peut-être cassé – pour toujours – est un inconvénient colossal et permanent des hashbangs.
Pour avoir un bon suivi de tout cela, Twitter – l’un des pionniers des URL de hashbang et de l’interface à une seule page – a admis que le système de hashbang était lent à long terme et qu’il avait commencé à revenir sur sa décision. liens de la vieille école.
L’article à ce sujet est ici.
J’ai toujours supposé 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 semblerait que l’API Google AJAX Crawling l’aime bien.
Le hachage, bien sûr, indique simplement qu’il n’ya pas de rechargement de page réel, alors oui, c’est pour AJAX. Edit: Raganwald fait un beau travail en expliquant cela plus en détail.
Les réponses ci-dessus décrivent bien pourquoi et comment il est utilisé sur twitter et facebook, ce qui me manque, c’est l’explication de ce que #
fait par défaut …
Sur une «application normale» (pas une application sur une seule page), vous pouvez faire un ancrage avec un hash
pour tout élément ayant un identifiant en plaçant cet élément dans l’URL après le hachage #
Exemple:
(sur Chrome) Cliquez sur l’ Inspect element
F12 ou Rihgt Mouse and Inspect element
alors prenez id="answer-10831233"
et ajoutez à url comme suit
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 (#!) 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 contradictoire … bien que je ne perdrais pas mon sumil … depuis Angular, c’est devenu un peu un standard ….