『Software Design』の最新号(2016年12月号)を読んでいたところ、田所駿佑の「ゼロからはじめる文字コード　符号化のしくみと、ASCIIからUTF-8への系譜」(pp.60-65)という記事が目にとまった。目にとまったのには理由があって、p.61の「表1 US-ASCII」にバグがあったからだ。0x3Cが「←」、0x3Eが「→」になっている上に、0x3Bが「;;」、0x1Cが「FC」になっていて、ちゃんとチェックしてないのかしら、と思える。そもそも、本文が基本的に「ASCII」なのに、表1のタイトルと説明だけが「US-ASCII」になっていて、何か使い分けがあるのか良く分からない。それに加え、「ISO/IEC 2022」の説明の中に「EUC-JP」と「UTF-16」と「UTF-8」が出てきて、「ISO-2022-JP」がどこにも出てこないのは、私(安岡孝一)個人としてはどうにも腑に落ちない。また、「図3 ISO/IEC 2022のしくみ」に「G0」と「G1」と「G3」があるのはいいのだが、「G4」があって「G2」が無いのは、正直なところ理解できない。「EUC-JP」の説明に「0x8F未満のコードポイントはASCII」と書かれているのも、理解できない。それだと0x8Eから始まる「JIS X 0201カナ」が困ってしまうし、「図4 EUC-JPの構造」とも話が合わない。

次の記事、田所駿佑「HTMLと文字コード　仕様を理解し、文字を正しく表示する」(pp.66-69)では、何の説明もなしに「UTF-7」が現れていて、かなり混乱している。その上、前の記事の「表1 US-ASCII」には「<」も「>」も含まれていないのに、この記事では当然のように「<」と「>」が必要になっている。しかも「<」の名前文字参照を「&gt」と説明していて、もうワケが分からない。その次の記事、田所駿佑「Javaと文字コード　char型の落とし穴と文字化け予防策」(pp.70-73)では、「𩹉(U+29E15 とびうお)」が例として使われており、𩹉(U+29E49)の文字コードを間違ってしまっているために、どう考えても「文字化け予防策」になっていない。うーん、こういう記事、どうすればいいんだろ。