ゲンナリ

via もう、日本のPKIはめちゃくちゃだ @ 圏外からのひとこと

これを読んで、モニタの前で思わず頭を抱え込んでしまいました。ここから連想されるテーマは色々あり、ちょっと気が重くなります。

  1. IEは、(紆余曲折してきてはいるが)それなりのセキュリティ対策を備えている。しかし、その内容はユーザーに理解されていないのでは。
    • それはIEだけの問題か。ユーザーの問題はないのか。業界として啓蒙が必要なのでは。
    • ひとくちに「ユーザー」と言っても、小学校に入る前の子供から、100歳を超える高齢者までいる。どうやって啓蒙するのか。
  2. こんなシステムを開発しておいて、その対価を受け取っている輩がいる。
    • 要は、セキュリティ面の評価ができる人材、評価する制度が整っていないのでは。
  3. IT分野だけに限った問題だろうか。他の、例えば建築・土木分野における技術的領域ではどうか。

和暦サポート

via Javaで和暦をサポートするよう投票しよう @ オレンジニュース

JavaのCore APIで和暦に対応してもらおう、そのためにSunのBug Paradeで投票しよう、という動きです。厳密に仕様を規定しようと思ったら、南北朝時代はどうするのか、とか微妙な問題が色々あるような気がします*1が、とりあえず明治以降がちゃんと動いてくれれば、多くのJavaプログラマにとって福音となるでしょう。業務系ではまだまだ和暦のニーズは多いです。

とりあえず、今すぐに手っ取り早くJavaでの和暦対応が必要なら、IBMオープンソースライブラリであるICU4Jの、Calendarクラスを使えばできたはずです。「大化」くらいの昔からの変換テーブルを持っていたと思います。3年くらい前に少し試しただけで、ちゃんと検証していませんが。

気になったので、ちょっとICU4Jのソースを確認。com.ibm.icu.util.JapaneseCalendarクラスに、以下のようなテーブルがありますね。

    private static final int[] ERAS = {
    //  Gregorian date of each emperor's ascension
    //  Years are AD, months are 1-based.
    //  Year  Month Day
         645,    6, 19,     // Taika
         650,    2, 15,     // Hakuchi
         672,    1,  1,     // Hakuho
         686,    7, 20,     // Shucho
         701,    3, 21,     // Taiho
         704,    5, 10,     // Keiun
         708,    1, 11,     // Wado
         715,    9,  2,     // Reiki
         717,   11, 17,     // Yoro
         724,    2,  4,     // Jinki
         729,    8,  5,     // Tempyo
         749,    4, 14,     // Tempyo-kampo
         749,    7,  2,     // Tempyo-shoho
         757,    8, 18,     // Tempyo-hoji
         765,    1,  7,     // Tempho-jingo
         767,    8, 16,     // Jingo-keiun

(以下つづく)

ついでに、3年前に試したときのコードをCVSから発掘。

import com.ibm.text.*;
import com.ibm.util.*;

(snip)

    SimpleDateFormat formatter =
        (SimpleDateFormat)DateFormat.getInstance(new JapaneseCalendar(), Locale.JAPANESE);
    formatter.applyPattern("Gy年M月d日");

    System.out.println(formatter.format(new Date()));

これで、「平成16年10月19日」と出力された、はずです。

*1:そもそも、GregorianCalendarではダメですね