2011年1月アーカイブ

北海道開拓記念館の作品展の情報を記したウェブページに、JIS X 0213にあるアイヌ語表記用の片仮名をうまく記せずに困っている形跡を発見しました。

アイヌ語で「カンナ イカㇻカㇻアㇱ ルウェタパンナ」(また、あたらしいものを作りました)と書かれているのですが、PCで「ㇻ」(JIS面区点番号1-6-90)や「ㇱ」(JIS面区点番号1-6-79) が入力できないと見えて、こうした小書きの字を所謂ハンカクカタカナで記しています。

紙のチラシをスキャンした風な画像の中には、こうした小書きの字がきちんと記されています。

リンク先のウェブページはUTF-8で符号化されています。UTF-8ならこれらの字も符号化できるのですが、入力方法がない、あるいは存在はしていても利用者にとって分からなかった、といったところなのでしょう。

さらに、北海道開拓記念館自体のウェブサイトにもこの作品展のページがあるのですが、ここでも文字コード的な解決策はとられず、HTMLのfontタグでサイズを調整することで対処しています。

やはり、文字入力環境の問題が大きいように思えます。JIS X 0213にちゃんと対応した文字入力ソフトウェアが普及していれば、こういう苦労は今頃なくなっていたのでしょうが...。

なお、Mac OS X では、ことえりにアイヌ語入力方式が実装されているので、アイヌ語のローマ字綴りから片仮名に変換できます。また、SKKのJIS第3・第4水準漢字辞書やそこから派生したAnthy用の辞書を使えば、「ら」や「し」から小書きの片仮名に変換することができます。

この作品展はちょうどいま開催中のようです。興味のある方は足を運んでみてはと思います。

筒井康隆『ダンシング・ヴァニティ』(新潮文庫)にJIS第3水準漢字が使われていることに気付きました。

尾骶骨(びていこつ)」の「骶」(面区点番号1-94-21)です。

やはり文学作品では「尾てい骨」よりも「尾骶骨」とする方がきまってる感じがします。

SKKのJIS第3・第4水準漢字辞書では、もちろん「びていこつ」から変換可能です。

今書店に並んでいる雑誌「自転車人」2011冬号に、「ロンドンが自転車都市に大変身!」と題した6ページの記事が掲載されています。ここ10年くらいでロンドン市内の自転車が飛躍的に増えたという話です。

ヨーロッパの自転車活用先進国、オランダやドイツ、デンマークに比べて、イギリスは元々あまり街中で自転車を見かけなかったそうです。しかし、今はどんどん増えている。

ロンドンが変われた原因のうち日本にないものとして、3つをこの記事では挙げています。①政治と行政が自転車に積極的になったこと、②マスコミが自転車のメリットとあるべき姿を正しく理解し、自転車や徒歩へのモーダルシフトを応援してきたこと、③イギリスでは自転車はどんなにマイナーな存在でも常に「車両」であったこと、です。

①と②からすると、ただ何となく自転車が増えたのではなく、自転車を増やすのが良いことだという明確な意志が存在したことが分かります。

また③は少々説明が必要かもしれません。日本では1970年代に自動車が急増した時期に、応急処置としてそれまで車道を走っていた自転車を歩道にあげるということを行いました。これが日本では今もダラダラと続いているわけですが、イギリスにはそういう歴史がなく、自転車は車道を走る車両であるという認識が、たとえ自転車が少数であるときでも、常になされていたということです。

この記事には写真が多く掲載されています。そこで目につくのは、自転車レーンはもちろんとして、信号待ちのときは自転車が自動車よりも前に出て止まるように線が引かれていることです。こういうのは実際に乗っていれば必要性が分かるものです。自転車に乗らない人が頭だけで考えたものでなく (日本の自転車政策にはそういうのが多いらしく聞きます)、きちんと実用性が考慮されていることが伺えます。

さて、日本の都市はどうするのでしょうね。

著と着

| コメント(0) | トラックバック(0)

「著」と「着」が異体関係にあることは、10年以上前に出た「JIS漢字字典」初版のコラムを読んで知識としては知っていたのですが、新しい本にしか触れていない私は、実際にそのように使われている例を知りませんでした。

が、今現在現役で販売されている本の中にも、そういう例があることに気付きました。

岩波文庫で出ている中村元訳『ブッダのことば』(私の手元にあるのは2009年の第51刷)には、「執著」と書いて「しゆうじやく」とルビの振られている箇所が頻繁にあります。また、「愛著」に「あいじやく」とルビの振られている箇所もあります。

闇雲に「著」ばかりなのではなく、「落ち着く」という言葉の表記には「着」が使われていたりします。執着や愛着という語の表記については割合最近まで「著」が使われることが多かった、ということなのでしょうか。

手持ちの国語辞典を見てみると、大辞林第二版には「執著」の見出しはなく、広辞苑第五版には「しゅうじゃく」の項に「執着・執著」の両方が載っています。広辞苑第五版では「しゅうちゃく【執着】」は「しゅうじゃく」を参照するようになっています (大辞林・広辞苑とも最新版でないことをご了承下さい)。

大熊肇『文字の骨組み』ではこの字について、もと同じ字であったことが説明されています。遅くとも江戸時代には「著・着」の意味的な使い分けがあったとのことです。

三脚の効用

| コメント(0) | トラックバック(0)

Night view of Yokohama / 横浜の夜景

日の短いこの時期。すぐ日が沈んでしまうと気が滅入りがちでもありますが、せめて前向きにとらえようと、早い日暮れを利用して夜景を撮影することを思い立ちました。

写真雑誌などを見てみると、夜景撮影には三脚が必須なんていうことが書いてあります。実際のところは手持ちでも撮れないことはないのですが、ISO感度が3200とか高感度になってしまいます。すると、機種にもよるのでしょうが、ザラザラした感じになりやすいでしょう。ISO100とかの低感度にしてシャッター速度を遅くした方が綺麗になるのは道理です。シャッター速度を遅くすると手持ちではブレるので、三脚が必要になります。

自分がそれをどれくらい活用するかについてやや疑念があったものの、思い切って三脚を買ってみました。三脚使用の初陣として、横浜みなとみらい地区を撮影してみたのが、上の写真です。

この写真の露出時間は5秒です。ISO感度を低くできるだけでなく、海面に写った光がとけるような感じになるのも、露出時間が長ければこそです。若干画面が傾いている気がするのは気にしない(!)。

この前函館に行ったとき、実に美味しいホッケをいただきました。

根ボッケという種類のものだそうです。なんでも、ホッケには縞ホッケと真ホッケとがあり、真ホッケの中でも海の底の方にいるのを根ボッケというのだそうです。

これは東京あたりの定食屋などで食べるものとはもちろん、札幌で普通に食べられるものと比べてもずっと美味しいように感じました。私のごく主観的な印象ですが、別次元のうまさです。

ウェブを検索したところ、函館ではこの魚の名前を店名にしてしまった居酒屋まであるようです。それほど美味しいということなのでしょう。

北海道、特に函館でホッケを食べるときは、種類に注意してみるといいと思います。「根ボッケ」だったらたぶん当たりです。

ちなみにホッケは漢字では魚へんに花、「𩸽」と書きます。もともとJIS X 0208やUnicodeにはなく、JIS X 0213で第4水準漢字、面区点位置2-93-44に追加されました。Unicodeにはのちに面02に追加され、U+29E3Dという符号位置にあります。

Java 6が対応しているUnicodeのバージョンは4.1だそうです 【追記: 後で確かめたら4.0だそうです。私の思い違いでした _o_】。IVSに使われる面0Eのvariation selector (異体字セレクタ)はこのバージョンには既に入っています。なので、最新IVDの知識は期待できないとしても、variation selectorを無視するくらいの処理はひょっとしたら入っていてくれないかな、と思ってちょっと試してみました。

まず、Stringクラスの挙動から。まあ、何が起こるかは大体想像できるのですが、一応確認しておきましょう。

こんな風な文字列があるとします。

    String nonIvs = "与太郎";
    String ivs1 = "与\uDB40\uDD00太郎";
    String ivs2 = "与\uDB40\uDD02太郎";

ここで、\uDB40\uDD00というのはU+E0100の、\uDB40\uDD02というのはU+E0102のエスケープ表現です。つまり、この3つの文字列はいずれも「与太郎」という文字列を表しています。ivs1とivs2の「与」にはそれぞれU+E0100とU+E0102という異体字セレクタがついていますが、現在のIVDによるとこれはいずれも常用漢字体の (つまり、普通の)「与」の形であり、見た目に区別がつきません。つまり、この三つの文字列はIVS対応の環境で表示するといずれも「与太郎」と見えます。

この文字列をまずはString#equals()で比較してみましょう。

    System.out.println("\"" + nonIvs + "\".equals(\"" + ivs1 + "\") = "
        + nonIvs.equals(ivs1));
    System.out.println("\"" + ivs1 + "\".equals(\"" + ivs2 + "\") = " +
        ivs1.equals(ivs2));

結果はこうなります。

    "与太郎".equals("与[0E0100]太郎") = false
    "与[0E0100]太郎".equals("与[0E0102]太郎") = false

ただし、[0E0100] は、U+E0100のバイト列を表します。私の実験環境では四角の中に 0E0100 という文字が入った格好で表示されています。

これは想像通りですね。単にcharの列を比較しただけの結果になっています。つまり、見た目の区別がつかなくても容赦なく別々の文字列として扱っています。これが何をもたらすかというと、Stringクラスで比較しているプログラムに対しては、"与" と "与[0E0100]" と "与[0E0102]" を、見た目の区別がないにもかかわらず、人が入力し分けてやらないと困ることになるということです。

String#compareTo() も試しておきましょう。比較のためにもう一つ文字列を定義しておきます。

    String nonIvsNext = "与那国";

「那」はUnicode順でもJISコード順でも「太」より後になります。つまり、「与太郎」と「与那国」を比較すると「与那国」の方が後にくることが期待されます。実際、IVSを含まない文字列同士での比較、

    System.out.println("\"" + nonIvs + "\".compareTo(\"" + nonIvsNext + "\") = " +
        nonIvs.compareTo(nonIvsNext));

を実行すると、負の値が出力されます。これは期待通りです。

IVSが絡むとどうなるか。

    System.out.println("\"" + nonIvsNext + "\".compareTo(\"" + ivs1 + "\") = " +
        nonIvsNext.compareTo(ivs1));

を実行すると、

    "与那国".compareTo("与[0E0100]太郎") = -1910

と、負の値になります。「与那国」の方が「与[0E0100]太郎」より先だといっているのです。これは、見た目の期待に反します。残念。(まあ、Stringクラスにそこまで期待しない方がいいのですが)

気をとりなおして、Collatorでうまいこと処理してくれないものか、実験してみます。

JavaにはCollatorというものがあります。存在理由や効果などは『プログラマのための文字コード技術入門』の第7章を参照してほしいのですが、これを使うと文字コード順でなく言語に応じた適切な照合(collation)を実現できます。

準備として、デフォルトロケール (この場合は日本語環境) のCollatorオブジェクトを取得しておきます。

    Collator c = Collator.getInstance();

このCollatorで比較するとどうなるか。人が同じと認識する文字列は同じだという結果を返してほしいわけです。

    System.out.println("Compare " + ivs1 + " with " + nonIvs + ": " +
        c.compare(ivs1, nonIvs));

を実行すると、

    Compare 与[0E0100]太郎 with 与太郎: 1

となります。等しい文字列のときには0という値が返却されるのですが、ここで1と出ているのは、「与[0E0100]太郎」の方が大きい文字列だといっているわけです。念を押すようですが、見た目の区別はつきません。

IVS同士だとどうか。

    System.out.println("Compare " + ivs1 + " with " + ivs2 + ": " +
        c.compare(ivs1, ivs2));

この結果はこうです。

    Compare 与[0E0100]太郎 with 与[0E0102]太郎: -1

「与[0E0100]太郎」の方が小さいといっています。同じとはみなしてくれません。この二つは、見た目の区別のつかないIVS同士です。

どうも、Collatorを使っても、異体字セレクタを無視して比較するような賢いことはしてくれず、単に漢字の後ろに面0Eの文字があるような処理がされています。

だめおしにもうひとつ。

    System.out.println("Compare " + nonIvs + " with " + nonIvsNext + ": " +
        c.compare(nonIvs, nonIvsNext));
    System.out.println("Compare " + nonIvsNext + " with " + ivs1 + ": " +
        c.compare(nonIvsNext, ivs1));

この2行の実行結果は下のとおり。

    Compare 与太郎 with 与那国: -1
    Compare 与那国 with 与[0E0100]太郎: -1

IVSなしの「与太郎」と「与那国」では常識的に負の値が返却されています。一方、「与那国」と「与[0E0100]太郎」とでは、前者の方が小さいといっています。見た目の文字列としては「与那国」と「与太郎」の比較なので正の値がかえってほしいところですが、そうはなってくれません。もし「与太郎」(IVSなし)「与那国」「与[0E0100]太郎」の三つの文字列をソートすると、Collatorを使ったとしても、異体字セレクタの入るものが一番後にくるという格好悪い結果になってしまいます。見た目のソート結果としては「与太郎」「与那国」「与太郎」という風になり、なぜ「与那国」の後に「与太郎」がひとつだけ来ているのか、人が見てもさっぱり分からないという状況になります。

結論としては、予想されたことではありますが、Java 6はIVSについて特別なことは何もしてくれません。なので、IVSを含むデータを考えなしに垂れ流すと、いろいろ困ったことになるでしょう。UTS #37のIVDの仕様には「variation selectors are default ignorable」と書いてありますが、Javaはignoreしてくれないようです。

文字列がIVSを含む場合の照合(collation)についてUnicodeの人が何も考えていないとは思えないのですが、UTS #10 「Unicode Collation Algorithm」には異体字セレクタへの言及が何もありません。このあたりがどうなっているのか、もしご存じの方がいたら教えていただけるとうれしいです。(まあ、variation selectorは単に無視せよということなのかもしれませんが、どこかでそう明言されていないと実装者は何も考えなさそうな気がするので)

年末年始に函館と札幌に行ってきました。西日本では雪が多く降っていましたが、函館や札幌は雪も降らず気温もあまり下がらず、穏やかな年越しとなりました。

箱館奉行所

函館・五稜郭の中に、箱館奉行所の建物が復元されました。これは幕末に建てられたものですが、明治維新のためにわずか7年後に解体されたというもの。内部を見学すると、可能な限り忠実に復元するよう努力されたことがわかります。

Russian Orthodox Church in Hakodate / ハリストス正教会

定番の観光地、異国情緒の代表格、函館ハリストス正教会。地元ではその鐘の音からガンガン寺という愛称で呼ばれているそうです。この教会はギリシャ正教ですが、すぐ隣にはプロテスタントの聖ヨハネ教会があるかと思えば向かいにはカトリックの教会があり、至近距離にはさらに仏教の寺があってと、いろんな宗教・宗派が仲良く混在しているエリアです。

Old Public Hall of Hakodate Ward / 旧函館区公会堂

これも定番、旧函館区公会堂。ハリストス教会からも近くです。この付近一帯は見所の宝庫です。

Sapporo White Illumination / ホワイトイルミネーション

札幌ホワイトイルミネーション。大通公園で1981年から行われており、もう30年にもなります。なんとなく西2丁目・3丁目でやってるイメージが強かったのですが、今年は4丁目に新しいのがお目見えしたそうだし、実は1丁目から8丁目まであるそうです。その辺の事情をよく知らないで行ったので、ちょっと見落しが多かったように思います。次回はWebサイトで下調べしてから行こう。

Sapporo TV Tower in winter / 冬の札幌テレビ塔

大通公園の東端、札幌テレビ塔。

Ōdōri park in winter / 冬の大通公園

冬の大通公園はこんな感じ。

Funky snowman / しゃくれ雪だるま

街行く人が作っていったのだろう、こんな雪だるまも見かけました。

Tongue / ペロッ

札幌・円山公園にある円山動物園は、年末の休みのあと、元日から開園しています。雪の中のホッキョクグマを見られないかと期待していたのですが、なんと出産のためお休み中とのこと。かわりといってはなんですが、オオカミなどを見てきました。オオカミは雪の上で元気でした。

オオカミのじゃれあい

じゃれあうオオカミ。痛くないのかな...。

Eating / まるのみ

アザラシの餌やりタイムに出食わしました。見物客のいるすぐそば、雪の上で餌やりしていました。子供にも餌やり体験をさせていました。

カーリング

アザラシが雪の上をぽよんぽよん歩くところを間近に見られました。こうして見るとカーリングの石のようです。

Raccoon dog / エゾタヌキ

エゾタヌキ。毛皮のせいか、貫禄があるように見えます。

まだらのウサギ

干支企画ということで、ウサギをとりあげていました。この企画、来年はやるのかな...。

雪の動物園といえば、旭山動物園のペンギンの散歩などが有名ですが、ここ円山動物園もなかなかいいと思いました。

今後は、ホッキョクグマの子供が無事に育って、デビューしてくれるといいと思います。

4位!

| コメント(0) | トラックバック(0)

昨年2010年の、ジュンク堂書店池袋本店のコンピュータ書売上冊数ランキングの第4位に、見事、『プログラマのための文字コード技術入門』が入りました!

「2位じゃだめなんですか」という迷言にすら及ばない4位ではありますが、去年1年間にあれだけたくさん出たコンピュータ書の中で多い方から4位というのは、望んでも得られないような大変嬉しい結果だというのが、偽らざる感想です。

書店の皆さま、技術評論社の皆さま、そしてもちろん本書をお読みいただいた皆さま、本当にありがとうございます。

なお、上記リンクのページは、私の大学時代の先輩である高橋征義さんが今度の土曜日に行うトークイベント『このコンピュータ書がすごい! 2011年版』に関係したものです。どうも満員となったようですが、ぜひ注目してみてください。

疋田智さんのメルマガで紹介されていた毎日新聞の記事がこれ。

出だしはこうです。

自転車事故の7割は交差点で発生し、その主要因は自転車の歩道走行とみられることが、元建設官僚で住信基礎研究所の古倉宗治研究理事の分析で分かった。

そしてこう続きます。

自転車を除く交差点での事故率は全体の4割強にとどまり、自転車の事故率は突出。大半は車との事故で、歩道を走る自転車が交差点に進入した際、車道走行時よりも車の死角に入りやすいためだという。自転車の車道走行は危険視されがちだが、むしろ歩道走行の方が危険性が高い実態が浮かんだ。

直感的には、自転車が車道を走っていると危険だと思うかもしれません。しかし、実際には歩道走行の方が危険だというのです。

これにはきちんと理由があります。詳しくは記事を見てほしいのですが(わかりやすい図入りです)、自転車が歩道を走っていると自動車から見落しやすく、それが交差点での事故につながるのです。

理屈としては納得できます。しかし、実際のところこれを人に説明するのはある点で難しい。

なぜかというと、車道の方が安全だと人に説明して、その相手の人が実際に車道を走って事故にあったら、あわせる顔がないからです。だから、自分では車道を走っても、他人に対して車道を走れとはなかなかいいづらい。

この毎日の記事は、そういう感情を克服して、あくまで論理に徹して「歩道の方が危険だ」と述べているところが画期的だと思います。

ここで説明されている歩道走行の危険性は、京都や東京の一部で見られる、歩道上に設置される自転車レーンに対しての警告ともなるといえるでしょう。なぜなら、歩道上のレーンを自転車が走っていると、交差点を渡る際には、単に歩道を走っているのと何ら変わりなくなるからです。歩道上のレーンは自転車の事故を減らすという意味では疑問符がつくことになります。

なお、自転車の歩道走行が危険の種だということは、疋田智『自転車の安全鉄則』でも述べられています。自転車交通の安全について興味があるならこの本は必須といえるでしょう。

IVSを使うと、常用漢字体の「与」は以下の異なる符号化表現で表し得ます。

  • U+4E0E U+E0100
  • U+4E0E U+E0102
  • U+4E0E (※通常の日本語環境では上2つと同じように見える筈。中国語環境などでは異なる)

これが何を意味するかというと、画面上で同じ「与」という漢字が見えていても、その背後にある符号化表現は上の3つのいずれでもあり得るわけです。これがどのような不都合をもたらすかはいうまでもないでしょう。

文字コードというものは、文字を一意に符号化するものです。しかしIVSでは一意に符号化することは最初から考えられていないようです。つまり、IVSは文字コードではありません。

文字コードでないものをUnicodeのレベルで扱うのが適切なのか、再考を要するかもしれません。たとえばルビタグや言語タグのような文字コードでないものがUnicodeにはあって、こういうのはXMLなどで実現すべきだと主張する人たちがいます。IVSもそれと同じようなことになる可能性も考えられます。

広告