Qual è la baracca / hashbang (#!) Di Facebook e Twitter per nuovi URL?

Question

Ho appena notato che i Facebook URL lungo, contorto che siamo abituati ad ora assomigliare a questo:

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

Per quanto posso ricordare, all'inizio di quest'anno è stato solo un normale URL-frammento-come stringa (a partire da #), senza il punto esclamativo. Ma ora è uno shebang o hashbang (#!), che ho visto in precedenza solo in script di shell e script Perl.

Il nuovo Twitter URL ora dispongono inoltre i simboli #!. Un profilo Twitter URL, per esempio, ora si presenta così:

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

non #! ora giocare un qualche ruolo speciale nella URL, come per un certo quadro Ajax o qualcosa del genere dal momento che le nuove interfacce di Facebook e Twitter sono ormai ampiamente Ajaxified? Sarebbe utilizzare questo nei miei URL beneficio mia applicazione Web in qualche modo?

Answer 1

Questa tecnica è ora sconsigliato .

Questo utilizzato per dire a Google come indicizzare la pagina.

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

Questa tecnica è in gran parte stata soppiantata dalla possibilità di utilizzare l'API JavaScript storia che è stato introdotto a fianco di HTML5. Per un URL come www.example.com/ajax.html#!key=value, Google controllerà la www.example.com/ajax.html?_escaped_fragment_=key=value URL per recuperare una versione non-AJAX dei contenuti.

Answer 2

Il cancelletto / numero-segno / hashmark ha un significato speciale in un URL, normalmente identifica il nome di una sezione di un documento. Il termine esatto è che il testo che segue l'hash è il ancora porzione di un URL. Se si utilizza Wikipedia, si vedrà che la maggior parte delle pagine hanno un sommario e si può saltare alle sezioni all'interno del documento con un ancoraggio, come ad esempio:

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

https://en.wikipedia.org/wiki/Alan_Turing identifica la pagina e Early_computers_and_the_Turing_test è l'ancora. La ragione per cui Facebook e altre applicazioni JavaScript-driven (come il mio Legno & pietre ) uso ancore è che vogliono rendere le pagine bookmarkable (come suggerito da un commento su questa risposta) oppure appoggiare il pulsante indietro senza ricaricare l'intera pagina dal server .

Al fine di sostenere bookmarking e il pulsante indietro, è necessario modificare l'URL. Tuttavia, se si cambia la porzione di pagina (con qualcosa come window.location = 'http://raganwald.com';) a un URL diverso o senza specificare un ancoraggio, il browser caricherà l'intera pagina dall'URL. Prova questo in Firebug o Safari di console Javascript. Carico http://minimal-github.gilesb.com/raganwald. Ora nella console Javascript, tipo:

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

Si vedrà l'aggiornamento della pagina dal server. Ora digitate:

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

Aha! Nessun aggiornamento della pagina! Tipo:

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

Ancora nessuna aggiornare. Utilizzare il pulsante indietro per vedere che questi URL sono nella cronologia del browser. Gli avvisi del browser che siamo sulla stessa pagina, ma solo cambiando l'ancora, in modo che non ricaricare. Grazie a questo comportamento, si può avere una singola applicazione Javascript che appare al browser di essere su una 'pagina', ma di avere molte sezioni bookmarkable che rispettano il pulsante Indietro. La domanda deve cambiare l'ancora quando un utente inserisce diversi 'stati', e allo stesso modo se un utente utilizza il pulsante Indietro o un segnalibro o un link per caricare l'applicazione con un ancoraggio in dotazione, l'applicazione deve ripristinare lo stato appropriato.

Quindi il gioco è fatto: Ancore fornire ai programmatori JavaScript con un meccanismo per rendere memorizzabili come segnalibro, indicizzabili, e le applicazioni di back-button-friendly. Questa tecnica ha un nome:. Si tratta di una Pagina singola interfaccia

P.S. C'è un quarto vantaggio a questa tecnica: il contenuto della pagina Caricamento attraverso AJAX e poi iniettarlo nel DOM corrente può essere molto più veloce di caricare una nuova pagina. Oltre all'aumento della velocità, ulteriori trucchi come il caricamento di alcune parti in sottofondo possono essere eseguite sotto il controllo del programmatore.

p.p.s. Considerato tutto questo, il 'botto' o punto esclamativo è un ulteriore suggerimento per il crawler web di Google che la stessa pagina può essere caricata dal server in un URL leggermente diverso. Vedere Ajax Crawling . Un'altra tecnica è quella di rendere ogni punto di collegamento a un URL server accessibili e quindi utilizzare discreto Javascript per trasformarla in uno SPI con un ancoraggio.

Ecco il link di nuovo il tasto: La pagina singola interfaccia Manifesto

Answer 3

Prima di tutto: Sono l'autore del La pagina singola interfaccia Manifesto citato da raganwald

Come raganwald ha spiegato molto bene, il più importante aspetto della pagina singola interfaccia (SPI) approccio utilizzato FaceBook e Twitter è l'uso di hash # negli URL

Il ! carattere viene aggiunto solo per scopi di Google, questa notazione è uno "standard" di Google per la scansione di siti web intensivo su AJAX (nelle estreme siti web pagina singola interfaccia). Quando il crawler di Google trova un URL con #! sa che un URL convenzionale alternativa esiste fornendo la stessa pagina "Stato", ma in questo caso il tempo di caricamento.

Nonostante combinazione #! è molto interessante per la SEO, è supportato solo da Google (per quanto ne so), con alcuni trucchi JavaScript è possibile costruire siti web SPI SEO compatibile per qualsiasi crawler web (Yahoo, Bing ...) .

Lo SPI Manifesto demo e non usano il formato di Google di ! in hash, questa notazione potrebbe essere facilmente aggiunti e SPI scansione potrebbe essere ancora più semplice (UPDATE: ora la notazione viene utilizzato e rimane compatibile con altri motori di ricerca).

Date un'occhiata a questo esercitazione , è un esempio di un semplice sito ItsNat SPI, ma è possibile scegliere alcune idee per altri framework, questo esempio è SEO compatibile per qualsiasi web crawler.

Il problema difficile è quello di generare qualsiasi (o selezionato) "pagina AJAX stato" come semplice HTML per SEO, in ItsNat è molto semplice e automatico, lo stesso sito si trova nella stessa SPI tempo o pagina basata per SEO (o quando JavaScript è disabilitato per l'accessibilità). Con altri framework web si può mai seguire l'opzione doppio sito, un sito si basa SPI e un'altra pagina in base per la SEO, per esempio Twitter utilizza questa tecnica "doppio sito".

Answer 4

molto attenti se si stanno prendendo in considerazione l'adozione di questa convenzione hashbang .

  

Una volta hashbang, non si può tornare indietro. Questo è probabilmente il problema appiccicoso. Il post di Ben ha avanzato al punto che quando pushState è più ampiamente adottato allora possiamo lasciare hashbangs alle spalle e tornare a URL tradizionali. Beh, fatto è che non è possibile. In precedenza ho affermato che gli URL sono per sempre, vengono indicizzati e archiviati e generalmente mantenute intorno. Per aggiungere a questo, gli URL fresco non cambiano. Non vogliamo staccare noi stessi da tutti i link prezioso per i nostri contenuti. Se hai implementato URL hashbang in qualsiasi punto poi si desidera cambiare senza rompere i collegamenti l'unico modo si può fare è quello di eseguire alcuni JavaScript sul documento principale del tuo dominio. Per sempre. E 'in alcun modo temporaneo, si sono bloccati con esso.

Si vuole veramente pushState invece di hashbangs , perché fare gli URL brutto e possibilmente rotto - per sempre -. è un colossale e svantaggio permanente hashbangs

Answer 5

Per avere un buon follow-up di tutto questo, Twitter - uno dei pionieri della URL hashbang di e singola pagina interfaccia - ammesso che il sistema hashbang era lento nel lungo periodo e che hanno effettivamente iniziato invertire la decisione e il ritorno a legami di vecchia scuola.

articolo su questo è qui.

Answer 6

Ho sempre assunto il ! appena indicato che il frammento hash che seguirono corrisponde a un URL, con ! prendendo il posto della radice sito o dominio. Potrebbe essere qualsiasi cosa, in teoria, ma sembra l'API di Google AJAX Crawling piace in questo modo.

L'hash, ovviamente, solo indica che nessuna pagina vera e propria ricarica è in corso, quindi sì, è a scopo di AJAX. Modifica:. Raganwald fa un bel lavoro che spiega più in dettaglio

Answer 7

Le risposte sopra descritto bene perché e come viene utilizzato su twitter e facebook, quello che ho perso è la spiegazione che cosa # fa di default ...

In una (non una singola applicazione pagina) 'normale' si può fare con l'ancoraggio hash per ogni elemento che possiede id ponendo che gli elementi id in url dopo hash #

Esempio:

(su Chrome) Clicca F12 o rihgt mouse e Inspect element

poi prendere id="answer-10831233" e aggiungere alla url del tipo seguente

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

e si otterrà un link che salta a quella elemento della pagina

Qual è la baracca / hashbang (#!) di Facebook e Twitter per nuovi URL?

Utilizzando # in maniera descritta nelle risposte di cui sopra si stanno introducendo in conflitto comportamento ... anche se non mi perdere il sonno su di esso ... dal momento angolare è diventato un po 'di uno standard ....