2013年6月アーカイブ

先日テレビをなんとなく見ていたら、エンディングのスタッフロールに「𡈽野」という名字が見えて俄然注意を引かれました。

「𡈽」は「土」の異体字で、JIS第3水準漢字、面区点1-15-34にあります。UnicodeではBMPになく、面02、U+2123Dなので、UTF-16ではサロゲート・ペアが必要です。

異体字なので読みや意味は「土」と同じです。読みや意味が同じだったら区別する必要はないだろうという気もしますが、それはまた別の話。テレビでは読みが書いていなかったので推測するしかないのですが、ヒジノかハジノ、あるいはツチノと読むのでしょうか。

そんなことをTwitterでつぶやいたのですが、事件はそのあと起こりました。事件というほど大げさなことでもありませんが。

Twitterには自分の投稿に対するアクションがあるとメールで通知する機能があります。オフにしておこうと思いつつそのままになっていたので、上記「𡈽野」という文字を含んだツイートに対するアクションの通知メールがとんできました。

ところがそのメールには「𡈽野」の「𡈽」がきちんと表示されていませんでした。メーラにもよるのでしょうが、私の環境では問題の文字の代わりに「~」が2個並んで「~~野」となっていました。

はて、どうなっているのか。

このHTMLメールのソースを見ると、疑問はすぐに氷解しました。

「𡈽」にあたる部分が、HTMLの数値文字参照で「��」となっていたのです。10進数で書かれてもよく分かりませんが、2個並んでいることから何が起こっているのか想像はつきます。それぞれの数を16進にしてみると、55364はD844、56893はDE3D。これはUTF-16のサロゲート・ペアの値です。

つまり、上位・下位それぞれのサロゲートの値をHTMLの文字参照にされてしまっていたわけです。どういうロジックを経てそうなってしまったのかは分かりませんが。

テキストエディタやウェブブラウザなどで、UTF-16のサロゲートを表示できたとしても、テキストデータを処理するプログラムがきちんとサロゲートに対応しているかはまた別の話です。私の見るところでは、まだまだこうした、サロゲートがあるとおかしくなることは見かけるように思います。

こういうのは個々のプログラマがちゃんと処理せよというのはなかなか難しい話で、標準的に用意されているライブラリが、普通に使えばサロゲートがきても問題の起こらないような仕組みになっていることが必要でないかと思います。

普通のプログラマにとってサロゲートの必要な場面というのは想像しづらいかもしれないし、また想像できたとしてもそれがあまり頻繁に起こらないことであれば、必要になるまで後回しでいいやと思うのはいかにもありそうなことです。私だって、使い捨てのプログラムなら「あーこれはサロゲートがきたら駄目だねー」と思いながらそのままにすることがあります。それが使い捨てで済まずに生き延びたりすると地雷になるのですが。

悲観的な見方をすれば、UTF-16が使われている限りはこうしたトラブルはなくならないのかもしれません。

アップルのバックアップ装置兼無線LANルータのTime CapsuleをNTT東日本のフレッツ光とともに使う設定をしたので、後日のための備忘もかねて注意点を記しておきます。(なお、Time Capsuleはつい最近発表された802.11ac対応のやつではなく、そのひとつ前のモデルです)

試した構成はこうなっています: フレッツ光の終端装置PR-400NEからLANケーブルでTime Capsuleにつないで、そこからMacとLinux PCそれぞれにLANケーブルでつないでいます。無線LANはTime Capsuleの機能を利用して、スマートフォンやタブレットから利用するようになっています。

設定はAir Macユーティリティで行いました。フレッツ光の終端装置についてくるCD-ROMにはMac用の設定ソフトも入っていますが、Time Capsuleと一緒に使うような設定が可能かどうかは知りません。あらかじめWindows PCと終端装置を直接接続して、付属のCD-ROMからインターネットが使える設定は済んでいます。

Air Macユーティリティの設定でポイントと思われたのは下記の2点です。ここが最初よくわからなくて手間取りました。

  • 「インターネット」の設定で接続方法を「DHCP」に設定。(PPPoEじゃない)
  • 「ネットワーク」の設定でルーターモードを「切 (ブリッジモード)」に設定。(DHCPじゃない)

(私はネットワークの設定もTime Capsuleもフレッツ光のことも詳しく知らないので、なぜそうなのかと聞かれても答えられません。あしからず)

無線LANの設定は、「ワイヤレス」の項目から普通に(?)やればたぶん困ることはないと思います。

Evernoteはあまりヘビーに使いこなしているわけではないのですが、この前リマインダー機能がついたというニュースには興味を引かれました。

ただリマインダー機能が想定している使い方と自分の使い方とは少し違うなという感じがしました。以下、もしかしたら勘違いを含んでいるかもしれませんが、あまりヘビーユーザーでない利用者が感じたことという意味でお読みいただければと思います。

Evernoteのリマインダーは、ノートをリマインドするという使い方になっています。ある日が来たらあるノートについて通知する、ということです。

ここには、ノートひとつがタスクひとつという考え方があるように考えられます。

それがEvernoteの想定なのかもしれませんが、私の使い方では、ひとつのノートの中に小さなタスクのリストが並んでいて、それを処理していくことでひとつのまとまった意味のある仕事を完了するという方がしっくりきます。したがって、リマインドされるべきはノート全体じゃなくて、ノートの中の箇条書きひとつといった粒度です。

例えば、旅行の予定を立てるとしたら、旅行ひとつがひとつのノートになって、その中に箇条書きで宿の予約や航空券の購入や新幹線の予約などが並ぶ。それを順次実施して、終わったら印を付けて適宜結果を記していく、というわけです。

まあこれは、私の使い方がもしかすると特殊なのかもしれません。もしかするとノートブックがひとつのプロジェクト(上の例では旅行)に、ノートがひとつの実施項目に相当することが想定されているのかもしれません。

ただ、ノートの編集画面ではToDoリスト用のチェックボックスがわざわざ用意されているくらいですから、私の使い方が間違っているというようなことではないんじゃないかと思います。

むしろ、その用意されているToDoリスト用チェックボックスにリマインダー(というかアラーム)を設定できればいいのではないか。チェックボックスの属性として、項目の開始日と締め切り日を設定できるようにしておく。あと、関連情報(URLや他のノート)や成果物(URLや他のノート)へのリンクなども属性として設定できるといいかもしれない。

それで、自分のホームページ(のような画面)では、全ノートを通じた「直近のタスク一覧」が見られれば良い。近々開始するべき項目や、締切の近い項目が一目で分かればいいわけです。(これは実は、Emacs上のhowmというツールでは実現されています。私の頭にあるのは「オンライン版howm」だといえば分かる人には分かるかもしれません。「howmは『Wikiもどき』なんだから、それって要するにWikiなのでは?」というツッコミがくるかもしれませんが)

こういう仕方で設定できた方が見通しが良くて使いやすいんじゃないかなあ...と思いますが、はてさて。もうしばらく試行錯誤してみましょうか。

北海道大学総合博物館のイベント案内に、JIS第3水準漢字が使われているのを見つけました。

この題に使われている「鮞」という字がJIS第3水準漢字です。面区点番号1-94-40にあります。

字だけ見えても意味が分からなければ仕方ありません。「はららご」とは、辞書によれば、「魚類の産卵前の卵塊」(大辞林)だそうです。要するに筋子のようなものだそうです。秋の季語である由。

広辞苑も大辞林も、この言葉の見出しに、漢字表記として上記の第3水準漢字「鮞」を掲げています。

上記リンク先のページ、多分UTF-8なんだろう...と思いつつソースを見たら、EUC-JPとなっていました。JIS X 0212補助漢字に「鮞」があるのでEUC-JPでも表現できるわけです。記事の執筆はUnicodeベースの編集環境なのでしょうが、ウェブサイトのCMSか何かの設定のためにEUC-JPで保存したらそのまま保存できてしまった(まあ、保存できて間違いではないのですが)というのが実際のところではないかと想像します。

入力環境でどのように「鮞」を入力したのかが少々気になります。JIS第3第4水準に対応した環境でも、こうした語彙が仮名漢字変換辞書に整備されているとは限らないからです。例えばMacのデフォルトの環境では「はららご」という読みから変換することはできませんでした。

SKKの第3第4水準辞書SKK-JISYO.JIS3_4や、それを元に作成したATOKやAnthy用の第3第4水準辞書では、「はららご」から「鮞」に変換できます。

JIS X 0213を使いこなすには、単に漢字のフォントが揃っているだけでなく、こうした言葉を簡単に入力できる変換辞書を用いる必要があります。

Ruby 2.0では、対応する文字コードにEUC-JIS-2004が追加されています。"EUC-JP-2004" という名前で入っています (真ん中が "-JP-" になっているので注意)。

これは大変良いことです。Ruby 1.9では文字コードの扱いが大きく変わって興味深かったのですが、肝心のJIS X 0213の符号化方式に対応していないので私の役には立ちませんでした。

Ruby 1.9以降では、Javaなど他の言語でよくある内部コードとしてUnicodeを使う方法でなく、文字列に符号化方式の情報をつけて直接に元のコードの文字列を処理できる方法がとられています。

この方式はJIS X 0213を使う上でこそメリットがあります。サロゲートや結合文字や互換漢字といったUnicodeの面倒な部分を無視することができるからです。(細かいことをいう人のための注釈: 厳密にはJIS X 0213にも結合文字がありますが、日本語のためにJIS X 0213を使っていて必要になることはまずないでしょう)

Ruby 2.0でEUC-JIS-2004が実装されたのは大変意義深いことで、ぜひ試してみたいと思います。EUCが使えるということは、JIS X 0213で定義されているコード(ビット組合せ)が直に操作対象となるということですから、Unicodeに変換した上で処理するのと違って、まさにJIS X 0213の世界そのものということになります。

Unicodeとの変換も実装されているので、iconvのような他のライブラリを使わずに(というか使えなくなった) 必要に応じてUTF-8などと変換ができます。

他の言語と比較するとこんな感じになります。

EUC-JIS-2004Shift_JIS-2004
Ruby 2.0×
Java 7×
Python

ちなみにRuby 1.8でもEUC-JIS-2004のテキストデータをEUC-JPと同じように処理できたのですが、このときはStringクラスが文字単位でなくバイト単位で処理するようになっていました(EUCに限らず、Ruby 1.8までの多バイトコードの扱い全般の特徴)。2.0ではきちんと文字単位になります。

広告