В спецификации DICOM UID определяется: 9.1 Правила кодирования UID. Другими словами, допустимы следующие DIDOM UID:
- "1.2.3.4.5"
- "1.3.6.1.4.35045.103501438824148998807202626810206788999"
- "1.2.826.0.1.3680043.2.1143.5028470438645158236649541857909059554"
в то время как следующие недопустимые DICOM UID:
- ". 1.2.3.4.5"
- "1..2.3.4.5"
- "1.2.3.4.5".
- "1.2.3.4.05"
- "12345"
- "1.2.826.0.1.3680043.2.1143.50284704386451582366495418579090595540"
Поэтому я знаю, что строка не более 64 байт и должна соответствовать следующему regex [0-9\.]+
. Однако это регулярное выражение действительно является супермножеством, поскольку существует намного меньше возможностей (10+1)^64 (=4457915684525902395869512133369841539490161434991526715513934826241L)
.
Как бы точно вычислить количество возможностей для соблюдения правил DIDOM UID?
Чтение правила org root/suffix ясно указывает, что мне нужна хотя бы одна точка ('.'). В этом случае комбинация не менее 3 байтов (char) в форме: [0-9]. [0-9]. В этом случае существуют возможности 10x10=100
для UID длины 3.
Глядя на первый ответ, кажется, что-то неясно о:
Первая цифра каждого компонента не должна быть равна нулю, если только компонент - это одна цифра.
Это означает, что:
- "0.0" действительно
- "00.0" или "1.01" недействительны
Таким образом, я бы сказал, что правильное выражение будет:
(([1-9][0-9]*)|0)(\.([1-9][0-9]*|0))+
Используя простой код C, я мог бы найти:
- f (0) = 0
- f (1) = 0
- f (2) = 0
- f (3) = 100
- f (4) = 1800
- f (5) = 27100
- f (6) = 369000
- f (7) = 4753000
- f (8) = 59049000
Валидация части корневого UID выходит за рамки этого вопроса. Второй шаг проверки может позаботиться об отказе от какого-либо OID, который не может быть зарегистрирован (некоторые упоминают ограничение на первую и вторую дугу, например). Для простоты мы примем все возможные (допустимые) корневые UID.