Pregunta ¿Para qué sirve el shebang / hashbang (#!) En Facebook y las nuevas URL de Twitter?


Me acabo de dar cuenta de que las largas y complicadas URL de Facebook que estamos acostumbrados ahora se ven así:

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

Por lo que puedo recordar, a principios de este año era simplemente una cadena normal de fragmento de URL (empezando por #), sin el signo de admiración. Pero ahora es un shebang o hashbang (#!), que solo he visto anteriormente en scripts de shell y scripts de Perl.

los nuevo Twitter Las URL ahora también cuentan con #! símbolos. Una URL de perfil de Twitter, por ejemplo, ahora se ve así:

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

Hace #! ahora juegan algún papel especial en las URL, como para cierto 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á mi aplicación web de alguna manera?


725
2018-06-09 19:49


origen


Respuestas:


Esta técnica es ahora en desuso.

Esta Acostumbrado a dile 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 utilizar la API de historial de JavaScript que se introdujo junto con HTML5. Para una URL como www.example.com/ajax.html#!key=value, Google verificará la URL www.example.com/ajax.html?_escaped_fragment_=key=value para buscar una versión que no sea AJAX de los contenidos.


477
2018-06-09 20:07



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 el ancla porción de una URL. Si utiliza Wikipedia, verá que la mayoría de las páginas tienen una tabla de contenido y puede saltar a secciones dentro del documento con un delimitador, como por ejemplo:

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 impulsadas por Javascript (como la mía Madera y piedras) el uso de anclas es que quieren hacer las páginas favoritas (como sugiere un comentario en esa respuesta) o respaldar el botón Atrás sin recargar toda la página del servidor.

Para admitir marcadores y el botón Atrás, debe cambiar la URL. Sin embargo, si cambia la parte de la página (con algo así 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 Firebug o en la consola de Javascript de Safari. Carga 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';

Aha! ¡Sin actualización de 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 se encuentran en el historial del navegador. El navegador se da cuenta de que estamos en la misma página, pero simplemente cambia el ancla, por lo que no se recarga. Gracias a este comportamiento, podemos tener una sola aplicación de Javascript que aparezca en el navegador para estar en una 'página' pero que tenga muchas secciones de marcadores que respeten el botón Atrás. La aplicación debe cambiar el delimitador cuando un usuario ingresa diferentes 'estados', y del mismo modo si un usuario usa el botón Atrás o un marcador o un enlace para cargar la aplicación con un delimitador incluido, la aplicación debe restaurar el estado apropiado.

Así que ahí lo tienes: los anclajes proporcionan a los programadores de Javascript un mecanismo para crear aplicaciones que sean bookmarkable, indexables y amigables con el botón de retroceso. Esta técnica tiene un nombre: es una Interfaz de página única.

PD. Hay un cuarto beneficio para esta técnica: cargar 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, se pueden realizar otros trucos como cargar ciertas partes en el fondo bajo el control del programador.

p.p.s. Teniendo en cuenta todo eso, el 'bang' o signo de admiración es una pista más del rastreador web de Google que la misma página puede cargarse desde el servidor en una URL ligeramente diferente. Ver Ajax arrastrándose. Otra técnica es hacer que cada enlace apunte a una URL accesible para el servidor y luego usar un discreto Javascript para convertirlo en un SPI con un anclaje.

Aquí está el enlace clave de nuevo: El manifiesto de la interfaz de una sola página


214
2017-10-16 22:30



Primero que nada: soy el autor del Manifiesto de interfaz de página única 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 rastrear sitios web intensivos en AJAX (en los sitios web de la Interfaz de página única extrema). Cuando el rastreador de Google encuentra una URL con #! sabe que existe una URL convencional alternativa que proporciona el mismo "estado" de página, pero en este caso, 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 puedes construir sitios web SPI compatibles con SEO para cualquier rastreador web (Yahoo, Bing ...).

El Manifiesto SPI y demos no usan el formato de Google ! en hashes, esta notación podría agregarse fácilmente y el rastreo de SPI podría ser aún más fácil (la notación UPDATE: now! se usa y sigue siendo compatible con otros motores de búsqueda).

Eche un vistazo a esto tutorial, es un ejemplo de un sitio ItsNat SPI simple 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 es en el mismo tiempo SPI o página basada en SEO (o cuando JavaScript está deshabilitado para accesibilidad). Con otros frameworks web, puede seguir el enfoque de doble sitio, un sitio es SPI y otro basado en SEO, por ejemplo, Twitter utiliza esta técnica de "doble sitio".


110
2017-10-17 09:04



Yo sería muy cuidadoso si está considerando adoptar esta convención hashbang.

Una vez que hashbang, no puedes volver atrás. Este es probablemente el problema más complicado. La publicación de Ben plantea el punto de que cuando pushState se adopte más ampliamente, entonces podemos dejar atrás hashbangs y volver a las URL tradicionales. Bueno, el hecho es que no puedes. Antes mencioné que las URL son para siempre, se indexan y archivan y, en general, se mantienen. Para agregar a eso, las URL geniales no cambian. No queremos desconectarnos de todos los enlaces valiosos a nuestro contenido. Si ha implementado URL hashbang en cualquier punto y luego desea cambiarlas sin romper enlaces, la única forma en que puede 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 usa pushState en lugar de hashbangs, porque hacer que sus URLs sean feas y posiblemente rotas para siempre es una desventaja colosal y permanente para los hashbangs.


82
2018-02-24 21:34



Para tener un buen seguimiento de todo esto, Twitter, uno de los pioneros de la URL de hashbang y la interfaz de una sola página, admitió que el sistema de hashbang fue lento a largo plazo y que en realidad han comenzado a revertir la decisión y volviendo a enlaces de la vieja escuela.

El artículo sobre esto está aquí.


14
2018-05-31 09:51



Siempre asumí el ! simplemente indicó que el fragmento de hash que siguió correspondía a una URL, con ! tomando el lugar del sitio raíz o dominio. Podría ser cualquier cosa, en teoría, pero parece que a la API de rastreo AJAX de Google le gusta de esta manera.

El hash, por supuesto, solo indica que no está realizándose una nueva recarga de la página, así que sí, es para propósitos de AJAX. Editar: Raganwald hace un trabajo encantador al explicar esto con más detalle.


9
2017-10-16 22:31



Las respuestas anteriores describen bien por qué y cómo se usa en Twitter y Facebook, lo que extrañé es una explicación de qué # lo hace por defecto ...

En una aplicación 'normal' (no en una sola página) puede hacer el anclaje con hash a cualquier elemento que tenga identificación al colocar esa identificación de elementos en url después de hash #

Ejemplo: 

(en Chrome) Click F12 o Rihgt Mouse y Inspect element 

enter image description here

luego toma id="answer-10831233" y agregue a url como siguiendo

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

y obtendrás 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?

Mediante el uso # de la manera descrita en las respuestas anteriores, estás introduciendo un comportamiento conflictivo ... aunque no me perdería el sueño ... desde Angular se convirtió en algo así como un estándar ...


-1
2017-07-12 03:13