From msyk ＠ mtg.biglobe.ne.jp Sat Apr 1 15:55:31 2006 From: msyk ＠ mtg.biglobe.ne.jp (MORIYAMA Masayuki) Date: Sat, 01 Apr 2006 15:55:31 +0900 Subject: [LE-talk-ja 7] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TIA==?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: References: <20060323132320.DBAA.MORIYAMA@miraclelinux.com> <20060330092037.GA16364%numata@jp.fujitsu.com> <20060331130203.B34F.MORIYAMA@miraclelinux.com> Message-ID: <442E23E3.2060800@mtg.biglobe.ne.jp> 森山です。 Kazuhiro Kazama wrote: >> On 2006/03/31, at 16:26, MORIYAMA Masayuki wrote: > >>> > MUA (メールソフト) などを想定し、変換元に指定した場合は >>> > 機種依存文字は >>> > 受け付けて、変換先に指定した場合には、機種依存文字などは変換エ >>> > ラーにし >>> > てしまうと、テキストエディタで使う場合に、ファイル読み込みは可 >>> > 能だけれ >>> > ども、保存は出来ないという事になってしまう可能性があります。 >>> > >>> > 文字コード変換の事情を知っていないと、何が問題であるのかという >>> > のが理解 >>> > できず戸惑ってしまう事でしょう。 > >> >> そのような場合には，沼田さんはUTF-8を使えばよいのではない >> かと指摘していると思います．まず最初にUTF-8で解決できない >> 問題は何かを，考えるべきではないでしょうか？ MUA に関しては、UTF-8 対応が進んできているので、RFC1468 の ISO-2022-JP に変換できない文字が使われた場合には、UTF-8 でメール送信する事は現実的な 解決策の一つだという事には異論はありません。 ただし、MUA の都合だけで、文字コード変換の実装を行ってしまうと、「テキス トエディタでの利用の場合に、問題が生じるでしょう」という事を書きました。 >> それで，文字レパートリの問題と，変換表の問題は分けて議論すべきだ >> と思います．私は，少なくとも扱える文字数という点に関しては，増え >> るのではなく，減る方向の提案だと考えています． 文字レパートリの問題と，変換表の問題は分けて議論すべきという点について は同じ考えです。 扱える文字数に関しては、風間さんの意図されている事が、どういう事なのか理 解できませんでしたので、説明していただけると助かります。 >> 数年前に我々も検討したのですが，その時点でもIANA Registry >> への新たなcharsetの登録は，基本的にはおこなわないとのこと >> でした．これは，今後は新たな符号化文字集合を増やすことは避けて， >> できる限りISO/IEC-10646/Unicodeに統一したいという意図によ >> るものです．現在，非常に広く使われているが登録されていなかったと >> いう実績が明確にない限りは難しいでしょう． ISO-2022-JP という名前で Windows の機種依存文字が扱える拡張(CP50220 のサ ブセット?) を実装して使っているものとしては、Mozilla Thunderbird や Sylpheed などがあります。 7ビットJISのエンコーディングで、Windows 機種依存文字を使える実装というの は増えてきていると感じています。 >> なお，すでにJIS委員会では，7ビット及び8ビットの >> 2バイト情報交換用符合化漢字集合は廃止する方向で，JIS X >> 0221の改訂を進めていると聞いていますし，Microsoftやアップ >> ルコンピュータなどのメーカも，同じ意向だそうです．使わないように >> しようとする合意が取れているものに対して，複雑化を進めるのは得策 >> ではないと思います． 今までは、シフトJIS符号化方式の cp932 を、日本語EUC符号化方式、7ビット JIS符号化方式との間で変換して扱う事が困難だったのを、変換して使えるよう にするという事がポイントになります。 「eucJP-ms と ISO-2022-JP-MS は、CP932 の全文字レパートリーを扱えま す。」と一言で言い表せますから、単純明快だと考えています。 cp51932 は、ユーザ定義文字を扱えませんが、Internet Expolorer や Mozilla Firefox が "EUC-JP" として POST してくる文字コードと互換があります。 cp51932 を使えるようになると Windows 機種依存文字を扱う必要のある Web-DB システムで日本語EUC符号化方式だけで処理する事ができるようになり、処理の 単純化が行えるようになります。 >> 以前，Javaの設計で国際化エンジニアと議論したことがあるので >> すが，やはり状況に応じて変換テーブルが変わるというのは，混乱をも >> たらすからよくないという結論になったことがあります．実際には，た >> とえば Emacsで変換テーブルを状況に応じて自由に切り替える実 >> 装もあったりするのですが，それは一般的とは言えず，新たな問題を発 >> 生されるだろうと考えています． どういった問題が発生するのか明らかにしていただければ、メリット、デメリッ トを比較して検討する事が出来るようになると思います。 -- ‖ 森山 将之 MORIYAMA Masayuki ‖ e-mail: msyk ＠ mtg.biglobe.ne.jp From msyk ＠ mtg.biglobe.ne.jp Sat Apr 1 13:33:39 2006 From: msyk ＠ mtg.biglobe.ne.jp (MORIYAMA Masayuki) Date: Sat, 01 Apr 2006 13:33:39 +0900 Subject: [LE-talk-ja 8] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TIA==?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: References: <20060323132320.DBAA.MORIYAMA@miraclelinux.com> <20060330092037.GA16364%numata@jp.fujitsu.com> <20060331130203.B34F.MORIYAMA@miraclelinux.com> Message-ID: <442E02A3.5020704@mtg.biglobe.ne.jp> 森山です。 Kazuhiro Kazama wrote: >> On 2006/03/31, at 16:26, MORIYAMA Masayuki wrote: > >>> > MUA (メールソフト) などを想定し、変換元に指定した場合は >>> > 機種依存文字は >>> > 受け付けて、変換先に指定した場合には、機種依存文字などは変換エ >>> > ラーにし >>> > てしまうと、テキストエディタで使う場合に、ファイル読み込みは可 >>> > 能だけれ >>> > ども、保存は出来ないという事になってしまう可能性があります。 >>> > >>> > 文字コード変換の事情を知っていないと、何が問題であるのかという >>> > のが理解 >>> > できず戸惑ってしまう事でしょう。 > >> >> そのような場合には，沼田さんはUTF-8を使えばよいのではない >> かと指摘していると思います．まず最初にUTF-8で解決できない >> 問題は何かを，考えるべきではないでしょうか？ MUA に関しては、UTF-8 対応が進んできているので、RFC1468 の ISO-2022-JP に変換できない文字が使われた場合には、UTF-8 でメール送信する事は現実的な 解決策の一つだという事には異論はありません。 ただし、MUA の都合だけで、文字コード変換の実装を行ってしまうと、「テキス トエディタでの利用の場合に、問題が生じるでしょう」という事を書きました。 >> それで，文字レパートリの問題と，変換表の問題は分けて議論すべきだ >> と思います．私は，少なくとも扱える文字数という点に関しては，増え >> るのではなく，減る方向の提案だと考えています． 文字レパートリの問題と，変換表の問題は分けて議論すべきという点について は同じ考えです。 扱える文字数に関しては、風間さんの意図されている事が、どういう事なのか理 解できませんでしたので、説明していただけると助かります。 >> 数年前に我々も検討したのですが，その時点でもIANA Registry >> への新たなcharsetの登録は，基本的にはおこなわないとのこと >> でした．これは，今後は新たな符号化文字集合を増やすことは避けて， >> できる限りISO/IEC-10646/Unicodeに統一したいという意図によ >> るものです．現在，非常に広く使われているが登録されていなかったと >> いう実績が明確にない限りは難しいでしょう． ISO-2022-JP という名前で Windows の機種依存文字が扱える拡張(CP50220 のサ ブセット?) を実装して使っているものとしては、Mozilla Thunderbird や Sylpheed などがあります。 7ビットJISのエンコーディングで、Windows 機種依存文字を使える実装というの は増えてきていると感じています。 >> なお，すでにJIS委員会では，7ビット及び8ビットの >> 2バイト情報交換用符合化漢字集合は廃止する方向で，JIS X >> 0221の改訂を進めていると聞いていますし，Microsoftやアップ >> ルコンピュータなどのメーカも，同じ意向だそうです．使わないように >> しようとする合意が取れているものに対して，複雑化を進めるのは得策 >> ではないと思います． 今までは、シフトJIS符号化方式の cp932 を、日本語EUC符号化方式、7ビット JIS符号化方式との間で変換して扱う事が困難だったのを、変換して使えるよう にするという事がポイントになります。 「eucJP-ms と ISO-2022-JP-MS は、CP932 の全文字レパートリーを扱えま す。」と一言で言い表せますから、単純明快だと考えています。 cp51932 は、ユーザ定義文字を扱えませんが、Internet Expolorer や Mozilla Firefox が "EUC-JP" として POST してくる文字コードと互換があります。 cp51932 を使えるようになると Windows 機種依存文字を扱う必要のある Web-DB システムで日本語EUC符号化方式だけで処理する事ができるようになり、処理の 単純化が行えるようになります。 >> 以前，Javaの設計で国際化エンジニアと議論したことがあるので >> すが，やはり状況に応じて変換テーブルが変わるというのは，混乱をも >> たらすからよくないという結論になったことがあります．実際には，た >> とえば Emacsで変換テーブルを状況に応じて自由に切り替える実 >> 装もあったりするのですが，それは一般的とは言えず，新たな問題を発 >> 生されるだろうと考えています． どういった問題が発生するのか明らかにしていただければ、メリット、デメリッ トを比較して検討する事が出来るようになると思います。 -- ‖ 森山 将之 MORIYAMA Masayuki ‖ e-mail: msyk ＠ mtg.biglobe.ne.jp From ogwata ＠ wb4.so-net.ne.jp Mon Apr 3 00:54:33 2006 From: ogwata ＠ wb4.so-net.ne.jp (Ogata Katsuhiro) Date: Mon, 3 Apr 2006 00:54:33 +0900 Subject: [LE-talk-ja 9] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TIA==?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: References: <20060323132320.DBAA.MORIYAMA@miraclelinux.com> <20060330092037.GA16364%numata@jp.fujitsu.com> <20060331130203.B34F.MORIYAMA@miraclelinux.com> Message-ID: <9B01E1C5-DE0B-4523-9635-C258F283C05E@wb4.so-net.ne.jp> 小形と申します。風間さん、こんにちは。 ちょっと脇道にそれる質問ですみません。 On 2006/03/31, at 18:55, Kazuhiro Kazama wrote: > なお，すでにJIS委員会では，7ビット及び8ビットの > 2バイト情報交換用符合化漢字集合は廃止する方向で，JIS X > 0221の改訂を進めていると聞いていますし， > 「7ビット及び8ビットの2バイト情報交換用符合化漢字集合」に該当するJISは、 おそらく以下のようなものだと思います。 　　JIS X 0201 　　JIS X 0208 　　JIS X 0213 「廃止の方向」というのは、上記のいずれ、あるいは全てでしょうか？ 見聞を率直に報告された風間さんを批判するつもりは毛頭ありませんが、 上記のいずれも多くのJISに引用規格として参照されることで、 その規格の一部をなしています。 またJIS X 0221-1ではJIS X 0208は原規格ですし、 JIS X 0213も実質的には原規格の扱いを受けていると考えられます（FA30〜 FA6A）。 廃止ともなれば大きな影響があり、幅広い議論が必要なはずです。 それをあたかも既定の方針として語られている様子に、いささか抵抗を覚えま した。 （※すみません、当初風間さんに直接メールしてしまいました。宛先を再設定 して再送します） ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 小形克宏 (うさぱら有限会社)/ Ogata Katsuhiro (USAPARA corp.) ogwata ＠ wb4.so-net.ne.jp From kazama ＠ mac.com Mon Apr 3 11:40:15 2006 From: kazama ＠ mac.com (Kazuhiro Kazama) Date: Mon, 3 Apr 2006 11:40:15 +0900 Subject: [LE-talk-ja 10] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TIA==?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <9B01E1C5-DE0B-4523-9635-C258F283C05E@wb4.so-net.ne.jp> References: <20060323132320.DBAA.MORIYAMA@miraclelinux.com> <20060330092037.GA16364%numata@jp.fujitsu.com> <20060331130203.B34F.MORIYAMA@miraclelinux.com> <9B01E1C5-DE0B-4523-9635-C258F283C05E@wb4.so-net.ne.jp> Message-ID: 一応，私はSC2の委員ではありませんので（笑） On 2006/04/03, at 0:54, Ogata Katsuhiro wrote: > 「7ビット及び8ビットの2バイト情報交換用符合 > 化漢字集合」に該当するJISは、 > おそらく以下のようなものだと思います。 > > 　　JIS X 0201 > 　　JIS X 0208 > 　　JIS X 0213 > > 「廃止の方向」というのは、上記のいずれ、あるいは全てでしょうか？ 今後，日本として「7ビット及び8ビットの2バイト 情報交換用符合化漢字集合」の新たな開発や保守は行わないということ だと理解しています．すでに制定した規格を廃止することは普通はあり ません・できませんから，そのために私は既存の規格番号を意図的に引 用していません． > それをあたかも既定の方針として語られている様子に、いささか抵抗 > を覚えま > した。 結局，国際と国内の規格が分離していたことがさまざまな不幸なできご とを生んでしましましたので，今後は国際と連動した作業をおこなうと いうことでしょうし，今後はそれ以外の選択肢はないと思います． --- 風間 一洋 (kazama ＠ mac.com) From ogwata ＠ wb4.so-net.ne.jp Mon Apr 3 11:57:52 2006 From: ogwata ＠ wb4.so-net.ne.jp (Ogata Katsuhiro) Date: Mon, 3 Apr 2006 11:57:52 +0900 Subject: [LE-talk-ja 11] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TIA==?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: References: <20060323132320.DBAA.MORIYAMA@miraclelinux.com> <20060330092037.GA16364%numata@jp.fujitsu.com> <20060331130203.B34F.MORIYAMA@miraclelinux.com> <9B01E1C5-DE0B-4523-9635-C258F283C05E@wb4.so-net.ne.jp> Message-ID: <5694AC2E-6E7D-4E9F-B26E-4A4A6F6FA7AD@wb4.so-net.ne.jp> 風間さん 委員でもないのに、絡んですみません（笑）。 On 2006/04/03, at 11:40, Kazuhiro Kazama wrote: > 今後，日本として「7ビット及び8ビットの2バイト > 情報交換用符合化漢字集合」の新たな開発や保守は行わないということ > だと理解しています． なるほど、「廃止」というよりは「確認」ですね。 それならば納得です。 ただ、JIS X 0213:2004では 今後の課題として「JIS X 0208とJIS X 0213の不整合の解消」が あげられていたんだよなあ、とこれは独り言。 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 小形克宏 (うさぱら有限会社)/ Ogata Katsuhiro (USAPARA corp.) ogwata ＠ wb4.so-net.ne.jp From msyk ＠ mtg.biglobe.ne.jp Tue Apr 4 17:04:31 2006 From: msyk ＠ mtg.biglobe.ne.jp (MORIYAMA Masayuki) Date: Tue, 4 Apr 2006 17:04:31 +0900 (JST) Subject: [LE-talk-ja 12] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TIA==?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <5109A252-E400-4C90-9F50-D562670351AF@mac.com> References: <442E02A3.5020704@mtg.biglobe.ne.jp> <5109A252-E400-4C90-9F50-D562670351AF@mac.com> Message-ID: <20060404130547.B376.MSYK@mtg.biglobe.ne.jp> 森山です。 On Mon, 3 Apr 2006 13:03:33 +0900 Kazuhiro Kazama wrote: > On 2006/04/01, at 13:33, MORIYAMA Masayuki wrote: > > MUA に関しては、UTF-8 対応が進んできているので、 > > RFC1468 の ISO-2022-JP > > に変換できない文字が使われた場合には、UTF-8 でメール送信 > > する事は現実的な > > 解決策の一つだという事には異論はありません。 > > その通りだと思っています． > > > ただし、MUA の都合だけで、文字コード変換の実装を行ってし > > まうと、「テキス > > トエディタでの利用の場合に、問題が生じるでしょう」という事を書 > > きました。 > > そもそもテキストエディタで，ISO-2022-JP-MSを使わなければい > けないケースって，どのくらいあるのでしょうか？ 逆に、ISO-2022-JP-MS がメールのやりとりにだけしか使われないという保障 があるのか? と考えると、MUA 依存の実装を行う事は、テキストエディタでの 利用の場合のように弊害があるので、避けたいところです。 > > 扱える文字数に関しては、風間さんの意図されている事が、どういう > > 事なのか理 > > 解できませんでしたので、説明していただけると助かります。 > > 講演の質疑応答でも他の方からあった通り，一番主なのはJIS X > 0213対応だと思います．わざわざ収録文字数が少ない符号化文字集合を > 新たに提案する意味はないはずです． MUA で、メール受信の時だけ ISO-2022-JP-MS を使い、メール送信は必ず UTF-8 で行うという事になれば、ISO-2022-JP-MS を IANA Registry に登録す る必要は無くなると思います。 わざわざ、ISO-2022-JP-MS のようなものを定義しようとしているのは、 x-iso2022jp-cp932 では Windows 機種依存文字が扱えないという事と、 Windows の CP50220, CP50221, CP50222 のように複数のものを用意するとい うアイデアは良いとは思えなかった為です。 CP50220 互換の実装に関して、eucJP-ms を G0 集合のみを使う 7ビットJISコー ドにしたものが CP50220 であるという間違った理解に基づく実装が行われて たりするので、いつまでも非標準だからと、この問題に取り組まないでいると、 いろいろと不都合が生じてくるだろうと考えています。 > > ISO-2022-JP という名前で Windows の機種依存文字が扱える > > 拡張(CP50220 のサ > > ブセット?) を実装して使っているものとしては、Mozilla > > Thunderbird や > > Sylpheed などがあります。 > > > > 7ビットJISのエンコーディングで、Windows 機種依存文 > > 字を使える実装というの > > は増えてきていると感じています。 > > 逆に考えれば．Windows機種依存文字をUnicodeとして扱え > る実装は非常に沢山あるわけで，それに対してほとんど無視できるくら > いしか存在しないのでは？ 実装の数は少なくても、実際に利用されている絶対数という事では、無視でき ない数になると考えています。 メール送信の場合 極力、UTF-8 を使って送信するようにする。 メール受信の場合 現状では、ISO-2022-JP という名前で、CP50220 が送られてくることが多い ので ISO-2022-JP-MS で文字コード変換を行う。 という事で良いのであれば、MUA 開発者に負担を強いることなく、Windows 機 種依存文字を含むメールを受信でき、メール送信時には非標準のものを出さず に済むようになるでしょう。 > > 今までは、シフトJIS符号化方式の cp932 を、日本語 > > EUC符号化方式、7ビット > > JIS符号化方式との間で変換して扱う事が困難だったのを、変換して > > 使えるよう > > にするという事がポイントになります。 > > > > 「eucJP-ms と ISO-2022-JP-MS は、CP932 の全 > > 文字レパートリーを扱えま > > す。」と一言で言い表せますから、単純明快だと考えています。 > > いや，実は変換表の齟齬の問題があるから，そんなに簡単にはなりませ > ん． eucJP-ms, ISO-2022-JP-MS, CP932, CP51932 のそれぞれは、変換表の齟齬が 生じないようにします。 他の変換表で Unicode に変換したものを変換しようとすると問題が生じるで しょうけれども、CP932 と同じ変換表を使う ISO-2022-JP-MS といようなもの が無い事で、別の変換表の ISO-2022-JP を使ってしまって問題が生じるとい う類の問題は解消されると考えています。 > ここではっきり言いますが，文字のレパートリだけ考えるのはもう止め > ましょうよ．だって，これは既存の符号化文字集合をシステムでほぼ問 > 題なく扱えるようにする提案だと理解しています．そもそも，扱える文 > 字数はすでにオーソライズされているUTF-8より少なくなるのは > 確実なんですから． 既存の符号化文字集合を考える上で、文字レパートリ(Windows機種依存 文字)の問題を扱わないわけにはいかないと考えています。 > > cp51932 は、ユーザ定義文字を扱えませんが、Internet > > Expolorer や Mozilla > > Firefox が "EUC-JP" として POST してくる文字コード > > と互換があります。 > > > この「互換」というのも微妙だと思うんですが，eucJP-msでは問 > 題があるのでしょうか？CP51932が非常に普及しているのなら異 > 論がありません． IE で POST されてきた CP51932 を PostgreSQL の EUC_JP や MySQL の eucjpms でデータ格納したとします。そして、PostgreSQL や MySQL の文字コー ド変換で Unicode や CP932 で取り出すと、NEC選定IBM拡張文字がユーザ定義 文字に化けてしまうという問題があります。 どれほど普及しているのかまでは不明ですが、日本語EUC符号化方式で処理し、 そのまま HTML の入出力を行っているような Web アプリケーションでは、 CP51932 で多くのデータが蓄積されている可能性はあります。 Unicode ベースのシステムへ移行する段階になって、NEC選定IBM拡張文字が文 字化けする問題が発覚する事になるというケースが、今後出てくる事が予想さ れます。 > しかし，単に文字レパートリの問題で引っ張り出してきたのなら，意味 > はないと思います． 意味が無いとしても、最低限、eucJP-ms と cp51932 が別物であるという事を 明確化しておかないと、間違った理解に基づく開発が行われてしまう危険があ ります。 > > cp51932 を使えるようになると Windows 機種依存文字を扱う > > 必要のある Web-DB > > システムで日本語EUC符号化方式だけで処理する事ができるよ > > うになり、処理の > > 単純化が行えるようになります。 > > これはUnicodeベースのシステムの問題点を解決する提案だと理 > 解していますので，それならUTF-8などで扱える方が単純ですよ > ね．特にWebベースシステムを考えれば，UTF-8しか扱えな > いフレームワークなども多く普及していますし，符号化文字集合は > （iモードなどの特殊な場合を除けば），システム側で決定でき > る自由度があります． 個人的には、Windows 機種依存文字を日本語EUC符号化方式で扱うのはやめて おいた方が良いと考えているのですが、そのような考え方は一般的ではないよ うです。 > > どういった問題が発生するのか明らかにしていただければ、メリッ > > ト、デメリッ > > トを比較して検討する事が出来るようになると思います。 > > 「状況に応じて変換テーブルが変わるというのは，混乱をもたらす」書 > いてあるはずです．結局，開発者は必ずしもよくわかっていないで使う > ことが多いわけで，よく理解しないで非互換性があるコンバータを使う > ことは，別の問題をもたらすことがあります． > > なお，「できる」には，「そのままできる」と「できる選択肢が用意さ > れている」の二つのレベルがあることを考慮に入れるべきです．前者 > は，一旦普及したらそれをなくすことはできないので慎重に検討しなけ > ればいけません．問題が多く，使用が限られている部分などは，あえて > 入れないが，何らかの形で対処法は残しておくというのが，安全な方法 > でしょう． 選択肢が与えられずデフォルトで「そのままできる」ようにしてしまう事は問 題が多すぎるという事に異論ありません。 > たとえば，ISO-2022-JP-MSのような文字符号化に関しては， > Javaでも追加しようと検討したことがありますが，結局おこないません > でした．それは，まずそれがほぼ電子メール＝情報交換専用に使われる > のが明らかでありながら標準ではないことと，要求が少なかったことで > す． > しかし，それが必要な場合は理解していますので，コンバータを拡張す > るAPIを設計・追加しました．実際に，某超大手Webメール > システムに相談された時には，独自にコンバータを追加するようにアド > バイスし，そこではWindowsの機種依存文字は扱えるようになっ > ています． 必要とされるケースがごくまれなのであれば、そのような対処でも良いのでしょ うけれども、日本語のメールを扱うケースでは、Windows 機種依存文字を扱わ ない訳にはいかないという現実があるので、個別に独自のコンバータを追加し て使うという事だと敷居が高いように感じます。 Java では、次のようなものが開発されているようなので、独自のコンバータ を開発する余裕がない場合など、こういったものを利用すれば良いのか… プロジェクト: Windows Japanese Charsets for Java http://sourceforge.jp/projects/wjc4j/ 概要 Windows で使用されるコードページ51932(EUC-JP) および コードページ50220、 50221、50222(ISO-2022-JP)を J2SE1.4以降で使えるようにします。 > また，ISO-2022-JP-MSとeucJP-msは少々意味が異なると > 思っています．前者は明らかに情報交換専用でありながら非標準で，す > でにより優れた代替があるのに対して，後者はシステム内で使われるも > のであることです． > > とにかく，一覧表を書いてしまうと，つい空いている部分をとにかく埋 > めたくなってしまう（笑）ものですが，まずそれがどのような意味を > 持っているかを考えることが必要だと思います． 一覧表に空きがある事、どうして空きがあるのかという事、そして空きがある 部分に関して、どのような処理を行うのが適切なのか? といった事が周知徹底 されていない為、落とし穴にはまる人が後を断たないように思います。 ‖森山 将之 (MORIYAMA Masayuki) ‖e-mail: msyk ＠ mtg.biglobe.ne.jp ‖ moriyama ＠ miraclelinux.com From kazama ＠ mac.com Tue Apr 4 18:37:53 2006 From: kazama ＠ mac.com (Kazuhiro Kazama) Date: Tue, 4 Apr 2006 18:37:53 +0900 Subject: [LE-talk-ja 13] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TIA==?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <20060404130547.B376.MSYK@mtg.biglobe.ne.jp> References: <442E02A3.5020704@mtg.biglobe.ne.jp> <5109A252-E400-4C90-9F50-D562670351AF@mac.com> <20060404130547.B376.MSYK@mtg.biglobe.ne.jp> Message-ID: <682059D7-3F32-47A4-843C-8CC5517179FE@mac.com> On 2006/04/04, at 17:04, MORIYAMA Masayuki wrote: >>> ただし、MUA の都合だけで、文字コード変換の実装を行ってし >>> まうと、「テキス >>> トエディタでの利用の場合に、問題が生じるでしょう」という事を書 >>> きました。 >> >> そもそもテキストエディタで，ISO-2022-JP-MSを使わなければい >> けないケースって，どのくらいあるのでしょうか？ > > 逆に、ISO-2022-JP-MS がメールのやりとりにだけしか使われないという保障 > があるのか? と考えると、MUA 依存の実装を行う事は、テキストエディタでの > 利用の場合のように弊害があるので、避けたいところです。 ということは，現在そのような符号化文字集合はエディタで使われれている例 は示せないということですね． では，現在新しい7ビット及び8ビットの2バイト情報交換用符合化漢字集合は 新たに作成しないという合意を覆すまでの必要はないという結論になります． > MUA で、メール受信の時だけ ISO-2022-JP-MS を使い、メール送信は必ず > UTF-8 で行うという事になれば、ISO-2022-JP-MS を IANA Registry に登録す > る必要は無くなると思います。 というか，メールの送受信をUTF-8でおこなってしまえばよいのでは？ もちろん，それだと修正が必要なソフトウェアがある可能性はありますが，そ れは国際的な方向性に一致した，必要なものだと思います． それで，現在の話では，同じ言語を喋る人間からさえ批判が出てくるのですか ら，IANA Registryへの登録は不可能でしょう． > わざわざ、ISO-2022-JP-MS のようなものを定義しようとしているのは、 > x-iso2022jp-cp932 では Windows 機種依存文字が扱えないという事と、 > Windows の CP50220, CP50221, CP50222 のように複数のものを用意するとい > うアイデアは良いとは思えなかった為です。 > CP50220 互換の実装に関して、eucJP-ms を G0 集合のみを使う 7ビットJIS > コー > ドにしたものが CP50220 であるという間違った理解に基づく実装が行われて > たりするので、いつまでも非標準だからと、この問題に取り組まないでいる > と、 > いろいろと不都合が生じてくるだろうと考えています。 だから，そのような用途にはUTF-8があれば十分ではないですか？ 新たな提案を行う時には，その必要性と，解決する問題などを明確に示さない といけません．しかし，すでにオーソライズされているUTF-8の方が上位互換 の仕様であり，すでに提案する文字符号化が広く使われているという実例もな いようなら，合意を得るのは難しいと思います． > 実装の数は少なくても、実際に利用されている絶対数という事では、無視でき > ない数になると考えています。 「利用されている絶対数」と言っても，電子メールの場合を除いた場合には， ほぼゼロになるのではないですか？「アプリケーションを使っているユーザ 数」が「ある特定の符号化文字集合を使っているユーザ数」に等しいわけでは ありません． > eucJP-ms, ISO-2022-JP-MS, CP932, CP51932 のそれぞれは、変換表の齟齬が > 生じないようにします。 > > 他の変換表で Unicode に変換したものを変換しようとすると問題が生じるで > しょうけれども、CP932 と同じ変換表を使う ISO-2022-JP-MS といようなもの > が無い事で、別の変換表の ISO-2022-JP を使ってしまって問題が生じるとい > う類の問題は解消されると考えています。 現時点では必要性，将来性，使用実績ともに不十分ですから，ISO-2022-JP-MS を情報交換用として新たに認めて貰うのはたぶん不可能です．で，電子メール 用が難しいとしたら，使われないわけですから，問題は起こらないと思います． > 既存の符号化文字集合を考える上で、文字レパートリ(Windows機種依存 > 文字)の問題を扱わないわけにはいかないと考えています。 基本的には，既存の文字符号化集合をそのまま扱えばよいだけで，パズルゲー ム的な遊びをする必要はないでしょう． > IE で POST されてきた CP51932 を PostgreSQL の EUC_JP や MySQL の > eucjpms でデータ格納したとします。そして、PostgreSQL や MySQL の文字 > コー > ド変換で Unicode や CP932 で取り出すと、NEC選定IBM拡張文字がユーザ定義 > 文字に化けてしまうという問題があります。 > > どれほど普及しているのかまでは不明ですが、日本語EUC符号化方式で処理 > し、 > そのまま HTML の入出力を行っているような Web アプリケーションでは、 > CP51932 で多くのデータが蓄積されている可能性はあります。 頭の中で考えた可能性ではなく，実例を示して頂けると幸いです．実例が一番 強いので． > Unicode ベースのシステムへ移行する段階になって、NEC選定IBM拡張文字が文 > 字化けする問題が発覚する事になるというケースが、今後出てくる事が予想さ > れます。 ただ何度も言うけど，Unicodeベースのシステムが前提なら，たとえばUTF-8な らその問題は起こらないのでは？ ＃　別の問題が起こりますが（笑） >> しかし，単に文字レパートリの問題で引っ張り出してきたのなら，意味 >> はないと思います． > > 意味が無いとしても、最低限、eucJP-ms と cp51932 が別物であるという事を > 明確化しておかないと、間違った理解に基づく開発が行われてしまう危険があ > ります。 実際にどのように使われていて，どのような問題が起こるかを，明確化する必 要はあると思います． > 個人的には、Windows 機種依存文字を日本語EUC符号化方式で扱うのはやめて > おいた方が良いと考えているのですが、そのような考え方は一般的ではないよ > うです。 あなたが一般的ではないだけで，すでに世界的には一般的だと思いますし，そ れはMSの方針でもあれば，日本の方針でもあります． それで，もし本当にUTF-8でWindows機種依存文字を扱って問題があるとした ら，その例を挙げてください．それは重要です． > 必要とされるケースがごくまれなのであれば、そのような対処でも良いので > しょ > うけれども、日本語のメールを扱うケースでは、Windows 機種依存文字を扱わ > ない訳にはいかないという現実があるので、個別に独自のコンバータを追加し > て使うという事だと敷居が高いように感じます。 標準ではない・将来的にもならないのなら，敷居が高くなるべきでは？ もちろん，標準になったとしたら，敷居を低くすべきです． それで，どうしてももし私の意見に納得ができないのなら，勝手に作業を始め るまえにIANAやIETFに問い合わせてみる方がいいのでは？それで合意が取れれ ば，問題ないと思いますので．また，それで却下されれば，さすがに納得でき ますよね？ > 一覧表に空きがある事、どうして空きがあるのかという事、そして空きがある > 部分に関して、どのような処理を行うのが適切なのか? といった事が周知徹底 > されていない為、落とし穴にはまる人が後を断たないように思います。 今回のプロジェクトは，それを周知徹底すると聞いていますが． 落とし穴にはまらないためには，できる限り日本固有の文字符号化を複雑にし ないということが重要だと思います． 最後に，日本国内で国際的な方針に逆らったゲリラ活動をするごく少数の人物 のおかげで，日本人全体が批判される不幸なことだけは起こさないようにして 欲しいと思います． --- 風間 一洋 (kazama ＠ mac.com) From moriyama ＠ miraclelinux.com Wed Apr 5 21:20:11 2006 From: moriyama ＠ miraclelinux.com (MORIYAMA Masayuki) Date: Wed, 5 Apr 2006 21:20:11 +0900 (JST) Subject: [LE-talk-ja 13] Re: ISO-2022-JP-MS =?UTF-8?B?44Gr44Gk44GE44Gm?= In-Reply-To: <682059D7-3F32-47A4-843C-8CC5517179FE@mac.com> References: <20060404130547.B376.MSYK@mtg.biglobe.ne.jp> <682059D7-3F32-47A4-843C-8CC5517179FE@mac.com> Message-ID: <20060405115031.B383.MORIYAMA@miraclelinux.com> 森山です。 ○ ISO-2022-JP-MS で非対称な変換を行う事に関して > > 逆に、ISO-2022-JP-MS がメールのやりとりにだけしか使われないという保障 > > があるのか? と考えると、MUA 依存の実装を行う事は、テキストエディタでの > > 利用の場合のように弊害があるので、避けたいところです。 > > ということは，現在そのような符号化文字集合はエディタで使われれている例 > は示せないということですね． > > では，現在新しい7ビット及び8ビットの2バイト情報交換用符合化漢字集合は > 新たに作成しないという合意を覆すまでの必要はないという結論になります． ISO-2022-JP-MS の実装に関して、Unicode へ変換する時には、Windows 機種 依存文字を変換するようにし、Unicode から 7ビットJISコードに変換する際 には、US-ASCII と JIS X 0208:1997 だけを変換するようにする。 ISO-2022-JP として認められていない文字が含まれている場合は、変換できな いようにしておくという事であれば、合意を覆すわけではないから良いという 事になるでしょうか? ○ MUA でのメール送受信について > > MUA で、メール受信の時だけ ISO-2022-JP-MS を使い、メール送信は必ず > > UTF-8 で行うという事になれば、ISO-2022-JP-MS を IANA Registry に登録す > > る必要は無くなると思います。 > > というか，メールの送受信をUTF-8でおこなってしまえばよいのでは？ メールの送受信ともに UTF-8 にすれば問題ないという事に異論はありません。 実際に、問題になるのは、完全に UTF-8 環境に移行するまでの間、 ISO-2022-JP という名前で Windows 機種依存文字を含むメールを受信した時 の話で、その場合、どうしたら良いのか、良いアイディアはあるでしょうか? ○ eucJP-ms と cp51932 の違いに起因する問題 次の図に示すように、Webブラウザ ⇔ PHP ⇔ MySQL (5.0.3以降) というパス で CP51932 が処理されている場合は、一見問題なく動作しているように見え ますが、右側のパスのように eucjpms を cp932 に文字コード変換して表示さ せるなどすると、文字化けが発生します。 '?' を POST '?' で表示される '・' で表示される。 ↓ ↑ ↑ +--------------------------------+ +--------------------------+ |Web ブラウザ (IE, Firefox など) | |MS-Access | | EUC-JP(CP51932) で表示 | | | | EUC-JP(CP51932) で POST | | | +--------------------------------+ +--------------------------+ │ ↑ ↑ 0xFCE2でPOST 0xFCE2 0xF3E0 (ユーザ定義文字) ↓ │ │ +--------------------------------+ +--------------------------+ |PHP | |MyODBC | | 内部エンコーディング = EUC-JP | | クライアント | | HTTP入力 = 無変換 | | エンコーディング = cp932| | HTTP出力 = 無変換 | +---------------------------+ +--------------------------------+ ↑ │ ↑ │ 0xFCE2でDBに格納 0xFCE2 │ ↓ │ │ +--------------------------------+ │ |MySQL |────────┘ | DBエンコーディング = eucjpms | +--------------------------------+ MySQL を直接操作して上記の現象を再現させる方法 ------------------------------------------------------------- TeraTerm Pro で文字コードを EUC に設定して以下の操作を行う。 # TeraTerm Pro の EUC は CP51932 モドキです。 # CP51932 の表示は可能ですが、NEC選定IBM拡張文字の入力が出来ません。 # SJIS->EUC の変換で CP932 の IBM拡張文字に対応していない為。 mysql> SET NAMES eucjpms; Query OK, 0 rows affected (0.00 sec) mysql> CREATE DATABASE eucjpms_db DEFAULT CHARACTER SET eucjpms; Query OK, 1 row affected (0.00 sec) mysql> USE eucjpms_db; Database changed mysql> CREATE TABLE eucjpms_table ( code TEXT, ch TEXT ); Query OK, 0 rows affected (0.08 sec) mysql> insert into eucjpms_table values( 'ADA1', '?' ); Query OK, 1 row affected (0.00 sec) mysql> INSERT INTO eucjpms_table VALUES ( 'FCE2', _eucjpms 0xFCE2 ); Query OK, 1 row affected (0.00 sec) mysql> SELECT code,HEX(ch) FROM eucjpms_table; +------+---------+ | code | HEX(ch) | +------+---------+ | ADA1 | ADA1 | | FCE2 | FCE2 | +------+---------+ 2 rows in set (0.00 sec) mysql> SELECT * FROM eucjpms_table; +------+------+ | code | ch | +------+------+ | ADA1 | ? | | FCE2 | ? | ← CP51932 で表示させると '?' に見えますが、eucJP-ms +------+------+ では、本来ユーザ定義文字。 2 rows in set (0.00 sec) TeraTerm Pro の文字コードを SJIS に設定しなおして次の操作を行う。 mysql> SET NAMES cp932; Query OK, 0 rows affected (0.00 sec) mysql> SELECT * FROM eucjpms_table; +------+------+ | code | ch | +------+------+ | ADA1 | ? | | FCE2 | ? | ← 元々、eucjpms でユーザ定義文字だったものが正しく表示 +------+------+ されるようになっただけ。 2 rows in set (0.00 sec) mysql> SELECT code,HEX(CONVERT(ch using cp932)) FROM eucjpms_table; +------+------------------------------+ | code | HEX(CONVERT(ch USING cp932)) | +------+------------------------------+ | ADA1 | 8740 | | FCE2 | F3E0 | +------+------------------------------+ 2 rows in set (0.01 sec) ------------------------------------------------------------- eucJP-ms と cp51932 が別物であるという認識が無いと、上記のような事 (CP51932 を eucjpms な DB に直接格納してしまう) をしてしまう危険性があ ります。 Web ブラウザからのアクセスだけであれば、文字化けしないという事で、問題 がある事に気が付いていない例は多いかもしれません。 -- 森山 将之 moriyama ＠ miraclelinux.com ミラクル・リナックス株式会社 From msyk ＠ mtg.biglobe.ne.jp Wed Apr 5 23:58:40 2006 From: msyk ＠ mtg.biglobe.ne.jp (MORIYAMA Masayuki) Date: Wed, 05 Apr 2006 23:58:40 +0900 Subject: [LE-talk-ja 15] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TIA==?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <20060405115031.B383.MORIYAMA@miraclelinux.com> References: <20060404130547.B376.MSYK@mtg.biglobe.ne.jp> <682059D7-3F32-47A4-843C-8CC5517179FE@mac.com> <20060405115031.B383.MORIYAMA@miraclelinux.com> Message-ID: <4433DB20.8090104@mtg.biglobe.ne.jp> 森山です。 メーリングリストでは、いろいろな環境でメールを読んでいるので、確認せずに UTF-8 でメールしていまった事で、読めなかった方がいるかもしれませんので、 ISO-2022-JP で再送します。 「UTF-8 のメールが読めなかった」という方は、moriyama ＠ miraclelinux.com まで 連絡していただけないでしょうか。よろしくお願いいたします。 MORIYAMA Masayuki wrote: > 森山です。 > > ○ ISO-2022-JP-MS で非対称な変換を行う事に関して > > >>>逆に、ISO-2022-JP-MS がメールのやりとりにだけしか使われないという保障 >>>があるのか? と考えると、MUA 依存の実装を行う事は、テキストエディタでの >>>利用の場合のように弊害があるので、避けたいところです。 >> >>ということは，現在そのような符号化文字集合はエディタで使われれている例 >>は示せないということですね． >> >>では，現在新しい7ビット及び8ビットの2バイト情報交換用符合化漢字集合は >>新たに作成しないという合意を覆すまでの必要はないという結論になります． > > > ISO-2022-JP-MS の実装に関して、Unicode へ変換する時には、Windows 機種 > 依存文字を変換するようにし、Unicode から 7ビットJISコードに変換する際 > には、US-ASCII と JIS X 0208:1997 だけを変換するようにする。 > ISO-2022-JP として認められていない文字が含まれている場合は、変換できな > いようにしておくという事であれば、合意を覆すわけではないから良いという > 事になるでしょうか? > > ○ MUA でのメール送受信について > > >>>MUA で、メール受信の時だけ ISO-2022-JP-MS を使い、メール送信は必ず >>>UTF-8 で行うという事になれば、ISO-2022-JP-MS を IANA Registry に登録す >>>る必要は無くなると思います。 >> >>というか，メールの送受信をUTF-8でおこなってしまえばよいのでは？ > > > メールの送受信ともに UTF-8 にすれば問題ないという事に異論はありません。 > > 実際に、問題になるのは、完全に UTF-8 環境に移行するまでの間、 > ISO-2022-JP という名前で Windows 機種依存文字を含むメールを受信した時 > の話で、その場合、どうしたら良いのか、良いアイディアはあるでしょうか? > > ○ eucJP-ms と cp51932 の違いに起因する問題 > > 次の図に示すように、Webブラウザ ⇔ PHP ⇔ MySQL (5.0.3以降) というパス > で CP51932 が処理されている場合は、一見問題なく動作しているように見え > ますが、右側のパスのように eucjpms を cp932 に文字コード変換して表示さ > せるなどすると、文字化けが発生します。 以下の「(1)」は、「丸付き数字1」、「高」は、「はしご高」と読みかえてください。 > > '高' を POST '高' で表示される '・' で表示される。 > ↓ ↑ ↑ > +--------------------------------+ +--------------------------+ > |Web ブラウザ (IE, Firefox など) | |MS-Access | > | EUC-JP(CP51932) で表示 | | | > | EUC-JP(CP51932) で POST | | | > +--------------------------------+ +--------------------------+ > │ ↑ ↑ > 0xFCE2でPOST 0xFCE2 0xF3E0 (ユーザ定義文字) > ↓ │ │ > +--------------------------------+ +--------------------------+ > |PHP | |MyODBC | > | 内部エンコーディング = EUC-JP | | クライアント | > | HTTP入力 = 無変換 | | エンコーディング = cp932| > | HTTP出力 = 無変換 | +---------------------------+ > +--------------------------------+ ↑ > │ ↑ │ > 0xFCE2でDBに格納 0xFCE2 │ > ↓ │ │ > +--------------------------------+ │ > |MySQL |────────┘ > | DBエンコーディング = eucjpms | > +--------------------------------+ > > MySQL を直接操作して上記の現象を再現させる方法 > ------------------------------------------------------------- > TeraTerm Pro で文字コードを EUC に設定して以下の操作を行う。 > > # TeraTerm Pro の EUC は CP51932 モドキです。 > # CP51932 の表示は可能ですが、NEC選定IBM拡張文字の入力が出来ません。 > # SJIS->EUC の変換で CP932 の IBM拡張文字に対応していない為。 > > mysql> SET NAMES eucjpms; > Query OK, 0 rows affected (0.00 sec) > > mysql> CREATE DATABASE eucjpms_db DEFAULT CHARACTER SET eucjpms; > Query OK, 1 row affected (0.00 sec) > > mysql> USE eucjpms_db; > Database changed > mysql> CREATE TABLE eucjpms_table ( code TEXT, ch TEXT ); > Query OK, 0 rows affected (0.08 sec) > > mysql> insert into eucjpms_table values( 'ADA1', '(1)' ); > Query OK, 1 row affected (0.00 sec) > > mysql> INSERT INTO eucjpms_table VALUES ( 'FCE2', _eucjpms 0xFCE2 ); > Query OK, 1 row affected (0.00 sec) > > mysql> SELECT code,HEX(ch) FROM eucjpms_table; > +------+---------+ > | code | HEX(ch) | > +------+---------+ > | ADA1 | ADA1 | > | FCE2 | FCE2 | > +------+---------+ > 2 rows in set (0.00 sec) > > mysql> SELECT * FROM eucjpms_table; > +------+------+ > | code | ch | > +------+------+ > | ADA1 | (1) | > | FCE2 | 高 | ← CP51932 で表示させると'高' に見えますが、eucJP-ms > +------+------+ では、本来ユーザ定義文字。 > 2 rows in set (0.00 sec) > > TeraTerm Pro の文字コードを SJIS に設定しなおして次の操作を行う。 > > mysql> SET NAMES cp932; > Query OK, 0 rows affected (0.00 sec) > > mysql> SELECT * FROM eucjpms_table; > +------+------+ > | code | ch | > +------+------+ > | ADA1 | (1) | > | FCE2 | ・ | ← 元々、eucjpms でユーザ定義文字だったものが正しく表示 > +------+------+ されるようになっただけ。 > 2 rows in set (0.00 sec) > > mysql> SELECT code,HEX(CONVERT(ch using cp932)) FROM eucjpms_table; > +------+------------------------------+ > | code | HEX(CONVERT(ch USING cp932)) | > +------+------------------------------+ > | ADA1 | 8740 | > | FCE2 | F3E0 | > +------+------------------------------+ > 2 rows in set (0.01 sec) > ------------------------------------------------------------- > > eucJP-ms と cp51932 が別物であるという認識が無いと、上記のような事 > (CP51932 を eucjpms な DB に直接格納してしまう) をしてしまう危険性があ > ります。 > > Web ブラウザからのアクセスだけであれば、文字化けしないという事で、問題 > がある事に気が付いていない例は多いかもしれません。 > > -- > 森山 将之 moriyama ＠ miraclelinux.com > ミラクル・リナックス株式会社 > > _______________________________________________ > Legacy-Encoding-talk-ja mailing list > Legacy-Encoding-talk-ja ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/legacy-encoding-talk-ja From naruse ＠ airemix.com Thu Apr 6 03:04:08 2006 From: naruse ＠ airemix.com (NARUSE, Yui) Date: Thu, 06 Apr 2006 03:04:08 +0900 Subject: [LE-talk-ja 16] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TIA==?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <4433DB20.8090104@mtg.biglobe.ne.jp> References: <20060404130547.B376.MSYK@mtg.biglobe.ne.jp> <682059D7-3F32-47A4-843C-8CC5517179FE@mac.com> <20060405115031.B383.MORIYAMA@miraclelinux.com> <4433DB20.8090104@mtg.biglobe.ne.jp> Message-ID: <44340698.7070206@airemix.com> はじめまして、成瀬と申します。 わたしは Legacy Encoding Project でターゲットに挙げられている、 nkf、Ruby/NKF、Encode::EUCJPMS をメンテナンスしています。 OSC2006 発表資料にもある通り、 これらではすでにこのプロジェクトとは独立に CP932, CP51932, eucJP-ms には対応しておりまして、 この作業はそれなりに考えがあって行ったのですが、それについて。 わたしは今更レガシーエンコーディングに対応する必要性は、 ただ過去の資産の継承及び、 既存システムが残っている間の相互運用だと考えています。 そこで、日本語テキストを扱う場合に、 過去の資産及びシステムが使っている文字コードは、 * ISO-2022-JP * Shift_JIS * CP932 * EUC-JP * eucJP-ms * CP51932 だと考えました。 CP932 が Shift_JIS と別にあるのは、 * CSS が CP932 の方が大きい * Unicode との対応が異なる * そのような CP932 を用いた資産が相当数存在する からです。 同様に、CP51932 は、 * CSS が EUC-JP と異なる * eucJP-ms には CSS 的に含まれるが、 CP51932 の NEC選定IBM拡張文字 の領域が eucJP-ms ではユーザ定義文字 * よって、CP51932 のテキストを eucJP-ms とみなすと化ける $ perl -e'print"\xEE\xEC"'| iconv -f cp932 -t cp51932 \ | iconv -f euc-jp -t cp932 -> iconv: (stdin):1:0: cannot convert $ perl -e'print"\xEE\xEC"'| iconv -f cp932 -t cp51932 \ |iconv -f eucJP-ms -t cp932 　-> 化ける * Unicode との対応が異なる (eucJP-ms とも一部異なる) * そのような CP51932 を用いた資産が相当数存在する (IEから投げられた「日本語 (EUC)」をそのまま保存しているシステム） という理由からこれも追加しました。 同様に、eucJP-ms も MySQL 周辺をはじめとして用いられているので、 これを追加しました。 風間さんはこの CP932, CP51932, eucJP-ms も必要ないし、 ユーザは使い分けることが難しいと考えていらっしゃるようですが、 eucjpms を Google で検索して 17000 件ヒットすることからも考えて、 相当の人が必要性を感じ、使い分けていると考えます。 （CP51932 はまだ少ないですが、今後 UTF-8 への移行の過程で、 　はまった人の blog 等がひっかかるようになると予想します） 一方で今回提案された ISO-2022-JP-MS は、 * CSS が ISO-2022-JP (RFC1468) と異なる * そのような「ISO-2022-JP-MS で扱える符号化文字列」の 資産は相当数存在する ため、その類のものに対する必要性は一定あるでしょう。 （例えばMLのアーカイブの Unicode 化に用いる） しかし、それならば CP502xx で十分でしょう。 ユーザ定義文字が ISO 2022 から逸脱するのは、 確かに問題だとも思いますが、 すでに逸脱した形でエンコードされたデータが 相当数存在するシステムで用いられるのですし、 ユーザ定義文字を出力しない CP50221 でいい気もします。 ユーザ定義文字をメールで送信するために、 当事者同士で合意の上 ISO-2022-JP-MS で送る余裕があるのならば、 CP932 で添付ファイルにするなり、UTF-8 で送るべき、 というのは当然の批判でしょう。 ISO-2022-JP-MS の謳う、CP932 との相互運用性は、 レガシーエンコーディングへの対応意義である、 「過去の資産の継承」からは外れるのではないか、 というのがわたしの考えです。 -- NARUSE, Yui DBDB A476 FDBD 9450 02CD 0EFC BCE3 C388 472E C1EA From yw3t-trns ＠ asahi-net.or.jp Thu Apr 6 04:52:47 2006 From: yw3t-trns ＠ asahi-net.or.jp (Tadamasa Teranishi) Date: Thu, 06 Apr 2006 04:52:47 +0900 Subject: [LE-talk-ja 17] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TICA=?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= References: <20060404130547.B376.MSYK@mtg.biglobe.ne.jp> <682059D7-3F32-47A4-843C-8CC5517179FE@mac.com> <20060405115031.B383.MORIYAMA@miraclelinux.com> <4433DB20.8090104@mtg.biglobe.ne.jp> <44340698.7070206@airemix.com> Message-ID: <4434200F.71140409@asahi-net.or.jp> 寺西です。 "NARUSE, Yui" wrote: > > そこで、日本語テキストを扱う場合に、 > 過去の資産及びシステムが使っている文字コードは、 > * ISO-2022-JP > * Shift_JIS > * CP932 > * EUC-JP > * eucJP-ms > * CP51932 > > だと考えました。 んー。どうでしょうね。意見は割れるところではないかと思います。 > * そのような CP51932 を用いた資産が相当数存在する > (IEから投げられた「日本語 (EUC)」をそのまま保存しているシステム） > という理由からこれも追加しました。 それが CP51932 でなければならないとか、そのまま CP51932 として 生かさないといけないのかというところには疑問が残ります。 私は > 風間さんはこの CP932, CP51932, eucJP-ms も必要ないし、 必要ないかどうかはともかく、 > ユーザは使い分けることが難しいと考えていらっしゃるようですが、 そう思いますよ。 > eucjpms を Google で検索して 17000 件ヒットすることからも考えて、 > 相当の人が必要性を感じ、使い分けていると考えます。 この数が多いととるか、少ないととるかでこれも意見が割れるのでは ないかと思います。 eucjp-ms なら 31,600件ヒットします。 ...が、私の名前の寺西忠勝でも、29,400件ヒットします。(名前が変わって いるので同姓同名はそう多くはいません。) ヒット数だけでは何とも判断がつかないのではないでしょうか? 相当の人が必要性を感じ、使い分けているとはどうも思えませんし、 その根拠にgoogleのヒット数を出すのでは、説得力にかけます。 普通の人は、中身を理解して使い分けたりしていないでしょう。 eucjp-ms Samba で検索すると 11,300件ですし、条件反射的に使っている 人も多いかと思われます。 > （CP51932 はまだ少ないですが、今後 UTF-8 への移行の過程で、 > 　はまった人の blog 等がひっかかるようになると予想します） まぁ、それはあるでしょうけど、それを救うことにどれほどの意味が あるのか疑問が残ります。 # そんなことを言ってはいけないのかもしれませんが。 > ユーザ定義文字をメールで送信するために、 > 当事者同士で合意の上 ISO-2022-JP-MS で送る余裕があるのならば、 > CP932 で添付ファイルにするなり、UTF-8 で送るべき、 > というのは当然の批判でしょう。 メールに限らず UTF-8 化に力を注ぐほうが、より健全だろうと思います。 -- ===================================================================== 寺西 忠勝(TADAMASA TERANISHI) yw3t-trns ＠ asahi-net.or.jp http://www.asahi-net.or.jp/~yw3t-trns/index.htm Key fingerprint = 474E 4D93 8E97 11F6 662D 8A42 17F5 52F4 10E7 D14E From nozomi ＠ biol.tsukuba.ac.jp Thu Apr 6 08:47:15 2006 From: nozomi ＠ biol.tsukuba.ac.jp (Nozomi Ytow) Date: Thu, 06 Apr 2006 08:47:15 +0900 (JST) Subject: [LE-talk-ja 18] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TIA==?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <4433DB20.8090104@mtg.biglobe.ne.jp> References: <682059D7-3F32-47A4-843C-8CC5517179FE@mac.com> <20060405115031.B383.MORIYAMA@miraclelinux.com> <4433DB20.8090104@mtg.biglobe.ne.jp> Message-ID: <20060406.084715.78709645.nozomi@biol.tsukuba.ac.jp> 何をしたいのかわからないので黙って見て(あるいは見ないで)いましたが... MORIYAMA Masayuki wrote: > 「UTF-8 のメールが読めなかった」という方は、moriyama ＠ miraclelinux.com まで > 連絡していただけないでしょうか。よろしくお願いいたします。 連絡する目的は何でしょう。 私の環境では一部正しい字形では表示されませんでしたが、 意図してそう設定しているので気にしていません。 > 実際に、問題になるのは、完全に UTF-8 環境に移行するまでの間、 > ISO-2022-JP という名前で Windows 機種依存文字を含むメールを受信した時 > の話で、その場合、どうしたら良いのか、良いアイディアはあるでしょうか? ゲタを表示するのが活版印刷由来の伝統ではないかと思います。 -- 伊藤 希(のぞみ) From moriyama ＠ miraclelinux.com Thu Apr 6 10:07:56 2006 From: moriyama ＠ miraclelinux.com (MORIYAMA Masayuki) Date: Thu, 6 Apr 2006 10:07:56 +0900 (JST) Subject: [LE-talk-ja 19] =?iso-2022-jp?b?GyRCJWEhPCVqJXMlMCVqJTklSCRHGyhC?= =?iso-2022-jp?b?GyRCJE4bKEIgVVRGLTggGyRCJWEhPCVrJEskRCQkJEYbKEI=?= Message-ID: <20060406092559.B38B.MORIYAMA@miraclelinux.com> 森山です。 このメールリストで、UTF-8 でメールを扱う事について事前に取り決めしてい ない状態で UTF-8 でメールを送ってしまい、一部の方にはご迷惑をおかけし て申し訳ありませんでした。 将来的に、UTF-8 への移行が必要であるとしても、メーリングリストのように 不特定多数の方が読まれているところで、事前のアナウンスなしに利用すれば、 UTF-8 のメールを読む準備の出来ていない環境でメールを読んでいる場合もあ る事が想定できるわけですから、問題が起きてしまうという事への配慮が足り ませんでした。 数名の方から UTF-8 のメールが読めなかったという連絡を頂きました。 ISP の SPAM フィルタに引っかかって届かなかったという例もあり、利用者の 環境が整っているだけでは駄目なケースもあるのだと認識した次第です。 -- 森山 将之 moriyama ＠ miraclelinux.com ミラクル・リナックス株式会社 From naruse ＠ airemix.com Thu Apr 6 11:22:58 2006 From: naruse ＠ airemix.com (NARUSE, Yui) Date: Thu, 06 Apr 2006 11:22:58 +0900 Subject: [LE-talk-ja 20] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TIA==?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <4434200F.71140409@asahi-net.or.jp> References: <20060404130547.B376.MSYK@mtg.biglobe.ne.jp> <682059D7-3F32-47A4-843C-8CC5517179FE@mac.com> <20060405115031.B383.MORIYAMA@miraclelinux.com> <4433DB20.8090104@mtg.biglobe.ne.jp> <44340698.7070206@airemix.com> <4434200F.71140409@asahi-net.or.jp> Message-ID: <44347B82.4070109@airemix.com> 成瀬です。 Tadamasa Teranishi wrote: > "NARUSE, Yui" wrote: >> そこで、日本語テキストを扱う場合に、 >> 過去の資産及びシステムが使っている文字コードは、 >> * ISO-2022-JP >> * Shift_JIS >> * CP932 >> * EUC-JP >> * eucJP-ms >> * CP51932 >> >> だと考えました。 > > んー。どうでしょうね。意見は割れるところではないかと思います。 三つでいいとか、逆にもっと必要だと考える方もいるでしょうね。 >> * そのような CP51932 を用いた資産が相当数存在する >> (IEから投げられた「日本語 (EUC)」をそのまま保存しているシステム） >> という理由からこれも追加しました。 > > それが CP51932 でなければならないとか、そのまま CP51932 として > 生かさないといけないのかというところには疑問が残ります。 NEC選定IBM拡張文字が 0xF9A1 から 0xFCFE になる文字コードは、 わたしは CP51932 しか知りませんが、 他にそのような文字コードがあるならばそれでもよいでしょうね。 他に無いならば eucJP-ms でなく、CP51932 でなければならないでしょう。 そのまま CP51932 として生かさないといけない、とは思っていません。 多少平行運用を行わなければならない場合もあるでしょうが、 多くの場合は、 nkf --overwrite --ic=CP51932 --oc=UTF-8 一回の利用だろうとは思っています。 >> ユーザは使い分けることが難しいと考えていらっしゃるようですが、 > > そう思いますよ。 うーん、MySQL 4.0 の時に CP932 相当が提供されず騒ぎになった記憶や、 Ruby に nkf-2 を取り込んだときに何人かから CP932 まわりで ツッコミを受けたりしたので、 少なくとも CP932 についてはわたしはニーズもあるし、 使い分けたい人がいると考えているのですけれど。 eucJP-ms についても、Perl Encode は対応しないのかという質問を、 ML も投稿者も異なるもので 4,5 件見てはいます。 けれど、説得力のあるニーズを示すデータは難しいですね。 > ヒット数だけでは何とも判断がつかないのではないでしょうか? > 相当の人が必要性を感じ、使い分けているとはどうも思えませんし、 > その根拠にgoogleのヒット数を出すのでは、説得力にかけます。 ごもっともな指摘だと思います。 しかし、他に「数字」が出る指標があるかというと、うーん。。。 はてなあたりで質問すれば数字は出せるでしょうが、 それも説得力に欠けそうですし。 > まぁ、それはあるでしょうけど、それを救うことにどれほどの意味が > あるのか疑問が残ります。 これは反論不可能ですね。 >> ユーザ定義文字をメールで送信するために、 >> 当事者同士で合意の上 ISO-2022-JP-MS で送る余裕があるのならば、 >> CP932 で添付ファイルにするなり、UTF-8 で送るべき、 >> というのは当然の批判でしょう。 > > メールに限らず UTF-8 化に力を注ぐほうが、より健全だろうと思います。 UTF-8 化の前提として、既存データの UTF-8 化が存在し、 それを行うのにレガシーエンコーディングと Unicode の対応表が、 ‘いくつか’必要である、というのがわたしの考えです。 過去のデータは全て捨ててしまえ・・・とは言いませんよね？ ＃システムは捨ててしまえ、というのもありでしょうが。 そのうえで、Shift_JIS だけでいいじゃんとか、 Shift_JIS と CP932 の違いは大きいよ、という話になるでしょう。 Java 方面で Shift_JIS がCP932 の alias になった騒ぎがありましたが、 騒ぎになる程度の違いは両者にある、と。 （これもまたえらく主観的ですが） -- NARUSE, Yui DBDB A476 FDBD 9450 02CD 0EFC BCE3 C388 472E C1EA From kazama ＠ mac.com Thu Apr 6 12:21:33 2006 From: kazama ＠ mac.com (Kazuhiro Kazama) Date: Thu, 6 Apr 2006 12:21:33 +0900 Subject: [LE-talk-ja 21] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TIA==?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <44340698.7070206@airemix.com> References: <20060404130547.B376.MSYK@mtg.biglobe.ne.jp> <682059D7-3F32-47A4-843C-8CC5517179FE@mac.com> <20060405115031.B383.MORIYAMA@miraclelinux.com> <4433DB20.8090104@mtg.biglobe.ne.jp> <44340698.7070206@airemix.com> Message-ID: <53C09C81-3421-49BE-B9AA-0D2860D18B6B@mac.com> On 2006/04/06, at 3:04, NARUSE, Yui wrote: > 風間さんはこの CP932, CP51932, eucJP-ms も必要ないし、 > ユーザは使い分けることが難しいと考えていらっしゃるようですが、 まったく違います．もし，私が実際にそのようなことに言及している部分が あったら引用して頂けますか？ > 一方で今回提案された ISO-2022-JP-MS は、 > * CSS が ISO-2022-JP (RFC1468) と異なる > * そのような「ISO-2022-JP-MS で扱える符号化文字列」の > 資産は相当数存在する > ため、その類のものに対する必要性は一定あるでしょう。 > （例えばMLのアーカイブの Unicode 化に用いる） > しかし、それならば CP502xx で十分でしょう。 > > ISO-2022-JP-MS の謳う、CP932 との相互運用性は、 > レガシーエンコーディングへの対応意義である、 > 「過去の資産の継承」からは外れるのではないか、 > というのがわたしの考えです。 私も同じ意見です． --- 風間 一洋 (kazama ＠ mac.com) From kazama ＠ mac.com Thu Apr 6 13:01:53 2006 From: kazama ＠ mac.com (Kazuhiro Kazama) Date: Thu, 6 Apr 2006 13:01:53 +0900 Subject: [LE-talk-ja 22] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TIA==?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <44347B82.4070109@airemix.com> References: <20060404130547.B376.MSYK@mtg.biglobe.ne.jp> <682059D7-3F32-47A4-843C-8CC5517179FE@mac.com> <20060405115031.B383.MORIYAMA@miraclelinux.com> <4433DB20.8090104@mtg.biglobe.ne.jp> <44340698.7070206@airemix.com> <4434200F.71140409@asahi-net.or.jp> <44347B82.4070109@airemix.com> Message-ID: <84237377-E027-40B9-BE70-B5EA590FDD03@mac.com> On 2006/04/06, at 11:22, NARUSE, Yui wrote: >>> ユーザ定義文字をメールで送信するために、 >>> 当事者同士で合意の上 ISO-2022-JP-MS で送る余裕があるのならば、 >>> CP932 で添付ファイルにするなり、UTF-8 で送るべき、 >>> というのは当然の批判でしょう。 >> >> メールに限らず UTF-8 化に力を注ぐほうが、より健全だろうと思います。 > > UTF-8 化の前提として、既存データの UTF-8 化が存在し、 > それを行うのにレガシーエンコーディングと Unicode の対応表が、 > ‘いくつか’必要である、というのがわたしの考えです。 > > 過去のデータは全て捨ててしまえ・・・とは言いませんよね？ > ＃システムは捨ててしまえ、というのもありでしょうが。 > > そのうえで、Shift_JIS だけでいいじゃんとか、 > Shift_JIS と CP932 の違いは大きいよ、という話になるでしょう。 基本的には，レガシーエンコーディングしか扱えないシステムと，Unicode ベースのシステムが混在する際の問題は解決しなければいけないと考えていま すし，基本的にEUCやShift-JISの変種は主にその相互変換に使われると思って います． しかし，それとは関係ない部分で，単に扱える文字レパートリーを増やすこと が目的で新しい符号化文字集合をデファクト化しようとするとしたら違う話 で，別のよりよい方法がすでにオーソライズされている場合には，そちらを使 う方向の努力の方がよいと思います．たぶん，元の記事もそういう意図だと思 います． 少なくとも，「より多くの文字を扱いたい」は，日本を含めた漢字を扱うアジ ア圏の人間の願いなわけですが，それなら今はJIS X 0213は無視できないし， また従来の機種依存文字が，機種依存文字でない形で扱える，しかも従来は Windowsとは非互換の機種依存文字のマッピングを採用していたMac OS Xなど でも正しく表示できるということは重要だと思います． なお，顧客の強引な要求でどうしても危険な実装をしなければいけない時もあ るでしょう（今回指摘されたMozilla関係のOSSプロダクトで実際に実装したの は，たぶん元Netscapeの国際化部門の知りあいでしょう（笑））が，そのよう な特殊な要求に応じられるようにAPIを整備することは必要だと思いますが， その場合には危険な実装は局所化すべきでしょう． > Java 方面で Shift_JIS がCP932 の alias になった騒ぎがありましたが、 > 騒ぎになる程度の違いは両者にある、と。 > （これもまたえらく主観的ですが） それの騒ぎに関係したのは私だったりします（笑）． それで，結論ありきで議論を始めるよりも，まず既存の文字符号化を今よりさ らに詳しく分析して，その違いを明らかにすることが重要ではないかと思いま す．できれば，Unicodeへのマッピングが違う部分はどこなのかを一覧表にす るのは有効だと思います．また同じ符号化文字集合であってもOSSプロダクト によってマッピングが違うということはないかということも一度確認すること も必要な気がします． --- 風間 一洋 (kazama ＠ mac.com) From yw3t-trns ＠ asahi-net.or.jp Thu Apr 6 16:03:39 2006 From: yw3t-trns ＠ asahi-net.or.jp (Tadamasa Teranishi) Date: Thu, 06 Apr 2006 16:03:39 +0900 Subject: [LE-talk-ja 23] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TICA=?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= References: <20060404130547.B376.MSYK@mtg.biglobe.ne.jp> <682059D7-3F32-47A4-843C-8CC5517179FE@mac.com> <20060405115031.B383.MORIYAMA@miraclelinux.com> <4433DB20.8090104@mtg.biglobe.ne.jp> <44340698.7070206@airemix.com> <4434200F.71140409@asahi-net.or.jp> <44347B82.4070109@airemix.com> Message-ID: <4434BD4B.4C5DD39E@asahi-net.or.jp> 寺西です。 "NARUSE, Yui" wrote: > > > それが CP51932 でなければならないとか、そのまま CP51932 として > > 生かさないといけないのかというところには疑問が残ります。 > > NEC選定IBM拡張文字が 0xF9A1 から 0xFCFE になる文字コードは、 > わたしは CP51932 しか知りませんが、 > 他にそのような文字コードがあるならばそれでもよいでしょうね。 > 他に無いならば eucJP-ms でなく、CP51932 でなければならないでしょう。 現状、うまく使えていないであろう文字(おそらくは想定外の入力データ)を 生かす必要があるのかどうか。 もし、そのような文字を使いたいのであれば、そもそもアプリケーションを UTF-8 で設計すべきではないか、と思います。 どうしてもデータを生かしたいのなら > そのまま CP51932 として生かさないといけない、とは思っていません。 > 多少平行運用を行わなければならない場合もあるでしょうが、 > 多くの場合は、 > nkf --overwrite --ic=CP51932 --oc=UTF-8 > 一回の利用だろうとは思っています。 のように移行する際に1回データを変換するだけで良いような気がします。 それは代表的なコード変換プログラムがサポートしさえしておれば良く、 多くのアプリケーションがサポートしなければならないことではない ように思います。 > >> ユーザは使い分けることが難しいと考えていらっしゃるようですが、 > > > > そう思いますよ。 > > うーん、MySQL 4.0 の時に CP932 相当が提供されず騒ぎになった記憶や、 > Ruby に nkf-2 を取り込んだときに何人かから CP932 まわりで > ツッコミを受けたりしたので、 > 少なくとも CP932 についてはわたしはニーズもあるし、 > 使い分けたい人がいると考えているのですけれど。 CP932 と eucJP-ms と それ以外とではかなり事情が違うと思います。 CP932 に関しては Shift_JIS と使い分けているといえるでしょう。 しかし、それ以外はそうかどうかは疑問が残ります。 > けれど、説得力のあるニーズを示すデータは難しいですね。 ... > しかし、他に「数字」が出る指標があるかというと、うーん。。。 ようするに裏づけされたデータがないということで、なんとなくそうなん じゃないかという感覚的なものなのでしょう。 > > メールに限らず UTF-8 化に力を注ぐほうが、より健全だろうと思います。 > > UTF-8 化の前提として、既存データの UTF-8 化が存在し、 > それを行うのにレガシーエンコーディングと Unicode の対応表が、 > ‘いくつか’必要である、というのがわたしの考えです。 > > 過去のデータは全て捨ててしまえ・・・とは言いませんよね？ > ＃システムは捨ててしまえ、というのもありでしょうが。 過去のデータの全てを生かさなければならないとは思わないということです。 生かすデータを選別しても良いのではないかということです。 CP932 とかは生かさなければならないでしょうけど、CP51932 を生かさ なければならないか(個々の事情で生かさなければならない場合はあるで しょうけれども)というのは疑問です。 機種依存文字等を含む場合は、 UTF-8 への変換は移行する際に必要でも、UTF-8 からの変換は CP932 ぐらいに絞らないと余計混乱するのではないかと思います。 例えば、CP51932 や ISO-2022-JP-MS で出力するアプリケーションが増えて、 世の中にそのようなデータが増える方向に動きはしないかと懸念します。 (コード変換プログラムは除く) CP51932 や ISO-2022-JP-MS で出力する場合には、慎重に行うべきでしょう。 それよりは UTF-8 で処理する方向で動いて欲しいと願います。 ついでに。 シェアの問題でしょうけれども Windows のコード中心なのも気になります。 Macintosh は? とか、携帯電話の絵文字は? とかもあるわけです。 特に携帯電話は無視できる数ではないので、Windows のコードだけ考えて いても...という気もします。 -- ===================================================================== 寺西 忠勝(TADAMASA TERANISHI) yw3t-trns ＠ asahi-net.or.jp http://www.asahi-net.or.jp/~yw3t-trns/index.htm Key fingerprint = 474E 4D93 8E97 11F6 662D 8A42 17F5 52F4 10E7 D14E From naruse ＠ airemix.com Fri Apr 7 10:17:20 2006 From: naruse ＠ airemix.com (NARUSE, Yui) Date: Fri, 07 Apr 2006 10:17:20 +0900 Subject: [LE-talk-ja 24] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TIA==?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <53C09C81-3421-49BE-B9AA-0D2860D18B6B@mac.com> References: <20060404130547.B376.MSYK@mtg.biglobe.ne.jp> <682059D7-3F32-47A4-843C-8CC5517179FE@mac.com> <20060405115031.B383.MORIYAMA@miraclelinux.com> <4433DB20.8090104@mtg.biglobe.ne.jp> <44340698.7070206@airemix.com> <53C09C81-3421-49BE-B9AA-0D2860D18B6B@mac.com> Message-ID: <4435BDA0.1010506@airemix.com> 成瀬です。 Kazuhiro Kazama wrote: > On 2006/04/06, at 3:04, NARUSE, Yui wrote: >> 風間さんはこの CP932, CP51932, eucJP-ms も必要ないし、 >> ユーザは使い分けることが難しいと考えていらっしゃるようですが、 > > まったく違います．もし，私が実際にそのようなことに言及している部分が > あったら引用して頂けますか？ 以下を読んでそのような印象を持ったのですが、 だとすると ISO-2022-JP-MS 限定の話だったのですね、了解です。 >> Unicode ベースのシステムへ移行する段階になって、NEC選定IBM拡張文字が文 >> > 字化けする問題が発覚する事になるというケースが、今後出てくる事が予想さ >> > れます。 > > ただ何度も言うけど，Unicodeベースのシステムが前提なら，たとえばUTF-8な > らその問題は起こらないのでは？ > > ＃　別の問題が起こりますが（笑） > >>> >> しかし，単に文字レパートリの問題で引っ張り出してきたのなら，意味 >>> >> はないと思います． >> > >> > 意味が無いとしても、最低限、eucJP-ms と cp51932 が別物であるという事を >> > 明確化しておかないと、間違った理解に基づく開発が行われてしまう危険があ >> > ります。 > > 実際にどのように使われていて，どのような問題が起こるかを，明確化する必 > 要はあると思います． > >> > 個人的には、Windows 機種依存文字を日本語EUC符号化方式で扱うのはやめて >> > おいた方が良いと考えているのですが、そのような考え方は一般的ではないよ >> > うです。 > > あなたが一般的ではないだけで，すでに世界的には一般的だと思いますし，そ > れはMSの方針でもあれば，日本の方針でもあります． -- NARUSE, Yui DBDB A476 FDBD 9450 02CD 0EFC BCE3 C388 472E C1EA From naruse ＠ airemix.com Fri Apr 7 10:47:46 2006 From: naruse ＠ airemix.com (NARUSE, Yui) Date: Fri, 07 Apr 2006 10:47:46 +0900 Subject: [LE-talk-ja 25] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TIA==?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <84237377-E027-40B9-BE70-B5EA590FDD03@mac.com> References: <20060404130547.B376.MSYK@mtg.biglobe.ne.jp> <682059D7-3F32-47A4-843C-8CC5517179FE@mac.com> <20060405115031.B383.MORIYAMA@miraclelinux.com> <4433DB20.8090104@mtg.biglobe.ne.jp> <44340698.7070206@airemix.com> <4434200F.71140409@asahi-net.or.jp> <44347B82.4070109@airemix.com> <84237377-E027-40B9-BE70-B5EA590FDD03@mac.com> Message-ID: <4435C4C2.6030009@airemix.com> 成瀬です。 Kazuhiro Kazama wrote: > 基本的には，レガシーエンコーディングしか扱えないシステムと，Unicode > ベースのシステムが混在する際の問題は解決しなければいけないと考えていま > すし，基本的にEUCやShift-JISの変種は主にその相互変換に使われると思って > います． そうですね。 > しかし，それとは関係ない部分で，単に扱える文字レパートリーを増やすこと > が目的で新しい符号化文字集合をデファクト化しようとするとしたら違う話 > で，別のよりよい方法がすでにオーソライズされている場合には，そちらを使 > う方向の努力の方がよいと思います．たぶん，元の記事もそういう意図だと思 > います． 現状で変態的なものしか存在しないならばともかく、 CP50221 のような比較的マシなものがあるならば、 そちらの方がいいでしょうね。 # CP50221 がなければ意見が変わっていた可能性は高いです。 # いや、 CP50220 を支持してたかな。 > 少なくとも，「より多くの文字を扱いたい」は，日本を含めた漢字を扱うアジ > ア圏の人間の願いなわけですが，それなら今はJIS X 0213は無視できないし， > また従来の機種依存文字が，機種依存文字でない形で扱える，しかも従来は > Windowsとは非互換の機種依存文字のマッピングを採用していたMac OS Xなど > でも正しく表示できるということは重要だと思います． これは UTF-8 の話ですよね？ 最初 Shift_JIS-2004 や EUC-JIS-2004 の話かと思ったのですが。 >> Java 方面で Shift_JIS がCP932 の alias になった騒ぎがありましたが、 >> 騒ぎになる程度の違いは両者にある、と。 >> （これもまたえらく主観的ですが） > > それの騒ぎに関係したのは私だったりします（笑）． > > それで，結論ありきで議論を始めるよりも，まず既存の文字符号化を今よりさ > らに詳しく分析して，その違いを明らかにすることが重要ではないかと思いま > す．できれば，Unicodeへのマッピングが違う部分はどこなのかを一覧表にす > るのは有効だと思います．また同じ符号化文字集合であってもOSSプロダクト > によってマッピングが違うということはないかということも一度確認すること > も必要な気がします． CP932 と CP51932、 eucJP-ms、ISO-2022-JP-MS の対応をまとめた表や、 個々の文字コードの詳細は森山さんが公開されてましたね。 あれを Legacy Encoding Project でも公開してくださるとうれしいです。 マッピングは、各プロダクトで「CP932」と称されるものは、 どれも近いマッピングになってきた気がしていますが、 他はだいぶ差がありそうですね。 その辺の検証結果も公開を期待しておりますけれど。 -- NARUSE, Yui DBDB A476 FDBD 9450 02CD 0EFC BCE3 C388 472E C1EA From naruse ＠ airemix.com Fri Apr 7 11:58:01 2006 From: naruse ＠ airemix.com (NARUSE, Yui) Date: Fri, 07 Apr 2006 11:58:01 +0900 Subject: [LE-talk-ja 26] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TIA==?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <4434BD4B.4C5DD39E@asahi-net.or.jp> References: <20060404130547.B376.MSYK@mtg.biglobe.ne.jp> <682059D7-3F32-47A4-843C-8CC5517179FE@mac.com> <20060405115031.B383.MORIYAMA@miraclelinux.com> <4433DB20.8090104@mtg.biglobe.ne.jp> <44340698.7070206@airemix.com> <4434200F.71140409@asahi-net.or.jp> <44347B82.4070109@airemix.com> <4434BD4B.4C5DD39E@asahi-net.or.jp> Message-ID: <4435D539.3010707@airemix.com> 成瀬です。 Tadamasa Teranishi wrote: > 現状、うまく使えていないであろう文字(おそらくは想定外の入力データ)を > 生かす必要があるのかどうか。 想定外というか、思うにどのような文字が来るか、 「想定」していないのが実情かなと。 > もし、そのような文字を使いたいのであれば、そもそもアプリケーションを > UTF-8 で設計すべきではないか、と思います。 これから作るならばそうなりますね。 > どうしてもデータを生かしたいのなら > >> そのまま CP51932 として生かさないといけない、とは思っていません。 >> 多少平行運用を行わなければならない場合もあるでしょうが、 >> 多くの場合は、 >> nkf --overwrite --ic=CP51932 --oc=UTF-8 >> 一回の利用だろうとは思っています。 > > のように移行する際に1回データを変換するだけで良いような気がします。 > それは代表的なコード変換プログラムがサポートしさえしておれば良く、 > 多くのアプリケーションがサポートしなければならないことではない > ように思います。 自分で文字コード変換を抱えているソフトウェアですと、 その「一回」にぶつかってしまう可能性はありますね。 iconv に丸投げしているならばアプリケーション自身が 意識する必要はありませんけれど。 Ruby 2.0 のように CSI ならばともかく、UCS 正規化を行っているならば、 基本的には意識してサポートする必要は無いでしょう。 # 現状 UCS 正規化（広義）はしていても、Shift_JIS で正規化とか、 # EUC で正規化とかが多そうですけれど :-) > CP932 と eucJP-ms と それ以外とではかなり事情が違うと思います。 > CP932 に関しては Shift_JIS と使い分けているといえるでしょう。 > しかし、それ以外はそうかどうかは疑問が残ります。 eucJP-ms の事情がご理解いただけるのならば、 それは環境の違いかと思います。 わたしは eucJP-ms より CP51932 の方が欲しいくらいなので。 >> けれど、説得力のあるニーズを示すデータは難しいですね。 > ... >> しかし、他に「数字」が出る指標があるかというと、うーん。。。 > > ようするに裏づけされたデータがないということで、なんとなくそうなん > じゃないかという感覚的なものなのでしょう。 いえ、わたし自身は CP51932 は意図して使っています。 むしろ、eucJP-ms より CP51932 の方が使いますね。 # ゲイツ側の人間なので。 >>> メールに限らず UTF-8 化に力を注ぐほうが、より健全だろうと思います。 >> UTF-8 化の前提として、既存データの UTF-8 化が存在し、 >> それを行うのにレガシーエンコーディングと Unicode の対応表が、 >> ‘いくつか’必要である、というのがわたしの考えです。 >> >> 過去のデータは全て捨ててしまえ・・・とは言いませんよね？ >> ＃システムは捨ててしまえ、というのもありでしょうが。 > > 過去のデータの全てを生かさなければならないとは思わないということです。 > 生かすデータを選別しても良いのではないかということです。 生かすデータの選別は、何らかの形で行われるでしょうね。 ただ、それはアプリケーションの与り知らない、 もっと上のレイヤーで行われることだと考えます。 # そのために数字は出しづらいわけで。 実装コスト等の理由で、そのような選択肢を残さず切ってしまうか、 選別の余地を残すのかは、わたしには判断付きかねます。 # で、結局 CP51932 は自分のニーズで実装したわけです > CP932 とかは生かさなければならないでしょうけど、CP51932 を生かさ > なければならないか(個々の事情で生かさなければならない場合はあるで > しょうけれども)というのは疑問です。 例えば CGI/Perl は EUC-JP で書く習慣がありましたから、 掲示板のログ等で潜在的に CP51932 のデータが大量に眠ってはいます。 その大量のデータのうち、どの程度の割合が残すに値するかの判断は、 わたしにはつきかねます。 # が、自分の管理している範囲では全て残しますね。 > 機種依存文字等を含む場合は、 > UTF-8 への変換は移行する際に必要でも、UTF-8 からの変換は CP932 > ぐらいに絞らないと余計混乱するのではないかと思います。 > > 例えば、CP51932 や ISO-2022-JP-MS で出力するアプリケーションが増えて、 > 世の中にそのようなデータが増える方向に動きはしないかと懸念します。 > (コード変換プログラムは除く) > CP51932 や ISO-2022-JP-MS で出力する場合には、慎重に行うべきでしょう。 > それよりは UTF-8 で処理する方向で動いて欲しいと願います。 ある程度同意します。 多くの標準で、レガシーエンコーディングから Unicode への、 一方向のマッピングしか公開されていないのはそのような意図なのでしょう。 しかし、わたしは特に思想を持たず、両方向提供した上で、 後は神の見えざる手にまかせちゃえばいいや、と思ってしまったりも。 今更そんな絞らなくても、UTF-8 にできる部分は UTF-8 になるだろう、 と楽天的に考えています。 CSS の大きさにしても、CES としての設計にしても、 UTF-8 の優位性は明らかなので。 > ついでに。 > シェアの問題でしょうけれども Windows のコード中心なのも気になります。 > Macintosh は? とか、携帯電話の絵文字は? とかもあるわけです。 > 特に携帯電話は無視できる数ではないので、Windows のコードだけ考えて > いても...という気もします。 Macintosh は？というツッコミはわたしも考えたのですけれど、 実際にニーズを伴った発言はなぜか見かけませんね。 もっとも、MAC-JAPANESE はメンテナンスされている対応表が存在するので、 あとは実装だけという気もします。 http://www.unicode.org/Public/MAPPINGS/VENDORS/APPLE/JAPANESE.TXT # あー、でも0x5C -> U+00A5 なのかー 携帯の絵文字はニーズが結構あるようですが、 これの対応表は・・・あるんですかね？ Vodafone が公開しているのは見つけましたが、 http://www.vodafone.jp/3G/live/mail/pict_convert.html どのようにUnicodeの仕様領域に割り当てるか等、 なんらかの標準は欲しいですね、すでにあるのかな？ # 各社が Unicode との対応は公開しているものの、 # au と Vodafone は領域重なってるし・・・。 -- NARUSE, Yui DBDB A476 FDBD 9450 02CD 0EFC BCE3 C388 472E C1EA From moriyama ＠ miraclelinux.com Fri Apr 7 12:30:16 2006 From: moriyama ＠ miraclelinux.com (MORIYAMA Masayuki) Date: Fri, 7 Apr 2006 12:30:16 +0900 (JST) Subject: [LE-talk-ja 27] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TIA==?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <44340698.7070206@airemix.com> References: <4433DB20.8090104@mtg.biglobe.ne.jp> <44340698.7070206@airemix.com> Message-ID: <20060407100809.B3B0.MORIYAMA@miraclelinux.com> 森山です。 "NARUSE, Yui" wrote: > はじめまして、成瀬と申します。 > > わたしは Legacy Encoding Project でターゲットに挙げられている、 > nkf、Ruby/NKF、Encode::EUCJPMS をメンテナンスしています。 Encode モジュール用の eucJP-ms, CP51932 に関しては、作らねばと思ってい たのですが、なかなか重い腰が上がらず、成瀬さんに作っていただき助かりま した。 > 一方で今回提案された ISO-2022-JP-MS は、 > * CSS が ISO-2022-JP (RFC1468) と異なる > * そのような「ISO-2022-JP-MS で扱える符号化文字列」の > 資産は相当数存在する > ため、その類のものに対する必要性は一定あるでしょう。 > （例えばMLのアーカイブの Unicode 化に用いる） > しかし、それならば CP502xx で十分でしょう。 > > ユーザ定義文字が ISO 2022 から逸脱するのは、 > 確かに問題だとも思いますが、 > すでに逸脱した形でエンコードされたデータが > 相当数存在するシステムで用いられるのですし、 > ユーザ定義文字を出力しない CP50221 でいい気もします。 ユーザ定義文字を出力しない CP50221 にしてみました。 どうでしょう? ■ ISO-2022-JP-MS(改1) ユーザ定義文字を出力しない CP50221 使用するエスケープシーケンス 文字セット esc seq. 1バイト目 2バイト目 --------------------- --------- ------------------- --------- ------ US-ASCII ESC ( B 0x00-0x7F -- in/out JIS X 0201 ラテン文字 ESC ( J 0x00-0x7F -- in JIS X 0201 片仮名 ESC ( I 0x21-0x5F -- in/out SO/SI 0x21-0x5F -- in ESC ( B 0xA1-0xDF -- in ESC ( J 0xA1-0xDF -- in JIS X 0208:1978 ESC @ B 0x21-0x28,0x30-0x74 0x21-0x7E in JIS X 0208:1997 ESC $ B 0x21-0x28,0x30-0x74 0x21-0x7E in/out NEC特殊文字 ESC $ B 0x2D 0x21-0x7E in/out NEC選定IBM拡張文字 ESC $ B 0x79-0x7C 0x21-0x7E in/out ユーザ定義文字 ESC $ B 0x7F-0x92 0x21-0x7E in ※in = ISO-2022-JP-MS(改1) から Unicode への変換 out= Unicode から ISO-2022-JP-MS(改1) への変換 実は、Windows の CP5022X での SO/SI の扱いに関しては、やや特殊な事が 行われているようで、SO から SI の間のバイト列それぞれに 0x80 を OR して 0xA1〜0xDF の範囲であれば、JIS X 0201 片仮名として変換されます が、0x81〜0x9F, 0xE0〜0xFC のコードが出てくると、CP932 の 2バイトコー ドとみなして Unicode に変換するという事が行われているようなのです。 このような処理をしてやると、Becky! Internet Mail で送信したユーザ定 義文字を受信しても Unicode に変換できるようになります。 そこまでやる必要はないでしょうけれども… -- 森山 将之 moriyama ＠ miraclelinux.com ミラクル・リナックス株式会社 From kazama ＠ mac.com Fri Apr 7 12:50:19 2006 From: kazama ＠ mac.com (Kazuhiro Kazama) Date: Fri, 7 Apr 2006 12:50:19 +0900 Subject: [LE-talk-ja 28] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TIA==?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <4435C4C2.6030009@airemix.com> References: <20060404130547.B376.MSYK@mtg.biglobe.ne.jp> <682059D7-3F32-47A4-843C-8CC5517179FE@mac.com> <20060405115031.B383.MORIYAMA@miraclelinux.com> <4433DB20.8090104@mtg.biglobe.ne.jp> <44340698.7070206@airemix.com> <4434200F.71140409@asahi-net.or.jp> <44347B82.4070109@airemix.com> <84237377-E027-40B9-BE70-B5EA590FDD03@mac.com> <4435C4C2.6030009@airemix.com> Message-ID: <25770C0E-81DE-4A73-9C6F-06ACED80AEA6@mac.com> On 2006/04/07, at 10:47, NARUSE, Yui wrote: >> しかし，それとは関係ない部分で，単に扱える文字レパートリーを増やす >> こと >> が目的で新しい符号化文字集合をデファクト化しようとするとしたら違う話 >> で，別のよりよい方法がすでにオーソライズされている場合には，そちら >> を使 >> う方向の努力の方がよいと思います．たぶん，元の記事もそういう意図だ >> と思 >> います． > > 現状で変態的なものしか存在しないならばともかく、 > CP50221 のような比較的マシなものがあるならば、 > そちらの方がいいでしょうね。 > # CP50221 がなければ意見が変わっていた可能性は高いです。 > # いや、 CP50220 を支持してたかな。 最近はこの問題にあまり関わっていなかったので，その辺の話を詳しく知りた いですね． なお，基本的にOSベンダによってすでに実装されて，ユーザによってある程度 使われているものは検討する価値があると思います．ただし，場合によって は，すべてには入れないということも考えなければいけないと思っています． >> 少なくとも，「より多くの文字を扱いたい」は，日本を含めた漢字を扱う >> アジ >> ア圏の人間の願いなわけですが，それなら今はJIS X 0213は無視できない >> し， >> また従来の機種依存文字が，機種依存文字でない形で扱える，しかも従来は >> Windowsとは非互換の機種依存文字のマッピングを採用していたMac OS Xなど >> でも正しく表示できるということは重要だと思います． > > これは UTF-8 の話ですよね？ > 最初 Shift_JIS-2004 や EUC-JIS-2004 の話かと思ったのですが。 違います．すでに前の投稿で書きましたが，OSベンダや標準化団体では， UTF-8で使うことを前提に検討が進んでいます． ＃　今，みんなで無視することで歴史的になかったことにされようとしている のが，JIS X 0212と，JIS X 0213のそのような符号化です（笑） > CP932 と CP51932、 eucJP-ms、ISO-2022-JP-MS の対応をまとめた表や、 > 個々の文字コードの詳細は森山さんが公開されてましたね。 > あれを Legacy Encoding Project でも公開してくださるとうれしいです。 私も昔に同様な表を作って公開したのですが，非常に多くのところから見に来 て頂いていました．正しくおこなわれた分析は，説得力や影響力がありますの で，それは重要だと思います． > マッピングは、各プロダクトで「CP932」と称されるものは、 > どれも近いマッピングになってきた気がしていますが、 > 他はだいぶ差がありそうですね。 > その辺の検証結果も公開を期待しておりますけれど。 やはり，マッピングにばらつきがあるわけですか…． 基本的に，一旦普及したものを変更するのは非常に難しいと言えます．だか ら，パッチを送っても，拒否される可能性も高いでしょう． しかし，ここで議論した結果をまとめて公開することで，（別の回避策がある とか，問題が緩和されるのなら）統一しようという動きが起こるかもしれませ ん． ただし，そのような影響があるゆえに，議論は慎重に行うべきだと思います． --- 風間 一洋 (kazama ＠ mac.com) From yw3t-trns ＠ asahi-net.or.jp Fri Apr 7 12:51:41 2006 From: yw3t-trns ＠ asahi-net.or.jp (Tadamasa Teranishi) Date: Fri, 07 Apr 2006 12:51:41 +0900 Subject: [LE-talk-ja 29] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TICA=?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= References: <4433DB20.8090104@mtg.biglobe.ne.jp> <44340698.7070206@airemix.com> <20060407100809.B3B0.MORIYAMA@miraclelinux.com> Message-ID: <4435E1CD.732FBF1@asahi-net.or.jp> 寺西です。 MORIYAMA Masayuki wrote: > > このような処理をしてやると、Becky! Internet Mail で送信したユーザ定 > 義文字を受信しても Unicode に変換できるようになります。 これはつまり Becky! Internet Mail が変なコードでメールを出すという ことを意味しているのでしょうか? # その辺りの背景が見えないですが...。 -- ===================================================================== 寺西 忠勝(TADAMASA TERANISHI) yw3t-trns ＠ asahi-net.or.jp http://www.asahi-net.or.jp/~yw3t-trns/index.htm Key fingerprint = 474E 4D93 8E97 11F6 662D 8A42 17F5 52F4 10E7 D14E From moriyama ＠ miraclelinux.com Fri Apr 7 12:59:32 2006 From: moriyama ＠ miraclelinux.com (MORIYAMA Masayuki) Date: Fri, 7 Apr 2006 12:59:32 +0900 (JST) Subject: [LE-talk-ja 30] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TICA=?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <4434BD4B.4C5DD39E@asahi-net.or.jp> References: <44347B82.4070109@airemix.com> <4434BD4B.4C5DD39E@asahi-net.or.jp> Message-ID: <20060407123811.B3BA.MORIYAMA@miraclelinux.com> 森山です。 Tadamasa Teranishi wrote: > > "NARUSE, Yui" wrote: > > > > > それが CP51932 でなければならないとか、そのまま CP51932 として > > > 生かさないといけないのかというところには疑問が残ります。 > > > > NEC選定IBM拡張文字が 0xF9A1 から 0xFCFE になる文字コードは、 > > わたしは CP51932 しか知りませんが、 > > 他にそのような文字コードがあるならばそれでもよいでしょうね。 > > 他に無いならば eucJP-ms でなく、CP51932 でなければならないでしょう。 > > 現状、うまく使えていないであろう文字(おそらくは想定外の入力データ)を > 生かす必要があるのかどうか。 > > もし、そのような文字を使いたいのであれば、そもそもアプリケーションを > UTF-8 で設計すべきではないか、と思います。 そもそも、CP51932 と eucJP-ms が別物であるという理解がされていない状況 では、どういった問題が発生するのかという事も理解されておらず、なおかつ、あ る状況下では一見問題なく動いているように見えるため、Windows 機種依存文字 を扱う必要がある場合は、UTF-8 もしくは CP932 (Windows-31J) で設計すべき であるという事が理解されていない可能性が高いように思います。 -- 森山 将之 moriyama ＠ miraclelinux.com ミラクル・リナックス株式会社 From yw3t-trns ＠ asahi-net.or.jp Fri Apr 7 13:01:38 2006 From: yw3t-trns ＠ asahi-net.or.jp (Tadamasa Teranishi) Date: Fri, 07 Apr 2006 13:01:38 +0900 Subject: [LE-talk-ja 31] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TICA=?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= References: <20060404130547.B376.MSYK@mtg.biglobe.ne.jp> <682059D7-3F32-47A4-843C-8CC5517179FE@mac.com> <20060405115031.B383.MORIYAMA@miraclelinux.com> <4433DB20.8090104@mtg.biglobe.ne.jp> <44340698.7070206@airemix.com> <4434200F.71140409@asahi-net.or.jp> <44347B82.4070109@airemix.com> <4434BD4B.4C5DD39E@asahi-net.or.jp> <4435D539.3010707@airemix.com> Message-ID: <4435E422.D6115079@asahi-net.or.jp> 寺西です。 "NARUSE, Yui" wrote: > > Tadamasa Teranishi wrote: > > 現状、うまく使えていないであろう文字(おそらくは想定外の入力データ)を > > 生かす必要があるのかどうか。 > > 想定外というか、思うにどのような文字が来るか、 > 「想定」していないのが実情かなと。 受け取り側の対応コード以外のものが送られてくれば、それは想定外のデータ でしょう。 で、CP-932, EUC-JP, UTF-8 ぐらいは対応していても、CP51932 とかは 想定していないケースがほとんどかと。 # CP51932 を想定していたのなら、それなりに対処もしているでしょうし。 > > もし、そのような文字を使いたいのであれば、そもそもアプリケーションを > > UTF-8 で設計すべきではないか、と思います。 > > これから作るならばそうなりますね。 いや、今でも使いたいなら UTF-8 に移行すべきであって、CP51932 とか で使おうとするのが良いことではないだろうと思います。例え、使える ようになったとしてもです。 > > CP932 と eucJP-ms と それ以外とではかなり事情が違うと思います。 > > CP932 に関しては Shift_JIS と使い分けているといえるでしょう。 > > しかし、それ以外はそうかどうかは疑問が残ります。 > > eucJP-ms の事情がご理解いただけるのならば、 > それは環境の違いかと思います。 > わたしは eucJP-ms より CP51932 の方が欲しいくらいなので。 その理由を説明していただけますか? CP51932 を使っているのは IE (および他のブラウザ?)から送られてくる データぐらいしか知りませんが、他にありますか? > >> けれど、説得力のあるニーズを示すデータは難しいですね。 > > ... > >> しかし、他に「数字」が出る指標があるかというと、うーん。。。 > > > > ようするに裏づけされたデータがないということで、なんとなくそうなん > > じゃないかという感覚的なものなのでしょう。 > > いえ、わたし自身は CP51932 は意図して使っています。 それは成瀬さんがということであって、相当の人がということには なりませんよね。 (使い分けている人がいないと言っているのではなくて、相当の人が 使い分けているかどうかは疑問があると言っているわけですから。) > むしろ、eucJP-ms より CP51932 の方が使いますね。 > # ゲイツ側の人間なので。 Windows よりの設計をするのはわからないわけではないですが、自ら公言され ては、設計が偏っていると受け取られかねないですよ。 # Windows はもちろん無視できるわけではありませんが。 > > CP932 とかは生かさなければならないでしょうけど、CP51932 を生かさ > > なければならないか(個々の事情で生かさなければならない場合はあるで > > しょうけれども)というのは疑問です。 > > 例えば CGI/Perl は EUC-JP で書く習慣がありましたから、 > 掲示板のログ等で潜在的に CP51932 のデータが大量に眠ってはいます。 つまり現状死んでいるわけです。 > その大量のデータのうち、どの程度の割合が残すに値するかの判断は、 > わたしにはつきかねます。 > # が、自分の管理している範囲では全て残しますね。 現状死んでいるデータを本当に生かしたいですか? CP51932 のデータは、本当に全てCP51932 のデータなのでしょうか? 他のEUC系のコードと混在していたりしませんか? 生かそうとしてはまったりすることはないのでしょうか? > 多くの標準で、レガシーエンコーディングから Unicode への、 > 一方向のマッピングしか公開されていないのはそのような意図なのでしょう。 > しかし、わたしは特に思想を持たず、両方向提供した上で、 > 後は神の見えざる手にまかせちゃえばいいや、と思ってしまったりも。 両方向提供すること自体は必ずしも悪いわけではありませんが、 それにより、レガシーエンコーディングのまま、より悪い方向で拡張された アプリケーションが増えてしまって、かえって Unicode への移行を妨げる ことになるのではないかと懸念します。(と、レガシーエンコーディング のデータが増えて、移行の際により混乱を拡大しそうです。) 両方向提供するのと同時に、レガシーエンコーディングへの変換は最小限 に注意して使うようにするのと、Unicode への移行を推奨するといった 内容を含むガイドライン等を示す必要があるのではないかと思います。 > 今更そんな絞らなくても、UTF-8 にできる部分は UTF-8 になるだろう、 > と楽天的に考えています。 遠い将来はそうでしょうが、レガシーエンコーディングの環境が整うと、 しばらくレガシーエンコーディングのまま使い続ける可能性も出てくる ような気がします。 そこを心配しているわけです。 > > ついでに。 > > シェアの問題でしょうけれども Windows のコード中心なのも気になります。 > > Macintosh は? とか、携帯電話の絵文字は? とかもあるわけです。 > > 特に携帯電話は無視できる数ではないので、Windows のコードだけ考えて > > いても...という気もします。 > > Macintosh は？というツッコミはわたしも考えたのですけれど、 > 実際にニーズを伴った発言はなぜか見かけませんね。 Macintosh ユーザは歴史的にものわかりが良くて、困っていてもそんなもの だと割り切って使う人が多いですからね。そうじゃないと、Windows じゃ なくてわざわざ Mac を使ったりしませんし。 > もっとも、MAC-JAPANESE はメンテナンスされている対応表が存在するので、 > あとは実装だけという気もします。 > http://www.unicode.org/Public/MAPPINGS/VENDORS/APPLE/JAPANESE.TXT > # あー、でも0x5C -> U+00A5 なのかー またかぁ。 > 携帯の絵文字はニーズが結構あるようですが、 > これの対応表は・・・あるんですかね？ あるにはあるはずです。各社で対応は違うのでしょうが、SDK には含まれる のではないでしょうか。 > Vodafone が公開しているのは見つけましたが、 > http://www.vodafone.jp/3G/live/mail/pict_convert.html > どのようにUnicodeの仕様領域に割り当てるか等、 > なんらかの標準は欲しいですね、すでにあるのかな？ > # 各社が Unicode との対応は公開しているものの、 > # au と Vodafone は領域重なってるし・・・。 Microsoft 同様、各社好き勝手にやってます。 Shift_JIS とかにも絵文字はあるので、これもレガシーエンコーディング??? -- ===================================================================== 寺西 忠勝(TADAMASA TERANISHI) yw3t-trns ＠ asahi-net.or.jp http://www.asahi-net.or.jp/~yw3t-trns/index.htm Key fingerprint = 474E 4D93 8E97 11F6 662D 8A42 17F5 52F4 10E7 D14E From yw3t-trns ＠ asahi-net.or.jp Fri Apr 7 13:06:02 2006 From: yw3t-trns ＠ asahi-net.or.jp (Tadamasa Teranishi) Date: Fri, 07 Apr 2006 13:06:02 +0900 Subject: [LE-talk-ja 32] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TICAg?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= References: <44347B82.4070109@airemix.com> <4434BD4B.4C5DD39E@asahi-net.or.jp> <20060407123811.B3BA.MORIYAMA@miraclelinux.com> Message-ID: <4435E52A.493B2EDF@asahi-net.or.jp> 寺西です。 MORIYAMA Masayuki wrote: > > > もし、そのような文字を使いたいのであれば、そもそもアプリケーションを > > UTF-8 で設計すべきではないか、と思います。 > > そもそも、CP51932 と eucJP-ms が別物であるという理解がされていない状況 > では、どういった問題が発生するのかという事も理解されておらず、なおかつ、あ > る状況下では一見問題なく動いているように見えるため、Windows 機種依存文字 > を扱う必要がある場合は、UTF-8 もしくは CP932 (Windows-31J) で設計すべき > であるという事が理解されていない可能性が高いように思います。 そうそう。 そのように設計しましょうというガイドラインを示すことが重要ではないか と思うわけです。 # 今更 CP932 を推奨することはないと思いますが。 レガシーエンコーディングの環境を整えるのはその後なんではないかと。 -- ===================================================================== 寺西 忠勝(TADAMASA TERANISHI) yw3t-trns ＠ asahi-net.or.jp http://www.asahi-net.or.jp/~yw3t-trns/index.htm Key fingerprint = 474E 4D93 8E97 11F6 662D 8A42 17F5 52F4 10E7 D14E From kazama ＠ mac.com Fri Apr 7 13:19:44 2006 From: kazama ＠ mac.com (Kazuhiro Kazama) Date: Fri, 7 Apr 2006 13:19:44 +0900 Subject: [LE-talk-ja 33] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TIA==?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <4435D539.3010707@airemix.com> References: <20060404130547.B376.MSYK@mtg.biglobe.ne.jp> <682059D7-3F32-47A4-843C-8CC5517179FE@mac.com> <20060405115031.B383.MORIYAMA@miraclelinux.com> <4433DB20.8090104@mtg.biglobe.ne.jp> <44340698.7070206@airemix.com> <4434200F.71140409@asahi-net.or.jp> <44347B82.4070109@airemix.com> <4434BD4B.4C5DD39E@asahi-net.or.jp> <4435D539.3010707@airemix.com> Message-ID: 文字レパートリと既存の符号化文字集合とUnicodeのマッピングの対応の問題 が混在している気がしますが（たぶん明確な切り分けが必要），それはとりあ えずおいておいて． On 2006/04/07, at 11:58, NARUSE, Yui wrote: >> ついでに。 >> シェアの問題でしょうけれども Windows のコード中心なのも気になります。 >> Macintosh は? とか、携帯電話の絵文字は? とかもあるわけです。 >> 特に携帯電話は無視できる数ではないので、Windows のコードだけ考えて >> いても...という気もします。 > > Macintosh は？というツッコミはわたしも考えたのですけれど、 > 実際にニーズを伴った発言はなぜか見かけませんね。 MacJapaneseは必要ですが，すべてのプラットフォームで必要ではないかもし れません． それで，Macに関して問題があまり認識されていない理由としては，私がApple Computerに問題を報告したことで，比較的早期に何らかの対処をして頂いたか らかもしれません．かなり昔に検証したので詳しいことは忘れてしまったので すが，少なくともマッピングが異なっていても文字は表示されるようにフォン トを変更して頂いたと思います．もしかすると森山さんが拒否された提案のよ うに既存文字符号化への変換の際の変換テーブルにも手が入っていたかもしれ ません． > 携帯の絵文字はニーズが結構あるようですが、 > これの対応表は・・・あるんですかね？ NTT DoCoMoのiモードのページを見れば，Shift-JISやUnicodeでどの部分に割 り当てられているかがわかります．ただし，割り当てられている領域は，それ ぞれ外字領域，私用領域です． これらの文字をUnicodeに正式に収録する提案は，Apple ComputerやMicrosoft などからもおこなわれたですが，拒否されたようです．実は私も打診したこと があります．私の口からは理由ははっきり言うことはできませんが，実際にど のような文字が収録されているかを…特に未公開領域に…見て頂ければ，収録 できない理由はすぐ推測できると思います（謎）．衝撃です． > Vodafone が公開しているのは見つけましたが、 > http://www.vodafone.jp/3G/live/mail/pict_convert.html こちらは文字としてではなく，単なる絵として扱われていた記憶があります． --- 風間 一洋 (kazama ＠ mac.com) From moriyama ＠ miraclelinux.com Fri Apr 7 13:37:15 2006 From: moriyama ＠ miraclelinux.com (MORIYAMA Masayuki) Date: Fri, 7 Apr 2006 13:37:15 +0900 (JST) Subject: [LE-talk-ja 34] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TICA=?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <4435E1CD.732FBF1@asahi-net.or.jp> References: <20060407100809.B3B0.MORIYAMA@miraclelinux.com> <4435E1CD.732FBF1@asahi-net.or.jp> Message-ID: <20060407131331.B3C0.MORIYAMA@miraclelinux.com> 森山です。 Tadamasa Teranishi wrote: > 寺西です。 > > MORIYAMA Masayuki wrote: > > > > このような処理をしてやると、Becky! Internet Mail で送信したユーザ定 > > 義文字を受信しても Unicode に変換できるようになります。 > > これはつまり Becky! Internet Mail が変なコードでメールを出すという > ことを意味しているのでしょうか? > > # その辺りの背景が見えないですが...。 Becky! では CP932 の 0xF09F (96区1点) を ISO-2022-JP に変換すると、次 のようなバイト列で送信されてきます。 SO SI ---- ---- 0x0E 0x70 0x1F 0x0F これを 0x0E と 0x0F の間のバイト列に 0x80 を OR すると次のようになり元 に戻ります。 0xF0 0x9F しかし、0xF040〜0xF09E (95区1点〜95区94点) に関しては、CP5022X と同じ ようなコードになります。0xF040 は次のようなコードになります。 ESC $ B ESC ( B ---- ---- ---- ---- ---- ---- 0x1B 0x24 0x42 0x7F 0x21 0x1B 0x28 0x42 こちらは、計算式により jis->sjis 変換を行うと 0xF040 に変換されます。 かなり変則的なコードと言えます。 -- 森山 将之 moriyama ＠ miraclelinux.com ミラクル・リナックス株式会社 From kazama ＠ mac.com Fri Apr 7 13:45:56 2006 From: kazama ＠ mac.com (Kazuhiro Kazama) Date: Fri, 7 Apr 2006 13:45:56 +0900 Subject: [LE-talk-ja 35] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TICA=?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <20060407131331.B3C0.MORIYAMA@miraclelinux.com> References: <20060407100809.B3B0.MORIYAMA@miraclelinux.com> <4435E1CD.732FBF1@asahi-net.or.jp> <20060407131331.B3C0.MORIYAMA@miraclelinux.com> Message-ID: <9FEE10D9-F2FB-4735-8A6C-9F741F438338@mac.com> On 2006/04/07, at 13:37, MORIYAMA Masayuki wrote: > かなり変則的なコードと言えます。 これは，すぐ直して貰えるような単純なバグと考えてよいのでしょうか？それ とも仕様？ --- 風間 一洋 (kazama ＠ mac.com) From yw3t-trns ＠ asahi-net.or.jp Fri Apr 7 13:59:53 2006 From: yw3t-trns ＠ asahi-net.or.jp (Tadamasa Teranishi) Date: Fri, 07 Apr 2006 13:59:53 +0900 Subject: [LE-talk-ja 36] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TICA=?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= References: <20060404130547.B376.MSYK@mtg.biglobe.ne.jp> <682059D7-3F32-47A4-843C-8CC5517179FE@mac.com> <20060405115031.B383.MORIYAMA@miraclelinux.com> <4433DB20.8090104@mtg.biglobe.ne.jp> <44340698.7070206@airemix.com> <4434200F.71140409@asahi-net.or.jp> <44347B82.4070109@airemix.com> <4434BD4B.4C5DD39E@asahi-net.or.jp> <4435D539.3010707@airemix.com> Message-ID: <4435F1C9.E4CE3F03@asahi-net.or.jp> 寺西です。 Kazuhiro Kazama wrote: > > MacJapaneseは必要ですが，すべてのプラットフォームで必要ではないかもし > れません． Mac 上でのみ必要という意味でしょうか? > それで，Macに関して問題があまり認識されていない理由としては，私がApple > Computerに問題を報告したことで，比較的早期に何らかの対処をして頂いたか > らかもしれません．かなり昔に検証したので詳しいことは忘れてしまったので > すが，少なくともマッピングが異なっていても文字は表示されるようにフォン > トを変更して頂いたと思います．もしかすると森山さんが拒否された提案のよ > うに既存文字符号化への変換の際の変換テーブルにも手が入っていたかもしれ > ません． 文字が表示されてもマッピングが異なっていると困ることはあるような。 > NTT DoCoMoのiモードのページを見れば，Shift-JISやUnicodeでどの部分に割 > り当てられているかがわかります．ただし，割り当てられている領域は，それ > ぞれ外字領域，私用領域です． はい。 > これらの文字をUnicodeに正式に収録する提案は，Apple ComputerやMicrosoft > などからもおこなわれたですが，拒否されたようです．実は私も打診したこと 正式に収録されるのが望ましいですが、拒否されるのもわからないではない です。 正式に収録されなくても(外字領域，私用領域)であっても、少なくとも 国内で広く使われているので、Windows 系のコードを考慮するなら こちらも考慮が必要ではないかと思います。 > があります．私の口からは理由ははっきり言うことはできませんが，実際にど > のような文字が収録されているかを…特に未公開領域に…見て頂ければ，収録 > できない理由はすぐ推測できると思います（謎）．衝撃です． 未公開領域だけに見れませんが、そんな衝撃的なものがあったのですか。 > > Vodafone が公開しているのは見つけましたが、 > > http://www.vodafone.jp/3G/live/mail/pict_convert.html > > こちらは文字としてではなく，単なる絵として扱われていた記憶があります． Vodafone のコードの情報は http://developers.vodafone.jp/dp/tool_dl/web/picword_top.php とか http://developers.vodafone.jp/dp/tool_dl/download.php?docid=120 ですね。 -- ===================================================================== 寺西 忠勝(TADAMASA TERANISHI) yw3t-trns ＠ asahi-net.or.jp http://www.asahi-net.or.jp/~yw3t-trns/index.htm Key fingerprint = 474E 4D93 8E97 11F6 662D 8A42 17F5 52F4 10E7 D14E From kazama ＠ mac.com Fri Apr 7 14:26:49 2006 From: kazama ＠ mac.com (Kazuhiro Kazama) Date: Fri, 7 Apr 2006 14:26:49 +0900 Subject: [LE-talk-ja 37] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TICA=?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <4435F1C9.E4CE3F03@asahi-net.or.jp> References: <20060404130547.B376.MSYK@mtg.biglobe.ne.jp> <682059D7-3F32-47A4-843C-8CC5517179FE@mac.com> <20060405115031.B383.MORIYAMA@miraclelinux.com> <4433DB20.8090104@mtg.biglobe.ne.jp> <44340698.7070206@airemix.com> <4434200F.71140409@asahi-net.or.jp> <44347B82.4070109@airemix.com> <4434BD4B.4C5DD39E@asahi-net.or.jp> <4435D539.3010707@airemix.com> <4435F1C9.E4CE3F03@asahi-net.or.jp> Message-ID: On 2006/04/07, at 13:59, Tadamasa Teranishi wrote: >> MacJapaneseは必要ですが，すべてのプラットフォームで必要ではないかもし >> れません． > > Mac 上でのみ必要という意味でしょうか? Macの上では今でも使われていると思います．ただし，すでに述べたようにあ る程度互換性が配慮されていたりすることと，レガシーなシステムが少ないか らかもしれません．まあ，基本的なアプリケーションはMac独自のAPIで書かれ ていて，独自のコンバータAPIがあるので，必要になるのはUnix系ソフトウェ アを動かす時ですが，その場合には普通のUnixの場合と問題は同等になるから かな…．ちょっと調べてみないといけないかもしれません． 脱線しますが，面白いのはJavaの処理系で，実はJavaは自前で多くのコンバー タを持っているのですが，Mac上のJava処理系ではMacのコンバータAPIを呼び 出すコンバータが実装されていて，デフォルトではそれを使ったりします． 同様にすれば，たとえばWindows環境においてはWindowsに沿った処理をするよ うにできますが，ソフトウェアによって実装が難しいだろうと思います． >> それで，Macに関して問題があまり認識されていない理由としては，私が >> Apple >> Computerに問題を報告したことで，比較的早期に何らかの対処をして頂い >> たか >> らかもしれません．かなり昔に検証したので詳しいことは忘れてしまった >> ので >> すが，少なくともマッピングが異なっていても文字は表示されるように >> フォン >> トを変更して頂いたと思います．もしかすると森山さんが拒否された提案 >> のよ >> うに既存文字符号化への変換の際の変換テーブルにも手が入っていたかも >> しれ >> ません． > > 文字が表示されてもマッピングが異なっていると困ることはあるような。 実はその通りです…が，少なくともマッピングが異なる文字が混在するのは， UTF-8などを直接取り込めるようになると不可避かと思っていますので，私は さらに別の問題として考えています．ちょっと，これについては書きかけの文 章を後から投稿します． > 未公開領域だけに見れませんが、そんな衝撃的なものがあったのですか。 昔使ったHTMLファイルを密送しましょうか？（笑） > Vodafone のコードの情報は > > http://developers.vodafone.jp/dp/tool_dl/web/picword_top.php > > とか > > http://developers.vodafone.jp/dp/tool_dl/download.php?docid=120 > > ですね。 了解しました．要するに，以前文字として扱ってはいなかったが，今は Unicodeの私用領域に割り当てているということですね． --- 風間 一洋 (kazama ＠ mac.com) From yw3t-trns ＠ asahi-net.or.jp Fri Apr 7 14:33:45 2006 From: yw3t-trns ＠ asahi-net.or.jp (Tadamasa Teranishi) Date: Fri, 07 Apr 2006 14:33:45 +0900 Subject: [LE-talk-ja 38] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TICAg?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= References: <20060407100809.B3B0.MORIYAMA@miraclelinux.com> <4435E1CD.732FBF1@asahi-net.or.jp> <20060407131331.B3C0.MORIYAMA@miraclelinux.com> Message-ID: <4435F9B9.1DB83414@asahi-net.or.jp> 寺西です。 MORIYAMA Masayuki wrote: > > Tadamasa Teranishi wrote: > > > > MORIYAMA Masayuki wrote: > > > > > > このような処理をしてやると、Becky! Internet Mail で送信したユーザ定 > > > 義文字を受信しても Unicode に変換できるようになります。 > > > > これはつまり Becky! Internet Mail が変なコードでメールを出すという > > ことを意味しているのでしょうか? > > > > # その辺りの背景が見えないですが...。 > > Becky! では CP932 の 0xF09F (96区1点) を ISO-2022-JP に変換すると、次 > のようなバイト列で送信されてきます。 誤解しているかもしれませんが、 これは96区の文字(95区以降?)が入力されることを想定していなかっただけ なのでは? > かなり変則的なコードと言えます。 Becky! Internet Mail 開発者に問題を指摘されていますか? 送られてきたデータをアプリケーション側で読めるようにするよりは、 Becky! Internet Mail に送らないように修正してもらうのが筋な話に 見えます。 -- ===================================================================== 寺西 忠勝(TADAMASA TERANISHI) yw3t-trns ＠ asahi-net.or.jp http://www.asahi-net.or.jp/~yw3t-trns/index.htm Key fingerprint = 474E 4D93 8E97 11F6 662D 8A42 17F5 52F4 10E7 D14E From yw3t-trns ＠ asahi-net.or.jp Fri Apr 7 14:45:03 2006 From: yw3t-trns ＠ asahi-net.or.jp (Tadamasa Teranishi) Date: Fri, 07 Apr 2006 14:45:03 +0900 Subject: [LE-talk-ja 39] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TICAg?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= References: <20060404130547.B376.MSYK@mtg.biglobe.ne.jp> <682059D7-3F32-47A4-843C-8CC5517179FE@mac.com> <20060405115031.B383.MORIYAMA@miraclelinux.com> <4433DB20.8090104@mtg.biglobe.ne.jp> <44340698.7070206@airemix.com> <4434200F.71140409@asahi-net.or.jp> <44347B82.4070109@airemix.com> <4434BD4B.4C5DD39E@asahi-net.or.jp> <4435D539.3010707@airemix.com> <4435F1C9.E4CE3F03@asahi-net.or.jp> Message-ID: <4435FC5E.8CD9CC42@asahi-net.or.jp> 寺西です。 Kazuhiro Kazama wrote: > > > Mac 上でのみ必要という意味でしょうか? > > Macの上では今でも使われていると思います．ただし，すでに述べたようにあ > る程度互換性が配慮されていたりすることと，レガシーなシステムが少ないか > らかもしれません．まあ，基本的なアプリケーションはMac独自のAPIで書かれ そうですね。 > ていて，独自のコンバータAPIがあるので，必要になるのはUnix系ソフトウェ > アを動かす時ですが，その場合には普通のUnixの場合と問題は同等になるから > かな…．ちょっと調べてみないといけないかもしれません． ふむふむ。 > 脱線しますが，面白いのはJavaの処理系で，実はJavaは自前で多くのコンバー > タを持っているのですが，Mac上のJava処理系ではMacのコンバータAPIを呼び > 出すコンバータが実装されていて，デフォルトではそれを使ったりします． Samba でも Mac 版(Apple版だったか?)は、Mac の API を呼び出して 同等のことをしていますね。 ただ、多くのソフトでは Mac のことまで手が回らない(動作確認環境を 持たない)からか、対応していないのが残念なところです。 個々のアプリケーションで Mac の API 呼び出しをするのは大変ですから。 > 同様にすれば，たとえばWindows環境においてはWindowsに沿った処理をするよ > うにできますが，ソフトウェアによって実装が難しいだろうと思います． そういったのをまとめて面倒みてくれるライブラリがあると良いのかも しれません。 # 深く考えていないので、余計混乱が増えることを言っているかもしれま # せんが。 > > 文字が表示されてもマッピングが異なっていると困ることはあるような。 > > 実はその通りです…が，少なくともマッピングが異なる文字が混在するのは， > UTF-8などを直接取り込めるようになると不可避かと思っていますので，私は > さらに別の問題として考えています．ちょっと，これについては書きかけの文 > 章を後から投稿します． そうですね。避けて通れない問題ですが、別問題になります。 > > 未公開領域だけに見れませんが、そんな衝撃的なものがあったのですか。 > > 昔使ったHTMLファイルを密送しましょうか？（笑） メーリングリストで話をしてて密送になるのかわかりませんが、見せていた だけるなら欲しいですね。 # こっそり、笑いたいです。(^^; -- ===================================================================== 寺西 忠勝(TADAMASA TERANISHI) yw3t-trns ＠ asahi-net.or.jp http://www.asahi-net.or.jp/~yw3t-trns/index.htm Key fingerprint = 474E 4D93 8E97 11F6 662D 8A42 17F5 52F4 10E7 D14E From y.naoi ＠ glamour.co.jp Fri Apr 7 14:51:01 2006 From: y.naoi ＠ glamour.co.jp (NAOI Yasushi) Date: Fri, 7 Apr 2006 14:51:01 +0900 Subject: [LE-talk-ja 40] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TIA==?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: References: <20060404130547.B376.MSYK@mtg.biglobe.ne.jp> <682059D7-3F32-47A4-843C-8CC5517179FE@mac.com> <20060405115031.B383.MORIYAMA@miraclelinux.com> <4433DB20.8090104@mtg.biglobe.ne.jp> <44340698.7070206@airemix.com> <4434200F.71140409@asahi-net.or.jp> <44347B82.4070109@airemix.com> <4434BD4B.4C5DD39E@asahi-net.or.jp> <4435D539.3010707@airemix.com> Message-ID: <8AD2AAD9-612A-4F2D-B6B4-D81A3C5D65AC@glamour.co.jp> On 2006/04/07, at 13:19, Kazuhiro Kazama wrote: > それで，Macに関して問題があまり認識されていない理由とし > ては，私がApple > Computerに問題を報告したことで，比較的早期に何らかの対処をして > 頂いたか > らかもしれません．かなり昔に検証したので詳しいことは忘れてし > まったので > すが，少なくともマッピングが異なっていても文字は表示されるよう > にフォン > トを変更して頂いたと思います．もしかすると森山さんが拒否された > 提案のよ > うに既存文字符号化への変換の際の変換テーブルにも手が入っていた > かもしれ > ません． 「マッピングが異なっていても文字は表示される」というのはどういう 意味ですか？　Macユーザですが、それらしい例を思いつかない ので。 -- 直井@Glamour Profession, Inc. From moriyama ＠ miraclelinux.com Fri Apr 7 20:45:39 2006 From: moriyama ＠ miraclelinux.com (MORIYAMA Masayuki) Date: Fri, 7 Apr 2006 20:45:39 +0900 (JST) Subject: [LE-talk-ja 41] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TICA=?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <9FEE10D9-F2FB-4735-8A6C-9F741F438338@mac.com> References: <20060407131331.B3C0.MORIYAMA@miraclelinux.com> <9FEE10D9-F2FB-4735-8A6C-9F741F438338@mac.com> Message-ID: <20060407203104.B3D0.MORIYAMA@miraclelinux.com> 森山です。 Kazuhiro Kazama wrote: > > On 2006/04/07, at 13:37, MORIYAMA Masayuki wrote: > > かなり変則的なコードと言えます。 > > これは，すぐ直して貰えるような単純なバグと考えてよいのでしょうか？それ > とも仕様？ [becky-ml:08217] Re: IBM 選定 IBM 拡張文字 http://b2search.tietew.net/archive/becky-ml/8217 意図的にやっているようです。 Becky! で シフトJIS の0xF040(0xF09F) 以上のコードを処理した時のコード を読める必要はないと思っています。 From yw3t-trns ＠ asahi-net.or.jp Fri Apr 7 22:07:10 2006 From: yw3t-trns ＠ asahi-net.or.jp (Tadamasa Teranishi) Date: Fri, 07 Apr 2006 22:07:10 +0900 Subject: [LE-talk-ja 42] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TICAg?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= References: <20060407131331.B3C0.MORIYAMA@miraclelinux.com> <9FEE10D9-F2FB-4735-8A6C-9F741F438338@mac.com> <20060407203104.B3D0.MORIYAMA@miraclelinux.com> Message-ID: <443663FE.99E45B8D@asahi-net.or.jp> 寺西です。 MORIYAMA Masayuki wrote: > > Kazuhiro Kazama wrote: > > > > On 2006/04/07, at 13:37, MORIYAMA Masayuki wrote: > > > かなり変則的なコードと言えます。 > > > > これは，すぐ直して貰えるような単純なバグと考えてよいのでしょうか？それ > > とも仕様？ > > [becky-ml:08217] Re: IBM 選定 IBM 拡張文字 > http://b2search.tietew.net/archive/becky-ml/8217 > > 意図的にやっているようです。 ちゃんと理解していませんが、ISO-2022 としては正しいという主張の ようですが... これでは ISO-2022-JP じゃないのでは??? これを ISO-2022-JP だとして送っているのなら、問題なのではないかと 思います。(誤解していますかね?) かといって、これを何だといって送っているのやら。 # 何でこんな実装をしたのやら。 森山さんの http://webdav-jp.ml.nemui.org/msg00810.html にもう少し情報がありましたが、Outlook Express の実装は95区以降が 入力されることを想定していない単純なバグ、Becky! は独自路線だと 思えます。 それらは個々のアプリケーションの問題で、送られてきたデータを救済 するとかよりも、アプリケーション側に修正してもらうべき話だと 思います。 > Becky! で シフトJIS の0xF040(0xF09F) 以上のコードを処理した時のコード > を読める必要はないと思っています。 Becky! に限らず 95区以降読める必要はないでしょうし、 通す(送る)必要もないはずですが...。 -- ===================================================================== 寺西 忠勝(TADAMASA TERANISHI) yw3t-trns ＠ asahi-net.or.jp http://www.asahi-net.or.jp/~yw3t-trns/index.htm Key fingerprint = 474E 4D93 8E97 11F6 662D 8A42 17F5 52F4 10E7 D14E From taca ＠ back-street.net Fri Apr 7 22:11:23 2006 From: taca ＠ back-street.net (Takahiro Kambe) Date: Fri, 07 Apr 2006 22:11:23 +0900 (JST) Subject: [LE-talk-ja 43] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TIA==?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <443663FE.99E45B8D@asahi-net.or.jp> References: <9FEE10D9-F2FB-4735-8A6C-9F741F438338@mac.com> <20060407203104.B3D0.MORIYAMA@miraclelinux.com> <443663FE.99E45B8D@asahi-net.or.jp> Message-ID: <20060407.221123.74752689.taca@back-street.net> こんばんは。 In message <443663FE.99E45B8D ＠ asahi-net.or.jp> on Fri, 07 Apr 2006 22:07:10 +0900, Tadamasa Teranishi wrote: > > [becky-ml:08217] Re: IBM 選定 IBM 拡張文字 > > http://b2search.tietew.net/archive/becky-ml/8217 > > > > 意図的にやっているようです。 > > ちゃんと理解していませんが、ISO-2022 としては正しいという主張の > ようですが... これでは ISO-2022-JP じゃないのでは??? ISO-2022とISO-2022-JP(やISO-8859-1とか)の関係を理解されていません。 > これを ISO-2022-JP だとして送っているのなら、問題なのではないかと > 思います。(誤解していますかね?) ちょっと酷いです。(あぁ、だから巷のメールのツールは「JIS」って表現して るのかな?) -- 神戸 隆博 / Takahiro Kambe From yw3t-trns ＠ asahi-net.or.jp Fri Apr 7 22:21:25 2006 From: yw3t-trns ＠ asahi-net.or.jp (Tadamasa Teranishi) Date: Fri, 07 Apr 2006 22:21:25 +0900 Subject: [LE-talk-ja 44] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TICA=?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= References: <9FEE10D9-F2FB-4735-8A6C-9F741F438338@mac.com> <20060407203104.B3D0.MORIYAMA@miraclelinux.com> <443663FE.99E45B8D@asahi-net.or.jp> <20060407.221123.74752689.taca@back-street.net> Message-ID: <44366755.C3A27F3B@asahi-net.or.jp> 寺西です。 # あれ。やっちゃったかな? Takahiro Kambe wrote: > > > ちゃんと理解していませんが、ISO-2022 としては正しいという主張の > > ようですが... これでは ISO-2022-JP じゃないのでは??? > ISO-2022とISO-2022-JP(やISO-8859-1とか)の関係を理解されていません。 理解していないのは私が? Becky! が? どちらでしょう。 私が間違っている場合は、ご指摘いただけると助かります。 -- ===================================================================== 寺西 忠勝(TADAMASA TERANISHI) yw3t-trns ＠ asahi-net.or.jp http://www.asahi-net.or.jp/~yw3t-trns/index.htm Key fingerprint = 474E 4D93 8E97 11F6 662D 8A42 17F5 52F4 10E7 D14E From taca ＠ back-street.net Fri Apr 7 22:31:09 2006 From: taca ＠ back-street.net (Takahiro Kambe) Date: Fri, 07 Apr 2006 22:31:09 +0900 (JST) Subject: [LE-talk-ja 45] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TIA==?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <44366755.C3A27F3B@asahi-net.or.jp> References: <443663FE.99E45B8D@asahi-net.or.jp> <20060407.221123.74752689.taca@back-street.net> <44366755.C3A27F3B@asahi-net.or.jp> Message-ID: <20060407.223109.41631268.taca@back-street.net> In message <44366755.C3A27F3B ＠ asahi-net.or.jp> on Fri, 07 Apr 2006 22:21:25 +0900, Tadamasa Teranishi wrote: > # あれ。やっちゃったかな? まぎわらしくてすみません。 > Takahiro Kambe wrote: > > > > > ちゃんと理解していませんが、ISO-2022 としては正しいという主張の > > > ようですが... これでは ISO-2022-JP じゃないのでは??? > > ISO-2022とISO-2022-JP(やISO-8859-1とか)の関係を理解されていません。 > > 理解していないのは私が? Becky! が? どちらでしょう。 Beck!の方です。 ISO-2022は、ISO-2022-JPのような具体的なエンコーディングを決める枠組み のような規格です。ISO-2022で決められている方法を取捨選択して、実際に決 めたISO-2022-JPでは、SI(Shift-In)やSO(Shift-Out)は規定していませんから、 使ってはいけないことになります。 -- 神戸 隆博 / Takahiro Kambe From yw3t-trns ＠ asahi-net.or.jp Fri Apr 7 23:58:44 2006 From: yw3t-trns ＠ asahi-net.or.jp (Tadamasa Teranishi) Date: Fri, 07 Apr 2006 23:58:44 +0900 Subject: [LE-talk-ja 46] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TICA=?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= References: <443663FE.99E45B8D@asahi-net.or.jp> <20060407.221123.74752689.taca@back-street.net> <44366755.C3A27F3B@asahi-net.or.jp> <20060407.223109.41631268.taca@back-street.net> Message-ID: <44367E24.56712ED8@asahi-net.or.jp> 寺西です。 Takahiro Kambe wrote: > > > 理解していないのは私が? Becky! が? どちらでしょう。 > Beck!の方です。 安心しました。 > ISO-2022は、ISO-2022-JPのような具体的なエンコーディングを決める枠組み > のような規格です。ISO-2022で決められている方法を取捨選択して、実際に決 > めたISO-2022-JPでは、SI(Shift-In)やSO(Shift-Out)は規定していませんから、 > 使ってはいけないことになります。 理解していた内容と一致しておりました。 -- ===================================================================== 寺西 忠勝(TADAMASA TERANISHI) yw3t-trns ＠ asahi-net.or.jp http://www.asahi-net.or.jp/~yw3t-trns/index.htm Key fingerprint = 474E 4D93 8E97 11F6 662D 8A42 17F5 52F4 10E7 D14E From naruse ＠ airemix.com Mon Apr 10 06:42:09 2006 From: naruse ＠ airemix.com (NARUSE, Yui) Date: Mon, 10 Apr 2006 06:42:09 +0900 Subject: [LE-talk-ja 47] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TIA==?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <4435E422.D6115079@asahi-net.or.jp> References: <20060404130547.B376.MSYK@mtg.biglobe.ne.jp> <682059D7-3F32-47A4-843C-8CC5517179FE@mac.com> <20060405115031.B383.MORIYAMA@miraclelinux.com> <4433DB20.8090104@mtg.biglobe.ne.jp> <44340698.7070206@airemix.com> <4434200F.71140409@asahi-net.or.jp> <44347B82.4070109@airemix.com> <4434BD4B.4C5DD39E@asahi-net.or.jp> <4435D539.3010707@airemix.com> <4435E422.D6115079@asahi-net.or.jp> Message-ID: <44397FB1.1020601@airemix.com> 成瀬です。 Tadamasa Teranishi wrote: > 受け取り側の対応コード以外のものが送られてくれば、それは想定外のデータ > でしょう。 > で、CP-932, EUC-JP, UTF-8 ぐらいは対応していても、CP51932 とかは > 想定していないケースがほとんどかと。 > # CP51932 を想定していたのなら、それなりに対処もしているでしょうし。 どの範囲のユーザを想定するのかという話になってしまいますが、 「JIS X 0208」という言葉をしらない人が「EUC-JP」を指定した場合、 想定しているのは「ひらがなとか漢字とか」程度なので、 想定内か想定外かというのははっきりしないかと。 >>> もし、そのような文字を使いたいのであれば、そもそもアプリケーションを >>> UTF-8 で設計すべきではないか、と思います。 >> これから作るならばそうなりますね。 > > いや、今でも使いたいなら UTF-8 に移行すべきであって、CP51932 とか > で使おうとするのが良いことではないだろうと思います。例え、使える > ようになったとしてもです。 システムが複数のモジュールから構成されていて、 かつそのモジュールのうちいくつかが UTF-8 非対応の場合、 モジュールを置き換えるまで延命が必要でしょう。 >>> CP932 と eucJP-ms と それ以外とではかなり事情が違うと思います。 >>> CP932 に関しては Shift_JIS と使い分けているといえるでしょう。 >>> しかし、それ以外はそうかどうかは疑問が残ります。 >> eucJP-ms の事情がご理解いただけるのならば、 >> それは環境の違いかと思います。 >> わたしは eucJP-ms より CP51932 の方が欲しいくらいなので。 > > その理由を説明していただけますか? > > CP51932 を使っているのは IE (および他のブラウザ?)から送られてくる > データぐらいしか知りませんが、他にありますか? Windows のテキストエディタで、ファイルを EUC-JP として保存した場合、 それは CP51932 ですね。 >>>> けれど、説得力のあるニーズを示すデータは難しいですね。 >>> ... >>>> しかし、他に「数字」が出る指標があるかというと、うーん。。。 >>> ようするに裏づけされたデータがないということで、なんとなくそうなん >>> じゃないかという感覚的なものなのでしょう。 >> いえ、わたし自身は CP51932 は意図して使っています。 > > それは成瀬さんがということであって、相当の人がということには > なりませんよね。 > (使い分けている人がいないと言っているのではなくて、相当の人が > 使い分けているかどうかは疑問があると言っているわけですから。) 使い分けている人は現状多くは無いと思います。 が、自分の思っていた「EUC-JP」が実は CP51932 だった、 という人はかなり多いのではないでしょうか。 # Windows で 3バイト EUC を扱えるエディタってあまりないですし。 >> むしろ、eucJP-ms より CP51932 の方が使いますね。 >> # ゲイツ側の人間なので。 > > Windows よりの設計をするのはわからないわけではないですが、自ら公言され > ては、設計が偏っていると受け取られかねないですよ。 > # Windows はもちろん無視できるわけではありませんが。 自分が偏っていることを自覚しているので、あえて公言し、 誰かが補正してくださることを期待しています。 その点、寺西さんには本当に感謝しています。 >>> CP932 とかは生かさなければならないでしょうけど、CP51932 を生かさ >>> なければならないか(個々の事情で生かさなければならない場合はあるで >>> しょうけれども)というのは疑問です。 >> 例えば CGI/Perl は EUC-JP で書く習慣がありましたから、 >> 掲示板のログ等で潜在的に CP51932 のデータが大量に眠ってはいます。 > > つまり現状死んでいるわけです。 Windows から「日本語 (EUC)」として読めば普通に見れますから、 「死んでいる」は語弊があるかと。 “dying”ではありますな。 >> その大量のデータのうち、どの程度の割合が残すに値するかの判断は、 >> わたしにはつきかねます。 >> # が、自分の管理している範囲では全て残しますね。 > > 現状死んでいるデータを本当に生かしたいですか? > CP51932 のデータは、本当に全てCP51932 のデータなのでしょうか? > 他のEUC系のコードと混在していたりしませんか? > 生かそうとしてはまったりすることはないのでしょうか? CP51932 と eucJP-ms が混在しているというのは、ありえますし、 厄介なシナリオですが、読み出しに限れば、 eucJP-ms のユーザ定義文字領域を NEC選定IBM拡張文字とみなす、 というバッドノウハウは可能ですね。 > 両方向提供すること自体は必ずしも悪いわけではありませんが、 > それにより、レガシーエンコーディングのまま、より悪い方向で拡張された > アプリケーションが増えてしまって、かえって Unicode への移行を妨げる > ことになるのではないかと懸念します。(と、レガシーエンコーディング > のデータが増えて、移行の際により混乱を拡大しそうです。) > > 両方向提供するのと同時に、レガシーエンコーディングへの変換は最小限 > に注意して使うようにするのと、Unicode への移行を推奨するといった > 内容を含むガイドライン等を示す必要があるのではないかと思います。 あくまでレガシーであるというのを強調するのはいいですね。 Shift_JIS や EUC-JP がレガシーであることを、 （知るべきなのに）まだ知らない人って多そうですし。 > 遠い将来はそうでしょうが、レガシーエンコーディングの環境が整うと、 > しばらくレガシーエンコーディングのまま使い続ける可能性も出てくる > ような気がします。 > そこを心配しているわけです。 環境を整えなかった場合、 全面的にレガシーなシステムのまま限界まで使い、 一二の三で一気に Unicode、というシナリオになるのでしょうが、 それですと、MySQL 4.1 の二の舞になるように思います。 http://www.mysql.gr.jp/mysqlml/mysql/msg/12372 >>> ついでに。 >>> シェアの問題でしょうけれども Windows のコード中心なのも気になります。 >>> Macintosh は? とか、携帯電話の絵文字は? とかもあるわけです。 >>> 特に携帯電話は無視できる数ではないので、Windows のコードだけ考えて >>> いても...という気もします。 >> Macintosh は？というツッコミはわたしも考えたのですけれど、 >> 実際にニーズを伴った発言はなぜか見かけませんね。 > > Macintosh ユーザは歴史的にものわかりが良くて、困っていてもそんなもの > だと割り切って使う人が多いですからね。そうじゃないと、Windows じゃ > なくてわざわざ Mac を使ったりしませんし。 思うに、Windows の機種依存データは外の環境に出て行きやすいが、 Mac の機種依存データは Mac の環境内で処理され、外に出てこないので、 問題が顕在化しづらいのかもしれません。 # Mac 上では MAC-JAPANESE に対応した iconv があるので -- NARUSE, Yui DBDB A476 FDBD 9450 02CD 0EFC BCE3 C388 472E C1EA From naruse ＠ airemix.com Mon Apr 10 08:12:48 2006 From: naruse ＠ airemix.com (NARUSE, Yui) Date: Mon, 10 Apr 2006 08:12:48 +0900 Subject: [LE-talk-ja 48] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TIA==?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: References: <20060404130547.B376.MSYK@mtg.biglobe.ne.jp> <682059D7-3F32-47A4-843C-8CC5517179FE@mac.com> <20060405115031.B383.MORIYAMA@miraclelinux.com> <4433DB20.8090104@mtg.biglobe.ne.jp> <44340698.7070206@airemix.com> <4434200F.71140409@asahi-net.or.jp> <44347B82.4070109@airemix.com> <4434BD4B.4C5DD39E@asahi-net.or.jp> <4435D539.3010707@airemix.com> Message-ID: <443994F0.7030309@airemix.com> 成瀬です。 Kazuhiro Kazama wrote: >> 携帯の絵文字はニーズが結構あるようですが、 >> これの対応表は・・・あるんですかね？ > > NTT DoCoMoのiモードのページを見れば，Shift-JISやUnicodeでどの部分に割 > り当てられているかがわかります．ただし，割り当てられている領域は，それ > ぞれ外字領域，私用領域です． 各社のサイトでShift_JISとUnicodeの対応は見ました。 ここで「これの対応表」と言っているのは、各社絵文字同士の対応ですね。 と、「携帯の絵文字対応」と言った場合、ベンダごとに閉じた中で、 Shift_JIS と Unicode の間でだけ変換できればいいのですかね。 > これらの文字をUnicodeに正式に収録する提案は，Apple ComputerやMicrosoft > などからもおこなわれたですが，拒否されたようです．実は私も打診したこと > があります．私の口からは理由ははっきり言うことはできませんが，実際にど > のような文字が収録されているかを…特に未公開領域に…見て頂ければ，収録 > できない理由はすぐ推測できると思います（謎）．衝撃です． えーっと、調べてみたのですが、ぴーな絵文字ですか？（謎 いつ収録されるのかなーと思ってはいたのですが、無理そうですね、残念。 ぴーな絵文字以外にも理由があるのでしたら、わたしもHTMLを見てみたいです。 >> Vodafone が公開しているのは見つけましたが、 >> http://www.vodafone.jp/3G/live/mail/pict_convert.html > > こちらは文字としてではなく，単なる絵として扱われていた記憶があります． これの意図は絵文字番号（絵文字画像のファイル名の番号）同士で、 対応がなされている→ベンダ横断な変換ができる、という意味です。 っと、auによる au と i-mode の対応表もあるのですね。 http://www.au.kddi.com/ezfactory/tec/spec/icon_i_k.html -- NARUSE, Yui DBDB A476 FDBD 9450 02CD 0EFC BCE3 C388 472E C1EA From moriyama ＠ miraclelinux.com Mon Apr 10 11:23:20 2006 From: moriyama ＠ miraclelinux.com (MORIYAMA Masayuki) Date: Mon, 10 Apr 2006 11:23:20 +0900 (JST) Subject: [LE-talk-ja 49] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TICAg?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <443663FE.99E45B8D@asahi-net.or.jp> References: <20060407203104.B3D0.MORIYAMA@miraclelinux.com> <443663FE.99E45B8D@asahi-net.or.jp> Message-ID: <20060410103954.B3E0.MORIYAMA@miraclelinux.com> 森山です。 > 森山さんの > http://webdav-jp.ml.nemui.org/msg00810.html > にもう少し情報がありましたが、Outlook Express の実装は95区以降が > 入力されることを想定していない単純なバグ、Becky! は独自路線だと > 思えます。 > > それらは個々のアプリケーションの問題で、送られてきたデータを救済 > するとかよりも、アプリケーション側に修正してもらうべき話だと > 思います。 Becky! に対しては、次の例を出して修正依頼を出しておきました。 http://www2d.biglobe.ne.jp/~msyk/cgi-bin/charcode/bbs.cgi?c=gr&n=361 次期バージョンで修正するとの事です。 >>Becky! で シフトJIS の0xF040(0xF09F) 以上のコードを処理した時のコード >>を読める必要はないと思っています。 > > > Becky! に限らず 95区以降読める必要はないでしょうし、 > 通す(送る)必要もないはずですが...。 CP5022X でのユーザ定義文字は、JIS X 0208 が G0 集合に指示されている状態 で、0x7F〜0x92 が来るわけですが、これを ISO 2022 として正しく解釈して1バ イトコードとして処理すると、ユーザ定義文字の2バイト目が取り残されてしま います。その取り残されたバイトを JIS X 0208 の 1 バイト目だとして処理す る事になってしまいます。その事により、それ以降の文字が文字化けしてしま うという事になってしまいます。 CP932 の F040 (ユーザ定義文字) 82A0 (あ) を CP5022X へ変換し、それを正規 の ISO 2022 で解釈すると次のようになります。 あ ----- ----- CP932 F0 40 82 A0 ----- ----- CP5022X 1B 24 42 7F 21 24 22 -- ----- -- ↑ ↑ │ ユーザ定義文字の2 バイト目と次の文字の1バイト目 │ が JIS X 0208 の文字として解釈されてしまう。 │ 1バイトコード(制御コード)として解釈 ユーザ定義文字のエスケープシーケンスとして、ESC $ ( ? を使う ISO-2022-JP-MS では、CP5022X のユーザ定義文字は救済しない代わりに、 ISO/IEC 2022(JIS X 0202) の枠組みの中で、ユーザ定義文字を安全に扱うた めの方法を提示してみました。 RFC化の事を視野に入れて、ISO 2022 から逸脱するものは排除して、新たに ISO 2022 の枠組みの中で、ユーザ定義文字の扱いを提示することにより、 Windows のCP5022X のような実装を行う事への歯止めにならないかとも考えま した。 しかし、「過去の資産の継承」を考えるなら、CP5022X でのユーザ定義文字に よって、ユーザ定義文字に続く JIS X 0208 の文字が文字化けしてしまう事を 避ける意味でも、ISO 2022 から逸脱している CP5022X のユーザ定義文字を Unicode に変換できるようにしておいた方が良いのかもしれません。 (この場合、Unicode から 7ビットJIS への変換では、ユーザ定義文字は変換 しない。) -- 森山 将之 moriyama ＠ miraclelinux.com ミラクル・リナックス株式会社 From moriyama ＠ miraclelinux.com Mon Apr 10 19:19:54 2006 From: moriyama ＠ miraclelinux.com (MORIYAMA Masayuki) Date: Mon, 10 Apr 2006 19:19:54 +0900 (JST) Subject: [LE-talk-ja 50] =?iso-2022-jp?b?TGVnYWN5IEVuY29kaW5nIBskQiVXGyhC?= =?iso-2022-jp?b?GyRCJW0lOCUnJS8lSCVaITwlOBsoQg==?= Message-ID: <20060410154859.B3FB.MORIYAMA@miraclelinux.com> 森山です。 Legacy Encoding Project のプロジェクトページが、SourceForge.jp へのリ ンクのみでしたので、Wiki でページを作成し公開しました。 http://legacy-encoding.sourceforge.jp/ cp932, cp51932, eucJP-ms, ISO-2022-JP-MS の簡単なコード割り当ての表と、 NEC特殊文字、NEC選定IBM拡張文字、IBM拡張文字 の一覧を載せておきました。 Macintsoh、携帯の絵文字についても、メーリングリストで出てきた Web ペー ジへのリンクを作っておきました。 -- 森山 将之 moriyama ＠ miraclelinux.com ミラクル・リナックス株式会社 From moriyama ＠ miraclelinux.com Mon Apr 10 19:52:57 2006 From: moriyama ＠ miraclelinux.com (MORIYAMA Masayuki) Date: Mon, 10 Apr 2006 19:52:57 +0900 (JST) Subject: [LE-talk-ja 51] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TIA==?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <443994F0.7030309@airemix.com> References: <443994F0.7030309@airemix.com> Message-ID: <20060410192102.B404.MORIYAMA@miraclelinux.com> 森山です。 "NARUSE, Yui" wrote: > 各社のサイトでShift_JISとUnicodeの対応は見ました。 > ここで「これの対応表」と言っているのは、各社絵文字同士の対応ですね。 > > と、「携帯の絵文字対応」と言った場合、ベンダごとに閉じた中で、 > Shift_JIS と Unicode の間でだけ変換できればいいのですかね。 Perl 用のモジュールに限った話になりますが、いくつかあるモジュールに関 して調べてみたところ、次のようになっていました。 ○ Encode::JP::Mobile モジュール キャリアが示すマッピングを用いているようです。 http://blog.bulknews.net/mt/archives/001742.html ○ Unicode::Japanese Unicode へ変換した時にキャリア毎に別々のコード領域にマッピングされる ように独自のマッピングになっているようです。 http://tech.ymirlink.co.jp/perl/cpan/Unicode-Japanese-0.27/unicodej.html ○ EscapeSJIS.pm モジュール 次のようになっています。 http://www.kawa.net/works/perl/i18n-emoji/i18n-emoji.html#EscapeSJIS ---- なお、ボーダフォン絵文字については、ボーダフォン社のJava 環境 (Vアプ リケーション仕様) では各絵文字が Unicode の E001〜E55A にマップされま すが、本仕様では EZ 絵文字との重複マッピングを避けるため、 F001〜F55A に移動しています。 ---- -- 森山 将之 moriyama ＠ miraclelinux.com ミラクル・リナックス株式会社 From kazama ＠ mac.com Tue Apr 11 19:10:30 2006 From: kazama ＠ mac.com (Kazuhiro Kazama) Date: Tue, 11 Apr 2006 19:10:30 +0900 Subject: [LE-talk-ja 52] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TIA==?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <8AD2AAD9-612A-4F2D-B6B4-D81A3C5D65AC@glamour.co.jp> References: <20060404130547.B376.MSYK@mtg.biglobe.ne.jp> <682059D7-3F32-47A4-843C-8CC5517179FE@mac.com> <20060405115031.B383.MORIYAMA@miraclelinux.com> <4433DB20.8090104@mtg.biglobe.ne.jp> <44340698.7070206@airemix.com> <4434200F.71140409@asahi-net.or.jp> <44347B82.4070109@airemix.com> <4434BD4B.4C5DD39E@asahi-net.or.jp> <4435D539.3010707@airemix.com> <8AD2AAD9-612A-4F2D-B6B4-D81A3C5D65AC@glamour.co.jp> Message-ID: 遅くなりました． On 2006/04/07, at 14:51, NAOI Yasushi wrote: > 「マッピングが異なっていても文字は表示される」というのはどういう > 意味ですか？　Macユーザですが、それらしい例を思いつかない > ので。 普通にMacで使っていたら，体験しないかもしれません． たとえば，異なるコンバータでUnicodeに変換した時に一部の文字のマッピン グが違う場合とか，そのような文字を明示的にUnicodeの符号位置で指定した 場合の話です． --- 風間 一洋 (kazama ＠ mac.com) From kazama ＠ mac.com Tue Apr 11 19:49:01 2006 From: kazama ＠ mac.com (Kazuhiro Kazama) Date: Tue, 11 Apr 2006 19:49:01 +0900 Subject: [LE-talk-ja 53] =?iso-2022-jp?b?UmU6IExlZ2FjeSBFbmNvZGluZyA=?= =?iso-2022-jp?b?GyRCJVclbSU4JSclLyVIJVohPCU4GyhC?= In-Reply-To: <20060410154859.B3FB.MORIYAMA@miraclelinux.com> References: <20060410154859.B3FB.MORIYAMA@miraclelinux.com> Message-ID: 森山さん， On 2006/04/10, at 19:19, MORIYAMA Masayuki wrote: > Legacy Encoding Project のプロジェクトページが、SourceForge.jp へのリ > ンクのみでしたので、Wiki でページを作成し公開しました。 > > http://legacy-encoding.sourceforge.jp/ > > cp932, cp51932, eucJP-ms, ISO-2022-JP-MS の簡単なコード割り当ての表 > と、 > NEC特殊文字、NEC選定IBM拡張文字、IBM拡張文字 の一覧を載せておきまし > た。 ISO-2022-JP-MSですが，案という形式ではなく，まず現在の実装がどうなって いるのかという観点で整理した方がよいと思います．まず，現在どのように なっているかをここの参加者が認識することが必要だと思うので． あと，例のOSSソフトウェアのサポート表があるといいですね． --- 風間 一洋 (kazama ＠ mac.com) From moriyama ＠ miraclelinux.com Wed Apr 12 11:22:54 2006 From: moriyama ＠ miraclelinux.com (MORIYAMA Masayuki) Date: Wed, 12 Apr 2006 11:22:54 +0900 (JST) Subject: [LE-talk-ja 54] =?iso-2022-jp?b?UmU6IExlZ2FjeSBFbmNvZGluZyA=?= =?iso-2022-jp?b?GyRCJVclbSU4JSclLyVIJVohPCU4GyhC?= In-Reply-To: References: <20060410154859.B3FB.MORIYAMA@miraclelinux.com> Message-ID: <20060412111609.B41F.MORIYAMA@miraclelinux.com> 風間さん、ご指摘ありがとうございます。 ISO-2022-JP-MS のページを整理し、案2,案3 を提案1,提案2として別ページに しました。 CP50220 に関して一部誤解があるようで、7bit-eucJP-ms として載せておきま した。 Unicode コンソーシアムで配布されている CP932.TXT や TOG/JVC の eucJP-ms の変換表を元に作成した基準となる変換表、およびその基準となる 変換表と実際の OSS での変換との差分などもページにあげていく予定です。 Kazuhiro Kazama wrote: > ISO-2022-JP-MSですが，案という形式ではなく，まず現在の実装がどうなって > いるのかという観点で整理した方がよいと思います．まず，現在どのように > なっているかをここの参加者が認識することが必要だと思うので． > > あと，例のOSSソフトウェアのサポート表があるといいですね． -- 森山 将之 moriyama ＠ miraclelinux.com ミラクル・リナックス株式会社 From moriyama ＠ miraclelinux.com Wed Apr 12 12:04:53 2006 From: moriyama ＠ miraclelinux.com (MORIYAMA Masayuki) Date: Wed, 12 Apr 2006 12:04:53 +0900 (JST) Subject: [LE-talk-ja 55] =?iso-2022-jp?b?GyRCNHBLXDtFTU0bKEI=?= Message-ID: <20060412114057.B423.MORIYAMA@miraclelinux.com> 森山です。 cp932, cp51932, eucJP-ms, ISO-2022-JP-MS の定義および Unicode との変換 を「基本仕様書」のドラフト版を次の場所にアップしました。 ISO-2022-JP-MS に関しては、ユーザ定義文字の扱いに関して変更になるかも しれませんが、現状では ESC $ ( ? としています。 http://sourceforge.jp/docman2/?group_id=2198 今までの説明でなかった点として、重複定義されている文字の変換を明示しま した。 重複定義文字に関する Unicode から(MS)レガシーエンコーディングへの変換 ルールを簡単に説明すると次のようになります。 次の変換規則を番号の若い順番から適用していきコード変換を行う。 1. JIS X 0208:1997 で定義されている文字であれば、JIS X 0208:1997 の符 号位置に変換する。 2. NEC特殊文字で定義されている文字であれば、NEC特殊文字の符号位置に変 換する。 3. IBM拡張文字で定義されている文字であれば、IBM拡張文字の符号位置に変 換する。 4. IBM拡張文字の符号位置が存在しない場合は、NEC選定IBM拡張文字の符号位 置に変換する。 マイクロソフト > [PRB] SHIFT - JIS と Unicode 間の変換問題 http://support.microsoft.com/default.aspx?scid=kb;ja;JP170559 上記の、変換表がベースとなっています。 ここで説明している変換については、別途 ucm ファイルとして公開予定して います。 -- 森山 将之 moriyama ＠ miraclelinux.com ミラクル・リナックス株式会社 From kazama ＠ mac.com Wed Apr 12 15:24:39 2006 From: kazama ＠ mac.com (Kazuhiro Kazama) Date: Wed, 12 Apr 2006 15:24:39 +0900 Subject: [LE-talk-ja 56] =?iso-2022-jp?b?UmU6IBskQjRwS1w7RU1NGyhC?= In-Reply-To: <20060412114057.B423.MORIYAMA@miraclelinux.com> References: <20060412114057.B423.MORIYAMA@miraclelinux.com> Message-ID: <40682A6A-AA5F-4E02-B1B8-4E1A3BE02B51@mac.com> On 2006/04/12, at 12:04, MORIYAMA Masayuki wrote: > ISO-2022-JP-MS に関しては、ユーザ定義文字の扱いに関して変更になるかも > しれませんが、現状では ESC $ ( ? としています。 なお，次のような別の角度から書かれた図を見つけました． http://www2d.biglobe.ne.jp/~msyk/charcode/cp932/cp932mapping.png これを見るに，私は検討対象としてはCodepage 50221の方がまだよいと思いま す． ISO-2022-JP-MSは，次の点で検討する意味があまりないと思います． ・特別なJIS符号化方式が要求されるとしても，それはWindows環境との互換性 が理由だろう． ・用途を考えるとユーザ定義文字をサポートするのは，望ましくない・意味が ない． ・名前が誤解を与えやすい（ISO-2022-JPでもなく，eucJP-msとも非互換）． ・実装例がほとんどない(libiconv程度) ・ISO-2022-JP-MSは森山さん以外の賛成意見がなかった． --- 風間 一洋 (kazama ＠ mac.com) From moriyama ＠ miraclelinux.com Wed Apr 12 20:37:06 2006 From: moriyama ＠ miraclelinux.com (MORIYAMA Masayuki) Date: Wed, 12 Apr 2006 20:37:06 +0900 (JST) Subject: [LE-talk-ja 57] =?iso-2022-jp?b?UmU6IBskQjRwS1w7RU1NGyhC?= In-Reply-To: <40682A6A-AA5F-4E02-B1B8-4E1A3BE02B51@mac.com> References: <20060412114057.B423.MORIYAMA@miraclelinux.com> <40682A6A-AA5F-4E02-B1B8-4E1A3BE02B51@mac.com> Message-ID: <20060412172605.B42F.MORIYAMA@miraclelinux.com> 森山です。 Kazuhiro Kazama wrote: > > On 2006/04/12, at 12:04, MORIYAMA Masayuki wrote: > > ISO-2022-JP-MS に関しては、ユーザ定義文字の扱いに関して変更になるかも > > しれませんが、現状では ESC $ ( ? としています。 > > なお，次のような別の角度から書かれた図を見つけました． > > http://www2d.biglobe.ne.jp/~msyk/charcode/cp932/cp932mapping.png > > これを見るに，私は検討対象としてはCodepage 50221の方がまだよいと思いま > す． cp50221 互換とする場合、Windows では次のようにユーザ定義文字を 94x94 集合に収まらない領域を使って表現しているので、ここの所の扱いをどうする か明確にする必要があると考えています。 http://legacy-encoding.sourceforge.jp/wiki/index.php?plugin=attach&pcmd=open&file=cp5022x_cp932_map.png&refer=ISO-2022-JP-MS 提案2 では、7ビットJIS から Unicode へ変換する際には、cp5022x のユーザ 定義文字を受け付けるようにし、Unicode から 7ビットJISへの変換では、ユー ザ定義文字は変換しないようになっています。 提案2 http://legacy-encoding.sourceforge.jp/wiki/index.php?%C4%F3%B0%C62 成瀬さんも cp50221 を推していますが、ISO 2022 から逸脱している形でエン コードされているユーザ定義文字に関しては救うが、7ビットJIS へは変換し ないと考えていると理解して、提案2 のようにしました。 "NARUSE, Yui" wrote: > ユーザ定義文字が ISO 2022 から逸脱するのは、 > 確かに問題だとも思いますが、 > すでに逸脱した形でエンコードされたデータが > 相当数存在するシステムで用いられるのですし、 > ユーザ定義文字を出力しない CP50221 でいい気もします。 Sylpheed は現在、提案2 に近い実装になっています。 当初、Sylpheed での機種依存文字対応は、7bit-eucJP-ms のような実装になっ ていて、私が cp5022x の NEC選定IBM拡張文字対応のパッチを作成したとき、 cp5022x のユーザ定義文字を救うように実装しました。(送信はしません) 7bit-eucJP-ms(?) http://legacy-encoding.sourceforge.jp/wiki/index.php?7bit-eucJP-ms%28%3F%29 提案2 のようにする事で、受信したメールに cp5022x のユーザ定義文字が含 まれていて、それに続く文字が 2バイトコード文字の場合に、それらの文字ま で道連れで文字化けするという事を防げます。 cp50221 互換とする場合、このような動作が期待されるのか否かという所が気 になる所です。 ちなみに、libiconv に実装した ISO-2022-JP-MS は、cp5022x のユーザ定義 文字に関してノータッチです。 cp5022x のユーザ定義文字をケアしなかった場合、どのような文字化けになる かは、Outlook Express でユーザ定義文字の直後に2バイトコードの文字を何 文字か書いてメール送信し、Mozilla Thunderbird で受信すると確認できます。 ユーザ定義文字は、次のファイル(kanjitbl.txt) の 95区〜114区の文字のど れかをカットアンドペーストで Outlook Express に入力する事が出来ます。 http://www2d.biglobe.ne.jp/~msyk/text/kanjitbl.html -- 森山 将之 moriyama ＠ miraclelinux.com ミラクル・リナックス株式会社 From yanagisw ＠ gmail.com Wed Apr 12 22:50:12 2006 From: yanagisw ＠ gmail.com (Yanagisawa) Date: Wed, 12 Apr 2006 06:50:12 -0700 Subject: [LE-talk-ja 58] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TIA==?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: References: <20060404130547.B376.MSYK@mtg.biglobe.ne.jp> <682059D7-3F32-47A4-843C-8CC5517179FE@mac.com> <20060405115031.B383.MORIYAMA@miraclelinux.com> <4433DB20.8090104@mtg.biglobe.ne.jp> <44340698.7070206@airemix.com> <4434200F.71140409@asahi-net.or.jp> <44347B82.4070109@airemix.com> <4434BD4B.4C5DD39E@asahi-net.or.jp> <4435D539.3010707@airemix.com> <8AD2AAD9-612A-4F2D-B6B4-D81A3C5D65AC@glamour.co.jp> Message-ID: 柳沢と申します。 On Apr 11, 2006, at 3:10 AM, Kazuhiro Kazama wrote: > On 2006/04/07, at 14:51, NAOI Yasushi wrote: >> 「マッピングが異なっていても文字は表示される」というのはどう >> いう >> 意味ですか？　Macユーザですが、それらしい例を思いつかない >> ので。 > > 普通にMacで使っていたら，体験しないかもしれません． > > たとえば，異なるコンバータでUnicodeに変換した時に一部の > 文字のマッピン > グが違う場合とか，そのような文字を明示的にUnicodeの符号 > 位置で指定した > 場合の話です． 自分が Mac OS X 上でときどき目にする例ですが（普通に Macで使っていないのかも）、 web ページで、charset=EUC-JP だけど実際には EUC-JP- MS だとか charset=SHIFT_JIS なのに cp932 なページは、 Mac OS X 上では web ブラウザによって見え方が違います。 文字コードの変換というよりむしろ charset の解釈の違いかも しれませんが。 Mac OS X に最初から付いてくる Safari だと、MS 拡張の 文字は化けてしまいます。 （文字コードが不正であることを示す特殊なグリフで表示される） 一方、Mac OS X 版の FireFox だとたいてい表示されます。 どちらの挙動が望ましいのかはよくわかりませんが。 実装の詳細を調べてはいませんが、内部的にはどちらもテキストデータ が文字描画 API に達するまでに Unicode への変換が行わ れていると思われます。 ちなみに、両ブラウザで http://www.mysql-partners-jp.biz/techinfo/ tech_01.html の表を見てみたところ、 Safari は NEC特殊文字のところだけ表示できてその他は化ける 一方、FireFox だと NEC特殊文字、EEEF - EEFC あ たり、FA40 - FA53 あたりが化けて（数字系が半角カナになって いる）他は表示されることがわかりました。微妙です。 しかしこのページ自体が charset=shift_jis なのはあえてこの ようなテストに使われることを狙ってるのかな:-p ローカルにこのページをコピーして charset=Windows-31J にし たら Safari では全部の文字が正しく表示できるようになりまし た（おおっ）。FireFox の方は charset=shift_jis のと きと変わりません。 From moriyama ＠ miraclelinux.com Thu Apr 13 10:47:46 2006 From: moriyama ＠ miraclelinux.com (MORIYAMA Masayuki) Date: Thu, 13 Apr 2006 10:47:46 +0900 (JST) Subject: [LE-talk-ja 59] =?iso-2022-jp?b?UmU6IBskQjRwS1w7RU1NGyhC?= In-Reply-To: <20060412172605.B42F.MORIYAMA@miraclelinux.com> References: <40682A6A-AA5F-4E02-B1B8-4E1A3BE02B51@mac.com> <20060412172605.B42F.MORIYAMA@miraclelinux.com> Message-ID: <20060413101133.B435.MORIYAMA@miraclelinux.com> 森山です。 MORIYAMA Masayuki wrote: > 提案2 のようにする事で、受信したメールに cp5022x のユーザ定義文字が含 > まれていて、それに続く文字が 2バイトコード文字の場合に、それらの文字ま > で道連れで文字化けするという事を防げます。 > > cp50221 互換とする場合、このような動作が期待されるのか否かという所が気 > になる所です。 Citrus iconv のように、ISO/IEC 2022 を忠実に実装しているものでは、 cp50221 のユーザ定義文字を受け付けるようにするのは考え物でしょうね。 cp5022X のユーザ定義の面倒をみないものを 提案3 としておきます。 提案3 http://legacy-encoding.sourceforge.jp/wiki/index.php?%C4%F3%B0%C63 libiconv 1.10 のパッチで実装した ISO-2022-JP-MS と異なる点としては、次 の 2 点になります。 ・ユーザ定義文字を扱わない。 ・デフォルトで JIS X 0201 片仮名が G1 集合に指示されている状態とし、SO により G1 が GL に呼び出された場合に、JIS X 0201 片仮名として処理す る。(SO/SI による JIS X 0201 片仮名を受け付ける) -- 森山 将之 moriyama ＠ miraclelinux.com ミラクル・リナックス株式会社 From y.naoi ＠ glamour.co.jp Thu Apr 13 12:55:35 2006 From: y.naoi ＠ glamour.co.jp (NAOI Yasushi) Date: Thu, 13 Apr 2006 12:55:35 +0900 Subject: [LE-talk-ja 60] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TIA==?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: References: <20060404130547.B376.MSYK@mtg.biglobe.ne.jp> <682059D7-3F32-47A4-843C-8CC5517179FE@mac.com> <20060405115031.B383.MORIYAMA@miraclelinux.com> <4433DB20.8090104@mtg.biglobe.ne.jp> <44340698.7070206@airemix.com> <4434200F.71140409@asahi-net.or.jp> <44347B82.4070109@airemix.com> <4434BD4B.4C5DD39E@asahi-net.or.jp> <4435D539.3010707@airemix.com> <8AD2AAD9-612A-4F2D-B6B4-D81A3C5D65AC@glamour.co.jp> Message-ID: <579F15D9-23E0-442B-8B15-62E124F36DB1@glamour.co.jp> On 2006/04/12, at 22:50, Yanagisawa wrote: > ちなみに、両ブラウザで http://www.mysql-partners-jp.biz/techinfo/ > tech_01.html の表を見てみたところ、 > Safari は NEC特殊文字のところだけ表示できてその他は化ける Safari は Shift_JIS のページにおいて、（理由は謎ですが）NEC 選定 IBM 拡張文字を表示し、IBM 拡張文字を表示しません。 件のページで両方とも化けて見えるのは「NEC 選定」のほうの表中の文 字が、実際には、IBM 拡張文字に正規化（？）されているからだと思い ます。 > 一方、FireFox だと NEC特殊文字、EEEF - EEFC あ > たり、FA40 - FA53 あたりが化けて（数字系が半角カナになって > いる） Firefox はこのあたりの文字を表示するために、Mac OS の Unicode 描 画ルーチンを用いず、CP932 → MacJapanese（90pv）の変換を自前で行 っている（古い変換方法を使い続けている）ようです。 その結果、ヒラギノなどの 83pv フォントで文字化けします。化けてい る文字は、Firefox の環境設定で、Osaka などの 90pv フォントを指定 すれば表示できます。 -- 直井@Glamour Profession, Inc. From kazama ＠ mac.com Fri Apr 14 16:57:28 2006 From: kazama ＠ mac.com (Kazuhiro Kazama) Date: Fri, 14 Apr 2006 16:57:28 +0900 Subject: [LE-talk-ja 61] =?iso-2022-jp?b?UmU6IBskQjRwS1w7RU1NGyhC?= In-Reply-To: <20060412172605.B42F.MORIYAMA@miraclelinux.com> References: <20060412114057.B423.MORIYAMA@miraclelinux.com> <40682A6A-AA5F-4E02-B1B8-4E1A3BE02B51@mac.com> <20060412172605.B42F.MORIYAMA@miraclelinux.com> Message-ID: <158A7F0E-A1DB-4537-879A-B5A37566D25B@mac.com> On 2006/04/12, at 20:37, MORIYAMA Masayuki wrote: > cp50221 互換とする場合、Windows では次のようにユーザ定義文字を 94x94 > 集合に収まらない領域を使って表現しているので、ここの所の扱いをどうする > か明確にする必要があると考えています。 そもそも新しいレガシーエンコーディングを勝手に増やすというアプローチは 避けるべきではないのか？ということです． (実際に広くサポートすべきかは別の話として)，たぶんISO-2022-JP-MSを追加 したいというのは，CP932との互換性が一番だと思っていますが，その場合に はすでにCP50220, 50221, 50222がMicrosoftの手によってすでに提供されてい るわけです．としたら，ユーザが望むとしたら，似て非なるものではなく，良 くも悪くもこれら自身であるわけです．互換性というのはバグや問題点させも 合わせる，そういうものだと思います． 確かに，すでにあるものが気に入らないからと，新しいものを作りたくなる気 持ちはわかります．それは本質的に共通化が必要な文字符号化に関しては気軽 にやるべきではないし，それを各社がやってしまったから，こんなに混乱をも たらしてしまったわけです． 私はそれらは未来に向かって解決していくしかないと思っています．しかし， 混乱を解決するために移行していかなければいけない過去のものに対してやる のは，単に混乱を拡大する結果にしかならないでしょう． > 成瀬さんも cp50221 を推していますが、ISO 2022 から逸脱している形でエン > コードされているユーザ定義文字に関しては救うが、7ビットJIS へは変換し > ないと考えていると理解して、提案2 のようにしました。 いや，下記のように，私と同じことを言っていると理解しています． On 2006/04/06, at 3:04, NARUSE, Yui wrote: > 一方で今回提案された ISO-2022-JP-MS は、 > * CSS が ISO-2022-JP (RFC1468) と異なる > * そのような「ISO-2022-JP-MS で扱える符号化文字列」の > 資産は相当数存在する > ため、その類のものに対する必要性は一定あるでしょう。 > （例えばMLのアーカイブの Unicode 化に用いる） > しかし、それならば CP502xx で十分でしょう。 つまり，単に互換性を取れということではなく，そもそもISO-2022-JP-MSとい う新しい文字符号化を検討する必要はないということでしょう． 一生懸命検討してくださっていて悪いと思いますが，少なくとも誰も他に支持 する人がいない現状では，ISO-2022-JP-MS（または類似する「新しい」レガ シーエンコーディング）は白紙に戻した方がよいと思います． --- 風間 一洋 (kazama ＠ mac.com) From tom ＠ asakawa.ne.jp Fri Apr 14 17:17:47 2006 From: tom ＠ asakawa.ne.jp (Tomoyuki Asakawa) Date: Fri, 14 Apr 2006 17:17:47 +0900 Subject: [LE-talk-ja 62] =?iso-2022-jp?b?UmU6IBskQjRwS1w7RU1NGyhC?= In-Reply-To: <158A7F0E-A1DB-4537-879A-B5A37566D25B@mac.com> References: <20060412114057.B423.MORIYAMA@miraclelinux.com> <40682A6A-AA5F-4E02-B1B8-4E1A3BE02B51@mac.com> <20060412172605.B42F.MORIYAMA@miraclelinux.com> <158A7F0E-A1DB-4537-879A-B5A37566D25B@mac.com> Message-ID: <06A10F61-BE65-437C-90C3-E58F8CC2C8BD@asakawa.ne.jp> あさかわです。 On 2006/04/14, at 16:57, Kazuhiro Kazama wrote: > 一生懸命検討してくださっていて悪いと思いますが，少なくとも誰も > 他に支持 > する人がいない現状では，ISO-2022-JP-MS（または類似する > 「新しい」レガ > シーエンコーディング）は白紙に戻した方がよいと思います． 考え方自体は支持していますので、白紙には戻してほしくはありません。 現状で不都合なのは確かですし、それの解決を、将来に期待するという のは受け入れがたいです。 （今困っている） ただ、ISO-2022-JP-MSとして提案されているものが、ベストなの かどうかまだ理解していないのが現状です。 他にもそういう人はたくさんいるだろうと思っています。 From LE-talk-ja.hata ＠ ml.mailso.net Fri Apr 14 17:39:36 2006 From: LE-talk-ja.hata ＠ ml.mailso.net (Hata) Date: Fri, 14 Apr 2006 17:39:36 +0900 Subject: [LE-talk-ja 63] =?iso-2022-jp?b?UmU6IBskQjRwS1w7RU1NGyhC?= In-Reply-To: <06A10F61-BE65-437C-90C3-E58F8CC2C8BD@asakawa.ne.jp> Message-ID: <200604140842.k3E8g2jX016307@rs26.luxsci.com> 私も今困っているので、少なくとも検討自体は歓迎しています。 -- Hata -----Original Message----- From: legacy-encoding-talk-ja-bounces ＠ lists.sourceforge.jp [mailto:legacy-encoding-talk-ja-bounces ＠ lists.sourceforge.jp] On Behalf Of Tomoyuki Asakawa Sent: Friday, April 14, 2006 5:18 PM To: legacy-encoding-talk-ja ＠ lists.sourceforge.jp Subject: [LE-talk-ja 62] Re: 基本仕様 あさかわです。 On 2006/04/14, at 16:57, Kazuhiro Kazama wrote: > 一生懸命検討してくださっていて悪いと思いますが，少なくとも誰も > 他に支持 > する人がいない現状では，ISO-2022-JP-MS（または類似する > 「新しい」レガ > シーエンコーディング）は白紙に戻した方がよいと思います． 考え方自体は支持していますので、白紙には戻してほしくはありません。 現状で不都合なのは確かですし、それの解決を、将来に期待するという のは受け入れがたいです。 （今困っている） ただ、ISO-2022-JP-MSとして提案されているものが、ベストなの かどうかまだ理解していないのが現状です。 他にもそういう人はたくさんいるだろうと思っています。 _______________________________________________ Legacy-Encoding-talk-ja mailing list Legacy-Encoding-talk-ja ＠ lists.sourceforge.jp http://lists.sourceforge.jp/mailman/listinfo/legacy-encoding-talk-ja From yw3t-trns ＠ asahi-net.or.jp Fri Apr 14 18:32:36 2006 From: yw3t-trns ＠ asahi-net.or.jp (Tadamasa Teranishi) Date: Fri, 14 Apr 2006 18:32:36 +0900 Subject: [LE-talk-ja 64] =?iso-2022-jp?b?UmU6IBskQjRwS1w7RU1NGyhC?= References: <200604140842.k3E8g2jX016307@rs26.luxsci.com> Message-ID: <443F6C34.A32004CC@asahi-net.or.jp> 寺西です。 Hata wrote: > > 私も今困っているので、少なくとも検討自体は歓迎しています。 せめて具体的に何がどう困っているかを説明していただけませんか? 私の気づいていない納得できる問題点に気づくこともできますから。 -- ===================================================================== 寺西 忠勝(TADAMASA TERANISHI) yw3t-trns ＠ asahi-net.or.jp http://www.asahi-net.or.jp/~yw3t-trns/index.htm Key fingerprint = 474E 4D93 8E97 11F6 662D 8A42 17F5 52F4 10E7 D14E From yw3t-trns ＠ asahi-net.or.jp Fri Apr 14 18:33:14 2006 From: yw3t-trns ＠ asahi-net.or.jp (Tadamasa Teranishi) Date: Fri, 14 Apr 2006 18:33:14 +0900 Subject: [LE-talk-ja 65] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TICA=?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= References: <20060404130547.B376.MSYK@mtg.biglobe.ne.jp> <682059D7-3F32-47A4-843C-8CC5517179FE@mac.com> <20060405115031.B383.MORIYAMA@miraclelinux.com> <4433DB20.8090104@mtg.biglobe.ne.jp> <44340698.7070206@airemix.com> <4434200F.71140409@asahi-net.or.jp> <44347B82.4070109@airemix.com> <4434BD4B.4C5DD39E@asahi-net.or.jp> <4435D539.3010707@airemix.com> <4435E422.D6115079@asahi-net.or.jp> <44397FB1.1020601@airemix.com> Message-ID: <443F6C5A.3566469A@asahi-net.or.jp> 寺西です。 # 亀レスですが。 "NARUSE, Yui" wrote: > > どの範囲のユーザを想定するのかという話になってしまいますが、 > 「JIS X 0208」という言葉をしらない人が「EUC-JP」を指定した場合、 > 想定しているのは「ひらがなとか漢字とか」程度なので、 > 想定内か想定外かというのははっきりしないかと。 ちょっと認識がずれていますが。 受け取り側のプログラムを設計する人は、すくなくともその程度の知識 は必要ですし、それを知らない人を助けるために CP51932 に対応する というのは方向として問題だろうと思います。 そもそも CP51932 で扱うべきことではないので。 コード変換の環境整備するよりは、知らずにプログラムを設計してしまう 人に教える環境を整えるべきだろうなぁと思いますね。 > > いや、今でも使いたいなら UTF-8 に移行すべきであって、CP51932 とか > > で使おうとするのが良いことではないだろうと思います。例え、使える > > ようになったとしてもです。 > > システムが複数のモジュールから構成されていて、 > かつそのモジュールのうちいくつかが UTF-8 非対応の場合、 > モジュールを置き換えるまで延命が必要でしょう。 そういう場合は、それらのモジュールが全て CP51932 に対応していない といけない/不具合がでる可能性があるわけでして、CP51932 で何とか するという解決法にも、無理があるように思います。 # 解決する場合もあるのはわかりますが。よっぽど UTF-8 の方が現状対応 # しているような...。 > > CP51932 を使っているのは IE (および他のブラウザ?)から送られてくる > > データぐらいしか知りませんが、他にありますか? > > Windows のテキストエディタで、ファイルを EUC-JP として保存した場合、 > それは CP51932 ですね。 ノートパッドは EUC-JP で保存できないので、結局はそのエディタの仕様に 依存する話なのでは? コード変換に CP51932 を使っている場合に限られるでしょう。 そもそも機種依存文字を含めて EUC-JP として保存できるエディタに 問題があるかと思いますし、それがスタンダードだとは思わないですけど。 具体的にはどのエディタでしょう。 > が、自分の思っていた「EUC-JP」が実は CP51932 だった、 > という人はかなり多いのではないでしょうか。 ??? > # Windows で 3バイト EUC を扱えるエディタってあまりないですし。 3バイト EUC が扱えるエディタの有無と CP51932 とは直接関係ないでしょう。 # かすってますが...。 > > つまり現状死んでいるわけです。 > > Windows から「日本語 (EUC)」として読めば普通に見れますから、 > 「死んでいる」は語弊があるかと。 > “dying”ではありますな。 Windows で閉じた世界ならわざわざ CP51932 で処理する必要はない ということです。EUC-JP に変換するなら、そこに何らかの UNIX との かかわりがあるわけでして、その処理のどこかで何らかの不具合が 生じている(生じていなければ CP51932 に対応する必要はないから)わけ で、それはデータが死んでいる(というか、生かされていない)ということ です。 > 環境を整えなかった場合、 > 全面的にレガシーなシステムのまま限界まで使い、 > 一二の三で一気に Unicode、というシナリオになるのでしょうが、 > それですと、MySQL 4.1 の二の舞になるように思います。 これは意見が異なるところでしょう。 変にレガシーエンコーディングの環境が整う方が厄介だろうと思いますけ どね。 > 思うに、Windows の機種依存データは外の環境に出て行きやすいが、 > Mac の機種依存データは Mac の環境内で処理され、外に出てこないので、 > 問題が顕在化しづらいのかもしれません。 ユーザの絶対数が Windows よりかなり少ないので、問題が表面化することは 少ないですね。 個人的には、いろいろと厄介な問題を持っていて、解決しないといけないか、 あるは全て捨ててしまうか、ということになるだろうと思っています。 -- ===================================================================== 寺西 忠勝(TADAMASA TERANISHI) yw3t-trns ＠ asahi-net.or.jp http://www.asahi-net.or.jp/~yw3t-trns/index.htm Key fingerprint = 474E 4D93 8E97 11F6 662D 8A42 17F5 52F4 10E7 D14E From tom ＠ asakawa.ne.jp Fri Apr 14 18:54:51 2006 From: tom ＠ asakawa.ne.jp (Tomoyuki Asakawa) Date: Fri, 14 Apr 2006 18:54:51 +0900 Subject: [LE-talk-ja 66] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TICA=?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <443F6C5A.3566469A@asahi-net.or.jp> References: <20060404130547.B376.MSYK@mtg.biglobe.ne.jp> <682059D7-3F32-47A4-843C-8CC5517179FE@mac.com> <20060405115031.B383.MORIYAMA@miraclelinux.com> <4433DB20.8090104@mtg.biglobe.ne.jp> <44340698.7070206@airemix.com> <4434200F.71140409@asahi-net.or.jp> <44347B82.4070109@airemix.com> <4434BD4B.4C5DD39E@asahi-net.or.jp> <4435D539.3010707@airemix.com> <4435E422.D6115079@asahi-net.or.jp> <44397FB1.1020601@airemix.com> <443F6C5A.3566469A@asahi-net.or.jp> Message-ID: あさかわ > Windows で閉じた世界ならわざわざ CP51932 で処理する必要 > はない > ということです。EUC-JP に変換するなら、そこに何らかの > UNIX との > かかわりがあるわけでして、その処理のどこかで何らかの不具合が > 生じている(生じていなければ CP51932 に対応する必要 > はないから)わけ > で、それはデータが死んでいる(というか、生かされていな > い)ということ > です。 それは、Windowsで閉じているなら、正論です。 しかし、現状は、Windowsで閉じていないのです。 クライアントマシンとしての、Windowsと、 サーバマシンとしての、UNIXが、普通に存在しています。 sambaを、ファイルサーバにした場合もしかりですが Windows上の、ブラウザから、UNIX上で動作する、WEBアプ リを使うなんてのはザラでしょう。 こういう時に、Windowsで入力できる文字が、UNIX上の制 約で、欠落してしまうのが現状なのです。 From tom ＠ asakawa.ne.jp Fri Apr 14 18:57:21 2006 From: tom ＠ asakawa.ne.jp (Tomoyuki Asakawa) Date: Fri, 14 Apr 2006 18:57:21 +0900 Subject: [LE-talk-ja 67] =?iso-2022-jp?b?UmU6IBskQjRwS1w7RU1NGyhC?= In-Reply-To: <443F6C34.A32004CC@asahi-net.or.jp> References: <200604140842.k3E8g2jX016307@rs26.luxsci.com> <443F6C34.A32004CC@asahi-net.or.jp> Message-ID: <23750D02-B7C6-47F7-82B8-37BC8CDC3EC2@asakawa.ne.jp> あさかわ On 2006/04/14, at 18:32, Tadamasa Teranishi wrote: > せめて具体的に何がどう困っているかを説明していただけませんか? Windowsのクライアントから、クサナギのナギという漢字を、 UNIXで動作しているブログに投稿できない。 （ブログは一つの例です） From yw3t-trns ＠ asahi-net.or.jp Fri Apr 14 19:02:27 2006 From: yw3t-trns ＠ asahi-net.or.jp (Tadamasa Teranishi) Date: Fri, 14 Apr 2006 19:02:27 +0900 Subject: [LE-talk-ja 68] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TICAg?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= References: <20060404130547.B376.MSYK@mtg.biglobe.ne.jp> <682059D7-3F32-47A4-843C-8CC5517179FE@mac.com> <20060405115031.B383.MORIYAMA@miraclelinux.com> <4433DB20.8090104@mtg.biglobe.ne.jp> <44340698.7070206@airemix.com> <4434200F.71140409@asahi-net.or.jp> <44347B82.4070109@airemix.com> <4434BD4B.4C5DD39E@asahi-net.or.jp> <4435D539.3010707@airemix.com> <4435E422.D6115079@asahi-net.or.jp> <44397FB1.1020601@airemix.com> <443F6C5A.3566469A@asahi-net.or.jp> Message-ID: <443F7333.C9C4260D@asahi-net.or.jp> 寺西です。 Tomoyuki Asakawa wrote: > > > UNIX との > > かかわりがあるわけでして、その処理のどこかで何らかの不具合が > > 生じている(生じていなければ CP51932 に対応する必要 > > はないから)わけ > > で、それはデータが死んでいる(というか、生かされていな > > い)ということ > > です。 > > それは、Windowsで閉じているなら、正論です。 > しかし、現状は、Windowsで閉じていないのです。 ... > Windows上の、ブラウザから、UNIX上で動作する、WEBアプ > リを使うなんてのはザラでしょう。 > > こういう時に、Windowsで入力できる文字が、UNIX上の制 > 約で、欠落してしまうのが現状なのです。 だから現状死んでいるのでしょ? 使いたいなら Unicode 化するか CP932 でシステムを作るのが筋で EUC-JP で使えるようにするのは方向性として違うのではないか と、言っているわけですが...。 無理やり EUC-JP で何とかしようとしているのが不思議なんですが...。 -- ===================================================================== 寺西 忠勝(TADAMASA TERANISHI) yw3t-trns ＠ asahi-net.or.jp http://www.asahi-net.or.jp/~yw3t-trns/index.htm Key fingerprint = 474E 4D93 8E97 11F6 662D 8A42 17F5 52F4 10E7 D14E From yw3t-trns ＠ asahi-net.or.jp Fri Apr 14 19:04:32 2006 From: yw3t-trns ＠ asahi-net.or.jp (Tadamasa Teranishi) Date: Fri, 14 Apr 2006 19:04:32 +0900 Subject: [LE-talk-ja 69] =?iso-2022-jp?b?UmU6IBskQjRwS1w7RU1NGyhC?= References: <200604140842.k3E8g2jX016307@rs26.luxsci.com> <443F6C34.A32004CC@asahi-net.or.jp> <23750D02-B7C6-47F7-82B8-37BC8CDC3EC2@asakawa.ne.jp> Message-ID: <443F73B0.DDA663C4@asahi-net.or.jp> 寺西です。 Tomoyuki Asakawa wrote: > > > せめて具体的に何がどう困っているかを説明していただけませんか? > > Windowsのクライアントから、クサナギのナギという漢字を、 > UNIXで動作しているブログに投稿できない。 > （ブログは一つの例です） 使いたいなら Unicode 化すれば良いわけでして...。 -- ===================================================================== 寺西 忠勝(TADAMASA TERANISHI) yw3t-trns ＠ asahi-net.or.jp http://www.asahi-net.or.jp/~yw3t-trns/index.htm Key fingerprint = 474E 4D93 8E97 11F6 662D 8A42 17F5 52F4 10E7 D14E From tom ＠ asakawa.ne.jp Fri Apr 14 19:07:04 2006 From: tom ＠ asakawa.ne.jp (Tomoyuki Asakawa) Date: Fri, 14 Apr 2006 19:07:04 +0900 Subject: [LE-talk-ja 70] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TICAg?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <443F7333.C9C4260D@asahi-net.or.jp> References: <20060404130547.B376.MSYK@mtg.biglobe.ne.jp> <682059D7-3F32-47A4-843C-8CC5517179FE@mac.com> <20060405115031.B383.MORIYAMA@miraclelinux.com> <4433DB20.8090104@mtg.biglobe.ne.jp> <44340698.7070206@airemix.com> <4434200F.71140409@asahi-net.or.jp> <44347B82.4070109@airemix.com> <4434BD4B.4C5DD39E@asahi-net.or.jp> <4435D539.3010707@airemix.com> <4435E422.D6115079@asahi-net.or.jp> <44397FB1.1020601@airemix.com> <443F6C5A.3566469A@asahi-net.or.jp> <443F7333.C9C4260D@asahi-net.or.jp> Message-ID: <0D9B740D-6EC0-488E-9712-D98F970DE3F2@asakawa.ne.jp> あさかわ > 使いたいなら Unicode 化するか CP932 でシステムを作 > るのが筋で > EUC-JP で使えるようにするのは方向性として違うのではないか > と、言っているわけですが...。 それが、スジなのは、わかりますよ。 しかし、UTFでの、動作が完全じゃないからですよ。 PHPにしても、PostgreSQLにしても、MySQLにしても。 > > 無理やり EUC-JP で何とかしようとしているのが不思議なんで > すが...。 実際に、アプリつくっていれば、頻繁に遭遇するはずなので、どうし て、不思議に思うのか不思議です。 From tom ＠ asakawa.ne.jp Fri Apr 14 19:08:02 2006 From: tom ＠ asakawa.ne.jp (Tomoyuki Asakawa) Date: Fri, 14 Apr 2006 19:08:02 +0900 Subject: [LE-talk-ja 71] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TICA=?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <443F6C5A.3566469A@asahi-net.or.jp> References: <20060404130547.B376.MSYK@mtg.biglobe.ne.jp> <682059D7-3F32-47A4-843C-8CC5517179FE@mac.com> <20060405115031.B383.MORIYAMA@miraclelinux.com> <4433DB20.8090104@mtg.biglobe.ne.jp> <44340698.7070206@airemix.com> <4434200F.71140409@asahi-net.or.jp> <44347B82.4070109@airemix.com> <4434BD4B.4C5DD39E@asahi-net.or.jp> <4435D539.3010707@airemix.com> <4435E422.D6115079@asahi-net.or.jp> <44397FB1.1020601@airemix.com> <443F6C5A.3566469A@asahi-net.or.jp> Message-ID: <0F710D2D-8F6E-4B68-97E5-7C5B0D9323AD@asakawa.ne.jp> あさかわ On 2006/04/14, at 18:33, Tadamasa Teranishi wrote: > そもそも機種依存文字を含めて EUC-JP として保存できるエ > ディタに > 問題があるかと思いますし、それがスタンダードだとは思わないです > けど。 > > 具体的にはどのエディタでしょう。 すくなくとも、WIndowsや、MAC OS上で、動作する、エ ディタで EUC/SJIS/JISなどの、複数のエンコーディングに対応してるならば 機種依存文字も含めて、保存できる、ベキだと思います。 そうじゃないと、データが欠落します。 From yw3t-trns ＠ asahi-net.or.jp Fri Apr 14 19:16:11 2006 From: yw3t-trns ＠ asahi-net.or.jp (Tadamasa Teranishi) Date: Fri, 14 Apr 2006 19:16:11 +0900 Subject: [LE-talk-ja 72] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TICAg?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= References: <20060404130547.B376.MSYK@mtg.biglobe.ne.jp> <682059D7-3F32-47A4-843C-8CC5517179FE@mac.com> <20060405115031.B383.MORIYAMA@miraclelinux.com> <4433DB20.8090104@mtg.biglobe.ne.jp> <44340698.7070206@airemix.com> <4434200F.71140409@asahi-net.or.jp> <44347B82.4070109@airemix.com> <4434BD4B.4C5DD39E@asahi-net.or.jp> <4435D539.3010707@airemix.com> <4435E422.D6115079@asahi-net.or.jp> <44397FB1.1020601@airemix.com> <443F6C5A.3566469A@asahi-net.or.jp> <0F710D2D-8F6E-4B68-97E5-7C5B0D9323AD@asakawa.ne.jp> Message-ID: <443F766B.E0FD3EE@asahi-net.or.jp> 寺西です。 Tomoyuki Asakawa wrote: > > すくなくとも、WIndowsや、MAC OS上で、動作する、エ > ディタで > EUC/SJIS/JISなどの、複数のエンコーディングに対応してるならば > 機種依存文字も含めて、保存できる、ベキだと思います。 はぁ? > そうじゃないと、データが欠落します。 そりゃそうです。 Unicode が扱えるなら漢字以外の文字はどうやっても EUC/SJIS/JIS で 保存すれば欠落しますし。 日本語だけ特別扱いしたいということなんでしょうけど...。 > EUC/SJIS/JISなどの、複数のエンコーディングに対応してるならば > 機種依存文字も含めて、保存できる、ベキだと思います。 私はとても支持できません。 -- ===================================================================== 寺西 忠勝(TADAMASA TERANISHI) yw3t-trns ＠ asahi-net.or.jp http://www.asahi-net.or.jp/~yw3t-trns/index.htm Key fingerprint = 474E 4D93 8E97 11F6 662D 8A42 17F5 52F4 10E7 D14E From yw3t-trns ＠ asahi-net.or.jp Fri Apr 14 19:32:32 2006 From: yw3t-trns ＠ asahi-net.or.jp (Tadamasa Teranishi) Date: Fri, 14 Apr 2006 19:32:32 +0900 Subject: [LE-talk-ja 73] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TIA==?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= References: <20060404130547.B376.MSYK@mtg.biglobe.ne.jp> <682059D7-3F32-47A4-843C-8CC5517179FE@mac.com> <20060405115031.B383.MORIYAMA@miraclelinux.com> <4433DB20.8090104@mtg.biglobe.ne.jp> <44340698.7070206@airemix.com> <4434200F.71140409@asahi-net.or.jp> <44347B82.4070109@airemix.com> <4434BD4B.4C5DD39E@asahi-net.or.jp> <4435D539.3010707@airemix.com> <4435E422.D6115079@asahi-net.or.jp> <44397FB1.1020601@airemix.com> <443F6C5A.3566469A@asahi-net.or.jp> <443F7333.C9C4260D@asahi-net.or.jp> <0D9B740D-6EC0-488E-9712-D98F970DE3F2@asakawa.ne.jp> Message-ID: <443F7A40.12E5F41F@asahi-net.or.jp> 寺西です。 Tomoyuki Asakawa wrote: > > > 使いたいなら Unicode 化するか CP932 でシステムを作 > > るのが筋で > > EUC-JP で使えるようにするのは方向性として違うのではないか > > と、言っているわけですが...。 > > それが、スジなのは、わかりますよ。 > しかし、UTFでの、動作が完全じゃないからですよ。 > PHPにしても、PostgreSQLにしても、MySQLにしても。 なら、UTF の方を何とかするべきなんでは? EUC-JP を何とかするより、そっちを何とかする方がよっぽど有意義だろう と思いますよ。 > > 無理やり EUC-JP で何とかしようとしているのが不思議なんで > > すが...。 > > 実際に、アプリつくっていれば、頻繁に遭遇するはずなので、どうし > て、不思議に思うのか不思議です。 現状 EUC-JP で解決しているわけでもないものなんだし、UTF の方で 何とかすれば良い話だからです。 ところで、クサナギのナギという漢字については、確か JIS補助漢字 (JIS X 0212) に含まれますので、レガシーな EUC-JP でなくても、 使えないわけではありません。 # が、EUC-JP で 3バイト文字に対応していない場合も多いが...。 -- ===================================================================== 寺西 忠勝(TADAMASA TERANISHI) yw3t-trns ＠ asahi-net.or.jp http://www.asahi-net.or.jp/~yw3t-trns/index.htm Key fingerprint = 474E 4D93 8E97 11F6 662D 8A42 17F5 52F4 10E7 D14E From kazama ＠ mac.com Fri Apr 14 19:38:46 2006 From: kazama ＠ mac.com (Kazuhiro Kazama) Date: Fri, 14 Apr 2006 19:38:46 +0900 Subject: [LE-talk-ja 74] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TICA=?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: References: <20060404130547.B376.MSYK@mtg.biglobe.ne.jp> <682059D7-3F32-47A4-843C-8CC5517179FE@mac.com> <20060405115031.B383.MORIYAMA@miraclelinux.com> <4433DB20.8090104@mtg.biglobe.ne.jp> <44340698.7070206@airemix.com> <4434200F.71140409@asahi-net.or.jp> <44347B82.4070109@airemix.com> <4434BD4B.4C5DD39E@asahi-net.or.jp> <4435D539.3010707@airemix.com> <4435E422.D6115079@asahi-net.or.jp> <44397FB1.1020601@airemix.com> <443F6C5A.3566469A@asahi-net.or.jp> Message-ID: <392A807F-240B-4BC7-9DD8-F6E0A8E64494@mac.com> On 2006/04/14, at 18:54, Tomoyuki Asakawa wrote: > こういう時に、Windowsで入力できる文字が、UNIX上の制 > 約で、欠落してしまうのが現状なのです。 まずWindows上の文字に関しては，CP932かCP51932を使えば問題はほとんどな いと考えています． また，メールに関しては，ISO-2022-JPというのは，「どのコンピュータでも 正しく情報交換ができるようにする」ことを目的に作られた情報交換用の符号 化文字集合なので，それに関しては機種依存文字を送らないのが正しい動作と 言えます． しかし，万が一システム内部に閉じた形で異なるJIS符号化を使う必然性が あったとします．その場合のためにMicrosoftから提案されているのが， CP50220, CP50221, CP50222です． そこで，ISO-2022-JP-MSの問題は， 1) CP5022Xと同じにした場合は，存在意味がない． 2) CP5022Xと異なる場合には，互換性に問題があるかもしれない． ということです． ようするに，「すでにMicrosoftのオフィシャルな解決方法があるのに，なぜ わざわざ別の方法を別の名前で使う必要があるのか？」ということです．もし 必要ならオフィシャルな解決方法を使う方がよくないですか？ --- 風間 一洋 (kazama ＠ mac.com) From kazama ＠ mac.com Fri Apr 14 19:48:22 2006 From: kazama ＠ mac.com (Kazuhiro Kazama) Date: Fri, 14 Apr 2006 19:48:22 +0900 Subject: [LE-talk-ja 75] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TIA==?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <443F7A40.12E5F41F@asahi-net.or.jp> References: <20060404130547.B376.MSYK@mtg.biglobe.ne.jp> <682059D7-3F32-47A4-843C-8CC5517179FE@mac.com> <20060405115031.B383.MORIYAMA@miraclelinux.com> <4433DB20.8090104@mtg.biglobe.ne.jp> <44340698.7070206@airemix.com> <4434200F.71140409@asahi-net.or.jp> <44347B82.4070109@airemix.com> <4434BD4B.4C5DD39E@asahi-net.or.jp> <4435D539.3010707@airemix.com> <4435E422.D6115079@asahi-net.or.jp> <44397FB1.1020601@airemix.com> <443F6C5A.3566469A@asahi-net.or.jp> <443F7333.C9C4260D@asahi-net.or.jp> <0D9B740D-6EC0-488E-9712-D98F970DE3F2@asakawa.ne.jp> <443F7A40.12E5F41F@asahi-net.or.jp> Message-ID: <3DD77548-1218-4170-AA39-1D40EDD28FA0@mac.com> On 2006/04/14, at 19:32, Tadamasa Teranishi wrote: >> それが、スジなのは、わかりますよ。 >> しかし、UTFでの、動作が完全じゃないからですよ。 >> PHPにしても、PostgreSQLにしても、MySQLにしても。 > > なら、UTF の方を何とかするべきなんでは? > > EUC-JP を何とかするより、そっちを何とかする方がよっぽど有意義だろう > と思いますよ。 まあ，文字を沢山サポートして欲しいという要求はわかります． しかし，今後重要なのは，Windows VistaでJIS X 0213の文字が正式にサポー トされること（Windows XPにはバックポートされるかもしれません），そして Windows上で普通にかな漢字変換しただけで，それらの新しい文字が使えてし まうようになるということです． その場合には，ユーザからのJIS X 0213対応要求は絶対拒否できないと思いま す．そして，それを互換性を保ってサポートするには，UTF-8しかないと思い ますので，UTF-8対応は非常に重要だと考えています． だから，今のうちに問題があれば早めに直しておく方がよいと思います． --- 風間 一洋 (kazama ＠ mac.com) From kazama ＠ mac.com Fri Apr 14 20:20:29 2006 From: kazama ＠ mac.com (Kazuhiro Kazama) Date: Fri, 14 Apr 2006 20:20:29 +0900 Subject: [LE-talk-ja 76] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TICAg?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <443F766B.E0FD3EE@asahi-net.or.jp> References: <20060404130547.B376.MSYK@mtg.biglobe.ne.jp> <682059D7-3F32-47A4-843C-8CC5517179FE@mac.com> <20060405115031.B383.MORIYAMA@miraclelinux.com> <4433DB20.8090104@mtg.biglobe.ne.jp> <44340698.7070206@airemix.com> <4434200F.71140409@asahi-net.or.jp> <44347B82.4070109@airemix.com> <4434BD4B.4C5DD39E@asahi-net.or.jp> <4435D539.3010707@airemix.com> <4435E422.D6115079@asahi-net.or.jp> <44397FB1.1020601@airemix.com> <443F6C5A.3566469A@asahi-net.or.jp> <0F710D2D-8F6E-4B68-97E5-7C5B0D9323AD@asakawa.ne.jp> <443F766B.E0FD3EE@asahi-net.or.jp> Message-ID: On 2006/04/14, at 19:16, Tadamasa Teranishi wrote: > Tomoyuki Asakawa wrote: >> >> すくなくとも、WIndowsや、MAC OS上で、動作する、エ >> ディタで >> EUC/SJIS/JISなどの、複数のエンコーディングに対応してるならば >> 機種依存文字も含めて、保存できる、ベキだと思います。 > > はぁ? > >> そうじゃないと、データが欠落します。 > > そりゃそうです。 作って頂いた資料を見るとわかりますが，そこまでの完全性はこのプロジェク トの対象になっていないと理解しています． たとえば，eucJP-msの全文字レパートリを（機種依存文字を保ったままで）シ フトJIS符号化で保存するのは論理的に無理（で正しい？）でしょう． 基本的には， ・あるプラットフォーム上では，そのプラットフォームの文字（機種依存文字 も）をちゃんと扱えること． ・Unicodeベースシステムとレガシーシステムの間の問題に解決策を与えるこ と． ではないでしょうか． --- 風間 一洋 (kazama ＠ mac.com) From yw3t-trns ＠ asahi-net.or.jp Fri Apr 14 21:19:09 2006 From: yw3t-trns ＠ asahi-net.or.jp (Tadamasa Teranishi) Date: Fri, 14 Apr 2006 21:19:09 +0900 Subject: [LE-talk-ja 77] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TICA=?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= References: <20060404130547.B376.MSYK@mtg.biglobe.ne.jp> <682059D7-3F32-47A4-843C-8CC5517179FE@mac.com> <20060405115031.B383.MORIYAMA@miraclelinux.com> <4433DB20.8090104@mtg.biglobe.ne.jp> <44340698.7070206@airemix.com> <4434200F.71140409@asahi-net.or.jp> <44347B82.4070109@airemix.com> <4434BD4B.4C5DD39E@asahi-net.or.jp> <4435D539.3010707@airemix.com> <4435E422.D6115079@asahi-net.or.jp> <44397FB1.1020601@airemix.com> <443F6C5A.3566469A@asahi-net.or.jp> <443F7333.C9C4260D@asahi-net.or.jp> <0D9B740D-6EC0-488E-9712-D98F970DE3F2@asakawa.ne.jp> <443F7A40.12E5F41F@asahi-net.or.jp> <3DD77548-1218-4170-AA39-1D40EDD28FA0@mac.com> Message-ID: <443F933D.C0472A30@asahi-net.or.jp> 寺西です。 Kazuhiro Kazama wrote: > > しかし，今後重要なのは，Windows VistaでJIS X 0213の文字が正式にサポー > トされること（Windows XPにはバックポートされるかもしれません），そして ... > その場合には，ユーザからのJIS X 0213対応要求は絶対拒否できないと思いま > す．そして，それを互換性を保ってサポートするには，UTF-8しかないと思い > ますので，UTF-8対応は非常に重要だと考えています． その場合にも EUC-JISX0213 を基に機種依存文字を加えて、レガシーな EUC-JISX0213 を新たに作って使いましょうという方向に動かないこと を祈ります。 -- ===================================================================== 寺西 忠勝(TADAMASA TERANISHI) yw3t-trns ＠ asahi-net.or.jp http://www.asahi-net.or.jp/~yw3t-trns/index.htm Key fingerprint = 474E 4D93 8E97 11F6 662D 8A42 17F5 52F4 10E7 D14E From moriyama ＠ miraclelinux.com Fri Apr 14 22:02:39 2006 From: moriyama ＠ miraclelinux.com (MORIYAMA Masayuki) Date: Fri, 14 Apr 2006 22:02:39 +0900 (JST) Subject: [LE-talk-ja 78] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TICA=?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <392A807F-240B-4BC7-9DD8-F6E0A8E64494@mac.com> References: <392A807F-240B-4BC7-9DD8-F6E0A8E64494@mac.com> Message-ID: <20060414195026.D2B8.MORIYAMA@miraclelinux.com> 森山です。 Kazuhiro Kazama wrote: > また，メールに関しては，ISO-2022-JPというのは，「どのコンピュータでも > 正しく情報交換ができるようにする」ことを目的に作られた情報交換用の符号 > 化文字集合なので，それに関しては機種依存文字を送らないのが正しい動作と > 言えます． > > しかし，万が一システム内部に閉じた形で異なるJIS符号化を使う必然性が > あったとします．その場合のためにMicrosoftから提案されているのが， > CP50220, CP50221, CP50222です． > > そこで，ISO-2022-JP-MSの問題は， > > 1) CP5022Xと同じにした場合は，存在意味がない． > 2) CP5022Xと異なる場合には，互換性に問題があるかもしれない． > > ということです． > > ようするに，「すでにMicrosoftのオフィシャルな解決方法があるのに，なぜ > わざわざ別の方法を別の名前で使う必要があるのか？」ということです．もし > 必要ならオフィシャルな解決方法を使う方がよくないですか？ Windows の CP50221 に限りなく近いものを実装してもよいのであれば、そう したい所です。 その場合、ユーザ定義文字の扱いも Windows 互換にするのは問題なのでは? (Unicode → CP50221 の変換でユーザ定義文字も Windows 互換で変換すると いう意味) という所が気がかりな点です。 Windows とは非互換な実装にするのであれば、CP50221 という名前を使わない ほうがいいのではないかと考えました。 CP5022X の仕様が明確になっていないという所が一番の問題ではありますけれ ども。 libiconv のパッチで実装した ISO-2022-JP-MS のユーザ定義文字の扱いに関 しては、異論のある部分でしょうから、これを取り除いたものにしても良いと 考えています。 -- 森山 将之 moriyama ＠ miraclelinux.com ミラクル・リナックス株式会社 From motoyuki ＠ bc4.so-net.ne.jp Sat Apr 15 22:12:32 2006 From: motoyuki ＠ bc4.so-net.ne.jp (OGAWA Motoyuki) Date: Sat, 15 Apr 2006 22:12:32 +0900 Subject: [LE-talk-ja 79] =?iso-2022-jp?b?GyRCJDMkThsoQk1MGyRCJEckTjVEGyhC?= =?iso-2022-jp?b?GyRCT0A8K0JOJEskRCQkJEYbKEI=?= Message-ID: <20060415212608.CE29.MOTOYUKI@bc4.so-net.ne.jp> 小川創生と申します。 いままで ROM していましたが、あえて以下投稿します。 森山さん (ミラクル・リナックス) は、このメーリングリストでの議論にかかわ らず、IPA (独立行政法人情報処理推進機構) との委託契約上、ISO-2022-JP-MS と名の付くものを開発しなければならない、というような事情があるのではない ですか？ 2005年度下期オープンソースソフトウェア活用基盤整備事業の公募要領 http://www.ipa.go.jp/software/open/2005/koubo2.html#youryo を読むと、開発するソフトウェアの機能を「応募時」に申告し、契約期間の終了 時には機能ごとに検収され、もし検収が不合格なら、契約金額の全部または一部 が支払われなくなるようですね。 このメーリングリスト設立の趣旨として、「日本語文字コードの問題を話し合う メーリングリスト」と記されていますが、このメーリングリストは、IPA との委 託契約に基づいて開発するソフトウェアの機能を議論する場ではないということ になりますよね？ (機能の細部はともかく) そして、ISO-2022-JP-MS を誰が必要としているかについて言えば、国の運営費 交付金で運営されている独立行政法人の IPA は ISO-2022-JP-MS を必要として いるということになってしまう可能性があります。 もしもそうした事情があるなら、それを明示しないとフェアでないと思いますし、 その状態で議論を続けても時間と労力の無駄ではないかと思います。(と案じた のが投稿の動機です) -- 名前: 小川 創生 (おがわ もとゆき) E-mail: motoyuki ＠ bc4.so-net.ne.jp Web: http://www.motoyuki.net/ From hyoshiok ＠ miraclelinux.com Sun Apr 16 12:47:21 2006 From: hyoshiok ＠ miraclelinux.com (Hiro Yoshioka) Date: Sun, 16 Apr 2006 12:47:21 +0900 (JST) Subject: [LE-talk-ja 80] =?iso-2022-jp?b?UmU6IBskQiQzJE4bKEJNTBskQiRHGyhC?= =?iso-2022-jp?b?GyRCJE41RE9APCtCTiRLJEQkJCRGGyhC?= In-Reply-To: <20060415212608.CE29.MOTOYUKI@bc4.so-net.ne.jp> References: <20060415212608.CE29.MOTOYUKI@bc4.so-net.ne.jp> Message-ID: <20060416.124721.884020845.hyoshiok@miraclelinux.com> 小川さま、そしてこのメーリングリストに参加している皆さん、 よしおかと申します。 今回のプロジェクトのプロジェクトマネージャーを しております。 ご指摘の点に関しまして、われわれのポジションを示します。 メーリングリストやOSC2006やYAPC::Asiaでの発表でも 明記、明言しているように今回のプロジェクトはＩＰＡの オープンソースソフトウェア活用基盤整備事業の支援を うけております。 われわれは、そのプロジェクトをバザールモデル的におこないたい という強い意志のもと仕様の議論において全ての情報を公開し、 議論そのものをオープンのプロセスにしております。 社内でおこなっている議論、情報に関しましても、可能な かぎりWikiで公開しております。 http://legacy-encoding.sourceforge.jp/wiki/ われわれはISO-2022-JP-MSが必要でかつ有用であると信じておりますが いくつかの応用においては、ご指摘のとおり他の方式が有用である場合も あると思います。 バザールモデルという開発手法をとる限りコードを書く人に対して ＸＸＸをするなと命令する事はできません。しかしコードを書く人 にＹＹＹの方がよりよいと説得することはできるかもしれません。 多くの方からのコメントをいただき議論をしているのは、この プロジェクトをよりよいものにしたいからです。 単にＩＰＡとの契約を遂行するだけためであれば、わざわざ このような面倒なプロセスをふまづ10月時点で書いた仕様を そのまま実装すればいいだけです。 そうではなく情報を公開しバザールモデル的なプロセスをとって いるのは、よりよいものにしたいというわれわれの意志とご理解 ください。 よ -- Hiro Yoshioka CTO/Miracle Linux Corporation From: OGAWA Motoyuki Subject: [LE-talk-ja 79] このMLでの議論自体について Date: Sat, 15 Apr 2006 22:12:32 +0900 Message-ID: <20060415212608.CE29.MOTOYUKI ＠ bc4.so-net.ne.jp> > 小川創生と申します。 > いままで ROM していましたが、あえて以下投稿します。 > > 森山さん (ミラクル・リナックス) は、このメーリングリストでの議論にかかわ > らず、IPA (独立行政法人情報処理推進機構) との委託契約上、ISO-2022-JP-MS > と名の付くものを開発しなければならない、というような事情があるのではない > ですか？ > > 2005年度下期オープンソースソフトウェア活用基盤整備事業の公募要領 > http://www.ipa.go.jp/software/open/2005/koubo2.html#youryo > を読むと、開発するソフトウェアの機能を「応募時」に申告し、契約期間の終了 > 時には機能ごとに検収され、もし検収が不合格なら、契約金額の全部または一部 > が支払われなくなるようですね。 > > このメーリングリスト設立の趣旨として、「日本語文字コードの問題を話し合う > メーリングリスト」と記されていますが、このメーリングリストは、IPA との委 > 託契約に基づいて開発するソフトウェアの機能を議論する場ではないということ > になりますよね？ (機能の細部はともかく) > > そして、ISO-2022-JP-MS を誰が必要としているかについて言えば、国の運営費 > 交付金で運営されている独立行政法人の IPA は ISO-2022-JP-MS を必要として > いるということになってしまう可能性があります。 > > もしもそうした事情があるなら、それを明示しないとフェアでないと思いますし、 > その状態で議論を続けても時間と労力の無駄ではないかと思います。(と案じた > のが投稿の動機です) > > -- > 名前: 小川 創生 (おがわ もとゆき) > E-mail: motoyuki ＠ bc4.so-net.ne.jp > Web: http://www.motoyuki.net/ > > _______________________________________________ > Legacy-Encoding-talk-ja mailing list > Legacy-Encoding-talk-ja ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/legacy-encoding-talk-ja From tom ＠ asakawa.ne.jp Sun Apr 16 13:14:53 2006 From: tom ＠ asakawa.ne.jp (Tomoyuki Asakawa) Date: Sun, 16 Apr 2006 13:14:53 +0900 Subject: [LE-talk-ja 81] =?iso-2022-jp?b?UmU6IBskQiQzJE4bKEJNTBskQiRHGyhC?= =?iso-2022-jp?b?GyRCJE41RE9APCtCTiRLJEQkJCRGGyhC?= In-Reply-To: <20060416.124721.884020845.hyoshiok@miraclelinux.com> References: <20060415212608.CE29.MOTOYUKI@bc4.so-net.ne.jp> <20060416.124721.884020845.hyoshiok@miraclelinux.com> Message-ID: あさかわです。 > 単にＩＰＡとの契約を遂行するだけためであれば、わざわざ > このような面倒なプロセスをふまづ10月時点で書いた仕様を > そのまま実装すればいいだけです。 はい、そう思います。 > > そうではなく情報を公開しバザールモデル的なプロセスをとって > いるのは、よりよいものにしたいというわれわれの意志とご理解 なので、この様な場をもうけてくれた事に感謝します。 From motoyuki ＠ bc4.so-net.ne.jp Mon Apr 17 13:26:10 2006 From: motoyuki ＠ bc4.so-net.ne.jp (OGAWA Motoyuki) Date: Mon, 17 Apr 2006 13:26:10 +0900 Subject: [LE-talk-ja 82] =?iso-2022-jp?b?UmU6IBskQiQzJE4bKEJNTBskQiRHGyhC?= =?iso-2022-jp?b?GyRCJE41RE9APCtCTiRLJEQkJCRGGyhC?= In-Reply-To: <20060416.124721.884020845.hyoshiok@miraclelinux.com> References: <20060415212608.CE29.MOTOYUKI@bc4.so-net.ne.jp> <20060416.124721.884020845.hyoshiok@miraclelinux.com> Message-ID: <20060417124150.D86D.MOTOYUKI@bc4.so-net.ne.jp> 小川創生です。 On Sun, 16 Apr 2006 12:47:21 +0900 (JST) Hiro Yoshioka さんは書きました: > われわれは、そのプロジェクトをバザールモデル的におこないたい > という強い意志のもと仕様の議論において全ての情報を公開し、 > 議論そのものをオープンのプロセスにしております。 であれば、なおさら、 > 単にＩＰＡとの契約を遂行するだけためであれば、わざわざ > このような面倒なプロセスをふまづ10月時点で書いた仕様を > そのまま実装すればいいだけです。 その10月時点で書いたという仕様 (およびそれに関するプロセス) こそが、公 開すべき最重要情報なのでは？ と問うているのですが。 そして、 ・御社 (ミラクル・リナックス) が契約履行の義務を負っている仕様に ISO-2022-JP-MS と名の付くものが含まれている ・IPA との委託契約後、この ML で ISO-2022-JP-MS 自体を白紙に戻すべきと の主張がなされている という二つの事象が重なっているとしたら、プロセスのオープンさを保てない のではないか？ と案じています。 ＃ 精力的に活動している方々にこのようなことを申し上げるのは心苦しくも ＃ あるのですが、誰かが言うべき事だと思い投稿しています。 -- 名前: 小川 創生 (おがわ もとゆき) E-mail: motoyuki ＠ bc4.so-net.ne.jp Web: http://www.motoyuki.net/ From moriyama ＠ miraclelinux.com Mon Apr 17 19:33:54 2006 From: moriyama ＠ miraclelinux.com (MORIYAMA Masayuki) Date: Mon, 17 Apr 2006 19:33:54 +0900 (JST) Subject: [LE-talk-ja 83] =?iso-2022-jp?b?UmU6IBskQiQzJE4bKEJNTBskQiRHGyhC?= =?iso-2022-jp?b?GyRCJE41RE9APCtCTiRLJEQkJCRGGyhC?= In-Reply-To: <20060417124150.D86D.MOTOYUKI@bc4.so-net.ne.jp> References: <20060416.124721.884020845.hyoshiok@miraclelinux.com> <20060417124150.D86D.MOTOYUKI@bc4.so-net.ne.jp> Message-ID: <20060417193126.BD98.MORIYAMA@miraclelinux.com> ミラクル・リナックスの森山です。 小川さま、コメントありがとうございます。弊社の考え方を のべさせてもらいます。 今回の開発では、cp932, cp51932, eucJP-ms, ISO-2022-JP-MS を、 libiconv, glibc, perl, ruby, PHP, Python, PostgreSQL, MySQL, nkf で使 えるように開発を行うという事になっています。 契約では、それぞれのキャラクタセットに関して細かな仕様に関しては、定義 しておらず、「実装する文字コード変換機能の仕様は、各OSSコミュニティと バザールモデルにより広く意見交換を行い決定する。」としてあります。 最初に ISO-2022-JP-MS として上げた仕様に関して、それで開発する事が検収 条件になっているわけではなく、変更の余地があり、その為の議論とお考えく ださい。 Windows での ISO-2022-JP の実装としては Windows Codepage 50220, 50221, 50222 という 3 種類があり、これと同じものを実装するのであれば、新たな 名前を作る必要はありませんでした。 しかし、これらはユーザ定義文字の扱いに関して、ISO 2022 から逸脱してお り、ISO 2022 を忠実に実装しているものとの相性が悪いという問題があり、 別の名前で、定義して利用する事を考えました。 ISO-2022-JP-MS という名前を新たに作るべきでないという意見もありますの で、その事に関しても必要であれば、ISO-2022-JP-MS ではなく、CP50221 な どの名前で Winodws の実装に近いものを開発するという事も可能と考えてい ます。その場合、名称が変わる旨の連絡を IPA に対して行う必要はあります が、弊社が IPA に対して行うべき事と考えています。 ISO-2022-JP-MS も CP5022X も一切、実装すべきではないという事になってし まうと議論の余地が無くなってしまうのですが、現実問題として、Mozilla Thunderbird や Sylpheed などで類似のものが、すでに実装されていますので、 Windows 機種依存文字を扱えるような 7ビットJIS コードが必要と考えています。 遅くならないうちに議論してきた内容について要約を出す予定でいますので、 よろしくお願いいたします。 -- 森山 将之 moriyama ＠ miraclelinux.com ミラクル・リナックス株式会社 From kazama ＠ mac.com Tue Apr 18 17:52:29 2006 From: kazama ＠ mac.com (Kazuhiro Kazama) Date: Tue, 18 Apr 2006 17:52:29 +0900 Subject: [LE-talk-ja 84] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TICA=?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <20060414195026.D2B8.MORIYAMA@miraclelinux.com> References: <392A807F-240B-4BC7-9DD8-F6E0A8E64494@mac.com> <20060414195026.D2B8.MORIYAMA@miraclelinux.com> Message-ID: <677A1524-D083-4508-BDB5-E82D01478F1A@mac.com> On 2006/04/14, at 22:02, MORIYAMA Masayuki wrote: > CP5022X の仕様が明確になっていないという所が一番の問題ではありますけれ > ども。 それは重要だと思います．確かに，Web上の資料も細かいところが食い違って いる気がしています． なんと，"Developing International Software"の第二版を注文していなかっ た（会社で数年前にちゃんと注文した記憶があるのだが…単に手違いで来てい ない気が）ので，今注文しているのですが，これに何か書かれていませんか ね？＞それとなく 正式な資料が手に入らないようなら，私からMicrosoftにコンタクトしてみま しょうか？ --- 風間 一洋 (kazama ＠ mac.com) From tom ＠ asakawa.ne.jp Tue Apr 18 18:01:14 2006 From: tom ＠ asakawa.ne.jp (Tomoyuki Asakawa) Date: Tue, 18 Apr 2006 18:01:14 +0900 Subject: [LE-talk-ja 85] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TICA=?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <677A1524-D083-4508-BDB5-E82D01478F1A@mac.com> References: <392A807F-240B-4BC7-9DD8-F6E0A8E64494@mac.com> <20060414195026.D2B8.MORIYAMA@miraclelinux.com> <677A1524-D083-4508-BDB5-E82D01478F1A@mac.com> Message-ID: <6F527745-38C5-489B-AC0E-02E52FA2984E@asakawa.ne.jp> あさかわ アマゾンの中身検策で、目次がみえたのですが。 らしい記述ないですねえ。 On 2006/04/18, at 17:52, Kazuhiro Kazama wrote: > なんと，"Developing International Software"の第二版を注 > 文していなかっ > た（会社で数年前にちゃんと注文した記憶があるのだが…単に手違い > で来てい > ない気が）ので，今注文しているのですが，これに何か書かれていま > せんか > ね？＞それとなく From moriyama ＠ miraclelinux.com Tue Apr 18 21:41:38 2006 From: moriyama ＠ miraclelinux.com (MORIYAMA Masayuki) Date: Tue, 18 Apr 2006 21:41:38 +0900 (JST) Subject: [LE-talk-ja 86] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TICA=?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <677A1524-D083-4508-BDB5-E82D01478F1A@mac.com> References: <20060414195026.D2B8.MORIYAMA@miraclelinux.com> <677A1524-D083-4508-BDB5-E82D01478F1A@mac.com> Message-ID: <20060418191133.BDB9.MORIYAMA@miraclelinux.com> 森山です。 Kazuhiro Kazama wrote: > > On 2006/04/14, at 22:02, MORIYAMA Masayuki wrote: > > CP5022X の仕様が明確になっていないという所が一番の問題ではありますけれ > > ども。 > > それは重要だと思います．確かに，Web上の資料も細かいところが食い違って > いる気がしています． マイクロソフトの Web だと、次のような情報くらいしか見つかりませんね。 http://www.google.co.jp/search?as_q=50221&num=100&hl=ja&btnG=Google+%E6%A4%9C%E7%B4%A2&as_epq=&as_oq=&as_eq=&lr=&as_ft=i&as_filetype=&as_qdr=all&as_occt=any&as_dt=i&as_sitesearch=microsoft.com&as_rights= > なんと，"Developing International Software"の第二版を注文していなかっ > た（会社で数年前にちゃんと注文した記憶があるのだが…単に手違いで来てい > ない気が）ので，今注文しているのですが，これに何か書かれていませんか > ね？＞それとなく "Developing International Software" 注文しなければ。 > 正式な資料が手に入らないようなら，私からMicrosoftにコンタクトしてみま > しょうか？ お願いしてよろしいでしょうか。 -- 森山 将之 moriyama ＠ miraclelinux.com ミラクル・リナックス株式会社 From motoyuki ＠ bc4.so-net.ne.jp Wed Apr 19 01:15:16 2006 From: motoyuki ＠ bc4.so-net.ne.jp (OGAWA Motoyuki) Date: Wed, 19 Apr 2006 01:15:16 +0900 Subject: [LE-talk-ja 87] =?iso-2022-jp?b?UmU6IBskQiQzJE4bKEJNTBskQiRHGyhC?= =?iso-2022-jp?b?GyRCJE41RE9APCtCTiRLJEQkJCRGGyhC?= In-Reply-To: <20060417193126.BD98.MORIYAMA@miraclelinux.com> References: <20060417124150.D86D.MOTOYUKI@bc4.so-net.ne.jp> <20060417193126.BD98.MORIYAMA@miraclelinux.com> Message-ID: <20060419010900.2CA4.MOTOYUKI@bc4.so-net.ne.jp> 小川創生です。 On Mon, 17 Apr 2006 19:33:54 +0900 (JST) MORIYAMA Masayuki さんは書きました: > ISO-2022-JP-MS という名前を新たに作るべきでないという意見もありますの > で、その事に関しても必要であれば、ISO-2022-JP-MS ではなく、CP50221 な > どの名前で Winodws の実装に近いものを開発するという事も可能と考えてい > ます。その場合、名称が変わる旨の連絡を IPA に対して行う必要はあります > が、弊社が IPA に対して行うべき事と考えています。 丁寧なご回答ありがとうございます。私の懸念は解消されました。 私もあさかわさんと同様に、この様な場をもうけてくれた事に感謝しています。 -- 名前: 小川 創生 (おがわ もとゆき) E-mail: motoyuki ＠ bc4.so-net.ne.jp Web: http://www.motoyuki.net/ From kazama ＠ mac.com Tue Apr 25 12:34:47 2006 From: kazama ＠ mac.com (Kazuhiro Kazama) Date: Tue, 25 Apr 2006 12:34:47 +0900 Subject: [LE-talk-ja 88] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TICA=?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <20060418191133.BDB9.MORIYAMA@miraclelinux.com> References: <20060414195026.D2B8.MORIYAMA@miraclelinux.com> <677A1524-D083-4508-BDB5-E82D01478F1A@mac.com> <20060418191133.BDB9.MORIYAMA@miraclelinux.com> Message-ID: 返事が遅くなってごめんなさい． On 2006/04/18, at 21:41, MORIYAMA Masayuki wrote: >> 正式な資料が手に入らないようなら，私からMicrosoftにコンタクトしてみま >> しょうか？ > > お願いしてよろしいでしょうか。 はい．もちろん向こうも会社の方針があるので，必ず望む答えが得られるとは 限りませんが，誠意のある対応をしてくれると思います． それで，ここは外したくないという要点があれば列挙して頂けますか？たとえ ば， ・CP5022Xをどれでも処理できるようにしているのか？ ・外字はどうしているか？ ・MSとしては，どのようにして欲しいか？ とか…． ところで，MS用JIS符号化（特定の文字符号化を限定しない，曖昧な表現で す）について考えていて一つ興味深いことがわかりました． というのは，実はUTF-8レベルで文字のマッピング（たとえば，WAVE DASHがU +301CかU+FF5Eか）が混在しちゃうのはどうしようもない（たぶん，本当にど うしようもないと思う…）という仮定に立つとします． また，問題にするのはマッピングの違いであり，文字レパートリはとりあえず 範囲外とも仮定します．これはISO-2022-JPというのが情報交換専用であり文 字レパートリを積集合に限定することが重要だということもありますが，この MLの報告を見ていても，あまりに変種（MS，Mac，メールソフトなど）が多す ぎて，実質的にISO-2022-JPを超えた範囲が使われても，それを完全に同定す るのは難しく，またUnicode変換した時点で意味がなくなる（復旧できない文 字化け）ことです． で，まず現場で一番問題になるのは，クライアントがWindows (CP932)でサー バがUnix系(EUC符号化)という時です．この時は，合わせてCP51932を使えば問 題はないはずです（すでに普及してしまったeucJP-msも，限定された互換性を 持つ？？？）． で，MS用JIS符号化を使うのは，たとえば ・nkf風に文字符号化を相互変換するケース． ・既存のメールをUnicode化してアーカイブ化するケース． ・Webブラウザのように，任意の文字符号化をサポートするケース． だろうなと私は最初考えていました．ところが，これらのケースでは問題は解 決されないようです． というのは，Unicodeをベースとしたピボット変換を前提にすると，必ずUTF-8 がサポートされると考えられます．しかし，UTF-8レベルではマッピングが統 一できないので，たとえばCP5022Xの代わりにISO-2022-JPを使っても状況は同 じ（一部の文字の欠落は許容する）ことになります． たとえばWebブラウザの場合には，どちらの符号位置でも表示さえできれば問 題は顕在化しにくいかもしれません．というのは，UTF-8のページはUTF-8で保 存するからです．また，Unicodeデータベースアーカイブに既存のJISメールを マージするのも同じです．それは，一般にマッピングが異なる記号類は全文検 索では無視されることが多い（その方がユーザの利便性が高い…たとえば，ハ イフンでもスペースでもよいとか）からです． しかし，nkf風プログラムの場合には，レガシーエンコーディングに戻さなけ ればいけないので，文字が化けてしまうことになります． これを回避するためには，たとえば次のような対策が必要です． 1, UTF-8入力をサポートしない． 2, プログラム内でどちらかに正規化する． 3, 出力時に，どちらも同じ文字に変換できる（例，U+301CとU+FF5EもWAVE DASHに）ようにする． さて，これをどうするか…ということですねえ…． 結局，CP5022Xの導入だけでマッピングの違いをカバーできるのは，UTF-8をサ ポートしないでISO-2022-JPでしかやりとりしないシステムということになり そうです． なお，Unicodeベースのピボット変換をしないシステムについては考えていな いので，何か考察すべきことがあればお願いします． --- 風間 一洋 (kazama ＠ mac.com) From taca ＠ back-street.net Tue Apr 25 13:04:55 2006 From: taca ＠ back-street.net (Takahiro Kambe) Date: Tue, 25 Apr 2006 13:04:55 +0900 (JST) Subject: [LE-talk-ja 89] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TIA==?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: References: <677A1524-D083-4508-BDB5-E82D01478F1A@mac.com> <20060418191133.BDB9.MORIYAMA@miraclelinux.com> Message-ID: <20060425.130455.74746556.taca@back-street.net> こんにちは。 In message on Tue, 25 Apr 2006 12:34:47 +0900, Kazuhiro Kazama wrote: > 範囲外とも仮定します．これはISO-2022-JPというのが情報交換専用であり文 > 字レパートリを積集合に限定することが重要だということもありますが，この > MLの報告を見ていても，あまりに変種（MS，Mac，メールソフトなど）が多す > ぎて，実質的にISO-2022-JPを超えた範囲が使われても，それを完全に同定す > るのは難しく，またUnicode変換した時点で意味がなくなる（復旧できない文 この手の変種を「ISO-2022-JPの実装」と森山さんが書かれていたと思います が、「ISO-2022-JPの亜種」と呼ぶべきものではないかと思います。 少し横にそれますが、RFC1468では ISO-2022-JP は、 Esc Seq Character Set ISOREG ESC ( B ASCII 6 ESC ( J JIS X 0201-1976 ("Roman" set) 14 ESC $ @ JIS X 0208-1978 42 ESC $ B JIS X 0208-1983 87 と、規定しています。厳密には、JIS X 0208-1990 や JIS X 0208-1997 とか は扱えません。:-) (JIS X 0208-1990を表すための改版だったかのエスケー プ・シーケンス自体も存在していたと記憶しています。) -- 神戸 隆博(かんべ たかひろ) at 仕事場 From umq.876 ＠ gmail.com Tue Apr 25 13:42:17 2006 From: umq.876 ＠ gmail.com (Hirohisa Yamaguchi) Date: Tue, 25 Apr 2006 13:42:17 +0900 Subject: [LE-talk-ja 90] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TIA==?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <20060425.130455.74746556.taca@back-street.net> References: <677A1524-D083-4508-BDB5-E82D01478F1A@mac.com> <20060418191133.BDB9.MORIYAMA@miraclelinux.com> <20060425.130455.74746556.taca@back-street.net> Message-ID: <1dba65f30604242142h6c1bebf4kfd24c4dbeea41abe@mail.gmail.com> やまぐちと申します # さらに横道へ On 4/25/06, Takahiro Kambe wrote: > 少し横にそれますが、RFC1468では ISO-2022-JP は、 > Esc Seq Character Set ISOREG > ESC ( B ASCII 6 > ESC ( J JIS X 0201-1976 ("Roman" set) 14 > ESC $ @ JIS X 0208-1978 42 > ESC $ B JIS X 0208-1983 87 > と、規定しています。厳密には、JIS X 0208-1990 や JIS X 0208-1997 とか > は扱えません。:-) (JIS X 0208-1990を表すための改版だったかのエスケー > プ・シーケンス自体も存在していたと記憶しています。) ISO/IEC 2022:1994 に対応する、JIS X0202:1998 では 14.5 登録文字集合の改定番号の識別 という節で、ESC 02/06 F 形式のシーケンスで、後続の指示の版数を 指定できるとあります。 > 改版だったかのエスケープ・シーケンス とは、おそらくこれかと -- end やまきゅう umq.876 ＠ gmail.com From moriyama ＠ miraclelinux.com Tue Apr 25 21:13:34 2006 From: moriyama ＠ miraclelinux.com (MORIYAMA Masayuki) Date: Tue, 25 Apr 2006 21:13:34 +0900 (JST) Subject: [LE-talk-ja 91] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TICA=?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: References: <20060418191133.BDB9.MORIYAMA@miraclelinux.com> Message-ID: <20060425153745.D406.MORIYAMA@miraclelinux.com> 森山です。 Kazuhiro Kazama wrote: > 返事が遅くなってごめんなさい． こちらこそ、要約を出すといっていて出せていなくて申し訳ありません。 > On 2006/04/18, at 21:41, MORIYAMA Masayuki wrote: > >> 正式な資料が手に入らないようなら，私からMicrosoftにコンタクトしてみま > >> しょうか？ > > > > お願いしてよろしいでしょうか。 > > はい．もちろん向こうも会社の方針があるので，必ず望む答えが得られるとは > 限りませんが，誠意のある対応をしてくれると思います． > > それで，ここは外したくないという要点があれば列挙して頂けますか？たとえ > ば， > ・CP5022Xをどれでも処理できるようにしているのか？ > ・外字はどうしているか？ > ・MSとしては，どのようにして欲しいか？ > > とか…． 次の点が一番の要点となるかと思いますので、よろしくお願いいたします。 ・Windows の Codepage 50220, 50221, 50222 による変換で、Unicode の U+E000〜U+E757 にマッピングされているものは、Windows での仕様と考え てよいか? 仕様でなければ、ISO 2022 をまじめに実装しているものでも、ユーザ定義文 字の変換は行わないようにする事で、CP5022X を利用できるようにできると考 えています。 > ところで，MS用JIS符号化（特定の文字符号化を限定しない，曖昧な表現で > す）について考えていて一つ興味深いことがわかりました． > > というのは，実はUTF-8レベルで文字のマッピング（たとえば，WAVE DASHがU > +301CかU+FF5Eか）が混在しちゃうのはどうしようもない（たぶん，本当にど > うしようもないと思う…）という仮定に立つとします． この問題があるので、今までは積極的に UTF-8 を使う事はしていませんでし た。 ただ、Blog が起爆剤となってか、Web での UTF-8 の利用が増えてきているよ うに感じています。 > で，MS用JIS符号化を使うのは，たとえば > > ・nkf風に文字符号化を相互変換するケース． > ・既存のメールをUnicode化してアーカイブ化するケース． > ・Webブラウザのように，任意の文字符号化をサポートするケース． > > だろうなと私は最初考えていました．ところが，これらのケースでは問題は解 > 決されないようです． > > というのは，Unicodeをベースとしたピボット変換を前提にすると，必ずUTF-8 > がサポートされると考えられます．しかし，UTF-8レベルではマッピングが統 > 一できないので，たとえばCP5022Xの代わりにISO-2022-JPを使っても状況は同 > じ（一部の文字の欠落は許容する）ことになります． どのマッピングも等しく使われているのであれば、どれを使っても状況は同じ ことになると言えると思います。 ただ、現実問題として Windows がクライアント OS として広く使われてい るという事を考えると、CP5022X を使った方が ISO-2022-JP を使うよりも UTF-8 からの変換での文字ばけの頻度は抑えられるのではないかと考えていま す。 > しかし，nkf風プログラムの場合には，レガシーエンコーディングに戻さなけ > ればいけないので，文字が化けてしまうことになります． > > これを回避するためには，たとえば次のような対策が必要です． > > 1, UTF-8入力をサポートしない． > 2, プログラム内でどちらかに正規化する． > 3, 出力時に，どちらも同じ文字に変換できる（例，U+301CとU+FF5EもWAVE > DASHに）ようにする． > > さて，これをどうするか…ということですねえ…． glibc, libiconv のパッチでは 3. の方法を取っています。 具体的には、次の 表1, 表2 のような変換を行っています。 表1 文字 Unicode 文字名称 変換方向 JIS(GL) ----------------------------------------------- \ U+00A5 YEN SIGN → 0x5C \ U+005C REVERSE SOLIDUS ←→ 0x5C ----------------------------------------------- ~ U+203E OVERLINE → 0x7E ~ U+007E TILDE ←→ 0x7E ----------------------------------------------- 表2 文字 Unicode 文字名称 変換方向 JIS(GL) ----------------------------------------------- ― U+2014 EM DASH → 0x213D ― U+2015 HORIZONTAL BAR ←→ 0x213D ----------------------------------------------- 〜 U+301C WAVE DASH → 0x2141 〜 U+FF5E FULLWIDTH TILDE ←→ 0x2141 ----------------------------------------------- ‖ U+2016 DOUBLE VERTICAL LINE → 0x2142 ‖ U+2225 PARALLEL TO ←→ 0x2142 ----------------------------------------------- − U+2212 MINUS SIGN → 0x215D − U+FF0D FULLWIDTH HYPHEN-MINUS ←→ 0x215D ----------------------------------------------- ¢ U+00A2 CENT SIGN → 0x2171 ¢ U+FFE0 FULLWIDTH CENT SIGN ←→ 0x2171 ----------------------------------------------- £ U+00A3 POUND SIGN → 0x2172 £ U+FFE1 FULLWIDTH POUND SIGN ←→ 0x2172 ----------------------------------------------- ¬ U+00AC NOT SIGN → 0x224C ¬ U+FFE2 FULLWIDTH NOT SIGN ←→ 0x224C ----------------------------------------------- 表1 での U+00A5, U+203E の変換に関しては、Unicode では US-ASCII ではな かった文字が、レガシーエンコーディングに変換すると US-ASCII (JIS X 0201 ラテン文字) に変換されてしまうため問題が発生するケースがあるよう です。 > 結局，CP5022Xの導入だけでマッピングの違いをカバーできるのは，UTF-8をサ > ポートしないでISO-2022-JPでしかやりとりしないシステムということになり > そうです． CP5022X を導入した場合、UTF-8 からの変換で、U+301C WAVE DASH が変換で きないとしても、CP932, CP51932, eucJP-ms と CP5022X との変換が可能だと いう事と、Windows の API で UTF-8 (Unicode) に変換されたものは、扱える ようになるので、それなりのメリットはあると考えています。 一度、Unicode に変換してやりとりされたデータに関しては、基本的にレガシー エンコーディングには戻せない。もしくは戻せたとしても元のデータに戻る保 障は無いという認識を広めいていく必要があるでしょうね。 > なお，Unicodeベースのピボット変換をしないシステムについては考えていな > いので，何か考察すべきことがあればお願いします． CP5022X や CP51932 をアルゴリズム的な変換で CP932 へ文字コード変換した 場合に、CP5022X や CP51932 の NEC選定IBM拡張文字(89区〜92区)をそのまま、 NEC選定IBM拡張文字の符号位置に変換するという実装が多いかと思います。 表示を行うだけであれば、それだも良いのですが、CSI(Code Set Independent) な実装を行っているソフトウェアでは、NEC選定IBM拡張文字とIBM拡張文字 (115区〜119区)は、表示上同じ文字であっても符号位置が異なるという事で別 字として扱われてしまうので注意が必要になってきます。 -- 森山 将之 moriyama ＠ miraclelinux.com ミラクル・リナックス株式会社 From moriyama ＠ miraclelinux.com Tue Apr 25 21:15:59 2006 From: moriyama ＠ miraclelinux.com (MORIYAMA Masayuki) Date: Tue, 25 Apr 2006 21:15:59 +0900 (JST) Subject: [LE-talk-ja 92] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TIA==?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <1dba65f30604242142h6c1bebf4kfd24c4dbeea41abe@mail.gmail.com> References: <20060425.130455.74746556.taca@back-street.net> <1dba65f30604242142h6c1bebf4kfd24c4dbeea41abe@mail.gmail.com> Message-ID: <20060425211109.D411.MORIYAMA@miraclelinux.com> 森山です。 "Hirohisa Yamaguchi" wrote: > やまぐちと申します > # さらに横道へ > > On 4/25/06, Takahiro Kambe wrote: > > 少し横にそれますが、RFC1468では ISO-2022-JP は、 > > > Esc Seq Character Set ISOREG > > > ESC ( B ASCII 6 > > ESC ( J JIS X 0201-1976 ("Roman" set) 14 > > ESC $ @ JIS X 0208-1978 42 > > ESC $ B JIS X 0208-1983 87 > > > と、規定しています。厳密には、JIS X 0208-1990 や JIS X 0208-1997 とか > > は扱えません。:-) (JIS X 0208-1990を表すための改版だったかのエスケー > > プ・シーケンス自体も存在していたと記憶しています。) > > ISO/IEC 2022:1994 に対応する、JIS X0202:1998 では > 14.5 登録文字集合の改定番号の識別 > という節で、ESC 02/06 F 形式のシーケンスで、後続の指示の版数を > 指定できるとあります。 > > > 改版だったかのエスケープ・シーケンス > とは、おそらくこれかと やまぐちさんのご指摘のとおりです。 JIS X 0208:1997 にも書いてありまして、JIS X 0208-1990 もしくは JIS X 0208:1997 を G0 集合に指示するエスケープシーケンスは、次のとおりです。 ESC 2/6 4/0 ESC 2/4 4/2 ( ESC & @ ESC $ B ) JIS X 0208:1997 では、文字の追加・削除・入替えなど文字集合に対する変更 及び規格票の字形の変更は、一切行われていないため、JIS X 0208-1990 と同 じエスケープシーケンスが使えます。 参考) JIS X 0208:1997 -「9.2 指示」 JIS X 0202:1998 -「14.5 登録文字集合の改定番号の識別」 JIS規格は、http://www.jisc.go.jp/ の「JIS検索」から PDF ファイル を閲覧可能となっています。ちなみに、上記 PDF ファイルでは、「解説」は 省略されています。 -- 森山 将之 moriyama ＠ miraclelinux.com ミラクル・リナックス株式会社 From tom ＠ asakawa.ne.jp Wed Apr 26 09:54:23 2006 From: tom ＠ asakawa.ne.jp (Tomoyuki Asakawa) Date: Wed, 26 Apr 2006 09:54:23 +0900 Subject: [LE-talk-ja 93] =?iso-2022-jp?b?GyRCMj8kLEA1JDckJCQrJGgkajI/GyhC?= =?iso-2022-jp?b?GyRCJCxJLE1XJCskOCRjJEokJCRHJDckZyQmJCshKRsoQg==?= Message-ID: あさかわです。 なんかもやもやしていたんですが。 コード変換機能として、必要なのは何？という視点で考えると 例えば5C問題は。 SJIS -> UTF なら YEN SIGIN EUC -> UTF なら　Back Slash というふうに、決めうちすべきではないと思います。 SJIS/EUCに関わらず、 5C を、UTFにする場合は、 YEN SIGN と Back Slashの選択ができる必要がある 逆に、UTF のYEN SIGNも、Back Slashも、SJIS/ EUCに変換する場合は UTFの YEN SIGNは、5Cもしくは、２バイトのYEN SIGN。 UTFの Back Slashは、5Cもしくは、２バイトのBack Slash と思います。（どうやって選択するかは別次元) 規格とか標準ってものに、凝り固まると、上記の考えは受け入れがたい でしょうけども。 SJISに設定されてるエデイタで書いたCのソースと、 EUCに設定されてる、エディタで書いたCのソースの中の 5Cというコードは、バックスラッシュで表示されていようと、YEN SIGNで表示されていようと どちらも、エスケープとして使用されてるわけです。 この２つのファイルを、UTFに変換した時に、どちらも同じもの （Back Slash）ではなくては困るわけです。 逆に、金額を表記する為に5cを使っていた場合は、どちらも、 YEN SIGNでなくては困るわけです。 5cというビットパターンだけでは、何を目的としているかわからないの が現実なので その現実を許容する必要があると思います。 すべて、UTFにすれば良いという考え方が正しいという仮説の元 でも 非UTFの資産を、UTFに変換する場合に、適切に変換できる 様にする必要があるとおもいます。 先に示したのは、5c問題ですが。WAVE DASH問題も同じだ と思います。 例えば、NEC9801で作成していた、ファイルは、78JISだと 想定されます。 また、EPSONの98互換機や、AXマシンで作成された、 83JISだと想定されます。 しからば、これらのファイルをUTFに変換する場合は、それぞれ に適切な対応が必要と思います。 いわゆる機種依存文字問題も、同じだとおもう。 9801の内蔵FONT ROMから継承した、Windows拡張文字につ いても、 使用されているのが現状ですから、かのうな限り、UTFに変換す る必要があります。 RFCに無い亜種の存在を否定する人がいますが。 RFCは、あくまで、インターネットという環境での、一つの実装にすぎ ないと思います。 このMLのきっかけになったのは、sambaです。 sambaは、インターネットとは直接は無関係ですから、RFCを適用 するのはおかしいと思います。 sambaの場合に重要なのは sambaの漢字のファイル名の扱いを、Windowsでの扱いと、同じに する事がMASTのはずです。 なので、sambaだけ、なんとかしてしまうという方法もあるとお もいますが 結局、このコード変換というものは、他の環境でも必要になるので 統一してやりましょうというのが、このMLの趣旨だと理解してい ます。 しかし、その結論が、私は、新しい汎用コードページを作成することで はなく 汎用のコード変換モジュールを作成することだと思います。 汎用のコード変換があれば PostgresSQLやMySQLで、すべての文字をあつかうことができる様 にもなるはずです。 汎用のコード変換であれば、当事者の合意のもとに、携帯電話に SJISでメールを出すMUAを作成できます。 もちろん、RFCに厳密にしたがったメールしか出せないMUA を作成することだってできます。 その場合、RFCに違反した文字の扱い(たとえば半角カナは 全角にするなどもできる) いまだと、そういうことを使用とすると、DBなどには、変換され ないコードポイントだけ維持されるモードをつかって 自力で変換をかかないとならないわけです。 まあ、携帯など、あまりにぐちゃぐちゃなのは、アダプタブルでいいと おもいますが すくなくとも、JISコードの範囲ないですらおきる、問題は、標 準的に選択可能になっていてほしい。 利用者側が選択可能であればいい。 sambaの場合、クライアントとして、何がくるかという問題だけではなく sambaが実行されてる、サーバ環境が、なにかという問題もあります。 サーバ側が、UTF環境なのか、EUC環境なのか サーバ側の設定と、クライアント側の設定は、独立事象で設定したいわ けです。 PostgreSQLは、Winodws上でも動作させることができます。 その場合、Windows上で、違和感なく、動作させる設定が必要で すし UNIXや、MACから、アクセスされることを考慮した、設定も必要 です。 つまり、私の意見としては、RFCから物をみてはイケナイのでは ないだろうという事です。 ちなみに、機種依存文字というのは、フォント依存文字と言うべきだろ うと思います。 同じ機種でも、フォントを切り替えると、見える文字の形が変わります。 78JIS/83JIS問題は、この現象の一部です。 YEN SIGNや、WAVE DASH問題も、同様だと思います。 From moriyama ＠ miraclelinux.com Fri Apr 28 15:10:10 2006 From: moriyama ＠ miraclelinux.com (MORIYAMA Masayuki) Date: Fri, 28 Apr 2006 15:10:10 +0900 (JST) Subject: [LE-talk-ja 94] =?iso-2022-jp?b?UmU6IBskQjI/JCxANSQ3JCQkKyRoGyhC?= =?iso-2022-jp?b?GyRCJGoyPyQsSSxNVyQrJDgkYyRKJCQkRyQ3JGckJiQrISkbKEI=?= In-Reply-To: References: Message-ID: <20060428141235.BC57.MORIYAMA@miraclelinux.com> 森山です。 あさかわさん、はじめまして。 返事が遅くなり申し訳ありません。 何が正しいかより何が必要かという事を考える場合、そもそも標準規格では、 どうなっているのかという事をベースに考える必要があると思います。 標準規格さえ守っていれば問題ないという状況が作り出されているのであれば 良いのですが、現実にはそうなっていませんから、いろいろと問題が発生して しまっているのだと理解しています。 > SJIS -> UTF なら YEN SIGIN > EUC -> UTF なら　Back Slash この変換は、IANA に登録されている Shift_JIS, EUC-JP を調べて素直に実装 すると、上記のようなマッピングになってしまうのだと思います。 何を頼りに実装を行うのかという、標準規格などの公式な規格を優先すると考 えるのが自然ですから、上記のような変換が実用上問題であったとしても、間 違いではないという所が、悩ましいところです。 > 先に示したのは、5c問題ですが。WAVE DASH問題も同じだ > と思います。 > > 例えば、NEC9801で作成していた、ファイルは、78JISだと > 想定されます。 > また、EPSONの98互換機や、AXマシンで作成された、 > 83JISだと想定されます。 > しからば、これらのファイルをUTFに変換する場合は、それぞれ > に適切な対応が必要と思います。 すべてのものに対して、平等に対応できる事が理想ですけれども、果たしてそ こまでする必要があるのかという事も考える必要があると思います。 > ちなみに、機種依存文字というのは、フォント依存文字と言うべきだろ > うと思います。 > 同じ機種でも、フォントを切り替えると、見える文字の形が変わります。 > 78JIS/83JIS問題は、この現象の一部です。 Unicode ベースのシステムでは、フォント依存文字という呼び方も通用しなく なりつつありますから、JIS X 0208 外字とでも呼んだほうがいいかもしれま せん。 -- 森山 将之 moriyama ＠ miraclelinux.com ミラクル・リナックス株式会社 From kazama ＠ mac.com Fri Apr 28 21:37:43 2006 From: kazama ＠ mac.com (Kazuhiro Kazama) Date: Fri, 28 Apr 2006 21:37:43 +0900 Subject: [LE-talk-ja 95] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TIA==?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <20060425.130455.74746556.taca@back-street.net> References: <677A1524-D083-4508-BDB5-E82D01478F1A@mac.com> <20060418191133.BDB9.MORIYAMA@miraclelinux.com> <20060425.130455.74746556.taca@back-street.net> Message-ID: On 2006/04/25, at 13:04, Takahiro Kambe wrote: > In message > on Tue, 25 Apr 2006 12:34:47 +0900, > Kazuhiro Kazama wrote: >> 範囲外とも仮定します．これはISO-2022-JPというのが情報交換専用であり文 >> 字レパートリを積集合に限定することが重要だということもありますが， >> この >> MLの報告を見ていても，あまりに変種（MS，Mac，メールソフトなど）が多す >> ぎて，実質的にISO-2022-JPを超えた範囲が使われても，それを完全に同定す >> るのは難しく，またUnicode変換した時点で意味がなくなる（復旧できない文 > この手の変種を「ISO-2022-JPの実装」と森山さんが書かれていたと思います > が、「ISO-2022-JPの亜種」と呼ぶべきものではないかと思います。 ここで仮定しているのは，森山さんの定義とも違います．具体的には， ISO-2022-JPと同じ文字レパートリであるが，UnicodeへのマッピングがMS的と いうものです．というのは，やはりISO-2022-JPは情報交換用に文字レパート リを規定する規格ですので．しかし，Unicodeへのマッピングは必ずしも明確 に規定されていません． > 厳密には、JIS X 0208-1990 や JIS X 0208-1997 とか > は扱えません。:-) (JIS X 0208-1990を表すための改版だったかのエスケー > プ・シーケンス自体も存在していたと記憶しています。) これに関してはRFC1468中で次のように書かれて，それは使わないことが推奨 されているようです． The JIS X 0208 standard was revised in 1990, to add two characters at the end of the table. Although ISO 2022 specifies special additional escape sequences to indicate the use of revised character sets, it is suggested here not to make use of this special escape sequence in ISO-2022-JP text, even if the two characters added to JIS X 0208 in 1990 are used. ISO-2022-JPは，ISO標準の方とは少々離反しちゃっていますからね…． --- 風間 一洋 (kazama ＠ mac.com) From kazama ＠ mac.com Fri Apr 28 21:51:15 2006 From: kazama ＠ mac.com (Kazuhiro Kazama) Date: Fri, 28 Apr 2006 21:51:15 +0900 Subject: [LE-talk-ja 96] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TIA==?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <20060425211109.D411.MORIYAMA@miraclelinux.com> References: <20060425.130455.74746556.taca@back-street.net> <1dba65f30604242142h6c1bebf4kfd24c4dbeea41abe@mail.gmail.com> <20060425211109.D411.MORIYAMA@miraclelinux.com> Message-ID: On 2006/04/25, at 21:15, MORIYAMA Masayuki wrote: > やまぐちさんのご指摘のとおりです。 > > JIS X 0208:1997 にも書いてありまして、JIS X 0208-1990 もしくは JIS X > 0208:1997 を G0 集合に指示するエスケープシーケンスは、次のとおりです。 > > ESC 2/6 4/0 ESC 2/4 4/2 ( ESC & @ ESC $ B ) > > JIS X 0208:1997 では、文字の追加・削除・入替えなど文字集合に対する変更 > 及び規格票の字形の変更は、一切行われていないため、JIS X 0208-1990 と同 > じエスケープシーケンスが使えます。 > > 参考) > JIS X 0208:1997 -「9.2 指示」 > JIS X 0202:1998 -「14.5 登録文字集合の改定番号の識別」 前のメールにちょっとだけ書きましたが，ISO-2022-JPは，ISO/IEC 2022を ベースにしてはいますが，実際には異なる文字符号化だと認識した方がよいと 思います．実際に，かなり制限していますし（これは意図的です），相反する 部分も多少あります． --- 風間 一洋 (kazama ＠ mac.com) From tom ＠ asakawa.ne.jp Sat Apr 29 10:02:54 2006 From: tom ＠ asakawa.ne.jp (Tomoyuki Asakawa) Date: Sat, 29 Apr 2006 10:02:54 +0900 Subject: [LE-talk-ja 97] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TIA==?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: References: <20060425.130455.74746556.taca@back-street.net> <1dba65f30604242142h6c1bebf4kfd24c4dbeea41abe@mail.gmail.com> <20060425211109.D411.MORIYAMA@miraclelinux.com> Message-ID: あさかわ > 前のメールにちょっとだけ書きましたが，ISO-2022-JPは，ISO/ > IEC 2022を > ベースにしてはいますが，実際には異なる文字符号化だと認識した方 > がよいと > 思います．実際に，かなり制限していますし（これは意図的です）， > 相反する > 部分も多少あります． そうですね。 ISO-2022-JPを決めるとき、EUCに変換した時に、困らない様にと いう、ご都合主義できめられてる事がISO-2022の不幸だとおもて います。 これは、SJISが、MSBASCOMを、CP/Mで使うときに困 らない様にというご都合主義で決められたのと同じです。 そもそもISO-2022-JPが決められた前（以後も)は、 UNIX圏以外では、JISというと、 GL = ISO646日本版 GR = JISX0201（当時はC6220) を初期状態としていました。 漢字をつかう時は ESC $ @ で、GLに、X0208を呼び出していたわけです。 不要になると ESC ( Bで、GLに、ISO646日本語版を呼び出す こういう切り替えが、一般的にJISと呼ばれていました。 なのに、EUCで扱えないという理由で、半角カナを、GRに 呼び出すことを、禁止した形でISO-2022-JPをRFCにしてし まった。 当時、インターネットなんて使っていた人は、一部の人だったけれども この一部の人が、作成した、RFCが、現在の混乱の一つの芽をこ こで作ってるのです。 ７ビットに押さえるという目的なら、GLに、よびだせばよかった のです。 当時の実装としてそういうものもあったのですから。 純粋なISO-2022原理主義者だった私から言えば,SJISも EUCも内部コードです。 内部コードで外部コードを規定すべきではない。ISO-2022-JPは EUCの7ビット版になってしまってる。 ISO-2022には、初期状態は、当事者間の想定のみで決まるという「欠 陥」がありますこれを補う為に 初期状態を、どこかで管理する必要はあるとおもっていました。なの で、ISO-2022-JPをRFCにしたと聞いたとき これは、前述の初期状態を規定したものだとおもっていました。 ところが、初期状態だけではなく、状態遷移まで規定していた。 しかも、GLは、ISO646日本語版ではなく、ASCII だった。(5cがバックスラッシュ) （それがわからなかった自分を悔やみます) 各国も同様な基準でISO2022の初期状態を規定するだけにしてお けば、 ISO-2022という、規格にしたがってる文字集合はすべてあつかえたはず なわけです ネット上は、ISO2022だけで扱うことにして、UTFを、垂れ 流しする必要はなかったはずです。 UTFは処理系の内部コードとして扱うことができたはずなのです。 EUCやSJISという内部コードを外部に垂れ流しした、パソコン通 信と同じ轍を踏んでる。 まあ、過去を後悔しても仕方ないのですが、 Unicodeで統一すればというのは理想ですが、わたしの知ってる過去２ ５年間の歴史から考えると無理ですね。 すべて併存されてしまうでしょう。 その、併存を前提にものを考えないと、いつまでたっても、同じ話を繰 り返す事になる。 そうすると、新しい、コードページを作るというのは、非常に危険です。 From taca ＠ back-street.net Sat Apr 29 19:14:11 2006 From: taca ＠ back-street.net (Takahiro Kambe) Date: Sat, 29 Apr 2006 19:14:11 +0900 (JST) Subject: [LE-talk-ja 98] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TIA==?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: References: <20060425.130455.74746556.taca@back-street.net> Message-ID: <20060429.191411.91446181.taca@back-street.net> In message on Fri, 28 Apr 2006 21:37:43 +0900, Kazuhiro Kazama wrote: > > 厳密には、JIS X 0208-1990 や JIS X 0208-1997 とか > > は扱えません。:-) (JIS X 0208-1990を表すための改版だったかのエスケー > > プ・シーケンス自体も存在していたと記憶しています。) > > これに関してはRFC1468中で次のように書かれて，それは使わないことが推奨 > されているようです． あぁ、これはずっと見落としていました、ご指摘ありがとうございます。 -- 神戸 隆博 / Takahiro Kambe From taca ＠ back-street.net Sat Apr 29 19:19:47 2006 From: taca ＠ back-street.net (Takahiro Kambe) Date: Sat, 29 Apr 2006 19:19:47 +0900 (JST) Subject: [LE-talk-ja 99] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TIA==?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: References: <20060425211109.D411.MORIYAMA@miraclelinux.com> Message-ID: <20060429.191947.54184881.taca@back-street.net> あまり歴史のことを掘り返しても仕方ないかもしれませんが、 In message on Sat, 29 Apr 2006 10:02:54 +0900, Tomoyuki Asakawa wrote: > なのに、EUCで扱えないという理由で、半角カナを、GRに > 呼び出すことを、禁止した形でISO-2022-JPをRFCにしてし > まった。 日本語EUCで扱えないという理由よりは、 o 積極的に(フォントが汚いから?)見たくない。 o 日本語EUCの半角仮名の使用を許すと、3つの文字エンコーディングの 自動判別が困難になる。 といった背景もあったような記憶があります。 -- 神戸 隆博 / Takahiro Kambe From kazama ＠ mac.com Sun Apr 30 21:56:24 2006 From: kazama ＠ mac.com (Kazuhiro Kazama) Date: Sun, 30 Apr 2006 21:56:24 +0900 Subject: [LE-talk-ja 100] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TIA==?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: References: <20060425.130455.74746556.taca@back-street.net> <1dba65f30604242142h6c1bebf4kfd24c4dbeea41abe@mail.gmail.com> <20060425211109.D411.MORIYAMA@miraclelinux.com> Message-ID: On 2006/04/29, at 10:02, Tomoyuki Asakawa wrote: > Unicodeで統一すればというのは理想ですが、わたしの知ってる過去２ > ５年間の歴史から考えると無理ですね。 > すべて併存されてしまうでしょう。 > > その、併存を前提にものを考えないと、いつまでたっても、同じ話を繰 > り返す事になる。 > > そうすると、新しい、コードページを作るというのは、非常に危険です。 私もレガシーエンコーディングに関して新しいコードページを作ることは，百 害あって一利無しだと思っています．あと，情報交換用コードと，システム内 部コードを区別すべきだと思います． 今でさえ，レガシーエンコーディングが山のように有ります．それらを使わざ るをえないケースというのはあるでしょう．しかし，今更，それらと違う新し いレガシーエンコーディングを作っても，どちらにせよ完全に解決できない問 題を，さらに複雑化するだけでしょう． また，新しいことは，できる限り国際的にやるべきであって，局地的にやるべ きではないと思います．局地的にゲリラ的にやるのは，ソフトウェアの世界に 対するテロでしかないと思います．としたら，今はISO/IEC 10646に対してお こなうしかない． もちろん，あんな問題だらけのUnicode/10646ではなく，新しい体系に移って もかまわないでしょう．ただし，歴史的には完璧な文字コードは決して設計で きないことが証明されてしまっているので，よほどのメリットがない限りは大 小同意の結果になるだろうと思っています…というのは，文字は技術や文化だ けでなく，宗教的・政治的な側面を持つからです． On 2006/04/29, at 19:19, Takahiro Kambe wrote: > あまり歴史のことを掘り返しても仕方ないかもしれませんが、 ただ，その設計の背景を知って貰うのは重要でしょう． 森山さんのような若い世代は，ISO-2022-JPの背景を知らないと思っていま す．いかにもISO/IEC 2022に完全に準拠しているようでしていないとか，ある 種の文字がサポートされていないのは，単なる欠陥ではなく，意図的に除外し ているのだということとか． それを教えるのは，意味があることではないでしょう． --- 風間 一洋 (kazama ＠ mac.com) From kazama ＠ mac.com Sun Apr 30 22:14:54 2006 From: kazama ＠ mac.com (Kazuhiro Kazama) Date: Sun, 30 Apr 2006 22:14:54 +0900 Subject: [LE-talk-ja 101] =?iso-2022-jp?b?UmU6IBskQjI/JCxANSQ3JCQkKyRoGyhC?= =?iso-2022-jp?b?GyRCJGoyPyQsSSxNVyQrJDgkYyRKJCQkRyQ3JGckJiQrISkbKEI=?= In-Reply-To: <20060428141235.BC57.MORIYAMA@miraclelinux.com> References: <20060428141235.BC57.MORIYAMA@miraclelinux.com> Message-ID: <570034E6-E29F-4A4D-B667-14A0C6D1A815@mac.com> On 2006/04/28, at 15:10, MORIYAMA Masayuki wrote: > 何が正しいかより何が必要かという事を考える場合、そもそも標準規格では、 > どうなっているのかという事をベースに考える必要があると思います。 > > 標準規格さえ守っていれば問題ないという状況が作り出されているのであれば > 良いのですが、現実にはそうなっていませんから、いろいろと問題が発生して > しまっているのだと理解しています。 標準規格ではどうなっているのかという事をベースに新たに考えるのではな く，基本的にはどの標準規格およびデファクト標準を採用するのか，そしてそ れらで明確に規定されていない部分をどうするのかということを考えるべきで はないでしょうか． たとえば，次のような方針がよいと思っています． ・既存のレガシーエンコーディングを対象とする．新しいレガシーエンコー ディングは作らない． ・現在，広く使われているレガシーエンコーディングにおける問題を明確に分 析する． ・広く発生する問題に対しては，その解決法を明示し，さらに(一部を)実装す る． --- 風間 一洋 (kazama ＠ mac.com)