Для чего нужен шебанг / хэшбанг (#!) В Facebook и новые URL-адреса Twitter?

Octothorpe / number-sign / hashmark имеет особое значение в URL-адресе, обычно он идентифицирует имя раздела документа. Точный термин заключается в том, что текст, следующий за хешем, является частью URL-адреса привязкой. Если вы используете Википедию, вы увидите, что на большинстве страниц есть оглавление, и вы можете переходить к разделам в документе с привязкой, например:

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

https://en.wikipedia.org/wiki/Alan_Turing обозначает страницу, а Early_computers_and_the_Turing_test является привязкой. Причина, по которой Facebook и другие приложения на основе Javascript (например, мои собственные Wood & Stones) используют якоря, заключается в том, что что они хотят делать страницы закладками (как предлагается в комментарии к этому ответу) или поддерживать кнопку «Назад» без перезагрузки всей страницы с сервера.

Чтобы поддерживать закладку и кнопку «Назад», вам необходимо изменить URL-адрес. Однако, если вы измените часть страницы (с чем-то вроде window.location = 'http://raganwald.com';) на другой URL-адрес или без указания привязки, браузер загрузит всю страницу с URL-адреса. Попробуйте это в консоли Javascript Firebug или Safari. Загрузить http://minimal-github.gilesb.com/raganwald. Теперь в консоли Javascript введите:

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

Вы увидите, что страница обновляется с сервера. Теперь введите:

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

Ага! Нет обновления страницы! Тип:

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

По-прежнему нет обновления. Используйте кнопку «Назад», чтобы увидеть, что эти URL-адреса находятся в истории браузера. Браузер замечает, что мы находимся на той же странице, но просто меняем привязку, поэтому он не перезагружается. Благодаря такому поведению у нас может быть одно приложение Javascript, которое отображается в браузере как на одной «странице», но имеет много закладок, соответствующих кнопке «Назад». Приложение должно изменить привязку, когда пользователь входит в разные «состояния», и аналогично, если пользователь использует кнопку «Назад», закладку или ссылку для загрузки приложения с включенной привязкой, приложение должно восстановить соответствующее состояние.

Итак, у вас есть: якоря предоставляют программистам Javascript механизм для создания приложений с возможностью добавления закладок, индексации и обратной кнопки. У этого метода есть название: это одностраничный интерфейс.

p.s. У этого метода есть четвертое преимущество: загрузка содержимого страницы через AJAX с последующим его внедрением в текущую модель DOM может быть намного быстрее, чем загрузка новой страницы. Помимо увеличения скорости, под контролем программиста могут выполняться дополнительные трюки, такие как загрузка определенных частей в фоновом режиме.

p.p.s. Учитывая все это, восклицательный знак или восклицательный знак - это еще один намек для поискового робота Google на то, что одна и та же страница может быть загружена с сервера по немного другому URL-адресу. См. Сканирование Ajax. Другой способ - сделать так, чтобы каждая ссылка указывала на URL-адрес, доступный серверу, а затем использовать ненавязчивый Javascript, чтобы преобразовать его в SPI с привязкой.

Вот снова ключевая ссылка: Манифест одностраничного интерфейса

Прежде всего: я являюсь автором манифеста одностраничного интерфейса, цитируемого Раганвальдом.

Как очень хорошо объяснил Раганвальд, наиболее важным аспектом подхода одностраничного интерфейса (SPI), используемого в FaceBook и Twitter, является использование хэша # в URL-адресах.

Символ ! добавлен только для целей Google, это обозначение является «стандартом» Google для сканирования веб-сайтов, интенсивно использующих AJAX (на крайних веб-сайтах с одностраничным интерфейсом). Когда поисковый робот Google находит URL-адрес с #!, он знает, что существует альтернативный традиционный URL-адрес, обеспечивающий то же "состояние" страницы, но в данном случае во время загрузки.

Несмотря на то, что комбинация #! очень интересна для SEO, поддерживается только Google (насколько я знаю), с помощью некоторых уловок JavaScript вы можете создать веб-сайты SPI, совместимые с SEO для любого поискового робота (Yahoo, Bing ...).

Манифест SPI и демонстрации не используют формат Google ! в хэшах, эту нотацию можно было бы легко добавить, и сканирование SPI могло бы быть еще проще (ОБНОВЛЕНИЕ: теперь! Нотация используется и остается совместимой с другими поисковыми системами).

Взгляните на это руководство, являющееся примером простого Сайт ItsNat SPI, но вы можете выбрать несколько идей для других фреймворков, этот пример SEO-совместим с любым поисковым роботом.

Сложная проблема состоит в том, чтобы сгенерировать любое (или выбранное) «состояние страницы AJAX» как обычный HTML для SEO, в ItsNat это очень просто и автоматически, тот же сайт находится в то же время SPI или страница, основанная для SEO (или когда JavaScript отключен для доступности). С другими веб-фреймворками вы можете когда-либо следовать подходу двойного сайта, один сайт основан на SPI, а другая страница - для SEO, например, Twitter использует эту технику «двойного сайта».

Я был бы очень осторожным, если вы планируете принять это соглашение о хэшбэнге.

После хэшбэга вернуться назад уже нельзя. Это, вероятно, самая сложная проблема. В сообщении Бена подчеркивается, что, когда pushState получит более широкое распространение, мы сможем оставить хэшбэги позади и вернуться к традиционным URL-адресам. Что ж, факт в том, что ты не можешь. Ранее я заявлял, что URL-адреса вечны, они индексируются, архивируются и обычно хранятся. Вдобавок к этому классные URL не меняются. Мы не хотим отключаться от всех ценных ссылок на наш контент. Если вы в какой-то момент внедрили URL-адреса хэшбэга, то хотите изменить их, не разрывая ссылки, единственный способ сделать это - запустить JavaScript в корневом документе вашего домена. Навсегда. Это ни в коем случае не временно, вы застряли в этом.

Вы действительно хотите использовать pushState вместо hashbangs, потому что создание ваши URL-адреса уродливые и, возможно, сломанные - навсегда - это колоссальный и постоянный недостаток хэшбэгов.

Чтобы хорошо следить за всем этим, Twitter - один из пионеров хэшбэнг-URL и одностраничного интерфейса - признал, что система хэшбэга была медленной в долгосрочной перспективе и что они фактически начали менять решение и возвращаться к ссылки старой школы.

Статья об этом здесь.

Я всегда предполагал, что ! просто указывает, что следующий за ним хеш-фрагмент соответствует URL-адресу, где ! занимает место корня сайта или домена. Теоретически это может быть что угодно, но похоже, что Google AJAX Crawling API так любит.

Хеш, конечно, просто указывает на то, что реальной перезагрузки страницы не происходит, так что да, это для целей AJAX. Изменить: Раганвальд прекрасно объяснил это более подробно.

Ответы выше хорошо описывают, почему и как он используется в твиттере и фейсбуке, я пропустил объяснение того, что # делает по умолчанию ...

В «нормальном» (а не одностраничном приложении) вы можете сделать привязку с hash к любому элементу с идентификатором, поместив этот идентификатор элемента в url после хеша #

Пример:

(в Chrome) Нажмите F12 или Rihgt Mouse и Inspect element

затем возьмите id="answer-10831233" и добавьте к URL-адресу, как показано ниже

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

и вы получите ссылку, которая перейдет к этому элементу на странице

Что такое shebang / hashbang ( #!) в Facebook и новые URL-адреса Twitter для?

Используя # способом, описанным в ответах выше, вы вводите конфликтующее поведение ... хотя я бы не потерял из-за этого сон ... поскольку Angular стал чем-то вроде стандарта ...