Доброго всем! Сразу говорю, что объяснять зачем и почему довольно долго, поэтому вопросы "НАФИГА" не задавать!

Теперь вопрос - есть некая фраза (т.е. реквизит типа строка), например:

"Строка примера некой фразы"

Нужно получить уникальный числовой код этой фразы! Именно УНИКАЛЬНЫЙ!
Я думал примерно так:

Код символа = [код символа по аске] * [позиция в строке] * ( [длина строки] - [позиция в строке] ) * 10

Так получаем число для каждого символа, а затем просто складываем все это и получаем одно число (правда большое)! Основная задача - сдалать та ,чтобы сумма при сумме разряды не пересекались.

(0) в общем это то, что пришло мне на ум. Готов выслушать ваши предложения по поводу данной проблемы!

Или объясняй, зачем и почему, или ветку - в печь

а вчем проблема?
есть набор символов, закодируй его как хощь, хоть в двоичной системе и будет тебе все уникальное

(2) ну начинается.
Хорошо, если очень кратко - попробуй сделать у Регистра сведений измерение с типом "Строка" более 130 символов!?

(3) так подскажи как лучше закодировать?!

А -101
Б- 102
В- 103
и тому подобное
только с количеством разрядов определись

(6) ну нарисуй мне что получится для вот этого:

"Строка примера некой фразы"

(4) наркоман, штоле? зачем делать регистр сведений с таким измерением?

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

кстати, автор, юзай MD5 или SHA

(7) еще забыл предупредить - фраза может быть на любом языке!!! И даже составной (на половину на русском, на половину на английском, например)

http://www.webutils.pl/SHA1_Calculator

(8) мне нужно хранить переводы фраз. Больше "зачем" не отвечаю!

(0)
Создать справочник.
Добавить элемент.
В наименование ввести свою фразу.
Записать элемент.

Имеем уникальный код для каждой фразы...

число в (0) будет слишком большое
хотябы [код символа по аске - мин. код символа по аске]

(13) а, вот оно чо. Печатные формы.
SHA подойдет

(13) Фактически у тебя 256-ричное число, тебе надо перевести его в 10-ричное и обратно. В чем проблема?

(14) длина фразы может быть больше 150 симовлов. Да и хранение в любой таблице 1С все равно так или иначе упрется в ограничение кластерного индекса.

(15) ну это уже ньюансы.

(16) Верно!

А там длина конечного кода всегда одинакова? не зависимо от длины входной строки?!

(14) теряется уникальности ключа!
Т.е. теоретически может быть 2 справочника с фразой внутри "ПРИВЕТ"!

А это косяк!

(18) Есть хранилище.

(21) Ну это одна строчка на проверку уникальности при вводе

(20) у меня где-то дома должна гнить на винте WSC-шка на жабаскрипте, в которой актив-икс, умеющий SHA-1 и MD5 генерить. Как раз для похожей задачи стряпал года два назад, если не забуду и найду - поделюсь.
Длина как раз всегда одинакова - 40 символов у сха и 32 у МД5

(22) ага, молодец! НУ не ужели я делаю вид полного дебила? Наверное же , если можно было использовать хранилище, то я его использовал!

Значение хранилища нельзя юзать в запросе!!!

(24) отлично - буду очень признателен!

(26) + хотя конечно я бы такой чисто на 1С-ке реализовал.

Короче говоря проссто алгоритм нужен расписанный.

(27) http://pajhome.org.uk/crypt/md5/

(25) Не нервируйся, по ту сторону интернета не видно кто какой делает вид )

Что ты собрался в запросах использовать?

(0) А тебе потом обратно разорачивать надо будет? Или будешь потом хэш брутфорсить?

(0) преобразуй md5 хешь в число

(28) я вот не увидел в описании...

этот алгоритм кодирования в обратную сторону работает?

Т.е. например я вставляю на входе строку из 1000 символов. На выходе получаю число из 40 символов. Обратно эти 40 в 1000 можно?

(30) в данной ситуации не надо - это просто ключ уникальности. Но для интереса хотелось бы и обратно попробовать.

(33) Лол. МД 5 только в одну сторону.
А справочник с реквизитом строка и контролем её уникальности не?

(32) если ты изобретешь алгоритм преобразующий 1000 символов в 40 и способный развернуть его обратно в 1000, то твой алгоритм купят все архиваторы т.к. их алгоритмы позволяют сжимать 1000 символов только в 300

(32)
Отец-грузин обьясняет своему сыну правила бизнеса:
- Берешь баран, кладешь в машин, получаешь две палка колбасы: один палка
себе, другой палка-продаешь, понял?
- Нэт.
- Обьясняю ещё раз: берешь баран, кладешь в машин, выходит два палка
колбасы: один палка себе, другой палка на базар, понял?
- Нэт.
- Обьясняю последний раз: берешь баран, кладешь в машин, получаешь две
палка колбасы: один палка себе, другой палка продаешь, понял?
- Пап. а есть такой машин, куда две палка кладешь, один баран
получается?
- Да, сынок, твой мама такой машин!!!

(31) я так понял, ему обратно расшифровывать надо

Base64 - не пойдет? 1с имеет встроеную поддержку...

(38) ему сжать надо а не увеличить строку на 30%
пожалуй ему подойдет СжатиеДанных

(34) Двойников можно понавставлять случайно. MD5 может оказаться мало, все-таки он не исключает коллизий. Может два MD5: один от строки, другой с солью? Хотя не помню какая вероянтость коллизий, может 1: миллиард, тогда двойной MD5 будет миллиард в квадрате

(37) пока не надо. Просто интересно возможно ли это?!

Вот читаю, читаю и не понимаю, а чем ГУИД не угодил? Уже предлагали же... 36 символов...

(40) вроде как SHa-1 более продвинутый алгоритм

(0) уж сколько раз твердили миру. удали избыточность и всё, а иначе неуникально. или нужно заранее ограничивать диапазон значений.

(42) еще один... :(

какой нафиг ГУИД СТРОКИ?????
Создавать отдельно справочник я не хочу!

(44) ты сейчас о чем дядя? давай досвиданья!

(39) у него строка юникоде (разные языки) и потом ее нужно использовать как ключ (по этому это должна быть имено строка).

именно для таких случаев и используется Base64, только на вход к шифрованию нужно подавать сжатую строку (например 6 битовую)

(45) "Создавать отдельно справочник я не хочу!"
Тебе хранить перевод всё-равно где-то придется. А создавать РС хочешь, значит?

(48) молодец! догадался :)

(45) о том что у тебя с математикой туго совсем, тётя

(10) +1.
Для вычисления можно использовать внешние компоненты.

(45) Ути-пути. Справочник создавать не хочу, а кривожо_пый велосипед изобретать хочу. Любитель ручного секса?

(49) И? Какая разница: хранить в РС или в справочнике? В справочнике в данном случае проще.

(43) Какая разница, все равно при свертке неограниченного объема информации к фиксированному всега появляется вероятность коллизий. Например у меня блок информации 1000 бит, это 1000^2 разных значений, если хеш будет 100 бит, то есть только 100^2 вариантов хешей, т.к. в одном из ста случаев хеши будут совпадать.

(53) мне кажется в РС лучше.

(55) Чем? Тем что надо велосипед с квадратными колесами придумать? Заюзать ГУИД это как два пальца об асфальт...

(56) в пень гуид

(57) Обоснуешь?

(45) кстати хорошая идея (я так делал, нормально работает)

делаешь справочник с табличной частью
в табличную часть заносишь список параметров поиска,
на основании табличной части строим ХЕШ и его пишем в наименование справочника.

далее как использовать

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

то есть перекладываем часть расчетов на момент до выполнения запросов и сильно упрощаем сами запросы...

у меня было переменное количество параметров от 2х до 5, использовал в RLS - все летало!

аналогично можно сделаить и в сабже, просто в раблицу писать отдельные слова из фразы

(58) недосуг

(59) типы придумал ключи аналитики. только хэш тут лишнее

(61) *ты

(32) да, конечно, работает. Скачал кино на работе, посчитал md5, записал на бмажку 32 символа, принес домой, развернул, смотри кино.

(59) отдельные слова не вариант. тут нужна именно фраза целиком. Т.к. одни и теже слова в разных ситуациях могут переводиться по разному.

Напрмиер в одном случае "корабль" переводится как "ship" в другом "vessel". Поэтому сложный перевод не вариант формировать по словам - приходится хранить целую фразу или предложение.

(32) не нужно тебе обратно расшифровывать. В измерении будет хэш, а само значение - в ресурсе неограниченной строкой. Искать ты будешь по хэшу, а не по значению

(63) было бы здорово :)

(61) не лишнее,

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

делал для документооборота, прикидывал преспективы - при 500 пользователях аналитика полностью покрывала все возможные варианты доступа до 6 аналитик, а справочник в преспективе выдерживает до 10-15 аналитик

(65) я знаю. Мне в данной ситуации обратно не надо!

Просто интересно можно ли это сделать...

вообще-то где-то видел в инете преобразователи обратные.

Тебе надо кодирование без потерь? Смотри в сторону Сжатие.ZIP

(67) насколько преимущество перед регистром сведений?

(69) а причем тут сжатие зип? зип мне на выходе двоичные данные даст....причем по длине очень не маленькие.

(68) ты не то в интернете видел и не так

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

(71) Так тебе с потерями или без?

(70) на регистре такое просто сделать невозможно, дело в том что типы разные (разные варианты доступа в одном регистре)

например реализуй два вида доступа которые действуют или/или
1. ШтатноеРасписание + ВидДокумента + ПравоПодписи
2. ГруппаДоступа + ПравоПросмотра + ВидДокумента + РуководительАвтора

у меня это реализовывалось созданием N количества элементов и записи их в регистры а RLS был в одну строку

(74) ну вообще без хочется.

(59) при таком подходе, на кой кол тебе хеш?

(76) перестань этого хотеть и все получится

Для всех символов: сумма = сумма^65536 + КодСимвола(Н)

(79) *

wiki:RC6
DynaCrypt в 1С++ по такому алгоритму шифрует и расшифровывает.