Какие символы Unicode разрешены в ярлыках хостов IDN?

В настоящее время я работаю над «правильным» валидатором URI, и в настоящее время все сводится к проверке имени хоста; остальное не так сложно.

Я застрял на метках имен хостов IDN (т. е. содержащих Unicode; возможные строки, закодированные с помощью punycode, были декодированы на данный момент).

Моей первой идеей было, по сути, одно регулярное выражение для TLD, которые не поддерживают IDN, и одно для тех, которые поддерживают. Возможно, это может быть основано на списке Mozilla ДВУ с поддержкой IDN. Соответственно, ^[a-zA-Z0-9\-]+$ и ^[a-zA-Z0-9\-\p{L}]+$. Однако это не идеальная ситуация, поскольку каждый регистратор IDN может решать, какие символы разрешать.

То, что я ищу, — это правильная, непротиворечивая и актуальная таблица данных символов Unicode, разрешенных в различных TLD. Складывается впечатление, что мне придется самому искать все данные на российских и китайских сайтах реестров (что довольно сложно).

Поэтому, прежде чем я попытаюсь собрать все эти данные самостоятельно, я поинтересовался, существует ли уже такой список. Или есть лучшие подходы, лучшие/общие практики и т. д.? (Я хочу, чтобы проверка была максимально строгой.)


unicode tld idn
person Roland Franssen    schedule 17.05.2010    source источник

Ответы (2)


arrow_upward
4
arrow_downward

IANA поддерживает список всех кодовых точек и их статус по адресу https://www.iana.org/assignments/idna-tables-6.3.0/idna-tables-6.3.0.xhtml#idna-свойстватаблиц

Все помеченные как PVALID безопасны в использовании. Те, которые отмечены CONTEXTO или CONTEXTJ, имеют больше правил, которым нужно следовать. Прочтите RFC5892 (IDNA) и RFC6452 (изменив статус пары символов) для получения всех кровавых подробностей.

person Joe Hildebrand    schedule 31.07.2014

arrow_upward
1
arrow_downward

Разве вы не можете преобразовать все домены Unicode в punycode и проверить это? Поскольку DNS в любом случае не поддерживает настоящие символы UTF-8, это может быть лучшим решением.

person Byron Whitlock    schedule 17.05.2010
comment
Правда.. я тоже об этом думал. Однако речь идет о пользовательском вводе. Я не могу сказать своим пользователям сначала заполнить uri, преобразованный в punycode. Таким образом, это оставляет мне (что вы, вероятно, имели в виду) внутреннее преобразование его в punycode... но это не означает, что имя хоста должно быть действительно действительным (поправьте меня, если я ошибаюсь), поэтому в этом случае соответствие любому символу Юникода (\p{ L}) и считать его действительным, по сути, одно и то же. Последний вариант будет моим запасным методом, если я не могу найти хорошее решение; если это произойдет, вы бы предложили придерживаться списка, который предоставляет Mozilla (например, 2 регулярных выражения)? - person Roland Franssen; 17.05.2010
comment
Чтобы уточнить выше; TLD, указанные в Mozzilla -› [a-zA-Z0-9\-\p{L}] / Все остальные TLD -› [a-ZA-Z0-9\-] Будет ли это надлежащей проверкой? - person Roland Franssen; 17.05.2010
comment
Это зависит от энкодера. Некоторые кодировщики преобразуют ввод в IDNA и должны следовать RFC5892. Другие кодировщики преобразуются в punycode и не обязаны следовать RFC5892. Это довольно легко проверить, просто введите клингонское DNS-имя, и если вы получите punycode, кодировщик не следует RFC5892 (клингонский алфавит находится в диапазоне кодовых точек RFC5892 DISALLOWED). - person Klaws; 18.06.2020