パスワードを忘れた? アカウント作成
1396 story
プログラミング

UNICODEをどう組み込む 160

ストーリー by wakatono
とりあえず仕様調査から入ろう 部門より

takusi 曰く,"ソフトウェアのi18n(国際化)の切り札と目されているUNICODE。しかし、このUNICODEはUTF-16、UTF-8などのいくつかのエンコードや、実装を支援するための、IBMのICUやGNUのgtextのような多数のライブラリがあります。UNICODEはどのようにプログラムに組み込むのが吉でしょうか?(当然、OSや言語によって様々でしょう)"

確かに悩ましい。iconv() 1つ取ってもさまざまな仕様があったりするし、Samba 日本語版などでは MS の CodePage の仕様から、結局 iconv() に頼ることなく自前で実装してたりする。悩むくらいならば自前でやるぜと思う人もいるかと思うが、それはそれでメンテナンスの面で悩ましい。さて、どうするのが吉か?

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by oku (4610) on 2001年10月28日 23時41分 (#33426) 日記

    何も iconv や Unicode に関わらずとも wchar_t⇔char + メッセージカタログで 十分ではありませんか?

    m17n だと内部コードはやっぱり UCS-4 (or UTF-32) かな~とか 考えざるを得なくなるのかも知れませんが。

  • by oku (4610) on 2001年10月28日 23時45分 (#33428) 日記
    英語だけ == 8bit clean の事であれば まあ世界中の大概の人は困らないでしょうね。
    # 私も適当に誤魔化して使うと思う。
    でも US-ASCII 限定の意味だとすると ISO-8859 人にも使えなくなってしまいますよ?
  • Re:UNICODEなんて (スコア:3, おもしろおかしい)

    by Anonymous Coward on 2001年10月29日 0時18分 (#33442)
    その提案が2バイト日本語でなされているのがイタイ(w
  • by oku (4610) on 2001年10月29日 0時56分 (#33454) 日記
    「他人に売れるものが作れるか」
    ということを念頭におかないのであれば
    1. まずは 8bit clean で作りました。ソース公開します
    2. 誰か i18n 対応してください > i18n が必要な人
    3. 誰か m17n 対応してください > m17n が必要な人
    という解もありうるのではないかと思いますが。

    # Ext-B への需要とか Unicode 以外の日本語処理の
    # 部分については大筋で御意です。

  • Re:i18n の範疇ならば (スコア:3, すばらしい洞察)

    by brake-handle (5065) on 2001年10月29日 2時04分 (#33473)

    メッセージカタログというのは、i18nの全体像から考えるとUCS-4などのcharsetよりも上位に来る概念ではないですか? メッセージカタログに含まれる各ロケールのメッセージを記述するために例えばiso-8859-1やUCS-4などのcharsetを選ぶという位置づけになるので。

    ただし、世の中を見渡してみるとメッセージを出さないツールなんてほとんどないんですよね。したがって、用意されているロケールのどれか1つを選択することは必須です。このとき、実際にあるロケールを選択することによって、それによって選べるcharsetが限定されてしまう(場合によってはUCSを除くとuniqueになってしまう)ことがしばしばあります。その点からするとUCS-4はいささかオーバースペックに見えます(間違いなく使わない文字が大量に残ってしまう)。

    そう考えてみると、UCS-4が魅力を持つためには、複数のロケールを併用する場面を作り出すことが必要になってきそうです(そんな場面あるのか?)。

  • 初心者の敵だ (スコア:3, おもしろおかしい)

    by Anonymous Coward on 2001年10月29日 4時15分 (#33501)
    JavaはUNICODEを使うようになってるので国際化は全部解決してるみたいな甘い言葉に誘われて手を出してみたらエディタやらデータ入出力等あらゆるところで文字コード変換が必要で死ぬかと思った。 ごめんなさい、初心者のボクにはJavaは無理でした。うそです。弱音は吐きません。がんばって文字コードの泥沼を横断するです。
  • PythonでUNICODEするときは「日本語環境で Python (Idle) を使う (utf-8編)」が有益です。

    --
    景気なんて飾りです。偉い人にはそれがわからんのです。
  • まず、Unicode (UTF-8) のほうがいい理由。

    • フル規格の ISO-2022 の実装は大変すぎてとてもできない。
    • ISO-2022 は、そこそこのサブセットでさえ、実装するのは面倒。
    • stateless である。つまり、「状態」を持たない。エスケープシーケンスもない。というわけで、サロゲートペアで批判されている UTF-16 でさえ、ISO-2022 よりもはるかにシンプル。ISO-2022-JP よりもシンプルと言える。
    • 必要に迫られていて、かなりの能力と時間がある人でないと実装ができないので、対応ソフトウェアがいつまでたっても増えない。
    • CJK の漢字はたしかに CJK で区別できるといろいろと利点があるが、 ISO-8859-* に載っている文字 (たとえば、ISO-8859-1 [の右半分] にも ISO-8859-2 [の右半分] にも同じ文字 [たとえば 0xc4 はウムラウトのついた A] が入っている [というか、大部分が共通な文字]) は区別しないほうがいい。

    次に、どちらでもいい、もしくは、どちらともいいがたい点。

    • 結合文字や bidi (bi-direction、アラビア文字やヘブライ文字のように右から左へと文字が進むのを許す実装) は、Unicode でも ISO-2022 でも手間は同じ。
    • 漢字のうち、CJK で字形が同じものについては、賛成、反対どちらも意見がある。賛成の意見で有名なのは「grep 毛沢東」だろう。(反対は「grep 手紙」かな?)

    最後に、Unicode に移行したほうが悪くなる点。

    • CJK 統合漢字のうち、字形が異なるもの。「骨」とかが有名だが、「直」に至っては中国の字形はたいていの日本人には判読不能と思われる。ただしこれも、U+E0000 からのタグや、もうひとつレベルを上げてマークアップで区別することが可能だが、実装が大変。
    • JIS X 0208 と Unicode との相互変換テーブルが、さまざまな実装があって統一されていない。漢字部分については Unicode Consortium がきちんと変換テーブルを用意しているので問題がないが、記号部分については各社ばらばら (英語ですみませんが、ぼくの書いた文書 [debian.or.jp]の Conversion tables differ between venders を参照してください)。 Unicode Consortium は、参考扱いの変換テーブルを用意していたが、 最近それも obsolete (廃止) 扱いにしてしまった (http://www.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/ [unicode.org])。 完全に移行しきってしまえば問題とはならないはずだけども。 ちなみに、GNU libc は、上記の OBSOLETE なテーブルのうちの JIS0208.TXT をもとに、上記拙文の EUC-JP round-trip compatibility に記載されている問題を回避する目的で、JIS X 0208 の 0x2140 (「\」) を U+005C から U+FF3C に変更したものを使っています。 XFree86 は、JIS0208.TXT そのままでしたが、GNU libc 式に追随するパッチが受け入れ待ちとなっています。
    • 文字幅問題。これは、ターミナルエミュレータなど、固定幅フォントを使う場面において、どの文字が倍角扱いになるかが、EUC-JP などで広く使われていたデファクトスタンダード (JIS X 0208 や JIS X 0212 に含まれている文字はすべて全角、ASCII や JIS X 0201 に含まれている文字はすべて半角) とは異なる。詳しくは、上記拙文 [debian.or.jp]の Width problems を参照 (英語)。 ただしこれも、完全に移行してしまえば問題でなくなる。
    • EUC-JP や Shift_JIS で、2バイト文字 = 全角、という世界では、マルチバイト文字に対応していないソフトウェアもごまかして使うことができる場合があったが、UTF-8 だとそうはいかなくなる。

    完全にユーザである (開発は一切おこなわない) のなら、対応ソフトウェアの状況で、移行するほうがいいかどうかを決めればいいと思います。

  • UNICODEなんて (スコア:2, おもしろおかしい)

    by Anonymous Coward on 2001年10月28日 23時26分 (#33413)
    使わなければいい。英語だけでたくさん。
  • なんだか、モデレータ氏がフレームを煽っているような気がします。

    ところで UTF-16 で書いたソースコードを扱えるCコンパイラってあるのでしょうか?
  • by oku (4610) on 2001年10月29日 1時10分 (#33458) 日記
    ところで UTF-16 で書いたソースコードを扱えるCコンパイラってあるのでしょうか?
    存在の有無については寡聞にして存じ上げないわけですが。
    そのコンパイラは
    puts("�a5;n");
    をどう解釈するのでしょうね? :-)
    # いや、\xa5\x6e が正しいと言うのは
    # 頭では分かってはいるんですけどね...
  • by kyle (3923) on 2001年10月29日 1時26分 (#33461) 日記

    LANG=ja_JP.romaji を使う覚悟があるのですか? 読みにくいぞー、慣れの問題かも知れんが。

  • by oku (4610) on 2001年10月29日 1時32分 (#33463) 日記
    i18n 上、何の解決にもなっていないと思いますが。
    # きちんと入力を Byte[] で受けて
    # 自前で操るのであれば別ですけど...
    # ひょっとして考えているターゲットがズレてます?
  • 英語だけなので locale.h 自体が なかったりするのではありませんか? :-)
  • by brake-handle (5065) on 2001年10月29日 9時46分 (#33525)

    どこにshiftが入るかわからない素の文字列でgrepするとひどいことになるのは事実です。しかし、

    • shiftで区切られる部分文字列について、minimum charsetを用いる(iso-8859-1など)
    • shiftの連続について、最後のshift以外を除去

    ぐらいをやってやれば、uniqueなエンコーディング(同時に最簡形でもある)を得ることができるのでは?

    この手の需要はすでにIntenet message headerなどで存在し、かつ実装もあります(From: の内容で検索できるなど)。

  • by brake-handle (5065) on 2001年10月29日 10時00分 (#33528)

    うーん、私の近くにもJavaを勉強している人がいるんで(私自身は使ってない)いろいろ話が聞けるんですが...

    文字列というのは現代の(あるいは昔から?)計算機では数え切れないほど多くの場面で使われています。とならば、ある局所的な部分だけで高い機能を実現しても、現実に存在するほかの部分との整合性をとらなければオモチャで終わってしまいます。Javaが世の中の全てになればいいですが、おそらくそうはならないでしょう(C当たりは永遠に残る可能性が高い、こいつがないとOSが書けないので仕事にならん)。

    ところで、複数localeは何に対して定義しているんでしょうか? UTF-16じゃlocaleなんて概念は要らないし、もし部分文字列に対して定義できるというんだったらiso-2022と全く変わらない。あるいはlocale情報を持つオブジェクトがあるのかも知れないが、localeを切り換えるやり方とどう違うのかよくわからない...

  • Re:初心者の敵だ (スコア:2, 参考になる)

    by Anonymous Coward on 2001年10月29日 10時41分 (#33542)

    Locale とエンコーディングは本来は直交した概念だよ。 C ロケールではロケールにエンコーディングわりふってる けどね。仮にすべてで UTF-16 をつかってても Locale 的な考え方は必須。

    んで、Javaでは、Locale関連情報を扱うクラスが あって、任意にオブジェクトを生成できます。 それを引数にとることで、日付とか数値の書式とか メッセージ処理とか、文字種判定とか、メッセージ 境界判定とかとか、文字列の比較処理とか、GUIで 扱うフォントとかの挙動を部分的に変更できるわけ。 もちろんC的にデフォルトロケール指定もできますが、 もし、Cのように系全体での変更しかできないと、 アプリケーションの動的な追従ができないのね。 ストリームのエンコード指定はロケールとは別に できます。Cではこの種の処理はロケール非依存の 従来のストリームとiconv 使えばある程度は いけるけど、書いてると死ねるし環境依存が激しい から使いたくならんですな。 C/C++の少なくともエンコード処理周りを java 並に しようと思うなら、IBM がJava と機能的に同等の クラスライブラリを提供してるので、それを使うと いいんじゃないかな。 局所的に高機能でも・・・のくだりなんだけど、現実では 他と整合とる必要なんてないと思うよ。局面に応じて 必要十分な能力が発揮できる言語をつかえばよいだけ のこと。Javaがすべてになればなんて考える こと自体ナンセンス。

  • by redbrick (4865) on 2001年10月29日 12時07分 (#33560) 日記
    なんでこのコメントがScore:-1なんですか?
    #非常に参考になったと思ったんですけど・・・。

    ちゃんと目開けて、頭動かして見てます?>モデレータ諸氏
    --
    ---- redbrick
  • by rug (55) on 2001年10月29日 13時37分 (#33580) 日記
    何も iconv や Unicode に関わらずとも wchar_t⇔char + メッセージカタログで 十分ではありませんか?
    これってportabilityあるのですか? 今でもOpenBSDみたいにmultibyte localeに対応していないシステムがあるし、そもそもwchar_tが1 byteしかない環境さえある。WindowsもNTは問題ないけど9xはmbからwcに変換できなかったと思う。
  • 技術者の負け (スコア:2, すばらしい洞察)

    by wawawa (3653) on 2001年10月29日 13時38分 (#33581)
    若かりし頃、わたしも「英語でいいじゃーん」な人だったんで
    お気持ちは分かります。

    でもね

    学校で子供たちがWebページ作りを学ぶ、という実習で、
    現在のWebインフラでは、安心して日本語のディレクトリ名や
    ファイル名を扱えない。結局子供にローマ字でディレクトリ/
    ファイル名をつけるよう指導した。

    こんな話を聞くと、ソフト屋の端くれとして、悲しくなります。

    # もちろん特定環境に限定すれば日本語OKですよ。
    # IIS + IEとかね、でも、本件は Apache

    これ自体はURLのエンコードの話なんで、直接UNICODEの話題
    ではないし、UNICODEが全てを解決するとは思わないけど、
    世界中の人が自分の言語で普通にコンピューティング可能な
    環境を作るってのは崇高かつ重要な目標だと思いますよ。

    できれば美しい機構がいいけど、現実に困っている人がいるの
    なら、ベタな方法だろうとその解法を提示するのも、また
    必要な事です。
  • by rug (55) on 2001年10月29日 13時47分 (#33584) 日記
    MS Office文書やXML文書を扱おうと思ったらUnicodeは避けて通れないと思いますが。
  • by rug (55) on 2001年10月29日 17時10分 (#33655) 日記
    私は内容よりも表現の仕方の方が重要だと思いますが。 やはりいくら素晴らしくても相手に届かないと。
    相手にもよると思いますが。というか、どんな表現でもそれが届かない相手というのは存在し得るでしょう。いちいち気にしていたら何も書けなくなると思いますが。

    それに、表現をどうとらえるかというのは読み手自身の問題だと思いますが。ある文字列を見てカッとなったことがモデレートに影響を及ぼすなんて愚の骨頂です。
  • Unicodeの利点って

    日本語でも中国語でも毛沢東が一発検さ(もういい

    # というネタはともかく、↑がうれしいかどうかは、大いに疑問に感じています。必要ならシソーラス用意すればいい話でしょうに。

  • OpenBSD だと、昔の Linux (libc5) みたいに X の locale を代替品に使えないんでしょうか?
    # 実は自宅の Slackware を OpenBSD に差替えようかと
    # 妄想してたんですが...
  • >ライブラリ/実装なんかはいくらでもある訳だし
    だから問題なんじゃないかと思いますけど (^^;;;
    統一したライブラリ/実装にならないと「解決」にはならないでしょう。
    そういう意味では「選択肢のない」方がましな気もしますよ。
    #Unicodeがましな選択とは思いませんけどね。
  • 人口からいうと、中国語だと思う

    北京語と広東語の違いは方言の域を超えているという話だ。
    「中国語」としてひとまとめにするのは乱暴ではないかな。
    --
    char *A;
    モータースポーツ部 [slashdot.jp]
  • by oku (4610) on 2001年10月30日 5時17分 (#33877) 日記
    確かに ISO-10646 を指示するための ISO-2022 エスケープシーケンスが ISO-10646 側の文書で定義されていたような 記憶はありますけど...
    あれって使用は推奨されないんではありませんでした?
  • 日本語でも中国語でも「花子」が一発検索。

    さて、モデレートはどうくるかな?
  • ということを念頭に置くと、金田研究室ならいざ知らず、国内の顧客の連絡先を蓄積するような用途で「英語だけ」を扱うプログラムというのはその出力を結局人間が手作業で解釈し直さなければならない欠陥を持つため、十分な利益を得られないと言う意味で「他人に売れる物は作れない」ということになるでしょう。
    日本語処理については「避けて通れない時にどうするか」という仮定を置かないと収拾がつかないと思う。
    Unicodeも、Ext-Bあたりのレパートリに対する要求は決して少なくないレベルに来ていると思う。ただ、まだ日本語処理でUnicode以外の手段を取る余地はあると思う。
    というわけで、親コメントには「んなもの売れない。だからご提案は謹んで無視させていただく。」としかならないと思う。以上。
    --
    -- unicodebetrayer@gmail.com
  • by kyle (3923) on 2001年10月29日 1時35分 (#33464) 日記

    同意。Linux の各ディストリビューションでも、 UTF 化のモチベーションが高まりきらないのは、 現状で足りているからだと思います。

    i18n で足りている人に UTF 化の モチベーションを与える論理を、だれか頼む! お願い、マジで。移行したいんだもん。

  • by Anonymous Coward on 2001年10月29日 1時44分 (#33468)
    locale.h がないと、Single UNIX Specification に準拠できませんので、準拠するためだけに存在する可能性は高いです。
  • by kyle (3923) on 2001年10月29日 2時01分 (#33472) 日記

    (シフトを用いる 7bit 符合の ISO-2022 エンコーディングに 話を限らせてもらうと) grep ができません。

  • by Anonymous Coward on 2001年10月29日 2時30分 (#33479)
    NetBSD current の iso2022 rune みたいに、iso2022 の実用上十分なサブセットを作って、wchar_t にマッピングする方法論が実用的です。
    # 日本では、割と昔からやってるんだけどなぁ。
    # 上の rune の元になってる nvi-m17n とか、
    # XMulti の HTML モジュールとか。
  • by redbrick (4865) on 2001年10月29日 3時22分 (#33486) 日記
    >ISO-2022-JP は、エスケープシーケンスがうっとおしくて、
    >内部処理(切ったり貼ったり)に向きません。伝送用です。

    あのー・・・EUCはエスケープコード使ってないって、ご自分で示された
    リンク先に書いてあるんですけど(汗)。

    ISO-2022という大きなくくりで考えるなら、もっと実際に使われる
    encoding側に話の焦点を移さないと論点がぼやけませんか?

    #個人的には、内部コードに特定のencodingをそのまま使うのって
    #意味のないことだと思ってます。
    #現状はencoding方式間の変換からは逃れられないし、
    #Unicodeで世界統一なんて、現状は夢のまた夢だし。
    #それに、真の意味でのm17n文書なんて作るとき
    #(英語と中文と日本語が混じった文書など)に、Unicodeって、
    #それらをテキストレベルできっちり識別して表示できるんですかね?
    #それができなけりゃ、「単なるもうひとつの選択肢」ってだけで、
    #Unicode使う意味なんて見いだせないのだけど・・・。
    --
    ---- redbrick
  • by Anonymous Coward on 2001年10月29日 3時26分 (#33487)
    > UCS-4はいささかオーバースペックに見えます

    素晴らしい洞察 :D
    Unicode の筋の悪すぎるところはここなんですよねー。

    世の中文書ごとに 1 言語しか使わないことのほうが多くて、せいぜい文書ごとに言語が切り替えられれば十分な場合がほとんどなんで、M17N 化に伴うコストは、M17N という、使用頻度が非常に低いものが必要な奴らが極力背負うべきなんですが、Unicode は I18N のレベルで十分な人々にも大きな負担を背負わせるコード構造なんですね。
    新しく M17N 向きのシステムを作るとしたら、M17N も見据えつつ、でも、一番使用頻度の高い 単一言語下での利用がなるべく軽く行えるように熟慮するべきなんですが(その分、M17N が必要な時に要求リソースが余計に大きくなったとしても許す)、Unicode はそうなってませんねー。

    で、組み込みだとこれはそれなりに重大。あと、UNIX 限定の話をすれば、Unicode べたべたにしたいんなら、今の X のフォントの仕組みを棄てないと辛い。
  • by Anonymous Coward on 2001年10月29日 3時39分 (#33493)
    > LANG=ja_JP.romaji を使う覚悟があるのですか?

    それは英語ではない :D
    # 用字と言語は別です。
  • by Anonymous Coward on 2001年10月29日 10時30分 (#33540)
    > #(英語と中文と日本語が混じった文書など)に、Unicodeって、
    > #それらをテキストレベルできっちり識別して表示できるんですかね?

    Unicode の言語タグを使えばできますよね。
    言語情報を入れられない ISO-2022 よりはかなりマシかと。
  • by Anonymous Coward on 2001年10月29日 10時57分 (#33546)

    1 The Unicode Standard, Version 3.0 を買う
    2 The Unicode Standard, Version 2.0 を古本屋で買う
    3 The Unicode Standard Worldwide Character Encoding. Version 1.0 の 2 冊本を根性で入手する
    4 JIS X 0221-1:2001 の規格票を買う
    5 JIS X 0221-1995 の規格票を入手する
    6 ISO/IEC-10646-1:2000を取り寄せる
    7 ISO/IEC-10646-1:1993 を図書館で借りる

    で、こいつらを枕にして寝る悪夢を見てさらにunicode.org のこんな頁を見ちゃったりして結局 RFC 1815 しかないんぢゃない ? とかうそぶく。

    はい。というわけで規格オタクの出来上がり (^^;

  • by redbrick (4865) on 2001年10月29日 11時01分 (#33547) 日記
    >Unicode の言語タグを使えばできますよね。

    ふーむ、やはりそういったシステムは作られているのですね。
    #ちょっと安心・・・。

    ちなみに、現状の8bitコード体系でどうやってそのような追加情報
    (ですよね? 本来encodingに関わらない、地域、言語範疇の情報の追加だし)
    を入れているのか、方式等について、ポインタだけでもお教え願えませんか?
    #Unicode規格書読んだら載ってます?
    #それともISO-2022の最新の規格書にあるのかな?
    #UnicodeもISO-2022の規格に入るはずだったと思うけど、違ったかな(汗)?
    --
    ---- redbrick
  • by baby_face (5007) on 2001年10月29日 11時24分 (#33550)
    でも、真剣に英語を地球人の公用語にすれば
    いろいろ便利でいいのになぁ、なんてことは
    ありますね。

    んで、我々にとって日本語は、第二国語。
  • by Dark Knight (5476) on 2001年10月29日 11時38分 (#33555)

     超漢字を標準にしてしまうのダ。

    #もちろんオープンソースで。
    #でもUNIX用がないのね(^^;)

    --
    /* Written by Takayuki Masuda */
  • 意味はない.
    何のためにプログラムを作ってるの?
  • アルファベットだけ字形が同じでも元の言語が違えば別コードを割り振ってるわけですが、
    モンゴル文字とかは字形が同じならunicode的には同じコードですよね。
    「wa」とよむ「は」と「ha」と読む「は」は日本語の場合なぜか字形ベースで同じコード番号なのですが
    「ha」は文頭に来ないからソートとか助かってますよね。
    これがあっちこっちにある言語の処理は泣き泣きです。
    デバナガリというかインド系文字も中途半端に文字合成が前提ですが
    合成規則はタミル語とか使用言語によって違うのでアルファベットなみに別にコードが欲しいな。
    言語タグだとタグ位置をフォローしないと切り張りできないからiso2022以上のメリットないし。
    昔、部首から漢字を合成するフォント処理系がありましたが、漢字ですらこけたわけで。
    いっそunicode=フォントメーカー用字形カタログコードと定義してくれた方が楽です。
    pdfなんかは内部処理コードと字形コードは全く別ですね。
  • by redbrick (4865) on 2001年10月29日 13時29分 (#33579) 日記
    オフトピに反応してすみませんが(汗)、ご説明いただきどうもありがとうございます。
    #わたしとしては、もっとi18n/m17nの話を進めたい/読みたいんですけど・・・。
    #Unicodeの話も結局そこが一つの大きな話題の焦点だと思うし。

    >真相はわからんけど、文章の最後が 2chの吉野屋ネタだったので、
    >それを嫌った人がいたのかもね。
    >あるいは、ネタの体裁を取るなら、もっとうまくやれ。
    >ってことかも。

    つまりは、内容吟味せず表層だけ見て判断したというわけですか・・・。
    #質低すぎ(汗)>さっきのモデレーション

    わたしは2ch利用者じゃないんで、元コメントの何がどう悪いか、
    何に対して過敏反応したのか、はっきり言って理解できなかったんです。
    情報量や参考意見としてなら、評価に値するものではないかと思ったのです。

    ま、納得できない意見の表明に対しては、わたしは積極的に批判するつもりですし、
    他の方がモデレーション上書きし直したみたいですね。
    #しかし、メタモデレーションは時間が経ちすぎててあまり意味をなしてないよなぁ。
    --
    ---- redbrick
typodupeerror

吾輩はリファレンスである。名前はまだ無い -- perlの中の人

読み込み中...