Ищите уникальный шаблон идентификатора, который легко индексируется поисковыми системами

Question

Ищите уникальный шаблон идентификатора, который легко индексируется поисковыми системами

Как от Microsoft - "KB2756872" или от Национальной базы данных уязвимостей - "CVE-2010-1428" или от Red Hat - "RHSA-2010: 0376" или от OID - "1.3.6.1.4.1.311" или от UUID / GUID - "550e8400-e29b-41d4-a716-446655440000".

Я хочу поставить несколько рабочих мест для UID. Смотрите дальше...

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

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

Также это позволяет собрать статистику распространения статей. Многие сайты просто копируют контент (копирайтинг и переписывание ботов и людей) для взломанных поисковых систем. С помощью UID я легко могу идентифицировать такие сайты...

Итак, мой вопрос, как сделать UID (в какой форме), чтобы они были легко проиндексированы поисковыми системами (веб, как Google/Yahoo, и корпоративными, как Lucene/Solr/Sphinx/Xapian/ и т. Д.).

Я знаю о некоторых ограничениях поисковой системы, таких как:

только>= 3 символа для каждой поисковой части
это не была индексированная пыль, как gfh6wytrh6wu56he5gahj763

так что это задача не из легких...

Любой совет приветствуется (книги / статьи в блогах / и т. Д.).

2

search full-text-search search-engine uid

Источник

user173149 16 дек '12 в 19:26

2 ответа

Другие вопросы по тегам search full-text-search search-engine uid

user1591669 19 дек '12 в 09:06 2012-12-19 09:06 · Answer 1 · 2012-12-19 09:06

Вы можете использовать теги URI, как определено в RFC 4151.

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

Обратите внимание, что эти URI только идентифицируют, но не обнаруживают. Таким образом, тег URI ничего не говорит о том, где что-то опубликовано.

Допустим, домен вашего сайта - "example.com". Если вы создаете запись в блоге, вы можете создать следующий URI тега:

tag:example.com,2012-12:cute-cat

Обратите внимание, что дата в этом URI не является датой публикации! Это должна быть (прошедшая) дата, когда вы владели доменом (соответственно адрес электронной почты). Если вы зарегистрировали свой домен в 2003 году, вы всегда можете использовать теги URI, начиная с tag:example.com,2004: (не "2003", потому что "2003" будет означать "2003-01-01", что может быть временем, когда вы еще не владели доменом), за которым следует (уникальная) строка под вашим контролем. Однако, если вам нравится, вы всегда можете использовать дату публикации, конечно. Но не используйте будущие даты.

user1906700 16 дек '12 в 19:45 2012-12-16 19:45 · Answer 2 · 2012-12-16 19:45

Вы можете использовать годовой и числовой идентификатор статьи так же, как идентификаторы CVE. Поскольку вам также нужны изменения, вы можете добавить точку после идентификатора, чтобы уточнить версию. Например, для AWesome Bжурнал Service, AWBS-2012-1.0 будет ссылаться на оригинальный документ, AWBS-2012-1.1 будет ссылаться на первый пересмотр и т. д.

Однако вам необходимо убедиться, что AWBS являются уникальными, прежде чем использовать их. CVE назначаются вручную из пула. Вам, вероятно, понадобится какой-то сервис, который назначает AWBS из пула. Это может быть простой запрос к базе данных.