From: "たけ  (tk)" <ggb03124@...>
Date: 2000-11-01T02:31:53+09:00
Subject: [ruby-dev:11352] Re: Ruby I18N

たけ(tk)です。

Yukihiro Matsumoto さん曰く。
》違います。それでは新しい内部コードを作ることになってしまいま
》すし、結果的に(c)から(f)までの全部の問題が残ります。あと、
》つまんないことですがTRONコードはステートフルだからそのままで
》は使えませんね。

  えと、TRONにしても2022にしてもステートの部分は１バイトで表現できると思
います（未確認）。たんにその部分を「（２）サブコード」にコピーしておくだ
けで済むのではないかと思いまして・・。

　ステートフルな体系というのは通信コストを下げるための手段であって、内部
データとして取り込む場合にはステートの部分をそれぞれの文字コードの一部
（サブコード）として取り込んで処理することを想定しているのではないか？。
３２ビットマシンを想定するならそれの方が自然。

　「内部コードを作る」といっても、「そのままのコード」に「ステート」なり
「コードページ」なりをコピーして付加するだけなので、新しい内部コードを作
るというほどのものではないと思うんですけど。

》元の文字コードはなにか(つまりどう処理するか)という情報は文字
》列、正規表現それぞれに個別に持ってもらうことになるでしょう。
》文字コードが合わない文字列同士は処理できないことにしようと思
》います。

　「元の文字コードはなにか(つまりどう処理するか)という情報は文字列、正規
表現それぞれに個別に持ってもらう」という部分が「（１）処理系ＩＤ」と書い
た部分なんですけど・・。（あそか、文字毎に処理系のデータを持つか、文字列
毎に持つかの違いですね）。

　−−

　内部データの１文字のバイト数は固定でしょうか、可変でしょうか？。３２ビッ
トの固定長ではないかと想像しているんですが・・。（それのほうが、取り出し
やすい）。

たけ(tk)　ggb03124@nifty.ne.jp
http://member.nifty.ne.jp/take_tk