2011年5月アーカイブ

Anthy用JIS第3・第4水準漢字変換辞書を更新して第0.3版としました。

今回の主な変更点は、大文字のアルファベットから、対応する小文字のダイアクリティカルマーク付きの文字を変換できるようにしたことです。

例えば、大文字の O から小文字の ō に変換できたり、大文字の E から小文字の é に変換できたりということです。

これで何が嬉しいかというと、アルファベットを打鍵したときの挙動を思い浮かべると分かると思います。例えば、辞書上で仮に e から é に変換できるように定義されていたとします。このとき、é を入力するつもりで E のキーを押すと、平仮名の「え」になってしまいます (ローマ字入力の場合)。これでは目的の文字が入力できません。しかし、シフトキーを押して、つまり大文字の E ならば平仮名にならずにアルファベットのままでいてくれます。大文字からならば、アルファベットから変換できるというわけです。(なお、私はもっぱら月配列で入力しているのでローマ字入力のときの動作にちょっと自信がないのですが、多分あっていると思います)

本辞書のオリジナルはSKKの辞書ですが、SKKの入力は独特で、アルファベッ トからの変換はそれ用のモードから行うので、上記の問題はありません。e や o といった小文字のアルファベットから変換できるのです。今まではそれを前提とした辞書をそのままAnthyに流用していましたが、Anthyで使うにはそれでは具合が悪く、小文字の変換候補が全然使えないことになってしまいます。そこで、Anthy用として大文字から変換できるようにしたわけです。

これで、Anthyでも、「Ōdōri」のような日本語ローマ字や「Café」のような外国語も入力できるようになりました。そのほか、AE から æ が入力できたりとかいろいろ入っているので、興味のある方は辞書を覗いてみてください。UTF-8のクリアテキストなので適当なエディタで読めます。

Linux等でAnthyをご利用の方は、お試しいただけると嬉しいです。

先週、札幌に行って、北大などを散歩してきました。

その折、北大の総合博物館も見学してきました。入るのは初めてです。

北大総合博物館

この中に、文字の観点から面白い展示がありました。

3階の化石の骨格の展示の説明文が、だいぶ前の時期 (戦前?) に手書きされたものらしく、字体が今日普通の印刷物に見られるものとは結構違いがあったのです。

例えば、「今回」という言葉の「今」や「回」が、楷書に見られる形だったりしました。「今」は屋根の下が片仮名のテの形、「回」は中の口がはしごの形のもの (はしご回?) になっていました。

また、「骨」という字の中のカギが、今日の字体では右側につくのが、逆の左側につく格好になっていました。中国の簡体字と同じ形です。かつてUnicodeのCJK漢字統合が問題になった頃、「中国の『骨』」というような言い方がよくされていましたが、日本でも見られる形だったのですね。このことは小池和夫『異体字の世界』にも書かれています。

形が少々違っても、意味や読みや用法は今日の印刷字形の文字と違いのない、同じ文字であることは言うまでもありません。

さらに、かぎ括弧 「」 の向きが、普通は左上と右下にカギが来る格好をするものが、この展示では、左下と右上の位置に配置されていました。かつてはこういう書き方もしたのでしょうか。私はかぎ括弧については詳しくないのでどういう事情なのか分かりません。

さてこの文がいつ書かれたかですが、確かデスモスティルスの展示だったと思うので、すると展示説明のウェブページによれば1933年の発見だというので、それからそう遠くない時期に書かれたものだろうと推察します。

写真を撮ってくればよかったのでしょうが、妙に遠慮して撮らずにきてしまいました。気になる方は北大まで見に行ってみてください。

ふと思い立って、このブログにFacebookの「いいね!」ボタンを付けてみることにしました。

参考にしてのは「Movable Type に「いいね!」ボタンを設置する」という記事です。ここに書いてあることをほぼそのままやってみました。

多分うまくいっているのではないかと思います。とりあえずこの記事でテストしてみよう。

いいねと言ってもらえるような記事を書いているかという根本的な疑問もないではないが、それはそれ。

ツイートボタンと横に並べたいのだけど、思ったような格好にならない...。後日再挑戦しようか。

Firefoxでルビ

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

以前から、Firefoxでルビを表示させるのに、XHTML Ruby Supportというアドオンを使っていました。Firefoxはそのままではルビに対応していないのです。

ただ、アドオンの問題も分かっていました。このアドオンでは、ルビを振られる文字列がCJK統合漢字拡張Bから始まっていると、その漢字が化けてしまうのです。例えば「𣖔木作(ほうのきざく)」という具合にルビを振ると、先頭の「𣖔」が正しく表示されないということです。

この問題は開発者に報告した方がいいなあと思いつつ、なんとなく有耶無耶にしてしまっていました。BMP外の文字を含むときはルビタグを使うのを避けるという変な習慣もついてしまいました。

そうこうするうち、Firefox 4が出ましたが、このアドオンは新しいFirefoxのバージョンに対応していません。その一方で、HTML Rubyというルビのための新しいアドオンが出ています。

HTML Rubyを試してみると、上述の問題はありません。FirefoxとHTML Rubyでこのページをご覧の方は、上記のルビ付き文字列がきちんと表示されているはずです。

今後、FirefoxについてはHTML Rubyを使って下さい、ということにして、「𣖔木作」みたいなのもルビタグでルビを振ってしまっていいかな、と思い始めています。

なお、アドオンの機能については、ごく単純なルビについてしか試していません。複雑なルビは私は使わないと思うためです。あしからず。

ふと思い立って、このブログにTwitterのTweetボタンを付けてみることにしました。

参考にしたのは「Movable TypeにTweetボタンを設置する」という記事です。ここに書いてあることをそのままやってみました。

多分うまくいっているのではないかと思います。とりあえずこの記事でテストしてみよう。

ツイートされるような記事を書いているかという根本的な疑問もないではないが、それはそれ。

アウトドア系の雑誌などを発行している出版社に、(えい)出版社という会社があります。

この「枻」という字はJIS第3水準漢字なのですが (面区点番号1-85-56)、いまだに、いつでもどこでも使えるようにはなっていません。2000年の時点でベンダが覚悟を決めてJIS X 0213対応を進めていれば今ごろは第3水準も平気で使えるようになっていたのでしょうが、残念ながら現実にはそうなっていません(「文字コードの失われた10年」)。枻出版社のウェブサイトでは自社のことを「エイ出版社」のように片仮名で記載しています。(ちなみに枻出版社のウェブページはUTF-8で符号化されています)

漢和辞典によると、この字には船をこぐ「かい」の意味があるそうです。ベンダが第3・第4水準を冷遇する中でもこの字を社名に使い続けるのには、こめられた深い意味でもあるかもしれません。

ISO/IEC 10646:2011

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

ISOの一部の国際標準が無料でダウンロードできるサイト Publicly Available Standards から、ISO/IEC 10646:2011がダウンロードできるようになっています。

これはUnicodeの方でいうとバージョン6.0に対応します。ただし、インドの新しい通貨記号 U+20B9 INDIAN RUPEE SIGN の有無だけが異なるようです(Unicode 6.0には入っている)。

UnicodeコンソーシアムのサイトにあるUnicodeの文書によると、10646のこの新しい版においてUCS-4はUTF-32と同じになり、UCS-2はobsoleteなのだそうです。

2つ前の記事を読んで、文字の符号化と復号への関心のあり方がどう違うのか、疑問に思った方もあるかもしれません。プログラミング系の人から見れば、文字にフォーカスしているという点ではあまり変わりないように見えるだろうからです。しかしここには結構大きな違いがある。

文字の符号化というのは、具体的な字形の違いにかかわらず、「同じ文字」と認定することが必要になります。物事を符号で表すというのは大体そういうことです。例えば、天気を符号で表すとき、個別具体的な空の様子というのは日々刻々異なるものですが、雲量が2以上8以下だったら一律に「晴れ」という符号で表す、といった風に、一種の捨象が行われるわけです。文字を符号化するときも、少しの形の違いは捨象して、同じ文字と認められるものに同一の符号を振ります。

一方、文字を出力する方に興味が向いている人というのは、どんな形に字形を出力するかを気にするものです。このときは、線の向きがどうとか線が突き出ているとかいないとか、そういう細かな違いを制御したくなります。これは文字の符号化というよりも、出力字形の制御というべき関心です。

別の言い方をすれば、符号化というのは抽象化の方を向いており、復号は具体化の方を向いている、ということができるでしょう。

文字の抽象化よりも具体化に興味がある人というのは、文字コードというよりもフォントの方に関心があるといった方が適切であることが多いように思います。

先週のことですが、横浜美術館で開催中の「生誕120年記念 長谷川潔展」を見に行ってきました。大変素晴らしい作品が展示されています。

長谷川潔は横浜生まれの銅版画家で、フランスで活動し、かの地で亡くなりました。メゾチント(マニエール・ノワール)という古い技法を再興したことで知られています。

私がこの芸術家を知ったきっかけは、実は、少し前に放送されていたテレビ東京の「なんでも鑑定団」でした。そこに出ていた「依頼品」が、長谷川潔の晩年の代表作のひとつ、「草花とアカリョム」だったのです。テレビを通して作品を見た瞬間、ぐっとひきつけられるものがありました。

それでウェブで検索してみたところ、今ちょうど横浜美術館で展覧会をやっているので、見てきたわけです。

緻密に構成されたマニエール・ノワールの黒の世界は大変素敵でした。それとともに、若い頃はいろいろな技法をやっていたのだなということも分かりました。最終的にひとつのものに落ち着くとしても、いろいろやってみるのは良いことなのかもしれません。

帰り際、お楽しみミュージアムショップで作品の絵葉書やクリアファイルや栞を何点も購入してきました。本も買いました。とにかく気に入ったのです。

6月までやっているので、もしかしたらもう1回くらい見に行くかもしれません。

「なんでも鑑定団」では、依頼人は若い頃にこの作品を何気なく買ったということです。鑑定結果は依頼人の自己評価よりもずっと高い値がついていました。何気なく、そしておそらくは当時大したことのない額で買った作品がこんな素晴らしいものだとは、羨しいことです。

ひとくちに文字コードといっても、ときとして、人によってとらえ方が大きく異なることに戸惑うことがあります。例えば、興味の向かう先が、活字や印刷といった方向である人と、プログラミングである人とは、同じ文字コードといっても想起されるイメージや前提条件などに大きな隔たりがあるのではないかと思えます。

以前、このことを「文字コードに対する3つのスタンス」として考察したことがあるのですが、その後あらためて考えたところ、この3つのスタンスは、文字の符号化・処理・復号という3つのフェーズに対応するように思われました。

下図のようなイメージです。

文字コードに対する3つの見方

文字コードによって計算機上で文字を処理する場合、こうした、符号化・処理・復号というフェーズを経ることになります。このうちどこに重きを置くかによって、同じ文字コードでも見え方が違ってくるのだと思います。

注意したいのは、どれかひとつのスタンスに偏ると全体が見えなくなるおそれがあるということです。プログラミング大好きでコード変換プログラムをいくらたくさん書いたところで、それだけで文字の符号化を理解したことにはなりません。それは符号化された結果のバイト値の操作にすぎないからです(上図の「処理」)。また、印刷や活字に関する仕事をしているからといって文字コードを理解しているとは、やはり限りません。そういう人が関心を持つのは往々にしてバイト値からフォントによって字形を出力するところだけだったりします(上図の「復号」)。フォントの問題を文字コードの問題と混同することはよくある誤りです。

いくらプログラミングに詳しくなってもそれは全体の3分の1にすぎず、またいくら印刷字形に詳しくなってもやはり3分の1にすぎません。

興味深いことに、最初のフェーズである「符号化」に関心を持つ人はあまり多くないように私には見受けられます。このカテゴリに入るのは、青空文庫がやっているような文献の符号化や、文献情報のデータベース化を行う人、文字入力に深い注意を払う人などです。このフェーズは文字コードにとって最も根源的だといえるでしょう。符号化しないことにはその先を論じても意味がないからです。

大事なことは、上図の3つのフェーズにバランスよく目配りし、ひとりよがりにならないことだと思います。

私はメーラにMewを使っているのですが、これを使うといろいろ発見があります。

この前は、日本語のメールで、ISO-2022-JPをQuoted-Printableしたものに出食わしました。なぜそんなことが分かるかというと、Mewのメール一覧の表示エリアで、日本語がデコードされていなかったので気付いたのです。

7ビットのコードで特別な符号化を施す必要のないISO-2022-JPをQuoted-Printableにするのは、無駄なことです。なぜこんなことになったのでしょう。

UTF-8をQuoted-Printableにしたものを見ることもあります。Twitterから送られてくるメールはこれだと思います。日本語のメールならbase64の方が効率的なのですが、Q-Pにするのは欧米のASCII+αな文字体系のシステムをそのまま使っているからだと想像できます。これは仕方ない感じがしますが、Q-Pかbase64か、適切な符号化を自動で判断できればベストなのだと思います。

メールの符号化について、『プログラマのための文字コード技術入門』でも説明しています。メールを送信するようなアプリケーションを初めて作るというような方は、お読みいただくと良いと思います。いま買うと震災の被災地の支援にもなるので、是非どうぞ。

符号化とは少々別の話ですが、先日使ったあるウェブシステムは、送出されてきたメールを見たら全然読めない状態でした。何が起こったのかをひとしきり調べてみたら、UTF-8の本文をbase64して送っているのですが、ヘッダの途中に空行が誤って入ってしまって、それ以降が本文扱いされてしまい、base64した結果がまるごと本文になってしまっていたのでした。base64の箇所だけ抜き出してデコードしたら、何が書いてあったかは分かりました。普通は本番稼働する前にテストして気付かないものかと思います。メーラにもいろいろありますが、これが読めるメーラは多分ないと思うのですが...。開発時によく注意してほしいと思います。

『文字コード技術入門』震災被災地支援プログラム2011というものを始めました。本の売り上げの著者の取り分の一部を東日本大震災の被災地の支援のために寄付するものです。

まだ本書をお読みでない方は、是非この機会にお買い求めください。

一人の読者、一人の著者にできることは小さいですが、力を集めればきっと何かできるはずだと信じています。

私が使っている一眼レフカメラはキヤノンのEOS Kiss X4という機種です。1年くらい前に買いました。私にとって初めての一眼レフですが、楽しく使っています。当ブログで時々紹介している写真はこのカメラで撮ったものです。

ふとアマゾンでこの機種を見てみたら、値段がぐんと安くなっているのに驚きました。私が買ったときは、ズームレンズの2本付属するキットで11万円くらいだったのですが、今同じものが7万円台になっています。

この1年で、購入者層のかぶるEOS 60Dや、後継機のEOS Kiss X5、より手軽なX50が出ているので、値段が下がるのは当然かもしれません。

デジタルものはどんどん新機種が出て値段が下がるのは仕方ないこととはいえ、自分の買った物の値段が下がるとちょっと残念な気がします。

EOS Kiss X4とX5は、機能・性能的にほとんど差がないようなので、今買うなら値段の下がったX4を買うのもお買い得かもしれません。アマゾンのランキングを見てみたらX4の方がX5より上になっていました。

広告