2014年12月アーカイブ

下記のページに、「主権を?奪されて」というくだりがあって、頭の中で警報音が鳴り始めました。

「?奪」の「?」はHTMLソースから既に疑問符になってしまっています。何かが文字化けしてこうなってしまったのでしょう。

何が起こったのか想像する

前後の文脈から考えて、これは「剥奪」でしょう。もっといえば、「剝奪」だったのではないかというのが、私の想像です。何をいっているか、お分かりでしょうか。

「剥」と「剝」、両者は同じ字ですが、形の違いがあるのに気付いたでしょうか。左上の部分が「ヨ」のような形か「互」の上の横線が無いような形かどうかの違いです。

前者はJIS第1水準漢字(面区点位置1-39-77)ですが、後者はJIS第3水準(面区点位置1-15-94)、それも、JIS X 0213の2004年改正(JIS2004)で追加された「表外漢字UCS互換」10文字のひとつです。

上のウェブページでは、原稿に後者の「剝奪」を使ったところ文字化けしてしまったのではないかと想像します。MacでもWindowsでも「剝」を入力することはできます。

表外漢字UCS互換とは

「表外漢字UCS互換」というのは何かというと、『プログラマのための文字コード技術入門』第3章p.90でも説明していますが、簡単にいうと、印刷の字体としては「剝」の方がそれっぽくて好ましいのだけどもJISの例示字体は「剥」の方であった。そこで、JISの文字コード規格(X0213)の2004年改正の際に例示字体を変えたらいい、と考えた人がいたのだけど、Unicodeでは両者を区別し異なる符号位置を与えてしまっていて、JISの例示字体だけ変えると対応関係がうまくないことになってしまう。このため、JISでも以前からの「剥」とは別の符号位置に「剝」を用意することにした、というものです。こういうものが、この字を含めて10文字あります。

UTF-8やShift_JIS-2004, EUC-JIS-2004といった、JIS第3第4水準に対応した文字コードを使っている分には「剝」を使っていていもいいのですが、第1第2水準にしか対応していないJIS X 0208ベースのShift_JISやらISO-2022-JPなどに変換しようとすると、コード変換の実装にもよりますが上記の「?」のようになってしまいます。

上記のウェブページはUTF-8で符号化されているので「剝」を普通に文字として使うこともできるのですが、それでも「?」になってしまっているのは、もともと「剝奪」となっていた原稿を例えばメールで送信しようとしてISO-2022-JPを使ってしまったとか、プレーンテキストのファイルに保存するのに第3第4水準に対応していないコード(Shift_JISやその独自拡張の所謂CP932等)で保存してしまったとかいった事情があったのではないかと想像します。

常用漢字表の「剝」

ちなみにこの漢字は2010年に常用漢字表に入っています。例示されている字体は第3水準の「剝」の方です。ただし、手書きでは「剥」の形でもどちらで書いてもいいのですよ、ということが、常用漢字表では説明されています。

この字体差は手書きの楷書と明朝体活字との習慣の違いでしかないのであって、どちらでも同じ字です。正直これを文字コードで分ける意味は無いように思えますが、過去の経緯からしようがないという例のひとつだといえます。

JIS X 0213と常用漢字の各文字の対応は、JIS X 0213:2012で追加された附属書12に記載されています。

結局どうすればいいのか

JIS X 0213に含まれる文字を全部カバーしている符号化方式、例えばUTF-8やShift_JIS-2004, EUC-JIS-2004を常に使用していれば文字化けしません。現在なら常にUTF-8で困ることはあまりないでしょう。SJISやEUCの符号構造が必要な場合にはShift_JIS-2004やEUC-JIS-2004が使えます。

付記

リンク先のウェブページは、もしかすると全然違う理由で「?」になってしまっていて、元の字も実は「剝」ではなかった、という可能性はもちろんあります。推測ですのであしからず。

拙著『プログラマのための文字コード技術入門』の電子書籍版が発売されました! 紙の本と同内容です。2014年12月10日から発売されています。

技術評論社の販売サイトから購入できます。WEB+DB PRESS plusシリーズの他の書籍も電子版がそろっていますので、そちらをチェックしてみるのもいいですね。

フォーマットは今のところPDFのみとなっています。DRMはかかっていないそうなので扱いやすいと思います(購入者の情報がファイルに埋め込まれます)。

PCやタブレットで読みたい方、検索等の電子書籍ならではの機能を活用したい方、本棚が慢性的に不足している方などは、ぜひ電子書籍版をどうぞ。

もちろん、紙の本も今までどおりに購入できます。

前の記事に部首画数順という言葉が出てきました。「ああ、部首ね」と、どういうものか分かるかと思いますが、細かく見ていくと、部首というのはあまり分かりやすいものでない。部首ってなかなか厄介だ、というお話を少し。

例1 「巨」の部首

「巨」の部首が何であるか知っているでしょうか。漢字に詳しい人は知っているでしょうけど、学校教育を普通に受けただけでこの問いに正確に答えられる人は多くないでしょう。

模範解答は「工」です。漢和辞典には工部2画として掲載されています。「巨」の中に「工」が見当たらないので訝しく思うかもしれませんが、実は元々「巨」という字は「工」の縦線に「コ」型がくっついたような形だったのです。それが変化して今の字体になった。それで今でも「工部」に分類されているのです。と、まるで見てきたように言っていますが、ものの本で読んだことの受け売りです。ちなみに辞書によっては利用者の便のために異なる部に配置しているものもあるそうです。

例2 門構えの漢字の部首

もうひとつ。「問」「間」の部首はそれぞれ何であるか分かるでしょうか。どちらも門構えがついているから「門」でしょうか。

ところがそうではなく、「問」は口部、一方、「間」は門部に属するとされています。似た構成なのに部首は違うんですね。ちなみに「聞」は耳部で、「開」は門部。何がどうなっているのか。音読みがモンであるものは門部ではない、ということに気付いたでしょうか。形声文字に意符・音符という要素がありますが、「門」が音符となっていれば、その「門」は部首ではないわけです。例えば形声文字の「誠」の部首が「言」であることはすぐ分かると思いますが、部首でない方の「成」が音符として働いているわけです。これと同じです。

あまり調子に乗るとボロが出そうなのでこの辺でやめますが、いいたいことは、部首というのはそう簡単でない、結構面倒だ、ということです。

部首とはそもそも何なのか

実は「部首」という言葉自体も面倒というか、誤解されているなと感じることが時々あります。例えば「誠」の部首として「言」と「成」の両方を挙げてしまうような話し振りを聞くことがあるかもしれません。これは間違い。

部首というのは、漢字を構成要素に基づいて分類した「人部」や「火部」や「言部」などの「部」の、「首」つまり冒頭の文字を元々いうのです。漢和辞典で「人部」を見ると、にんべんのついた漢字がたくさん並んでいるその先頭に「人」という字があるはずです。これが「部首」。だから「誠」の部首は「言」であって(つまり言部に所属するということ)、「成」ではない。

現在使われている部首は18世紀の康熙字典に基づいたものですが、それより昔の字書では異なる分類があって部の数も変わっているので、大昔から不変のものというわけでもありません。

考えるに、部首がまずあってそこから演繹的に個々の漢字ができたわけではなく、山のようにたくさんある漢字をどうにか分かりやすく分類・配列しようとして編み出されたのが部首という方式であるとすれば、そう整然としたものになってくれないのも無理からぬことでしょう。

こんなブログ記事があって、面白く読みました。

「数字順にソートされない理由」はリンク先のブログ記事に書かれているとおりですが、「数の順にソートされないこと」が意外だということが、私には興味深く思えました。「漢数字」ではなく「漢字」ととらえれば、数の順に並ぶ必然性が特にないことは自然と納得されると思います。

文字コードにおける漢字の並び順

『プログラマのための文字コード技術入門』にも書きましたが、文字コード規格における漢字の並び順をちょっとおさらい。

  • JIS X 0208/0213の場合: 第1水準漢字は読みの順番、第2〜第4水準は(その水準内で)部首画数順
  • Unicodeの場合: 部首画数順 (ただし、順序はブロック内でしか通用しないので注意)

第1水準の読みの順番は、音読みが多いですが訓読みのものもあります。また、第3水準は第1水準の前や第1水準と第2水準の間にもあるので、単純にコードでソートするとおかしなことになります。さらに、JIS2004で第3水準に10文字追加された「表外漢字UCS互換」は、後から第3水準の隙間に詰め込んでいるので、これも例外となります。

またUnicodeの場合も、元々のCJK統合漢字ブロックと後から追加された拡張A, Bなんかをまたがると、コード順で整列した順序はデタラメになってしまいます。互換漢字があったりするとやはりうまくない。

対処の方針

文字コード順のソートは、あてにしないのが良いです。漢字の場合には特にです。例えばデータベースに格納されている人名のような場合は、読み仮名を別途持っておいてそれでソートする。

また、漢字以外でも、例えばアクセント付きのアルファベットを用いるフランス語やドイツ語等の欧州言語の場合にも文字コード順のソートというのはうまくありません。言語ごとの照合規則を用いる必要があります。JavaならCollatorクラスを使うとこれができます。『プログラマのための文字コード技術入門』p.257で紹介しています。国際的に使われるプログラムにはこうした考慮が必要となります。

余談

漢数字「一」「二」「三」に限ると、文字コード順のソートでは、JIS順でもUnicode順でも「一→三→二」になります。これはただの偶然の一致なのですが、ちょっと面白い、というか、ときによると紛らわしいかもしれません。

広告