[62] ToUnicode は、Unicode の文字列をできるだけ正規化し、 Punycode を復号する操作です。
[77] ドメインをUnicodeにする演算は、 ドメインドメインを、次のようにします >>76。
[19] UTS #46 の ToUnicode 演算は、
入力として次のものを受け取ります >>17。
[38] 次のようにします >>17。
[74] テストデータ:
[63] Unicode IDNA互換性処理はドメイン名に含まれる文字を正規化し、 Punycode を復号します。これは ToUnicode 操作そのものであると共に、 IDNA2008前処理として IDNA2008 本体での処理の前段階として用いたり、 ToASCII 操作の最初の手順として用いたりします。 Unicode に戻すために使うだけでなく、 ASCII (Punycode) にしたいときもまずはできるだけ Unicode 化して正規化した状態にするということですね。
[41] 入力は、次のものです >>44。
[64] 移行的処理と非移行的処理の違いは IDNA2003 と IDNA2008 で Aラベル (ACEラベル) への変換結果が変わってしまう4文字の扱いだけ >>25 です。 移行的処理はこの4文字を IDNA2003 風に写像して他の文字に変えたり削除したりしますが、 非移行的処理ではそのまま残します。
[45] 出力は、 (Unicode文字列, boolean) の組です。 Unicode文字列は、変換結果です。 boolean は、誤りの有無を表します。 誤りがあっても、出来る限りの変換結果の文字列が返されます。 >>44
[34] 次のようにします >>44。. で分割した結果に設定します。xn-- なら、. で連結した結果に設定します。
[33] 誤りが真なら成功、そうでなければ失敗です。 >>44
[65] 実装は、利用者に表示する時には、更に変更を加えても構いません。
例えば誤りが真に設定される原因の部分を U+FFFD
に置き換えたりすることが推奨されます。 >>44
[37] 誤りとなる場合の処理は、 Chrome も Firefox も、仕様書とは少しずつ違うようです。
両者も互いに異なります。非ASCII文字を含む場合、含まない場合、
誤りとなる文字の種別、 xn-- から始まる場合、
Aラベルを復号したら不正な場合などでそれぞれ違った結果になります。
[85] Chrome でも Firefox でも、入力 (正規化前) のドメイン名全体で非ASCII文字をまったく含まないなら妥当性基準を検証しないようです。
[89] Firefox は妥当性基準のうち - の検査を行わないようです。
Chrome はドメイン名全体で非ASCII文字を含む時、
ASCII文字のみのラベルも含め、行うようです。
[91] Chrome は偏差となる U+200C と U+200D
を無視としています (移行的処理の挙動)。
Firefox は妥当として扱い (非移行的処理の挙動)、
ContextJ規則の検査も行いません。
[90] IE は、 bidi規則の検査は (IDNA2008 相当も IDNA2003 相当も) 行っていないらしいです。
[92] Firefox も bidi規則の検査は行っていないようです。
[93] Chrome は IDNA2003 相当の検査は行っていないようですが、 何らかの検査は行っているようにみえます。
[108] Chrome は非ASCII文字が含まれるとき、 最後 (末尾の点後) 以外のラベルが空かどうか検査し、 空だとエラーとするようです。 非ASCII文字が含まれなければエラーにはしません。
[109] Chrome は非ASCII文字が含まれる時、 ラベルの長さの検査も行うようです。
[94] new URL ("http://\u0640a") は Chrome でエラーになります。
Firefox ではエラーになりません。
[83] IDNA2003 時代は、写像などの処理は Nameprep によって規定されていました。 (ただし IDNA2003 の仕様書はラベルに対する演算としているのに対し、 現実にはドメインに対する演算として実装されていて、その点は当時からすでに現在の UTS #46 と同じでした。)
[84] Nameprep では NFKC を使っていましたが、 UTS #46 では NFC を使っています。互換分解は Nameprep の他の処理と共に写像に組み込まれています。
[66] 移行期間中の DNS lookup では移行的処理を、表示を含むそれ以外の場面では非移行的処理を使うべきです。 >>25 2.1 両者の違いは偏差に分類される4文字だけであり、 lookup では移行的処理を使っていたとしても、 表示においては非移行的処理が利用者の入力により近い形になるので好ましいです。
[40] http://www.unicode.org/reports/tr46/#Table_Example_Processing にこの算法の適用例がいくつも示されています。
[36] 利用者にドメイン名を提示する時には更に変更を加えても構いません。
禁止されている文字を U+FFFD に置き換えたり、
妥当性検証で失敗したラベルを U+FFFD その他の表示により利用者に示したりするのがよいとされています。 >>44
[72] Unicode IDNA互換性処理とそれを使った ToUnicode, ToASCII は、次の場面で呼び出されます。
[1] IDNA2003 の ToUnicode 演算は、
国際化ラベルをACEラベルでない国際化ラベルに変換します。
大まかに言うと Punycode を復号して人間可読な文字列に戻す操作です。
[86] 入力:AllowUnassigned。 RFC 3490 4.2UseSTD3ASCIIRules。 RFC 3490 4.2
[11] ToASCII を内部的に呼び出すので、 >>10 が入力となっています。直接は使っていません。
[87] 出力:
[5] ToUnicode は失敗しません。
>>8 の算法が失敗した場合、
入力をそのまま出力とします。
RFC 3490 4.2
[8]U+0000〜U+007F)
に収まっていれば、 3 に進みます。AllowUnassigned を使用します)。
誤りがあれば失敗とします。ToASCII を適用します。
[15] 確認して違っていたらどうするのでしょう。失敗とすることを想定しているように見えますが、 明記されていません。
[16] 失敗した場合、 >>5 によりもとの入力が ToUnicode の結果となります。
[88] IDNA2003 ではラベルに対して、UTS #46 ではドメイン名に対して ToUnicode 操作が定義されています。また、 UTS #46 では ToUnicode と ToASCII の共通の内部操作Unicode IDNA互換性処理も定義されています。
[20] UTS #46 のIDNA2008前処理は、 (完全な Unicode IDNA互換性処理を行うのとは違って) IDNA2008 の規定する処理に対する前処理として使うことができる算法であり、 その適合性のクラスです。これは移行処理が特に必要がない場面で利用できます >>25。
[21] IDNA2008前処理とは、入力となる文字列に ToUnicode 演算 (>>19) を適用することと定義されています >>23。
my understanding is that Microsoft and Google do not want to switch away from Transitional until at least some solution is found to the attacks mentioned in this bug.
[68] Cleanup definitions of domainToASCII() and domainToUnicode(). Give up… · whatwg/url@d18639f ( 版) https://github.com/whatwg/url/commit/d18639f13cb710938f2251a8f0e40b637aa82823
[69] Add a section on rendering URLs with some advice around bidirectional… · whatwg/url@d1152b9 ( 版) https://github.com/whatwg/url/commit/d1152b94a16ae91e1f72d128fd5ef589635f0e7c
URL インターフェイス domainToUnicode 静的メソッド[111] URL インターフェイスの
domainToUnicode 静的メソッドは、
次のようにしなければなりません >>110。
[118] ドメインをUnicodeに操作を直接呼び出さずにホスト構文解析器を挟んでいますから、 パーセント符号化の処理、IPアドレスかどうかの判定、 不適切なASCII文字の検査が追加で行われます。
[119] domainToASCII 静的メソッドを実行してからドメインをUnicodeにを実行するのと等価です。
[120] Remove URL.domainToASCII and domainToUnicode (annevk著, ) https://github.com/whatwg/url/commit/2bd0f59b98024921ab90e628b7a526cca5abcb5f
[121] Use Nontransitional_Processing for IDNA ToASCII (annevk著, ) https://github.com/whatwg/url/commit/f4d84a52e67b154b2d11e04889fe0a35a029c833
[122] IDNA: use proposed UTS46 flags to avoid breaking YouTube (annevk著, ) https://github.com/whatwg/url/commit/dc9d83106cada9af507bf37dee3973de97b020fd
[125] IDNA / UTS #46 "should" requirements (Bidi and Joiners) · Issue #110 · whatwg/url () https://github.com/whatwg/url/issues/110
[126] IDNA: realign once UTS46 revision 18 is final · Issue #313 · whatwg/url () https://github.com/whatwg/url/issues/313
[127] Address several IDNA issues by annevk · Pull Request #309 · whatwg/url () https://github.com/whatwg/url/pull/309
[128] IDNA · Issue #53 · whatwg/url () https://github.com/whatwg/url/issues/53
[129] IDNA: UTS46 revision 19 is part of Unicode 10 (annevk著, ) https://github.com/whatwg/url/commit/b128ba9111c68ad767b472d77d0ada9ef85366ef
[130] IDNA: UTS46 revision 19 is part of Unicode 10 by annevk · Pull Request #325 · whatwg/url () https://github.com/whatwg/url/pull/325
[124] Continue to use Nontransitional processing for IDNA (TRowbotham著, ) https://github.com/whatwg/url/commit/6800342832fdf99caa265d0106cf984123716d9d
[131] Preserve use of Nontransitional processing for IDNA by TRowbotham · Pull Request #404 · whatwg/url () https://github.com/whatwg/url/pull/404
[132] Restructure URL rendering section and add additional guidance (estark37著, ) https://github.com/whatwg/url/commit/8809598ddfd1d935432c8a0cad53f13d70e24bc6