パスワードを忘れた？ アカウント作成
Close
7574 story

産総研が多言語化ライブラリをLGPLで公開 45

ストーリー by Oliver
l10->i18n->m17n 部門より

eto曰く、"CNET Japanの記事によると産業技術総合研究所（産総研)により多言語を一度に表示、入力、編集操作などができるライブラリ「the m17n library」がLGPLで公開されたようだ。 詳しくは産総研のプレスリリース及びプロジェクトのサイトを参照して欲しい。"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

産総研が多言語化ライブラリをLGPLで公開 More

  • ISO 10646 も仲良し (スコア:1, 興味深い)

    by Anonymous Coward on 2004年02月21日 6時56分 (#500109)
    ISO 10646も、符号化文字集合の1つにすぎないとして同列に扱える、至極真っ当な世の中がやってくるのでしょうか?

    #これでUnicodeにかかるテンションが幾らかでも下がれば、変換表の非互換性の解消も少しは易くなるかもしれないと期待してみるAC。

    • Re:ISO 10646 も仲良し (スコア:1)

      by TxG (7966) on 2004年02月21日 7時40分 (#500119)
      変換テーブルが一個増えるので余計混乱したりして。

      Cだけで、char配列とstring.hと自前の関数だけで書いている人にはいいでしょうが、正規表現ライブラリとか使ってるとあっさり死亡って感じですね。

      C++で内部UCSでいくにはICUとBoostとかなんでしょうか。ちょっと書いてみてこりゃー耐えられん＆環境作るのが面倒で誰も参加してくれんと思ってやめてしまったのでよく分かりませんが。
      シェア
      親コメント

    • Re:ISO 10646 も仲良し (スコア:0)

      by Anonymous Coward
      EUC-JP の 0x5c はバックスラッシュで、シフト JIS の 0x5c は円記号だから両者のあいだで 0x5c は変換エラーになるという 至極まっとうな世の中は、いつになったら来るのでしょうか？

      変換表の混乱の一部の責任は、JIS X 0201 ローマ字と ASCII とをエエカゲンに使ってきた日本人にもあります。あくまで一部ですが。

      • Re:ISO 10646 も仲良し (スコア:1)

        by thor (5250) on 2004年02月21日 18時19分 (#500362) 日記

        もうJIS X0201は捨てて、Shift JISの0x5cもバックスラッシュにしてしまう、というのが技術的には一番簡単な解決法でしょう。それが受け入れられるかという問題はありますが、EUC-JPの0x5cをバックスラッシュ以外にすることよりは受け入れられやすいでしょう。

        0x5cを半角の円記号(のグリフ)が表示されることを期待して使っている人にとっては文字化けしたように見えることにはなるが、円記号ならJIS X0208にちゃんとあるからそれを使えばよいし、もともと賢明な人は円記号が表示されて欲しい文脈で半角円記号は使っていないでしょう。

        ISO-2022-JPで送られる日本語のE-Mailでは、そもそもJIS X0201 Romanは現在ほとんど使われていないように見えます(半角英数字に切り替えるESC(Jというエスケープシーケンスはほとんど見ることがない。Outlook ExpressでさえもESC(Bを使う)。あくまで使われている文字コードとしては、ですが。もっとも、ほとんどの一般の人はそんなことは知らず、半角円記号として表示されるのが本当は誤りであることは知らないのでしょうが。

        2バイトコードであるJIS X0208が扱えるようになった段階で、JIS X0201はRomanも片仮名も捨ててしまっていれば今頃はもっとすっきりしていたのでしょうね。

        シェア
        親コメント

        • Re:ISO 10646 も仲良し (スコア:1)

          by oku (4610) on 2004年02月21日 19時00分 (#500372) 日記
          もうJIS X0201は捨てて、Shift JISの0x5cもバックスラッシュにしてしまう、というのが技術的には一番簡単な解決法でしょう。それが受け入れられるかという問題はありますが、 EUC-JPの0x5cをバックスラッシュ以外にすることよりは受け入れられやすいでしょう。
          技術的には (or 文字コード的には) こちらが真っ当な解であることを承知の上で (後、Shift_JIS の変換表でも 0x5c はバックスラッシュのはず。0x5c が u00a5 なのは CP932 の変換表くらいです)。
          もともと賢明な人は円記号が表示されて欲しい文脈で半角円記号は使っていないでしょう。
          そんな賢明な人など皆無とまではいいませんが、希少価値のある人間だとみなしていいと思います。 CP932 の変換表が 0x5c を u00a5 に割り付けているのは、日本では JIS X0201 の円と ISO-8859 のバックスラッシュは事実上区別されずに使われている (実装上、同一グリフの別フォントとみなさざるを得ない) という現実を冷徹に認識した上で、顧客の利便性のためなら技術的な筋のよさはステ、という決断を下したものと解釈しています。

          少なくない EBCDIC 系の日本語コードが $ の場所に￥を突っ込んでいるのも同じ理屈でしょう (多分、これは COBOL の実装が諸悪の根源と夢想)。

          シェア
          親コメント

          • Re:ISO 10646 も仲良し (スコア:0)

            by Anonymous Coward
            $gt; 0x5c が u00a5 なのは CP932 の変換表くらいです

            CP932 でも 0x5c は u005c です。u00a5 なのは Shift_JIS。

            ではなぜ Windows において 0x5c が halfwidth-￥ に見えるかと言うと、MS ゴシック等のグリフの問題。Arial Unicode MS 等を使うと、ちゃんとバックスラッシュになります。

            • Re:ISO 10646 も仲良し (スコア:1)

              by oku (4610) on 2004年02月21日 19時15分 (#500380) 日記
              あ～、すみません。 読み返してみると引っくり返して書いてました。

              ご指摘どうも。＞ #500377 の AC 氏

              結局何を主張したかったかというと、real world では 0x5C は「円とバックスラッシュを兼ねる＠日本限定」とするのがほぼ唯一の現実的な解だろうと言うことです。

              # Unicode ステという解もあるかも知れないが。

              シェア
              親コメント

            • Re:ISO 10646 も仲良し (スコア:1)

              by kanie (911) on 2004年02月21日 21時27分 (#500420)
              > もともと賢明な人は円記号が表示されて欲しい文脈で半角円記号は使っていないでしょう。

              しかしながら、JIS X 0208の円記号も使うべきではないです。
              「図形文字の一意な符号化」を考慮すると、それぞれの文字コードの円記号は

              • ISO-2022-JP: JIS X 0201(これは微妙)

              • EUC-JP: JIS X 0208

              • Shift JIS: JIS X 0201

              • Unicode: JIS X 0201由来のu005c


              となるわけで、文字コードを変換したときに「期待通り」になるとは限りません。
              結局、円記号は使わないのが無難です。

              # 請求書を書くときに困った
              シェア
              親コメント

        • 日本の通貨記号 (スコア:1)

          by zenkakueisuuji (20374) on 2004年02月22日 13時51分 (#500766) 日記
          0x5cを半角の円記号(のグリフ)が表示されることを期待して使っている人にとっては文字化けしたように見えることにはなるが、円記号ならJIS X0208にちゃんとあるからそれを使えばよいし、もともと賢明な人は円記号が表示されて欲しい文脈で半角円記号は使っていないでしょう。

          文字化けではないのです。日元の記号はバックスラッシュなのです ;-)

          それはさておき、私は日本語の通常のメール中では JIS X 0208 の円記号を使いますが、英語の場合は "JPY" と書きますね。美国通貨は "$" だったり "US$" だったり "USD" だったりしますが。
          日本語でも "JPY" が通れば安全なのかも知れませんが､なんせ普及率がバックスラッシュより圧倒的に低い。

          シェア
          親コメント

      • Re:ISO 10646 も仲良し (スコア:0)

        by Anonymous Coward
        ＞変換表の混乱の一部の責任は、JIS X 0201 ローマ字と ASCII とをエエカゲンに使ってきた日本人にもあります。あくまで一部ですが。

        ISO 646を策定した奴に文句言え。

  • 日本語での説明は？ (スコア:1)

    by Pen2 (18210) on 2004年02月21日 8時55分 (#500131)
    M-textって？ ワープロ系の RTF形式に相当するものか。
    M-textの操作API は XML DOM の Range みたいなものか。
    英文で読めませんでした。

    • Re:日本語での説明は？ (スコア:2, 参考になる)

      by flutist (16098) on 2004年02月21日 11時43分 (#500198)
      PDF資料 [m17n.org]の３頁目をみると、文字列とプロパティの組だ、とあります。プロパティは、キーとその値の複数の組で、ネストできるそうです。

      たとえばキーFACEには、文字時列のどこからどこまでがイタリックだとかボールドだとか、キーBIDIには右から左に読む範囲がどこどこだ（アラビア語のように）と指定するとか、そういう内容らしいです。そのアラビア語な文字列の中で日本語みたいに左から右に読む範囲を指定するのがネストということでしょうか（図を見るのが早いです）。

      あと、こっち [m17n.org]には、サポートしているinput methodはanthyとtcodeだ、と書いてあります。

      開発者には、muleで有名な半田剣一さんの名前が（一番に）ありますね。電総研のmuleノウハウを生かすプロジェクトってことでしょう。
      シェア
      親コメント
    • Emacs の text property みたいなものかな。

  • 早稲田の多言語化プロジェクトは (スコア:0)

    by Anonymous Coward on 2004年02月21日 9時49分 (#500144)
    結局のところ今どんな状況になってんですかね？こういう話題を見聞きする都度都度に思い出すんですけど……。

  • 多言語ワープロ (スコア:0)

    by Anonymous Coward on 2004年02月21日 10時39分 (#500164)
    これつかって多言語ワープロつくられたらいいのにね
    ワープロでなくてもPowerPointみたいなのでもVisio
    みたいなのでもいいけどさ。
    OOoとかKDEのアプリあたりが多言語化してくれる非常
    にうれしかったい。
    Win32版でもうれしいかな。いまはUNIX/Xだけだけど、
    そしたらWin32でも多言語化アプリつくれるし。現状
    Unicodeっても多言語アプリってしらないから。

  • Hideki Hiura氏ってどんな人？ (スコア:0)

    by Anonymous Coward on 2004年02月21日 18時02分 (#500358)

    産総研のプレスリリース [aist.go.jp]に、

    Open Internationalization Initiative（OpenI18N）※【Chairperson Hideki Hiura】と協力し
    とありますが、このOpenI18nは こっちのストーリー [srad.jp]で紹介されてる、 IIIMF project [openi18n.org] を抱えているとこのようで、図らずも(?)関係するプロジェクトのストーリーが前後して採用されたかっこうですね。

    それはいいんですが、続けて読んでいて大変気になったのが、 あっちの コメント [srad.jp]からリンクされてる先でけちょんけちょんに言われている(私も同意)XMLの例を書いているのが、 他ならぬ上記のHideki Hiura氏というところなのですよね。

    多言語化ライブラリには大期待なのですが、 こんな怪しげ(失礼)なプロジェクトと「協力」しちゃてて、 本当に大丈夫なんでしょうか？ 実際どんな「協力」関係でプロジェクトを進めているのかとても気になります。

    • この提携は相互の権威付けに利用したんじゃないかな？

      Hiura氏はそれなりに見識を持った人ですが、IIIMFはSunのJava端末を売るために仕方なくああいった形になってしまったのだと信じたいです。
      #会社勤めすると、思ってもいないことを堂々と主張することになるものです。
    • IIMF は XML で全ての言語エンジンを書くって話ではなく、
      簡単なものは XML で書いて、クライアントサイドで処理、
      複雑なものは、サーバサイドでって話だけですよね？

      IIIMF としては、XML は単なる一つのオプションなんで、
      使う使わないは 言語のエンジンを作る人の自由なんですが、
      それってそんなに怪しいんでしょうか？

      必要であれば、S式のインタプリタ
      • >結局のところ、uim と iiimf の違いは、クライアントサーバモデルか、
        >そうでないかということ以上ではないんと思うのですが違うのでしょうか？
        私もそのとおりだと思っています。
        変換エンジンの作者として、クライアントサーバ方式によってもたらされるオーバヘッド(マルチユーザ対応によるデータ構造の複雑さ、各個人のデータの安全な保存やアクセスの手間)に耐えることができずにuimの開発もやっています。
        このオーバヘッドは変換エンジンの作者だけが耐えれば良いものではなく、エンドユーザや辞書ツールの作者、あるいはそれらの入力システムを普段使わないユーザにもかかってきます。

        将来的にデスクトップ環境でSingle Sign Onの枠組やデスクトップバスなどが整備されれば、その上でクライアントサーバ方式の入力システムを作るのは良い方向だと思います。
        シェア
        親コメント
        • m17nlibもライブラリ形式のようです。
          Input methodのドキュメントを見てみました。Doxygenのドキュメントがいくつか欠けていて分からないことが多いのですが、XIMの影響を受けつついくつかの問題に興味深い解決を図っているように思います。
          いい加減な解析なので間違ってるかもしれませんが
          • 候補を扱うためのAPIを持っていて、プリエディット文字列のように一個(?)ずつアプリケーションに通知される。
          • Input Contextにプリエディットの位置情報を通知することで、レイアウトを行ってくれる(?)。今までのon/over the spotという概念を越えてそうな感じで興味深いです。
          • コミット文字列の有無はアプリケーションから調べに行かないといけないので、コード表やマイクなどの外部入力は別のレイヤーで処理しないといけない(?)
          • Window systemを抽象化したレイヤーを持っていて、とりあえずXに対応している。
          といった感じで興味深いです。
          後日ソースコードが出てくるのが楽しみです。日本語入力に関してはuimの方が充実しているのですが、多言語を同じ枠組の中できちんと扱えるようにして、そのノウハウが公開されるのは素晴らしいです。
          こういった有用なソフトがフリーで公開されると、世界における日本文化のポジションが高まってくれるのではないかと期待します。
          #役所の研究開発はこうでないといけないですね。
          シェア
          親コメント

  • LGPL なのが残念 (スコア:0)

    by Anonymous Coward on 2004年02月22日 5時08分 (#500624)
    LGPL ちうことは、X に取り込まれることはないだろうし、Windows に取り込まれることはないだろうし。

  • また経産の寄生虫か (スコア:0)

    by Anonymous Coward on 2004年02月22日 5時35分 (#500628)
    何で日本国の国家予算で設立されて、形だけ独立してるような所がFSFの資金を横取りするんだ？
    FSFの資金というのは、フリーなソフトを作るプログラマを資金的に援助するために集められているもので、予算を削られちゃった役所（モドキ）に開けやすい財布を提供するためではない。
    研究費が足らないなら予算を増やすなり、予算が増えないなら予算に見合った研究費で済むように首切るなりすべきだろう。
    国家機関（モドキ）がFSFから金もらうなんて恥晒しだな。
    • FSFの予算をどこに寄付するかは、FSFが決めることでは？ 横取りってできるのだろうか？
    • 国がからむととにかく文句を言わないと気が済まない方ですか？

      #いや、本当にそうみえるので
    • ほんとうは、金額的に言えばたいしたことはいのでは?
      基本的に、日本国の政府機関が国費を使って開発した物をタダ配り
      することにすごい制約があるので、LGPL で公開したいがために、
      資金援助を受けた「紐つき」プロジェクトの形を取っているのでは
      ないかと推測しますが。

  • 素朴な疑問 (スコア:0)

    by Anonymous Coward on 2004年02月22日 23時34分 (#500974)
    こういうのって国研がやる研究なんでしょうか。
    いまいちプロジェクトの位置づけがみえないです。
typodupeerror

「科学者は100%安全だと保証できないものは動かしてはならない」、科学者「えっ」、プログラマ「えっ」