Hatena::Groupasakura

浅倉卓司@blog風味? このページをアンテナに追加 RSSフィード

Error : RSSが取得できませんでした。

2006-06-28(Wed)

Jcode::CP932 - 0.04

| 12:27 |  Jcode::CP932 - 0.04 - 浅倉卓司@blog風味? を含むブックマーク  Jcode::CP932 - 0.04 - 浅倉卓司@blog風味? のブックマークコメント

 あ、canとData::Dumperとevalを使えばできるじゃん!*1

 Jcode-2.0ってsjisとかの部分がハードコーディングされてるので、convertとかsetとかappendをコピペしないといけないんですよね……。

 %jname2eと%ename2jがmyじゃなくてourなら良かったんだけど*1。なんかいい方法があればなぁ*2。

Jcode::CP932 - 0.03

 canでCODE_REFを取得してData::DumperでDumpしてevalすればいいっぽい。他により良い方法がなければこれで。

 Encode::CP5022x相当が実装されれば、Classic部分を削除してCPANに登録しよう……。

Jcode-CP932-0.04.tar.gz filelist


MySQLのFAQにCJK文字セットのことが上がってた

| 13:32 |  MySQLのFAQにCJK文字セットのことが上がってた - 浅倉卓司@blog風味? を含むブックマーク  MySQLのFAQにCJK文字セットのことが上がってた - 浅倉卓司@blog風味? のブックマークコメント

 5.0用と5.1用があるけど、今のところは同じみたい。

 ざっと眺めた感じだと

  • Shift_JISとCP932等の非互換のこと
  • Yen Sign問題
  • 挿入できない文字コードがあったときにエラーにせず、ワーニングを出してその文字を「?」にしてしまう話
  • クライアントのコードではSET NAMESを使えという話
  • LIKEとかFULLTEXTサーチとかの話
  • 5.1ではCJKなテーブル名を使えるようになるらしい
  • 他いろいろ

――ってな感じかな。ちゃんと読んでないので間違ってるかもしれないけど。

*1:最近はこーゆーのを「アハ!体験」とか言うらしい。ネーミングセンスないというか訳すときにもうちょっと工夫しろよ、とか思う。

トラックバック - http://asakura.g.hatena.ne.jp/asakura-t/20060628

2006-06-20(Tue)

Jcode::CP932 - 0.03

| 18:44 |  Jcode::CP932 - 0.03 - 浅倉卓司@blog風味? を含むブックマーク  Jcode::CP932 - 0.03 - 浅倉卓司@blog風味? のブックマークコメント

 動作をJcode-2.0に準拠するように変更して(それにともないJcode-2.0が必要)、Encode::CP932Familyを同梱するようにしました。


 Jcode-2.0ってsjisとかの部分がハードコーディングされてるので、convertとかsetとかappendをコピペしないといけないんですよね……。

 %jname2eと%ename2jがmyじゃなくてourなら良かったんだけど*1。なんかいい方法があればなぁ*2

*1:それはそれで問題があるかな?

*2:Jcodeの<DATA>を読み出して書き換えるとか? うーん。

2006-06-15(Thu)

Jcode::CP932 - 0.02

| 20:00 |  Jcode::CP932 - 0.02 - 浅倉卓司@blog風味? を含むブックマーク  Jcode::CP932 - 0.02 - 浅倉卓司@blog風味? のブックマークコメント

 森山さんのEncode::CP932Familyを元にIBM拡張文字とNEC選定IBM拡張文字の変換を追加しました。

 とりあえずはこれで問題ないのかな……。

トラックバック - http://asakura.g.hatena.ne.jp/asakura-t/20060615

2006-06-13(Tue)

Jcode::CP932 0.01

| 17:33 |  Jcode::CP932 0.01 - 浅倉卓司@blog風味? を含むブックマーク  Jcode::CP932 0.01 - 浅倉卓司@blog風味? のブックマークコメント

 とりあえず作りました。Jcode-2.05がベースです。use Jcodeするかわりにuse Jcode::CP932することで使えます。

 Jcode->new()を使っている場合はJcode::CP932->new()に変更する必要がありますが、jcode()を使っている場合はuseの部分を変更するだけで動くはずです*1

 CPANにアップする予定はありません。


 基本的にはJcode.pm(の旧版)と同じですが、Unicode変換まわりを変更しています(具体的にはEncodeモジュールを使ってCP932で変換するようにしています)。

 なお、EUCや7ビットJISについては、CP51923やeucJP-ms、CP5022xとの互換性については検証していません。このため何らかの問題が生じる可能性があります。


 ――弾さんが互換性を持たせるのを嫌がっていた理由がよく分かりました。

 変換テーブルの検証とかが大変なのね。。。


補足

 どうせCPANに上げるなら

  • Unicodeの正規化処理
  • Encode::EUCJPMS
  • Encode::CP5022x(あるいは相当のもの)

に対応して、Jcode-2.x互換にしたほうが良いと思うんですが、どうなんでしょうかね。

 正規化処理さえあればJcode::CP932は特に必要ないって気もするし、Jcodeインターフェイスのまま使いたいっていう需要はありそうな気もするけど。


 少なくとも

# 森山 将之 『Encodeモジュール用の cp51932、cp5022[01] (ユーザー定義文字なし) の超手抜き実装の例。(以前、試しに作ったものです)

http://www2d.biglobe.ne.jp/~msyk/software/perl5/CP932Family.pm

 Unicode との変換は、cp932 を使用し、jcode.pl で eucjis との変換を行う。

 jcode.pl を使っているので、ユーザー定義文字は〓に置換されます。』

*

を参考にしてある程度正しくCP51932とCP5022[01]に変換するようにしないとね。

CP51932やCP50220、CP20221に対応させるには

 大雑把にいうと

  • CP932はIBM拡張文字を使い、それ以外はNEC選定IBM拡張文字を使うから、それらの変換が必要?
  • CP50220は半角カナを扱わないから、半角カナは全角に変換するなどの対処をする?

――って感じなのかな。

 CP932Family.pmの変換ロジックをそのまま使えばいいか……。

*1:あとはJcode::convert()を使っている場合はJcode::CP932::convert()にする必要がある。……テストで修正したのはだいたいその辺だったので。

トラックバック - http://asakura.g.hatena.ne.jp/asakura-t/20060613

2006-06-12(Mon)

Jcode::CP932っぽいもの

| 20:01 |  Jcode::CP932っぽいもの - 浅倉卓司@blog風味? を含むブックマーク  Jcode::CP932っぽいもの - 浅倉卓司@blog風味? のブックマークコメント

 試しに作ってみた。基本的にはUnicodeとの変換をEncodeのCP932を使うように変更しただけです*1


 他にJcode-2.0以降に含まれるJcode::_Classicと::Constantsと::Trと::H2Zが必要。

 EncodeのFallbackとかどうにかしたほうがいいんだろうなぁ、とか思いつつ。Jcodeのt/*が通るように調整中。

続きを読む

*1:Encode::EUCJPMSがあるかどうか判定して、あるならそっちを使うべきな気もするけど。

トラックバック - http://asakura.g.hatena.ne.jp/asakura-t/20060612

2006-06-09(Fri)

古いJcode(or jcode.pl)の実装を利用すればJcode::CP932は作れるのか……

| 11:14 |  古いJcode(or jcode.pl)の実装を利用すればJcode::CP932は作れるのか…… - 浅倉卓司@blog風味? を含むブックマーク  古いJcode(or jcode.pl)の実装を利用すればJcode::CP932は作れるのか…… - 浅倉卓司@blog風味? のブックマークコメント

 あ、そうか。

 レガシーエンコーディング同士での変換なら(ある程度は)問題ないから、レガシーエンコーディングUnicodeの変換にだけEncodeモジュールを用いればいいのか。

# 森山 将之 『Encodeモジュール用の cp51932、cp5022[01] (ユーザー定義文字なし) の超手抜き実装の例。(以前、試しに作ったものです)

http://www2d.biglobe.ne.jp/~msyk/software/perl5/CP932Family.pm

 Unicode との変換は、cp932 を使用し、jcode.pl で eucjis との変換を行う。

 jcode.pl を使っているので、ユーザー定義文字は〓に置換されます。』

*

 jcode.plを利用してるとのことだけど、Jcodeクラシックでもイケルかな?

 イケルならそれをコピーして使えば良いような気もする。

森山 将之森山 将之2006/06/09 16:12Jcodeクラッシクも試して使えた記憶があります。
Jcode のマッピングを次のように修正して使っている人もいるくらいなので、Jcode::CP932 の需要はあるでしょうね。
http://homepage2.nifty.com/hobbit/html/jcode.html

トラックバック - http://asakura.g.hatena.ne.jp/asakura-t/20060609

2006-06-08(Thu)

とりあえずレガシーエンコーディングプロジェクトの成果待ち

| 23:26 |  とりあえずレガシーエンコーディングプロジェクトの成果待ち - 浅倉卓司@blog風味? を含むブックマーク  とりあえずレガシーエンコーディングプロジェクトの成果待ち - 浅倉卓司@blog風味? のブックマークコメント

 もうちょっとお気楽に対応できるかと思っていたんだけど、やっぱり大変そう。

(だからこそレガシーエンコーディング対策プロジェクトを立ち上げているのだと思いますけれど)

# 森山 将之 『eucJP-ms の ucm ファイルは、最初、成瀬さんが作っていたのですが、変換がうまくいっていない所があったので、私が作ったものになっていると思います。

 Unicode から eucJP-ms への変換でJIS規格準拠のマッピングで変換されたものも受け付けるように多対1 の変換を行っています。

 TOG/JVC のマッピングテーブルが元になっていますが、eucJP-0212M.txt はファイルが途中で途切れていて、そのままでは使えません。eucJP-0212M.txt.970820 (旧バージョン?)というのがあるのですが、eucJP-0212M.txt では 0x8FA2B7 は U+FF5E となっているのが、eucJP-0212M.txt.970820 では、0x8FA2B7 は U+007E になっているなどの違いがあり注意が必要です。

TOG/JVC のマッピングテーブル

http://www.opengroup.or.jp/jvc/cde/appendix.html

→ 1. Microsoft Windows 3.51 式の変換

 Legacy Encoding Project では、その多対1 変換を取り除いた ucm ファイルおよび、ucm ファイルを生成するためのスクリプトを公開予定です。

 JIS X 0208 の WAVE DASH と JIS X 0212 の TILDE の問題があるので、JIS系とCP932系の相互変換は出来ないと考えておいた方が無難でしょう。

 eucJP-ms は、そこのところは割り切って JIS X 0208 の WAVE DASH と JIS X 0212 の TILDE は区別できないものとして扱ってます。(どちらも U+FF5E にマッピングされ、eucJP-ms への変換では、JIS X 0212 TILDE は使用されません)』

# 森山 将之 『Encodeモジュール用の cp51932、cp5022[01] (ユーザー定義文字なし) の超手抜き実装の例。(以前、試しに作ったものです)

http://www2d.biglobe.ne.jp/~msyk/software/perl5/CP932Family.pm

 Unicode との変換は、cp932 を使用し、jcode.pl で eucjis との変換を行う。

 jcode.pl を使っているので、ユーザー定義文字は〓に置換されます。』

*

 森山さんは「JIS系とCP932系の相互変換は出来ないと考えておいた方が無難」と書かれていますが、問題が生じる可能性があることを認識のうえで――例えば「相互変換」ではなくどちらかに寄せる対応になると認識したうえで正規化する変換はあったほうが良いと思うのです。

 なぜならUTF-8Unicode)で流通しているテキストをレガシーエンコーディングに変換する必要がまだあって、そのUnicodeなテキストがCP932系なのかJIS系なのかは判別することができないからです。そういう時はなんらかのポリシー(CP932系にするかJIS系にするか)で正規化するようにしないと困ったことになるような気がします。

 確かAmazonのデータはCP932系らしく「~」はU+FF5Eで送られてきたと思うのですが*1、本当にCP932系なのであればそれをJIS系のエンコードに変換すると問題が生じたりするはずですし。そういう時に変換できないと困るんじゃないかと思うのです。

*1:逆でしたっけ?

森山 将之森山 将之2006/06/09 13:34Unicode 上での正規化とエンコーディングの変換を分けて使うようにするか、CP932系の方だけ融通を利かすようにするという事は現実解としてあるえると思っています。

トラックバック - http://asakura.g.hatena.ne.jp/asakura-t/20060608

2006-06-05(Mon)

JIS系とCP932系の相互変換

| 16:46 |  JIS系とCP932系の相互変換 - 浅倉卓司@blog風味? を含むブックマーク  JIS系とCP932系の相互変換 - 浅倉卓司@blog風味? のブックマークコメント

 現状で問題になっている(気がする)のはJIS系とCP932系のUnicodeマッピングが非互換だかららしくて、sjis同士*1euc-jp同士*2だと(あまり)問題がなくても、Unicodeに変換しちゃうとそれぞれお互いに変換できなくなる。らしい。

 であれば、

  1. Unicodeマッピングに無いものでもレガシーエンコーディングにするときは変換しちゃうようにする
  2. JIS系かCP932系に正規化するUnicodeのマッピングテーブルを作って、レガシーエンコーディングに変換する前には正規化する

――のどちらかが実現すればちょっと幸せになるような気がする*3

 前者については規格至上主義者の方々が反対するだろうから*4、後者の正規化処理があればいいんじゃないかな~と思うんだけど。

 どこかで誰かが実装していないのかな……*5


UnicodeのU+FF00-U+FFFFって誰が申請(登録)したのかな?

| 00:38 |  UnicodeのU+FF00-U+FFFFって誰が申請(登録)したのかな? - 浅倉卓司@blog風味? を含むブックマーク  UnicodeのU+FF00-U+FFFFって誰が申請(登録)したのかな? - 浅倉卓司@blog風味? のブックマークコメント

 Unicodeの決定プロセスとか知らないんだけど、U+FF00-U+FFFFって日本(と韓国)でしか使っていなさそうな――もっと言えばMicrosoftが好みそうな――コードがみっちり入ってるんだけど、どういう経緯で登録されたんだろうか。

 僕の想像(妄想)ではMicrosoftあたりが「日本じゃASCIIと同じ記号の『全角文字』ってのがないと駄目らしいよ?」とか言って――だからFULLWIDTHなんていう日本人以外*6には意味不明な名称がついてる――登録したんじゃないかと*7。だから

$str =~ tr/\x21-\x7e/\x{ff01}-\x{ff5e}/;

ってな感じで、完全に1対1対応になってるんじゃないだろうか。だからMicrosoftにとって「~」はFULLWIDTH TILDEであってもWAVE DASHじゃない。

Microsoftは、これらの変更のうち、0x8157、0x815D、0x81FCは従ったけど、残り4つは従わなかったうちの3つはこのU+FF01-U+FF5Eの文字だから――僕の妄想によれば「MicrosoftがASCIIの半角・全角変換用に用意した文字だから」従わなかったのでしょう。……残る0x8161はなんだろう?)


 他にもU+FF61-U+FF9Fには半角カナが入っていたりU+FFE0-U+FFE5に他で割り当てられているっぽい全角記号が入っていたりして、どうも実装上の都合(何らかの事情で全角・半角をきちんと分けなければいけない)っぽい感じがします*8


 ……このへんの事情って想像するしかないんだけど、どこかで説明されてたりするんでしょうかね。

*1Shift_JISとCP932。

*2EUC-JPとeucJP-ms。

*3レガシーエンコーディング対策本部のメーリングリストでこういう主張は見なかった気がする。見逃してるかな?

*4:勝手に変換されると問題があるだろうから、反対するのは正しい。

*5:個人的にはPerlのモジュールがあればとりあえず問題は解決するんだけれど。

*6:それとも日本以外でも「全角」って言うんだろうか? あれは日本の組版からきた呼び名だと思ってたんだけど。

*7:もちろん同じ主張はMicrosoft以外もする可能性はある。

*8:U+FF00-U+FFFFの残りの部分は韓国向けの記号っぽいけど、韓国のコードが分からないのであの配置だと実装がしやすいのかはちょっと分からない。

kosakikosaki2006/06/06 09:53昔、XML開発者の日で樋浦さんから聞いた話だと、
現在、文字の追加はISO10646の仕事、コード体系の枠組みの拡張はUnicode Consortiumと分業されているそうです。
で、IBMがISO10646の日本のNational Bodyにうちの機種依存文字いれてよー。といったらケンもホロロに断られたので(他のメーカも数千字づつメーカ外字をもっているので収集がつかなくなるから)、IBMさん、知恵をめぐらせて、カナダ委員から提案させて無理やり通した。
というIBMカナダ漢字秘話ってのがあるらしいですよ。超二次情報ですまんす(^^ゞ

hiohio2006/06/06 10:28Unicode::Japanese はどうでしょう?正規化ていう訳じゃないですけれど。

asakura-tasakura-t2006/06/06 11:05IBMカナダ漢字の話はどこかで聞いた気もするのですが、あれってU+FF00-U+FFFFとは別の話ですよね? それともあれがU+FF00-U+FFFFの話だったのかな?

asakura-tasakura-t2006/06/06 11:30Unicode::Japaneseは前に降れたように(http://asakura.g.hatena.ne.jp/asakura-t/20060531/1149066700)それで解決するのは知ってはいるのですが、それはそれとして正規化するマッピングは欲しいなあ、と。
 tr///で済みそうな気もするので、モジュールにするほどではないかもしれませんが……。

asakura-tasakura-t2006/06/06 12:16補足。
 IBMカナダ漢字の件を知ったのは最近の小形さんの記事でした。
http://internet.watch.impress.co.jp/www/column/ogata/news4.htm
 Unicode::JapaneseはActivePerlでmakeに失敗するようです。どうしたものか……。

kosakikosaki2006/06/06 21:04おお、すいません。私の記憶違いのようですね。失礼しましたm(_ _)m

kosakikosaki2006/06/09 10:58どもども(^^ゞ
いつも参考にさせてもらっています。
JIS系とCP932系の相互変換の案1の規格至上主義者が云々というのは、ちょっと違うと思っていて(いやもちろん規格至上主義者も反対するんですが)
・今世間で公開されているマッピングを実装するとソースレビューが不可能になるので嫌がられる(メンテナは自分が合ってるかどうか確認できないコード嫌い)
・Windows以外のプラットフォームの人からWindowsに対応するならうちのプラットフォーム用の変換もShift_JISのテーブルに入れて。とか言われだすと収集つかなくなるじゃん。そんな調停したくないよ
とかとか、全員が幸せになる提案ならあんまり揉めないんですけど、9割が幸せになる提案は「自分の事ばかり・・・」みたいな議論になっていく事があって難しいな。と
それは、それとして、正規化の提案はとてもすばらしいですね。僕的にはすごく賛成。
これぐらいならメンテも楽だし。

asakura-tasakura-t2006/06/09 11:07ああそうか。確かにそうですね>ソースレビューが不可能
 そういえば弾さんもそれで苦労したような話をしていたのをすっかり失念していました。

トラックバック - http://asakura.g.hatena.ne.jp/asakura-t/20060605

2006-06-04(Sun)

ActivePerl用のTemplate-Toolkit

| 22:18 |  ActivePerl用のTemplate-Toolkit - 浅倉卓司@blog風味? を含むブックマーク  ActivePerl用のTemplate-Toolkit - 浅倉卓司@blog風味? のブックマークコメント

 何も考えずに

ppm install Template-Toolkit

でインストールできた記憶があったので調べてみたら、例によってhttp://theoryx5.uwinnipeg.ca/ppms/レポジトリにありました。

http://d.hatena.ne.jp/ikasam_a/20060603/1149347840

 自力でmakeするのが目的なら余計なお世話ですが、案外uwinnipegのレポジトリを知らない人も多いようですので、とりあえず。

トラックバック - http://asakura.g.hatena.ne.jp/asakura-t/20060604

2006-06-03(Sat)

Jcode::CP932

| 18:57 |  Jcode::CP932 - 浅倉卓司@blog風味? を含むブックマーク  Jcode::CP932 - 浅倉卓司@blog風味? のブックマークコメント

 弾先生はJcodeの手入れにあまり乗り気ではないようなので、Jcode::CP932の実装をちょっと考えてみよう。

 Jcodeのcompatibleオブションは、例えば

use Jcode compatible => 'win'; # or 'cp932'

とすることでsjisやeuc等がCP932互換で動くのを期待していました。なので、最低でもuseしている行は変更しなくちゃいけない。であれば

use Jcode::CP932 qw/:override/;

とかするとJcodeがCP932互換になるようなモジュールを作れば解決するような気がする。

 わざわざ:overrideを指定するのは、:overrideしないときはJcode::CP932とJcodeを別々に使えるようにするため。必要ないかな?


 Encode::CP5022xがあれば作っちゃうんだけど、まだないもんなぁ。

 Encode::EUCJPMSってどうやって.ucmを作ったんでしょ? Microsoftの資料から変換するツールとかありそうな気がするんだけど……。

森山 将之森山 将之2006/06/08 18:14eucJP-ms の ucm ファイルは、最初、成瀬さんが作っていたのですが、変換がうまくいっていない所があったので、私が作ったものになっていると思います。
Unicode から eucJP-ms への変換でJIS規格準拠のマッピングで変換されたものも受け付けるように多対1 の変換を行っています。
TOG/JVC のマッピングテーブルが元になっていますが、eucJP-0212M.txt はファイルが途中で途切れていて、そのままでは使えません。eucJP-0212M.txt.970820 (旧バージョン?)というのがあるのですが、eucJP-0212M.txt では 0x8FA2B7 は U+FF5E となっているのが、eucJP-0212M.txt.970820 では、0x8FA2B7 は U+007E になっているなどの違いがあり注意が必要です。
TOG/JVC のマッピングテーブル
http://www.opengroup.or.jp/jvc/cde/appendix.html
→ 1. Microsoft Windows 3.51 式の変換
Legacy Encoding Project では、その多対1 変換を取り除いた ucm ファイルおよび、ucm ファイルを生成するためのスクリプトを公開予定です。
JIS X 0208 の WAVE DASH と JIS X 0212 の TILDE の問題があるので、JIS系とCP932系の相互変換は出来ないと考えておいた方が無難でしょう。
eucJP-ms は、そこのところは割り切って JIS X 0208 の WAVE DASH と JIS X 0212 の TILDE は区別できないものとして扱ってます。(どちらも U+FF5E にマッピングされ、eucJP-ms への変換では、JIS X 0212 TILDE は使用されません)

森山 将之森山 将之2006/06/08 19:05Encodeモジュール用の cp51932、cp5022[01] (ユーザー定義文字なし) の超手抜き実装の例。(以前、試しに作ったものです)
http://www2d.biglobe.ne.jp/~msyk/software/perl5/CP932Family.pm
Unicode との変換は、cp932 を使用し、jcode.pl で euc や jis との変換を行う。
jcode.pl を使っているので、ユーザー定義文字は〓に置換されます。

asakura-tasakura-t2006/06/08 19:31「JIS系とCP932系の相互変換は出来ないと考えておいた方が無難」なのであればやっぱりJcode::CP932モジュールのようなものが必要になりますね。
 個人的には「問題が起こりうる」のを承知の上でJIS系とCP932系の相互変換ができるような方策が必要な気がしていますけれど。難しいんでしょうかね……。

2006-06-02(Fri)

やっぱりこれからは期間課金じゃなくて1回払いですよ!

| 22:42 |  やっぱりこれからは期間課金じゃなくて1回払いですよ! - 浅倉卓司@blog風味? を含むブックマーク  やっぱりこれからは期間課金じゃなくて1回払いですよ! - 浅倉卓司@blog風味? のブックマークコメント

 「年間更新料ゼロのセキュリティ対策ソフトの勝算」を読んだら、昔ちらっと書いた「絶対成功する有料サイトの課金方法」を思い出した。

 やっぱりこれからは期間課金じゃなくて1回払いですよ、社長!


 この発想を3月に思いつき、ライセンスの期限が終了する際に表示される「期限切れメッセージ」や、ライセンスを更新する際の手間をなくすという結論に至りました。顧客はほとんど何もする必要がなくなるので、こんなにいいことはないと確信しましたね。

――ってあるけど、僕もそう思ったのは3月なんですよね。

 この時期って何かそういうネタがあったんだっけ?


 それはそれとして。

 前に「打倒!2大セキュリティー対策ソフト――中国、ロシア、東欧、北欧から参入続々」という記事があって調べてみたら

キングソフト(中国)以外にも結構沢山進出してきてたのね。……調べてみたらキングソフト以外は普通に高いじゃん。それじゃシマンテックやトレンドマイクロどころかマカフィーにすら勝てないんじゃ?

という結論になってうんざりしてたんですが、この値段なら買ってもいい気がします。

 なにしろ他社の年間更新料とだいたい同じなんだから(キングソフトを除く)、だったら試しに買ってみるのもアリだと思うし。セキュリティソフトの妥当な価格は500円/年くらいだと思っていたので、そういう意味でも値ごろ感があっていいんじゃないでしょうか。

トラックバック - http://asakura.g.hatena.ne.jp/asakura-t/20060602
2004 | 01 | 02 | 03 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2005 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2006 | 01 | 02 | 03 | 04 | 05 | 06 | 08 | 09 | 10 | 11 | 12 |
2007 | 02 | 03 | 04 | 05 | 06 | 07 | 10 | 11 | 12 |
2008 | 02 | 03 | 04 | 06 | 09 | 10 | 11 | 12 |
2009 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 09 | 10 | 11 | 12 |
2010 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2011 | 01 | 02 | 03 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2012 | 02 | 03 | 04 | 05 | 07 | 08 | 10 | 11 | 12 |
2013 | 01 | 05 | 07 |
2014 | 01 | 02 |
2016 | 01 |
2017 | 01 | 05 |