facebook - que - twitter acortador url
¿Para qué sirve el shebang/hashbang(#!) En Facebook y las nuevas URL de Twitter? (7)
El octothorpe / number-sign / hashmark tiene un significado especial en una URL, normalmente identifica el nombre de una sección de un documento. El término preciso es que el texto que sigue al hash es la parte del ancla de una URL. Si utiliza Wikipedia, verá que la mayoría de las páginas tienen una tabla de contenido y puede saltar a las secciones dentro del documento con un ancla, como:
https://en.wikipedia.org/wiki/Alan_Turing#Early_computers_and_the_Turing_test
https://en.wikipedia.org/wiki/Alan_Turing identifica la página y Early_computers_and_the_Turing_test es el ancla. La razón por la que Facebook y otras aplicaciones controladas por Javascript (como mi propia Wood & Stones ) usan anclas es que quieren que las páginas se puedan marcar (como lo sugiere un comentario en esa respuesta) o admitir el botón Atrás sin volver a cargar toda la página desde el servidor
Para admitir los marcadores y el botón Atrás, debe cambiar la URL. Sin embargo, si cambia la parte de la página (con algo como window.location = ''http://raganwald.com''; ) a una URL diferente o sin especificar un ancla, el navegador cargará toda la página desde la URL. Prueba esto en la consola de Javascript de Firebug o Safari. Cargue http://minimal-github.gilesb.com/raganwald . Ahora en la consola de Javascript, escriba:
window.location = ''http://minimal-github.gilesb.com/raganwald'';
Verá la actualización de la página desde el servidor. Ahora escribe:
window.location = ''http://minimal-github.gilesb.com/raganwald#try_this'';
Jajaja No hay actualización de la página! Tipo:
window.location = ''http://minimal-github.gilesb.com/raganwald#and_this'';
Todavía no hay actualización. Use el botón Atrás para ver que estas URL están en el historial del navegador. El navegador advierte que estamos en la misma página pero que solo cambiamos el ancla para que no se vuelva a cargar. Gracias a este comportamiento, podemos tener una única aplicación de Javascript que parece que el navegador está en una ''página'' pero que tiene muchas secciones que se pueden marcar y que respetan el botón Atrás. La aplicación debe cambiar el ancla cuando un usuario ingresa diferentes "estados", y de la misma manera si un usuario usa el botón Atrás o un marcador o un enlace para cargar la aplicación con un ancla incluida, la aplicación debe restaurar el estado apropiado.
Así que ahí lo tienen: los anclajes proporcionan a los programadores de Javascript un mecanismo para crear aplicaciones aptas para marcadores, indexables y compatibles con el botón de retroceso. Esta técnica tiene un nombre: es una interfaz de una sola página .
Esta técnica tiene un cuarto beneficio: cargar el contenido de la página a través de AJAX y luego inyectarlo en el DOM actual puede ser mucho más rápido que cargar una página nueva. Además del aumento de velocidad, otros trucos como cargar ciertas partes en el fondo pueden realizarse bajo el control del programador.
pps Dado todo eso, el ''bang'' o el signo de exclamación es otra sugerencia para el rastreador web de Google de que la misma página se puede cargar desde el servidor en una URL ligeramente diferente. Ver Ajax Crawling . Otra técnica es hacer que cada enlace apunte a una URL accesible al servidor y luego usar un Javascript discreto para convertirlo en un SPI con un ancla.
Aquí está el enlace clave de nuevo: El Manifiesto de la Interfaz de una sola página.
Acabo de notar que las largas y complicadas URL de Facebook a las que estamos acostumbrados ahora son así:
http://www.facebook.com/example.profile#!/pages/Another-Page/123456789012345
Por lo que puedo recordar, a principios de este año era solo una cadena normal similar a un fragmento de URL (comenzando con # ), sin el signo de exclamación. Pero ahora es un shebang o un hashbang ( #! ), Que anteriormente solo había visto en shell scripts y en scripts de Perl.
Las nuevas URL de Twitter ahora también incluyen el #! simbolos Una URL de perfil de Twitter, por ejemplo, ahora se ve así:
http://twitter.com/#!/BoltClock
Hace #! ¿Ahora juega algún papel especial en las URL, como para un determinado marco de Ajax o algo así, ya que las nuevas interfaces de Facebook y Twitter ahora están en gran parte Ajaxified? ¿El uso de esto en mis URL beneficiaría a mi aplicación web de alguna manera?
En primer lugar: soy el autor del Manifiesto de interfaz de una sola página citado por raganwald
Como raganwald ha explicado muy bien, el aspecto más importante del enfoque de interfaz de página única (SPI) utilizado en FaceBook y Twitter es el uso de hash # en las URL
El personaje ! se agrega solo para fines de Google, esta notación es un "estándar" de Google para el rastreo de sitios web con AJAX (en los sitios web de interfaz de página única extrema). Cuando el rastreador de Google encuentra una URL con #! sabe que existe una URL convencional alternativa que proporciona la misma página "estado" pero en este caso en el tiempo de carga.
A pesar de #! La combinación es muy interesante para SEO, solo es compatible con Google (hasta donde sé), con algunos trucos de JavaScript puede crear sitios web SPI compatibles con SEO para cualquier rastreador web (Yahoo, Bing ...).
El Manifiesto SPI y las demostraciones no utilizan el formato de Google ! en hashes, esta notación podría agregarse fácilmente y el rastreo SPI podría ser aún más fácil (ACTUALIZACIÓN: ¡ahora se utiliza la notación! y sigue siendo compatible con otros motores de búsqueda).
Eche un vistazo a este tutorial , es un ejemplo de un sitio simple de ItsNat SPI pero puede elegir algunas ideas para otros marcos, este ejemplo es compatible con SEO para cualquier rastreador web.
El problema difícil es generar cualquier (o seleccionado) "Estado de página AJAX" como HTML simple para SEO, en ItsNat es muy fácil y automático, el mismo sitio está en SPI o página basada en SEO (o cuando JavaScript está deshabilitado). por accesibilidad). Con otros marcos web puede seguir el enfoque de sitio doble, un sitio está basado en SPI y otra página basada en SEO, por ejemplo, Twitter utiliza esta técnica de "sitio doble".
Las respuestas anteriores describen bien por qué y cómo se usa en Twitter y Facebook, lo que me perdí es una explicación de lo que # hace por defecto ...
En una ''normal'' (no en una aplicación de una sola página), puede anclar con hash a cualquier elemento que tenga id colocando esa id en la url después de hash #
Ejemplo:
(en Chrome) Haga clic en F12 o en Rihgt Mouse e Inspect element
luego tome id="answer-10831233" y agregue a la url como sigue
https://.com/questions/3009380/whats-the-shebang-hashbang-in-facebook-and-new-twitter-urls-for#answer-10831233
y obtendrá un enlace que salta a ese elemento en la página
¿Para qué sirve el shebang / hashbang (#!) En Facebook y las nuevas URL de Twitter?
Al usar # de la manera descrita en las respuestas anteriores, está introduciendo un comportamiento conflictivo ... aunque no perdería el sueño por eso ... ya que Angular se convirtió en una norma ...
Para tener un buen seguimiento de todo esto, Twitter, uno de los pioneros de las URL de hashbang y la interfaz de una sola página, admitió que el sistema de hashbang era lento a largo plazo y que en realidad comenzaron a revertir la decisión y volver a enlaces de la vieja escuela.
Siempre asumí el ! solo se indica que el fragmento de hash que siguió correspondía a una URL, con ! ocupando el lugar del sitio raíz o dominio. Podría ser cualquier cosa, en teoría, pero parece que a la API de rastreo de AJAX de Google le gusta esto.
El hash, por supuesto, solo indica que no se está produciendo una recarga de la página real, así que sí, es para propósitos AJAX. Edit: Raganwald hace un trabajo encantador explicando esto con más detalle.
Tendría mucho cuidado si está considerando adoptar esta convención de hashbang.
Una vez que hashbang, no puedes volver. Este es probablemente el problema más pegajoso. La publicación de Ben expuso el punto de que cuando pushState se adopte más ampliamente, podemos dejar atrás los hashbangs y regresar a las URL tradicionales. Bueno, el hecho es que no puedes. Anteriormente dije que las URL son para siempre, se indexan y archivan y generalmente se guardan. Para agregar a eso, las URL frescas no cambian. No queremos desconectarnos de todos los enlaces valiosos a nuestro contenido. Si ha implementado las URL de hashbang en algún momento, entonces desea cambiarlas sin romper los enlaces, la única forma de hacerlo es ejecutando JavaScript en el documento raíz de su dominio. Siempre. No es de ninguna manera temporal, estás atrapado con eso.
Realmente quieres usar pushState en lugar de hashbangs , porque hacer que tus URL sean feas y posiblemente rotas para siempre es un inconveniente colosal y permanente para los hashbangs.
Esta técnica ahora está en desuso .
Esto solía decirle a Google cómo indexar la página.
https://developers.google.com/webmasters/ajax-crawling/
Esta técnica ha sido suplantada principalmente por la capacidad de usar la API de historial de JavaScript que se introdujo junto con HTML5. Para una URL como www.example.com/ajax.html#!key=value , Google revisará la URL www.example.com/ajax.html?_escaped_fragment_=key=value para obtener una versión no AJAX de los contenidos.