寝るまえに、 ICU4J で static IDNA API method は IDNA 2003 だから非推奨って公式 doc に書いてあったの見つけたので張っとく
IDNA (ICU4J 78)
カレーなる午後
afternooncurry@nostrplebs.com
npub1exjc...pmfx
Loves Indian cuisine, Italian food and sichuans. Piano, Classical music. Gardening.
ねむ。おやノス
CharUtils.isDot() と URLDetector.readDefault() の句点部分を削除したとして、ドメイン判定直るのかな？ 日本語は長いシングルラベルドメインとして扱われて、シングルラベルドメインは detect 対象外なので判定されない、って感じになんのかな
絵文字は大体 4 byte だったような。
漢字以外で BMP 超えの日本語の文字あったかな？ちょっとわからない
JISX0213 の第3水準、第4水準の文字は Unicode でらほはぼ BMP 超えなので 4 byte
結合文字とか使うと一文字何 byte と言えるだろうか、みたいな。
BMP より大きいところは 4 byte
UTF-8 の日本語は 3 byte か 4 byte だよ
スペース区切りで分割している上で IDNA 2003 で判定するライブラリ使ってるってことなのかな？
ほー。ICU4J は IDNA 2008準拠だが、static method は IDNA 2003 止まりになっていて android の java.net.IDN の実装にそれを使っていて問題だ、という issue があるんだな。
どのバージョンの ICU のことか分からんが、今の ICU4J の状況はどうなんだろ。
Google Issue Tracker
IDNA2008 では Stringprep と Nameprep はもう使われていない、とな。ICANN は IDNA2008 しかサポートしてない。
IDNA2008 に準拠するライブラリにしなさい、というのが recmendation のようだ。
Confluence
Java6 は 2006年からだから、RFC3490 に準拠してるのは変では無いか。
逆方向では無いか。順方向に変換できるものは全て国際化ドメインだ、と判定するやり方が想定外、ってことかな。
国際化ドメイン名からの NAMEPREP は順方向の正規化方法を規定しているだけで、逆方向の変換によってドメイン名と判定する使い方が想定外なのでは。
あ、今日から5月だった。通信量リセット！！
スカウター型のスマホでもどっか出してくれんかな。持つのめんどい
さーて来週のサザエさんは、じゃなくて、さーてコーヒーでも淹れて仕事すっか
まだ月曜日です
TGIF