つい先日発売された、筒井康隆「アホの壁
いうまでもなく、養老孟司「バカの壁
この「序章」に執筆の経緯が書いてあるのですが、ここがまず秀逸。というか、面白い。
仕事をしている人であれば、最も自分に引きよせて読むことができるのは、第4章「人はなぜアホな計画をたてるか」だと思います。この章に書かれていることをどれもこれも他人事だとして読んでしまい自らを顧みることを全くしない人は、おそらく、それこそ真正のアホであるか、ないしは凄い天才であるかのいずれかでありましょう。
本書には、ベストセラー「国家の品格
少し前にテレビでアニメの「ルパン3世」を放映していました。地上デジタルテレビの番組情報画面を何気なく見たら、声の出演者として
この人名の2文字目、「璐」はJIS第3水準漢字、面区点番号1-88-29です。地上デジタル放送の文字情報では漢字が表示できていませんでした。先日の「世界ふれあい街歩き」のときにも思ったことですが、デジタルテレビの仕様を決めるときにJIS X 0213に対応していればこういうことにならなかっただろうに、残念なことです。
東京・成城ホールにて、「筒井康隆、筒井康隆を読む」という朗読会を鑑賞してきました。筒井康隆による自作の朗読劇です。
もう10年以上前にも同様の朗読劇を鑑賞したことがあって、こういうものが面白いということは知っていました。小説を自分で黙読するのと、上手な人が演じるのとでは、同じ作品の同じ字面を読むのであっても、全く違う体験ができるのです。それが自分の好きな作家であれば、とりわけ筒井康隆であれば、面白くないわけはないのです。
演じられたのは、「昔はよかったなあ」と「関節話法」、それに上山克彦演じる一人芝居「陰悩録」。さらに山下洋輔のピアノ演奏もあるという贅沢な舞台でした。アンコールで「発明後のパターン」のオリジナルに加えて現代版というのもやられました。筒井作品に詳しい方にはすぐお分かりのとおり、いずれも笑いを誘う作品です。
残念ながら、筒井氏自身によるこうした朗読劇は今回を最後としてもうやらないのだそうです。ホールにぎっしり入った観客は大いに笑っていました。惜しまれながらの最後の舞台ということになります。
北道邦彦「アイヌ語地名で旅する北海道
また、間違って認識しやすい地名も取り上げられています。例えば、知床はアイヌ語で「地の果て」だとする説を結構見かけますが、これには問題があって、「地の先」と解釈する方が適切だそうです。あるいは、山名のニセコアンヌプリというのは「ニセコ・アンヌプリ」と分けられると思いがちですが、アイヌ語の文法に即していうなら「ニセイ・コアンヌプリ」となるのだそうです。
さて、この本ではアイヌ語を片仮名で表記しているので、通常の日本語表記用とは異なる片仮名が頻出します。例えば、小さく書くㇻㇼㇽㇾㇿなどです。コンピュータ上の文字コードとしては、2000年制定のJIS X 0213において、これらの字のコードが決められています。JIS X 0213に対応したソフトウェアならこうした字が使えるのです。
同書のアイヌ語の片仮名を見ると、必要に応じて小書きの片仮名を使っています。しかし、字のサイズが、「ッ」のような普通の小書きの片仮名と釣合いがとれていないのが気になります。
例えば、p.115で「シレトコ アナㇰ シレトッコㇿ!」(知床は美しい!)と書かれていますが、後半の「ッ」と「ㇿ」を見比べると明らかに「ㇿ」の方が小さく、バランスを損なっています。「ㇿ」などの小さな字を特別に用意したのでこうなったのでしょうか。
また、「ト゚」(半濁点付きのト)における半濁点は、妙に大きくなっています。用意されていない活字なので何か間に合わせで作字したのでしょうか。例えばp.213に「パンケ ト゚エ ピラ」と書いてありますが、「パ」や「ピ」の半濁点と比べて「ト゚」の半濁点が明らかに大きく、バランスを損なっています。
印刷にいつでも使える文字として、JIS X 0213の文字が網羅されていれば、「ㇿ」や「ト゚」なども他の文字とのバランスを考慮してデザインされ、読者に違和感を与えずに済んだかもしれません。やはり、JIS X 0213をサポートすることが大変大事であるように思えます。
なお、Unicodeでサポートしようとすると、上記の「ト゚」や、ほかにもアイヌ語で頻出する「ㇷ゚」などは単一の符号位置でなく、結合文字を使って2つの符号位置の組み合わせによって1文字を表現する必要があります。「ト゚」ならU+30C8 U+309Aという列になるという具合です。プログラミング上、注意が必要です。
このほど技術評論社さんから著書が発売される運びとなりました。
著者自身による紹介ページを作りました。興味がありましたらどうぞ。
私がぼやぼやしている間に、著名なプログラマのhyoshiokさんにブログで取り上げていただきました(「プログラマのための文字コード技術入門を読んだ」)。ありがたいことです。
ちなみに正式な発売日は2月18日ですが、早く店頭に並ぶ書店もあるようで
す。Amazon
宮城県角田市に「𥼣塚(しいなつか)」という地名があるようです。米へんに無という「𥼣」の字は、JIS第4水準、面区点番号2-84-04。UnicodeではU+25F23という、BMP外の位置にあります。UTF-16ではサロゲートペア、UTF-8では4バイトのUTF-8が処理できる必要があります。SJISならShift_JIS-2004、EUCならEUC-JIS-2004で扱えます。
この地名はJIS漢字字典にも載っています。ネット上の地図サイトでは、「しいな塚」と、平仮名をまぜて書かれるようです。
この字の用例をWebで探してみたところ、角田市のWebサイトにありました。
角田市市税条例のページの後ろの方、「別表」の中に、「字𥼣塚」と、「𥼣」の字を画像にして表現しています。
市のサイトに漢字で書かれているということは、役所の発行する印刷物ではやはり漢字で書かれているのではと想像します。
大修館書店の「大漢和辞典」では、「しったげきれい」や「しっせき」などの熟語に使われる「しかる」という漢字、口へんに七という字は、3247番にあります。
ところが、Unicodeの漢字のデータを揃えているUnihanデータベースを見ると、大漢和辞典の3247番を参照している文字は存在しません。口へんに匕のように書く「叱」U+53F1は大漢和辞典の3247でなく3248番ということになっています。大漢和辞典ではこの字は「しかる」ではなく、「か」という読みの、「口を開くさま」という意味の字だとされています。また、近頃一部で話題のU+20B9Fという符号位置(口へんに七、「𠮟」)についても、大漢和の3247番への参照はついていません。
なんと、「しかる」という特に珍しいわけでもない字がUnicodeには存在しなかった!
......まあ勿論、単にUnihanデータベースの整備不良なのでしょうけど。
本来は、U+20B9FかU+53F1に大漢和辞典の3247番への参照があるべきでしょう。U+53F1につけていいかどうかは微妙ですが、大漢和の3247番の説明には俗に「叱」の形に作るともあるので、まあいいんじゃないでしょうか。それに、U+53F1の元になっているJIS X 0208の28区24点が「しかる」でないとは考えにくいですし。
Unihanを更によく見ると、読みを記したファイルにはU+53F1の日本語の読みとして「しち」「しつ」「しかる」を掲げているので、大漢和辞典の3248番だという参照とは矛盾しています。3248番だとするのなら読みは「か」でなければならず、あるいはU+53F1が「しかる」という読みだとするのなら大漢和辞典の3247番でなければなりません。
ちなみに、大漢和辞典における3248番の「か」という読みだとする字の説明は、昔の字書の説明を引いているだけで、熟語も用例もありません。現実の言語表記において、「か」という読み、「口を開くさま」という意味として、実際にどれくらい使われた実績があるのかは、大漢和辞典の説明からだけでは想像がつきません。
文字コード変換プログラムのiconvでは、文字コード「UTF-8」において、入出力ともにBOMを用いません。
出力においてBOMを使わないということは、すぐに納得がいくことと思います。UTF-8として出力されるバイト列の先頭にBOMがつかないということです。
かたや、入力においてというのがどういうことかというと、BOMに相当するバイト列を 見ても、それをBOMとは認識しないということです。
つまり、データ先頭にEF BB BFという3バイトがあったら、それをBOMとして消費するのでなく、単なる普通の1文字のように扱うのです。
ちょっと実験してみましょう。
UTF-8にBOMを付けて出力するプログラムとしてポピュラーなのはWindowsのメモ帳です(XPで確認)。メモ帳でUTF-8としてテキストを保存するともれなくBOMがついてきます。
例えば、メモ帳で「あ」とだけ書いて改行し、UTF-8で保存する。すると、EF BB BF E3 81 82 0D 0A というバイト列になる。
これをiconvでShift_JISに変換しようとする。「あ」と書いてあるだけなのだから問題ない筈と思いきや、これがうまくいかない。
$ iconv -f UTF-8 -t SHIFT_JIS a.txt > a-s.txt iconv: illegal input sequence at position 0
なんと、エラーでとまってしまいます。
なぜかというと、先頭のEF BB BFをBOMとみなすのでなくテキストの一部と解釈し、U+FEFFの文字をShift_JISに変換しようとして、Shift_JISには該当する文字がないので、当然のごとく失敗しているわけです。
この場合、iconvにオプション -c を付けて、変換できない文字を無視するようにすればエラーなく通ります。
また、上のUTF-8テキストをUTF-16に変換しようとするとこうなります。ここではUTF-16BEやUTF-16LEでなく、UTF-16を指定します。つまり、BOMを用います。
$ iconv -f UTF-8 -t UTF-16 a.txt | hd 00000000 ff fe ff fe 42 30 0d 00 0a 00 |....B0....|
なんと、BOMが2つ並ぶという残念な結果になってしまいます(先頭のff feがBOM)。もう説明の必要はないと思いますが、UTF-8テキストの先頭の3バイトがBOMとして解釈されず、UTF-16を出力するときに改めてBOMを付けようとするので、こういう結果になっています。
上で使った出力のUTF-16はBOMを用いますが、ではBOMを付けないつもりでUTF-16BE を指定するとどうなるか。大体想像がつくと思いますが、こうなります。
$ iconv -f UTF-8 -t UTF-16BE a.txt | hd 00000000 fe ff 30 42 00 0d 00 0a |..0B....|
iconvの入力にUTF-8を指定するときは、入力データにBOMがついていないことを確認しておくのが良さそうです。
前世や来世というのは、現代の日本人にとってはほとんど縁のない世界です。
が、チベット仏教の僧侶の話を聞いて、なぜそのような概念が有用であり得るかということは理解できた気がしました。
うまれかわりという概念があると、街ですれ違っただけの見知らぬ人でも、前世では自分の親や兄弟であったかもしれない。前世の前世の前世の、ずっと前までさかのぼれば、誰とでも何かしら深い関わりがあるんだよ、ということです。
つまり、誰に対しても分け隔てなく思いやりを持つために、前世やあるいは来世では身近な肉親であったかもしれないという気持ちを持つことが役に立つということです。
うまれかわりを心から信じるかというとなかなかそうはいかないけれども、それが役に立ち得る概念なのだということが分かったのが収穫でした。
以前は確か違ったと思うのですが、goo辞書の英和辞典では、発音記号をUnicodeで表現しています。例えば、「cache」という単語について〔kæʃ〕という発音記号を画像でなしに文字データとして表現しています。
ふーん、そうなんだ。と思って、ではこれはどうだろうかと「acrobat」という単語を引いてみました。すると、第2強勢のある二つ目のaに当たる母音の発音記号「æ̀」(æの上に｀) という字だけは文字データでなく画像で表現しています。
この字はUnicodeに単一の符号位置が用意されておらず、æの後に合成用の｀ (U+0300) を続けることで表さなければなりません。JIS X 0213ならば1-11-36という単一の符号位置が与えられています。
goo辞書の人がどう判断したのかは不明ですが、Unicodeで合成の必要な文字は正しく表示されないかもしれないと考えたのでしょうか。このブログの読者の環境ではどうでしょう。〔ǽkrəbæ̀t〕という発音記号が、アクセント記号を上に乗せた形できちんと表示されているでしょうか。
ちなみに、強勢を表すのに母音の上に「´」や「｀」をつける形は日本の英語教材や英和辞典ではポピュラーですが、英英辞典では音節の前に「 ˈ 」や「 ˌ 」を置くものが多いようです。
」。2004年の作品。評判は知っていて興味を持っていたのですが、何となく先延ばしにしていたものです。