Path: ccsf.homeunix.org!CALA-MUZIK!newsfeed.media.kyoto-u.ac.jp!newsfeed.mesh.ad.jp!t-newsgw1.odn.ne.jp!nwall.odn.ne.jp!not-for-mail From: IIJIMA Hiromitsu Newsgroups: fj.kanji Subject: Re: Mixi Unicode =?iso-2022-jp?B?GyRCSjg7ejI9JDEbKEI=?= Date: Fri, 19 Aug 2005 06:27:18 +0900 Organization: DENNOU GEDOU GAKKAI, N. D. D. // FABRICA UTILITATIS Lines: 86 Message-ID: <4304FD36.6E9E2CE@ht.sakura.ne.jp> References: <3992273news.pl@rananim.ie.u-ryukyu.ac.jp> <42FF4EDB.768E5340@ht.sakura.ne.jp> NNTP-Posting-Host: eatcf-12p13.ppp15.odn.ne.jp Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit X-Trace: nwall1.odn.ne.jp 1124400488 61935 211.121.43.13 (18 Aug 2005 21:28:08 GMT) X-Complaints-To: news@odn.ad.jp NNTP-Posting-Date: Thu, 18 Aug 2005 21:28:08 +0000 (UTC) X-Mailer: Mozilla 4.78 [ja] (Win98; U) X-Accept-Language: ja,en,zh-TW,zh,zh-CN,de,es,ko Xref: ccsf.homeunix.org fj.kanji:207 いいじまです。 > 　正直に告白すると、前の記事は酒呑んで TV 見ながら書いてまし > た。なので「極力」なんです :-) 了解です。 > >・「所謂Shift_JIS」は単に「Shift_JIS」で正しい。 > >　Shift_JIS は IANA に正式に登録されたエンコーディング名。 > > 　いえ。「Shift_JIS」と「Windows-J31」とが別の charset であ > ることを称して「所謂」です。拡張文字は後者にしか含まれません > が、一般にはこれらは同一視されていますので。 なるほど、そういう意図でしたか。了解です。 ＃とすると、「Shift_JIS系」とか書いてほしかった :-) > 　もっと遡ると、元々「IBM 拡張文字」ってのは汎用機に実装され > てたものなので PC-9801 が生まれるより前からあったと思います。 > なので初期の PC-9801 から実装されてるんですね。 なるほど。 > >> また、a は PC-9801 の頃は漢字 ROM に入ってません。 > 　だから PC-9821 がまだ出ていない時代です。少なくとも初代に > は載ってませんでした。ひょっとすると PC-8x01 みたいに拡張漢 > 字 ROM が出てたかも知れませんけど。 > 　標準実装されたのは V30 機が出て来た頃じゃないかなー。尤も、 > その後も暫くは「平成」なんかは実装されてませんでしたが :-) なるほど、私が触ったいちばん古いのはPX-9801VXですから、たしかに知らない わけです。 > >Windows の場合、Unicode から Windows-31J への変換の優先順位は a→c です。 > >（b. は使わない。） > > 　それが違うんですよ。95/98 architecture と NT architecture > とで拡張文字領域の mapping が逆になってます。 > > ＃　この辺りを Samba 日本語版で苦労したいきさつが「Samba の > ＃すべて」にちょっと載ってたりします。 手元にあるのは Windows Me なので、すでに 2000 系と統一されていると思います。 実家に帰れば98SEがあるのですが…。 > >JIS X0213ではこの領域が de facto standard から de jure standard に昇格 > >しましたから、JIS X0213 ベースの体系を指定すれば堂々と使えます。 > > 　X0213 だと EUC-JP にした時に 3bytes になりませんか？ いえ、13区の文字はG1に入っています。 ただ、G3に回されている文字もあると思います。 ＃ちなみに、元々はG2を使う予定だったのですが、G2に1バイト文字（＝半角カタ ＃カナ）を想定している処理系が多すぎるとのことで、G3にまわされました。 > そもそ > も、この特殊な EUC-JP には対応している環境がまず存在しないと > 思うんですが、どっかにあります？ Emacs :-) G1だけでよければ非 Unicode な処理系全般でフォントだけ用意して処理できるの ですが。 > 　実際、95/98 architecture では Unicode が介在するのは VFAT > VxD の部分だけ (アプリは別) ですが、IME の正規化は行なってい > ます。 > 　これは、Windows-31J -> Unicode -> Windows-31J という変換の > 結果ではなくて、内部に Windows-31J の正規化テーブルを持って > いるからですね。 > > 　なので、Windows の version によっては妙なことが起こります。 > filename に拡張文字を使う時は上の変換による副作用として生じ > る正規化ですが、IME による正規化は IME 独自のテーブルによる > ものなので、結果として同じ入力文字が異なるコードを生成します。 > 　Windows API はこれらの重複文字を同一視するので特に支障はな > いんですが、アプリベースだと同一視出来ないので、例えば「dir」 > の結果を「grep」で引っかけようとするとヒットしなかったりしま > す。 あちゃあ。 ======================================================================== 飯嶋 浩光 / でるもんた・いいじま http://www.ht.sakura.ne.jp/~delmonta/ IIJIMA Hiromitsu, aka Delmonta mailto:delmonta@ht.sakura.ne.jp