Как перевести ГУИД в число и обратно? #378881

Сабж.

наверно так же как и 16-ричное число в десятичное, хотя могу ошибаться....

Там порядок тетрадок важен

ты хочешь именно в десятичное число?

а как его обратно собрать?...

сделать тип строка

если просто взять гуид как 16-ричное число и убрать разделители, страшно представить какое там десятичное число получиться...

хотя собственно гуид и есть число...только не десятичное...

уже заводил тему - что опять вотка?

Функция ПолучитьGUIDПоУникальномуИдентификатору(Знач UUID)

Там было несколько другое

ну тогда сорри

Это проверенная информация?

здесь не церковь, вас не обманут (с) Бендер

вполне очевидная функция, что не понятного в ней?

меня только порядок тетрад беспокоит. Ну ладно, если все ок. то я включаю ее в свою библиотеку функций.

Вроде так:

если не секрет ты чего делаешь?

а зачем?

Синхронизирую контакты с аутлук, в поле User4 контакта проставляю уникальный номер ссылки, соответствующей этому контакту в справочнике Контакты. Преобразовываю ГУИД в длину 25 символов по 36-ричной системе счисления, чтобы занимал 25, а не 32 символа, экономия таки.

контактов миллионов 50?

а обратный процесс как? вот у меня есть число, как его перевести в GUID?

ладно тебе это же Гений - можно уже было привыкнуть

нет около 2000, просто при отправке на смартфон экономия 7*2000 = 14 кбайт.

для смартфона да, актуально...

И тест соответственно:

Тест выдает: 22345200-abe8-4f60-90c8-0d43c5f6c0f6 192 447 559 805 613 441 075 694 136 988 370 489 856 22345200-abe8-4f60-90c8-0d43c5f6c0f6 8KKJTDWBYFOY845G9L8ICSS8W 22345200-abe8-4f60-90c8-0d43c5f6c0f6 Короче, я только не уверен, что мне Злобный Мальчик дал правильный алгол для преобразования ГУИД в число, но если он правильный, то все пучком.

Коллеги, на партнерском не могут мне помочь. Может вы подскажете: Написал алгоритм для перевода ГУИД в 16-ричный формат. Подскажите, коллеги, правильно или нет. Переводил ГУИД: "22345200-abe8-4f60-90c8-0d43c5f6c0f6" Получил шестнадцатичеричное число: 90C80D43C5F6C0F64F60ABE822345200

Странное пристрастие к ГУИДам... что не ветка то про гуид... Наверное это потому что они длинные... ))))))))))

Краснов Денис очень подробно ответил.

Не фига он не ответил. У меня был конкретный вопрос - правильно ли я перевел число ГУИД в шестнадцатеричный формат. А он что ответил?

Вылизывают библиотеку функций просто

"Если представлять ГУИД как это делает 1С в строках <Объект не найден....>, то скомпоновал ты правильно." Краснов Денис.

а если нет? меня интересует не как 1с переводит, а как правильно. Дайте мне ссылку на страницу в интернете, где написано: "Например, ГУИД такой-то в шестнадцатеричной форме пишется так".

Эта функция слева прибавляет 32 символа "0"?

фиксин, ты женат?

сходи в мой дневник и узнаешь, гыгыгы нет, она дополняет до длины 32.

Блин, так неужели правильный ответ знает только БГ. Коллеги, кто снимет имидж "тупого 1сника"???

Нет "правильного" перевода в число. Какой алгоритм задашь такой и будет.

Коллега, ну что вы такое говорите? ГУИД: "22345200-abe8-4f60-90c8-0d43c5f6c0f6" это вполне конкретное 128-битное число. Оно не может быть произвольным, т.к. по ГУИД формируется например CLSID OLE-объектов. Вот я и спрашиваю, это: ox90C80D43C5F6C0F64F60ABE822345200 или нет

Спецом для тебя запустил скуль и написал: print cast(@a as varbinary) И вот какой ответ: 0xBB67BF402C745543ABB9DFF6A60BD701

блин, ты все запутал. кому теперь верить?

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

есть какой-то стандарт преобразования ГУид в число?

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

Хочешь сказать в Microsoft SQL 2005 наврали с преобразованием?

Я хочу найти ссылку в документации, блин Счас буду копать про ToByteArray

нет, я просто тащусь. Никто не знает такой банальнейшей вещи, ладно я дебил... но другие-то

Читаю себе, читаю. Сирожа, все дела. Тут бац, и ссылка на майкрософт. Ну, думаю, вот и гейтсу теперь Осипов снится будет. Потом уже перевел взгляд, увидел автора поста. Вы так не пугайте:) ЗЫ на : Вообще, такие вещи сперва стоит проверять. Аутлук хранит строки в UTF-16. Паршивая там экономия будет.

Не скажи, на 20 000 контактах то, уже не 7 байт, а 14!

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

Да и вообще, вопрос вроде бы простой, а ответ никто не знает, гыгыгы.

Т.к. вопрос оказался сложнее, чем народ думал, задал еще и на SQL:

Какие 14 байт? 16 байт GUID как GUID, и 50 байт на GUID как строку. Еще раз - какие 14 байт какой экономии?

Достаточно открыть pst, чтобы в этом убедиться.

+ "50 байт...на строку" + "если 25 символов в 36-ричной системе"

+ И чем же отличается поле с 25-значным 36-ричным числом от поля текстового?

по сабжу, GUID это и есть число...

Как ты собираешься в аутлуке хранить GUID как GUID По сабжу меня интересовал порядок тетрад, чтобы преобразовать GUID в 16ричную форму, не надо умничать на пустом месте, буквоедство detected

ещё один проснулся. Жениться тебе надо.

А догадаться слабо? Как 8 пар байт. Причем, в том же самом поле типа "Строка". И прежде чем кричать про нули - советую таки попробовать.

Че раскричались?

:))))) Пытаемся представить, как будет выглядеть чудак, пытающийся позвонить по смартфону с 20000 контактов:)

Счаст напишу алгоритм

Погодь, чего то я не въехал, Гений. Тебе же просто надо число из 16-ричной системы в 10-тичную перевести. И все!

Ты откуда проблему на 60 постов высосал?

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

нолик лишний, у меня 2000 контактов

Внимательно курим пост

Описка

Ладно. Говорю точнее. С точки зрения microsoft - гуид это 16 байт, которые можно представить также в виде 4 длинных слов (слева направо, индекс с 0) (т.н. "старое" представление), или в виде строки в нескольких вариантах, или в наборе из (длинное слово, короткое слово, короткое слово, 12 байт).

Продолжать?

Еще на Человек, ковыряющий 2000 контактов, смотрится примерно также, как человек с 20000 контактов. Качесвтенный переход, вообще говоря, несколько ниже, как я понимаю.

+ Я таки продолжу. Вопрос про разнообразие видов строк представления GUID почти тривиален. В контексте 1С это либо вид "{ХХХХХХХХ-ХХХХ-ХХХХ-ХХХХХХХХХХХХ}", либо какой-либо пользовательский (например - в 36-ричной системе).

+ Но менять систему исчисления имеет смысл только ради экономии (losless-сжатия). Причем, необходимо учитывать, что существуют более эффективные способы такого сжатия. Об одном из которых я и говорю. Он очень прост. Достаточно перейти от представления в виде строки к представлению в виде набора чисел.

+ 1. В очепятка. "12 байт" -> "6 байт" 2. Совершенно необязательно следовать представлениям microsoft о группах в наборе GUID. Достаточно обеспечить взаимное преобразование. Что и было сделано (со строкой), например, в .

+ Ну, и, собсно, пример losless без строки. Представим GUID как 8 коротких слов (по 16 бит). Такое представление тривиально хранится в строковых переменных с кодировкой UTF-16 (т.е. везде, практически): одно слово - один символ, всего 8 символов.

Осталось только пробразовать группы символов (по 4 16-ричных символа на каждое слово) из "классического" строкового представления GUID в числа и обратно.

Ему это число (128 бит в пределе) надо еще как-то засунуть в Outlook, в контакты. Да еще он хочет, чтобы покороче:)

+ Здесь я вижу только один подводный камень. Все сказанное не проверялось на wince-девайсах. Если winmobile 5/6 - проблем с нулевыми символами быть не должно.

Меня интересует вопрос академически, а не "лишь бы сделать", лишь бы сделать не вопрос. Меня интересует, в каком именно порядке должны идти в результирующее число тетрады из ГУИД. Но вы не парьтесь, на партнерке мне уже дали правильный ответ. По крайней мере в SQL и в функции JAVA guidtobyteArray результат одинаковый, значит можно считать его правильным.

! выруби своего дятла и вруби гения, а потом кури пост + кури свою найденую ссылку на сайте мелкомягких...

Кину ссылку на Вики - может поможет разобраться с типами GUID'ов и зачем "переставляют" группы

Просто приведи пример. Хахаха. В этой статье строку: "Например, '22345200-abe8-4f60-90c8-0d43c5f6c0f6' соответствует шестнадцатеричному 128-битному числу 0x00523422E8AB604F90C80D43C5F6C0F6" написал я, по материалам разборки полетов с ГУИД на партнерке. Надеюсь, правильно.

Написал функцию конвертации, провел тесты: ГУИД: 40bf67bb-742c-4355-abb9-dff6a60bd701 ГУИД числом: 249 104 320 812 803 032 337 390 685 874 299 852 545 ГУИД в шестнадцатеричной с/с: BB67BF402C745543ABB9DFF6A60BD701 ГУИД из шестнадцатеричной с/с обратно: 249 104 320 812 803 032 337 390 685 874 299 852 545 ГУИД: 22345200-abe8-4f60-90c8-0d43c5f6c0f6 ГУИД числом: 426 825 793 464 474 646 002 922 100 115 292 406 ГУИД в шестнадцатеричной с/с: 523422E8AB604F90C80D43C5F6C0F6 ГУИД из шестнадцатеричной с/с обратно: 426 825 793 464 474 646 002 922 100 115 292 406 Что забавно, функции конвертации числа в ГУИД и обратно оказались симметричными, т.е. практически идентичный код, наверное это как раз и говорит о том, что конвертация правильная: </pre>

ГУИД для лохов, даже 1С использует binary