yasuokaの日記： ゼロからはじめるASCIIとISO-2022-JPとUTF-7 4
『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」には「<」も「>」も含まれていないのに、この記事では当然のように「<」と「>」が必要になっている。しかも「<」の名前文字参照を「>」と説明していて、もうワケが分からない。その次の記事、田所駿佑「Javaと文字コード char型の落とし穴と文字化け予防策」(pp.70-73)では、「𩹉(U+29E15 とびうお)」が例として使われており、𩹉(U+29E49)の文字コードを間違ってしまっているために、どう考えても「文字化け予防策」になっていない。うーん、こういう記事、どうすればいいんだろ。
「お詫びと訂正」が出てました (スコア:2)
『Software Design』2017年1月号p.184に「お詫びと訂正」が出てましたが、あまりに多くて…
さすがにこれは…… (スコア:1)
本屋で立ち読みしました（買う気がしなかった）が、これは酷い。誤りの多さは群を抜いています。「1件だけなら誤記かもしれない」けれど、あれは本格的にわかってない。絵文字の話をする暇があるなら、他のところに力を入れればいいのに。
ISO 2022の説明でJIS X 0201をSI/SOで切り替える例にしたために、ISO-2022-JPにつなげられない。そのくせISO 2022の解説図にはSI/SOが表記していない。わけがわからない。UTF-7の説明もおかしい（何も書かないとUTF-7と解釈されるんでしたっけ？）。
後ろの方も、JavaでEUC_JPの変換規則が3種類もあるのに、違いを説明していないし。どうやって使えというんだろう。「こんなにありますよ。適当に使ってね。」じゃあ困る。
解説しようといって出てくる記事が、この程度なんですから、頭が痛いですね。
Re:さすがにこれは…… (スコア:2)
私(安岡孝一)も、最初の記事「ゼロからはじめる文字コード」をチェックしてたら、かなり疲れてしまって、残りの記事はチェックし切れてないのです。でも、こういうのチェックするのは、読者の仕事じゃなくて、著者や編集者の仕事のような気もするのです。
「Part5 MySQLと文字コード」に (スコア:1)
「Windows-31JやJISは日本語と、日本でよく使用されることのある一部のラテン文字しか含んでいません」とありました。MySQLのWindows-31JやJISはJIS X 0208の6区(ギリシア文字)や7区(キリル文字)をわざわざ取り除く処理をしているのでしょうか。
説明不足ならまだしも、いろいろ誤解や誤りが含まれていてよくない特集ですね……