Comments 203
Кто-то может оценить надёжность таких чек-сумм и предположить, почему такие выбраны? Например, почему остатки по модулю 11, а не 10?
Есть математическое обоснование этому, и, если не ошибаюсь, оно связано с более равномерным распределением при использовании хэш-функции, но не могу найти ссылок на литературу.
UPD
Дело, скорее всего, в делителях. Если по какой-то причине все числа будут чётными, то остаток от деления на 10 будет давать только четные числа, что уменьшит полезность контрольной суммы. Если использовать простые числа, то проблемы могут быть только при генерации чисел кратных модулю, но это очень странная ситуации. То есть, в общем случае, простые числа гарантируют, что контрольной суммой может быть любое число, которое меньше модуля, невзирая на принцип генерации исходных чисел.
Уже вижу проблему!
Можно опечататься в 5 цифре и не поломать контрольные суммы!
Допустим k2=0, потому что остаток от деления суммы на 11 — 0.
Далее, 5-ая цифра не влияет на k1 вообще, потому что там коэффициент 11. Поэтому k1 — не меняется вообще. А в k2 она входит с коэффициентом 4. Соответственно, ошибка на +3 в этом разряде даст +12 к контрольной сумме, что делает из остатка 0 — остаток 1. По алгоритму это оставит k2=0.
Еще можно опечататься на +3 в четвертой цифре (если проверочные суммы 0 и 1 mod 10, k1=k2=0), тогда первая сумма изменится на +12 (+1 mod 11), а вторая на +21 (-1 mod 11).
Вообще, кажется очень плохой идеей назначать проверочную цифру нулем для разных сумм да еще и использовать модуль в качестве коэффициента. Ввели аж 2 проверочные цифры, а опечатки в одной цифре возможны.
"Я сделаль" — https://jsfiddle.net/ktz3mLvd/5/
У меня такая проблема не воспроизводится (
114172744=11417274423
114472744=11447274411
Пятый разрад — ошибка
370041837=37004183750
370071837=37007183750
Гораздо интереснее, почему такие алгоритмы, работающие на основе написания, выбираются.
Можно же взять бинарное представление десятичного числа, вычислить какое-нибудь CRC-8, прицепить (или даже перемешать) его с исходным числом, снова записать в десятичном виде — и готово число со встроенной контрольной суммой.
Или я ошибаюсь и ничего хорошего из этого не получится?
Ну конкретно CRC8 может оказаться больше 100 и не влезет полностью в 2 десятичных цифры, отведенные на чек-сумму. Но зачем надо было изобретать велосипед, я тоже не понимаю, наверняка что-то уже давно придумано.
Непонятно, почему контрольные цифры отдельно, а само число — отдельно. Нужно ведь только чтобы не каждое из 10^11 чисел подходило, а приблизительно каждое сотое. Это можно и в другом виде формулировать. "Должно являться корнем функции...". А функция пускай хоть с отдельными битами работает и логарифмы вычисляет.
Как бы, использование CRC-8 для контроля ошибок последовательности цифр (UTF-8/ASCII) после предварительного контроля на то, что они цифры, несколько странно. Ввиду того, что цифры это у нас 3,3 бит младших бита, какие-либо гарантии за пакеты ошибок теряются, и получаем просто некую контрольную сумму.
UTF-8/ASCII
CRC не от битовой последовательности строки как последовательности символов, а от битовой последовательности двоичного представления этого целого.
Те. для берем "случайное" целое '536870912'. Считаем CRC от последовательности битов CRC8(100000000000000000000000000000 BIN) = 10010100 BIN (считал тут)
Цепляем в конец и переводим обратно в целое, получая допустимый ID:
10000000000000000000000000000010010100 BIN = 1374 3895 3620 DEC. Да, я знаю, что тут не 11 цифр — просто демонстрирую идею. Если нужно именно 11 — надо будет подбирать другую функцию.
какие-либо гарантии за пакеты ошибок теряются, и получаем просто некую контрольную сумму.
К сожалению, не понял аргумента. Например, в примере выше набрали не то что надо а переставили четвертую и пятую цифры: '1347 3895 3620' (т.е. 1111101011111000100010100010110010100 BIN)
CRC8(11111010111110001000101000101 BIN) = 00110110 BIN
Что не равно 10010100, которое добавлено в конце. Можно ругаться, что при вводе допустили ошибку.
CRC не от битовой последовательности строки как последовательности символов, а от битовой последовательности двоичного представления этого целогоС учётом того, что многие каналы для передачи номера оперируют цифрами, например, ввод с клавиатуры, такое использование CRC-8 окажется не очень хорошим, если не сказать грубее. Ошибка в одной цифре, может изменить любое количество бит двоичного представления, но CRC-8 гарантировано обнаруживает искажение не более 8 последовательных бит, а любые другие искажения лишь с вероятностью примерно 1-1/256, тем более после преобразования 8-и контрольных бит в 2-е контрольные цифры.
Скорее всего, найдутся такие номера и такие ошибки в одной цифре, которые не будут обнаружены таким кодом. (Т.е. получится так же, как в коде из основной статьи, найдётся дырочка)
К сожалению, не понял аргумента.… Что не равно...Просто повезло, всё таки 99/100 близко к 1.
Как вариант, можно рассмотреть такое использование CRC-8, которое обнаруживает почти все пакетные двойные ошибки (две последовательные цифры) в основном номере и все одинарные ошибки:
- Каждой цифре сопоставляем её 4-х битное представление;
- Рассчитываем CRC-8 от конкатенации некой начальной строки и всех 4-х битных строк;
- 8-и битный результат делим по модулю 100.
Я практически уверен, что можно будет подобрать такую начальную или конечную строку, что бы гарантировать обнаружение всех одиночных ошибок. Но не уверен в возможности её вычислить аналитически, без большого перебора.
Другое дело, что оперируя в полях по модулю 10 можно построить лучшие коды с лучшими гарантиями.
P,S. С точки зрения простоты доказательства гарантий обнаружения одиночных ошибок, CRC-4, CRC-5 или CRC-6 выглядят существенно предпочтительнее.
тем более после преобразования 8-и контрольных бит в 2-е контрольные цифры.
Весь первоначальный вопрос был, зачем нужно такое выделение. Я вот в примере отдельных десятичных цифр контрольной суммы не выделял — и вроде все работает.
Другое дело, что оперируя в полях по модулю 10 можно построить лучшие коды с лучшими гарантиями.
Может быть. Вот как раз это мне и не очевидно. Кроме того, что-то я не верю, что оно получается при таких простых алгоритмах, как вот тут предлагается.
Весь первоначальный вопрос был, зачем нужно такое выделение. Я вот в примере отдельных десятичных цифр контрольной суммы не выделял — и вроде все работает.
Оно, конечно, работает, но получается, иногда 11 значный номер, иногда 12 значный номер, что противоречит постановке задачи и, к тому же, не имеет гарантии обнаружения ошибки в одной цифре.
Если нужно именно 11 — надо будет подбирать другую функцию.
Простейший вариант обеспечения 11 значного номера, это отобразить 8-и контрольных бит в 2-е контрольные цифры.
Наверное есть вариант изменения первоначальной постановки задачи — ужать случайную часть номера, тем или иным способом, скажем, брать не 9 случайных цифр, а 28 случайных бит.
Может быть. Вот как раз это мне и не очевидно. Кроме того, что-то я не верю, что оно получается при таких простых алгоритмах, как вот тут предлагается.А что у нас с вами для CRC-8 лучше получается?
Пока нам с вами вариант, который гарантирует обнаружение одиночных ошибок неизвестен же. Причём, даже если мы корректируем изначальную постановку задачи, всё равно пока нет варианта, только идеи.
Вот с CRC-6 было бы просто, но Вам он, почему-то не нравится.
Наверное есть вариант изменения первоначальной постановки задачи
Тогда уж использовать 16-чное число. Только вместо цифр 'ABCDEF' использовать что-то вроде 'ABCEHK' — чтобы одновременно и латиницу не заставлять русскоязычных произносить и проблем с кириллицей для зарубежных систем не создавать.
Пока нам с вами вариант, который гарантирует обнаружение одиночных ошибок неизвестен же.
В 11-ти значном числе, если в арифметике не ошибся, есть 99 вариантов ошибиться в одной цифре и 10 вариантов — переставить две рядом стоящие. Т.е. для гарантированного обнаружения таких ошибок валидным ID-ом должно быть каждое 109-ое число. Кажется, это означает, что двух десятичных разрядов контрольной суммы заведомо для этой задачи не хватить.
Вот с CRC-6 было бы просто, но Вам он, почему-то не нравится.
Почему не нравится? Мне все равно. Единственное, что я хотел выяснить — почему выбирают алгоритмы, переводящие десятичные цифры в отдельные десятичные же цифры контрольной суммы. Хотя можно выставить условие на все число сразу. Это выглядит так, как будто обеспечивают удобство ручного вычисления. Что странно.
А CRC-8 — это был сходу придуманный пример, возможно не очень удачный, того, как это 'на все число сразу' может выглядеть.
Т.е. для гарантированного обнаружения таких ошибок валидным ID-ом должно быть каждое 109-ое число.
Похоже, кстати, что "делится нацело на 109" — и есть алгоритм для 11-ти значного десятичного числа, гарантированно находящий ошибку в одной цифре либо одну перестановку рядом стоящих.
Очевидно, что для любого простого M >= 100, остатки от деления X и X + E*10n на M, где E <= 99, будут отличаться.
Так что и 101 тоже подойдёт для обнаружения ошибок двух рядом стоящих цифр, но для задачи с 9 случайными цифрами и общей длинной номера 11 этот алгоритм не подходит.
Так и не надо формулировать алгоритм генерации в виде '9 случайных цифр + контрольная сумма'
Просто: ID-ом является случайное число, кратное 101 (ну или, как у меня — 109) длиной меньше 12 десятичных цифр.
И все.
Ошибку в наборе в одном знаке находим, ошибку в двух рядом стоящих — находим. Чего еще хочется?
Как вариант, оставаясь в рамках ТЗ, возмите число 97, и наплюйте на гарантии обнаружения двойных ошибок, типа и по вероятности 1-1/97 сойдёт.
Но математически задача и в изначальной постановке имеет решение, надо только правильное «поле» подобрать.
Для любого M >= 100 взаимно простого с 10, остатки от деления X и X + E*10n на M, где E <= 99, будут отличаться.
В 11-ти значном числе, если в арифметике не ошибся, есть 99 вариантов ошибиться в одной цифре и 10 вариантов — переставить две рядом стоящие. Т.е. для гарантированного обнаружения таких ошибок валидным ID-ом должно быть каждое 109-ое число. Кажется, это означает, что двух десятичных разрядов контрольной суммы заведомо для этой задачи не хватить.Ошиблись, только не в арифметике.
Например, для гарантированного обнаружения ошибки в одной цифре номера любой длины достаточно иметь одну контрольную цифру. Очевидно, простейший код, где контрольная цифра является суммой по модулю 10 остальных цифр, обеспечивает обнаружение одиночной ошибку.
Если говорить за ошибки в двух рядом стоящих цифрах, до для восьмеричных номеров их гарантированно обнаруживает CRC-6, а шестнадцатиричных — CRC-8. Опять же для последовательностей любой длины.
Единственное, что я хотел выяснить — почему выбирают алгоритмы, переводящие десятичные цифры в отдельные десятичные же цифры контрольной суммы. Хотя можно выставить условие на все число сразу. Это выглядит так, как будто обеспечивают удобство ручного вычисления. Что странно.Я же уже объяснял почему так делать плохо.
С учётом того, что многие каналы для передачи номера оперируют цифрами, например, ввод с клавиатуры, такое использование CRC-8 окажется не очень хорошим, если не сказать грубее. Ошибка в одной цифре, может изменить любое количество бит двоичного представления, но CRC-8 гарантировано обнаруживает искажение не более 8 последовательных бит, а любые другие искажения лишь с вероятностью примерно 1-1/256
Правда, в приложении к CRC-8, но проблема касается почти любых кодов обнаружения ошибок.
Блочность кода, разбитие входной информации на небольшие блоки: биты, цифры и т.п., это не для удобства ручных вычислений, это для удобства математических доказательств свойств кода.
Ошибка в одной цифре, может изменить любое количество бит двоичного представленияЭто если рассматривать число, как записанное в DEC-представлении. В BCD-представлении изменение одной цифры изменит не более четырёх подряд идущих битов.
https://habr.com/ru/news/t/512936/#comment_21927332
Кратко: Следующая проблема попытки использования CRC-8 в том, что он вернёт 8 бит, которые не влезают в две цифры. Готовых решений, которые бы гарантировали обнаружение одиночной ошибки нет, есть только идеи.
Я же уже объяснял почему так делать плохо.
Так мы же не в техническом канале передачи ошибки ловим (там обычно какая-то защита от ошибок уже есть), а именно при наборе. Поэтому отдельно учитывать ошибки вида "n последовательных бит" вроде бы должны быть неактуально.
Вообще, можно же было взять ИНН или номер пенсионного и выдать их тем, у кого их сейчас нет, а тут ещё один номер какой-то
И в последнее время частая ситуация, почему то картинки со сторонних ресурсов грузятся через раз. Проблема не только у меня.
Ещё и выглядит как «битая» картинка(т.к. иначе отображался бы код/урл)
А если вручную сходить по урлу, то попадем на страницу на которой будет также и картинка.
Только урл страницы: xkcd.ru/927
А урл картинки с этой страницы: xkcd.ru/i/927_v4.png
ИНН привязан к региону выдачи. А
Страховой номер индивидуального лицевого счета, или СНИЛС, в системе обязательного пенсионного страхования является уникальным, принадлежит только одному человеку и присваивается один раз в жизни. Страховое свидетельство выдается всем категориям граждан, зарегистрированным в системе обязательного пенсионного страхования, в том числе детям, неработающим гражданам и военным.
То есть учёт уже есть, идентификатор 11тизначный. Даёшь ещё один! И контору к нему.
Это значит, что встречаются люди, у которых есть несколько ИНН. Челоьвек переехал — а налоговая выдала новый номер. Ещё бывали случаи, когда ИНН переходил к другому человеку. Короче, ИНН — это ненадёжная штука.
Данный же идентификатор — выдается всем.
не имеют возможности оформить СНИЛС
А в чем проблема дать им такую возможность? Это лишь набор цифр, наличие СНИЛСа еще не означет, что человеку будут платить пенсию, пособия и т.п.
Скорее всего есть операции разрешённые человеку со СНИЛС. Если выдавать негражданам СНИЛС то эти процедуры/законы/регламенты нужно переписать. И ПО поправить по всей стране.
Если выдавать негражданам СНИЛС то эти процедуры/законы/регламенты нужно переписать
Так уже выдают, достаточно заключит договор на работу от 6 месяцев и любой иностранец получает СНИЛС.
И нет, ничего особенного кроме доступа к госуслугам и потенциально к пенсии СНИЛС не дает.
Ну вот как минимум одно ограничение уже появилось) А из-под госуслуг очень многое можно сделать. И ещё нужно проверять что этот СНИЛС даёт+ многодетно история применения СНИЛС которое придётся тоже подправить. (Ну или возможно вы точно знакомы с процедурами и законами и укажете что это не так) А если бизнес поездка, или к родителям/родственникам раз в год приезжает. А этот смогут получить вообще все (хотя не уверен, ещё только обсуждения идут) Вообщем я думаю что не стоит брать старое. Унификация нужна с прицелом на будущее. И для этого по мне лучше что то новое, что изначально разрабатывалось для широкого применения (и потом будут на это ориентироваться законы и акты) А и забыл: тогда ещё надо будет номер СНИЛС выводить из-под ведомства которое его выдаёт
А из-под госуслуг очень многое можно сделать.
Что именно опасного может негражданин сделать из госуслуг?
Представим, что есть два иностранца с рабочими контрактами 6 и 5 месяцев, у первого есть СНИЛС, у второго — нет.
Конкретно какие-такие удивительные привелегии есть у первого, которые нельзя дать использовать второму?
Буду благодарен за ссылку. Пока что, проживая в РФ с ребенком и продлевая миграционную карту каждые 90 дней поездками зарубеж, получить СНИЛС ни себе ни ребенку не удалось. А его требуют как минимум чтобы заходить в электронный школьный дневник (на mos.ru который).
www.pfrf.ru/branches/spb/info/~vopros_otvet/2638
www.pfrf.ru/branches/spb/news~2015/01/23/83849
Не знаю, насколько соответствуют вашей ситуации
Да, я знаю про эту статью. На первый взгляд, СНИЛС может получить любой иностранный гражданин, но если вчитаться дальше, то только "постоянно либо временно пребывающий в РФ". А временно пребывающий — это тот у кого РВП. На РВП по квоте я в очереди уже 5 лет, и все никак. То же самое подтвердили в ближайшем ПФ.
Кроме того, в документах люди часто ошибаются, вводя различные номера, и эти ошибки зачастую приносят много проблем. Алгоритм проверки корректности номера не позволит просто так опечататься, так что и резон и плюсы в этом нововведении есть.
им нельзя выдать ни ИНН, ни СНИЛС
Почему нельзя?
Можно выдать ИНН даже, если человек сейчас не платит налогов (например, новорожденный), или СНИЛС, даже если у него пока нет право на пенсию.
Например, у нас в Люксембурге основной номер это номер соцобеспечения — первый 7 цифр это год-месяц-день рождения, а потом еще пять вроде произвольных чисел. При этом его выдают любому, кто регистрируется в стране, даже временно.
Кроме того, в документах люди часто ошибаются, вводя различные номера, и эти ошибки зачастую приносят много проблем. Алгоритм проверки корректности номера не позволит просто так опечататься, так что и резон и плюсы в этом нововведении есть.
Контрольное число СНИЛС рассчитывается следующим образом:
- Каждая цифра СНИЛС умножается на номер своей позиции (позиции отсчитываются с конца);
- Полученные произведения суммируются;
- Если сумма меньше 100, то контрольное число равно самой сумме;
- Если сумма равна 100 или 101, то контрольное число равно 00;
- Если сумма больше 101, то сумма делится нацело на 101 и контрольное число определяется остатком от деления аналогично предыдущим двум пунктам.
И ИНН и СНИЛС могут быть у иностранного гражданина.
А так мучительно родили абсолютно новый алгоритм (в точности повторяющий вычисление ИНН) и освоили очередной олимпиард бюджета.
Причём не просто номер, а номер с малым количеством цифр, ну что мешало сделать не 11 а 20? И контроль можно улучшить и проблем с тем что кто-то будет в int пихать нет :)
Первые девять разрядов номера генерируются случайным образом. Последовательность из девяти цифр должна быть уникальной.
Это вообще глупо, почему просто не по порядку, если так мало чисел?
Если бы можно было выделить пару разрядов на доп.информацию, например в каком городе или каким центром выдавали номер, а не уникальный рандом, который нужно согласовывать по всей территории РФ.
Ну проект только на стадии общественного обсуждения. Может, и поменяют алгоритм генерации.
Так это такая работа, новые идентификаторы каждые 3 года вводить, люди на этом уже наверное лет по 20 сидят, а так если ввести с запасом то они не нужны будут :)
640кб хватит всем! (с)
То есть когда рождается ребенок, ему система присваивает случайные 9 цифр. А потом надо просмотреть всю базу на 140 миллионов записей, чтобы убедиться, что число уникальное. И так пока не станет уникальным. Плюс базу надо блокировать, чтобы двум детям не дать одинаковые номера. Мне кажется, или тут перформанс потерялся.
Плюсом тут будет возможность разбивать комбинации на любое количество частей и хранить их в разных физических базах (условно в первой — первых 10 миллионов комбинаций, во второй — с 10 млн. до 20 млн и т.д.).
Зачем так сложно? Квоты. На бумаге генерируем по 100к записей и отсылаем заказным в роддом. Кончаются цифры — пишешь запрос на новую квоту. Тут тебе и майские указы по повышению рождаемости, и наказания в виде уменьшения количества квот… У — удобство. База только генерирует и печатает.
Действительно, пусть Гос. База сгенеренных номеров принимает запросы от ЗАГСов. Запросы ставятся в очередь и по-очереди загсам отправляются номера, тут же помечаясь как выданные. Всё. Не надо ничего постоянно генерить и сверять где-то в иглу оленевода или деревне гадюкино. Ну, кроме собственно уникальных защищенных запросов в сторону ГлавБазы.
Пусть рождается 4 человека в минуту (сейчас 3.3 чел/мин)- это совсем копеечная нагрузка, с собственно выдачей и регистрацией выдачи справится даже офисный комп.
Потом генерим любое случайное число и если оно уже занятЗачем так сложно? Просто просим базу выдать следующий незанятый номер, и сразу его забить. Не надо много раз что-то там генерировать, а потом много раз проверять в базе.
А что если первое число свободно и в двух потоках одновременно выпало это число?
Один из потоков заблокирует запись на уровне строки базы данных и поменяет ее. Второй поток обламается, откатит транзакцию и пойдет искать свободное поле дальше. Это же стандартная задача для работы с любой базой данных.
Да это не защищает от одновременного занятия номера, тут достаточно второго(максимум третьего) уточняющего запроса. Лучше чем тысячи повторных запросов от тысяч роддомов.
Индекс существенно упрощает задачу проверки. И в каком случае не понадобится блокировка?
А потом надо просмотреть всю базу на 140 миллионов записей, чтобы убедиться, что число уникальное.
Битовая карта на 1 млрд битов — это всего ~125МБ данных. Сканируется менее, чем за секунду.
Другое дело что есть теория вероятности и она говорит, что чем больше вы в такую базу вставите, тем чаще будет возникать коллизия на следующей вставке. Вероятность коллизии = n/N где n — число уже занятых ключей, а N — максимально возможное значение ключей. И вот тут у тех кто этот идентификатор придумал есть одна проблема: под фактический идентификатор (контрольные — зависимые числа) выделено только 9 знаков. Т.е. всего идентификаторов 1 миллиард. И когда туда 140 миллионов нынешних жителей вставят то уже с вероятностью 0.14 будет получать коллизию при вставке… Но люди то умирают и рождаются — в среднем за 70-80 лет поколение полностью сменяется и если старые ID после смерти не возвращать в используемые (допустим через 5 лет), то получим через 80 лет уже 0.28 (при условии что население расти не будет). А это уже каждая третья вставка будет натыкаться на коллизию. Дальше еще хуже…
Хотя о чем это я — за 80 лет они наверняка еще стопятьсот уникальных идентификаторов придумать успеют :)
Хотели бы без коллизий (ну с минимальной вероятностью) надо было брать N на много порядков выше числа занятых номеров в перспективе — что-то типа случайного UUID.
А самое печальное что коллизии они случайно распределяются и формулировка «каждая третья вставка провалится» может создать неверное впечатление что за три попытки то всяко вставим. А вот нет. Каждое событие в вероятностью 1/3 провалится и кому-то конкретно может банально не повести и получить заветный номер только с 5 или даже с 10 попытки. Комуто повезет с первой. В среднем — да будет каждая треться вылетать в массе запросов. Но комуто конкретному может все эти третьи и будут попадаться очень долго…
Социальное равенство же, цифры то случайные.
А единицы и нули это указание на пол?
Цветные штаны нельзя, цифры нельзя! Куда катится мир?
А если человек того, non-binary?
Но и с «биологическим полом» не всё так просто, да.
Даже на уровне биологии пол — это не одно монолитное понятие. Есть как минимум три уровня — хромосомный, гонадный и соматический. И хотя, по идее, между ними должна быть прямая зависимость (хромосомы определяют развитие половых желез — гонад, железы вырабатывают гормоны, влияющие на формирование остального организма), но мы живём не в идеальном детерминированном мире, и на любом из этапов этой зависимости может случиться какая-то поломка. Начиная с того, что и генотип (точнее, кариотип) может быть не только XX и XY, но и разные там анеуплоидии, и заканчивая тем, что гормоны действуют не «как положено» — например, в случае синдрома Морриса.
А еще бывает мозаицизм и химеризм: часть клеток (и даже органов в целом) имеет один кариотип, а другая часть — иной.
В общем, есть множество факторов, в результате которых получаются гермафродиты, гинандроморфы и прочие интерсексы.
Откровение Иоанна 13:18 "Здесь мудрость. Кто имеет ум, тот сочти число зверя, ибо число это человеческое".
А если старообрядцы возмущаться начнут ?
Отключат газ…
- Ну им за веру страдать не в первой.
- Да и негуманно это как-то :(
- Лучше мне кажется пока только готовятся ввести исключить из номера шестёрки напрочь. Чтобы ничьи умы не смущать во избежание.
Их проблемы. Веганы, вон, вообще от любой продукции животного происхождения испытывают гнев и возмущение, Но это не повод запрещать, или прятать мясо, кожу, или ещё что-нибудь
И он сделает то, что всем, малым и великим, богатым и нищим, свободным и рабам, положено будет начертание на правую руку их или на чело их,
и что никому нельзя будет ни покупать, ни продавать, кроме того, кто имеет это начертание, или имя зверя, или число имени его.
Стоит тег sarcasm ставить
Не поможет — рефлексы же у многих — что-то "противоречищее прогрессу" глаз увидел — на минус в карму палец нажал :)
Конечно так — поэтому и в кавычки взял !
А погодите, это уже сделали
Наверняка сделают обязательное указание этого номера при покупке симки, подключении к интернету, потом паспорт отпадёт за ненадобностью, полная деанонимизация. Интересно, а будут ли на чёрном рынке «левые» номера? И кстати, для чиновников наверняка будет механизм маскирования. Ну, типа вип-номер, везде отображается со звездочками.
— Привет, я — ebb3d1b9-05ca-4b5d-b344-931881555402!
— А я — eb7df85f-a798-408c-b4f3-7e50d21b0b0d.
Где-то заплакал Древарх
https://bit.ly/2DglFBk
Д-503, О-90...
Андрюха, у нас неопознанный труп, возможно — криминал. По коням!
Что Андрюха будет вводить в базу данных, разработчик которой полагает, что у всех граждан есть уникальный идентификатор? Есть-то он есть, только неизвестен.
Сюда же все вопросы замены документов, ошибок выдачи, всяких специальных случаев вроде программ защиты свидетелей. В государственных органах эти вопросы вручную, со скрипом, но решаются по каким-то внутренним регламентам. Автор системы будет на все грабли натыкаться сам.
Предположение, что каждому объекту присвоен идентификатор — это абстрактная идеализация, даже если речь идёт о деталях на конвейере. Идентификатор появляется в процессе выдачи и учитывается в базе данных (бумажной, электронной или какой-то ещё). Если у вас нет возможности взаимодействовать с этой базой, и остаётся только гадать о соответствии одного другому, то ничего хорошего из этого не выйдет.
https://jsfiddle.net/ktz3mLvd/5/
Примитивно, но работает. Описанная логика (вроде) соблюдена.
Но меня смутило "девять случайных цифр" — то есть множество ведущих нулей допустимо?
uuid же есть
Почему не использовать их везде где только можно?
К примеру к QR коду привязывать/шифровать мед. данные(группа крови, аллергия, несовместимые лекарства), чтобы скорая сразу знала как действовать.
А уникальных меток у человека и так хватает. И их уже давно собирают. Тот же сбербанк к примеру собирает лицо/голос/почерк. И можно в банкомате светануть лицом для опознания, но с учётом какие там камеры, обмануть их можно даже фотографией в теории. Кто понесёт вину(и будут ли возмещать) при этом большой вопрос.
… ведение… осуществляется органом исполнительной власти, осуществляющим функции по контролю и надзору за соблюдением законодательства о налогах и сборах
В общем, ещё один ИНН. Чуть далее расшифровка для непонятливых:
справочники и классификаторы… устанавливаются Министерством финансов Российской Федерации по согласованию с Федеральной налоговой службой
Не люблю я это понятие «случайные числа». Коллизий быть не должно, выходит? Алгоритм получения случайного числа будет, или закупим номера на random.org?
Код подразделения
ИНН
СНИЛС
ОГРН
Вод.права
Страховой полис
Нужно больше номеров богу номеров.
И самое печальное, что это будет просто очередной номер, по которому половина работает, половина нет, третьей половине нужно еще ФИО, четверной хватит ИНН.
ИНН — получение для физлица необязательно.
СНИЛС — не оформляется для иностранцев, работающих по срочному договору менее шести месяцев.
ОГРН — только у юрлиц.
Водительские права — номер бланка, меняется при смене прав.
Страховой полис — номер меняется при смене страховой компании или переоформлении договора.
Выдача ИНН и СНИЛС иностранцам, приезжающим на временную сезонную работу тоже особо не нужна, только будет захламлять базы налоговой и ПФР.
Выдача ИНН и СНИЛС иностранцам, приезжающим на временную сезонную работу тоже особо не нужна, только будет захламлять базы налоговой и ПФР.
Эээ, то есть сделать ТРЕТЬЮ базу в которой будут учитываться ВСЕ это лучше? Я уж не говорю о том, что потом скорее всего придется строить соотвествения ИНН-СНИЛС-Новый_общий_номер.
P.S. Я уж не говорю, что при существующих сейчас мощностях десяток миллионов записей (сколько тех иностранцев по всей РФ?) в правильно сделаной БД вообще не должен влиять ни на место, ни на скорость.
Выдача ИНН и СНИЛС иностранцам, приезжающим на временную сезонную работу тоже особо не нужна, только будет захламлять базы налоговой и ПФР.
Не захламлять, а, в случае ПФР, позволять учитывать пенсионные права)
Законы термодинамики, теорему Гёделя ещё не опровергли.
Я, лично, вообще вижу мало смысла во всей этой возне. Ну, кроме как отжать себе материальных благ…
ИНН — получение для физлица необязательно.
Это получение бумаги с ним необязательно. Но сам номер все равно будет сгенерирован. Просто вы его узнаете, когда он потребуется и за ним придете.
СНИЛС — не оформляется для иностранцев, работающих по срочному договору менее шести месяцев.
Не так велика проблема разрешить. Там на него идут пенсионные отчисления, но если их не делать, то будет 0.
Менять номер паспорта при смене вообще нет смысла. Сам номер не является секретным, а бумажку можно валидировать другими методами. Ну и т.д.
а бумажку можно валидировать другими методамиКакими, например?
В целом паспорт — просто бумажка. Сейчас практически любой человек наоставлял копий паспорта везде где только можно. Изготовить копию паспорта, которую бы приняли в банке не такая и проблема (ни разу у меня пристально не проверяли паспорт, а какой-нибудь Тинькофф вообще просто фото тебя делает). Какой смысл скрывать номер паспорта? Понятно что не стоит писать его на лбу, но все же это не такая уж и тайна.
UPD: Каждый факт валиации паспорта можно логировать, с записью ID устройства валидации, которые выдаются по отдельным законам.
При этом в законе прописана возможность по собственному желанию "изменить историю" насколько помню, но это работало когда были только паспорт + свид. о рождении, интересно сейчас как.
Будет считаться неприличным спрашивать у женщин ИНН?
Да и такой алгоритм тоже кажется странным. 6 цифр на дату, то есть год без столетия, и через 100 лет придётся снова возвращаться в тот же диапазон. А если из 12 цифр хотя бы две контрольные, то на уникальность остаётся 10000 вариантов на день, не так уж и много. Или дата кодируется иначе? Если, например, числом дней с какой-то даты, то 6 цифрами можно 2700 лет закодировать.
Я, конечно, понимаю, что вычислять, да ещё и по алгоритмам, это полностью в формате Хабра, но вот отвлечемся.
В Казахстане ввели Регистрационный Номер Налогоплательщика ещё (емнип) в 1993. Несколько лет после объявления почти не применяли, кстати, он был привязан к региону выдачи, народ умудрился получить по два, по три. Потом начали применять, да ещё сводить в общую базу, разобрались потихоньку.
Потом придумали СИК, это для пенсии, офигенная комбинация в 65 бит, записывалась цифрами и латинскими буквами (всего 32 символа) строкой из 13 символов. СИК вычислялся офигительным алгоритмом (мечта программиста) от ФИО и латы рождения. Одна ошибка в ведомости и платёж летит обратно, ну, ладно, это не технический показатель. Итак, у всей страны есть РНН и СИК, абсолютно нечитаемые и не запоминаемые.
«Обнуление»
Всем присвоены Индивидуальные Идентификационные Номера, с самого рождения. 12 цифр (12! Цифр!) Первые 6 — две цифры от года рождения, месяц, день. Абсолютно понятно сразу, где чей ИИН.
Потом ещё одна цифра — определяет пол и век рождения, так что ближайшая заковыка-«проблема 2300 года». И ещё пять цифр, обеспечивающих уникальность и целостность.
Для всех физлиц по ИИН и только по нему: налоги, пенсионный счёт ( напоминаю, в РК полноценная накопительная система без заморозки вкладов), учёт медстраховки, регистрация средств мобильной связи.
Что может пойти не так? Есть примеры?
И зачем каждое ведомство в РФ придумывает свой идентификатор для всей страны? (А это уже риторический вопрос :)
Да, ИИН нанесён на Удостоверение Личности, размером с кредитку. Последние версии УЛ имеют память, в ней можно хранить электронную подпись, считыватели продаются. Прекрасный новый мир :)
Проблема только в том что в итоге будут отклонения от алгоритма — пол и дату рождения могут поменять (коррекция ошибок, например, происходит чаще чем кажется). Номер от этого не перестаёт быть уникальным, но в каких-нибудь системах кто-то обязательно оптимизирует процесс и жёстко привяжет пол к 7й цифре. Непонятно зачем в ID вносить какую-то информацию. Номер должен быть просто уникальным в какой-то БД и все. Желательно случайным, но это не так важно
Так ИИН и есть «просто уникальный».
Если нет отклонений от нормы (смены пола :) и даты рождения, ума не приложу, зачем), то ИИН будет ещё и легко запоминаемым ( как у большинства граждан РК) — я могу, увидев ИИН в регистрационных документах, определить ошибку привязки.
А «случайность» там есть — в последних 5 цифрах, и «контрольная сумма».
Да, тут писали про «пиво для подростков» — продавец просто потребует УЛ, а там дата рождения прописана отдельно, крупно, и фотография владельца.
Для этнографов, в Казахстане внутренним документом гражданина является удостоверение личности ( в формате кредитной карты, с фото, ФИО, датой и местом рождения. Паспорт (книжечка с листами) существует только как «загранпаспорт».
Возможно, у нас это работает из-за меньших затрат, и на единый идентификатор, и на переделку старых баз данных. Нас же всего 17-18 миллионов, и никакого федерализма, вертикаль, понимаешь.
Для этнографов, в Казахстане внутренним документом гражданина является удостоверение личности ( в формате кредитной карты, с фото, ФИО, датой и местом рождения. Паспорт (книжечка с листами) существует только как «загранпаспорт».
Казахстан, по ощущениям, технологически несколько более развит, чем РФ. В то время, как в Казахстане уже были ID, в РФ проваливался проект УЭК, и вроде бы, чуть позже провалился ещё и проект электронных медицинских полисов.
Даже светодиодное освещение я видел на казахстанских предприятиях на пару лет раньше, чем оно массово появилось у нас в РФ.
Удостоверение с фотографией и удостоверение имеет свой номер. Хотя, конечно, фотка маленькая и можно перепутать :)
При утере заявляешь. Все, как в РФ с паспортом. И удостоверения проверяются через централизованную базу.
Вообще, с ИИН больше отдаёшь (налоги, пенсионные), чем получаешь.
Удостоверение личности имеет свой номер, уникальный, при замене номер удостоверения будет другим, а ИИН останется неизменным.
Да, ИИН присваивают новорождённым детям с рождения :)
Была бы уникальность в мировом масштабе, ну и сам протокол ipv6 продвинули бы заодно.
Опубликован алгоритм генерации уникальных 11-разрядных идентификаторов для жителей РФ