Народ, тока начал разбираться, пните в нужную сторону, тока не сильно!
Для ПФР пробую формировать xml для некой формы...
И вот нужен ТипGUID в формате
([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12})\(\{[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}\})

нашел вот енто

D5373476-E04C-47A4-AA68-2225534BE8F4

вроде бы 36 знаков в итоге.
Такого подхода достаточно?



Исправлено 1 раз(а). Последнее : descent52_tmp, 19.10.17 11:45

Эти гуиды понапихали во все форматы, вероятно в надежде, что файлы не "перепутаются" в принимающих конторах. Поэтому любого вменяемого случайного гуид-числа достаточно. Я в состав этого "гуид" иногда включаю, например, № месяца, года, № пачки (когда файл выдается не один, а разбитый на несколько файлов). Кстати, гуид можно и фоксом сделать: несколько случайных 32-разрядных целых чисел, изобразить каждое в HEX-виде (4 байта = 8 HEX-цифр) - вот и гуид доморощеный )

Нельзя делать "доморощенные" GUID (точнее UUID) - т.к. это очень сильно увеличивает вероятность конфликта (даже если ты математик, то нужно нехило поработать чтобы соорудить статистически надёжный вариант генератора). Нужно использовать "стандартные алгоритмы". Тем более что их реализации есть в большинстве систем разработки, или просто в ОС.
Кстати, чем меньше "человеко-осмысленных" элементов используется при генерации, тем лучше - тогда злому юзеру-хакеру будет крайне сложно создать такие условия, чтобы твой софт сгенерировал дубликат GUID-а.

из иcxодников Delphi






Исправлено 1 раз(а). Последнее : Penner, 19.10.17 14:26

В данном примере гуид всего лишь 4 случайных 32-битных числа. Нет в нем экстраординарной математики, а простые соображения, типа "давайте сделаем ГСЧ такой разрядности, чтобы повторы не наблюдались на нужном количестве отсчетов ГСЧ" (повторы же разрешены, иначе это уже не совсем ГСЧ). Например, случайное число I (2^32) годится для 4Г элементов (например людей, или документов). Реально, если получать отсчеты ГСЧ, то повторы будут наблюдаться не через 4Г запусков, а через <4Г отсчетов (повторы же разрешены, иначе это уже не совсем ГСЧ). С какой частотой лезут повторы из ГСЧ, не знаю, смотря какой конструкции. Я пробовал фоксовый RAND() 16-разрядный (65 тыс. элементов), повторы были через несколько тыс...

en.wikipedia.org
GUID никогда не создавался как "4 случайных 32-битных числа". Даже его version 4 отводит под "псевдослучайную" часть не все биты. Впрочем, это скорее терминологическая, нежели техническая проблема - вполне можно 128 случайных/псевдослучайных бит "отформатировать" как соответствующую строку из hex-цифр и использовать в качестве GUID - крайне редко "содержимое" GUID анализируется (тем более что осмысленным будет лишь анализ для version 1 и 2). Вот если предлагается схема с "№ месяца, года, № пачки" - вот тут то и возникают проблемы - как обеспечить уникальность при использовании ну совсем неуникальных и более чем "повторяющихся" значений в качестве базы.

Проблема с псевдослучайным GUID "гуид можно и фоксом сделать: несколько случайных 32-разрядных целых чисел" другого рода - насколько "случайной" будет такая последовательность. Фоксовый ГПСЧ (функция RAND() реализована с использованием Линейный конгруэнтный метод) совершенно не годится для такой махинации - поскольку он даёт абсолютно строго детерминированные значения. Грубо говоря (сами "длинные" значения я приводить не стану, это не суть важно) если первое сгенерированное число было 12, то второе будет ВСЕГДА 34, третье, соответственно 65 а четвёртое 87. Соответственно "период повторяемости" такого псевдо-GUID размером в 128 бит, будет ровно таким же как и у просто фоксового RAND() размером в 32 бита. По сути все элементы кроме первого уже совершенно НЕ случайны

of63
С какой частотой лезут повторы из ГСЧ, не знаю, смотря какой конструкции

Не совсем так... Вероятность коллизии вообще никак не зависит от вида ГПСЧ - она зависит только от его "периода повторяемости", или, если по другому сказать, от числа всех возможных значений выдаваемых этим ГПСЧ. В фоксе для RAND "период" составляет чуть меньше 4Г - т.е. после генерации 4Г значений RAND "зацикливается", т.е. начинает выдавать ту же самую последовательность с самого начала (упростим, пусть будет ровно 4Г как хранит 32битное целое число) - НО согласно известному статистическому закону, если разные системы станут независимо генерировать этот самый фоксовый RAND(), то мы получим конфликт (генерацию "уже встречавшегося" значения) с вероятностью в 50% всего лишь после создания 77000 "уникальных значений". "Независимость" тут крайне важна, т.к. если в рамках одного процесса вызывать последовательно RAND() без параметров, то он будет надёжно "по очереди" выдавать все эти 4Г возможных значений - ну а потом не менее надёжно начнёт их повторять
Как по мне, так это очень слабо даже для небольшой системы (а зачем было бы использовать распределённые/автономные алгоритмы генерации id для маленькой системы, где вполне можно тупо реализовать "строго последовательный счётчик").
В общем автору темы на заметку - не надо ничего "колхозить" - бери один из стандартных способов генерации "настоящего" GUID - хоть скриптовый (хотя по мне это явный перебор - тащить к себе экскаватор, когда вполне достаточно банальной лопаты), хоть через DECLARE CoCreateGuid (но там понадобится ещё функция для придания "читаемого вида" сгенерированному числу/набору бит)

> поскольку он даёт абсолютно строго детерминированные значения
4 независимых случайных числа не обязательно генерировать как 4 последовательных вызова RAND(), но можно взять 4 RAND с "случайными" параметрами nSeedValue, например, 4 DATATIME() последних нажатий клавиш, или что-то подобно "случайное". Вобщем это не проблема - получить 4 независимых отсчета ГСЧ (в случае фокса - 32 разрядности).

> 4Г...конфликт с вероятностью в 50% всего лишь после создания 77000 "уникальных значений".
Я вот и не знал этого параметра ГСЧ (какого? Ведь можно сделать генератор с неповторами, если запоминать все ранее им сгенерированные значения, или сделать в интернете единый мировой генератор ГУИД с такой опцией. Шутка). Но допустим. Каждый из 4х независимых генераторов повторяется каждые 10^5 отсчетов с вероятностью 1/2. С какой частотой будут повторяться 4 генератора с той же вероятностью ?

...хз. А допустим, что с вероятностью 1 генератор повторится через 10^5 (77тыс) тогда, грубо, 2 генератора повторяться каждые (10^5)^2 = 10^10 ? Сомневаюсь, что это так. Скорее надо знать формулу, по которой 4Г превращаются в 10^5 (77тыс), и подставить в нее (4Г*4Г*4Г*4Г). О! Формула есть в твоей ссылке (коренная зависимость):
? LOG10(1/2 + SQRT((1/4) + 2 * LOG(2) * 2^122)) && 18 ==> 10^18 отсчетов. 122 - двоичная разрядность ГУИД-генератора в ссылке
? LOG10(1/2 + SQRT((1/4) + 2 * LOG(2) * 2^32)) && 4.8 ==> действительно, ок. 77тыс для 32 бит
? LOG10(1/2 + SQRT((1/4) + 2 * LOG(2) * 2^(32*3))) && 14 ==> 10^14 = 10^5 Г для 3*32 бит. По-моему вполне хватит 3х независимых фоксовых ГСЧ!
? LOG10(1/2 + SQRT((1/4) + 2 * LOG(2) * 2^(32*2))) && 9 ==> 2 независимых фоксовых ГСЧ дадут "ожидаемую" (4Г) частоту коллизий

Далее, вот контора просит включить в состав файла ГУИД, механизма генерации вобще-то не оговаривает, оговаривает только разрядность (и то от балды обычно). Так что имеем право хоть все единички набрать. Но мы же добрые, мы берем правильный ГУИД из ОС. Я же предлагаю часть битов (символов) правильного ГУИД заменить на личные нужды, например № месяца и год (2 символа и 2 символа), контора же не пострадает, а наоборот, пришлет тебе письмо "у вас тут файл ГУИД такой-то чето нехороший", а мы уже по нашим вкраплениям ГУИД видим год и месяц, за который этот файл сделан. А если ориентироваться на максимально идеальные ГУИД, тогда можно сказать, что мало и 122 разряда (3.9 Integer), и 128 (4 Integer), и вообще любая разрядность недостаточна для идеала...

Igor Korolyov
...
"Независимость" тут крайне важна, т.к. если в рамках одного процесса вызывать последовательно RAND() без параметров, то он будет надёжно "по очереди" выдавать все эти 4Г возможных значений - ну а потом не менее надёжно начнёт их повторять
...

А если первый раз вызвать RAND(-1), а последующие - просто RAND()?

Игорь говорит, что последовательность 4 последовательных вызовов RAND() коррелирована. Т.е. "степень случайности" что для единственного вызова RAND(), что для последовательности любого количества вызовов RAND() одинакова, т.к. по началу (по первому вызову) можно угадать всю остальную последовательность.

Из хелпа: Если значение nSeedValue при первом вызове функции RAND() отрицательное, стартовое значение будет создано на основе показания системных часов
Вот эти системные часы и вносят элемент "истиной" случайности, а последующие вызовы RAND() уже не несут никакой случайной информации, т.к. угадываемы (зная конструкцию генератора, конечно, или запоминая его последовательности)

Вот если вызвать несколько раз RAND(-1)в случайные моменты времени системных часов, вот тогда эта последовательность чисел будет взаимонезависима. Правда от RAND в таком "ГСЧ" остается лишь функция "перемешивания" битов от показаний системных часов, а вся "случайность" ложится именно на "случайный" выбор этих моментов вызова RAND(-1)...

vic7tar
А если первый раз вызвать RAND(-1), а последующие - просто RAND()?

Если чуть упростить, то функция RAND() это строго последовательный возврат значений из зацикленной последовательности типа 0,1,2,3,4,5,6,7,8,9,0,1,2,3... и т.д.
Если вызвав RAND() мы получили, к примеру, значение 5, то со 100% вероятностью следующий вызов RAND() вернёт 6, а потом 7 и т.д. И даже если мы "сцепим" миллион последовательно вызванных RAND() то вся мера "случайности" будет заключаться лишь в том, какое же первое значение было получено. Для вышеуказанной последовательности с циклом в 10, мы можем генерировать не более 10-ти случайных чисел. Хоть 32-битных, хоть 100500-битных. Сам RAND(), конечно, гораздо менее очевиден - и отдельные элементы в нём это по сути 32-битные числа, и идут они совершенно "не по порядку", ну и "зацикливается" последовательность не через 10 а через >4млрд "уникальных" элементов. Но суть от этого не меняется - значения будут строго определённые, и узнав всего одно из них можно совершенно точно "предсказать" все последующие -> "комбинировать" их не имеет особого смысла, мера "случайности" от этого не изменится в лучшую сторону - а вот в худшую вполне может.

RAND(-1) просто инициализирует из системных часов "стартовую позицию" в такой последовательности. Более того, т.к. скорости вычислений лет уж 30 как очень велики, то вариант ещё как-то "работавший" на заре развития вычислительной техники "последовательно брать показания часов" уже никак не поможет. RAND(-1) по 100-1000 раз будет попадать на одну и ту же "секунду", и соответственно возвращать одно и то же значение из последовательности.
Да, если повесить на экран форму с кнопкой и просить пользователя её нажимать, то с какой-то ненулевой вероятностью (чем более развит артрит или "туннельный синдром" у пользователя, тем лучше) мы будем получать "почти случайное" время между этими самыми нажатиями - то 1 секунду, то две, а то и целых три Но строить на этой основе работу ГПСЧ мягко говоря не очень то хорошо. Уж ОЧЕНЬ коррелированы будут получаемые значения. Вот если отслеживать движения мышки, при том пропускать их через хитрый фильтр-преобразователь (т.к. конечно же два "соседних" положения выраженные в x,y будут предсказуемо "близки" - а вот "направление" перемещения и "скорость" оного - уже очень неплохо "случайны"), то мы получим очень даже неплохой ГСЧ - при том именно ГСЧ без буковки П - т.е. по настоящему "случайные" величины, а не псевдо-случайные.
Впрочем, если ты пользовался некоторыми из криптографических утилит, то это не будет для тебя ново - многие из них именно таким нехитрым способом собирают необходимую для создания "случайных" величин энтропию - т.е. ту самую "меру случайности". ОС тоже помогают в этом деле - т.к. ОС весьма сложная сущность, и обычно в ней происходит очень много мало связанных процессов, то некоторые из "статистических показателей работы" являются очень хорошо "случайными". В относительно новых процессорах вообще встроен специальный блок для генерации "случайных" последовательностей байт - правда специалисты по безопасности не очень доверяют этому варианту Но он куда как надёжнее тривиальной последовательности из нескольких сцепленных фоксовых RAND() или тех же RAND(-1) которые по сути есть просто модифицированные по некоторому алгоритму SECONDS()

of63
4 независимых случайных числа не обязательно генерировать как 4 последовательных вызова RAND(), но можно взять 4 RAND с "случайными" параметрами nSeedValue, например, 4 DATATIME() последних нажатий клавиш, или что-то подобно "случайное". Вобщем это не проблема - получить 4 независимых отсчета ГСЧ (в случае фокса - 32 разрядности).

Это как раз и есть проблема - "колхозить" свой собственный аккумулятор энтропии. Т.к. во-первых для этого надо очень неплохо понимать всю "математику" случайных/псевдослучайных величин и уметь оценивать "качество" полученного сборщика энтропии. А во-вторых это в чистом виде изобретение велосипеда, т.к. такие решения уже давным давно разработаны и внедрены в ОС

of63
> 4Г...конфликт с вероятностью в 50% всего лишь после создания 77000 "уникальных значений".
Я вот и не знал этого параметра ГСЧ

Это не связано со "случайностью". Это чисто статистическое (из теории вероятности) свойство любого набора случайно (при том "равномерно" - т.е. с равной вероятностью для выбора любого из допустимых значений) распределённых значений - зависит исключительно от количества всех возможных элементов и от объёма "выборки".
Опять же это оценка вероятности. Т.е. нельзя сказать что "ровно через 77тыщ вызовов будет дубль". НО если взять миллиард разнообразных "наборов по 77тыщ" таким образом полученных элементов, то в половине из них окажется как минимум один "дубль".
Что будет если генераторы будут "независимы" я не знаю. Этот вопрос, возможно, Леонид может прояснить. Проблема то в том что это гПсч. т.е. детерминированная последовательность значений, а значит уже второй вызов такой "сцепки" не будет в чистом виде "независимым" - будут половинки/четвертинки из "предсказуемых последовательностей", при том "предсказуемых" на основе одного и того же алгоритма их работы... Вот для ГПСЧ которые создают реально многобитные последовательности с циклом в 2^128 или там 2^96 элементов эти формулы применимы...

of63
Я же предлагаю часть битов (символов) правильного ГУИД заменить на личные нужды

1) Зачем? Зачем в синтетический ключ помещать прикладные данные? Что, мало полей куда можно НАПРЯМУЮ прописать эти самые прикладные данные? Даже если их (эти поля) и не передавать "на сайт", то что мешает у себя вести таблицу-лог, где для каждого сгенерированного GUID держать и год/месяц и ФИО автора с датой отсылки "на сайт" и нотариально заверенным скриншотом того что сей сайт всё скушал и "не ругался"
2) С точки зрения математики/матстатистики нужно отдельно проверять, насколько "уникальным" является "огрызок" от GUID. Лично у меня для этого нет квалификации Поэтому я и не ломаю то, где не могу аргументированно разъяснить что "это снизит надёжность с 1 сбоя в 100500 лет до 1 сбоя в 9999 лет". Может быть, такая модификация будет приводить к регулярному появлению дублей - скажем раз в месяц. Оно мне надо, каждый месяц разговаривать с разгневанным юзером у которого "опять твоя программа сломалась"

А зачем вообще городить этот огород из GUIDов?
У каждого предприятия (ФЛ) есть рег. № в ПФ. Для ГНИ - ИНН. Сие уникальные значения. К чему городить этот бред?

Эх, если бы всё было так просто... И ИНН/УНП не всегда уникальны (одни филиалы уже могут сломать напрочь всю якобы "красивость" - а проводить все подобные транзакции через "центральную бухгалтерию" далеко не всегда возможно и удобно), да и не всегда "однозначны" (хотя для "уникальности" это и не важно), и вообще составные ключи с кучей "логики" внутри не лучшее решение в 99% случаев. Это ружьё всегда "стреляет", и в самый неподходящий момент. А "на лету" менять всю систему с позиционным (составным) ключом - добавлять туда новые элементы, или банально изменять данные для старых - занятие не из приятных для всех участвующих лиц.
GUID достаточно обезличен, достаточно уникален и универсален (для распределённой системы, которой и являются "100500 независимых предприятий, посылающих свои отчёты"). Просто нужно не "колхозить" (т.к. реально тогда возникает хороший шанс получить "неуникальность", если как следует все нюансы генератора не продумать), а взять одну из апробированных реализаций, и не знать проблем... А все эти ИНН да регномер - как отдельный реквизит уже в секции собственно данных - это как раз неплохо. Особенно если он ещё и контролироваться будет адекватно

> А зачем вообще городить этот огород из GUIDов?
Просто поговорить на умную тему, ГСЧ, ГСПЧ всякие)

2 Igor Korolyov
Про те 77тыс, через которое количество отсчетов произойдет коллизия (с вероятностью 1/2). Случайно (на сайте про коллайдер elementy.ru ) встретилась статья, как физики оценивают результаты измерений (оценивают в "сигма"-х, наблюдение нового явления с вероятностью, что это не старое явление, в 5 "сигма" - Нобелевка, в 1 "сигма" - обычное отклонение, типа хз...). А именно на страничке elementy.ru

Цитата:
Существует теория расчета статистической погрешности, в которую мы, конечно, вдаваться не будем. Но есть одно очень простое правило, которое легко запомнить и которое срабатывает почти всегда. Пусть у вас есть статистическая выборка из N столкновений и в ней присутствует n событий какого-то определенного типа. Тогда в другой статистической выборке из N событий, набранной в тех же условиях, можно ожидать примерно n ± SQRT(n) таких событий. Поделив это на N, мы получим среднюю вероятность встретить такое событие и погрешность среднего: n/N ± SQRT(n)/N. Оценка истинного значения вероятности такого типа события примерно соответствует этому выражению.

Коренная зависимость - это как раз 77тыс = SQRT(4Г). Что здесь N, и что n - пока не понял. Но это явно применимо к коллизиям, и размеру случайного числа...

Друзья присоединяюсь к вопросу как получить:

*[GUID] - глобальный уникальный идентификатор, обеспечивающий уникальность электронного документа. Значение GUID должно быть идентично значению GUID документа, содержащегося в файле. Реализация спецификации стандарта www.ietf.org.

уроды из роструда прислали письма до 15.10 сделать выгрузку в ПФ в XML и и тот GUID иднт в название файла в тэге

Почитать тему и воспользоваться поиском по имени функции CoCreateGuid никак не получается
Ну вот первая из ссылок с рабочим кодом примера forum.foxclub.ru

dafni_2004, если пишешь на фоксе, то смело юзай енто

Этого предостаточно!

descent52_tmp
dafni_2004, если пишешь на фоксе, то смело юзай енто

 oGUID = CreateObject("scriptlet.typelib")  
  cGUID = substr( oGUID.GUID, 2, 36 )  
  ?cGUID  
  RELEASE oGUID

Этого предостаточно!

спасибо все сделал!



Исправлено 1 раз(а). Последнее : dafni_2004, 26.10.17 14:08

Это, мягко говоря, спорный способ получения GUID. Ну это как для покраски забора начать врезаться в него на красных автомобилях
Сомнительная офисная компонента, заблокированная в одном из обновлений самим MS-ом... При том что для фокса "прямой" способ вызова АПИ функции генерации GUID предельно прост...
answers.microsoft.com

Игорь, приведи, пожалуйста, этот простой способ получения в фоксе )))