Функции java IDN необратимы?

Почему некоторые IDN необратимы:

String domain = "aʼnċăwb7rňuħ.eu";
System.out.println(domain);
domain = IDN.toASCII(domain);
System.out.println(domain);
domain = IDN.toUnicode(domain);
System.out.println(domain);

Он отображает:

aʼnċăwb7rňuħ.eu
xn--anwb7ru-93a5e8ozmq2m.eu
aʼnċăwb7rňuħ.eu

Как видите, второй символ был разделен!

Спасибо


java idn
person Omar EDDASSER    schedule 25.04.2017    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Это по дизайну. Насколько я могу судить, второй символ в вашей строке — это кодовая точка ʼn. Согласно последним таблицам кодов Unicode:

этот символ устарел, и его использование настоятельно не рекомендуется

Таблица кодов Unicode говорит, что устаревшая кодовая точка эквивалентна \u02bc, за которой следует \u006e.

Согласно javadocs, первым шагом, который делает IDN.toASCII(String), является использование алгоритма RFC 3491 stringprep / nameprep для обработки символов во входной строке. Аннотация RFC гласит:

В этом документе описывается, как подготовить метки интернационализированных доменных имен (IDN), чтобы повысить вероятность того, что ввод и сравнение имен будут работать таким образом, чтобы это было понятно обычным пользователям во всем мире. Этот профиль протокола stringprep используется как часть набора сетевых протоколов для интернационализации системы доменных имен (DNS).

(Другими словами, stringprep усложняет создание сложных доменных имен, которые выглядят одно, а означают другое.)

На самом деле, если вы углубитесь, вы обнаружите, что предписанное отображение в таблицах stringprep для \u0149 равно \u02bc \u006e ; то есть эквивалент, определенный в таблицах кодов Unicode.

И... это то, что происходит.

Сводка

  1. Ваше ожидание того, что вы сможете использовать IDN в обоих направлениях, необоснованно.
  2. В любом случае вы не должны использовать этот символ, так как он устарел. (Конечно, использовать его в IDN — плохая идея!)
person Stephen C    schedule 25.04.2017

arrow_upward
0
arrow_downward

Процедура преобразования IDN в ASCII по своей сути является необратимой, поскольку она включает нормализацию Unicode (для формирования NFKC) как часть процесса. Как правило, несколько последовательностей символов Unicode могут иметь одну и ту же нормализованную форму; процедура IDN toUnicode создаст одну из этих форм из метки ACE, но нет гарантии, что это будет та же форма, которая была изначально закодирована.

Если результат toUnicode(toASCII(x)) отличается от x, то они, тем не менее, эквивалентны для целей IDN, и, кроме того, они должны быть эквивалентами совместимости Unicode друг друга. Вообще говоря, они будут одинаково отображаться шрифтами Unicode. В этом смысле немного удивительно, что в вашем случае есть заметная разница, но суть в том, что ваше очевидное ожидание обратимости необоснованно.

person John Bollinger    schedule 25.04.2017