[#11357] [PATCH] an analogue of `long long' — "Nobuyoshi.Nakada" <nobu.nakada@...>
なかだです。
まつもと ゆきひろです
えぐち@エスアンドイー です。
まつもと ゆきひろです
えぐち@エスアンドイー です。
まつもと ゆきひろです
>From: matz@zetabits.com (Yukihiro Matsumoto)
まつもと ゆきひろです
[#11440] class Character (was: Ruby I18N) — Yasushi Shoji <yashi@...>
[ruby-dev:11428] からの続きですが、threadは切りました。
高橋征義です。用語について。
At Wed, 8 Nov 2000 20:44:55 +0900,
高橋征義です。
At Thu, 9 Nov 2000 13:30:34 +0900,
まつもと ゆきひろです
[#11447] gets は secure? — Kazuhiro NISHIYAMA <zn@...>
出力がInsecureなのに入力はsecureなのでしょうか?
[#11467] debug write in regex.c? — "Nobuyoshi.Nakada" <nobu.nakada@...>
なかだです。
[#11500] rb_to_integer/rb_to_int — "Nobuyoshi.Nakada" <nobu.nakada@...>
なかだです。
[#11520] A problem of Socket methods on Windows — OKA Toshiyuki <oka@...>
岡と申します。
なかだです。
まつもと ゆきひろです
なかだです。
岡です。
なかだです。
なかだです。
岡です。
なかだです。
[#11569] blocking on socket? — Shugo Maeda <shugo@...>
前田です。
[#11591] object.c パッチ — Kazuhiro NISHIYAMA <zn@...>
使われてなかったnil_plusの削除とOBJ_INFECTへの変更です。
[#11611] return value of waitpid2 — Koji Arai <JCA02266@...>
新井です。
まつもと ゆきひろです
荒井です。いや、新井です。(よくあることさ)
まつもと ゆきひろです
新井です。
新井です。
[#11618] Re: class variable — "Koji Arai" <jca02266@...>
新井です
なかだです。
まつもと ゆきひろです
> まつもと ゆきひろです
まつもと ゆきひろです
まつもと ゆきひろです
新井です。
[#11641] eval too slow — Wakou Aoyama <wakou@...>
青山です。
[#11650] conflict of NODE_DREGX_ONCE — "Nobuyoshi.Nakada" <nobu.nakada@...>
なかだです。
まつもと ゆきひろです
[#11662] IO (Re: fork problem?) — Tanaka Akira <akr@...17n.org>
In article <E140cR3-0002ls-00@ev.netlab.zetabits.co.jp>,
まつもと ゆきひろです
In article <E140fxW-0002u9-00@ev.netlab.zetabits.co.jp>,
In article <hvor93w5wb8.fsf@coulee.m17n.org>,
In article <hvoofz05uwz.fsf@coulee.m17n.org>,
まつもと ゆきひろです
新井です。
まつもと ゆきひろです
In article <E141eaC-0003w0-00@ev.netlab.zetabits.co.jp>,
まつもと ゆきひろです
In article <E142ZqF-0004rX-00@ev.netlab.zetabits.co.jp>,
まつもと ゆきひろです
In article <E143Zem-000271-00@ev.netlab.zetabits.co.jp>,
まつもと ゆきひろです
In article <E143amj-00028V-00@ev.netlab.zetabits.co.jp>,
[ruby-dev:11521] Re: Proposal of "Array of CharCode"
たけ(tk)です。 [ruby-dev:11506] Re: Proposal of "Array of CharCode" にて matz@zetabits.com (Yukihiro Matsumoto) さん 曰く: 》うーん、二本立ての嬉しさがあまり見えてこないんですけど。たし (1)文字列中のN文字目の文字にランダムにアクセスするようなスクリプトの とき。 (2)文字集合が同じでエンコードだけが異なる場合の処理の共通化。 (3)文字コードでの変換の方が簡単な場合。 (4)前寺さん(TM-Editor という、多言語エディタの作者)の経験談は次の とおり。 》でも、中国の GB 18030 (4バイトコードを持つ)や Mule の UTF-2000 を考えれば、 》24bit や 32bit は程度のビット数は今後の文字処理では必要だと思います。 》でないと、いまケチっても結局将来的に内部処理を大幅に 》書き換えることになります。(経験談) こんな風に続いていますが・・、 》それよりも、内部的には思い切って、64bit固定長(最低でも32bit)にして、 》それをメモリバッファに保持するときに何らかの高速可逆圧縮アルゴリズム 》(UTF-8みたに使用頻度の高い ASCII は1バイトにするなどの工夫をこらす) 》にしたほうが、ソースコードの寿命を延ばせる気がします。 関連URL: http://hp.vector.co.jp/authors/VA002891/TMEDIT/ http://hp.vector.co.jp/authors/VA002891/TMEDIT/TMF_SMJK.TXT nifty:FREKI/MES/19/1539 −− TM-Editor の多言語度は次のとおり。(説明は適当にカット。【分類】は、た け(tk)による)。 http://hp.vector.co.jp/authors/VA002891/TMEDIT/TMH_EXT.HTM 》TM-Editor では以下の文字コードを扱えます。 【既存の文字コード系】 》 DBCS(Shift-JIS, GBK, KSC, Big5 etc) 》 EUC-JP ・・TM-Editor の場合は、半角カナもサポート・・ 》 JIS(ISO-2022-JP) 》 Unicode(UCS-2) ・・TM-Editor の内部ではこの形式で処理・・ 》 Unicode(UTF-16) ・・約100万字を収容できる文字セット・・ 》 UTF-7 ・・7bitしか通さない既存のメールシステムでも・・ 》 UTF-8 ・・収容文字数は約20億文字、一文字は1バイトから6バイト 》 UCS-4 ・・ISO-10646 で決められた、32bit固定文字コード 》 Java Source ・・コード番号129番以後の文字コードは \uXXXX ・・ 》 Unicode 3.0 with Language Tag ・・Unicode 3.0の言語タグつきUnicode 》 超漢字TRONコード BTRON OS「超漢字」て採用されたTRONコードです。 【独自文字コード系】 》 ESC:(TM spec) TM-Editor独自のフォーマットで多言語が扱えます。 》 ISO-2022-ESC B(TM spec) TM-Editor独自のフォーマット 》 Shift-Mojikyo(TM spec) TM-Editor独自のフォーマット 【既存文字コード系+タグ】 》 Unicode + (@;)Mojikyo Tag Unicode文字列+文字鏡番号を指定するタグ 》 DBCS + (@;)Mojikyo Tag DBCS文字列+文字鏡番号を指定するタグ 》 Unicode + (&M;)Mojikyo Tag Unicode文字列+文字鏡番号を指定するタグ 》 DBCS + (&M;)Mojikyo Tag DBCS文字列+文字鏡番号を指定するタグ 【?】 》 16進数 0-9,A-B だけの文字を使った16進数表現 * ユーザーサイドから見ると「DBCS + (&M;)Mojikyo Tag=DBCS文字列+文 字鏡番号を指定するタグ」が扱いやすいとのこと。TM-Editor が吐き出したファ イルを Ruby で扱えるようになると、うれしい。 −− 》もしろいとは思いますが、たぶん標準では提供しないんじゃないか 》なあ。 「処理モジュール」(CharCodeType)に次のメソッドがあれば、 簡単に作れ ると思います。 (1)decode バイト列を受け取って、文字コードの配列を返す (2)encode 文字コードの配列を受け取って、バイト列を返す。 * 「だから標準に入れたほうがよい」となるのか「だからユーザが勝手に作 れ」となるかは、???(保留)。 たけ(tk)=熊谷秀武