Огромное число авторов используют хэштеги для пометки своих постов. А также для заголовков, вносят эту информацию на картинки, в инфографику для видео и всячески применяют для поиска.

Хочу рассказать о наблюдаемом мной парадоксе этой технологии с точки зрения IT и обычной жизни.

Этот термин состоит из конкатенации двух слов: hash и tag. Hash - это прежде всего понятие про уникальность с шифрованием.

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

Такие функции не всегда могут однозначно давать уникальные ответы в виде строк, поэтому существуют так называемые коллизии.

Короче, здесь главный приоритет - уникальность, "не как у других".

Тег, или тэг - это обозначение какой-то метки.

В HTML используются теги верстки, в разработке через систему контроля версий тегами помечали стабильную версию кода. tag-1.2.3

В общем, эти два термина несут окрас, который применяется во многих отраслях разработки.

Итак, хэштег. Откуда он вообще появился?

Многие уже забыли, как формируется полный URL веб-страницы.

protocol//username:password@hostname:port/path?search#hash

В конце строки после разделителя той самой #решетки идет текстовая подстрока, которая называется hash.

На заре развития интернета у какого-то программиста была потребность создать дополнительный для адреса подстроковый блок, в котором он мог бы добавить свою информацию для дальнейшего использования. Так появился hash.

Если взглянуть на Javascript-вызов этого поля, то это будет просто location.hash, т.е. сама запись #info - это краткое обозначение, состоящее из отсылки на то самое свойство location.hash со значением “info”

Из этих рассуждений уже просматривается задуманный сценарий применения:

1. Пометить на странице уникальным идентификатором какой-то блок

2. При вызове URL с непустым значением hash найти искомый блок, или убедиться, что он отсутствует.

Казалось бы, что тут плохого, всё логично, есть потребность в нововведении какой-то технологии - вперед. Но этот нечетко продуманный подход привел к интересному парадоксу, о котором пойдет речь чуть далее.

И прошлого

Лет эдак 10-15 назад были сильно популярны в интернете сайты-лендинги с большим количеством анимаций.

Самая простая из них - сделать одностраничник с меню, в котором ссылки будут вести не на новые эндпоинты, а на разделы на той же странице.

Эти href’s содержали в себе #hash, который ссылался на раздел ниже. Также приобрел популярность термин “якорь”. Так вот - вы жмете на ссылку с якорем и браузер скролит страницу до нужной секции с преимуществами, контактами и прочее.

Есть важное НО - значение хэша было жестко привязано к точному совпадению со значением атрибута id=“hash” нужной секции или любого другого HTML-тега.

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

Смотрите:

• По определению id-атрибут HTML-тега по договоренности на странице должен быть уникальным в единственном экземпляре. Да, безусловно, это верстка, запилить два одинаковых id-шника - не проблема. Но это бессмысленно.

• Hash по своему изначальному применению также про уникальность, но существуют и коллизии (совпадающие хэши, например, в HashMap).

Но из-за "невалидированности" (отсутствия явного или логического запрета на неуникальные значения id и #hash), разработчики и юзеры могут наполнять эти свойства любыми значениями.

Для сравнения, порт, домен, путь до страницы зафиксированы или завалидированы более четко, неправильное обращение приводит к показу 4хх или 5хх ошибок (как минимум, возможны варианты).

Если сверстать HTML-страницу с двумя совпадающими id-шниками у разных блоков, то при вводе в URL этого значения hash, то страница просколлится (или прыгнет) к ПЕРВОМУ. А почему к первому?

Да просто это очевидно. А второй проигнорируется. Мы же не наблюдаем ни ошибки, ни исключения, ни алерта “Какой нужен блок, их здесь несколько?”.

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

К хэштегу

Он взялся не из ниоткуда. Неплохое сочетание хэш+тег в виде лаконичного оформления с решеткой так понравилось авторам идеи и пользователям социальных сетей, что вошло в нашу интернет-жизнь глубоко и надолго.

Сама идея помечать статьи и контент тегами (ну или как ранее было различными лэйблами) стала стандартом. Пишем статью - ставим теги, заливаем видео - рекомендуется вставлять теги, они везде, и всегда с решетками.

Хэштег работает по принципу обычной метки для поста, с помощью которой можно легко найти похожий и помеченный аналогичным образом контент.

В ВК например при клике по тегу #гитара нас перенаправляет на URL https://vk.com/search/statuses?q=%23гитара

Функционал совсем иной, чем было придумано для якорей. Это просто поиск по метке, а от хэша осталась только решетка.

А теперь к парадоксу

Людям свойственен поведенческий дуализм - с одной стороны человек всегда хочет выделиться в сравнении с другими, но с другой он хочет быть “как все”. И балансирует между этими крайностями.

Поэтому при использовании функционала #hashtag возникает следующий парадокс:

При пометке контента тегами возникает дилемма и следствие:

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

• Если есть желание выделиться среди других и пометить пост уникальным хэштегом, то вероятность поиска по уникальному низкочастотному тегу стремится к нулю, т.к. о нем еще никто не знает

И дополнительно:

• Поиск в большинстве случаев выдает результаты, отсортированные по убыванию даты-времени, поэтому в топе выдачи будет самый последний результат вне зависимости от “крутизны” контента.

Пояснение

При создании контента люди подсознательно хотят выделить свой пост среди других с помощью хэштега, но при этом уникальный #теговыйтермин никто не “подцепит”, пока действительно не удостоверится в его актуальности и применимости, а далее начнет использовать для своих постов.

Но это же и есть возвращение к теме хэша - он должен быть уникальным или близким к этому в применении для структур данных.

Т.е. первый и уникальный будет всегда ПЕРВЫМ и единственным в поиске, но мало видимым, а массовые популярные теги будут пушиться вверх просто по дате, это конечно не обязательно, но достаточно широко применяется, хотя и не абсолютно всегда.

Иногда выборку нужно отсортировать, например, по цене, или по лайкам, но это применяется реже.

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

Например, на Ютубе URL для клипа Nothing Else Matters

https://www.youtube.com/watch?v=tAGnKpE4NCI

содержит хэш в GET-параметре, это какая-то уникальная строка.

А что касается хэштега - он перекочевал в обычный поиск и стал одним из множества других простых функциональных реализаций в интерфейсе для удобства пользователя.