2013年3月アーカイブ

今年は桜が早く咲いています。ここ南関東では今や盛んに散っているところです。

桜といえば全国各地に名所がありますが、京都の桜も人気が高いですね。

以前、春の京都に旅行に行ったことがあります。

春の京都は大人気なので、桜の全盛期を少し外すように予定を立てました。人込みが苦手なんです。それでも京都市内の宿がとれず、滋賀県の大津に宿泊しました。隣の県まで行くというと大変に聞こえますが、実は京都から大津まで電車でわずか10分しかかかりません。

京都自体が、高校の修学旅行以来、大変久しぶりでした。それでいきおい、定番の観光地に足を運ぶことになります。

竜安寺は修学旅行で行った場所です。細かいところは忘れたものの良い印象があったので、再訪してみました。すると思いがけず、こんな桜が出迎えてくれました。

Rock garden of Ryōanji temple

ソメイヨシノはもう終わった時期でしたが、枝垂れ桜はまだ咲いていたんですね。たまたま腰を下ろしたところから見た角度がとても良かったので、カメラを向けて撮ってみたのがこの写真です。当時まだ一眼レフを使っていなかったので、コンパクトカメラで工夫も何もなくシャッターを押しただけです。それでも被写体がいいので、素敵な感じに写りました。

日本語版Wikipediaの「関数」の項目のノート (記事についての議論)を開いてみると、表記が「関数」か「函数」かという議論を延々としています。一生懸命議論している人たちには申し訳ないけれども、それは本当に労力を費やすべき部分なのかと疑問に思わざるを得ない。もちろん、英語版のfunctionの記事にはこういう現象はありません。

本文の方も、いきなり「表記の歴史」から始まっているのが異様な感じがします。肝心なことは関数という概念そのものであって、漢字でどう書くかというのは枝葉に属することではないでしょうか。

俗に「生き字引」という言葉があるように、昔は文字を知っていることが物事を知っていることと同じようにみなされてきたのでしょう。過去においてはある程度仕方なかったところがある。

本来、物事を知る、物事の道理を知るということが、学問の上で大事なことです。文字でどう書くかというのは言語の記録や伝達の手段です。手段が目的よりも幅をきかせるのが良いこととは思えません。もちろん、記録や伝達のために効果的な表記方法を選択するのは良いことですが、この場合は正直どちらでもいいような話です。

そんなことに労力を使うのなら、いっそ「かん数」にしてはどうでしょうか。(冗談ですよ!)

「現在一般に行われている表記は歪められた間違ったもので、過去に遡ると唯一の正式な表記が存在するのだからそれを再現すべきだ」という考えにとりつかれてしまうと、不毛なことになるようです。これは必ずしも上記の「関数」のこと(だけ)をいっているのでなく、ネットでときおり見られる文字に関する主張についての感想です。

ふたつの中国

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

中国の政府や政治家が「ひとつの中国」と言うことがあります。三つも四つもあったら大変だろうひとつで十分だと私などは思うのですが、そうでなくて、主に台湾の中華民国政府との関係で言われるわけです。チベット問題の文脈でもこの言葉が使われることがあります。

日本の政治家が「ひとつの日本」と声高に主張することはありませんし、フランスやドイツなど他の国も大体同様でしょう。わざわざ「ひとつの」と強調するのは、そう言わなければならない理由があるということです。思い出すのはアメリカの大統領選挙でオバマ氏が「United States of America」とUnitedを強調して言っていたことで、これはちょっと「ひとつの」に近いかもしれない。

さて、歴史的に考えたときに、「中国」とは一体なんなのか、というのは、真面目に調べたり考えたりするほど分からなくなってきます。現代の中華人民共和国が支配している領域(+α)をそのまま過去に延長したものが中国だ、というのが中国政府の見解かもしれませんが、それは歴史的にはかなり無理がある。

例えば、「秦の始皇帝が初めて中国を統一した」というけれども、その「統一された中国」の領域にはチベットも東トルキスタンも南モンゴルも満洲も入っていない。

歴史的な領域と現代の国境が必ずしも一致しないのはよくあることかもしれませんが、それにしても「中国」の場合には違いが大きすぎる。それに何より、自分たちの土地を「中国の一部」とされることによしとしない人々が大勢いる。それで百件以上もの焼身抗議が起こっているわけです。

最近思うのは、「中国a」「中国b」というふたつを分けて考えると見通しが良くなるということです。

  • 中国a: 歴史的に秦や漢や宋などの漢民族国家が興亡した地域。漢民族の伝統的な居住地域
  • 中国b: 清の最大勢力範囲を国土とし、その中の住民を「中国人」と定義して国民国家化しようとした概念

これに従えば、秦の始皇帝が中国を統一したというときの中国とは「中国a」のことです。一方、中華人民共和国政府が「××は昔から中国の一部だった」と主張するときは大体「中国b」が想定されているでしょう。

人によっては、「中国a」を「シナ」、「中国b」を単に「中国」と呼ぶことがあります。これはこれでひとつの方針だと思いますし異を唱えるつもりはないのですが、ここでは「中国」という言葉の曖昧さの表現という意味もあってこういう言葉遣いになっています。

多分この説明だけでは、どういうことかよく分からない、なぜこういう考えに至ったのかよく分からないという人も多いと思います。その背景はおいおい説明していきたいと思います。そのためには、清という国がどういう性格のものだったのかという理解が必要になってきます。

「おやき」という食べ物を知っていますか? 知っている人もそうでない人もいるでしょう。知っている人でも、あなたが知っている「おやき」は、もしかすると、ほかの人が知っているそれとは全然別の食べ物かもしれません。という話を少々。

私が札幌から南関東に引っ越してきて、あちこちを見て回っていた頃、神奈川県の江ノ島にも行ったことがありました。

江ノ島は小さな島ですが、割と高低差があります。そのおかげで迫力ある断崖の景色が見られたりするわけですが、ひとまわり歩くと結構な運動になる。

歩いている途中に、お茶とお菓子を出している店があって、のぼりに「おやき」と書いてある。歩き疲れたのでちょうどいい、ここで一休みしていこう、と思いました。疲れたから甘いものでも頂こう、と。

ここで、「えっ、おやきなのに『甘いもの』?」と思った方がいるかもしれません。また、「おやきって何?」という人もいるでしょう。まさに、そこが問題なのです。

私の育った北海道、札幌では、今川焼きという名でも知られているお菓子を「おやき」と呼びます。今川焼きでも通じるでしょうが、おやきという方がポピュラーだと思います。

なので当然、それが出てくるものだと期待したわけです。しかし注文して出されたものを見るとどうも様子が違う。表面が固いようですし、形も少し違う。でも、おやきと注文して出てきたものである以上、これは私の知っているあのおやきであって、ただ地域によって少し違いがあるんだな、くらいに思いました。しかし、かじりついてみると。

なんと! 中から野菜が出てきました。漫画でいえば頭の上に手書きの「!」が飛び出したような気持ちです。

全然違う食べ物でした...。

後で分かったところでは、これは信州の「おやき」という食べ物で、今川焼きとは全く異なるものでした。

全国、地域によって、「おやき」という言葉が何を指すかはだいぶ違いがあるようです。以前テレビ番組でこの件を取り上げているのを見たことがあります。上で述べた、信州、北海道以外にも、「おやき」という言葉が違う意味で使われる地域があるそうです。

まあ、考えてみれば「おやき」というのはいかにも一般的で茫漠とした言葉ですから、地域差があるのも無理はない。

なぜ、江ノ島で信州のおやきだったのかについては、いまだに理由が分かりませんが...。

春から新生活で別の地域に引っ越す方もいるかと思います。引っ越した先で「おやき」と聞いたら要注意。何を指しているのか、用心してかかった方がいいですよ。

ようやく、今年の6月から札幌の地下鉄でSuicaが使えるようになるというニュースがありました。

記事のタイトルには、札幌地下鉄のICカードのSAPICAが出ています。以前からSAPICAは地下鉄でしか使えず、バスや市電では使えないという課題がありました。今度ようやくバスと市電でも使えるようになり、同時に、SAPICAの使えるエリアでKitaca (JR北海道)やSuica (JR東日本)、ICOCA (JR西日本)等が使えるようになるということです。

関東在住者から見ると、今までは新千歳空港に着いてからJRで札幌市内に入るまではSuicaが使えたのですが(KitacaエリアでSuicaが使えるので)、そこから先、札幌市内の移動には使えませんでした。これが、6月22日からはSuicaだけで事実上どこでも行けるようになります。

今までは、市内を地下鉄やバスで移動するには、磁気式プリペイドカードの共通ウィズユーカードを買うか、いちいち切符を買うかしなかったわけです。SAPICAはバス・市電で使えないので利便性が低い。

札幌市はSAPICAを推したいのでしょうけど、この手の交通ICカードで一番肝心な点は「これ一枚でどこでも行ける」ということであって、その方面の取り組みがあまりにも劣っていると言わざるを得ない。報道によれば、6月になっても、SAPICAでKitacaエリアのJRに乗ることはできないんだそうです。

私はもっぱらモバイルSuicaを使っていて、おサイフケータイに航空会社のカードや電子マネーも入っています。なので、自宅を出て羽田空港に電車で行き、空港でお土産を買ったり食事をしたりして飛行機に搭乗し、新千歳空港からJRで札幌に向かって地下鉄やバスで市内を移動する、というのが、スマートフォン1つでできるようになるわけです。まあ、札幌でなく福岡だと今でもできるんですけどね...。

SuicaはあくまでもJR東日本のサービスに過ぎないので、それが全国どこでも使えることを無条件に期待することには少々無理があると私は思います (首都圏在住者にはそういう傲慢なことを言う人もいます)。ただ、JR東日本ばかりが得をするのでない形で、全国の交通ICカードが相互に利用できるようになることは望ましいと思います。

(SAPICAに少々厳しいことを書いてしまいましたが、事業者間の垣根は首都圏でも見られることがあって、JR東海の東海道新幹線の停まる新横浜駅ではJR東日本のカードが使えないとかいうこともかつてはあったように記憶しています。今でも、新幹線乗り場の売店ではSuicaが使えなかったんじゃないでしょうか。この手の縄張り争いは利用者にとって嬉しいものではありません)

Javaで動くウェブアプリケーションフレームワークであるPlay Framework 1.2.3の上で動いているプログラムを見てちょっといじっていたら、文字コードの扱いに関して、予想と異なる挙動をしていることに気付きました。

そのアプリではJavaのReader/Writerクラスを使う際に文字コードを指定しないでいたので、デフォルトエンコーディングとして、プラットフォームのデフォルト、したがって日本語版WindowsなのでシフトJIS (の、ベンダ定義外字付きのもの。JavaではMS932というラベルがついている) になるはずだ、と思っていました。

ところが、UTF-8の文字列データがきているはずのストリームを、文字コード指定なしにReaderで読んできちんと日本語文字列になっている。あれれどうなってるんだろう。

しばし悩んでしまいましたが、実はPlay起動時にjavaコマンドのオプション指定 -Dfile.encoding=UTF-8 というのが付加されていて、デフォルトエンコーディングが強制的にUTF-8になっていたのでした。

私はPlay Frameworkに詳しくないので、もしかしたらドキュメントのどこかに書いてあって私がそれを見逃していたのかもしれません。が、これはちょっと勘違いしやすそうだなと思いました。

ちなみに、Play 1.2.2のドキュメントには、国際化について、文字コードの問題は面倒くさいのでUTF-8しかサポートしないという意味のことが書かれていました。これはソースファイルや出力HTML等のことをいっているわけですが、このjava起動時の設定もその一環なのかもしれません。

入力としてUTF-8のテキストファイルをとるJavaプログラムでうまくいかないことがありました。

テキスト形式で入力されたデータを処理するプログラムなのですが、ファイル中に存在するはずのデータがないといってエラーになる。

テキストエディタで開いても、ExcelやLibreOffice Calcで開いてみても、ファイルに異常は見当たらないし、問題のデータもきちんと記述されているようにしか見えない。

実はこのエラーの原因は、入力のテキストファイルにBOMが付いていることでした。BOMがどういうものかは『プログラマのための文字コード技術入門』をご覧ください。

Javaで書かれた処理プログラムがUTF-8のテキストを読み込む際に、BOMを消費せずに単なるUnicode文字のように扱うため、1行目のデータの先頭にゴミが付いた状態になっていたのです。それで、見えないゴミ付きのデータになってしまい、意図どおりに動作しないし、テキストエディタで開いてみても異常に気付かなかったわけです。

JavaのライブラリでUTF-8のテキストを読み込むとき、先頭にBOMがあると、それを単なるU+FEFFという符号位置の文字データとして読み込んでしまいます。本来のBOMは、Byte Order Markという名前のとおり、バイト順を示す役割のものであって、文字を符号化したデータの一部ではありません。UTF-16/32と違ってバイト順の問題のないUTF-8にBOMを付けるべきかという問題は議論が分かれるところかもしれません。しかし現実にはBOM付きUTF-8は生成されることがあります。

ウェブ検索で「java utf-8 bom」などとしてみると、BOM付きUTF-8をJavaで読み込んでトラブルになった話が複数出てきたり、また互換性のためにJavaではUTF-8読み込み時の挙動を変える予定はなさそうだという話が出てきたりします。

自分で対策をするしかないようです。

ちなみに、iconvのUTF-8も同じようにデータ先頭のBOMを単なる文字として扱うということを、以前当ブログの記事に書きました。

広告