Легенда:
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Совершенно верно. 08.09.06 05:18 Число просмотров: 2182
Автор: void <Grebnev Valery> Статус: Elderman
|
> Получается, что задача сводится к тому, чтобы представить > 128-бит GUID в виде 16 строковых символов XML.
Совершенно верно.
> Без потерь это можно сделать, только сохраняя 8 бит на > символ. Поэтому первый вариант такой - определить алфавит в > 256 строковых символов из набора Unicode/UTF-8.
Спасибо за совет. Мы попробуем согласовать с партнёром поддерживаемый ими алфавит.
> Если ПО партнера не может Unicode/UTF-8, то придется > жертвовать размером GUID. Тогда делаем так: > - определяем алфавит из допустимых строковых символов, их > будет не меньше 64 (заглавные латинские буквы, прописные, > пробел, подчерк и цифры); > - разбиваем GUID на две половины по 64 биnа, для вычисления > на unsigned __int64; > - для каждой половины 8 раз берем остаток от деления на > размер алфавита и переводим в соответствующий символ; > - если есть вероятность, что все GUID не случайные числа с > нормальным распределением (например порядковый номер), то > перед преобразованием берем MD5 (или SHA) от GUID, и дальше > работаем с этим дайджестом. Свертка 8 байтов в 7через XOR > очень плохое решение с точки зрения обеспечения > уникальности результирующего DocID; > - вероятность коллизии 1.0/(размер_алфавита**16);
Интересно. Но в силу моей тугодомчивости, не совсем понятно.
Есть последовательность из 16 байт. Есть алфавит из, пусть, 64 литер.
Можно "сдвинуть" каждый байт набора символов (0-255) к номеру символа в "координатах" алфавита (0-64):
b[0] = b[0] mod 64;
...
b[15] = b[15] mod 64;
Правильно ли я понял ("... для каждой половины 8 раз берем остаток от деления на
размер алфавита и переводим в соответствующий символ ...")?
Спасибо.
|
|
|