From tom ＠ asakawa.ne.jp Tue May 2 06:06:48 2006 From: tom ＠ asakawa.ne.jp (Tomoyuki Asakawa) Date: Tue, 2 May 2006 06:06:48 +0900 Subject: [LE-talk-ja 102] =?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: <7A3862C7-06B9-4E97-A891-1198A4EA3B08@asakawa.ne.jp> あさかわ > 私もレガシーエンコーディングに関して新しいコードページを作るこ > とは，百 > 害あって一利無しだと思っています．あと，情報交換用コードと，シ > ステム内 > 部コードを区別すべきだと思います． そうなのですよね。 ところが、内部コードとして、「楽」にしたつもりが、結局裏切り者 が、外部コードにつかってしまったり。 (SJIS/EUC) 外部コードに恣意的に思想を混入(ISO2022-JP)させたりして、内 部コードにまで影響を与えてきてるのが現状です。 > 今でさえ，レガシーエンコーディングが山のように有ります．それら > を使わざ > るをえないケースというのはあるでしょう．しかし，今更，それらと > 違う新し > いレガシーエンコーディングを作っても，どちらにせよ完全に解決で > きない問 > 題を，さらに複雑化するだけでしょう． 山のようにある様に見えるのだけど、実は、厳密に考えすぎてさらに複 雑化させてる気がする。 もともと、SJISも初代EUCも、X0208のマッピングの 違いだけです。 この場合、X0208の、空きエリアの使い方(いわゆる機種依 存文字問題)を、どう考えるかの問題 しかし、この問題は、空きエリアに対して、積極的な対応(エ ラーにするなど)をしなければ 8bit環境では、透過的に扱えるので問題をアプリケーション側にゆだね ることができます。 その場合は、X0208と、X10646を相互変換する場合だけに 問題が顕在化するはずなわけです。 ところが、主流の実装では、X0208の未定義を積極的にエラーに するので始末が悪い。 わたしは、この問題は、昔からPC9801にあわせりゃいいと思って いました。 PC9801がデファクトスタンダードなのは、否定しようがなかったはず。 ところが、これを、否定したい派閥が、インターネット標準に近い側に いたことが 問題を複雑化させてるわけです。 半角カナ、5c問題、丸付き文字。IBM文字 マイクロソフトが、Windows3.1で、PC9801の非 X0208拡張を、標準に採用した見識は正しいと思っています。 (あえて問題があるとすると、新JISにしてしまった事ぐらい) また、SJISとcp932は違うという派閥もありますが SJISは、その制定当時から、すでに、PC9801拡張は含まれていた と考える方が自然です。 9801以外のシエアは誤差に等しく、新JIS/旧JISは、もと もと区別されていなかった (わたしは誤差のメーカにいました) SJISを、採用していたUNIXマシン、SONYのNEWSは、 ちゃんと98文字がフォントファイルにあった。 なので、javaの、エイリアス問題は、問題にする方がおかしいと 思っていました。 また、初代のEUCは、SJISと同じく、スクリーンエディタ の、処理を楽にする為につくられた様なものです。 EUCはその為に、半角カナをすてた しかし、この初代のEUCは、忠実なISO-2022の初期状態を 規定しただけと考えられるので SJISよりは、はるかに、美しいものでした。 ところが、半角カナを導入し、バイト数＝文字長　ではなくなった時点 で、内部コード(処理コード)と外部コードを区別するべき だったのです。 ここできちんと区別していなかったので、X0212拡張で、 SJIS同様の、ご都合コードになってしまった。 X0212拡張は、ISO2022で拡張すればよかった。 てゆーか、EUCの拡張の詳細について、今回はじめて知りまし た。というか誤解してました。 １５年くらいUNIX系をつかってますが、クライアントマシンは Windowsでしたから まったく気にせずに、euc-jp-msは、cp932のコードポイン トをEUCにしただけとおもってました。 しかし、euc-jp-msを決めた人たちは、なんで、cp932との 互換をとらず、 NEC選定IBM拡張漢字をはずしておいて、msなんてサフィッ クスをつけたのでしょう？ X0212とNEC選定IBM拡張漢字と重なるから、X0212を 優先したというのでしょうが ここでまたもや、混乱を増幅させている。 ユニファイなんかUNICODEにまかせりゃ良かったのに。 ところで euc-jp-msというエンコーディングで書かれた、ファイルは、この世に どのくらいあるのでしょう？ 自分がそうだったからって訳ではないですが限定された環境じゃないの でしょうか？ いや、あったとしても、X0212部分はほとんど使用されていない のではないでしょうか？ NEC選定IBM拡張漢字がX0212部分に変換されてるだけでは ないでしょうか？ と、ぐだぐだ書いてきましたが。 やはり、なにか、別のコードページをつくるしかないだろうという結論 に、森山さんがなったのは 理解しました。 From yw3t-trns ＠ asahi-net.or.jp Tue May 2 12:41:16 2006 From: yw3t-trns ＠ asahi-net.or.jp (Tadamasa Teranishi) Date: Tue, 02 May 2006 12:41:16 +0900 Subject: [LE-talk-ja 103] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TICA=?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= References: <20060425.130455.74746556.taca@back-street.net> <1dba65f30604242142h6c1bebf4kfd24c4dbeea41abe@mail.gmail.com> <20060425211109.D411.MORIYAMA@miraclelinux.com> Message-ID: <4456D4DC.F24EEFC0@asahi-net.or.jp> 寺西です。 Tomoyuki Asakawa wrote: > > ISO-2022-JPを決めるとき、EUCに変換した時に、困らない様にと > いう、ご都合主義できめられてる事がISO-2022の不幸だとおもて > います。 これが ISO-2022-JP(JUNETコード)の目的のひとつだっただろうと思いますが。 > ７ビットに押さえるという目的なら、GLに、よびだせばよかった > のです。 > 当時の実装としてそういうものもあったのですから。 7bitに抑えるだけでは不十分だったからでしょう。 > 純粋なISO-2022原理主義者だった私から言えば,SJISも > EUCも内部コードです。 > 内部コードで外部コードを規定すべきではない。ISO-2022-JPは > EUCの7ビット版になってしまってる。 JUNETコードは、7bitに抑えて、(すくなくとも当時は主流の)UNIX 間の やり取りに使うためのものだったので、EUC-JP の 7bit版とでもいう ような設計は妥当だったと思います。 # まだ、EUC-JP で半角カナも使えませんでしたし。 既に普及しているJUNETコードをほぼそのまま ISO-2022-JP として RFC化したわけですから。(その当時は EUC-JP でも半角カナが使えなくも なかったわけですが) # RFC化する時にJUNETコードを拡張しておくべきだったという考えも # あるでしょうけど。 > 内部コードで外部コードを規定すべきではない。 のかもしれませんが、そこには外部コードは内部コードの制限を受けない マキシマムなものであるべきだという考えがあるのだろうと思います。 しかし、外部コードをミニマムなものにして様々な環境で使えるように したという考えも間違いではないだろうと思います。 ISO-2022-JP はそういう考えです。 どっちが正しいというものではないと思います。 ISO-2022-JP でまずい点はネーミングであって、あたかも ISO-2022 と 互換性があるかのような誤解を与えることですが、サブセットに過ぎません。 -- ===================================================================== 寺西 忠勝(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 Tue May 2 12:41:29 2006 From: yw3t-trns ＠ asahi-net.or.jp (Tadamasa Teranishi) Date: Tue, 02 May 2006 12:41:29 +0900 Subject: [LE-talk-ja 104] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TICA=?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= References: <20060425.130455.74746556.taca@back-street.net> <1dba65f30604242142h6c1bebf4kfd24c4dbeea41abe@mail.gmail.com> <20060425211109.D411.MORIYAMA@miraclelinux.com> <7A3862C7-06B9-4E97-A891-1198A4EA3B08@asakawa.ne.jp> Message-ID: <4456D4E9.97D7620D@asahi-net.or.jp> 寺西です。 Tomoyuki Asakawa wrote: > > もともと、SJISも初代EUCも、X0208のマッピングの > 違いだけです。 > この場合、X0208の、空きエリアの使い方(いわゆる機種依 > 存文字問題)を、どう考えるかの問題 > しかし、この問題は、空きエリアに対して、積極的な対応(エ > ラーにするなど)をしなければ > 8bit環境では、透過的に扱えるので問題をアプリケーション側にゆだね > ることができます。 空きエリアの字形が違うわけですから、何らかの対策をアプリケーションが 行わなければなりません。 問題をアプリケーション側にゆだねられた結果、 > ところが、主流の実装では、X0208の未定義を積極的にエラーに > するので始末が悪い。 アプリケーションがエラーとして処理しているに過ぎません。 別に始末が悪いことではないでしょう。 何もしないと文字化けする環境も多々ありましたから。 > わたしは、この問題は、昔からPC9801にあわせりゃいいと思って > いました。 それは > １５年くらいUNIX系をつかってますが、クライアントマシンは > Windowsでしたから といった環境だったからそう思うのでしょう。 > PC9801がデファクトスタンダードなのは、否定しようがなかったはず。 はい。 しかし、一方で少数派ではあっても、無視できない Mac の存在も (少なくとも当時は)ありましたし、UNIX の各ベンダーはベンダー固有の 機種依存文字を持っていましたし、PC-9801に合わせるというのは 無理だったわけです。各社の思惑もありますから。 # 今なら事情は違うと思いますが...。 > SJISを、採用していたUNIXマシン、SONYのNEWSは、 > ちゃんと98文字がフォントファイルにあった。 > なので、javaの、エイリアス問題は、問題にする方がおかしいと > 思っていました。 既に忘れてしまっていますが、これを見ると HP は違っていたかもしれま せん。(HP はデフォルトが EUC-JP ではなく、Shift_JIS でした。) http://www.opengroup.or.jp/jvc/cde/sjis.html また、NEWS はそれなりに売れた(私も使っていたけど)と思いますが、当時は Sun が主流でしたので、NEWS がこうだったからというのは、あまり重要では ないと思います。 > また、初代のEUCは、SJISと同じく、スクリーンエディタ > の、処理を楽にする為につくられた様なものです。 ... > ところが、半角カナを導入し、バイト数＝文字長　ではなくなった時点 > で、内部コード(処理コード)と外部コードを区別するべき > だったのです。 後学のためにお聞きしたいのですが、では、内部コードはどのようなもの で、外部コードはどのようなもので、どう区別するべきだったのでしょう。 > ここできちんと区別していなかったので、X0212拡張で、 > SJIS同様の、ご都合コードになってしまった。 > X0212拡張は、ISO2022で拡張すればよかった。 これはどういう意味でしょう。 > しかし、euc-jp-msを決めた人たちは、なんで、cp932との > 互換をとらず、 > NEC選定IBM拡張漢字をはずしておいて、msなんてサフィッ > クスをつけたのでしょう？ NEC選定IBM拡張文字よりIBM拡張文字が優先的に使われる Microsoft Windows 3.51 式の変換だからでしょう。 http://www.opengroup.or.jp/jvc/cde/appendix.html NEC選定IBM拡張漢字をはずすのは、「マイクロソフトのマニュアルでも、 NEC選定IBM拡張文字は使わないように指導している」らしいですから。 その他、詳細は下記を参考に。 http://www.opengroup.or.jp/jvc/cde/sjis-euc.html#cp6 > X0212とNEC選定IBM拡張漢字と重なるから、X0212を > 優先したというのでしょうが > ここでまたもや、混乱を増幅させている。 様々な背景はここに書かれています。 http://www.opengroup.or.jp/jvc/cde/ucs-conv.html#ch4_1 これは私も混乱を増幅させていると思います。 eucJP-ms, eucJP-0201, eucJP-ascii と3通りのコード変換を規定して、 用途によって使い分けるということになってますから。 > euc-jp-msというエンコーディングで書かれた、ファイルは、この世に > どのくらいあるのでしょう？ ファイルとして存在するかどうかは重要でしょうか? euc-jp-ms は、eucJP-open のコード変換規則のひとつに過ぎません。 変換に使われているかどうかが重要なのではないでしょうか? -- ===================================================================== 寺西 忠勝(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 Tue May 2 13:00:27 2006 From: yw3t-trns ＠ asahi-net.or.jp (Tadamasa Teranishi) Date: Tue, 02 May 2006 13:00:27 +0900 Subject: [LE-talk-ja 105] =?iso-2022-jp?b?UmU6IBskQiQzJE4bKEJNTBskQiRHGyhC?= =?iso-2022-jp?b?GyRCJE41RE9APCtCTiRLJEQkJCRGGyhC?= References: <20060415212608.CE29.MOTOYUKI@bc4.so-net.ne.jp> <20060416.124721.884020845.hyoshiok@miraclelinux.com> Message-ID: <4456D95B.D5F37A1F@asahi-net.or.jp> 寺西です。 Hiro Yoshioka wrote: > > 社内でおこなっている議論、情報に関しましても、可能な > かぎりWikiで公開しております。 > http://legacy-encoding.sourceforge.jp/wiki/ > > われわれはISO-2022-JP-MSが必要でかつ有用であると信じておりますが > いくつかの応用においては、ご指摘のとおり他の方式が有用である場合も > あると思います。 ISO-2022-JP-MSが必要でかつ有用であると信じておられる部分の説明は Wikiのどこに書かれているのでしょうか? -- ===================================================================== 寺西 忠勝(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 Tue May 2 18:42:36 2006 From: moriyama ＠ miraclelinux.com (MORIYAMA Masayuki) Date: Tue, 2 May 2006 18:42:36 +0900 (JST) Subject: [LE-talk-ja 106] =?iso-2022-jp?b?UmU6IBskQjI/JCxANSQ3JCQkKyRoGyhC?= =?iso-2022-jp?b?GyRCJGoyPyQsSSxNVyQrJDgkYyRKJCQkRyQ3JGckJiQrISkbKEI=?= In-Reply-To: <570034E6-E29F-4A4D-B667-14A0C6D1A815@mac.com> References: <20060428141235.BC57.MORIYAMA@miraclelinux.com> <570034E6-E29F-4A4D-B667-14A0C6D1A815@mac.com> Message-ID: <20060502140825.E9A1.MORIYAMA@miraclelinux.com> 森山です。 Kazuhiro Kazama wrote: > > On 2006/04/28, at 15:10, MORIYAMA Masayuki wrote: > > 何が正しいかより何が必要かという事を考える場合、そもそも標準規格では、 > > どうなっているのかという事をベースに考える必要があると思います。 > > > > 標準規格さえ守っていれば問題ないという状況が作り出されているのであれば > > 良いのですが、現実にはそうなっていませんから、いろいろと問題が発生して > > しまっているのだと理解しています。 > > 標準規格ではどうなっているのかという事をベースに新たに考えるのではな > く，基本的にはどの標準規格およびデファクト標準を採用するのか，そしてそ > れらで明確に規定されていない部分をどうするのかということを考えるべきで > はないでしょうか． > > たとえば，次のような方針がよいと思っています． > > ・既存のレガシーエンコーディングを対象とする．新しいレガシーエンコー > ディングは作らない． > ・現在，広く使われているレガシーエンコーディングにおける問題を明確に分 > 析する． > ・広く発生する問題に対しては，その解決法を明示し，さらに(一部を)実装す > る． レガシーエンコーディングに関してよく目にする問題点は次のとおりです。 (1) Unicode とのマッピングの問題 ('〜' などのマッピング) - JIS X 0208 で定義されている文字だけを使うようにしていても一部の 記号に関して変換できない問題が発生する。 - cp932 → Unicode → ISO-2022-JP という変換で '〜' が変換できない。 (2) 文字レパートリの問題 (いわゆる機種依存文字の問題) - 用途を問わず、丸付き数字などの Windows の機種依存文字がレガシー エンコーディングでやりとりされているが、特定の符号化方式でしかサ ポートされていない。 - 7ビットJIS(ISO-2022-JP)符号化方式で、サポートされていない、もし くはサポートされていても、Windows とは異なる実装が行われているケー スがあった。(Sylpheed に関しては修正済み) (3) 複数存在する Windows 機種依存文字対応の拡張 (CP51932, eucJP-open) - Internet Explorer, Mozilla Firefox などの Web ブラウザで、EUC-JP のページから POST されるのは CP51932 だが、現在の多くのオープン ソースソフトウェアでは、eucJP-open と呼ばれるもので、CP51932 の NEC選定IBM拡張文字を正しく取り扱えない。 Windows が絡む問題が多いのは、Windows の利用が多い事が反映されているの だと思います。 レガシーエンコーディングの各符号化方式に対して、下の表のように、 Unicode とのマッピングが MS 系のものを揃える事で、上の問題の多くが解決 できると考えています。 +------------+---------------------------------+ | | Unicode とのマッピング | | +-------------------+-------------+ | 符号化方式 | MS系 | JIS系 | +------------+-------------------+-------------+ | シフトJIS | cp932 | Shift_JIS | | 日本語EUC | cp51932 | EUC-JP | | | eucJP-ms | | | 7ビットJIS | cp5022x | ISO-2022-JP | | | or ISO-2022-JP-MS | | +------------+-------------------+-------------+ これだけでレガシーエンコーディングの問題が 100% 解決は出来ないでしょう けれども、多くの場合の問題解決に役に立つと考えています。 -- 森山 将之 moriyama ＠ miraclelinux.com ミラクル・リナックス株式会社 From moriyama ＠ miraclelinux.com Tue May 2 18:42:44 2006 From: moriyama ＠ miraclelinux.com (MORIYAMA Masayuki) Date: Tue, 2 May 2006 18:42:44 +0900 (JST) Subject: [LE-talk-ja 107] =?iso-2022-jp?b?UmU6IBskQiQzJE4bKEJNTBskQiRHGyhC?= =?iso-2022-jp?b?GyRCJE41RE9APCtCTiRLJEQkJCRGGyhC?= In-Reply-To: <4456D95B.D5F37A1F@asahi-net.or.jp> References: <20060416.124721.884020845.hyoshiok@miraclelinux.com> <4456D95B.D5F37A1F@asahi-net.or.jp> Message-ID: <20060502152043.E9AA.MORIYAMA@miraclelinux.com> 森山です。 On Tue, 02 May 2006 13:00:27 +0900 Tadamasa Teranishi wrote: > ISO-2022-JP-MSが必要でかつ有用であると信じておられる部分の説明は > Wikiのどこに書かれているのでしょうか? Wiki に ISO-2022-JP-MS に関して直接書いてありませんが、次の問題に関し て何らかの対応が必要と考えていて、ISO-2022-JP-MS や CP50221 のようなも のが必要でかつ有用であると考えています。 ・cp932→Unicode→ISO-2022-JP といった変換で、'〜' などの JISの記号が 変換できない。 ・ISO-2022-JP→Unicode といった変換で、Winodwsの機種依存文字が変換でき ない。 これらの問題の解決のために、ユーザ定義文字の扱いは直接には関係ありませ んから、ISO-2022-JP-MS からユーザ定義文字を取り除いたものを実装するの が現実的なのではないかと考えていました。 しかし、CP50221 の方が良いという意見があり、その場合、ユーザ定義文字を どうすべきなのか検討する必要があると考えています。 ‖森山 将之 (MORIYAMA Masayuki) ‖e-mail: msyk ＠ mtg.biglobe.ne.jp From moriyama ＠ miraclelinux.com Tue May 2 19:59:17 2006 From: moriyama ＠ miraclelinux.com (MORIYAMA Masayuki) Date: Tue, 2 May 2006 19:59:17 +0900 (JST) Subject: [LE-talk-ja 108] =?iso-2022-jp?b?GyRCJSolVSVpJSQlcyVfITwlRiUjGyhC?= =?iso-2022-jp?b?GyRCJXMlMBsoQigyMDA2LzA1LzE3KQ==?= Message-ID: <20060502191137.E9C4.MORIYAMA@miraclelinux.com> ミラクルリナックスの森山です。 「オープンソースソフトウェアにおける統一したレガシーエンコーディングの 変換機能の開発」のオフラインミーティングを次の通り開催いたします。 OSC2006 や YAPC::2006 で話した内容の繰り返しになるかと思いますが、もう 少し具体的な事も説明し、意見交換を行いたいと考えています。 日時：2006年5月17日(水) 19時開始 場所：ミラクル・リナックス株式会社(セミナールーム) http://www.miraclelinux.com/corp/map.html 終了後、懇親会を予定しています。 懇親会は、1,000円 ほど予定。 参加希望の方は、懇親会に参加希望かどうかを添えて、次の Wiki に参加表明 をお願いいたします。 会場の定員は 30名ほどとなっていますので、一応先着30名とさせていただき ます。 http://legacy-encoding.sourceforge.jp/wiki/index.php?%A5%AA%A5%D5%A5%E9%A5%A4%A5%F3%A5%DF%A1%BC%A5%C6%A5%A3%A5%F3%A5%B0%282006%2F05%2F17%29 -- 森山 将之 moriyama ＠ miraclelinux.com ミラクル・リナックス株式会社 From tom ＠ asakawa.ne.jp Tue May 2 20:50:00 2006 From: tom ＠ asakawa.ne.jp (Tomoyuki Asakawa) Date: Tue, 2 May 2006 20:50:00 +0900 Subject: [LE-talk-ja 109] =?iso-2022-jp?b?UmU6IBskQjI/JCxANSQ3JCQkKyRoGyhC?= =?iso-2022-jp?b?GyRCJGoyPyQsSSxNVyQrJDgkYyRKJCQkRyQ3JGckJiQrISkbKEI=?= In-Reply-To: <20060502140825.E9A1.MORIYAMA@miraclelinux.com> References: <20060428141235.BC57.MORIYAMA@miraclelinux.com> <570034E6-E29F-4A4D-B667-14A0C6D1A815@mac.com> <20060502140825.E9A1.MORIYAMA@miraclelinux.com> Message-ID: <7967505D-C557-48C8-BDFB-D21C93EC9B94@asakawa.ne.jp> あさかわ＠MAC使い > Windows が絡む問題が多いのは、Windows の利用が多い事が反 > 映されているの > だと思います。 そうです、MACを無視しても、Windowsを無視してはイケナ イと思います。 Windowsはデファクトです。 > > レガシーエンコーディングの各符号化方式に対して、下の表のように、 > Unicode とのマッピングが MS 系のものを揃える事で、上の問 > 題の多くが解決 > できると考えています。 わたしは、JIS系の新コードページを作成するよりも、EUC 系のcp51932拡張の方が良い様に今は思えています。 euc-jp-msは、msとの互換とったつもりで、じつはそうではない 所に問題があると思います。 euc-jp-msの欠陥は、cp51932との互換が無いことです。 euc-jp-msを作成したときに、cp51932が無かったと言われるかも しれませんが。 PC9801の漢字ROMを、単純にEUCにマップしたものを、 cp51932として登録したにすぎません。 広く使われてるEUCは、cp51932であると考えます。 また、JIS系は、そもそも、ISO-2022のフルセットで済ん でしまいます。(非X0208のマッピングは、私用でカバー) From tom ＠ asakawa.ne.jp Tue May 2 20:57:49 2006 From: tom ＠ asakawa.ne.jp (Tomoyuki Asakawa) Date: Tue, 2 May 2006 20:57:49 +0900 Subject: [LE-talk-ja 110] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TICA=?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <4456D4E9.97D7620D@asahi-net.or.jp> References: <20060425.130455.74746556.taca@back-street.net> <1dba65f30604242142h6c1bebf4kfd24c4dbeea41abe@mail.gmail.com> <20060425211109.D411.MORIYAMA@miraclelinux.com> <7A3862C7-06B9-4E97-A891-1198A4EA3B08@asakawa.ne.jp> <4456D4E9.97D7620D@asahi-net.or.jp> Message-ID: <439A0530-4D7A-485A-BCEE-0BBCAAF4C723@asakawa.ne.jp> あさかわ > 空きエリアの字形が違うわけですから、何らかの対策をアプリケー > ションが > 行わなければなりません。 > 問題をアプリケーション側にゆだねられた結果、 空きエリアの利用は多岐にわたります。それを、システム側で想定する ことはできません また、使用しない様に制限すべきではありません。 > >> ところが、主流の実装では、X0208の未定義を積極的にエラーに >> するので始末が悪い。 > > アプリケーションがエラーとして処理しているに過ぎません。 > 別に始末が悪いことではないでしょう。 いいえ、システムのコンバータレベル(iconvなど)で捨て られてる問題の方です、 この場合アプリケーションでは対処できません。 > 何もしないと文字化けする環境も多々ありましたから。 もじばけは、化けるだけです。化ける側で、自分の表示できないものに 対する対応をすべきです。 つまり、受信側で対処すべきで、送信側で対処するべきでないと思う。 実際、Windowsや、MACのものは、送信側ではなにもしない のが多いわけです。 そのおかげで、Windowsから送られた、丸一が、 (月)に化けても、それをWidnowsへ転送すれば 再現できる。ところが、送信時にすてられると、２度と再現できません。 (MAC OS Xが、UNIX系になりiconvの影響をモロに受けてる のが困りもの) From tom ＠ asakawa.ne.jp Tue May 2 21:00:40 2006 From: tom ＠ asakawa.ne.jp (Tomoyuki Asakawa) Date: Tue, 2 May 2006 21:00:40 +0900 Subject: [LE-talk-ja 111] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TICA=?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <4456D4E9.97D7620D@asahi-net.or.jp> References: <20060425.130455.74746556.taca@back-street.net> <1dba65f30604242142h6c1bebf4kfd24c4dbeea41abe@mail.gmail.com> <20060425211109.D411.MORIYAMA@miraclelinux.com> <7A3862C7-06B9-4E97-A891-1198A4EA3B08@asakawa.ne.jp> <4456D4E9.97D7620D@asahi-net.or.jp> Message-ID: あさかわ > しかし、一方で少数派ではあっても、無視できない Mac の存 > 在も > (少なくとも当時は)ありましたし、UNIX の各ベンダー > はベンダー固有の > 機種依存文字を持っていましたし、PC-9801に合わせるという > のは > 無理だったわけです。各社の思惑もありますから。 マイナー機種に、メジャー機種をあわせるのは、悪平等です。 ましてや使わないという方へ統一しようとしても、つかうに決まってる ので無駄ですし、無駄でしたね。 ちなみに、MACは、9801にあわせたフォントがあります。 From kazama ＠ mac.com Wed May 3 21:47:36 2006 From: kazama ＠ mac.com (Kazuhiro Kazama) Date: Wed, 3 May 2006 21:47:36 +0900 Subject: [LE-talk-ja 112] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TICA=?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <439A0530-4D7A-485A-BCEE-0BBCAAF4C723@asakawa.ne.jp> References: <20060425.130455.74746556.taca@back-street.net> <1dba65f30604242142h6c1bebf4kfd24c4dbeea41abe@mail.gmail.com> <20060425211109.D411.MORIYAMA@miraclelinux.com> <7A3862C7-06B9-4E97-A891-1198A4EA3B08@asakawa.ne.jp> <4456D4E9.97D7620D@asahi-net.or.jp> <439A0530-4D7A-485A-BCEE-0BBCAAF4C723@asakawa.ne.jp> Message-ID: On 2006/05/02, at 20:57, Tomoyuki Asakawa wrote: > 実際、Windowsや、MACのものは、送信側ではなにもしない > のが多いわけです。 > そのおかげで、Windowsから送られた、丸一が、 > (月)に化けても、それをWidnowsへ転送すれば > 再現できる。ところが、送信時にすてられると、２度と再現できませ > ん。 > (MAC OS Xが、UNIX系になりiconvの影響をモロに受けてる > のが困りもの) 困ったことに，最近はUnicodeをベースとしたピボット変換を実 装したOSやアプリケーションが増えていて，その再現できない問 題（最初に想定されていない文字は，一旦UnicodeのREPLACEMENT CHARACTERに変換された後に，代替文字(?とか)に変換され て二度と戻せない）が発生して，それゆえにこの提案がされているのだ と理解しています． ＃　たぶん，Windowsは気がつかないだけで，アーキテクチャ的 に必ずしも例外ではないと思います． > 空きエリアの利用は多岐にわたります。それを、システム側で想定する > ことはできません > また、使用しない様に制限すべきではありません。 結局，これはすでに不可能になっていますし，それが大きな問題を引き 起こしてしまっています． --- Kazuhiro Kazama kazama ＠ mac.com From naruse ＠ airemix.com Wed May 3 21:52:21 2006 From: naruse ＠ airemix.com (NARUSE, Yui) Date: Wed, 03 May 2006 21:52:21 +0900 Subject: [LE-talk-ja 113] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TIA==?= =?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: <4458A785.9060602@airemix.com> 成瀬です。 だいぶ遅れましたが、 Tadamasa Teranishi wrote: > そもそも機種依存文字を含めて EUC-JP として保存できるエディタに > 問題があるかと思いますし、それがスタンダードだとは思わないですけど。 > > 具体的にはどのエディタでしょう。 CP932で定義されている文字（ユーザ定義文字は除く）を、 4つのエディタで「EUC」として保存してみました。 試した結果、 * 秀丸エディタ * サクラエディタ * Peggy で、保存された結果が、CP51932での変換結果と一致していました。 つまり、これらのエディタのユーザは >> 自分の思っていた「EUC-JP」が実は CP51932 だった、 >> という人はかなり多いのではないでしょうか。 にあたる人だというわけです。 そしてTeraPadではIBM拡張文字が保存できませんでした。 （つまり、CP51932とeucJP-msの公約数） >> # Windows で 3バイト EUC を扱えるエディタってあまりないですし。 > > 3バイト EUC が扱えるエディタの有無と CP51932 とは直接関係ないでしょう。 > # かすってますが...。 3バイトEUCが使える場合、未定義領域の変換を蹴っている場合が多い と思われるので、その場合はCP51932による拡張部分が変換されなくなります。 逆に言えば、何も考えずにSJIS<->EUC変換を実装すれば、 CP932による拡張部分はCP51932風に変換される、と。 -- NARUSE, Yui DBDB A476 FDBD 9450 02CD 0EFC BCE3 C388 472E C1EA From kazama ＠ mac.com Wed May 3 22:37:16 2006 From: kazama ＠ mac.com (Kazuhiro Kazama) Date: Wed, 3 May 2006 22:37:16 +0900 Subject: [LE-talk-ja 114] =?iso-2022-jp?b?UmU6IBskQjI/JCxANSQ3JCQkKyRoGyhC?= =?iso-2022-jp?b?GyRCJGoyPyQsSSxNVyQrJDgkYyRKJCQkRyQ3JGckJiQrISkbKEI=?= In-Reply-To: <20060502140825.E9A1.MORIYAMA@miraclelinux.com> References: <20060428141235.BC57.MORIYAMA@miraclelinux.com> <570034E6-E29F-4A4D-B667-14A0C6D1A815@mac.com> <20060502140825.E9A1.MORIYAMA@miraclelinux.com> Message-ID: <2F12C631-2F85-4219-A09D-90E1C219A1D4@mac.com> On 2006/05/02, at 18:42, MORIYAMA Masayuki wrote: > これだけでレガシーエンコーディングの問題が 100% 解決は出 > 来ないでしょう > けれども、多くの場合の問題解決に役に立つと考えています。 発言の意図がちょっと把握できていないかもしれません…． 現在は，以下の標準規格とデファクト標準が使われていると思っていま す． > +------------+---------------------------------+ > | | Unicode とのマッピング | > | +-------------------+-------------+ > | 符号化方式 | MS系 | JIS系 | > +------------+-------------------+-------------+ > | シフトJIS | cp932 | Shift_JIS | > | 日本語EUC | cp51932 | EUC-JP | > | | eucJP-ms | | > | 7ビットJIS | cp5022x | ISO-2022-JP | > +------------+-------------------+-------------+ ISO-2022-JP-MSは，実装例が少なく，仕様も確定していないので，標準 規格やデファクト標準には含まれないということです． --- Kazuhiro Kazama kazama ＠ mac.com From kazama ＠ mac.com Thu May 4 02:05:00 2006 From: kazama ＠ mac.com (Kazuhiro Kazama) Date: Thu, 4 May 2006 02:05:00 +0900 Subject: [LE-talk-ja 115] =?iso-2022-jp?b?UmU6IElTTy0yMDIyLUpQLU1TICA=?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <20060425153745.D406.MORIYAMA@miraclelinux.com> References: <20060418191133.BDB9.MORIYAMA@miraclelinux.com> <20060425153745.D406.MORIYAMA@miraclelinux.com> Message-ID: On 2006/04/25, at 21:13, MORIYAMA Masayuki wrote: > 次の点が一番の要点となるかと思いますので、よろしくお願いいたし > ます。 > > ・Windows の Codepage 50220, 50221, 50222 による変 > 換で、Unicode の > U+E000〜U+E757 にマッピングされているものは、 > Windows での仕様と考え > てよいか? 問い合わせ中ですが，ちょうどGW連休に入った土曜日にメールし たのと，私の会社が停電なので，結果はまだわかりません． > glibc, libiconv のパッチでは 3. の方法を取っています。 この方法を許してもらえるとしたら（私は，以前のメールでこの方法が 却下されたと勘違いしていたようです），比較的無難だし，メール送受 信にISO-2022-JPを使っても大きな問題はなくなると言えるので はないでしょうか．ただ，この穂法は好まない人もいるようなので，要 検討ですが． > CP5022X を導入した場合、UTF-8 からの変換で、U+301C WAVE > DASH が変換で > きないとしても、CP932, CP51932, eucJP-ms と > CP5022X との変換が可能だと > いう事と、Windows の API で UTF-8 (Unicode) > に変換されたものは、扱える > ようになるので、それなりのメリットはあると考えています。 歴史的経緯としては，ISO-2022-JPと（いわゆる）JISコー ドは区別されていました．CP5022Xは後者の方の立場と考えられ ますので，また別の意味があります．ただ，実際にそれが必要なケース というのがどれくらいあるかですが．少ないとしたら，必須にする必要 はないと思います． > CP5022X や CP51932 をアルゴリズム的な変換で CP932 > へ文字コード変換した > 場合に、CP5022X や CP51932 の NEC選定 > IBM拡張文字(89区〜92区)をそのまま、 > NEC選定IBM拡張文字の符号位置に変換するという実装が多いか > と思います。 > > 表示を行うだけであれば、それだも良いのですが、CSI(Code Set > Independent) > な実装を行っているソフトウェアでは、NEC選定IBM拡張 > 文字とIBM拡張文字 > (115区〜119区)は、表示上同じ文字であっても符号位置 > が異なるという事で別 > 字として扱われてしまうので注意が必要になってきます。 それは実装の問題で，そのような問題が起こりえることは指摘していい と思いますが，本来は照合などの上位レベルで扱うべきものなので，今 回の範囲外でしょう． それで，そろそろ，ある程度，課題や技術的選択肢がある問題を整理し て，可能なものはまとめて結論を出していった方がよいのではないかと 思います． --- Kazuhiro Kazama kazama ＠ mac.com From kazama ＠ mac.com Mon May 8 15:43:06 2006 From: kazama ＠ mac.com (Kazuhiro Kazama) Date: Mon, 8 May 2006 15:43:06 +0900 Subject: [LE-talk-ja 116] =?iso-2022-jp?b?GyRCMnNFeiRLJEQkJCRGGyhC?= References: Message-ID: Microsoftの（JISの文字コード関係者でもあります）阿南さんから，問い合わ せに対する回答を頂いたので転送します． Begin forwarded message: > From: "Yasuhiro Anan" > Date: 2006年5月6日 17:41:50:JST > To: "Kazuhiro Kazama" > Subject: RE: CP5022X > > 風間さん、ご無沙汰しています。 > > 連休がはさまってお返事が遅くなってしまいました。 > >> 最近，以下のようなLinux上における文字符号化に関する問題を解決するため >> のアクティビティに関与しています． >> >> http://sourceforge.jp/projects/legacy-encoding/ >> >> ＃ 私は，推進側というより，悪い方向に行かないようにアドバイスするとい >> う立場です． >> > よろしくお願いします。legacy encodingはもはやいじったり増やしたり > しての解決はできないというのが私の理解です。 > >> そこで，現在Windowsのコードページ50220，50221，50222について話し >> 合って >> いるのですが，資料が見つからなくて困っています．もし，資料があれ >> ば，教 >> えて頂けないでしょうか？ >> > 残念ながらこれらについてはご案内できる資料はないようです、すみません。 > >> また，以下のことを教えて頂ければ嬉しいです． >> >> ・コードページ50220, 50221, 50222で、ユーザ外字をUnicodeの私用領域（U >> +E000〜U+E757）にマッピングしているのは仕様と考えてよいか? >> > はい。仕様です。 > >> ・コードページ50220, 50221, 50222では，入力はどれでも処理できるのか? >> > この3つのコードページをMB/WC APIの引数として渡せるかという > 意味ならどれもOKのはずです。 > >> ・マイクロソフトまたは阿南さん個人またはJISのナショナルボディとして >> は，これらのコードページをLinuxでどのように扱うべきだと思っているか? >> (たとえば，どのコードページの使用を推奨するのか? 将来的に電子メールな >> どでJIS X 0213の文字はどのように扱うつもりか?など) >> > MSとしてはコードページの変更や拡張はもう行う予定はありません。 > 98年に補助漢字をUnicode拡張し、Windows VistaでもJIS2004の > 第3，4水準の拡張もUnicodeで実装することになりますが、今後の > 文字の追加はすべてUnicodeベースになります。従って電子メール等 > でJIS X 0208の範囲をこえて補助漢字や第3，4水準漢字を扱うため > には基本的にはUTF-8を使っていただくのが一番よいと思っています。 > なお、この点に関してJISとしての見方も、2004年に公示された > 新人名用漢字とJISの対応に関する報告書 > （http://www.jisc.go.jp/newstopics/2004/jinmeicode.pdf） > に見えるとおり、同じ方向を向いていると理解しています。 > >> P.S. >> 個人的にはWindows VistaのJIS X 0213サポートがWindows XPにバックポート >> されるかも知りたいところです（笑） >> > Windows Vistaでもコードページは変更無し、追加無しです。 > JIS2004対応MSフォント及び結合文字のレンダリング等に必要なモジュール > のアップデートはXPでも提供予定です。 > > よろしくお願いします。 > MSD/Windows開発統括部 > 阿南康宏 なお，最後の蛇足の話については，新日本語フォント「メイリオ」としてすで に報道発表されていたようです． http://internet.watch.impress.co.jp/cda/news/2005/07/29/8621.html --- 風間 一洋 (kazama ＠ mac.com) From moriyama ＠ miraclelinux.com Mon May 8 18:27:59 2006 From: moriyama ＠ miraclelinux.com (MORIYAMA Masayuki) Date: Mon, 8 May 2006 18:27:59 +0900 (JST) Subject: [LE-talk-ja 117] =?iso-2022-jp?b?UmU6IBskQjJzRXokSyREJCQkRhsoQg==?= In-Reply-To: References: Message-ID: <20060508174854.B2D5.MORIYAMA@miraclelinux.com> 森山です。 風間さん、マイクロソフトへの問い合わせありがとうございます。 CP5022X については、ユーザー定義文字の変換に関しては仕様との事であれば、 CP5022X を実装する場合は、同様の変換にする必要がありますね。 まとめについては、もうしばらくお待ちください。 Windows Vista での JIS X 0213:2004 対応に関しては、フォントへの文字の 追加と表外漢字字体表に対応するための字体変更の話だと理解していましたの で、コードページが追加になる事はないだろうと考えていのですが、ハッキリ して良かったです。 Kazuhiro Kazama wrote: > Microsoftの（JISの文字コード関係者でもあります）阿南さんから，問い合わ > せに対する回答を頂いたので転送します． > > Begin forwarded message: > > From: "Yasuhiro Anan" > > Date: 2006年5月6日 17:41:50:JST > > To: "Kazuhiro Kazama" > > Subject: RE: CP5022X > > > > 風間さん、ご無沙汰しています。 > > > > 連休がはさまってお返事が遅くなってしまいました。 > > > >> 最近，以下のようなLinux上における文字符号化に関する問題を解決するため > >> のアクティビティに関与しています． > >> > >> http://sourceforge.jp/projects/legacy-encoding/ > >> > >> ＃ 私は，推進側というより，悪い方向に行かないようにアドバイスするとい > >> う立場です． > >> > > よろしくお願いします。legacy encodingはもはやいじったり増やしたり > > しての解決はできないというのが私の理解です。 > > > >> そこで，現在Windowsのコードページ50220，50221，50222について話し > >> 合って > >> いるのですが，資料が見つからなくて困っています．もし，資料があれ > >> ば，教 > >> えて頂けないでしょうか？ > >> > > 残念ながらこれらについてはご案内できる資料はないようです、すみません。 > > > >> また，以下のことを教えて頂ければ嬉しいです． > >> > >> ・コードページ50220, 50221, 50222で、ユーザ外字をUnicodeの私用領域（U > >> +E000〜U+E757）にマッピングしているのは仕様と考えてよいか? > >> > > はい。仕様です。 > > > >> ・コードページ50220, 50221, 50222では，入力はどれでも処理できるのか? > >> > > この3つのコードページをMB/WC APIの引数として渡せるかという > > 意味ならどれもOKのはずです。 > > > >> ・マイクロソフトまたは阿南さん個人またはJISのナショナルボディとして > >> は，これらのコードページをLinuxでどのように扱うべきだと思っているか? > >> (たとえば，どのコードページの使用を推奨するのか? 将来的に電子メールな > >> どでJIS X 0213の文字はどのように扱うつもりか?など) > >> > > MSとしてはコードページの変更や拡張はもう行う予定はありません。 > > 98年に補助漢字をUnicode拡張し、Windows VistaでもJIS2004の > > 第3，4水準の拡張もUnicodeで実装することになりますが、今後の > > 文字の追加はすべてUnicodeベースになります。従って電子メール等 > > でJIS X 0208の範囲をこえて補助漢字や第3，4水準漢字を扱うため > > には基本的にはUTF-8を使っていただくのが一番よいと思っています。 > > なお、この点に関してJISとしての見方も、2004年に公示された > > 新人名用漢字とJISの対応に関する報告書 > > （http://www.jisc.go.jp/newstopics/2004/jinmeicode.pdf） > > に見えるとおり、同じ方向を向いていると理解しています。 > > > >> P.S. > >> 個人的にはWindows VistaのJIS X 0213サポートがWindows XPにバックポート > >> されるかも知りたいところです（笑） > >> > > Windows Vistaでもコードページは変更無し、追加無しです。 > > JIS2004対応MSフォント及び結合文字のレンダリング等に必要なモジュール > > のアップデートはXPでも提供予定です。 > > > > よろしくお願いします。 > > MSD/Windows開発統括部 > > 阿南康宏 > > なお，最後の蛇足の話については，新日本語フォント「メイリオ」としてすで > に報道発表されていたようです． > > http://internet.watch.impress.co.jp/cda/news/2005/07/29/8621.html > --- > 風間 一洋 (kazama ＠ mac.com) > > > _______________________________________________ > Legacy-Encoding-talk-ja mailing list > Legacy-Encoding-talk-ja ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/legacy-encoding-talk-ja -- 森山 将之 moriyama ＠ miraclelinux.com ミラクル・リナックス株式会社 From moriyama ＠ miraclelinux.com Tue May 16 18:50:52 2006 From: moriyama ＠ miraclelinux.com (MORIYAMA Masayuki) Date: Tue, 16 May 2006 18:50:52 +0900 (JST) Subject: [LE-talk-ja 118] =?iso-2022-jp?b?TEUtdGFsay1qYSAbJEIkRyRONUQbKEI=?= =?iso-2022-jp?b?GyRCT0AkTiReJEgkYRsoQg==?= Message-ID: <20060516184928.894D.MORIYAMA@miraclelinux.com> 森山です。 遅くなって申し訳ありません。 これまでの、LE-talk-ja メーリングリストでの議論のまとめです。 改めてアナウンスします。 明日、5/17(水) を、オフラインミーティング(BOF) を開きます。会場の方は まだまだ余裕がありますので、ぜひご参加ください。 http://legacy-encoding.sourceforge.jp/wiki/index.php?%A5%AA%A5%D5%A5%E9%A5%A4%A5%F3%A5%DF%A1%BC%A5%C6%A5%A3%A5%F3%A5%B0%282006%2F05%2F17%29 よろしくお願いいたします。 ------------------------------------------------------------------------ LE-talk-ja での議論のまとめ 作成日 2006/05/15 レガシー・エンコーディング・プロジェクト 森山 将之 ■本プロジェクトとしての方針 ・標準を作るわけではない。 ・必要とされているものを実装する。 ■スコープ ・Windows Codepage 932 で使用可能な文字を Unicode 経由で、日本語EUC 符号化方式、7ビットJIS(ISO-2022-JP)符号化方式に変換できるようにする。 ■全般 ◎ JIS X 0208 で定義されていない文字を扱う場合は UTF-8 を使うべき ・既存のシステムすべてが短期間で UTF-8 に移行するわけではない - レガシーエンコーディング + UTF-8 (Unicode) という混在環境への移 行と考えている。 - 過去の資産はレガシーエンコーディングで蓄積されている。 - 短期間のうちにレガシーエンコーディングが無くなり UTF-8 に取って 代わられるわけではない。 ・シフトJIS や日本語EUC から UTF-8 への移行コストが高い場合がある。 - シフトJIS や日本語EUC に依存して開発されている - UTF-8 でのバイト数増加の問題 - UTF-8 環境が整っていない ・レガシーエンコーディングからUTF-8への移行期間がありプロジェクト の成果物はこの期間で使われること想定している。 ◎ IANAレジストリに登録しますか? ・可能であれば。 ・登録する場合は、RFC への提案を先に行う。 ◎ JIS X 0213 対応は? ・JIS X 0213 対応は Unicode への移行が必要と考えているので、レガシー エンコーディングでの対応は考えていない。 ・Windows Vista での JIS X 0213:2004 対応は Unicode のみの対応で、 コードページの追加は行わないことになっている。 ◎ 携帯絵文字 ・今回の開発ではスコープ外 ◎ Macintosh ・今回の開発ではスコープ外 ■ISO-2022-JP-MS について ◎ MUA でのメール送信時に、機種依存文字などが送信されないように、文字 コード変換ルーチン側で対処すべきでは? ・特定の用途に依存した変換を行うようにすると、用途毎に別々の変換を 用意する必要が出てくると思われる。 - MUA に依存した変換を行うと、テキストエディタで 7ビットJISコー ドを編集する場合など、ファイルを開くことが出来たものが保存で きないなどの問題が発生する ・文字種の制限の範囲や処理の仕方は、アプリケーション毎に異なるため、 アプリケーション側で対処するのが望ましい。 ◎ Unicode により国際化された MUA に変更を加えることなく機種依存文字が 含まれたメールが受信できるように ISO-2022-JP という名前で使えるよう にすべき ・ISO-2022-JP という名前のまま拡張する事は考えていない。 ◎ ユーザ定義文字をサポートするのは望ましくない ◎ ISO-2022-JP-MS といった、新しいレガシーエンコーディングを定義すべき ではなく、すでにある CP50221 の方が望ましい。 ・CP50221 の方が望ましいのであれば、ISO-2022-JP-MS ではなく CP50221 を実装するのでも良いと考えている。 ・Windows のコードページ 50220, 50221, 50222 では、ユーザ定義文字 と Unicode との変換は「仕様」である。 ・ISO-2022-JP-MS ではなく CP50221 を実装する場合、仕様である以上、 ユーザ定義文字は取り除いて実装するのは望ましくないと思われる。 ・現実の問題として 7ビットJIS(ISO-2022-JP) で、Windows 機種依存文字 が扱えない事が問題になっていて、ユーザ定義文字が扱えない事が、問題 視されている事はあまり見かけない。その事を考えれば、ISO-2022-JP-MS、 CP50221 のどちらでも良いと考えている。 ・CP50221 のようなものを RFC として提案して受け入れられるか? - ESC $ B で 94x94 文字集合ではなく、114x94 文字集合を G0 集合に 指示する事になってしまう。(GL 領域からはみ出る) ◎ CP5022X を扱えるテキストエディタ ・EmEditor http://www.emeditor.com/jp/ - Windows がサポートしているコードページのみ ・Alpha http://alpha.sourceforge.jp/ - Windows がサポートしているコードページ + α (EUC-JIS-2004など) ■CP51932 (Windows の EUC-JP のコードページ) について ◎ CP51932 は必要ないのでは? ◎ Unicode に移行すれば済む話なのでは? ・日本語EUC を使い PHP + PostgreSQL といった組み合わせで、システム 構築している場合に、CP51932 が必要だと考えている。 ・Perl/CGI など、日本語EUC で開発されているシステムでは、CP51932 でデータが蓄積されているので、そのデータを正しく変換するためにも 必要と考えている。 ■困っている実例 [pgsql-jp: 30677] ACCESSから漢字3が文字化け http://ml.postgresql.jp/pipermail/pgsql-jp/2003-August/014239.html ※漢字3 = IBM拡張文字 [PHP-jp 10948] 漢字コードの変換方法を教えてください。 http://ns1.php.gr.jp/php-jp/archives/msg10914.html [PHP-users 28961] 文字コード変換について（はしごたか） http://ns1.php.gr.jp/pipermail/php-users/2006-April/029478.html [Python-ml-jp 1821] 機種依存文字の扱いについて http://www.python.jp/pipermail/python-ml-jp/2002-September/001818.html [mmjp-users 366] 機種依存文字と arch (pipermail) について http://mm.tkikuchi.net/pipermail/mmjp-users/2003-May/000366.html ------------------------------------------------------------------------ -- 森山 将之 moriyama ＠ miraclelinux.com ミラクル・リナックス株式会社 From tom ＠ asakawa.ne.jp Wed May 17 16:03:08 2006 From: tom ＠ asakawa.ne.jp (Tomoyuki Asakawa) Date: Wed, 17 May 2006 16:03:08 +0900 Subject: [LE-talk-ja 119] =?iso-2022-jp?b?UmU6IExFLXRhbGstamEgGyRCJEcbKEI=?= =?iso-2022-jp?b?GyRCJE41RE9AJE4kXiRIJGEbKEI=?= In-Reply-To: <20060516184928.894D.MORIYAMA@miraclelinux.com> References: <20060516184928.894D.MORIYAMA@miraclelinux.com> Message-ID: <9448AF9E-FBCD-4DBA-9802-865B6DBC15B0@asakawa.ne.jp> あさかわ > これまでの、LE-talk-ja メーリングリストでの議論のまとめ > です。 まとめありがとうございます。すばらしい、パチパチ。 > ◎ 携帯絵文字 > > ・今回の開発ではスコープ外 > 携帯絵文字問題は、携帯絵文字拡張した、コードポイントが、 SJIS系 <-> Unicode EUC系 <-> Unicode JIS系 <-> Unicode JIS系 <-> EUC系 SJIS系 <->EUC系 で保持される必要があるとおもっています。 特にDBに格納した場合や、言語の内部での変換の場合に必要で 将来的には、内部コードとしての拡張UNICODEがあればいいとは 思いますが。 現状は、DBの都合で、EUC系の内部コードとして、必要と おもいます。 >◎ Macintosh > > ・今回の開発ではスコープ外 スコープ外と、言い切ってしまうのも。 MAC OS Xのiconvみると、utf-8-macなんてのが追加されて いて コメントには、sambaから持って来たと書いてある そういう意味では、MACが、歩みよってくれるという期待はあり ます。 From hyoshiok ＠ miraclelinux.com Wed May 17 22:45:35 2006 From: hyoshiok ＠ miraclelinux.com (Hiro Yoshioka) Date: Wed, 17 May 2006 22:45:35 +0900 (JST) Subject: [LE-talk-ja 120] =?iso-2022-jp?b?UmU6IBskQiUqJVUlaSUkJXMlXyE8GyhC?= =?iso-2022-jp?b?GyRCJUYlIyVzJTAbKEIoMjAwNi8wNS8xNyk=?= In-Reply-To: <20060502191137.E9C4.MORIYAMA@miraclelinux.com> References: <20060502191137.E9C4.MORIYAMA@miraclelinux.com> Message-ID: <20060517.224535.730575907.hyoshiok@miraclelinux.com> ミラクル・リナックスのよしおかです。 本日は、レガシーエンコーディングプロジェクトの 議論のために集まっていただき、ありがとうございました。 正直、当初は、どうなるかとは思いましたが、非常に 活発なご議論、ご討論、そして貴重なコメント、叱咤激励 ありがとうございます。 芝野さんからは、半分冗談で「よしおかが諸悪の根源だ(？！)」 と名指してコメントされましたが、まあいろいろ罪ほろぼしということで ご勘弁ください。 From: MORIYAMA Masayuki > 日時：2006年5月17日(水) 19時開始 > > 場所：ミラクル・リナックス株式会社(セミナールーム) > http://www.miraclelinux.com/corp/map.html 本日のおもな議事に関しましては後日メールさせて いただきますが、とりいそぎ御礼まで。 わたし自身は今回のオフラインミーティングで非常に勉強になりましたし、 それ以上に楽しかったので、参加の皆様に感謝の言葉もないです。 よ -- Hiro Yoshioka CTO/Miracle Linux Corporation http://blog.miraclelinux.com/yume/ From kazama ＠ mac.com Thu May 18 00:12:26 2006 From: kazama ＠ mac.com (Kazuhiro Kazama) Date: Thu, 18 May 2006 00:12:26 +0900 Subject: [LE-talk-ja 121] =?iso-2022-jp?b?GyRCJSolVSVpJSQlcyVfITwlRiUjGyhC?= =?iso-2022-jp?b?GyRCJXMlMCROGyhCKhskQjhEP01FKiRKGyhCKhskQjVET0AkTiReGyhC?= =?iso-2022-jp?b?GyRCJEgkYRsoQg==?= In-Reply-To: <20060516184928.894D.MORIYAMA@miraclelinux.com> References: <20060516184928.894D.MORIYAMA@miraclelinux.com> Message-ID: <70DB9439-5AA0-42A2-B846-44B050ECF741@mac.com> 皆さん，どうもごくろうさまでした． 部屋の片隅で，森山さんと二人で勝手に激烈（苦笑）な議論を戦わせて いましたが，その内容を個人的なメモとして簡単にまとめてみますの で，今後の叩き台にしてください． 1, Shift_JIS, EUC-JP, ISO-2022-JP系列 ・これらの既存の実装には手を加えない（今更これらの実装が足りない ことはないと思う）． ・既に広く使われている実装を変更するのは，互換性維持の点で反対さ れる可能性が高い（森山さんによると，その実例があるらしい）． ・Unicodeからレガシーエンコーディングに戻す時の変換表に手 を加えて，文字化けをより広く回避するような対策もおこなわない（森 山さんによると，この提案が却下された実例があるらしい）． 2, Windowsのコードページ系列 ・CP932, CP5022X, CP51932をサポート対象として検討． ・変換表に起因する文字化けはその組み合わせの中だけで回避する． ・森山さんによるとCP50221の方が実装の面から楽らしいが，私 が今日受け取ったばかりの"Developing International Software Second Edition"によるとCP50220の方がデフォルトのようなの で，どれを使うかは要調査． ・MSのコードページをUnix系OSでも利用できるよう にするだけなので，IANA登録やInternet Draftの提案はお こなわない． ・なお，既にこれらのコードページをサポートしているところでも，変 換表がMSと異なることがある．それを発見した時には，基本的に はMSに合わせて貰うようにお願いする．しかし， Shift_JISやEUC-JPなどを含めて変更してしまっていて，相手に 拒否されてしまったら，諦めざるをえないだろう（森山さんによると， その実例があるらしい）． 3, eucJP-ms ・すでにSambaで広く使われている． ・サポート対象として検討（ただし，サポートする意味のない環境は存 在したりするか？）． ・シフトJIS符号化(不可能)，JIS符号化は考 えない． 4, EUC-JP-2004（JIS X 0213:2004のEUC符号化） ・対象としない． ・CP51932やeucJP-msと互換性がなく，ベンダとしてはあ まり魅力がないらしい． P.S. "Developing International Application"ですが，付属のCD-ROM にコードページ表作成ツール（ただし，使ってみた感じでは，あまり期 待するようなものではなかったです）や変換ツールがありました． --- 風間 一洋 (kazama ＠ mac.com) From numata ＠ jp.fujitsu.com Thu May 18 09:56:40 2006 From: numata ＠ jp.fujitsu.com (NUMATA Toshinori) Date: Thu, 18 May 2006 09:56:40 +0900 Subject: [LE-talk-ja 122] =?iso-2022-jp?b?UmU6IBskQiUqJVUlaSUkJXMlXyE8GyhC?= =?iso-2022-jp?b?GyRCJUYlIyVzJTAkThsoQiobJEI4RD9NRSokShsoQio=?= =?iso-2022-jp?b?GyRCNURPQCROJF4kSCRhGyhC?= In-Reply-To: <70DB9439-5AA0-42A2-B846-44B050ECF741@mac.com> References: <20060516184928.894D.MORIYAMA@miraclelinux.com> <70DB9439-5AA0-42A2-B846-44B050ECF741@mac.com> Message-ID: <20060518005639.GA12382%numata@jp.fujitsu.com> Kazuhiro Kazama wrote: > 皆さん，どうもごくろうさまでした． > > 部屋の片隅で，森山さんと二人で勝手に激烈（苦笑）な議論を戦わせて > いましたが，その内容を個人的なメモとして簡単にまとめてみますの > で，今後の叩き台にしてください． 　その横で聞くともなく聞いておりましたが…． > 1, Shift_JIS, EUC-JP, ISO-2022-JP系列 ... > ・Unicodeからレガシーエンコーディングに戻す時の変換表に手 > を加えて，文字化けをより広く回避するような対策もおこなわない（森 > 山さんによると，この提案が却下された実例があるらしい）． 　これは: 「JIS X 0208 から Unicode に変換するときに， 1区33点“波ダッシュ”を U+301C WAVE DASH に変換する処理系と， U+FF5E FULLWIDTH TILDE に変換する処理系とが混在するので， Unicode から JIS X 0208 に変換するときは，U+301C も U+FF5E も 同じ1区33点に変換したい」 と提案したら，規格適合性の観点から(?)拒否された といった話ですよね． (具体例でいわないとわかりにくいので．) > 3, eucJP-ms ... > ・シフトJIS符号化(不可能)，JIS符号化は考 > えない． 　つまり，ISO-2022-JP-1 や ISO-2022-JP-2 のような JIS X 0212 を含む ISO-2022-JP 系エンコーディングに CP932 の拡張文字を追加するような ことは考えない，と． -- 富士通(株) ソフトウェア事業本部 開発企画統括部 沼田 利典 (numa ＠ sysrap.cs.fujitsu.co.jp) From moriyama ＠ miraclelinux.com Thu May 18 11:03:52 2006 From: moriyama ＠ miraclelinux.com (MORIYAMA Masayuki) Date: Thu, 18 May 2006 11:03:52 +0900 (JST) Subject: [LE-talk-ja 123] =?iso-2022-jp?b?UmU6IBskQiUqJVUlaSUkJXMlXyE8GyhC?= =?iso-2022-jp?b?GyRCJUYlIyVzJTAbKEIoMjAwNi8wNS8xNyk=?= References: <20060502191137.E9C4.MORIYAMA@miraclelinux.com> <20060517.224535.730575907.hyoshiok@miraclelinux.com> Message-ID: <20060518100415.895E.MORIYAMA@miraclelinux.com> ミラクル・リナックスの森山です。 昨日は、お忙しい中、お集まりいただきありがとうございます。 貴重なご意見を聞くことができ、有難く思っております。 次の場所に、使用した PowerPoint のプレゼン資料をを置きましたので、ご参 照ください。 http://sourceforge.jp/docman2/?group_id=2198 On Wed, 17 May 2006 22:45:35 +0900 (JST) Hiro Yoshioka wrote: > ミラクル・リナックスのよしおかです。 > > 本日は、レガシーエンコーディングプロジェクトの > 議論のために集まっていただき、ありがとうございました。 > > 正直、当初は、どうなるかとは思いましたが、非常に > 活発なご議論、ご討論、そして貴重なコメント、叱咤激励 > ありがとうございます。 > > 芝野さんからは、半分冗談で「よしおかが諸悪の根源だ(？！)」 > と名指してコメントされましたが、まあいろいろ罪ほろぼしということで > ご勘弁ください。 > > From: MORIYAMA Masayuki > > 日時：2006年5月17日(水) 19時開始 > > > > 場所：ミラクル・リナックス株式会社(セミナールーム) > > http://www.miraclelinux.com/corp/map.html > > 本日のおもな議事に関しましては後日メールさせて > いただきますが、とりいそぎ御礼まで。 > > わたし自身は今回のオフラインミーティングで非常に勉強になりましたし、 > それ以上に楽しかったので、参加の皆様に感謝の言葉もないです。 > > よ > -- > Hiro Yoshioka > CTO/Miracle Linux Corporation > http://blog.miraclelinux.com/yume/ > _______________________________________________ > Legacy-Encoding-talk-ja mailing list > Legacy-Encoding-talk-ja ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/legacy-encoding-talk-ja -- 森山 将之 moriyama ＠ miraclelinux.com ミラクル・リナックス株式会社 From murata656 ＠ oki.com Thu May 18 11:34:59 2006 From: murata656 ＠ oki.com (Toshiki Murata) Date: Thu, 18 May 2006 11:34:59 +0900 (JST) Subject: [LE-talk-ja 124] =?iso-2022-jp?b?UmU6IBskQiUqJVUlaSUkJXMlXyE8GyhC?= =?iso-2022-jp?b?GyRCJUYlIyVzJTAbKEIoMjAwNi8wNS8xNyk=?= In-Reply-To: <20060518100415.895E.MORIYAMA@miraclelinux.com> References: <20060502191137.E9C4.MORIYAMA@miraclelinux.com> <20060517.224535.730575907.hyoshiok@miraclelinux.com> <20060518100415.895E.MORIYAMA@miraclelinux.com> Message-ID: <20060518.113459.48508403.mura@kansai.oki.co.jp> はじめまして、 沖電気工業の村田と申します。 以前Javaにおける Shift_JIS と MS932(CP932)の問題に 関わっていました。（＆今も悩まされています。。。） > 昨日は、お忙しい中、お集まりいただきありがとうございます。 > 貴重なご意見を聞くことができ、有難く思っております。 参加できなくて申し訳ありませんでした。 参加していないのではずしているかもしれないのですが、 気になったことを書きます。 PowerPointの資料やみなさまの議論のまとめを見ていますと、 EUC-JP, Shift_JIS, ISO-2022-JP 間の変換の話が中心となっています。 おそらく Unicode への変換は議論のスコープ外なのではないかと 思っています。 ただ、上記の３つの変換の真ん中には Unicode がありますので、 当然関係しています。 今回の目的は３つの変換がうまくいくことをめざしていると思うのですが、 仮に「Windows系の変換表を用いる」ということが結論になった場合、 各OSS関連のツールは、これら３つのコードからUnicodeに変換するのは 「Windows系の変換表を用いる」ことが事実上デファクトになってしまう と思います。 とすると、議論のスコープ外かもしれませんが、 Unicode への変換は今後日本としては「Windows系の変換表」を 推奨するという感じになるのではと思います。 一応、それがいいかどうかも議論したほうがいいのではというのが ぼくの気になったことです。 この辺り、今どのような議論になっているのでしょうか。 -- ----------------------------------------------------- 沖電気工業株式会社 研究開発本部 技術マーケティング部 村田稔樹 〒541-0053 大阪市中央区本町2-5-7 丸紅大阪本社ビル4F Tel: 06-6260-0700 Fax: 06-6260-0770 E-mail: murata656 ＠ oki.com mura ＠ kansai.oki.co.jp URL: http://www.oki.com/jp/ URL: http://www.yakushite.net/ ----------------------------------------------------- From tom ＠ asakawa.ne.jp Thu May 18 11:50:15 2006 From: tom ＠ asakawa.ne.jp (Tomoyuki Asakawa) Date: Thu, 18 May 2006 11:50:15 +0900 Subject: [LE-talk-ja 125] =?iso-2022-jp?b?UmU6IBskQiUqJVUlaSUkJXMlXyE8GyhC?= =?iso-2022-jp?b?GyRCJUYlIyVzJTAbKEIoMjAwNi8wNS8xNyk=?= In-Reply-To: <20060518.113459.48508403.mura@kansai.oki.co.jp> References: <20060502191137.E9C4.MORIYAMA@miraclelinux.com> <20060517.224535.730575907.hyoshiok@miraclelinux.com> <20060518100415.895E.MORIYAMA@miraclelinux.com> <20060518.113459.48508403.mura@kansai.oki.co.jp> Message-ID: <14C8F22B-C6D5-408F-8E6D-B3AC15D4F601@asakawa.ne.jp> あさかわです。 > > 仮に「Windows系の変換表を用いる」ということが結論になっ > た場合、 > 各OSS関連のツールは、これら３つのコードからUnicode > に変換するのは > 「Windows系の変換表を用いる」ことが事実上デファクトに > なってしまう > と思います。 > 趣旨としてはそうなります。そもそも、「きっかけはーサンバ」 > とすると、議論のスコープ外かもしれませんが、 じつは、全くの、ストライクゾーンです。 > Unicode への変換は今後日本としては「Windows系の変換表」を > 推奨するという感じになるのではと思います。 そうおもいますし、それが、一番平和だとおもっています。 From kazama ＠ mac.com Thu May 18 12:44:45 2006 From: kazama ＠ mac.com (Kazuhiro Kazama) Date: Thu, 18 May 2006 12:44:45 +0900 Subject: [LE-talk-ja 126] =?iso-2022-jp?b?UmU6IBskQiUqJVUlaSUkJXMlXyE8GyhC?= =?iso-2022-jp?b?GyRCJUYlIyVzJTAkThsoQiobJEI4RD9NRSokShsoQiobJEI1RE9AGyhC?= =?iso-2022-jp?b?GyRCJE4kXiRIJGEbKEI=?= In-Reply-To: <20060518005639.GA12382%numata@jp.fujitsu.com> References: <20060516184928.894D.MORIYAMA@miraclelinux.com> <70DB9439-5AA0-42A2-B846-44B050ECF741@mac.com> <20060518005639.GA12382%numata@jp.fujitsu.com> Message-ID: On 2006/05/18, at 9:56, NUMATA Toshinori wrote: >> ・Unicodeからレガシーエンコーディングに戻す時の変換表に手 >> を加えて，文字化けをより広く回避するような対策もおこなわない（森 >> 山さんによると，この提案が却下された実例があるらしい）． > > 　これは: > > 「JIS X 0208 から Unicode に変換するときに， > 1区33点“波ダッシュ”を U+301C WAVE DASH に変換する処理系と， > U+FF5E FULLWIDTH TILDE に変換する処理系とが混在するので， > Unicode から JIS X 0208 に変換するときは，U+301C も U+FF5E も > 同じ1区33点に変換したい」 > > と提案したら，規格適合性の観点から(?)拒否された > > といった話ですよね． > (具体例でいわないとわかりにくいので．) どうも補足ありがとうございます． ＃ 時間がなかったのと，森山さん本人が補足してくれるだろうと思ったので （笑） ただ，「規格適合性」という言葉は多少微妙です． 実は，一時期Unicode Consortiumでは，彼らが配布していたレガシーエンコー ディングとUnicodeとの対応表がいろいろ問題を引き起こすので，これは規格 の一部でないと削除したことがあったと思います（その後復活しましたが）． そういう意味では，Unicode Consortium自身は，公式には規格の一部とはみな していないのではないかと思います．JISでは，若干含みを持たせた規定をし ていますし．昨夜も変換表の議論もありましたし，グレーゾーンなのかも． それで，この対応方法には，3種類あると思います． 1, 公式に配布されている規格，ないしは実装に完全に一致 2, 1に，他で符号化文字集合でUnicodeの異なる符号位置に変換される文字も サポート 3, 文字集合は一致するが，まったく独自の変換表 これで言及しているのは2の場合で（←これでよいですか？＞森山さん），規 格に適合する（が，他の符号位置も考慮される）とも考えられなくはないと思 います．ただし，この場合には，他の文字符号化への依存性が入ってしまう （たとえば，新しい異なるポリシーの文字符号化コンバータを追加したら，他 も修正しなければいけないのか？）ことになり，やっかいです．結局，この種 の問題が生じるのを嫌って，厳格に規定通りに実装するという意見が支持され るのだと思います． もちろん，異なる意見の人達もいるようです． >> 3, eucJP-ms > ... >> ・シフトJIS符号化(不可能)，JIS符号化は考 >> えない． > > 　つまり，ISO-2022-JP-1 や ISO-2022-JP-2 のような JIS X 0212 を含む > ISO-2022-JP 系エンコーディングに CP932 の拡張文字を追加するような > ことは考えない，と． eucJP-msは，IBM拡張文字が一部入っているので，ISO-2022-JP-1,2と完全に互 換じゃないと理解してたんだけど，間違いだったりします？ これ意外に，「ISO-2022-JP-1 や ISO-2022-JP-2は誰もつかってない/必要と してないよねえ」という状況が根底にあります． --- 風間 一洋 (kazama ＠ mac.com) From kazama ＠ mac.com Thu May 18 13:02:38 2006 From: kazama ＠ mac.com (Kazuhiro Kazama) Date: Thu, 18 May 2006 13:02:38 +0900 Subject: [LE-talk-ja 127] =?iso-2022-jp?b?UmU6IBskQiUqJVUlaSUkJXMlXyE8GyhC?= =?iso-2022-jp?b?GyRCJUYlIyVzJTAbKEIoMjAwNi8wNS8xNyk=?= In-Reply-To: <14C8F22B-C6D5-408F-8E6D-B3AC15D4F601@asakawa.ne.jp> References: <20060502191137.E9C4.MORIYAMA@miraclelinux.com> <20060517.224535.730575907.hyoshiok@miraclelinux.com> <20060518100415.895E.MORIYAMA@miraclelinux.com> <20060518.113459.48508403.mura@kansai.oki.co.jp> <14C8F22B-C6D5-408F-8E6D-B3AC15D4F601@asakawa.ne.jp> Message-ID: On 2006/05/18, at 11:50, Tomoyuki Asakawa wrote: >> 仮に「Windows系の変換表を用いる」ということが結論になっ >> た場合、 >> 各OSS関連のツールは、これら３つのコードからUnicode >> に変換するのは >> 「Windows系の変換表を用いる」ことが事実上デファクトに >> なってしまう >> と思います。 >> > > 趣旨としてはそうなります。そもそも、「きっかけはーサンバ」 問題はそんな簡単じゃないでしょう． というのは，話を聞くとOSSによっては独自の変更を加えてしまっていて，今 更変えられないというところがいくつかあるようですし，今回の話はISO-2022- JP，Shift_JIS, Windows-31J, EUC-JPというIANAに登録されているcharset名 との対応を公式に変更するわけでもないからです． >> Unicode への変換は今後日本としては「Windows系の変換表」を >> 推奨するという感じになるのではと思います。 > > そうおもいますし、それが、一番平和だとおもっています。 日本がどうするかは，次のJIS X 0221の改訂で何らかのアクションを起こすか にかかっていると思います． ご紹介したMSの阿南さんのメールで引用されていた「新人名用漢字とJISの対 応に関する報告書」では，UTF-8, UTF-16が安定してつかえる符号化方法であ り，インターネット上ではUTF-8を使うことを推奨しています． この方針に従って今後はUCSベースで文字を決めていくことになるので，次の 改訂作業で同時にUCSにおける日本語の集合を規定するかもしれないという噂 （←あくまで噂）も聞きます．それがおこなわれれば，日本ではどの文字を使 うということが明確に規定されることになるかもしれませんし，それにMS（そ もそも阿南さんが貢献しているので（笑））やAppleなどの企業も従うでしょ う． しかし，また玉虫色ということもあるかもしれませんけど（苦笑） --- 風間 一洋 (kazama ＠ mac.com) From kazama ＠ mac.com Thu May 18 13:59:30 2006 From: kazama ＠ mac.com (Kazuhiro Kazama) Date: Thu, 18 May 2006 13:59:30 +0900 Subject: [LE-talk-ja 128] =?iso-2022-jp?b?UmU6IExFLXRhbGstamEgGyRCJEcbKEI=?= =?iso-2022-jp?b?GyRCJE41RE9AJE4kXiRIJGEbKEI=?= In-Reply-To: <20060516184928.894D.MORIYAMA@miraclelinux.com> References: <20060516184928.894D.MORIYAMA@miraclelinux.com> Message-ID: <22441D30-61EE-47A0-89FF-AB5C6FD4DAB4@mac.com> 当日も本人に（前半部分を）言いましたが，このまとめに補足します． On 2006/05/16, at 18:50, MORIYAMA Masayuki wrote: > ◎ JIS X 0208 で定義されていない文字を扱う場合は UTF-8 を使うべき > > ・既存のシステムすべてが短期間で UTF-8 に移行するわけではない > - レガシーエンコーディング + UTF-8 (Unicode) という混在環境へ > の移 > 行と考えている。 > - 過去の資産はレガシーエンコーディングで蓄積されている。 > - 短期間のうちにレガシーエンコーディングが無くなり UTF-8 に > 取って > 代わられるわけではない。 > ・シフトJIS や日本語EUC から UTF-8 への移行コストが高い場合があ > る。 > - シフトJIS や日本語EUC に依存して開発されている > - UTF-8 でのバイト数増加の問題 > - UTF-8 環境が整っていない > ・レガシーエンコーディングからUTF-8への移行期間がありプロジェクト > の成果物はこの期間で使われること想定している。 これや吉岡さんのブログも読んでて，UTF-8をサポートする＝UCS正規化方式 （レガシーエンコーディングをUnicodeに変換して処理）で国際化すること， という勘違いをしているように感じました． 基本的に，レガシーエンコーディングを入出力時にUTF-8に変換するのは難し いことではありません．たとえば，nkfがその方式ではないでしょうか？実際 にさまざまな実装が考えられることが，「新人名用漢字とJISの対応に関する 報告書」で指摘されています． まあ，メールで言えば，ISO-2022-JPとUTF-8のどちらも使えるわけですし，実 装コストも高くはなく，UCS正規化方式でレガシーエンコーディングを処理す るシステムが増えている昨今性能などを云々しても意味はない（昔のUUCP時代 じゃないですからね）と思います．つまり，ここで指摘されたすべての事項 が，誤解からくる誤りであると考えてよいと思っています． ただし，一つ問題（？）があるのを発見しました． というのは，UCS正規化方式では，Unicodeがレガシーエンコーディングのスー パーセットなのですが，たとえば内部処理をレガシーエンコーディングベース でやっていた場合には，この立場が逆転します．たとえばShift-JIS符号化や EUC符号化であっても，ベンダ独自の文字を加えた変種が出てきますが，これ は従来の文字符号化間がアルゴリズム変換であることから許容される，文字と 符号位置の対応の曖昧性のために，あまり文字に依存した処理をしたり，表示 をしなければ許容されます．つまり，厳密に見ると，互いの内部の符号位置が 必ずしも互換ではないことがあります． これがどのような問題を引き起こすかというと，内部の文字の並びが入力に応 じて異なるために，変換表を使わねばならないUTF-8の場合には，内部でどの ような符号化文字集合を処理するかによって，変換表を使い分けなければなら ないということになります．たとえば，CP51932とeucJP-ms (EUC-JP-2004も) は異なる変換表を使わねばなりません．そうすると，現時点の（昨日批判され た）一つの文字符号化と一つの変換表を対応させて扱うという方法が取れなく なります．UTF-8-cp51932やUTF-8-eucJP-msとか…しかも中身が何かを意識し なければならない…． ＃ もし勘違いがあればご指摘ください． としたら， ・UCS正規化方式だったらUTF-8は簡単． ・それ以外でも，レガシーエンコーディングを特定すれば難しくない．ただ し，一般的には曖昧性があるので，アプリケーション依存で実装することにな るかも（まあ，できないとは言いませんが…）． という感じになるのかもしれません．どうでしょう？ --- 風間 一洋 (kazama ＠ mac.com) From hyoshiok ＠ miraclelinux.com Thu May 18 14:57:56 2006 From: hyoshiok ＠ miraclelinux.com (Hiro Yoshioka) Date: Thu, 18 May 2006 14:57:56 +0900 (JST) Subject: [LE-talk-ja 129] =?iso-2022-jp?b?UmU6IExFLXRhbGstamEgGyRCJEcbKEI=?= =?iso-2022-jp?b?GyRCJE41RE9AJE4kXiRIJGEbKEI=?= In-Reply-To: <22441D30-61EE-47A0-89FF-AB5C6FD4DAB4@mac.com> References: <20060516184928.894D.MORIYAMA@miraclelinux.com> <22441D30-61EE-47A0-89FF-AB5C6FD4DAB4@mac.com> Message-ID: <20060518.145756.576039588.hyoshiok@miraclelinux.com> よしおかです。 昨日は出席いただきありがとうございました。 From: Kazuhiro Kazama Subject: [LE-talk-ja 128] Re: LE-talk-ja での議論のまとめ Date: Thu, 18 May 2006 13:59:30 +0900 Message-ID: <22441D30-61EE-47A0-89FF-AB5C6FD4DAB4 ＠ mac.com> > 当日も本人に（前半部分を）言いましたが，このまとめに補足します． > > On 2006/05/16, at 18:50, MORIYAMA Masayuki wrote: > > ◎ JIS X 0208 で定義されていない文字を扱う場合は UTF-8 を使うべき > > > > ・既存のシステムすべてが短期間で UTF-8 に移行するわけではない > > - レガシーエンコーディング + UTF-8 (Unicode) という混在環境へ > > の移 > > 行と考えている。 > > - 過去の資産はレガシーエンコーディングで蓄積されている。 > > - 短期間のうちにレガシーエンコーディングが無くなり UTF-8 に > > 取って > > 代わられるわけではない。 > > ・シフトJIS や日本語EUC から UTF-8 への移行コストが高い場合があ > > る。 > > - シフトJIS や日本語EUC に依存して開発されている > > - UTF-8 でのバイト数増加の問題 > > - UTF-8 環境が整っていない > > ・レガシーエンコーディングからUTF-8への移行期間がありプロジェクト > > の成果物はこの期間で使われること想定している。 > > これや吉岡さんのブログも読んでて，UTF-8をサポートする＝UCS正規化方式 > （レガシーエンコーディングをUnicodeに変換して処理）で国際化すること， > という勘違いをしているように感じました． 違います。 UTF-8はUTF-8として考えています。 あるシステムが動いていたとして、それで何の問題もなく(文字化け以外) 動いているのなら、誰がUTF-8に移行しますか？ 現場でUTF-8移行するというインセンティブはありません。 だから、UTF-8をサポートすればいいというのは現場の人にはひびきません。 > 基本的に，レガシーエンコーディングを入出力時にUTF-8に変換するのは難し > いことではありません．たとえば，nkfがその方式ではないでしょうか？実際 > にさまざまな実装が考えられることが，「新人名用漢字とJISの対応に関する > 報告書」で指摘されています． 難しい易しいという話ではなく、現場の人は移行しないと いっているのです。 cp932で使える文字が、なんで化けるのか？その問題を 解決するというお話です。 > まあ，メールで言えば，ISO-2022-JPとUTF-8のどちらも使えるわけですし，実 > 装コストも高くはなく，UCS正規化方式でレガシーエンコーディングを処理す > るシステムが増えている昨今性能などを云々しても意味はない（昔のUUCP時代 > じゃないですからね）と思います．つまり，ここで指摘されたすべての事項 > が，誤解からくる誤りであると考えてよいと思っています． その前提が違うということを言っているのです。 クライアントがcp932でPHPとMySQLで組んでいるシステムがあったとして MySQLとPHPがeuc-jpを使っていたとします。 それを運用している人が文字化けするからUTF-8に移行するかという話です。 スクラッチからシステムを構築するならともかく、既にあるシステムに 積極的に手をいれてデータのコンバートをして、山のようにあるスクリプト を全部書き変えてというようなコストを誰がはらうか？誰もはらいたくない という現実に、どう対処するかという問題です。 よ -- Hiro Yoshioka CTO/Miracle Linux Corporation http://blog.miraclelinux.com/yume/ > ただし，一つ問題（？）があるのを発見しました． > > というのは，UCS正規化方式では，Unicodeがレガシーエンコーディングのスー > パーセットなのですが，たとえば内部処理をレガシーエンコーディングベース > でやっていた場合には，この立場が逆転します．たとえばShift-JIS符号化や > EUC符号化であっても，ベンダ独自の文字を加えた変種が出てきますが，これ > は従来の文字符号化間がアルゴリズム変換であることから許容される，文字と > 符号位置の対応の曖昧性のために，あまり文字に依存した処理をしたり，表示 > をしなければ許容されます．つまり，厳密に見ると，互いの内部の符号位置が > 必ずしも互換ではないことがあります． > > これがどのような問題を引き起こすかというと，内部の文字の並びが入力に応 > じて異なるために，変換表を使わねばならないUTF-8の場合には，内部でどの > ような符号化文字集合を処理するかによって，変換表を使い分けなければなら > ないということになります．たとえば，CP51932とeucJP-ms (EUC-JP-2004も) > は異なる変換表を使わねばなりません．そうすると，現時点の（昨日批判され > た）一つの文字符号化と一つの変換表を対応させて扱うという方法が取れなく > なります．UTF-8-cp51932やUTF-8-eucJP-msとか…しかも中身が何かを意識し > なければならない…． > > ＃ もし勘違いがあればご指摘ください． > > としたら， > > ・UCS正規化方式だったらUTF-8は簡単． > ・それ以外でも，レガシーエンコーディングを特定すれば難しくない．ただ > し，一般的には曖昧性があるので，アプリケーション依存で実装することにな > るかも（まあ，できないとは言いませんが…）． > > という感じになるのかもしれません．どうでしょう？ > --- > 風間 一洋 (kazama ＠ mac.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 tom ＠ asakawa.ne.jp Thu May 18 15:08:41 2006 From: tom ＠ asakawa.ne.jp (Tomoyuki Asakawa) Date: Thu, 18 May 2006 15:08:41 +0900 Subject: [LE-talk-ja 130] =?iso-2022-jp?b?UmU6IExFLXRhbGstamEgGyRCJEcbKEI=?= =?iso-2022-jp?b?GyRCJE41RE9AJE4kXiRIJGEbKEI=?= In-Reply-To: <20060518.145756.576039588.hyoshiok@miraclelinux.com> References: <20060516184928.894D.MORIYAMA@miraclelinux.com> <22441D30-61EE-47A0-89FF-AB5C6FD4DAB4@mac.com> <20060518.145756.576039588.hyoshiok@miraclelinux.com> Message-ID: あさかわ >> まあ，メールで言えば，ISO-2022-JPとUTF-8のどちら >> も使えるわけですし，実 >> 装コストも高くはなく，UCS正規化方式でレガシーエンコー >> ディングを処理す >> るシステムが増えている昨今性能などを云々しても意味はない（昔の >> UUCP時代 >> じゃないですからね）と思います．つまり，ここで指摘されたすべ >> ての事項 >> が，誤解からくる誤りであると考えてよいと思っています． > > その前提が違うということを言っているのです。 ですね。 > > クライアントがcp932でPHPとMySQLで組んでいる > システムがあったとして > MySQLとPHPがeuc-jpを使っていたとします。 > > それを運用している人が文字化けするからUTF-8に移行するか > という話です。 > スクラッチからシステムを構築するならともかく、既にあるシステムに > 積極的に手をいれてデータのコンバートをして、山のようにあるスク > リプト > を全部書き変えてというようなコストを誰がはらうか？誰もはらいた > くない > という現実に、どう対処するかという問題です。 そうです。 メールの例は、例としてわかりやすいかもしれないけれども、 実際は、メールは、表面的には、MUAだけの問題で解決できるの で、単純な部類です。 問題は、メールに限らず、「それ」を格納し、「それ」を、取り出す時 の問題 どこに格納するかによって、「それ」が、変化してしまう。 From kazama ＠ mac.com Thu May 18 15:23:41 2006 From: kazama ＠ mac.com (Kazuhiro Kazama) Date: Thu, 18 May 2006 15:23:41 +0900 Subject: [LE-talk-ja 131] =?iso-2022-jp?b?UmU6IExFLXRhbGstamEgGyRCJEcbKEI=?= =?iso-2022-jp?b?GyRCJE41RE9AJE4kXiRIJGEbKEI=?= In-Reply-To: <20060518.145756.576039588.hyoshiok@miraclelinux.com> References: <20060516184928.894D.MORIYAMA@miraclelinux.com> <22441D30-61EE-47A0-89FF-AB5C6FD4DAB4@mac.com> <20060518.145756.576039588.hyoshiok@miraclelinux.com> Message-ID: On 2006/05/18, at 14:57, Hiro Yoshioka wrote: > cp932で使える文字が、なんで化けるのか？その問題を > 解決するというお話です。 Cp932で使える文字がISO-2022-JPで使えない点に関しては，それがサポートさ れていないからという点を問題にしていました．私も，今更新しい独自の charsetを提案しても，結局誰も使わないという点に完全に同意します． > クライアントがcp932でPHPとMySQLで組んでいるシステムがあったとして > MySQLとPHPがeuc-jpを使っていたとします。 > > それを運用している人が文字化けするからUTF-8に移行するかという話です。 それなら了解しました． > スクラッチからシステムを構築するならともかく、既にあるシステムに > 積極的に手をいれてデータのコンバートをして、山のようにあるスクリプト > を全部書き変えてというようなコストを誰がはらうか？誰もはらいたくない > という現実に、どう対処するかという問題です。 …なんてことをしようという話は，私は書いていないから大丈夫です（笑） ただし，この例に関しては，新たにUTF-8入出力できるようにしても，それは 単に入出力時のコンバータレベルの話であり，内部に手を入れる必要はないと いう事例を指摘していました．その点が誤解していると思ったわけですよ． --- 風間 一洋 (kazama ＠ mac.com) From numata ＠ jp.fujitsu.com Thu May 18 15:27:04 2006 From: numata ＠ jp.fujitsu.com (NUMATA Toshinori) Date: Thu, 18 May 2006 15:27:04 +0900 Subject: [LE-talk-ja 132] =?iso-2022-jp?b?UmU6IBskQiUqJVUlaSUkJXMlXyE8GyhC?= =?iso-2022-jp?b?GyRCJUYlIyVzJTAkThsoQiobJEI4RD9NRSokShsoQio=?= =?iso-2022-jp?b?GyRCNURPQCROJF4kSCRhGyhC?= In-Reply-To: References: <20060516184928.894D.MORIYAMA@miraclelinux.com> <70DB9439-5AA0-42A2-B846-44B050ECF741@mac.com> <20060518005639.GA12382%numata@jp.fujitsu.com> Message-ID: <20060518062703.GA18052%numata@jp.fujitsu.com> Kazuhiro Kazama wrote: > On 2006/05/18, at 9:56, NUMATA Toshinori wrote: > >> ・Unicodeからレガシーエンコーディングに戻す時の変換表に手 > >> を加えて，文字化けをより広く回避するような対策もおこなわない（森 > >> 山さんによると，この提案が却下された実例があるらしい）． > > > > 　これは: > > > > 「JIS X 0208 から Unicode に変換するときに， > > 1区33点“波ダッシュ”を U+301C WAVE DASH に変換する処理系と， > > U+FF5E FULLWIDTH TILDE に変換する処理系とが混在するので， > > Unicode から JIS X 0208 に変換するときは，U+301C も U+FF5E も > > 同じ1区33点に変換したい」 > > > > と提案したら，規格適合性の観点から(?)拒否された > > > > といった話ですよね． > > (具体例でいわないとわかりにくいので．) > > どうも補足ありがとうございます． > > ＃ 時間がなかったのと，森山さん本人が補足してくれるだろうと思ったので > （笑） > > ただ，「規格適合性」という言葉は多少微妙です． > > 実は，一時期Unicode Consortiumでは，彼らが配布していたレガシーエンコー > ディングとUnicodeとの対応表がいろいろ問題を引き起こすので，これは規格 > の一部でないと削除したことがあったと思います（その後復活しましたが）． > そういう意味では，Unicode Consortium自身は，公式には規格の一部とはみな > していないのではないかと思います．JISでは，若干含みを持たせた規定をし > ていますし．昨夜も変換表の議論もありましたし，グレーゾーンなのかも． 　Unicode とレガシーエンコーディングとの間のコード変換規則については， Unicode の側ではなくレガシーエンコーディングの側で規定すべきである， という考え方が，少なくとも日本の関係者の間にはある，という話を聞いた ことがあります． 　だから，JIS X 0221:1995 で JIS X 0208 や JIS X 0212 との間の変換規則 を記述した部分は「附属書 (参考)」であって「規定」ではなく，規定になった のは JIS X 0208:1997 でした．(X 0212 は改定されていないので，いまだに 「参考」のまま…) 　というわけで，上で「規格適合性」と書いたのは，書いた本人の意図としては JIS の方を想定していました． > >> 3, eucJP-ms > > ... > >> ・シフトJIS符号化(不可能)，JIS符号化は考 > >> えない． > > > > 　つまり，ISO-2022-JP-1 や ISO-2022-JP-2 のような JIS X 0212 を含む > > ISO-2022-JP 系エンコーディングに CP932 の拡張文字を追加するような > > ことは考えない，と． > > eucJP-msは，IBM拡張文字が一部入っているので，ISO-2022-JP-1,2と完全に互 > 換じゃないと理解してたんだけど，間違いだったりします？ 　RFC1554 (ISO-2022-JP-2) 及び RFC2237 (ISO-2022-JP-1) のどちらも， IBM 拡張文字や NEC 特殊文字やユーザー定義文字などは入れていません． よって，eucJP-ms にある全ての文字を変換できるわけではありません． > これ意外に，「ISO-2022-JP-1 や ISO-2022-JP-2は誰もつかってない/必要と > してないよねえ」という状況が根底にあります． 　これは，そうでしょうねえ． -- 富士通(株) ソフトウェア事業本部 開発企画統括部 沼田 利典 (numa ＠ sysrap.cs.fujitsu.co.jp) From tom ＠ asakawa.ne.jp Thu May 18 15:42:11 2006 From: tom ＠ asakawa.ne.jp (Tomoyuki Asakawa) Date: Thu, 18 May 2006 15:42:11 +0900 Subject: [LE-talk-ja 133] =?iso-2022-jp?b?UmU6IBskQiUqJVUlaSUkJXMlXyE8GyhC?= =?iso-2022-jp?b?GyRCJUYlIyVzJTAkThsoQiobJEI4RD9NRSokShsoQiobJEI1RE9AGyhC?= =?iso-2022-jp?b?GyRCJE4kXiRIJGEbKEI=?= In-Reply-To: <20060518062703.GA18052%numata@jp.fujitsu.com> References: <20060516184928.894D.MORIYAMA@miraclelinux.com> <70DB9439-5AA0-42A2-B846-44B050ECF741@mac.com> <20060518005639.GA12382%numata@jp.fujitsu.com> <20060518062703.GA18052%numata@jp.fujitsu.com> Message-ID: <59323EB9-7BE8-45FC-80A5-8E68B1F9CF66@asakawa.ne.jp> あさかわ > >> これ意外に，「ISO-2022-JP-1 や ISO-2022-JP-2は誰 >> もつかってない/必要と >> してないよねえ」という状況が根底にあります． > > 　これは，そうでしょうねえ． ISO-2022-JP-1 や ISO-2022-JP-2 なんてものの存在を、じつは、今回はじめてしりました。 自分がそうだからというわけではないけど、きっとそういう人は多いだ ろうと思う。 しかし、ISO-2022-JP-1 や ISO-2022-JP-2で、ISO-2022- JPに対して、追加されてるものを 必要とした人は、ISO-2022-JPで、半角カナや、IBM 拡張 文字や NEC 特殊文字やユーザー定義文字 を、つかうのと同じく、そのまま、生エスケープシーケンスでつかって ると思う。 つまり、ISO-2022-JPという単語は、１５年前の私の誤解と同様に 単に、EUC「系」やSJIS「系」,UTF「系」ではない、 JIS「系」という、識別として使われてると思う。 いや、そもそも。ISO-2022-JPという識別子すらつかってないで しょう。 EUCやSJISが出現する前はそうだったのだから。 20年前のシステムの子孫をつかっていたらそうなってるはず。 From nozomi ＠ biol.tsukuba.ac.jp Thu May 18 15:49:03 2006 From: nozomi ＠ biol.tsukuba.ac.jp (Nozomi Ytow) Date: Thu, 18 May 2006 15:49:03 +0900 (JST) Subject: [LE-talk-ja 134] =?iso-2022-jp?b?UmU6IExFLXRhbGstamEgGyRCJEcbKEI=?= =?iso-2022-jp?b?GyRCJE41RE9AJE4kXiRIJGEbKEI=?= In-Reply-To: <20060518.145756.576039588.hyoshiok@miraclelinux.com> References: <20060516184928.894D.MORIYAMA@miraclelinux.com> <22441D30-61EE-47A0-89FF-AB5C6FD4DAB4@mac.com> <20060518.145756.576039588.hyoshiok@miraclelinux.com> Message-ID: <20060518.154903.36935854.nozomi@biol.tsukuba.ac.jp> オフラインミーティングには参加できず残念でしたが、 資料が見られ助かっています。 しかし、すみません、議論を読んでいてわからなくなりました。 Hiro Yoshioka wrote: よ> クライアントがcp932でPHPとMySQLで組んでいるシステムがあったとして よ> MySQLとPHPがeuc-jpを使っていたとします。 よ> それを運用している人が文字化けするからUTF-8に移行するかという話です。 cp932 には「はしご高」がある一方、euc-jp の高は「包摂高」なので euc-jp には「はしご高」も「くち高」もあり得ない (あってる?)、 だから cp932 と euc-jp は本当は共存できず、UTF-8 に移行した ところで問題は厳密には解決しない。でも見た目それっぽいくらいなら できる、というレベルの問題だと思っているのですが、違いますか。 そういう意味では、 Tomoyuki Asakawa wrote: あ> 実際は、メールは、表面的には、MUAだけの問題で解決できるの あ> で、単純な部類です。 と同じ程度だとも言えるし、MUA では実は解決していないとも言える気が。 あ> 問題は、メールに限らず、「それ」を格納し、「それ」を、 あ> 取り出す時 の問題 あ> どこに格納するかによって、「それ」が、変化してしまう。 文字集合間に(厳密な意味での)互換性がない以上、不可避だと思います。 「それ」が格納先の「それ」になってしまう (「包摂高」を 「はしご高」と「くち高」の格納場所を持ちかつ「包摂高」の 格納場所を持たない系に格納したら、取り出せるのは 「はしご高」か「くち高」のいずれかであって「包摂高」ではない) のは当り前ではないかと。そう考えると Unicode との変換規則は レガシー側でという発想は理解できます。 そこまで細かい事を問うているとは思いませんが、 結局は無理な事を求めているのだし、だから実装をいろいろ 作らざるを得ないのではないかと思います。 包摂文字かどうか指定する拡張というのもかつて考えてみたことは あるのですが、アプリケーション依存 (そんなのマニアしか使わない ともいう) になりそうなのでやめました。 eucJP-ms というのは名前としてはちょっとアレなのでいっそのこと euc-CPナントカなどもっと直接的なものにしてはどうかと思いますが、 UTF-8 に移行したところで解決しない問題なので、仮に移行コストを 度外視しても「UTF-8 にすればいいじゃん」とは言えないよなぁと 思っています。 -- ＮＯＺ 伊藤　希 (のぞみ) Ｏ　Ｏ ＺＯＮ From kazama ＠ mac.com Thu May 18 15:58:04 2006 From: kazama ＠ mac.com (Kazuhiro Kazama) Date: Thu, 18 May 2006 15:58:04 +0900 Subject: [LE-talk-ja 135] =?iso-2022-jp?b?UmU6IExFLXRhbGstamEgGyRCJEcbKEI=?= =?iso-2022-jp?b?GyRCJE41RE9AJE4kXiRIJGEbKEI=?= In-Reply-To: References: <20060516184928.894D.MORIYAMA@miraclelinux.com> <22441D30-61EE-47A0-89FF-AB5C6FD4DAB4@mac.com> <20060518.145756.576039588.hyoshiok@miraclelinux.com> Message-ID: On 2006/05/18, at 15:08, Tomoyuki Asakawa wrote: > メールの例は、例としてわかりやすいかもしれないけれども、 > 実際は、メールは、表面的には、MUAだけの問題で解決できるの > で、単純な部類です。 現時点では，MUAだけで解決されるかは，最近は微妙かもしれません．という のは，MTAでUCS正規化方式を使って実装していた場合(MTAをJavaやC#で記述す るとか)の場合には，たぶん一旦Unicodeに変換してから処理します．この場 合，入力と出力を一致させていれば，基本的（怪しいか？）にはround trip conversionが保証されるとは思いますが，サポートされていない文字列は欠落 する可能性があります． ＃ 逆にUTF-8なら素通しでしょうけど（苦笑） ＃ そもそもUCS正規化なんかするから悪いという批判はあるでしょうが，ここ まで広まってしまうとCP932と同様に必要悪かと． > 問題は、メールに限らず、「それ」を格納し、「それ」を、取り出す時 > の問題 > どこに格納するかによって、「それ」が、変化してしまう。 それはたぶん吉岡さんの指摘した問題とは別だと思いますし，すでに私の草案 に盛り込まれているのではないかと． ただ，前のメールで指摘したのは，さらにそれを逆方向から見て考えた場合の ことで，ある（レガシーエンコーディングに基づく）内部格納形式がしっかり 決まっているのなら，それは他に(UTF-8でも)にも変換できることにもなるで しょうし，コンバータAPIを持つ場合は，他の提案と同様にコンバータを追加 するだけであるということです． ただし，私が先ほどのメールで指摘した問題はあるので，結局アプリケーショ ンにおまかせしないといけないかなあ…というわけです． --- 風間 一洋 (kazama ＠ mac.com) From tom ＠ asakawa.ne.jp Thu May 18 16:17:59 2006 From: tom ＠ asakawa.ne.jp (Tomoyuki Asakawa) Date: Thu, 18 May 2006 16:17:59 +0900 Subject: [LE-talk-ja 136] =?iso-2022-jp?b?UmU6IExFLXRhbGstamEgGyRCJEcbKEI=?= =?iso-2022-jp?b?GyRCJE41RE9AJE4kXiRIJGEbKEI=?= In-Reply-To: <20060518.154903.36935854.nozomi@biol.tsukuba.ac.jp> References: <20060516184928.894D.MORIYAMA@miraclelinux.com> <22441D30-61EE-47A0-89FF-AB5C6FD4DAB4@mac.com> <20060518.145756.576039588.hyoshiok@miraclelinux.com> <20060518.154903.36935854.nozomi@biol.tsukuba.ac.jp> Message-ID: <658FB29F-DEDE-4844-BED0-B984FE2CAA09@asakawa.ne.jp> あさかわ > 包摂文字かどうか指定する拡張というのもかつて考えてみたことは > あるのですが、アプリケーション依存 (そんなのマニアしか使 > わない > ともいう) になりそうなのでやめました。 マニアしか、意味がわからないかもしれないけど なんのことかわかってない、一般ピープルには、必要だから わかってるベンダーはそいうい機能があれば使うはずです。 既存コード（じつはレガシーという意識はない)から UNICODE との、変換で、異なる実装があるのは、事実です。 その、違いを、統一するにしても（無理だろけど） 統一させるには、既存のデータ資産を、統一型に、変換する必要があり ます。 そのためには、なんらかの方法で、そういう指定が必要なはずです。 また、異なる実装の間での、UNICODE - UNICODE の変換も必要な はずです。 nkfが、ある意味、そういうものに対する「現実解」を、用意してくれ てはいます。 iconvにも、同様なオプションがあればいいと思うのです。 From kazama ＠ mac.com Thu May 18 16:19:31 2006 From: kazama ＠ mac.com (Kazuhiro Kazama) Date: Thu, 18 May 2006 16:19:31 +0900 Subject: [LE-talk-ja 137] =?iso-2022-jp?b?UmU6IExFLXRhbGstamEgGyRCJEcbKEI=?= =?iso-2022-jp?b?GyRCJE41RE9AJE4kXiRIJGEbKEI=?= In-Reply-To: <20060518.154903.36935854.nozomi@biol.tsukuba.ac.jp> References: <20060516184928.894D.MORIYAMA@miraclelinux.com> <22441D30-61EE-47A0-89FF-AB5C6FD4DAB4@mac.com> <20060518.145756.576039588.hyoshiok@miraclelinux.com> <20060518.154903.36935854.nozomi@biol.tsukuba.ac.jp> Message-ID: <98A94D1F-5753-4A93-86D6-8B2DC63D78DB@mac.com> On 2006/05/18, at 15:49, Nozomi Ytow wrote: > よ> クライアントがcp932でPHPとMySQLで組んでいるシステムがあったとして > よ> MySQLとPHPがeuc-jpを使っていたとします。 > よ> それを運用している人が文字化けするからUTF-8に移行するかという話 > です。 > > cp932 には「はしご高」がある一方、euc-jp の高は「包摂高」なので > euc-jp には「はしご高」も「くち高」もあり得ない (あってる?)、 > だから cp932 と euc-jp は本当は共存できず、UTF-8 に移行した > ところで問題は厳密には解決しない。でも見た目それっぽいくらいなら > できる、というレベルの問題だと思っているのですが、違いますか。 たぶん，違うと思います． 吉岡さんが指摘しているのは，CP932<->EUC-JPをなんとかしようという話では なく，CP932<->CP51932(ないしはeucJP-ms)をコンバータを追加して可能にし ようという話で，Unicodeを中心としたピボット変換時にベンダ独自文字が欠 落する問題を解決しようということだと思います． この場合に共存するレガシーエンコーディングで動くシステムは，アルゴリズ ム変換によるサポートする文字レパートリの曖昧性で処理できると考えている と思います．ただし，この場合も厳密に言うと伊藤さんが指摘したような字体 の問題がありますが，ここで想定しているのはデータベースのように蓄積する が，そこで直接文字を表示するわけでないシステムを念頭に置いているので， 無視できるものとしていると理解しています． > eucJP-ms というのは名前としてはちょっとアレなのでいっそのこと > euc-CPナントカなどもっと直接的なものにしてはどうかと思いますが、 > UTF-8 に移行したところで解決しない問題なので、仮に移行コストを > 度外視しても「UTF-8 にすればいいじゃん」とは言えないよなぁと > 思っています。 確かに前から名前が気に入らないという話はあるんです（笑）が，すでに使わ れている文字符号化の名前を変えるのは大変で，結局昔の名前をエイリアスと しても持たざるをえないなんてことになりますから，名前に関しては目を瞑っ て使うしかないかなあと思っています． --- 風間 一洋 (kazama ＠ mac.com) From shinichiro ＠ stained-g.net Thu May 18 17:00:21 2006 From: shinichiro ＠ stained-g.net (Shinichiro HIDA) Date: Thu, 18 May 2006 17:00:21 +0900 Subject: [LE-talk-ja 138] =?iso-2022-jp?b?UmU6IBskQiUqJVUlaSUkJXMlXyE8GyhC?= =?iso-2022-jp?b?GyRCJUYlIyVzJTAkThsoQiobJEI4RD9NRSokShsoQiobJEI1RE9AGyhC?= =?iso-2022-jp?b?GyRCJE4kXiRIJGEbKEI=?= In-Reply-To: <20060518062703.GA18052%numata@jp.fujitsu.com> References: <20060516184928.894D.MORIYAMA@miraclelinux.com> <70DB9439-5AA0-42A2-B846-44B050ECF741@mac.com> <20060518005639.GA12382%numata@jp.fujitsu.com> <20060518062703.GA18052%numata@jp.fujitsu.com> Message-ID: <87k68joj8q.wl%shinichiro@stained-g.net> こんにちは、 飛田です。 >>>>> In <20060518062703.GA18052%numata ＠ jp.fujitsu.com> >>>>> NUMATA Toshinori wrote: > Kazuhiro Kazama wrote: [...] > > これ意外に，「ISO-2022-JP-1 や ISO-2022-JP-2は誰もつかってない/必要と > > してないよねえ」という状況が根底にあります． > 　これは，そうでしょうねえ． 以前(数年前に)テストしてみた所、Mozilla mail で、日本語にアクサン付きア ルファベットを混ぜたメールを書いて出すと ISO-2022-JP-2 で出るようです。 試しにこれを Debian + Emacs22 + Wanderlust から出してみますが、"つかっ てない/必要としてない" かどうかは私の知識レベルでは何とも言えませんが、 "扱える実装はなくはない" ということで。 à ma façon de Côte du Rhône.. ;; ちなみに、このメールを Debian Sarge(安定版) 上の Evolution, ;; Thunderbird あたりで表示可能な事は確かめました。 -- Shinichiro HIDA shinichiro ＠ stained-g.net GPG fingerprint = 5F2D 1656 FFF6 F691 A51C 5E61 E416 D398 470C 1CE9 From kazama ＠ mac.com Thu May 18 17:52:27 2006 From: kazama ＠ mac.com (Kazuhiro Kazama) Date: Thu, 18 May 2006 17:52:27 +0900 Subject: [LE-talk-ja 139] =?iso-2022-jp?b?UmU6IBskQiUqJVUlaSUkJXMlXyE8GyhC?= =?iso-2022-jp?b?GyRCJUYlIyVzJTAkThsoQiobJEI4RD9NRSokShsoQiobJEI1RE9AGyhC?= =?iso-2022-jp?b?GyRCJE4kXiRIJGEbKEI=?= In-Reply-To: <87k68joj8q.wl%shinichiro@stained-g.net> References: <20060516184928.894D.MORIYAMA@miraclelinux.com> <70DB9439-5AA0-42A2-B846-44B050ECF741@mac.com> <20060518005639.GA12382%numata@jp.fujitsu.com> <20060518062703.GA18052%numata@jp.fujitsu.com> <87k68joj8q.wl%shinichiro@stained-g.net> Message-ID: On 2006/05/18, at 17:00, Shinichiro HIDA wrote: >>> これ意外に，「ISO-2022-JP-1 や ISO-2022-JP-2は誰もつかってない/必 >>> 要と >>> してないよねえ」という状況が根底にあります． > >> 　これは，そうでしょうねえ． > > 以前(数年前に)テストしてみた所、Mozilla mail で、日本語にアクサン付 > きア > ルファベットを混ぜたメールを書いて出すと ISO-2022-JP-2 で出るようで > す。 おおっ！貴重なご指摘ありがとうございます． > 試しにこれを Debian + Emacs22 + Wanderlust から出してみますが、"つかっ > てない/必要としてない" かどうかは私の知識レベルでは何とも言えません > が、 > "扱える実装はなくはない" ということで。 > > A` ma fagon de Ctte du Rhtne.. 今，Mac OS Xで標準のMailを使ってJIS X 0212の文字を入れて出してみたとこ ろ，黙ってUTF-8で送信しました．また，Windows上のThunderbirdで同じこと をしてみたところ，UTF-8にするか？というようなダイアログが表示されまし た（←私は英語版をそのまま入れているので，もし日本語版の挙動が違うなん てことがあればご指摘ください）． ところが，サポートされている文字符号化を調べてみたところ，前者には ISO-2022-JP-2がありました！後者には，ISO-2022-JPしかないように見えます （←ちょっと謎）． ＃ そう言えば，実はJavaのISO-2022-JPの実装は，途中からISO-2022-JP-1に 変わっていた記憶があります． --- 風間 一洋 (kazama ＠ mac.com) From moriyama ＠ miraclelinux.com Thu May 18 18:56:33 2006 From: moriyama ＠ miraclelinux.com (MORIYAMA Masayuki) Date: Thu, 18 May 2006 18:56:33 +0900 (JST) Subject: [LE-talk-ja 140] =?iso-2022-jp?b?UmU6IBskQiUqJVUlaSUkJXMlXyE8GyhC?= =?iso-2022-jp?b?GyRCJUYlIyVzJTAkThsoQiobJEI4RD9NRSokShsoQiobJEI1RE9AGyhC?= =?iso-2022-jp?b?GyRCJE4kXiRIJGEbKEI=?= In-Reply-To: <20060518005639.GA12382%numata@jp.fujitsu.com> References: <70DB9439-5AA0-42A2-B846-44B050ECF741@mac.com> <20060518005639.GA12382%numata@jp.fujitsu.com> Message-ID: <20060518142621.897A.MORIYAMA@miraclelinux.com> 森山です。 NUMATA Toshinori wrote: > Kazuhiro Kazama wrote: > > 1, Shift_JIS, EUC-JP, ISO-2022-JP系列 > ... > > ・Unicodeからレガシーエンコーディングに戻す時の変換表に手 > > を加えて，文字化けをより広く回避するような対策もおこなわない（森 > > 山さんによると，この提案が却下された実例があるらしい）． > > 　これは: > > 「JIS X 0208 から Unicode に変換するときに， > 1区33点“波ダッシュ”を U+301C WAVE DASH に変換する処理系と， > U+FF5E FULLWIDTH TILDE に変換する処理系とが混在するので， > Unicode から JIS X 0208 に変換するときは，U+301C も U+FF5E も > 同じ1区33点に変換したい」 > > と提案したら，規格適合性の観点から(?)拒否された > > といった話ですよね． > (具体例でいわないとわかりにくいので．) libiconv 1.8 の cp932修正、eucJP-ms追加パッチを作成したときに、cp932→ ISO-2022-JP といった変換が出来るように、ISO-2022-JP で本来の U+301C WAVE DASH と cp932 で変換された U+FF5E FULLWIDTH TILDE の両方を JIS X 0208 1区33点に変換するように修正したのですが、その点が、どうもまずかっ たようで、結局パッチは取り込まれませんでした。 という話になります。 Shift_JIS、EUC-JP、ISO-2022-JP という名前で、JIS準拠として実装している ものは、下手にいじらない方が良いようです。 > > 3, eucJP-ms > ... > > ・シフトJIS符号化(不可能)，JIS符号化は考 > > えない． > > 　つまり，ISO-2022-JP-1 や ISO-2022-JP-2 のような JIS X 0212 を含む > ISO-2022-JP 系エンコーディングに CP932 の拡張文字を追加するような > ことは考えない，と． はい、そうです。 CP932 の文字レパートリーの変換が出来れば良いという考えです。 -- 森山 将之 moriyama ＠ miraclelinux.com ミラクル・リナックス株式会社 From moriyama ＠ miraclelinux.com Thu May 18 18:56:51 2006 From: moriyama ＠ miraclelinux.com (MORIYAMA Masayuki) Date: Thu, 18 May 2006 18:56:51 +0900 (JST) Subject: [LE-talk-ja 141] =?iso-2022-jp?b?UmU6IBskQiUqJVUlaSUkJXMlXyE8GyhC?= =?iso-2022-jp?b?GyRCJUYlIyVzJTAbKEIoMjAwNi8wNS8xNyk=?= In-Reply-To: <20060518.113459.48508403.mura@kansai.oki.co.jp> References: <20060518100415.895E.MORIYAMA@miraclelinux.com> <20060518.113459.48508403.mura@kansai.oki.co.jp> Message-ID: <20060518145517.897D.MORIYAMA@miraclelinux.com> 森山です。 Toshiki Murata wrote: > 今回の目的は３つの変換がうまくいくことをめざしていると思うのですが、 > 仮に「Windows系の変換表を用いる」ということが結論になった場合、 > 各OSS関連のツールは、これら３つのコードからUnicodeに変換するのは > 「Windows系の変換表を用いる」ことが事実上デファクトになってしまう > と思います。 > > とすると、議論のスコープ外かもしれませんが、 > Unicode への変換は今後日本としては「Windows系の変換表」を > 推奨するという感じになるのではと思います。 > > 一応、それがいいかどうかも議論したほうがいいのではというのが > ぼくの気になったことです。 > > この辺り、今どのような議論になっているのでしょうか。 現実問題として、JIS準拠の変換表に関しては、複数のバリエーションがある という事と、Windows の機種依存文字に関しては、JIS準拠の変換表では扱え ないので、「Windows系の変換表」を使うという事になります。 OSS の多くで Shift_JIS(sjis)、EUC-JP(euc,ujis)、ISO-2022-JP(jis) といっ た名前で、JIS準拠の変換表を使っていますが、こちらに関しては、今回を手 を加えませんので、JIS準拠の変換表を使った変換に影響が出るような事はあ りません。 -- 森山 将之 moriyama ＠ miraclelinux.com ミラクル・リナックス株式会社 From moriyama ＠ miraclelinux.com Thu May 18 18:57:00 2006 From: moriyama ＠ miraclelinux.com (MORIYAMA Masayuki) Date: Thu, 18 May 2006 18:57:00 +0900 (JST) Subject: [LE-talk-ja 142] =?iso-2022-jp?b?UmU6IExFLXRhbGstamEgGyRCJEcbKEI=?= =?iso-2022-jp?b?GyRCJE41RE9AJE4kXiRIJGEbKEI=?= In-Reply-To: <20060518.154903.36935854.nozomi@biol.tsukuba.ac.jp> References: <20060518.145756.576039588.hyoshiok@miraclelinux.com> <20060518.154903.36935854.nozomi@biol.tsukuba.ac.jp> Message-ID: <20060518165956.8980.MORIYAMA@miraclelinux.com> 森山です。 Nozomi Ytow wrote: > eucJP-ms というのは名前としてはちょっとアレなのでいっそのこと > euc-CPナントカなどもっと直接的なものにしてはどうかと思いますが、 > UTF-8 に移行したところで解決しない問題なので、仮に移行コストを > 度外視しても「UTF-8 にすればいいじゃん」とは言えないよなぁと > 思っています。 TOG/JVC(オープングループ/日本ベンダ協議会) で eucJP-ms という名前が使 用されていますので、それを使っています。 コード変換規則 > 1.Microsoft Windows 3.51 式の変換 http://www.opengroup.or.jp/jvc/cde/appendix.html -- 森山 将之 moriyama ＠ miraclelinux.com ミラクル・リナックス株式会社 From moriyama ＠ miraclelinux.com Thu May 18 18:57:17 2006 From: moriyama ＠ miraclelinux.com (MORIYAMA Masayuki) Date: Thu, 18 May 2006 18:57:17 +0900 (JST) Subject: [LE-talk-ja 143] =?iso-2022-jp?b?UmU6IBskQiUqJVUlaSUkJXMlXyE8GyhC?= =?iso-2022-jp?b?GyRCJUYlIyVzJTAkThsoQiobJEI4RD9NRSokShsoQiobJEI1RE9AGyhC?= =?iso-2022-jp?b?GyRCJE4kXiRIJGEbKEI=?= In-Reply-To: References: <87k68joj8q.wl%shinichiro@stained-g.net> Message-ID: <20060518180918.898B.MORIYAMA@miraclelinux.com> 森山です。 Kazuhiro Kazama wrote: > 今，Mac OS Xで標準のMailを使ってJIS X 0212の文字を入れて出してみたとこ > ろ，黙ってUTF-8で送信しました．また，Windows上のThunderbirdで同じこと > をしてみたところ，UTF-8にするか？というようなダイアログが表示されまし > た（←私は英語版をそのまま入れているので，もし日本語版の挙動が違うなん > てことがあればご指摘ください）． Thunderbird (Windows 版で確認) は、NEC特殊文字、NEC選定IBM拡張文字に関 しては、ISO-2022-JP で送信しますね。 草ナギ剛の「ナギ」だと、ISO-2022-JP で送信 森鴎外の「鴎」が [區鳥] だと、UTF-8 で送信 上記の2つの文字は、どちらも JIS X 0212 補助漢字で定義されている文字で す。 -- 森山 将之 moriyama ＠ miraclelinux.com ミラクル・リナックス株式会社 From tom ＠ asakawa.ne.jp Thu May 18 18:59:14 2006 From: tom ＠ asakawa.ne.jp (Tomoyuki Asakawa) Date: Thu, 18 May 2006 18:59:14 +0900 Subject: [LE-talk-ja 144] =?iso-2022-jp?b?UmU6IBskQiUqJVUlaSUkJXMlXyE8GyhC?= =?iso-2022-jp?b?GyRCJUYlIyVzJTAkThsoQiobJEI4RD9NRSokShsoQiobJEI1RE9AGyhC?= =?iso-2022-jp?b?GyRCJE4kXiRIJGEbKEI=?= In-Reply-To: References: <20060516184928.894D.MORIYAMA@miraclelinux.com> <70DB9439-5AA0-42A2-B846-44B050ECF741@mac.com> <20060518005639.GA12382%numata@jp.fujitsu.com> <20060518062703.GA18052%numata@jp.fujitsu.com> <87k68joj8q.wl%shinichiro@stained-g.net> Message-ID: あさかわ On 2006/05/18, at 17:52, Kazuhiro Kazama wrote: > 今，Mac OS Xで標準のMailを使ってJIS X 0212の > 文字を入れて出してみたとこ > ろ，黙ってUTF-8で送信しました． なんと！、クサナギをいれたら。CP932で出ました。 > また，Windows上のThunderbirdで同じこと > をしてみたところ，UTF-8にするか？というようなダイアログ > が表示されまし > た（←私は英語版をそのまま入れているので，もし日本語版の挙動が > 違うなん > てことがあればご指摘ください）． MAC版で、クサナギをいれたら、ISO-2022-JPで送りました。 なので、受信側でバケた。 From kazama ＠ mac.com Thu May 18 19:42:12 2006 From: kazama ＠ mac.com (Kazuhiro Kazama) Date: Thu, 18 May 2006 19:42:12 +0900 Subject: [LE-talk-ja 145] =?iso-2022-jp?b?UmU6IBskQiUqJVUlaSUkJXMlXyE8GyhC?= =?iso-2022-jp?b?GyRCJUYlIyVzJTAkThsoQiobJEI4RD9NRSokShsoQiobJEI1RE9AGyhC?= =?iso-2022-jp?b?GyRCJE4kXiRIJGEbKEI=?= In-Reply-To: References: <20060516184928.894D.MORIYAMA@miraclelinux.com> <70DB9439-5AA0-42A2-B846-44B050ECF741@mac.com> <20060518005639.GA12382%numata@jp.fujitsu.com> <20060518062703.GA18052%numata@jp.fujitsu.com> <87k68joj8q.wl%shinichiro@stained-g.net> Message-ID: <884D65C0-153D-4F2B-BA57-FF40424F252C@mac.com> On 2006/05/18, at 18:59, Tomoyuki Asakawa wrote: >> 今，Mac OS Xで標準のMailを使ってJIS X 0212の >> 文字を入れて出してみたとこ >> ろ，黙ってUTF-8で送信しました． > > なんと！、クサナギをいれたら。CP932で出ました。 これが昨日聞いていたCP932問題ですか（苦笑） これ，WindowsのOutlook Expressでは自動認識で回避してくれますが， Firefoxの日本語自動認識では残念ながら駄目のようです．というわけで，今 Apple Computerに問い合わせ中です． >> また，Windows上のThunderbirdで同じこと >> をしてみたところ，UTF-8にするか？というようなダイアログ >> が表示されまし >> た（←私は英語版をそのまま入れているので，もし日本語版の挙動が >> 違うなん >> てことがあればご指摘ください）． > > MAC版で、クサナギをいれたら、ISO-2022-JPで送りました。 > なので、受信側でバケた。 私はMacにはインストールしてないんですが，指定してくるcharsetはISO-2022- JPだけど実際の中身はISO-2022-JP-1か2って感じなんですかね． --- 風間 一洋 (kazama ＠ mac.com) From nozomi ＠ biol.tsukuba.ac.jp Thu May 18 20:22:24 2006 From: nozomi ＠ biol.tsukuba.ac.jp (Nozomi Ytow) Date: Thu, 18 May 2006 20:22:24 +0900 (JST) Subject: [LE-talk-ja 146] =?iso-2022-jp?b?UmU6IExFLXRhbGstamEgGyRCJEcbKEI=?= =?iso-2022-jp?b?GyRCJE41RE9AJE4kXiRIJGEbKEI=?= In-Reply-To: <20060518165956.8980.MORIYAMA@miraclelinux.com> References: <20060518.145756.576039588.hyoshiok@miraclelinux.com> <20060518.154903.36935854.nozomi@biol.tsukuba.ac.jp> <20060518165956.8980.MORIYAMA@miraclelinux.com> Message-ID: <20060518.202224.18290788.nozomi@biol.tsukuba.ac.jp> MORIYAMA Masayuki wrote: > TOG/JVC(オープングループ/日本ベンダ協議会) で eucJP-ms という名前が使 > 用されていますので、それを使っています。 了解。で、ISO-2022-JP-MS の方は...ISO-2022-CP932 じゃだめですか。 たかが名前ではあるのですが。 -- 伊藤　希 (のぞみ) From naruse ＠ airemix.com Thu May 18 21:34:58 2006 From: naruse ＠ airemix.com (NARUSE, Yui) Date: Thu, 18 May 2006 21:34:58 +0900 Subject: [LE-talk-ja 147] =?iso-2022-jp?b?UmU6IBskQiUqJVUlaSUkJXMlXyE8GyhC?= =?iso-2022-jp?b?GyRCJUYlIyVzJTAbKEIoMjAwNi8wNS8xNyk=?= In-Reply-To: <20060502191137.E9C4.MORIYAMA@miraclelinux.com> References: <20060502191137.E9C4.MORIYAMA@miraclelinux.com> Message-ID: <446C69F2.8040903@airemix.com> 成瀬です。 昨日はおつかれさまでした。 とりあえず、昨日の会と今日のメール群を見て、 このプロジェクトの方向性について、 概要なりなんなりに追記する必要があると考えました。 勝手にWikiに追記しようとも思ったのですが、 とりあえずWikiにFAQという項を作っておきました。 http://legacy-encoding.sourceforge.jp/wiki/index.php?FAQ 途中からこのMLを読んでいる方に、 MLのログを全て読んでもらうのはつらいと思われるので、 FAQを最初に読めば一通りの流れがわかるようにするとよいかな、と。 ところで、わたしの解釈で、「このプロジェクトの意義」案。 「Legacy Encoding Project」とは、そもそも、 レガシーエンコーディングを混乱なくフェードアウトさせようというもの。 （ミーディングでの乾杯の時に言われていた通り、 　「レガシーエンコーディングの更なる発展と繁栄を祈る」 　ものではないと、笑。） これを実現する手段として、[LE-talk-ja 118]にも挙げられている、 > Windows Codepage 932 で使用可能な文字を Unicode 経由で、日本語EUC > 符号化方式、7ビットJIS(ISO-2022-JP)符号化方式に変換できるようにする。 これが手段となる前提として以下がある。 * レガシーエンコーディングはJIS系、SJIS系、EUC系の三つ * 今時の文字コード変換はUnicodeによるUCS正規化で行われる * よって「キャラクタセット」とはUnicodeとの変換表のこと * 既に"ISO-2022-JP", "Shift_JIS", "EUC-JP"といった名前の変換表は、 　各OSSが提供しているが、独自の変更が加えられていて、変更できない。 * 変換表のデファクトとしてWindows系のものがある。 以上のような事情から、 変換表の名前（キャラクタセット名）は既存のものを使えない ∵既存のものは別の変換表を指しているから →別の名前を定義する必要がある →かと言って全く新しいものを定義するのは混乱を助長する →CP932, CP51932, eucJP-ms, CP50221 　（CP*の典拠はMicrosoftの実装、eucJP-msはTOG/JVC） -- NARUSE, Yui DBDB A476 FDBD 9450 02CD 0EFC BCE3 C388 472E C1EA From naruse ＠ airemix.com Fri May 19 01:59:26 2006 From: naruse ＠ airemix.com (NARUSE, Yui) Date: Fri, 19 May 2006 01:59:26 +0900 Subject: [LE-talk-ja 148] =?iso-2022-jp?b?UmU6IExFLXRhbGstamEgGyRCJEcbKEI=?= =?iso-2022-jp?b?GyRCJE41RE9AJE4kXiRIJGEbKEI=?= In-Reply-To: <658FB29F-DEDE-4844-BED0-B984FE2CAA09@asakawa.ne.jp> References: <20060516184928.894D.MORIYAMA@miraclelinux.com> <22441D30-61EE-47A0-89FF-AB5C6FD4DAB4@mac.com> <20060518.145756.576039588.hyoshiok@miraclelinux.com> <20060518.154903.36935854.nozomi@biol.tsukuba.ac.jp> <658FB29F-DEDE-4844-BED0-B984FE2CAA09@asakawa.ne.jp> Message-ID: <446CA7EE.6050501@airemix.com> 成瀬です。 Tomoyuki Asakawa wrote: > あさかわ > >> 包摂文字かどうか指定する拡張というのもかつて考えてみたことは >> あるのですが、アプリケーション依存 (そんなのマニアしか使 >> わない >> ともいう) になりそうなのでやめました。 > > マニアしか、意味がわからないかもしれないけど > なんのことかわかってない、一般ピープルには、必要だから > わかってるベンダーはそいうい機能があれば使うはずです。 > > 既存コード（じつはレガシーという意識はない)から UNICODE > との、変換で、異なる実装があるのは、事実です。 > > その、違いを、統一するにしても（無理だろけど） > 統一させるには、既存のデータ資産を、統一型に、変換する必要があり > ます。 > そのためには、なんらかの方法で、そういう指定が必要なはずです。 > > また、異なる実装の間での、UNICODE - UNICODE の変換も必要な > はずです。 > > nkfが、ある意味、そういうものに対する「現実解」を、用意してくれ > てはいます。 > > iconvにも、同様なオプションがあればいいと思うのです。 iconv はそのような処理を提供するためのプログラムでは無いように感じます。 例えば改行コードの変換は、iconvは提供していませんしね。 # 提供している実装もありますけれど それは iconv 以外の何かが行うべきでしょう。 ICUで言えば、それは iconv に相当する UConverter でなく、 Transforms の管轄ですし。 http://icu.sourceforge.net/userguide/Transform.html ところで蛇足ですが、メイリオでは U+301C (Wave Dash) は、 U+FF5E (Fullwidth Tilde) と同じグリフになっているんですね。 -- NARUSE, Yui DBDB A476 FDBD 9450 02CD 0EFC BCE3 C388 472E C1EA From nozomi ＠ biol.tsukuba.ac.jp Fri May 19 02:30:50 2006 From: nozomi ＠ biol.tsukuba.ac.jp (Nozomi Ytow) Date: Fri, 19 May 2006 02:30:50 +0900 (JST) Subject: [LE-talk-ja 149] =?iso-2022-jp?b?UmU6IExFLXRhbGstamEgGyRCJEcbKEI=?= =?iso-2022-jp?b?GyRCJE41RE9AJE4kXiRIJGEbKEI=?= In-Reply-To: <658FB29F-DEDE-4844-BED0-B984FE2CAA09@asakawa.ne.jp> References: <20060518.145756.576039588.hyoshiok@miraclelinux.com> <20060518.154903.36935854.nozomi@biol.tsukuba.ac.jp> <658FB29F-DEDE-4844-BED0-B984FE2CAA09@asakawa.ne.jp> Message-ID: <20060519.023050.89026298.nozomi@biol.tsukuba.ac.jp> Tomoyuki Asakawa wrote: > マニアしか、意味がわからないかもしれないけど > なんのことかわかってない、一般ピープルには、必要だから > わかってるベンダーはそいうい機能があれば使うはずです。 今回の案での重複定義文字の変換で variation selector (VS) を 内部的に使うと trip around も実現できますが、VS に関する規定 からは逸脱しています。 > iconvにも、同様なオプションがあればいいと思うのです。 VS で実装できそうな気がします。 もとからある VS か内部的に挿入した VS かというのが 問題になりそうではありますが... -- 伊藤　希 (のぞみ) From nozomi ＠ biol.tsukuba.ac.jp Fri May 19 02:40:22 2006 From: nozomi ＠ biol.tsukuba.ac.jp (Nozomi Ytow) Date: Fri, 19 May 2006 02:40:22 +0900 (JST) Subject: [LE-talk-ja 150] =?iso-2022-jp?b?UmU6IExFLXRhbGstamEgGyRCJEcbKEI=?= =?iso-2022-jp?b?GyRCJE41RE9AJE4kXiRIJGEbKEI=?= In-Reply-To: <98A94D1F-5753-4A93-86D6-8B2DC63D78DB@mac.com> References: <20060518.145756.576039588.hyoshiok@miraclelinux.com> <20060518.154903.36935854.nozomi@biol.tsukuba.ac.jp> <98A94D1F-5753-4A93-86D6-8B2DC63D78DB@mac.com> Message-ID: <20060519.024022.38311271.nozomi@biol.tsukuba.ac.jp> > CP932<->CP51932(ないしはeucJP-ms)をコンバータを追加して > 可能にしようという話で，Unicodeを中心としたピボット変換時に > ベンダ独自文字が欠 落する問題を解決しようということだと思います． うーん、それなら、内部的にでも variant selector 使わずに 重複定義文字を unify して round trip 保証しないというのが なにをしたいのかよくわからんのですが... > ただし，この場合も厳密に言うと伊藤さんが指摘したような字体の > 問題がありますが，ここで想定しているのはデータベースのように > 蓄積する が，そこで直接文字を表示するわけでないシステムを > 念頭に置いているので，無視できるものとしていると理解しています． 字体の問題と言い切れるのかどうか、私には確信が持てません。 「はしご高」と「くち高」は包摂する立場からするとグリフの 問題ですが、文字としての「包摂高」は字体非依存なので、 グリフの問題ではない気がします。 ま、そこまで神経使ってデータ作ってないでしょふつー、 とは思いますが、「くち高」を含む文字集合を符号化する体系で 文字列に「くち高」のコードが現れた時、それが本当に「くち高」 なのかそれとも「包摂高」なのかはわからないと思います。 -- 伊藤　希 (のぞみ) From tom ＠ asakawa.ne.jp Fri May 19 05:21:20 2006 From: tom ＠ asakawa.ne.jp (Tomoyuki Asakawa) Date: Fri, 19 May 2006 05:21:20 +0900 Subject: [LE-talk-ja 151] =?iso-2022-jp?b?UmU6IExFLXRhbGstamEgGyRCJEcbKEI=?= =?iso-2022-jp?b?GyRCJE41RE9AJE4kXiRIJGEbKEI=?= In-Reply-To: <446CA7EE.6050501@airemix.com> References: <20060516184928.894D.MORIYAMA@miraclelinux.com> <22441D30-61EE-47A0-89FF-AB5C6FD4DAB4@mac.com> <20060518.145756.576039588.hyoshiok@miraclelinux.com> <20060518.154903.36935854.nozomi@biol.tsukuba.ac.jp> <658FB29F-DEDE-4844-BED0-B984FE2CAA09@asakawa.ne.jp> <446CA7EE.6050501@airemix.com> Message-ID: <936F52DE-7510-45DE-9174-A426CCBEC3EF@asakawa.ne.jp> あさかわ > iconv はそのような処理を提供するためのプログラムでは無いように > 感じます。 iconvを、コード変換アプリケーションとしてみた場合のことでしょう？ > 例えば改行コードの変換は、iconvは提供していませんしね。 > # 提供している実装もありますけれど 改行コードとコード変換は、別の次元です。 異なる環境への、変換コマンドとしてなら必須でしょうけど。 > それは iconv 以外の何かが行うべきでしょう。 iconvは、APIのレイヤ(libiconv)としての、存在でもあり ます。 この時、APIとしては、柔軟な仕様がもとめられるとおもいます。 標準的な変換は、APIを使い、非標準になったとたんに、たった 数文字の対応表の違い の為に、まったく別のものを書かないとならないなんてのは、ナンセン スだと思うのです。 そういう意味では、WindowsのAPIも酷い。 > ICUで言えば、それは iconv に相当する UConverter で > なく、 > Transforms の管轄ですし。 > http://icu.sourceforge.net/userguide/Transform.html いやー、このレイヤでするというのも違う気がする。 もう一つ下ですよ。やはり。 でも、日本以外では（日本でも）理解されないのだから このレイヤでするしかないかもしれませんね。 でも、できないよりできるならICUになればすばらしいかも ただ、ICUの基本のレベルで、そんなコードに対応する物は無い！ と、やられてしまったらやはり、別の変換を書く必要になってしまう。 IBMが作ってるからそんなことはないと期待したいが。。。。 （IBM自身がそういうニーズに直面してるはず) From tom ＠ asakawa.ne.jp Fri May 19 05:38:25 2006 From: tom ＠ asakawa.ne.jp (Tomoyuki Asakawa) Date: Fri, 19 May 2006 05:38:25 +0900 Subject: [LE-talk-ja 152] =?iso-2022-jp?b?UmU6IBskQiUqJVUlaSUkJXMlXyE8GyhC?= =?iso-2022-jp?b?GyRCJUYlIyVzJTAbKEIoMjAwNi8wNS8xNyk=?= In-Reply-To: <446C69F2.8040903@airemix.com> References: <20060502191137.E9C4.MORIYAMA@miraclelinux.com> <446C69F2.8040903@airemix.com> Message-ID: あさかわ > ところで、わたしの解釈で、「このプロジェクトの意義」案。 > > 「Legacy Encoding Project」とは、そもそも、 > レガシーエンコーディングを混乱なくフェードアウトさせようという > もの。 > > （ミーディングでの乾杯の時に言われていた通り、 > 　「レガシーエンコーディングの更なる発展と繁栄を祈る」 > 　ものではないと、笑。） 「でも、２０年後も無理だよねえ」と、その後に続いた様に無理なんだ から。 わたしは 「Legacy Encoding Project」とは、そもそも、レガシーエン コーディングで、死ぬまで苦労しない為 だとおもってます。 その為にも、汎用コード変換が必要だと思うのです。 期待するユニコードにロストなく変換できれば レガシーデータのユニコード化は加速すると思うのです しかし、制限する理想論では、レガシーデータは、変換されずに そのまま蓄積されて、フェードアウトどころか、そのデータを処理する プログラムとの互換の為に、新規のデータまで、レガシーコードで作成 されて 逆に、レガシーデータが増殖します。 From tom ＠ asakawa.ne.jp Fri May 19 05:38:59 2006 From: tom ＠ asakawa.ne.jp (Tomoyuki Asakawa) Date: Fri, 19 May 2006 05:38:59 +0900 Subject: [LE-talk-ja 153] =?iso-2022-jp?b?UmU6IExFLXRhbGstamEgGyRCJEcbKEI=?= =?iso-2022-jp?b?GyRCJE41RE9AJE4kXiRIJGEbKEI=?= In-Reply-To: <20060518.202224.18290788.nozomi@biol.tsukuba.ac.jp> References: <20060518.145756.576039588.hyoshiok@miraclelinux.com> <20060518.154903.36935854.nozomi@biol.tsukuba.ac.jp> <20060518165956.8980.MORIYAMA@miraclelinux.com> <20060518.202224.18290788.nozomi@biol.tsukuba.ac.jp> Message-ID: あさかわ On 2006/05/18, at 20:22, Nozomi Ytow wrote: > 了解。で、ISO-2022-JP-MS の方は...ISO-2022-CP932 > じゃだめですか。 > たかが名前ではあるのですが。 たしかに、まだこの方がいいと思う。 From tom ＠ asakawa.ne.jp Fri May 19 05:49:02 2006 From: tom ＠ asakawa.ne.jp (Tomoyuki Asakawa) Date: Fri, 19 May 2006 05:49:02 +0900 Subject: [LE-talk-ja 154] =?iso-2022-jp?b?UmU6IExFLXRhbGstamEgGyRCJEcbKEI=?= =?iso-2022-jp?b?GyRCJE41RE9AJE4kXiRIJGEbKEI=?= In-Reply-To: References: <20060518.145756.576039588.hyoshiok@miraclelinux.com> <20060518.154903.36935854.nozomi@biol.tsukuba.ac.jp> <20060518165956.8980.MORIYAMA@miraclelinux.com> <20060518.202224.18290788.nozomi@biol.tsukuba.ac.jp> Message-ID: あさかわ On 2006/05/19, at 5:38, Tomoyuki Asakawa wrote: >> 了解。で、ISO-2022-JP-MS の方は...ISO-2022-CP932 >> じゃだめですか。 >> たかが名前ではあるのですが。 > > たしかに、まだこの方がいいと思う。 ところで、森山さん。 わたし、しゃべりすぎて、聞くのわすれてました。 汎用派の私としては、あらたな変換テーブルの必要性は理解するのですが JIS系の変換テーブルの必要性がわかりません これは、生エスケープでいいじゃんという意味ではなくです。 Windowsが、SJIS系 <-> UNICODE の変換が充実していれば、EUC系やJIS系の変換なんてどう でもいいのと同じく UNIX系は、EUC系 <-> UNICODE の変換が充実していればいいはず。 最近は、UNIX系で作成された、OSSが,Windowsでも 動作するので OSS系は、EUC系 <-> UNICODE <-> SJIS系 の変換が充実していればいい。 なので、JIS系の変換ってメールぐらいにしか、必要性ないので は？ あっ、だから、風間さんが、メールを持ち出して否定するのか？ From naruse ＠ airemix.com Fri May 19 06:14:39 2006 From: naruse ＠ airemix.com (NARUSE, Yui) Date: Fri, 19 May 2006 06:14:39 +0900 Subject: [LE-talk-ja 155] =?iso-2022-jp?b?UmU6IExFLXRhbGstamEgGyRCJEcbKEI=?= =?iso-2022-jp?b?GyRCJE41RE9AJE4kXiRIJGEbKEI=?= In-Reply-To: <936F52DE-7510-45DE-9174-A426CCBEC3EF@asakawa.ne.jp> References: <20060516184928.894D.MORIYAMA@miraclelinux.com> <22441D30-61EE-47A0-89FF-AB5C6FD4DAB4@mac.com> <20060518.145756.576039588.hyoshiok@miraclelinux.com> <20060518.154903.36935854.nozomi@biol.tsukuba.ac.jp> <658FB29F-DEDE-4844-BED0-B984FE2CAA09@asakawa.ne.jp> <446CA7EE.6050501@airemix.com> <936F52DE-7510-45DE-9174-A426CCBEC3EF@asakawa.ne.jp> Message-ID: <446CE3BF.2050704@airemix.com> 成瀬です。 Tomoyuki Asakawa wrote: >> iconv はそのような処理を提供するためのプログラムでは無いように >> 感じます。 > iconvを、コード変換アプリケーションとしてみた場合のことでしょう？ 違います。 >> 例えば改行コードの変換は、iconvは提供していませんしね。 >> # 提供している実装もありますけれど > > 改行コードとコード変換は、別の次元です。 > 異なる環境への、変換コマンドとしてなら必須でしょうけど。 ずれているのは承知ですが、全く異なるとは考えません。 SJIS(CR) -> SJIS(LF)のように、 * 同じ文字コード * しかし実際に用いる文字集合が異なる という点で同じ問題と考えます。 >> それは iconv 以外の何かが行うべきでしょう。 > > iconvは、APIのレイヤ(libiconv)としての、存在でもあり > ます。 > この時、APIとしては、柔軟な仕様がもとめられるとおもいます。 iconv_t iconv_open(const char *tocode, const char *fromcode); size_t iconv(iconv_t cd, char **inbuf, size_t *inbytesleft, char **outbuf, size_t *outbytesleft); int iconv_close(iconv_t cd); という関数群が、およそそのような柔軟な存在になりうるとは考えられません。 そのようなiconvが存在したとしたら、 それはiconvでは無い可能性のほうが高いでしょう。 > 標準的な変換は、APIを使い、非標準になったとたんに、たった > 数文字の対応表の違い > の為に、まったく別のものを書かないとならないなんてのは、ナンセン > スだと思うのです。 > > そういう意味では、WindowsのAPIも酷い。 標準なAPIを使った後、正規化のAPIを用いることになるかと思います。 >> ICUで言えば、それは iconv に相当する UConverter で >> なく、 >> Transforms の管轄ですし。 >> http://icu.sourceforge.net/userguide/Transform.html > > いやー、このレイヤでするというのも違う気がする。 > もう一つ下ですよ。やはり。 SJIS->Unicodeを念頭に置けば、 iconvレイヤーでという考えになるのかもしれませんが、 Unicode->Unicodeで用いる文字を変えると考えれば、 それは文字コード変換というより正規化の領域だと考えます。 > でも、日本以外では（日本でも）理解されないのだから > このレイヤでするしかないかもしれませんね。 > > でも、できないよりできるならICUになればすばらしいかも > > ただ、ICUの基本のレベルで、そんなコードに対応する物は無い！ > と、やられてしまったらやはり、別の変換を書く必要になってしまう。 > > IBMが作ってるからそんなことはないと期待したいが。。。。 > （IBM自身がそういうニーズに直面してるはず) Transform Rule をちょろちょろと書けば言いだけの話に感じます。 極端な話、s/\x{301C}/\x{FF5E}/gすればいいことですしね。 -- NARUSE, Yui DBDB A476 FDBD 9450 02CD 0EFC BCE3 C388 472E C1EA From tom ＠ asakawa.ne.jp Fri May 19 06:35:18 2006 From: tom ＠ asakawa.ne.jp (Tomoyuki Asakawa) Date: Fri, 19 May 2006 06:35:18 +0900 Subject: [LE-talk-ja 156] =?iso-2022-jp?b?UmU6IExFLXRhbGstamEgGyRCJEcbKEI=?= =?iso-2022-jp?b?GyRCJE41RE9AJE4kXiRIJGEbKEI=?= In-Reply-To: <446CE3BF.2050704@airemix.com> References: <20060516184928.894D.MORIYAMA@miraclelinux.com> <22441D30-61EE-47A0-89FF-AB5C6FD4DAB4@mac.com> <20060518.145756.576039588.hyoshiok@miraclelinux.com> <20060518.154903.36935854.nozomi@biol.tsukuba.ac.jp> <658FB29F-DEDE-4844-BED0-B984FE2CAA09@asakawa.ne.jp> <446CA7EE.6050501@airemix.com> <936F52DE-7510-45DE-9174-A426CCBEC3EF@asakawa.ne.jp> <446CE3BF.2050704@airemix.com> Message-ID: <896E5377-ADC8-497D-A669-F07A6C6DBBE8@asakawa.ne.jp> あさかわ >> 改行コードとコード変換は、別の次元です。 >> 異なる環境への、変換コマンドとしてなら必須でしょうけど。 > ずれているのは承知ですが、全く異なるとは考えません。 > SJIS(CR) -> SJIS(LF)のように、 > * 同じ文字コード > * しかし実際に用いる文字集合が異なる > という点で同じ問題と考えます。 SJIS(CR) -> SJIS(LF) と言った場合、 MAC系SJIS -> UNIX系SJIS という様に、単純に字集合が決まるわけではないです。 なので、区別して考えるべきだよ。 CRとCRLF,LFなどの改行の変換は、 SJIS系、EUC系、SJIS系、UNICODE系 にかわらず。等しく存在します。 同じSJIS系でも ピュアSJIS <-> CP932 など、異なるSJIS系間の変換は必要だが この時点では、改行コードの変換が必要かどうかは 場合によってことなる。 すくなくとも、同一環境上では、通常改行の変換は必要ない 改行の変換が必要なのは、異なる環境との交換の時だけです。 UNIXから WINDOWSという変換のとき EUC(LF) -> SJIS(CRLF) と、セットで切り替えると便利なのは確かですが UNIX上で、ハンドリングする場合には、 EUC(LF) -> SJIS(LF) の方がいいに決まってる。 なので、改行コードは次元が違う。 From tom ＠ asakawa.ne.jp Fri May 19 06:47:58 2006 From: tom ＠ asakawa.ne.jp (Tomoyuki Asakawa) Date: Fri, 19 May 2006 06:47:58 +0900 Subject: [LE-talk-ja 157] =?iso-2022-jp?b?UmU6IExFLXRhbGstamEgGyRCJEcbKEI=?= =?iso-2022-jp?b?GyRCJE41RE9AJE4kXiRIJGEbKEI=?= In-Reply-To: <446CE3BF.2050704@airemix.com> References: <20060516184928.894D.MORIYAMA@miraclelinux.com> <22441D30-61EE-47A0-89FF-AB5C6FD4DAB4@mac.com> <20060518.145756.576039588.hyoshiok@miraclelinux.com> <20060518.154903.36935854.nozomi@biol.tsukuba.ac.jp> <658FB29F-DEDE-4844-BED0-B984FE2CAA09@asakawa.ne.jp> <446CA7EE.6050501@airemix.com> <936F52DE-7510-45DE-9174-A426CCBEC3EF@asakawa.ne.jp> <446CE3BF.2050704@airemix.com> Message-ID: <59593A24-A0A2-4644-B3CE-27F45EB6F2CC@asakawa.ne.jp> あさかわ >> そういう意味では、WindowsのAPIも酷い。 > > 標準なAPIを使った後、正規化のAPIを用いることになる > かと思います。 標準APIでカバーしてない文字は、捨てられてしまうので。その あとでは、正規化不能です。 > > Transform Rule をちょろちょろと書けば言いだけの話に感じます。 > 極端な話、s/\x{301C}/\x{FF5E}/gすればいいことですしね。 いや、そこへ来る前にすてられたらなにもできないのよ。 euc-jp-ms -> CP932で、X0212文字は捨てられる。 すてられたら、ルール書こうにもかけないでしょ。 ただし、Transform Ruleが、入力側に働けば別ですけどね。 この手の実装って、出力しかかんがえてないのではありませんか？ 入力したら、すでに内部はUNICODEでしょ。 入力に働けば euc-jp-ms上のX0212文字のうち、使用してるものだけ X0208エリアの未使用領域に振り分けて、読み込む 出力する時に、CP932上の外字領域に、再度変換する。 なんてことができる。 From naruse ＠ airemix.com Fri May 19 08:04:22 2006 From: naruse ＠ airemix.com (NARUSE, Yui) Date: Fri, 19 May 2006 08:04:22 +0900 Subject: [LE-talk-ja 158] =?iso-2022-jp?b?UmU6IExFLXRhbGstamEgGyRCJEcbKEI=?= =?iso-2022-jp?b?GyRCJE41RE9AJE4kXiRIJGEbKEI=?= In-Reply-To: <896E5377-ADC8-497D-A669-F07A6C6DBBE8@asakawa.ne.jp> References: <20060516184928.894D.MORIYAMA@miraclelinux.com> <22441D30-61EE-47A0-89FF-AB5C6FD4DAB4@mac.com> <20060518.145756.576039588.hyoshiok@miraclelinux.com> <20060518.154903.36935854.nozomi@biol.tsukuba.ac.jp> <658FB29F-DEDE-4844-BED0-B984FE2CAA09@asakawa.ne.jp> <446CA7EE.6050501@airemix.com> <936F52DE-7510-45DE-9174-A426CCBEC3EF@asakawa.ne.jp> <446CE3BF.2050704@airemix.com> <896E5377-ADC8-497D-A669-F07A6C6DBBE8@asakawa.ne.jp> Message-ID: <446CFD76.1050601@airemix.com> 成瀬です。 Tomoyuki Asakawa wrote: > SJIS(CR) -> SJIS(LF) > と言った場合、 > MAC系SJIS -> UNIX系SJIS > という様に、単純に字集合が決まるわけではないです。 相違点を探すのでなく、共通点を探して欲しいです。 相違点が大きいのは承知ですので。 もっとも、¬や∵も検討に入れると、 色々味わい深い例えにしてたりもするんですが。 > CRとCRLF,LFなどの改行の変換は、 > （略） > この時点では、改行コードの変換が必要かどうかは > 場合によってことなる。 > > すくなくとも、同一環境上では、通常改行の変換は必要ない > 改行の変換が必要なのは、異なる環境との交換の時だけです。 > > UNIXから WINDOWSという変換のとき > EUC(LF) -> SJIS(CRLF) > と、セットで切り替えると便利なのは確かですが > > UNIX上で、ハンドリングする場合には、 > EUC(LF) -> SJIS(LF) > の方がいいに決まってる。 > > なので、改行コードは次元が違う。 デフォルトでは改行コードはいじらず、必要なら別途、LF->CRLF変換する。 セットでCRLF変換できれば便利だろうけど。 デフォルトでは \x81\x60 -> U+FF5E、必要なら別途U+301Cに。 セットで変換できれば便利だろうけど。 共通項はありますよね。 -- NARUSE, Yui DBDB A476 FDBD 9450 02CD 0EFC BCE3 C388 472E C1EA From tom ＠ asakawa.ne.jp Fri May 19 08:17:03 2006 From: tom ＠ asakawa.ne.jp (Tomoyuki Asakawa) Date: Fri, 19 May 2006 08:17:03 +0900 Subject: [LE-talk-ja 159] =?iso-2022-jp?b?UmU6IExFLXRhbGstamEgGyRCJEcbKEI=?= =?iso-2022-jp?b?GyRCJE41RE9AJE4kXiRIJGEbKEI=?= In-Reply-To: <446CFD76.1050601@airemix.com> References: <20060516184928.894D.MORIYAMA@miraclelinux.com> <22441D30-61EE-47A0-89FF-AB5C6FD4DAB4@mac.com> <20060518.145756.576039588.hyoshiok@miraclelinux.com> <20060518.154903.36935854.nozomi@biol.tsukuba.ac.jp> <658FB29F-DEDE-4844-BED0-B984FE2CAA09@asakawa.ne.jp> <446CA7EE.6050501@airemix.com> <936F52DE-7510-45DE-9174-A426CCBEC3EF@asakawa.ne.jp> <446CE3BF.2050704@airemix.com> <896E5377-ADC8-497D-A669-F07A6C6DBBE8@asakawa.ne.jp> <446CFD76.1050601@airemix.com> Message-ID: あさかわ On 2006/05/19, at 8:04, NARUSE, Yui wrote: > 共通項はありますよね。 わたしの説明がわるかった。 制御コードと文字コードなので、別次元です。 用途として、一緒の方が便利な場合もあるでしょうけども 明確に別次元と言えるものを、一緒にあつかうベキではないと思う。 組み合わせを増やすだけ。 逆に、SJISとCP932なんか、わけるから、組み合わせが増 える。 From naruse ＠ airemix.com Fri May 19 08:21:26 2006 From: naruse ＠ airemix.com (NARUSE, Yui) Date: Fri, 19 May 2006 08:21:26 +0900 Subject: [LE-talk-ja 160] =?iso-2022-jp?b?UmU6IExFLXRhbGstamEgGyRCJEcbKEI=?= =?iso-2022-jp?b?GyRCJE41RE9AJE4kXiRIJGEbKEI=?= In-Reply-To: <59593A24-A0A2-4644-B3CE-27F45EB6F2CC@asakawa.ne.jp> References: <20060516184928.894D.MORIYAMA@miraclelinux.com> <22441D30-61EE-47A0-89FF-AB5C6FD4DAB4@mac.com> <20060518.145756.576039588.hyoshiok@miraclelinux.com> <20060518.154903.36935854.nozomi@biol.tsukuba.ac.jp> <658FB29F-DEDE-4844-BED0-B984FE2CAA09@asakawa.ne.jp> <446CA7EE.6050501@airemix.com> <936F52DE-7510-45DE-9174-A426CCBEC3EF@asakawa.ne.jp> <446CE3BF.2050704@airemix.com> <59593A24-A0A2-4644-B3CE-27F45EB6F2CC@asakawa.ne.jp> Message-ID: <446D0176.7030003@airemix.com> 成瀬です。 Tomoyuki Asakawa wrote: > あさかわ > >>> そういう意味では、WindowsのAPIも酷い。 >> 標準なAPIを使った後、正規化のAPIを用いることになる >> かと思います。 > > 標準APIでカバーしてない文字は、捨てられてしまうので。その > あとでは、正規化不能です。 CP932→Unicodeに関して言えば、カバーしていない文字は存在しないはずです。 >> Transform Rule をちょろちょろと書けば言いだけの話に感じます。 >> 極端な話、s/\x{301C}/\x{FF5E}/gすればいいことですしね。 > > いや、そこへ来る前にすてられたらなにもできないのよ。 > > euc-jp-ms -> CP932で、X0212文字は捨てられる。 > すてられたら、ルール書こうにもかけないでしょ。 euc-jp-ms -> CP932 という変換それ自体が行うべきでない変換ですが、 さておき、その変換は正確ではないです。 eucJP-ms -> Unicode -> CP932 のはずでしょう。 > ただし、Transform Ruleが、入力側に働けば別ですけどね。 > この手の実装って、出力しかかんがえてないのではありませんか？ > 入力したら、すでに内部はUNICODEでしょ。 > > 入力に働けば > euc-jp-ms上のX0212文字のうち、使用してるものだけ > X0208エリアの未使用領域に振り分けて、読み込む > 出力する時に、CP932上の外字領域に、再度変換する。 > なんてことができる。 Legacy Encoding -> Unicode では多対一変換は行われないので、 再変換は常に可能なはずです。 なお、legacy to legacyを一度に行うとfallbackができないというのは、 PerlのEncodeモジュールのfrom_to実装とかもそうですね。 Jcode.pmメーリングリストの [Jcode5 786] Re: Encodeの CHECK関係について も同じ問題だと思いますが、 UnicodeによるUCS正規化が行われている文字コード変換においては、 legacy to legacy は decode & encode なので。 -- NARUSE, Yui DBDB A476 FDBD 9450 02CD 0EFC BCE3 C388 472E C1EA From nozomi ＠ biol.tsukuba.ac.jp Fri May 19 08:28:56 2006 From: nozomi ＠ biol.tsukuba.ac.jp (Nozomi Ytow) Date: Fri, 19 May 2006 08:28:56 +0900 (JST) Subject: [LE-talk-ja 161] =?iso-2022-jp?b?UmU6IExFLXRhbGstamEgGyRCJEcbKEI=?= =?iso-2022-jp?b?GyRCJE41RE9AJE4kXiRIJGEbKEI=?= In-Reply-To: <446D0176.7030003@airemix.com> References: <446CE3BF.2050704@airemix.com> <59593A24-A0A2-4644-B3CE-27F45EB6F2CC@asakawa.ne.jp> <446D0176.7030003@airemix.com> Message-ID: <20060519.082856.23027453.nozomi@biol.tsukuba.ac.jp> > Legacy Encoding -> Unicode では多対一変換は行われないので、 > 再変換は常に可能なはずです。 森山案ではずいぶん行われていますが...それとも誤解? -- のぞみ From naruse ＠ airemix.com Fri May 19 08:29:55 2006 From: naruse ＠ airemix.com (NARUSE, Yui) Date: Fri, 19 May 2006 08:29:55 +0900 Subject: [LE-talk-ja 162] =?iso-2022-jp?b?UmU6IExFLXRhbGstamEgGyRCJEcbKEI=?= =?iso-2022-jp?b?GyRCJE41RE9AJE4kXiRIJGEbKEI=?= In-Reply-To: References: <20060516184928.894D.MORIYAMA@miraclelinux.com> <22441D30-61EE-47A0-89FF-AB5C6FD4DAB4@mac.com> <20060518.145756.576039588.hyoshiok@miraclelinux.com> <20060518.154903.36935854.nozomi@biol.tsukuba.ac.jp> <658FB29F-DEDE-4844-BED0-B984FE2CAA09@asakawa.ne.jp> <446CA7EE.6050501@airemix.com> <936F52DE-7510-45DE-9174-A426CCBEC3EF@asakawa.ne.jp> <446CE3BF.2050704@airemix.com> <896E5377-ADC8-497D-A669-F07A6C6DBBE8@asakawa.ne.jp> <446CFD76.1050601@airemix.com> Message-ID: <446D0373.90504@airemix.com> 成瀬です。 Tomoyuki Asakawa wrote: > 制御コードと文字コードなので、別次元です。 printableじゃなくても文字だと思いますが・・・、 まぁ脇道ですし。 > 用途として、一緒の方が便利な場合もあるでしょうけども > 明確に別次元と言えるものを、一緒にあつかうベキではないと思う。 > 組み合わせを増やすだけ。 > > 逆に、SJISとCP932なんか、わけるから、組み合わせが増 > える。 SJISとCP932は、別物ですよ。 IANAに登録されている定義を引くと、 http://www.iana.org/assignments/character-sets Name: Shift_JIS (preferred MIME name) MIBenum: 17 Source: This charset is an extension of csHalfWidthKatakana by adding graphic characters in JIS X 0208. The CCS's are JIS X0201:1997 and JIS X0208:1997. The complete definition is shown in Appendix 1 of JIS X0208:1997. This charset can be used for the top-level media type "text". Alias: MS_Kanji Alias: csShiftJIS Name: Windows-31J MIBenum: 2024 Source: Windows Japanese. A further extension of Shift_JIS to include NEC special characters (Row 13), NEC selection of IBM extensions (Rows 89 to 92), and IBM extensions (Rows 115 to 119). The CCS's are JIS X0201:1997, JIS X0208:1997, and these extensions. This charset can be used for the top-level media type "text", but it is of limited or specialized use (see RFC2278). PCL Symbol Set id: 19K Alias: csWindows31J ですので、 * NEC special characters (Row 13) * NEC selection of IBM extensions (Rows 89 to 92) * IBM extensions (Rows 115 to 119) が差分になります。 これに加えて、SJISはUnicode変換表としての意味においては、 通常 SJIS(\x81\x60)を U+301C に割り当てますからさらに別物となります。 -- NARUSE, Yui DBDB A476 FDBD 9450 02CD 0EFC BCE3 C388 472E C1EA From naruse ＠ airemix.com Fri May 19 08:41:49 2006 From: naruse ＠ airemix.com (NARUSE, Yui) Date: Fri, 19 May 2006 08:41:49 +0900 Subject: [LE-talk-ja 163] =?iso-2022-jp?b?UmU6IExFLXRhbGstamEgGyRCJEcbKEI=?= =?iso-2022-jp?b?GyRCJE41RE9AJE4kXiRIJGEbKEI=?= In-Reply-To: <20060519.082856.23027453.nozomi@biol.tsukuba.ac.jp> References: <446CE3BF.2050704@airemix.com> <59593A24-A0A2-4644-B3CE-27F45EB6F2CC@asakawa.ne.jp> <446D0176.7030003@airemix.com> <20060519.082856.23027453.nozomi@biol.tsukuba.ac.jp> Message-ID: <446D063D.2070105@airemix.com> 成瀬です。 Nozomi Ytow wrote: >> Legacy Encoding -> Unicode では多対一変換は行われないので、 >> 再変換は常に可能なはずです。 > > 森山案ではずいぶん行われていますが...それとも誤解? IBM拡張文字やNEC選定IBM拡張文字の話でしたら、 それらは「同じ文字」ですので問題ないと思いますけれど。 -- NARUSE, Yui DBDB A476 FDBD 9450 02CD 0EFC BCE3 C388 472E C1EA From nozomi ＠ biol.tsukuba.ac.jp Fri May 19 08:48:42 2006 From: nozomi ＠ biol.tsukuba.ac.jp (Nozomi Ytow) Date: Fri, 19 May 2006 08:48:42 +0900 (JST) Subject: [LE-talk-ja 164] =?iso-2022-jp?b?UmU6IExFLXRhbGstamEgGyRCJEcbKEI=?= =?iso-2022-jp?b?GyRCJE41RE9AJE4kXiRIJGEbKEI=?= In-Reply-To: <446D063D.2070105@airemix.com> References: <446D0176.7030003@airemix.com> <20060519.082856.23027453.nozomi@biol.tsukuba.ac.jp> <446D063D.2070105@airemix.com> Message-ID: <20060519.084842.70206264.nozomi@biol.tsukuba.ac.jp> > IBM拡張文字やNEC選定IBM拡張文字の話でしたら、 > それらは「同じ文字」ですので問題ないと思いますけれど。 同じ文字でも違うコードポイントなので、それを 無条件に unify するのは round trip 的に問題かと。 Unicode への移行を早めるために unify するというのは アリとは思いますが、だったらそもそもレガシーやめる べきでしょう。そうではなくて、現状の資産を使わざるを 得ないのだから、round trip は保証すべきだと思います。 その上で、unify するオプションもあっていいでしょう。 -- のぞみ From naruse ＠ airemix.com Fri May 19 09:25:36 2006 From: naruse ＠ airemix.com (NARUSE, Yui) Date: Fri, 19 May 2006 09:25:36 +0900 Subject: [LE-talk-ja 165] =?iso-2022-jp?b?UmU6IExFLXRhbGstamEgGyRCJEcbKEI=?= =?iso-2022-jp?b?GyRCJE41RE9AJE4kXiRIJGEbKEI=?= In-Reply-To: <20060519.084842.70206264.nozomi@biol.tsukuba.ac.jp> References: <446D0176.7030003@airemix.com> <20060519.082856.23027453.nozomi@biol.tsukuba.ac.jp> <446D063D.2070105@airemix.com> <20060519.084842.70206264.nozomi@biol.tsukuba.ac.jp> Message-ID: <446D1080.7060405@airemix.com> 成瀬です。 Nozomi Ytow wrote: >> IBM拡張文字やNEC選定IBM拡張文字の話でしたら、 >> それらは「同じ文字」ですので問題ないと思いますけれど。 > > 同じ文字でも違うコードポイントなので、それを > 無条件に unify するのは round trip 的に問題かと。 > Unicode への移行を早めるために unify するというのは > アリとは思いますが、だったらそもそもレガシーやめる > べきでしょう。そうではなくて、現状の資産を使わざるを > 得ないのだから、round trip は保証すべきだと思います。 > その上で、unify するオプションもあっていいでしょう。 まず、収録されている文字をご覧いただいた上での発言でしょうか。 以下ご覧いただいているという仮定で話をします。 いかなる理由があろうともroud tripを保障するというのは、 一つの方針でしょう。 しかし、今回の文字群は、 * 似ている文字でなく「同じ文字」である 　これらは重複符号化されている文字であり、違うのはコードポイント以外だけ * Microsoftも正規化している 　http://support.microsoft.com/default.aspx?scid=kb;ja;JP170559 * 仮に区別しようとおもって、別のUnicodeコードポイントが無い 　典拠であるMicrosoftでも正規化しているため、 　Unicodeに一つしかコードポイントがありません。 　外字領域にマッピングするくらいしか方法はないでしょう という事情から、round tripを保障する必要も無いし、 保障できないと思われます。 -- NARUSE, Yui DBDB A476 FDBD 9450 02CD 0EFC BCE3 C388 472E C1EA From nozomi ＠ biol.tsukuba.ac.jp Fri May 19 09:57:56 2006 From: nozomi ＠ biol.tsukuba.ac.jp (Nozomi Ytow) Date: Fri, 19 May 2006 09:57:56 +0900 (JST) Subject: [LE-talk-ja 166] =?iso-2022-jp?b?GyRCPUVKI0lkOWYyPUo4O3obKEI=?= In-Reply-To: <446D1080.7060405@airemix.com> References: <446D063D.2070105@airemix.com> <20060519.084842.70206264.nozomi@biol.tsukuba.ac.jp> <446D1080.7060405@airemix.com> Message-ID: <20060519.095756.31433706.nozomi@biol.tsukuba.ac.jp> サブジェクト変えました。 > まず、収録されている文字をご覧いただいた上での発言でしょうか。 そうです。 > * 似ている文字でなく「同じ文字」である > 　これらは重複符号化されている文字であり、違うのはコードポイント以外だけ 違うのはコードポイントだけ、その通りです。で、そもそも なんでそんなものを重複符号化したのかわからんのですが、 それはさておき、 > * Microsoftも正規化している > 　http://support.microsoft.com/default.aspx?scid=kb;ja;JP170559 これはするしかなかったからではないかと推測します。 > * 仮に区別しようとおもって、別のUnicodeコードポイントが無い > 　典拠であるMicrosoftでも正規化しているため、 > 　Unicodeに一つしかコードポイントがありません。 > 　外字領域にマッピングするくらいしか方法はないでしょう Unicode 3.2 からは valiation selector が使えるので、 内部的に表現できない訳ではありません。 規定されている組合せ以外は外に出してはダメです、もちろん。 > という事情から、round tripを保障する必要も無いし、 > 保障できないと思われます。 ので、保証はできます。必要がないか、というと、 区別したい場合はあると思います。 区別したくない場合があるのももちろんです。 -- のぞみ From naruse ＠ airemix.com Fri May 19 10:10:48 2006 From: naruse ＠ airemix.com (NARUSE, Yui) Date: Fri, 19 May 2006 10:10:48 +0900 Subject: [LE-talk-ja 167] =?iso-2022-jp?b?UmU6IBskQj1FSiNJZDlmMj1KODt6GyhC?= In-Reply-To: <20060519.095756.31433706.nozomi@biol.tsukuba.ac.jp> References: <446D063D.2070105@airemix.com> <20060519.084842.70206264.nozomi@biol.tsukuba.ac.jp> <446D1080.7060405@airemix.com> <20060519.095756.31433706.nozomi@biol.tsukuba.ac.jp> Message-ID: <446D1B18.5020501@airemix.com> 成瀬です。 Nozomi Ytow wrote: >> * 仮に区別しようとおもって、別のUnicodeコードポイントが無い >> 　典拠であるMicrosoftでも正規化しているため、 >> 　Unicodeに一つしかコードポイントがありません。 >> 　外字領域にマッピングするくらいしか方法はないでしょう > > Unicode 3.2 からは valiation selector が使えるので、 > 内部的に表現できない訳ではありません。 > 規定されている組合せ以外は外に出してはダメです うーん、U+FFFFを越えてしまう時点でnkf的には及び腰です。 また、Ideographic Variation Databaseを考えると、 あまりに危険な手法に感じます。 http://www.unicode.org/reports/tr37/ -- NARUSE, Yui DBDB A476 FDBD 9450 02CD 0EFC BCE3 C388 472E C1EA From nozomi ＠ biol.tsukuba.ac.jp Fri May 19 10:22:51 2006 From: nozomi ＠ biol.tsukuba.ac.jp (Nozomi Ytow) Date: Fri, 19 May 2006 10:22:51 +0900 (JST) Subject: [LE-talk-ja 168] =?iso-2022-jp?b?UmU6IBskQj1FSiNJZDlmMj1KODt6GyhC?= In-Reply-To: <446D1B18.5020501@airemix.com> References: <446D1080.7060405@airemix.com> <20060519.095756.31433706.nozomi@biol.tsukuba.ac.jp> <446D1B18.5020501@airemix.com> Message-ID: <20060519.102251.35028892.nozomi@biol.tsukuba.ac.jp> > うーん、U+FFFFを越えてしまう時点でnkf的には及び腰です。 はて。IVS ではなく VS (U+FE00-U+FE0F) を abuse しようと 言っているのですが。元の input stream に VS が現れた場合は 同じ VS or VS1 を追加してエスケープすれば処理できるでしょう。 > また、Ideographic Variation Databaseを考えると、 > あまりに危険な手法に感じます。 IVS のどのあたりがでしょうか。私は Unicode をちゃんと使うなら やらねばならない事だと思っていますが。 -- のぞみ From tom ＠ asakawa.ne.jp Fri May 19 10:24:17 2006 From: tom ＠ asakawa.ne.jp (Tomoyuki Asakawa) Date: Fri, 19 May 2006 10:24:17 +0900 Subject: [LE-talk-ja 169] =?iso-2022-jp?b?UmU6IBskQj1FSiNJZDlmMj1KODt6GyhC?= In-Reply-To: <446D1B18.5020501@airemix.com> References: <446D063D.2070105@airemix.com> <20060519.084842.70206264.nozomi@biol.tsukuba.ac.jp> <446D1080.7060405@airemix.com> <20060519.095756.31433706.nozomi@biol.tsukuba.ac.jp> <446D1B18.5020501@airemix.com> Message-ID: あさかわ On 2006/05/19, at 10:10, NARUSE, Yui wrote: > うーん、U+FFFFを越えてしまう時点でnkf的には及び腰 > です。 がんばれ、若者！ > > また、Ideographic Variation Databaseを考えると、 > あまりに危険な手法に感じます。 > http://www.unicode.org/reports/tr37/ おおおおおおお、こんな仕掛けも用意されていたのか、恐るべしというか なんと、無節操というか。。。。 From nozomi ＠ biol.tsukuba.ac.jp Fri May 19 10:27:12 2006 From: nozomi ＠ biol.tsukuba.ac.jp (Nozomi Ytow) Date: Fri, 19 May 2006 10:27:12 +0900 (JST) Subject: [LE-talk-ja 170] =?iso-2022-jp?b?UmU6IBskQj1FSiNJZDlmMj1KODt6GyhC?= In-Reply-To: References: <20060519.095756.31433706.nozomi@biol.tsukuba.ac.jp> <446D1B18.5020501@airemix.com> Message-ID: <20060519.102712.15251232.nozomi@biol.tsukuba.ac.jp> > おおおおおおお、こんな仕掛けも用意されていたのか、恐るべしというか 樋浦さんですから。遅くとも 2000 年頃には disambiguator の 必要性は唱えていましたよ。 > なんと、無節操というか。。。。 Unicode がそもそも無節操なのでしかたないでしょう。 現実的な解だと思いますが。 -- のぞみ From tom ＠ asakawa.ne.jp Fri May 19 10:31:21 2006 From: tom ＠ asakawa.ne.jp (Tomoyuki Asakawa) Date: Fri, 19 May 2006 10:31:21 +0900 Subject: [LE-talk-ja 171] =?iso-2022-jp?b?UmU6IBskQj1FSiNJZDlmMj1KODt6GyhC?= In-Reply-To: References: <446D063D.2070105@airemix.com> <20060519.084842.70206264.nozomi@biol.tsukuba.ac.jp> <446D1080.7060405@airemix.com> <20060519.095756.31433706.nozomi@biol.tsukuba.ac.jp> <446D1B18.5020501@airemix.com> Message-ID: <1477C5E6-D1AC-42A0-AF7A-996E930D09C2@asakawa.ne.jp> あさかわ >> また、Ideographic Variation Databaseを考えると、 >> あまりに危険な手法に感じます。 >> http://www.unicode.org/reports/tr37/ > > おおおおおおお、こんな仕掛けも用意されていたのか、恐るべしとい > うか > なんと、無節操というか。。。。 > もしかして。Vista用の次のMS-wordって こいつで、グリフを切り替えるのでは？ ということは、グリフ切り替えまで考慮したコンバータが必要になるっ てことじゃん。 From umq.876 ＠ gmail.com Fri May 19 10:39:54 2006 From: umq.876 ＠ gmail.com (Hirohisa Yamaguchi) Date: Fri, 19 May 2006 10:39:54 +0900 Subject: [LE-talk-ja 172] =?iso-2022-jp?b?UmU6IBskQj1FSiNJZDlmMj1KODt6GyhC?= In-Reply-To: <20060519.102251.35028892.nozomi@biol.tsukuba.ac.jp> References: <446D1080.7060405@airemix.com> <20060519.095756.31433706.nozomi@biol.tsukuba.ac.jp> <446D1B18.5020501@airemix.com> <20060519.102251.35028892.nozomi@biol.tsukuba.ac.jp> Message-ID: <1dba65f30605181839s78380e01t65e0859681421f8b@mail.gmail.com> やまぐちと申します On 5/19/06, Nozomi Ytow wrote: > > うーん、U+FFFFを越えてしまう時点でnkf的には及び腰です。 > はて。IVS ではなく VS (U+FE00-U+FE0F) を abuse しようと > 言っているのですが。元の input stream に VS が現れた場合は > 同じ VS or VS1 を追加してエスケープすれば処理できるでしょう。 Valiation Selectors を *abuse* してしまうと、 将来の「正しい」実装との不整合が問題になりませんか -- end やまきゅう umq.876 ＠ gmail.com From nozomi ＠ biol.tsukuba.ac.jp Fri May 19 10:44:30 2006 From: nozomi ＠ biol.tsukuba.ac.jp (Nozomi Ytow) Date: Fri, 19 May 2006 10:44:30 +0900 (JST) Subject: [LE-talk-ja 173] =?iso-2022-jp?b?UmU6IBskQj1FSiNJZDlmMj1KODt6GyhC?= In-Reply-To: <1dba65f30605181839s78380e01t65e0859681421f8b@mail.gmail.com> References: <446D1B18.5020501@airemix.com> <20060519.102251.35028892.nozomi@biol.tsukuba.ac.jp> <1dba65f30605181839s78380e01t65e0859681421f8b@mail.gmail.com> Message-ID: <20060519.104430.84959112.nozomi@biol.tsukuba.ac.jp> > Valiation Selectors を *abuse* してしまうと、 > 将来の「正しい」実装との不整合が問題になりませんか 内部処理の範囲なら問題にならないと思います。 重複符号化文字の積極的意義の解釈としてグリフの違い というのも不可能ではありませんし。 -- のぞみ From tom ＠ asakawa.ne.jp Fri May 19 10:56:00 2006 From: tom ＠ asakawa.ne.jp (Tomoyuki Asakawa) Date: Fri, 19 May 2006 10:56:00 +0900 Subject: [LE-talk-ja 174] =?iso-2022-jp?b?UmU6IBskQj1FSiNJZDlmMj1KODt6GyhC?= In-Reply-To: <20060519.095756.31433706.nozomi@biol.tsukuba.ac.jp> References: <446D063D.2070105@airemix.com> <20060519.084842.70206264.nozomi@biol.tsukuba.ac.jp> <446D1080.7060405@airemix.com> <20060519.095756.31433706.nozomi@biol.tsukuba.ac.jp> Message-ID: あさかわ On 2006/05/19, at 9:57, Nozomi Ytow wrote: > Unicode 3.2 からは valiation selector が使えるので、 > 内部的に表現できない訳ではありません。 > 規定されている組合せ以外は外に出してはダメです、もちろん。 >内部処理の範囲なら問題にならないと思います。 たぶん、事実上内部じゃなくなりますね。 マイクロソフト，新文字セット「JIS2004」への移行措置を明ら かに http://itpro.nikkeibp.co.jp/article/NEWS/20060516/238066/ 引用 「OpenTypeに対応したアプリケーションやWinFX（Windows Presentation Foundation） 対応アプリケーションでは，OpenTypeの機能によって， JIS90ベースの字形とJIS2004ベースの字形の両方が使えるように なる。」 opentypeの機能でadobeのグリフコードをつかうらしいとおもっ ていたけど。 adobeのグリフコードって、valiation selectorなわけね。 結局 vista opentype この組み合わせの世界が、 広ーい「内部」として、はびこってしまいますね。 これは、歴史が物語ってる。 From nozomi ＠ biol.tsukuba.ac.jp Fri May 19 11:00:57 2006 From: nozomi ＠ biol.tsukuba.ac.jp (Nozomi Ytow) Date: Fri, 19 May 2006 11:00:57 +0900 (JST) Subject: [LE-talk-ja 175] =?iso-2022-jp?b?UmU6IBskQj1FSiNJZDlmMj1KODt6GyhC?= In-Reply-To: References: <446D1080.7060405@airemix.com> <20060519.095756.31433706.nozomi@biol.tsukuba.ac.jp> Message-ID: <20060519.110057.68051959.nozomi@biol.tsukuba.ac.jp> > >内部処理の範囲なら問題にならないと思います。 > たぶん、事実上内部じゃなくなりますね。 ではますます問題なし、いや先送りか? 規格上は VSX+VS0 を予約しておけばいいわけですよね、 VS0 を VSX に対する valiation selcector と考えて、 後ろからエスケープする事にすれば。 -- のぞみ From m-kosaki ＠ ceres.dti.ne.jp Fri May 19 11:05:19 2006 From: m-kosaki ＠ ceres.dti.ne.jp (=?ISO-2022-JP?B?GyRCPi46ajtxOS0bKEI=?=) Date: Fri, 19 May 2006 11:05:19 +0900 Subject: [LE-talk-ja 176] =?iso-2022-jp?b?UmU6IBskQj1FSiNJZDlmMj1KODt6GyhC?= In-Reply-To: <20060519.095756.31433706.nozomi@biol.tsukuba.ac.jp> References: <446D063D.2070105@airemix.com> <20060519.084842.70206264.nozomi@biol.tsukuba.ac.jp> <446D1080.7060405@airemix.com> <20060519.095756.31433706.nozomi@biol.tsukuba.ac.jp> Message-ID: <2f11576a0605181905m6e0e3520h540ced0fb15a2429@mail.gmail.com> 小崎です。 > * Microsoftも正規化している > > http://support.microsoft.com/default.aspx?scid=kb;ja;JP170559 > > これはするしかなかったからではないかと推測します。 このプロジェクトの「現実を見よう！」方針からすると、 マイクロソフトが仕方ないと思っているどうかはともかく 必要ないってことになりませんか。 たとえば〜問題なんかはみんなが困っている。という所が重要だと思っていて、 だれか困っている人がいる「かも」しれない、ってのでコーディングしちゃうのは、 あとでコミュニティーにマージ働きかけるときにもめますよ。 （特にメンテナが英語圏の人の時には） 脱線しちゃいますが、 向こうの人から見たら、レガシーエンコーディング対応ってのはuglyな行為なわけ。 で、僕らはuglyなのは分かった上で、頻度が高すぎるから現実をみて押し込もうと してるわけでしょ。 そこで、頻度が低いモンがまじってたら、向こうからしたらこちらの活動全体が あいつらは規格のスミをつついてありもしない問題を大げさに騒いでいるだけだ。 と映るんじゃないかと危惧しています。 結構大変ですよ。説得。逆にUnicodeとかマジメに勉強した人の方が。 向こうは、どのぐらい頻繁に困っているかが肌で分からないからスジ論に陥りがちで 「えーい、おまえら黙って正規のShiftJIS使え」って話に１０回ぐらいは話を 戻されるんですから。 > > * 仮に区別しようとおもって、別のUnicodeコードポイントが無い > > 典拠であるMicrosoftでも正規化しているため、 > > Unicodeに一つしかコードポイントがありません。 > > 外字領域にマッピングするくらいしか方法はないでしょう > > Unicode 3.2 からは valiation selector が使えるので、 > 内部的に表現できない訳ではありません。 > 規定されている組合せ以外は外に出してはダメです、もちろん。 外に出せないコードを作るのはもうやめません？ 絶対裏切り者が出てきて、外に出しやがりますよ。 昔はShiftJISも内部コードだったんですから。 -------------- next part -------------- HTMLの添付ファイルを保管しました... URL: http://lists.sourceforge.jp/mailman/archives/legacy-encoding-talk-ja/attachments/20060519/c6914309/attachment.html From kazama ＠ mac.com Fri May 19 11:22:37 2006 From: kazama ＠ mac.com (Kazuhiro Kazama) Date: Fri, 19 May 2006 11:22:37 +0900 Subject: [LE-talk-ja 177] =?iso-2022-jp?b?UmU6IBskQj1FSiNJZDlmMj1KODt6GyhC?= In-Reply-To: References: <446D063D.2070105@airemix.com> <20060519.084842.70206264.nozomi@biol.tsukuba.ac.jp> <446D1080.7060405@airemix.com> <20060519.095756.31433706.nozomi@biol.tsukuba.ac.jp> Message-ID: <46E17890-E7C7-4D26-97BA-90C43A83506D@mac.com> On 2006/05/19, at 10:56, Tomoyuki Asakawa wrote: > opentypeの機能でadobeのグリフコードをつかうらしいとおもっ > ていたけど。 > adobeのグリフコードって、valiation selectorなわけね。 現時点では，ヒラギノでは独自の方法でグリフを指定していると聞いたことが ありますので，違うでしょう．ただ，将来的にValiation Selectorが整備され れば，それでも指定できるようにすると聞きました． --- 風間 一洋 (kazama ＠ mac.com) From kazama ＠ mac.com Fri May 19 11:26:26 2006 From: kazama ＠ mac.com (Kazuhiro Kazama) Date: Fri, 19 May 2006 11:26:26 +0900 Subject: [LE-talk-ja 178] =?iso-2022-jp?b?GyRCJVAlMEVQTz8bKEIgKFJlOiA=?= =?iso-2022-jp?b?GyRCJSolVSVpJSQlcyVfITwlRiUjJXMlMCROGyhCKhskQjhEP00bKEI=?= =?iso-2022-jp?b?GyRCRSokShsoQiobJEI1RE9AJE4kXiRIJGEbKEIp?= In-Reply-To: <884D65C0-153D-4F2B-BA57-FF40424F252C@mac.com> References: <20060516184928.894D.MORIYAMA@miraclelinux.com> <70DB9439-5AA0-42A2-B846-44B050ECF741@mac.com> <20060518005639.GA12382%numata@jp.fujitsu.com> <20060518062703.GA18052%numata@jp.fujitsu.com> <87k68joj8q.wl%shinichiro@stained-g.net> <884D65C0-153D-4F2B-BA57-FF40424F252C@mac.com> Message-ID: <5DC752CC-D5D2-430C-BCB5-25C797DE6B42@mac.com> On 2006/05/18, at 19:42, Kazuhiro Kazama wrote: > On 2006/05/18, at 18:59, Tomoyuki Asakawa wrote: >>> 今，Mac OS Xで標準のMailを使ってJIS X 0212の >>> 文字を入れて出してみたとこ >>> ろ，黙ってUTF-8で送信しました． >> >> なんと！、クサナギをいれたら。CP932で出ました。 > > これが昨日聞いていたCP932問題ですか（苦笑） > > これ，WindowsのOutlook Expressでは自動認識で回避してくれますが， > Firefoxの日本語自動認識では残念ながら駄目のようです．というわけで，今 > Apple Computerに問い合わせ中です． さっそく，バグとして登録して頂いたようです．変なバグですよねえ…． --- 風間 一洋 (kazama ＠ mac.com) From umq.876 ＠ gmail.com Fri May 19 12:05:33 2006 From: umq.876 ＠ gmail.com (Hirohisa Yamaguchi) Date: Fri, 19 May 2006 12:05:33 +0900 Subject: [LE-talk-ja 179] =?iso-2022-jp?b?UmU6IBskQiUqJVUlaSUkJXMlXyE8GyhC?= =?iso-2022-jp?b?GyRCJUYlIyVzJTAkThsoQiobJEI4RD9NRSokShsoQio=?= =?iso-2022-jp?b?GyRCNURPQCROJF4kSCRhGyhC?= In-Reply-To: <87k68joj8q.wl%shinichiro@stained-g.net> References: <20060516184928.894D.MORIYAMA@miraclelinux.com> <70DB9439-5AA0-42A2-B846-44B050ECF741@mac.com> <20060518005639.GA12382%numata@jp.fujitsu.com> <20060518062703.GA18052%numata@jp.fujitsu.com> <87k68joj8q.wl%shinichiro@stained-g.net> Message-ID: <1dba65f30605182005o4471c13fwf08a94542bee60ee@mail.gmail.com> やまぐちと申します # ちょいと脱線 On 5/18/06, Shinichiro HIDA wrote: > > > これ意外に，「ISO-2022-JP-1 や ISO-2022-JP-2は誰もつかってない/必要と > > > してないよねえ」という状況が根底にあります． > > これは，そうでしょうねえ． > 以前(数年前に)テストしてみた所、Mozilla mail で、日本語にアクサン付きア > ルファベットを混ぜたメールを書いて出すと ISO-2022-JP-2 で出るようです。 > 試しにこれを Debian + Emacs22 + Wanderlust から出してみますが、"つかっ > てない/必要としてない" かどうかは私の知識レベルでは何とも言えませんが、 > "扱える実装はなくはない" ということで。 ISO-2022-JP-2 の使用例といえば 1998 年ごろに メイリングリストだかニュースだかで、 「ハートマークは ISO-2022-JP に含まれないから ISO-2022-JP-2 使え」 というような趣旨のことを書いている人がいたのが記憶にある程度です。 当時は、mime のメールは受け取らないと公言してる人がいたり 今とは状況が大きく違いますが、そういう趣旨であれば、 UCS 対応でどうにかなると思っています。 -- end やまきゅう umq.876 ＠ gmail.com From moriyama ＠ miraclelinux.com Fri May 19 13:11:35 2006 From: moriyama ＠ miraclelinux.com (MORIYAMA Masayuki) Date: Fri, 19 May 2006 13:11:35 +0900 (JST) Subject: [LE-talk-ja 180] =?iso-2022-jp?b?UmU6IBskQiUqJVUlaSUkJXMlXyE8GyhC?= =?iso-2022-jp?b?GyRCJUYlIyVzJTAbKEIoMjAwNi8wNS8xNyk=?= In-Reply-To: <446C69F2.8040903@airemix.com> References: <20060502191137.E9C4.MORIYAMA@miraclelinux.com> <446C69F2.8040903@airemix.com> Message-ID: <20060519125529.8994.MORIYAMA@miraclelinux.com> 森山です。 成瀬さん、FAQ の作成ありがとうございます。 ただいま、変換表を公開する為の準備をしています。 Unicode コンソーシアム配布の CP932.TXT では、Unicode→マルチバイトの変 換で、重複定義文字が考慮されていないため、そのままで使えないという問題 があるため、IBM ICU の ucm フォーマット形式を採用します。この変換表か ら、機械的に次の 2 つの変換表を生成可能になります。 ・マルチバイト→Unicode ・Unicode→マルチバイト "NARUSE, Yui" wrote: > 成瀬です。 > 昨日はおつかれさまでした。 > > とりあえず、昨日の会と今日のメール群を見て、 > このプロジェクトの方向性について、 > 概要なりなんなりに追記する必要があると考えました。 > > 勝手にWikiに追記しようとも思ったのですが、 > とりあえずWikiにFAQという項を作っておきました。 > http://legacy-encoding.sourceforge.jp/wiki/index.php?FAQ > > 途中からこのMLを読んでいる方に、 > MLのログを全て読んでもらうのはつらいと思われるので、 > FAQを最初に読めば一通りの流れがわかるようにするとよいかな、と。 > > > ところで、わたしの解釈で、「このプロジェクトの意義」案。 > > 「Legacy Encoding Project」とは、そもそも、 > レガシーエンコーディングを混乱なくフェードアウトさせようというもの。 > > （ミーディングでの乾杯の時に言われていた通り、 > 　「レガシーエンコーディングの更なる発展と繁栄を祈る」 > 　ものではないと、笑。） > > これを実現する手段として、[LE-talk-ja 118]にも挙げられている、 > > Windows Codepage 932 で使用可能な文字を Unicode 経由で、日本語EUC > > 符号化方式、7ビットJIS(ISO-2022-JP)符号化方式に変換できるようにする。 補足しますと、eucJP-ms では、Unicode との変換では、JIS X 0212 補助漢字 を変換できますが、JIS X 0212 を他の符号化方式で使えるようには考えてい ません。 > これが手段となる前提として以下がある。 > * レガシーエンコーディングはJIS系、SJIS系、EUC系の三つ > * 今時の文字コード変換はUnicodeによるUCS正規化で行われる > * よって「キャラクタセット」とはUnicodeとの変換表のこと > * 既に"ISO-2022-JP", "Shift_JIS", "EUC-JP"といった名前の変換表は、 > 　各OSSが提供しているが、独自の変更が加えられていて、変更できない。 > * 変換表のデファクトとしてWindows系のものがある。 > > 以上のような事情から、 > 変換表の名前（キャラクタセット名）は既存のものを使えない > ∵既存のものは別の変換表を指しているから > →別の名前を定義する必要がある > →かと言って全く新しいものを定義するのは混乱を助長する > →CP932, CP51932, eucJP-ms, CP50221 > 　（CP*の典拠はMicrosoftの実装、eucJP-msはTOG/JVC） > > -- > NARUSE, Yui > DBDB A476 FDBD 9450 02CD 0EFC BCE3 C388 472E C1EA > _______________________________________________ > Legacy-Encoding-talk-ja mailing list > Legacy-Encoding-talk-ja ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/legacy-encoding-talk-ja -- 森山 将之 moriyama ＠ miraclelinux.com ミラクル・リナックス株式会社 From m-kosaki ＠ ceres.dti.ne.jp Fri May 19 14:11:07 2006 From: m-kosaki ＠ ceres.dti.ne.jp (=?ISO-2022-JP?B?GyRCPi46ajtxOS0bKEI=?=) Date: Fri, 19 May 2006 14:11:07 +0900 Subject: [LE-talk-ja 181] =?iso-2022-jp?b?UmU6IBskQiUqJVUlaSUkJXMlXyE8GyhC?= =?iso-2022-jp?b?GyRCJUYlIyVzJTAbKEIoMjAwNi8wNS8xNyk=?= In-Reply-To: References: <20060502191137.E9C4.MORIYAMA@miraclelinux.com> <446C69F2.8040903@airemix.com> Message-ID: <2f11576a0605182211s1f7fb001mfee84a8dea7da522@mail.gmail.com> 小崎です。 > 期待するユニコードにロストなく変換できれば > レガシーデータのユニコード化は加速すると思うのです > しかし、制限する理想論では、レガシーデータは、変換されずに > そのまま蓄積されて、フェードアウトどころか、そのデータを処理する > プログラムとの互換の為に、新規のデータまで、レガシーコードで作成 > されて > 逆に、レガシーデータが増殖します。 脱線かもしれませんが、ここにつなげます。 昔（でもないんだけど）、いままで付き合いのなかった業界のSEさんと付き合うことになってびっくりしたのは その世界の暗黙のルールとして（社内に閉じた話ちゃうよ）、通信はSJISというのがありまして、 理由を聞いたら、Unicodeは文字化けするから。 と言われた事があります。 つまり、まる１問題とか〜問題とかを一生懸命啓蒙するよりかはSJISに変換させて、Windowsの形式に出来ないやつが悪いんだー とやったほうが、各社の調整がえらい楽というマネージメント上のノウハウなんですな。 ＃当時すでに風間さんが非常にいいUnicodeの問題を解説したページをつくってくれていたが ＃ふつーのプログラマにはそれでも難しすぎたらしい そんな状況なのに、Microsoftが自分のMB2WCでIBM拡張文字とNEC選定IBM拡張文字を一緒にしちゃうのは だれも問題にしてない。 ああ、なんてWindowsは偉大なんだろうと思いましたね。 実際のプロジェクトでは、デファクト重要 ・・・例が特殊か？ -------------- next part -------------- HTMLの添付ファイルを保管しました... URL: http://lists.sourceforge.jp/mailman/archives/legacy-encoding-talk-ja/attachments/20060519/d8ccd84f/attachment.htm From nishida ＠ miraclelinux.com Fri May 19 14:41:26 2006 From: nishida ＠ miraclelinux.com (Shigeo Nishida) Date: Fri, 19 May 2006 14:41:26 +0900 (JST) Subject: [LE-talk-ja 182] =?iso-2022-jp?b?NS8xNyAbJEIlKiVVJWklJCVzJV8bKEI=?= =?iso-2022-jp?b?GyRCITwlRiUjJXMlMCReJEgkYRsoQg==?= Message-ID: <20060519.144126.115906589.nishida@miraclelinux.com> ミラクル・リナックスの西田です。 先日はお忙しい中お集まり頂きありがとうございました。 ミーティングのあと、吉岡、森山、西田の三名で議題の整理を致しました。 抜け、間違いなどございましたらフォローして頂けると助かります。 ● 1. 議題整理 森山が出しましたメール Message-Id: <20060516184928.894D.MORIYAMA ＠ miraclelinux.com> に沿って 当日挙った議論を整理しました。 仕様について ============ * プロジェクトの方針 →概ね理解された。 * スコープ →概ね理解された。 * 全般 - JIX X 0208 議題に挙らず。 - IANA レジストリ/RFC 議題に挙らず。 - JIS X 0213 対応は? PostgreSQL で JIS X 0213 対応と称して新しい LE 追加の動きがある ということが報告された。 - 携帯絵文字 キャリア毎にマッピングが異なる。 LE プロジェクトとしてはスコープ外。 - Macintosh samba のコードが一部流用されているという指摘があった。 * ISO-2022-JP-MS - 名前がだめ 違う名前にするべき - CP5022x にすべき 検討する - MUA 問題 議題に挙らず。 (風間さんと森山さんの間で局所的には話題になっていたようです。) - メールで ISO-2022-JP という名前で機種依存文字をあつかいたい 議題に挙らず。 - ユーザ定義文字をサポートするのは望ましくない 積極的にサポートせず、コードポイントを保持する程度という認識。 - ISO-2022-JP-MS といった、新しいレガシーエンコーディングを定義す べきではなく、すでにある CP50221 の方が望ましい。 あまり議論されず。 - CP5022X を扱えるテキストエディタ あまり議論されず。 * CP51932 (Windows の EUC-JP のコードページ) について - CP51932 は必要ないのでは? あまり議論されず。 - Unicode に移行すれば済む話なのでは? あまり議論されず。 * その他 活動について ============ * EUC LE では EUC として cp51932 と eucJP-ms を対象としているが、一般の 人にはその違いが分かりにくいので見せ方の工夫をすべし。 * 広報活動 英語で仕様を出してほしい。 変換表を unicode.org の形式で出してほしい。 ● 2. 総括 集まった人: 8人(ML 除く) 活発な議論が交わされ出席者にも好評であった。 オンラインだけでなく F2F で意見を交換することが重要である。 -- Shigeo Nishida. MIRACLE LINUX Corporation nishida ＠ miralelinux.com From nozomi ＠ biol.tsukuba.ac.jp Fri May 19 14:42:28 2006 From: nozomi ＠ biol.tsukuba.ac.jp (Nozomi Ytow) Date: Fri, 19 May 2006 14:42:28 +0900 (JST) Subject: [LE-talk-ja 183] =?iso-2022-jp?b?UmU6IBskQj1FSiNJZDlmMj1KODt6GyhC?= In-Reply-To: <2f11576a0605181905m6e0e3520h540ced0fb15a2429@mail.gmail.com> References: <446D1080.7060405@airemix.com> <20060519.095756.31433706.nozomi@biol.tsukuba.ac.jp> <2f11576a0605181905m6e0e3520h540ced0fb15a2429@mail.gmail.com> Message-ID: <20060519.144228.55735062.nozomi@biol.tsukuba.ac.jp> > このプロジェクトの「現実を見よう！」方針からすると、 > 必要ないってことになりませんか。 CP932 -> CP51932 という変換の場合、たとえば 0x81BE -> 0xA2C0 0x879C -> 0xADFC という変換の方が 0x81BE -> 0xA2C0 0x879C -> 0xA2C0 よりありがたいという気がするのですが、 「みんな」がありがたいかと言われると一々聞くわけにも 行かないのでわかりません。ただ、変換元でも変換先でも 区別できるものを、中間の都合で区別を保存せずに積極的に 区別できなくする実装というのが引っかかります。 マイクロソフトの変換仕様に合わせようというのはやりかたの 一つだとは思いますし、またそもそも CP932 なんて Unicode のソースコードではないから round trip なんかできなくても いいんだ、というのもわかるのですが、でも困る状況がある 気がします。 > 外に出せないコードを作るのはもうやめません？ VS の並びを Unicode の規格にしてしまえば外に出せます。 -- のぞみ From nozomi ＠ biol.tsukuba.ac.jp Fri May 19 15:45:00 2006 From: nozomi ＠ biol.tsukuba.ac.jp (Nozomi Ytow) Date: Fri, 19 May 2006 15:45:00 +0900 (JST) Subject: [LE-talk-ja 184] =?iso-2022-jp?b?UmU6IBskQj1FSiNJZDlmMj1KODt6GyhC?= In-Reply-To: <2f11576a0605181905m6e0e3520h540ced0fb15a2429@mail.gmail.com> References: <446D1080.7060405@airemix.com> <20060519.095756.31433706.nozomi@biol.tsukuba.ac.jp> <2f11576a0605181905m6e0e3520h540ced0fb15a2429@mail.gmail.com> Message-ID: <20060519.154500.77414785.nozomi@biol.tsukuba.ac.jp> 少し考え直しました。 > * Microsoftも正規化している > http://support.microsoft.com/default.aspx?scid=kb;ja;JP170559 これは、CP932 から Unicode への変換の話で、CP932 とたとえば CP51932 の間の変換の根拠にはなりませんよね。ただ、たまたま Unicode を中間コードに用いているから、影響があるかもしれない 事ではあるわけです。で、 "小崎資広" wrote: > このプロジェクトの「現実を見よう！」方針からすると、 Unicode を中間コードとして用いるのは現実的なやりかただと思います。 しかし、そこから > 必要ないってことになりませんか。 にはならないんじゃないでしょうか。 Unicode が中間にあるのだ、という実装を仕様に押しつけることなく、 CP932 と CP51932 なりの間の変換が現実的なやりかた、つまり 文字集合の組毎のコンバータを作らずに間に Unicode を使うやりかたで 実現できるなら、CP932 と CP51932 なりの変換仕様としてはむしろ 適切なのではないでしょうか。 「間に入るのがいかんせん Unicode だからねぇ」というのは 必ずしも仕様を束縛すべきではないでしょう。やり方が全くないなら 仕方ありませんが、VS を使えばできなくはありません。 あとは、それを利用して仕様を定義するか、利用せずに実装を 優先するかという問題だと思います。 -- のぞみ From moriyama ＠ miraclelinux.com Fri May 19 18:12:29 2006 From: moriyama ＠ miraclelinux.com (MORIYAMA Masayuki) Date: Fri, 19 May 2006 18:12:29 +0900 (JST) Subject: [LE-talk-ja 185] =?iso-2022-jp?b?UmU6IBskQj1FSiNJZDlmMj1KODt6GyhC?= In-Reply-To: <20060519.144228.55735062.nozomi@biol.tsukuba.ac.jp> References: <2f11576a0605181905m6e0e3520h540ced0fb15a2429@mail.gmail.com> <20060519.144228.55735062.nozomi@biol.tsukuba.ac.jp> Message-ID: <20060519160621.89AE.MORIYAMA@miraclelinux.com> 森山です。 Nozomi Ytow wrote: > > このプロジェクトの「現実を見よう！」方針からすると、 > > 必要ないってことになりませんか。 > > CP932 -> CP51932 という変換の場合、たとえば > 0x81BE -> 0xA2C0 > 0x879C -> 0xADFC > という変換の方が > 0x81BE -> 0xA2C0 > 0x879C -> 0xA2C0 > よりありがたいという気がするのですが、 MS の変換と異なってしまう事によって問題になるケースも出てくるでしょう から、ここの所は慎重に考える必要があると思います。 0x879C というデータは、Windows 上で入力する事は困難な状態になってきて いますので(WindowsNT、WindowsXP ではカットアンドペーストするだけで Unicode での正規化が行われます)、0x879C -> 0xADFC という変換が出来ない ために問題が生じるというケースは、少ないものと思われます。 0x879C -> 0xADFC といった変換を必要とするソフトで個別に対応するのが現実的 なのではないかと思いますが、いかがでしょうか? -- 森山 将之 moriyama ＠ miraclelinux.com ミラクル・リナックス株式会社 From m-kosaki ＠ ceres.dti.ne.jp Fri May 19 18:25:38 2006 From: m-kosaki ＠ ceres.dti.ne.jp (kosaki) Date: Fri, 19 May 2006 18:25:38 +0900 Subject: [LE-talk-ja 186] =?iso-2022-jp?b?UmU6IBskQj1FSiNJZDlmMj1KODt6GyhC?= In-Reply-To: <20060519.144228.55735062.nozomi@biol.tsukuba.ac.jp> References: <2f11576a0605181905m6e0e3520h540ced0fb15a2429@mail.gmail.com> <20060519.144228.55735062.nozomi@biol.tsukuba.ac.jp> Message-ID: <20060519182250.EFAB.M-KOSAKI@ceres.dti.ne.jp> 小崎です。 > > 外に出せないコードを作るのはもうやめません？ > > VS の並びを Unicode の規格にしてしまえば外に出せます。 賛成できるかどうかをさて置くと面白いですね。 ちなみにどういうパスでねじ込む気でいます？ １．どういうパスでコンソーシアムの議題にあげるか ２．理屈で、それはUnicodeを経由する実装がタコいだけじゃん。 規格の問題じゃないよ。っていってくる人たち ３．実装がメンドいからとりあえず反対票入れてくる各種ベンダな 人たち と壁が３つほど、想定されてますけど(n'ω'`) -- kosaki From m-kosaki ＠ ceres.dti.ne.jp Fri May 19 18:26:51 2006 From: m-kosaki ＠ ceres.dti.ne.jp (kosaki) Date: Fri, 19 May 2006 18:26:51 +0900 Subject: [LE-talk-ja 187] =?iso-2022-jp?b?UmU6IBskQj1FSiNJZDlmMj1KODt6GyhC?= In-Reply-To: <2f11576a0605181905m6e0e3520h540ced0fb15a2429@mail.gmail.com> References: <20060519.095756.31433706.nozomi@biol.tsukuba.ac.jp> <2f11576a0605181905m6e0e3520h540ced0fb15a2429@mail.gmail.com> Message-ID: <20060519182544.EFAF.M-KOSAKI@ceres.dti.ne.jp> 小崎です。 ごめんなさい、Gmailの操作方法がよく分からなくておろおろしている間に 誤まって３回もおんなじメールを送信してしまったようです。 混乱させてしまい、申し訳ありません > > * Microsoftも正規化している > > http://support.microsoft.com/default.aspx?scid=kb;ja;JP170559 > > これはするしかなかったからではないかと推測します。 > > > このプロジェクトの「現実を見よう！」方針からすると、 > マイクロソフトが仕方ないと思っているどうかはともかく > 必要ないってことになりませんか。 -- kosaki From hyoshiok ＠ miraclelinux.com Fri May 19 18:31:53 2006 From: hyoshiok ＠ miraclelinux.com (Hiro Yoshioka) Date: Fri, 19 May 2006 18:31:53 +0900 (JST) Subject: [LE-talk-ja 188] =?iso-2022-jp?b?UmU6IExFLXRhbGstamEgGyRCJEcbKEI=?= =?iso-2022-jp?b?GyRCJE41RE9AJE4kXiRIJGEbKEI=?= In-Reply-To: <20060518.154903.36935854.nozomi@biol.tsukuba.ac.jp> References: <22441D30-61EE-47A0-89FF-AB5C6FD4DAB4@mac.com> <20060518.145756.576039588.hyoshiok@miraclelinux.com> <20060518.154903.36935854.nozomi@biol.tsukuba.ac.jp> Message-ID: <20060519.183153.971178319.hyoshiok@miraclelinux.com> よしおかです。 > オフラインミーティングには参加できず残念でしたが、 > 資料が見られ助かっています。 > しかし、すみません、議論を読んでいてわからなくなりました。 今回のミーティングでも、メールでも、かなり明確に 言っていますが、cp932の文字を中心においています。 (これが良いか悪いかはもちろん議論の対象ではありますが) > Hiro Yoshioka wrote: > > よ> クライアントがcp932でPHPとMySQLで組んでいるシステムがあったとして > よ> MySQLとPHPがeuc-jpを使っていたとします。 > よ> それを運用している人が文字化けするからUTF-8に移行するかという話です。 > > cp932 には「はしご高」がある一方、euc-jp の高は「包摂高」なので > euc-jp には「はしご高」も「くち高」もあり得ない (あってる?)、 > だから cp932 と euc-jp は本当は共存できず、UTF-8 に移行した > ところで問題は厳密には解決しない。でも見た目それっぽいくらいなら > できる、というレベルの問題だと思っているのですが、違いますか。 違います。cp932セントリックな立場なので、「はしご高」と「くち高」は わけるという立場です。そのためにeucJPではだめで、eucJP-ms的なものが 必要ということになります。 符号化方式は日本語EUCだけど文字集合はcp932の文字集合という感じに なります。 よ -- Hiro Yoshioka CTO/Miracle Linux Corporation http://blog.miraclelinux.com/yume/ > > そういう意味では、 > > Tomoyuki Asakawa wrote: > > あ> 実際は、メールは、表面的には、MUAだけの問題で解決できるの > あ> で、単純な部類です。 > > と同じ程度だとも言えるし、MUA では実は解決していないとも言える気が。 > > あ> 問題は、メールに限らず、「それ」を格納し、「それ」を、 > あ> 取り出す時 の問題 > あ> どこに格納するかによって、「それ」が、変化してしまう。 > > 文字集合間に(厳密な意味での)互換性がない以上、不可避だと思います。 > 「それ」が格納先の「それ」になってしまう (「包摂高」を > 「はしご高」と「くち高」の格納場所を持ちかつ「包摂高」の > 格納場所を持たない系に格納したら、取り出せるのは > 「はしご高」か「くち高」のいずれかであって「包摂高」ではない) > のは当り前ではないかと。そう考えると Unicode との変換規則は > レガシー側でという発想は理解できます。 > > そこまで細かい事を問うているとは思いませんが、 > 結局は無理な事を求めているのだし、だから実装をいろいろ > 作らざるを得ないのではないかと思います。 > 包摂文字かどうか指定する拡張というのもかつて考えてみたことは > あるのですが、アプリケーション依存 (そんなのマニアしか使わない > ともいう) になりそうなのでやめました。 > > eucJP-ms というのは名前としてはちょっとアレなのでいっそのこと > euc-CPナントカなどもっと直接的なものにしてはどうかと思いますが、 > UTF-8 に移行したところで解決しない問題なので、仮に移行コストを > 度外視しても「UTF-8 にすればいいじゃん」とは言えないよなぁと > 思っています。 > -- > ＮＯＺ 伊藤　希 (のぞみ) > Ｏ　Ｏ > ＺＯＮ > _______________________________________________ > Legacy-Encoding-talk-ja mailing list > Legacy-Encoding-talk-ja ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/legacy-encoding-talk-ja From hyoshiok ＠ miraclelinux.com Fri May 19 18:51:01 2006 From: hyoshiok ＠ miraclelinux.com (Hiro Yoshioka) Date: Fri, 19 May 2006 18:51:01 +0900 (JST) Subject: [LE-talk-ja 189] =?iso-2022-jp?b?UmU6IBskQiUqJVUlaSUkJXMlXyE8GyhC?= =?iso-2022-jp?b?GyRCJUYlIyVzJTAbKEIoMjAwNi8wNS8xNyk=?= In-Reply-To: <446C69F2.8040903@airemix.com> References: <20060502191137.E9C4.MORIYAMA@miraclelinux.com> <446C69F2.8040903@airemix.com> Message-ID: <20060519.185101.35028185.hyoshiok@miraclelinux.com> よしおかです。 メールのフォローがまさに周回遅れでもうしわけないのです。 > 成瀬です。 > 昨日はおつかれさまでした。 おつかれさまでした。 > とりあえず、昨日の会と今日のメール群を見て、 > このプロジェクトの方向性について、 > 概要なりなんなりに追記する必要があると考えました。 > > 勝手にWikiに追記しようとも思ったのですが、 > とりあえずWikiにFAQという項を作っておきました。 > http://legacy-encoding.sourceforge.jp/wiki/index.php?FAQ おおおお、ありがとうございます。 まさにバザールモデル。 > 途中からこのMLを読んでいる方に、 > MLのログを全て読んでもらうのはつらいと思われるので、 > FAQを最初に読めば一通りの流れがわかるようにするとよいかな、と。 素晴しいです。 > ところで、わたしの解釈で、「このプロジェクトの意義」案。 > > 「Legacy Encoding Project」とは、そもそも、 > レガシーエンコーディングを混乱なくフェードアウトさせようというもの。 > > （ミーディングでの乾杯の時に言われていた通り、 > 　「レガシーエンコーディングの更なる発展と繁栄を祈る」 > 　ものではないと、笑。） 皆様のご健勝を祈りますが、レガシーエンコーディングは…(笑 > > これを実現する手段として、[LE-talk-ja 118]にも挙げられている、 > > Windows Codepage 932 で使用可能な文字を Unicode 経由で、日本語EUC > > 符号化方式、7ビットJIS(ISO-2022-JP)符号化方式に変換できるようにする。 > > これが手段となる前提として以下がある。 > * レガシーエンコーディングはJIS系、SJIS系、EUC系の三つ > * 今時の文字コード変換はUnicodeによるUCS正規化で行われる > * よって「キャラクタセット」とはUnicodeとの変換表のこと > * 既に"ISO-2022-JP", "Shift_JIS", "EUC-JP"といった名前の変換表は、 > 　各OSSが提供しているが、独自の変更が加えられていて、変更できない。 > * 変換表のデファクトとしてWindows系のものがある。 > > 以上のような事情から、 > 変換表の名前（キャラクタセット名）は既存のものを使えない > ∵既存のものは別の変換表を指しているから > →別の名前を定義する必要がある > →かと言って全く新しいものを定義するのは混乱を助長する > →CP932, CP51932, eucJP-ms, CP50221 > 　（CP*の典拠はMicrosoftの実装、eucJP-msはTOG/JVC） よ -- Hiro Yoshioka CTO/Miracle Linux Corporation http://blog.miraclelinux.com/yume/ From hyoshiok ＠ miraclelinux.com Fri May 19 19:12:25 2006 From: hyoshiok ＠ miraclelinux.com (Hiro Yoshioka) Date: Fri, 19 May 2006 19:12:25 +0900 (JST) Subject: [LE-talk-ja 190] =?iso-2022-jp?b?UmU6IBskQj1FSiNJZDlmMj1KODt6GyhC?= In-Reply-To: <20060519.102251.35028892.nozomi@biol.tsukuba.ac.jp> References: <20060519.095756.31433706.nozomi@biol.tsukuba.ac.jp> <446D1B18.5020501@airemix.com> <20060519.102251.35028892.nozomi@biol.tsukuba.ac.jp> Message-ID: <20060519.191225.521625148.hyoshiok@miraclelinux.com> 下記IVSのサポートは、レガシーエンコーディングではないので、 今回のプロジェクトの範囲外というのがわたしの理解です。 しかし、グリフの選択を文字コードレベルでやるというのは あきらかにやりすぎだと個人的には思います。 よ -- Hiro Yoshioka CTO/Miracle Linux Corporation http://blog.miraclelinux.com/yume/ From: Nozomi Ytow Subject: [LE-talk-ja 168] Re: 重複符号化文字 Date: Fri, 19 May 2006 10:22:51 +0900 (JST) Message-ID: <20060519.102251.35028892.nozomi ＠ biol.tsukuba.ac.jp> > > うーん、U+FFFFを越えてしまう時点でnkf的には及び腰です。 > > はて。IVS ではなく VS (U+FE00-U+FE0F) を abuse しようと > 言っているのですが。元の input stream に VS が現れた場合は > 同じ VS or VS1 を追加してエスケープすれば処理できるでしょう。 > > > また、Ideographic Variation Databaseを考えると、 > > あまりに危険な手法に感じます。 > > IVS のどのあたりがでしょうか。私は Unicode をちゃんと使うなら > やらねばならない事だと思っていますが。 > -- > のぞみ > _______________________________________________ > Legacy-Encoding-talk-ja mailing list > Legacy-Encoding-talk-ja ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/legacy-encoding-talk-ja From nozomi ＠ biol.tsukuba.ac.jp Fri May 19 19:37:44 2006 From: nozomi ＠ biol.tsukuba.ac.jp (Nozomi Ytow) Date: Fri, 19 May 2006 19:37:44 +0900 (JST) Subject: [LE-talk-ja 191] =?iso-2022-jp?b?UmU6IExFLXRhbGstamEgGyRCJEcbKEI=?= =?iso-2022-jp?b?GyRCJE41RE9AJE4kXiRIJGEbKEI=?= In-Reply-To: <20060519.183153.971178319.hyoshiok@miraclelinux.com> References: <20060518.145756.576039588.hyoshiok@miraclelinux.com> <20060518.154903.36935854.nozomi@biol.tsukuba.ac.jp> <20060519.183153.971178319.hyoshiok@miraclelinux.com> Message-ID: <20060519.193744.108746580.nozomi@biol.tsukuba.ac.jp> よ> クライアントがcp932でPHPとMySQLで組んでいるシステムがあったとして よ> MySQLとPHPがeuc-jpを使っていたとします。 > cp932セントリックな立場なので、「はしご高」と「くち高」は > わけるという立場です。そのためにeucJPではだめで、eucJP-ms的なものが > 必要ということになります。 MySQL...がeuc-jpを使っていたというのを ujis の意味で とらえたのですが、そうでなくてeucjpms の意味? > 符号化方式は日本語EUCだけど文字集合はcp932の文字集合という感じに > なります。 了解。 -- のぞみ From nozomi ＠ biol.tsukuba.ac.jp Fri May 19 19:44:36 2006 From: nozomi ＠ biol.tsukuba.ac.jp (Nozomi Ytow) Date: Fri, 19 May 2006 19:44:36 +0900 (JST) Subject: [LE-talk-ja 192] =?iso-2022-jp?b?UmU6IBskQj1FSiNJZDlmMj1KODt6GyhC?= In-Reply-To: <20060519160621.89AE.MORIYAMA@miraclelinux.com> References: <2f11576a0605181905m6e0e3520h540ced0fb15a2429@mail.gmail.com> <20060519.144228.55735062.nozomi@biol.tsukuba.ac.jp> <20060519160621.89AE.MORIYAMA@miraclelinux.com> Message-ID: <20060519.194436.71095420.nozomi@biol.tsukuba.ac.jp> > MS の変換と異なってしまう事によって問題になるケースも出てくる > でしょうから、ここの所は慎重に考える必要があると思います。 はい。いっそのこと、マイクロソフトの定める通りに実装します、 と明言していただく方がすっきりする気がします。 > 0x879C -> 0xADFC といった変換を必要とするソフトで個別に > 対応するのが現実的なのではないかと思いますが、いかがでしょうか? Windows NT 以前のレガシーデータがどれくらいあるのか感触として わからないので、なんとも。 -- のぞみ From nozomi ＠ biol.tsukuba.ac.jp Fri May 19 19:56:04 2006 From: nozomi ＠ biol.tsukuba.ac.jp (Nozomi Ytow) Date: Fri, 19 May 2006 19:56:04 +0900 (JST) Subject: [LE-talk-ja 193] =?iso-2022-jp?b?UmU6IBskQj1FSiNJZDlmMj1KODt6GyhC?= In-Reply-To: <20060519182250.EFAB.M-KOSAKI@ceres.dti.ne.jp> References: <2f11576a0605181905m6e0e3520h540ced0fb15a2429@mail.gmail.com> <20060519.144228.55735062.nozomi@biol.tsukuba.ac.jp> <20060519182250.EFAB.M-KOSAKI@ceres.dti.ne.jp> Message-ID: <20060519.195604.104037919.nozomi@biol.tsukuba.ac.jp> > > VS の並びを Unicode の規格にしてしまえば外に出せます。 > ちなみにどういうパスでねじ込む気でいます？ 内部的にのみ使う事を想定しているのであまりネジ込む気は ないのですが、 > １．どういうパスでコンソーシアムの議題にあげるか > ２．理屈で、それはUnicodeを経由する実装がタコいだけじゃん。 > 規格の問題じゃないよ。っていってくる人たち > ３．実装がメンドいからとりあえず反対票入れてくる各種ベンダな > 人たち > と壁が３つほど、想定されてますけど(n'ω'`) 3 は仕方ないとして、一番難しいのは 2 ですね。 Unicode を経由する実装以前に、対象文字集合がアカンのですから、 言われて当然です。1 は問題をストレートにアピールするしかないのでは。 -- のぞみ From m-kosaki ＠ ceres.dti.ne.jp Fri May 19 20:10:13 2006 From: m-kosaki ＠ ceres.dti.ne.jp (kosaki) Date: Fri, 19 May 2006 20:10:13 +0900 Subject: [LE-talk-ja 194] =?iso-2022-jp?b?UmU6IDUvMTcgGyRCJSolVSVpJSQbKEI=?= =?iso-2022-jp?b?GyRCJXMlXyE8JUYlIyVzJTAkXiRIJGEbKEI=?= In-Reply-To: <20060519.144126.115906589.nishida@miraclelinux.com> References: <20060519.144126.115906589.nishida@miraclelinux.com> Message-ID: <20060519200618.AB06.M-KOSAKI@ceres.dti.ne.jp> 小崎です。 > * CP51932 (Windows の EUC-JP のコードページ) について > - CP51932 は必要ないのでは? > あまり議論されず。 すいませーん。 誰かオイラに逆にCP51932だけで、eucJP-msやめちゃったら困る人たちの 例を教えてください。 eucJP-ms欲しい人って ・あとからCP932に戻すので、情報落ちがないこと ・unixなツールで処理するのでMSBみたらASCIIかどうか分かる EUCな性質が保持されていること の２点しか求めていないんじゃないの？？ という気が昨日から猛烈にしてきているんですが。 -- kosaki From umq.876 ＠ gmail.com Fri May 19 20:26:02 2006 From: umq.876 ＠ gmail.com (Hirohisa Yamaguchi) Date: Fri, 19 May 2006 20:26:02 +0900 Subject: [LE-talk-ja 195] =?iso-2022-jp?b?UmU6IDUvMTcgGyRCJSolVSVpJSQbKEI=?= =?iso-2022-jp?b?GyRCJXMlXyE8JUYlIyVzJTAkXiRIJGEbKEI=?= In-Reply-To: <20060519200618.AB06.M-KOSAKI@ceres.dti.ne.jp> References: <20060519.144126.115906589.nishida@miraclelinux.com> <20060519200618.AB06.M-KOSAKI@ceres.dti.ne.jp> Message-ID: <1dba65f30605190426l24a9d638m675d65c189e32706@mail.gmail.com> やまぐちです On 5/19/06, kosaki wrote: > > * CP51932 (Windows の EUC-JP のコードページ) について > > - CP51932 は必要ないのでは? > > あまり議論されず。 > すいませーん。 > 誰かオイラに逆にCP51932だけで、eucJP-msやめちゃったら困る人たちの > 例を教えてください。 困るかどうかはお構いナシに、やめられないでしょう :) > eucJP-ms欲しい人って > ・あとからCP932に戻すので、情報落ちがないこと > ・unixなツールで処理するのでMSBみたらASCIIかどうか分かる > EUCな性質が保持されていること > の２点しか求めていないんじゃないの？？ > という気が昨日から猛烈にしてきているんですが。 で、その2点の前者については、cp932 なバイト列から iconv -f cp932 -t eucJP-ms のように直接変換すれば成り立つでしょう。 実際には、クライアントサイドで cp51932 に変換してしまったものを そのまま放り込んでいる、というような例が多いという話が この ml でも以前に指摘されているように、 運用上うまくいっていないのではないかと思います。 これも、名前が悪かったかなぁとも思います。 -- end やまきゅう umq.876 ＠ gmail.com From moriyama ＠ miraclelinux.com Fri May 19 20:39:42 2006 From: moriyama ＠ miraclelinux.com (MORIYAMA Masayuki) Date: Fri, 19 May 2006 20:39:42 +0900 (JST) Subject: [LE-talk-ja 196] =?iso-2022-jp?b?UmU6IExFLXRhbGstamEgGyRCJEcbKEI=?= =?iso-2022-jp?b?GyRCJE41RE9AJE4kXiRIJGEbKEI=?= In-Reply-To: References: Message-ID: <20060519182059.89B7.MORIYAMA@miraclelinux.com> 森山です。 Tomoyuki Asakawa wrote: > 最近は、UNIX系で作成された、OSSが,Windowsでも > 動作するので > OSS系は、EUC系 <-> UNICODE <-> SJIS系 > の変換が充実していればいい。 > なので、JIS系の変換ってメールぐらいにしか、必要性ないので > は？ テキストエディタ系では必要になってくるのではないでしょうか? あと、メールのアーカイブを処理するようなソフトでも必要になってくると思 います。 -- 森山 将之 moriyama ＠ miraclelinux.com ミラクル・リナックス株式会社 From moriyama ＠ miraclelinux.com Fri May 19 20:39:42 2006 From: moriyama ＠ miraclelinux.com (MORIYAMA Masayuki) Date: Fri, 19 May 2006 20:39:42 +0900 (JST) Subject: [LE-talk-ja 197] =?iso-2022-jp?b?UmU6IExFLXRhbGstamEgGyRCJEcbKEI=?= =?iso-2022-jp?b?GyRCJE41RE9AJE4kXiRIJGEbKEI=?= In-Reply-To: <20060518.202224.18290788.nozomi@biol.tsukuba.ac.jp> References: <20060518165956.8980.MORIYAMA@miraclelinux.com> <20060518.202224.18290788.nozomi@biol.tsukuba.ac.jp> Message-ID: <20060519185023.89BA.MORIYAMA@miraclelinux.com> 森山です。 Nozomi Ytow wrote: > MORIYAMA Masayuki wrote: > > > TOG/JVC(オープングループ/日本ベンダ協議会) で eucJP-ms という名前が使 > > 用されていますので、それを使っています。 > > 了解。で、ISO-2022-JP-MS の方は...ISO-2022-CP932 じゃだめですか。 > たかが名前ではあるのですが。 ここのメーリングリストで、新しい名前を作るという事に関しては、反対され ていますので、ISO-2022-CP932 にしたところで反対されるのだろうと思います。 ISO-2022-JP-MS ではなく、CP50221 の方を実装する方が好ましいという意見 が複数でていますので、CP50221 の方を実際に実装する方向で考えています。 http://legacy-encoding.sourceforge.jp/wiki/index.php?cp50221 -- 森山 将之 moriyama ＠ miraclelinux.com ミラクル・リナックス株式会社 From moriyama ＠ miraclelinux.com Fri May 19 20:39:42 2006 From: moriyama ＠ miraclelinux.com (MORIYAMA Masayuki) Date: Fri, 19 May 2006 20:39:42 +0900 (JST) Subject: [LE-talk-ja 198] =?iso-2022-jp?b?UmU6IDUvMTcgGyRCJSolVSVpJSQbKEI=?= =?iso-2022-jp?b?GyRCJXMlXyE8JUYlIyVzJTAkXiRIJGEbKEI=?= In-Reply-To: <20060519200618.AB06.M-KOSAKI@ceres.dti.ne.jp> References: <20060519.144126.115906589.nishida@miraclelinux.com> <20060519200618.AB06.M-KOSAKI@ceres.dti.ne.jp> Message-ID: <20060519201544.89C9.MORIYAMA@miraclelinux.com> 森山です。 kosaki wrote: > 小崎です。 > > > * CP51932 (Windows の EUC-JP のコードページ) について > > - CP51932 は必要ないのでは? > > あまり議論されず。 > > すいませーん。 > 誰かオイラに逆にCP51932だけで、eucJP-msやめちゃったら困る人たちの > 例を教えてください。 すでに、PostgreSQL の EUC_JP や MySQL の eucjpms、PHP の eucJP-win、そ して Linux kernel NLS の euc-jp などが eucJP-ms (eucJP-open) だったり しますが、cp51932 を扱えるソフトは、OSS ではほとんど見かけないという状 態ですので、互換性を考えれば残しておかないと困ると思います。 eucJP-ms が正しく理解され、適切に使われているかどうかは別の問題と考え ています。 - 森山 将之 moriyama ＠ miraclelinux.com ミラクル・リナックス株式会社 From m-kosaki ＠ ceres.dti.ne.jp Fri May 19 20:41:19 2006 From: m-kosaki ＠ ceres.dti.ne.jp (kosaki) Date: Fri, 19 May 2006 20:41:19 +0900 Subject: [LE-talk-ja 199] =?iso-2022-jp?b?UmU6IDUvMTcgGyRCJSolVSVpJSQbKEI=?= =?iso-2022-jp?b?GyRCJXMlXyE8JUYlIyVzJTAkXiRIJGEbKEI=?= In-Reply-To: <1dba65f30605190426l24a9d638m675d65c189e32706@mail.gmail.com> References: <20060519200618.AB06.M-KOSAKI@ceres.dti.ne.jp> <1dba65f30605190426l24a9d638m675d65c189e32706@mail.gmail.com> Message-ID: <20060519203343.AB09.M-KOSAKI@ceres.dti.ne.jp> 小崎です。 > > > * CP51932 (Windows の EUC-JP のコードページ) について > > > - CP51932 は必要ないのでは? > > > あまり議論されず。 > > > すいませーん。 > > 誰かオイラに逆にCP51932だけで、eucJP-msやめちゃったら困る人たちの > > 例を教えてください。 > > 困るかどうかはお構いナシに、やめられないでしょう :) よく分からなかったので教えてくださいませ。 僕はもしも困る人が本当にいないんだったらやめられると思いますよ ＃いると思うんですが > > eucJP-ms欲しい人って > > > ・あとからCP932に戻すので、情報落ちがないこと > > ・unixなツールで処理するのでMSBみたらASCIIかどうか分かる > > EUCな性質が保持されていること > > > の２点しか求めていないんじゃないの？？ > > という気が昨日から猛烈にしてきているんですが。 > > で、その2点の前者については、cp932 なバイト列から > iconv -f cp932 -t eucJP-ms のように直接変換すれば成り立つでしょう。 > 実際には、クライアントサイドで cp51932 に変換してしまったものを > そのまま放り込んでいる、というような例が多いという話が > この ml でも以前に指摘されているように、 > 運用上うまくいっていないのではないかと思います。 > > これも、名前が悪かったかなぁとも思います。 僕も実運用としてピュアなeucJP-msでデータが蓄積されている例って 思いつかなくて、結局cp51932とごっちゃになってる例が多いと 思っています。 でも、それなら、やめられますよね。 そういう人たちはCP51932に移行したって失うものはないですよ。 あーっと、補足。 どっちかというと実装の有無よりもドキュメントの方を気にしています。 実装がそんなに大変じゃないのは僕でも分かる。 eucJP-msを推奨して行くのか、CP51932を推奨して行くのか、 はたまた共存させるんだったら、どういう基準で使い分けろと 一般プログラマーに啓蒙していくのか。 同じ事を何回も書いて申し訳ないが、ガイドラインなしで 変換テーブルだけ増やしても事態が好転するとはまったく思えないんですよ。 SJISとCP932が分かれているだけでも大混乱して文字化けさせまくる プログラマーはたくさんいるんですよ。 -- kosaki From kazama ＠ mac.com Fri May 19 20:45:51 2006 From: kazama ＠ mac.com (Kazuhiro Kazama) Date: Fri, 19 May 2006 20:45:51 +0900 Subject: [LE-talk-ja 200] =?iso-2022-jp?b?UmU6IDUvMTcgGyRCJSolVSVpJSQbKEI=?= =?iso-2022-jp?b?GyRCJXMlXyE8JUYlIyVzJTAkXiRIJGEbKEI=?= In-Reply-To: <1dba65f30605190426l24a9d638m675d65c189e32706@mail.gmail.com> References: <20060519.144126.115906589.nishida@miraclelinux.com> <20060519200618.AB06.M-KOSAKI@ceres.dti.ne.jp> <1dba65f30605190426l24a9d638m675d65c189e32706@mail.gmail.com> Message-ID: <923F4F0C-F5F0-485B-BE33-476E1F3B59B6@mac.com> On 2006/05/19, at 20:26, Hirohisa Yamaguchi wrote: > On 5/19/06, kosaki wrote: >>> * CP51932 (Windows の EUC-JP のコードページ) について >>> - CP51932 は必要ないのでは? >>> あまり議論されず。 > >> すいませーん。 >> 誰かオイラに逆にCP51932だけで、eucJP-msやめちゃったら困る人たちの >> 例を教えてください。 > > 困るかどうかはお構いナシに、やめられないでしょう :) 一旦使い始めたものは，なかなか止められないですからね．OSC2006を見る と，あきらかにeucJP-msのサポート率は高いので，これを止めるのは無理かと． ただ，eucJP-msの方はそれ以上広げないという選択肢は，ここで話し合っても いいかと思っています． 森山さんと話した時にも，結局CP51932がなかった（存在が知られていなかっ た）から，代わりにeucJP-msを使い始めたのであって，最初からCP51932が あったら使っていなかったのでは？という話がありましたから．それなら，現 在サポートしていない環境では，cp51932だけでいいという解もあるのかなあ と． ただし，これは単にCP51932の代替としてしかeucJP-msを使っていないこと， またそれが他に影響を及ぼさないという前提が成り立つ場合だけですけど．ど うなんですかね？ > で、その2点の前者については、cp932 なバイト列から > iconv -f cp932 -t eucJP-ms のように直接変換すれば成り立つでしょう。 > 実際には、クライアントサイドで cp51932 に変換してしまったものを > そのまま放り込んでいる、というような例が多いという話が > この ml でも以前に指摘されているように、 > 運用上うまくいっていないのではないかと思います。 これは気になります．運用上の問題点を，もう少し詳しく教えてもらえますか？ > これも、名前が悪かったかなぁとも思います。 名前に関しては，いろいろな人がいろいろな文句を聞きますが，それらの意見 を総合すると結構名前を変えなければならないので，もう単なる識別子とし て，それ以上踏み込まないで諦めた方がよいかと（苦笑） --- 風間 一洋 (kazama ＠ mac.com) From m-kosaki ＠ ceres.dti.ne.jp Fri May 19 20:47:47 2006 From: m-kosaki ＠ ceres.dti.ne.jp (kosaki) Date: Fri, 19 May 2006 20:47:47 +0900 Subject: [LE-talk-ja 201] =?iso-2022-jp?b?UmU6IDUvMTcgGyRCJSolVSVpJSQbKEI=?= =?iso-2022-jp?b?GyRCJXMlXyE8JUYlIyVzJTAkXiRIJGEbKEI=?= In-Reply-To: <20060519201544.89C9.MORIYAMA@miraclelinux.com> References: <20060519200618.AB06.M-KOSAKI@ceres.dti.ne.jp> <20060519201544.89C9.MORIYAMA@miraclelinux.com> Message-ID: <20060519204522.AB0F.M-KOSAKI@ceres.dti.ne.jp> 小崎です。 > すでに、PostgreSQL の EUC_JP や MySQL の eucjpms、PHP の eucJP-win、そ > して Linux kernel NLS の euc-jp などが eucJP-ms (eucJP-open) だったり > しますが、cp51932 を扱えるソフトは、OSS ではほとんど見かけないという状 > 態ですので、互換性を考えれば残しておかないと困ると思います。 OK. これは非常にこのプロジェクトの現実重視的な回答で私的には満足です。 > eucJP-ms が正しく理解され、適切に使われているかどうかは別の問題と考え > ています。 んでも、ガイドラインどうしようってのは上記OSSのコミュニティ交えて 相談したほうがいいかもしれませんね。 使う人が考えればいいじゃん方針反対。 スクリプト書く人が全員文字コードヲタクだと仮定するのは間違ってる。 -- kosaki From kazama ＠ mac.com Fri May 19 20:54:19 2006 From: kazama ＠ mac.com (Kazuhiro Kazama) Date: Fri, 19 May 2006 20:54:19 +0900 Subject: [LE-talk-ja 202] =?iso-2022-jp?b?UmU6IDUvMTcgGyRCJSolVSVpJSQbKEI=?= =?iso-2022-jp?b?GyRCJXMlXyE8JUYlIyVzJTAkXiRIJGEbKEI=?= In-Reply-To: <20060519201544.89C9.MORIYAMA@miraclelinux.com> References: <20060519.144126.115906589.nishida@miraclelinux.com> <20060519200618.AB06.M-KOSAKI@ceres.dti.ne.jp> <20060519201544.89C9.MORIYAMA@miraclelinux.com> Message-ID: <0687E6EA-23EE-4F23-9518-959600496C76@mac.com> On 2006/05/19, at 20:39, MORIYAMA Masayuki wrote: > eucJP-ms が正しく理解され、適切に使われているかどうかは別の問題と考え > ています。 私はeucJP-msの問題をまだ把握していないんだけど，もしCP51932を使えば問 題が起こらないよということなら，それを今回のCP51932の実装・追加理由と して明記して，今後実装する人達の指針にしてもらうのはよいことだと思いま す． --- 風間 一洋 (kazama ＠ mac.com) From m-kosaki ＠ ceres.dti.ne.jp Fri May 19 20:57:11 2006 From: m-kosaki ＠ ceres.dti.ne.jp (kosaki) Date: Fri, 19 May 2006 20:57:11 +0900 Subject: [LE-talk-ja 203] =?iso-2022-jp?b?UmU6IDUvMTcgGyRCJSolVSVpJSQbKEI=?= =?iso-2022-jp?b?GyRCJXMlXyE8JUYlIyVzJTAkXiRIJGEbKEI=?= In-Reply-To: <923F4F0C-F5F0-485B-BE33-476E1F3B59B6@mac.com> References: <1dba65f30605190426l24a9d638m675d65c189e32706@mail.gmail.com> <923F4F0C-F5F0-485B-BE33-476E1F3B59B6@mac.com> Message-ID: <20060519204930.AB12.M-KOSAKI@ceres.dti.ne.jp> 小崎です。 > > 困るかどうかはお構いナシに、やめられないでしょう :) > > 一旦使い始めたものは，なかなか止められないですからね．OSC2006を見る > と，あきらかにeucJP-msのサポート率は高いので，これを止めるのは無理かと． > > ただ，eucJP-msの方はそれ以上広げないという選択肢は，ここで話し合っても > いいかと思っています． > > 森山さんと話した時にも，結局CP51932がなかった（存在が知られていなかっ > た）から，代わりにeucJP-msを使い始めたのであって，最初からCP51932が > あったら使っていなかったのでは？という話がありましたから．それなら，現 > 在サポートしていない環境では，cp51932だけでいいという解もあるのかなあ > と． > > ただし，これは単にCP51932の代替としてしかeucJP-msを使っていないこと， > またそれが他に影響を及ぼさないという前提が成り立つ場合だけですけど．ど > うなんですかね？ 風間さんのメールでおいらが言いたいことは言い尽くされていて （もやもやして言語化出来ていなかった部分まで！） ちゃんと証明できませんが、おもいっきり推測ですが、 eucJP-ms の用途はCP51932の代替としてしか使っていないと推測していて eucJP-msは互換性のためにサポート、今後はWindows互換なEUCとしては CP51932を推奨して行きますよー ってのが、最終的にみんなが倖せになれるんじゃないかと予想しています。 繰り返すけど、これはただの予想ね。 でもって、自信がないので、ガイドラインの落としどころはぜひ議論したい。 -- kosaki From umq.876 ＠ gmail.com Fri May 19 20:58:40 2006 From: umq.876 ＠ gmail.com (Hirohisa Yamaguchi) Date: Fri, 19 May 2006 20:58:40 +0900 Subject: [LE-talk-ja 204] =?iso-2022-jp?b?UmU6IDUvMTcgGyRCJSolVSVpJSQbKEI=?= =?iso-2022-jp?b?GyRCJXMlXyE8JUYlIyVzJTAkXiRIJGEbKEI=?= In-Reply-To: <923F4F0C-F5F0-485B-BE33-476E1F3B59B6@mac.com> References: <20060519.144126.115906589.nishida@miraclelinux.com> <20060519200618.AB06.M-KOSAKI@ceres.dti.ne.jp> <1dba65f30605190426l24a9d638m675d65c189e32706@mail.gmail.com> <923F4F0C-F5F0-485B-BE33-476E1F3B59B6@mac.com> Message-ID: <1dba65f30605190458o2c1db852r6bdc104e8006a73b@mail.gmail.com> やまぐちです On 5/19/06, Kazuhiro Kazama wrote: > > で、その2点の前者については、cp932 なバイト列から > > iconv -f cp932 -t eucJP-ms のように直接変換すれば成り立つでしょう。 > > 実際には、クライアントサイドで cp51932 に変換してしまったものを > > そのまま放り込んでいる、というような例が多いという話が > > この ml でも以前に指摘されているように、 > > 運用上うまくいっていないのではないかと思います。 > これは気になります．運用上の問題点を，もう少し詳しく教えてもらえますか？ 「運用上」は言葉のあやでいいすぎかとおもいますが ここ3年ぐらいの間に、UTF-8 への migration に失敗した経験が 2度ほどあります。 # 自分の経験だけで、他で見聞きしたというわけではありません > > これも、名前が悪かったかなぁとも思います。 > 名前に関しては，いろいろな人がいろいろな文句を聞きますが，それらの意見 > を総合すると結構名前を変えなければならないので，もう単なる識別子とし > て，それ以上踏み込まないで諦めた方がよいかと（苦笑） あ、これから変えよう、とかそういうことではなくて、感想です。 -- end やまきゅう umq.876 ＠ gmail.com From m-kosaki ＠ ceres.dti.ne.jp Fri May 19 21:00:41 2006 From: m-kosaki ＠ ceres.dti.ne.jp (kosaki) Date: Fri, 19 May 2006 21:00:41 +0900 Subject: [LE-talk-ja 205] =?iso-2022-jp?b?UmU6IDUvMTcgGyRCJSolVSVpJSQbKEI=?= =?iso-2022-jp?b?GyRCJXMlXyE8JUYlIyVzJTAkXiRIJGEbKEI=?= In-Reply-To: <0687E6EA-23EE-4F23-9518-959600496C76@mac.com> References: <20060519201544.89C9.MORIYAMA@miraclelinux.com> <0687E6EA-23EE-4F23-9518-959600496C76@mac.com> Message-ID: <20060519205753.AB15.M-KOSAKI@ceres.dti.ne.jp> 小崎です。 > > eucJP-ms が正しく理解され、適切に使われているかどうかは別の問題と考え > > ています。 > > 私はeucJP-msの問題をまだ把握していないんだけど，もしCP51932を使えば問 > 題が起こらないよということなら，それを今回のCP51932の実装・追加理由と > して明記して，今後実装する人達の指針にしてもらうのはよいことだと思いま > す． これは > 実際には、クライアントサイドで cp51932 に変換してしまったものを > そのまま放り込んでいる、というような例が多いという話が > この ml でも以前に指摘されているように、 これが答えだと思います。 つまりEUCと名乗ってきたヤカラをCP51932 -> eucJP-ms 変換せずに ローカルに保存していく実装がおおくて、結局データとしては CP51932とeucJP-ms が混じってしまっていて、 まる１とかは文字化けしちゃってますね。現状。 という指摘だと思います。 -- kosaki From m-kosaki ＠ ceres.dti.ne.jp Fri May 19 21:05:35 2006 From: m-kosaki ＠ ceres.dti.ne.jp (kosaki) Date: Fri, 19 May 2006 21:05:35 +0900 Subject: [LE-talk-ja 206] =?iso-2022-jp?b?UmU6IExFLXRhbGstamEgGyRCJEcbKEI=?= =?iso-2022-jp?b?GyRCJE41RE9AJE4kXiRIJGEbKEI=?= In-Reply-To: <20060519182059.89B7.MORIYAMA@miraclelinux.com> References: <20060519182059.89B7.MORIYAMA@miraclelinux.com> Message-ID: <20060519204210.AB0C.M-KOSAKI@ceres.dti.ne.jp> 小崎です。 やや脱線気味のレス > テキストエディタ系では必要になってくるのではないでしょうか? LinuxでISO2022系あつかえるエディタってemacsしか 思いつかないんですけど・・・(^^; ＃ヤツは文字コード変換を自前でやるからこのプロジェクトの ＃スコープ外な気がする > あと、メールのアーカイブを処理するようなソフトでも必要になってくると思 > います。 これは完全に同意。 -- kosaki From kazama ＠ mac.com Fri May 19 21:08:33 2006 From: kazama ＠ mac.com (Kazuhiro Kazama) Date: Fri, 19 May 2006 21:08:33 +0900 Subject: [LE-talk-ja 207] =?iso-2022-jp?b?UmU6IDUvMTcgGyRCJSolVSVpJSQbKEI=?= =?iso-2022-jp?b?GyRCJXMlXyE8JUYlIyVzJTAkXiRIJGEbKEI=?= In-Reply-To: <20060519.144126.115906589.nishida@miraclelinux.com> References: <20060519.144126.115906589.nishida@miraclelinux.com> Message-ID: <551E684C-C70E-454F-BED0-3612AF169F08@mac.com> 西田さん，議題整理，どうもごくろうさまです． On 2006/05/19, at 14:41, Shigeo Nishida wrote: > - JIS X 0213 対応は? > PostgreSQL で JIS X 0213 対応と称して新しい LE 追加の動きがある > ということが報告された。 これって，具体的に何を追加するって話だったでしょうか？Shift_JIS-2004と か全部？EUC-JP-2004だけ？ ＃ すみません．鶏頭なので…特にアルコールが入ると…（泣）． --- 風間 一洋 (kazama ＠ mac.com) From hyoshiok ＠ miraclelinux.com Fri May 19 21:09:10 2006 From: hyoshiok ＠ miraclelinux.com (Hiro Yoshioka) Date: Fri, 19 May 2006 21:09:10 +0900 (JST) Subject: [LE-talk-ja 208] =?iso-2022-jp?b?UmU6IDUvMTcgGyRCJSolVSVpJSQbKEI=?= =?iso-2022-jp?b?GyRCJXMlXyE8JUYlIyVzJTAkXiRIJGEbKEI=?= In-Reply-To: <20060519204522.AB0F.M-KOSAKI@ceres.dti.ne.jp> References: <20060519200618.AB06.M-KOSAKI@ceres.dti.ne.jp> <20060519201544.89C9.MORIYAMA@miraclelinux.com> <20060519204522.AB0F.M-KOSAKI@ceres.dti.ne.jp> Message-ID: <20060519.210910.660860983.hyoshiok@miraclelinux.com> よしおかです。 > 小崎です。 こんにちは、 snip > > eucJP-ms が正しく理解され、適切に使われているかどうかは別の問題と考え > > ています。 > > んでも、ガイドラインどうしようってのは上記OSSのコミュニティ交えて > 相談したほうがいいかもしれませんね。 おっしゃるとおりだと思います。 > 使う人が考えればいいじゃん方針反対。 > スクリプト書く人が全員文字コードヲタクだと仮定するのは間違ってる。 ガイドライン重要、 コミュニティアライアンス重要、 おっしゃるとおりですので、各OSSコミュニティへのマーケティング広報 活動をしつつ、とりすすめたいと思います。 Perlの弾さんに直で連絡をしなかったのはわたしのミスですから。 ごめんなさい。 よ -- Hiro Yoshioka CTO/Miracle Linux Corporation http://blog.miraclelinux.com/yume/ From hyoshiok ＠ miraclelinux.com Fri May 19 21:13:06 2006 From: hyoshiok ＠ miraclelinux.com (Hiro Yoshioka) Date: Fri, 19 May 2006 21:13:06 +0900 (JST) Subject: [LE-talk-ja 209] =?iso-2022-jp?b?UmU6IDUvMTcgGyRCJSolVSVpJSQbKEI=?= =?iso-2022-jp?b?GyRCJXMlXyE8JUYlIyVzJTAkXiRIJGEbKEI=?= In-Reply-To: <1dba65f30605190458o2c1db852r6bdc104e8006a73b@mail.gmail.com> References: <1dba65f30605190426l24a9d638m675d65c189e32706@mail.gmail.com> <923F4F0C-F5F0-485B-BE33-476E1F3B59B6@mac.com> <1dba65f30605190458o2c1db852r6bdc104e8006a73b@mail.gmail.com> Message-ID: <20060519.211306.149823907.hyoshiok@miraclelinux.com> よしおかです。 > やまぐちです こんにちは、 > On 5/19/06, Kazuhiro Kazama wrote: > > > で、その2点の前者については、cp932 なバイト列から > > > iconv -f cp932 -t eucJP-ms のように直接変換すれば成り立つでしょう。 > > > 実際には、クライアントサイドで cp51932 に変換してしまったものを > > > そのまま放り込んでいる、というような例が多いという話が > > > この ml でも以前に指摘されているように、 > > > 運用上うまくいっていないのではないかと思います。 > > > これは気になります．運用上の問題点を，もう少し詳しく教えてもらえますか？ > > 「運用上」は言葉のあやでいいすぎかとおもいますが > ここ3年ぐらいの間に、UTF-8 への migration に失敗した経験が > 2度ほどあります。 > # 自分の経験だけで、他で見聞きしたというわけではありません 具体的に何が問題で失敗しちゃったのでしょうか？ さしつかえなければ、ぜひ、教えてください。 そのような実例を積み重ねることによって、よりよい理解が 深まると考えます。 よ -- Hiro Yoshioka CTO/Miracle Linux Corporation http://blog.miraclelinux.com/yume/ From kazama ＠ mac.com Fri May 19 21:24:24 2006 From: kazama ＠ mac.com (Kazuhiro Kazama) Date: Fri, 19 May 2006 21:24:24 +0900 Subject: [LE-talk-ja 210] =?iso-2022-jp?b?UmU6IDUvMTcgGyRCJSolVSVpJSQbKEI=?= =?iso-2022-jp?b?GyRCJXMlXyE8JUYlIyVzJTAkXiRIJGEbKEI=?= In-Reply-To: <20060519205753.AB15.M-KOSAKI@ceres.dti.ne.jp> References: <20060519201544.89C9.MORIYAMA@miraclelinux.com> <0687E6EA-23EE-4F23-9518-959600496C76@mac.com> <20060519205753.AB15.M-KOSAKI@ceres.dti.ne.jp> Message-ID: <792A0DD4-564E-4082-A709-3DFB815F44DF@mac.com> 小崎さん， On 2006/05/19, at 21:00, kosaki wrote: > これは > >> 実際には、クライアントサイドで cp51932 に変換してしまったものを >> そのまま放り込んでいる、というような例が多いという話が >> この ml でも以前に指摘されているように、 > > これが答えだと思います。 > つまりEUCと名乗ってきたヤカラをCP51932 -> eucJP-ms 変換せずに > ローカルに保存していく実装がおおくて、結局データとしては > CP51932とeucJP-ms が混じってしまっていて、 > まる１とかは文字化けしちゃってますね。現状。 > > という指摘だと思います。 ようやく理解しました（お手数を掛けてしまって，ごめんなさい）． 結局次のようなことでいいんでしょうか？ (->は「互換」，->>は「上位互 換」の意味) ・EUC-JPに対して，CP51932，eucJP-ms，EUC-JP-2004はそれぞれ上位互換であ る． ・CP932とCP51932は互換, CP932とeucJP-ms，EUC-JP-2004はそれぞれ互換であ る． ・しかし，CP51932とeucJP-ms，EUC-JP-2004は互換でない． ・特に，CP51932とeucJP-msは，Windows対応という同一コンテキストで使われ るにも関わらず，非互換であるためにクライアント側とサーバ側の間のデータ 交換に支障が出てしまう． それは結構大きな問題ですね． もし，eucJP-msは後方互換性のためにだけ必要ということでしたら，今後新し く追加するのはCP51932だけにし，その理由も明記するという選択肢がよさそ うに思えてきましたが，どうでしょうか？ --- 風間 一洋 (kazama ＠ mac.com) From moriyama ＠ miraclelinux.com Fri May 19 21:27:47 2006 From: moriyama ＠ miraclelinux.com (MORIYAMA Masayuki) Date: Fri, 19 May 2006 21:27:47 +0900 (JST) Subject: [LE-talk-ja 211] =?iso-2022-jp?b?UmU6IDUvMTcgGyRCJSolVSVpJSQbKEI=?= =?iso-2022-jp?b?GyRCJXMlXyE8JUYlIyVzJTAkXiRIJGEbKEI=?= In-Reply-To: <551E684C-C70E-454F-BED0-3612AF169F08@mac.com> References: <20060519.144126.115906589.nishida@miraclelinux.com> <551E684C-C70E-454F-BED0-3612AF169F08@mac.com> Message-ID: <20060519211234.89D5.MORIYAMA@miraclelinux.com> 森山です。 Kazuhiro Kazama wrote: > 西田さん，議題整理，どうもごくろうさまです． > > On 2006/05/19, at 14:41, Shigeo Nishida wrote: > > - JIS X 0213 対応は? > > PostgreSQL で JIS X 0213 対応と称して新しい LE 追加の動きがある > > ということが報告された。 > > これって，具体的に何を追加するって話だったでしょうか？Shift_JIS-2004と > か全部？EUC-JP-2004だけ？ > > ＃ すみません．鶏頭なので…特にアルコールが入ると…（泣）． 次の話になります。 PostgreSQLにおけるJIS X 0213サポートに関する考察メモ http://www2b.biglobe.ne.jp/~caco/pgpage/jisx0213.html [pgsql-jp: 36949] JIS X 0213のサポート http://ml.postgresql.jp/pipermail/pgsql-jp/2006-March/020509.html DB に格納する際のエンコーディングとして EUC-JIS-2004 (EUC_JIS_2004) を 追加、クライアントのエンコーディングには、Shift_JIS-2004 も追加という 事のようです。 -- 森山 将之 moriyama ＠ miraclelinux.com ミラクル・リナックス株式会社 From kazama ＠ mac.com Fri May 19 21:27:52 2006 From: kazama ＠ mac.com (Kazuhiro Kazama) Date: Fri, 19 May 2006 21:27:52 +0900 Subject: [LE-talk-ja 212] =?iso-2022-jp?b?UmU6IDUvMTcgGyRCJSolVSVpJSQbKEI=?= =?iso-2022-jp?b?GyRCJXMlXyE8JUYlIyVzJTAkXiRIJGEbKEI=?= In-Reply-To: <792A0DD4-564E-4082-A709-3DFB815F44DF@mac.com> References: <20060519201544.89C9.MORIYAMA@miraclelinux.com> <0687E6EA-23EE-4F23-9518-959600496C76@mac.com> <20060519205753.AB15.M-KOSAKI@ceres.dti.ne.jp> <792A0DD4-564E-4082-A709-3DFB815F44DF@mac.com> Message-ID: On 2006/05/19, at 21:24, Kazuhiro Kazama wrote: > 結局次のようなことでいいんでしょうか？ (->は「互換」，->>は「上位互 > 換」の意味) これは編集ミスです．すみません． 追加です． > ・EUC-JPに対して，CP51932，eucJP-ms，EUC-JP-2004はそれぞれ上位互換であ > る． > ・CP932とCP51932は互換, CP932とeucJP-ms，EUC-JP-2004はそれぞれ互換であ > る． > ・しかし，CP51932とeucJP-ms，EUC-JP-2004は互換でない． > ・特に，CP51932とeucJP-msは，Windows対応という同一コンテキストで使われ > るにも関わらず，非互換であるためにクライアント側とサーバ側の間のデータ > 交換に支障が出てしまう． ・ただし，eucJP-msを内部形式として持ち，クライアントとはCP932でしか情 報交換しない場合(例，Samba?)には，この問題は起こらない． つまり，eucJP-msを外部形式として持つ実装が，問題だということですか． --- 風間 一洋 (kazama ＠ mac.com) From umq.876 ＠ gmail.com Fri May 19 21:32:25 2006 From: umq.876 ＠ gmail.com (Hirohisa Yamaguchi) Date: Fri, 19 May 2006 21:32:25 +0900 Subject: [LE-talk-ja 213] =?iso-2022-jp?b?UmU6IDUvMTcgGyRCJSolVSVpJSQbKEI=?= =?iso-2022-jp?b?GyRCJXMlXyE8JUYlIyVzJTAkXiRIJGEbKEI=?= In-Reply-To: <792A0DD4-564E-4082-A709-3DFB815F44DF@mac.com> References: <20060519201544.89C9.MORIYAMA@miraclelinux.com> <0687E6EA-23EE-4F23-9518-959600496C76@mac.com> <20060519205753.AB15.M-KOSAKI@ceres.dti.ne.jp> <792A0DD4-564E-4082-A709-3DFB815F44DF@mac.com> Message-ID: <1dba65f30605190532h33b3cccdw6e06347dc986ecf5@mail.gmail.com> On 5/19/06, Kazuhiro Kazama wrote: > ようやく理解しました（お手数を掛けてしまって，ごめんなさい）． > 結局次のようなことでいいんでしょうか？ (->は「互換」，->>は「上位互 > 換」の意味) > ・EUC-JPに対して，CP51932，eucJP-ms，EUC-JP-2004はそれぞれ上位互換である． > ・CP932とCP51932は互換, CP932とeucJP-ms，EUC-JP-2004はそれぞれ互換である． > ・しかし，CP51932とeucJP-ms，EUC-JP-2004は互換でない． 森山さんが図示してくださってるので、それも見つつ http://legacy-encoding.sourceforge.jp/wiki/index.php?%B3%C6%A5%AD%A5%E3%A5%E9%A5%AF%A5%BF%A5%BB%A5%C3%A5%C8%A4%CE%C2%D0%B1%FE%B4%D8%B7%B8 > ・特に，CP51932とeucJP-msは，Windows対応という同一コンテキストで使われ > るにも関わらず，非互換であるためにクライアント側とサーバ側の間のデータ > 交換に支障が出てしまう． 「Windows 対応」 *らしい* ということ(名前からの印象)と どちらも EUC-JP のスーパーセットだ ということで、互換であると思ってしまいます > それは結構大きな問題ですね． > もし，eucJP-msは後方互換性のためにだけ必要ということでしたら，今後新し > く追加するのはCP51932だけにし，その理由も明記するという選択肢がよさそ > うに思えてきましたが，どうでしょうか？ 個別のコードについてどう、というのはよくわからないのですが いずれかのタイミングで、問題を最低限に抑えられる migration path の提示、というのが、欲しいと思っています -- end やまきゅう umq.876 ＠ gmail.com From kazama ＠ mac.com Fri May 19 21:41:13 2006 From: kazama ＠ mac.com (Kazuhiro Kazama) Date: Fri, 19 May 2006 21:41:13 +0900 Subject: [LE-talk-ja 214] =?iso-2022-jp?b?UmU6IDUvMTcgGyRCJSolVSVpJSQbKEI=?= =?iso-2022-jp?b?GyRCJXMlXyE8JUYlIyVzJTAkXiRIJGEbKEI=?= In-Reply-To: <20060519211234.89D5.MORIYAMA@miraclelinux.com> References: <20060519.144126.115906589.nishida@miraclelinux.com> <551E684C-C70E-454F-BED0-3612AF169F08@mac.com> <20060519211234.89D5.MORIYAMA@miraclelinux.com> Message-ID: 森山さん，どうもありがとうございます． On 2006/05/19, at 21:27, MORIYAMA Masayuki wrote: >> On 2006/05/19, at 14:41, Shigeo Nishida wrote: >>> - JIS X 0213 対応は? >>> PostgreSQL で JIS X 0213 対応と称して新しい LE 追加の動きが >>> ある >>> ということが報告された。 >> >> これって，具体的に何を追加するって話だったでしょうか？ >> Shift_JIS-2004と >> か全部？EUC-JP-2004だけ？ >> >> ＃ すみません．鶏頭なので…特にアルコールが入ると…（泣）． > > 次の話になります。 > > PostgreSQLにおけるJIS X 0213サポートに関する考察メモ > http://www2b.biglobe.ne.jp/~caco/pgpage/jisx0213.html > > [pgsql-jp: 36949] JIS X 0213のサポート > http://ml.postgresql.jp/pipermail/pgsql-jp/2006-March/020509.html > > DB に格納する際のエンコーディングとして EUC-JIS-2004 (EUC_JIS_2004) を > 追加、クライアントのエンコーディングには、Shift_JIS-2004 も追加という > 事のようです。 EUC-JIS-2004しか記憶の片隅に残っていませんでした（泣笑） EUC-JIS-2004は，(問題はありますが)レガシーシステムのままでJIS X 0213に 対応しなければいけない時の最後の手段（例，UTF-8<->EUC-JIS-2004）だとは 思うのですが，Windows VistaはShift_JIS-2004をサポートしないってことを 知らないみたいですね．誰か教えてあげられないでしょうか？ --- 風間 一洋 (kazama ＠ mac.com) From hyoshiok ＠ miraclelinux.com Fri May 19 22:05:03 2006 From: hyoshiok ＠ miraclelinux.com (Hiro Yoshioka) Date: Fri, 19 May 2006 22:05:03 +0900 (JST) Subject: [LE-talk-ja 215] =?iso-2022-jp?b?UmU6IDUvMTcgGyRCJSolVSVpJSQbKEI=?= =?iso-2022-jp?b?GyRCJXMlXyE8JUYlIyVzJTAkXiRIJGEbKEI=?= In-Reply-To: <1dba65f30605190532h33b3cccdw6e06347dc986ecf5@mail.gmail.com> References: <20060519205753.AB15.M-KOSAKI@ceres.dti.ne.jp> <792A0DD4-564E-4082-A709-3DFB815F44DF@mac.com> <1dba65f30605190532h33b3cccdw6e06347dc986ecf5@mail.gmail.com> Message-ID: <20060519.220503.137832236.hyoshiok@miraclelinux.com> よしおかです。 From: "Hirohisa Yamaguchi" > On 5/19/06, Kazuhiro Kazama wrote: > > > ようやく理解しました（お手数を掛けてしまって，ごめんなさい）． > > > 結局次のようなことでいいんでしょうか？ (->は「互換」，->>は「上位互 > > 換」の意味) > > > ・EUC-JPに対して，CP51932，eucJP-ms，EUC-JP-2004はそれぞれ上位互換である． 森山さんの図を見れば一目瞭然っす。 euc-jpに対し、 cp51932は上位互換ではない。 eucJP-msは上位互換である。 euc-jp-2004は上位互換ではない。 > > ・CP932とCP51932は互換, CP932とeucJP-ms，EUC-JP-2004はそれぞれ互換である． > > ・しかし，CP51932とeucJP-ms，EUC-JP-2004は互換でない． > > 森山さんが図示してくださってるので、それも見つつ > http://legacy-encoding.sourceforge.jp/wiki/index.php?%B3%C6%A5%AD%A5%E3%A5%E9%A5%AF%A5%BF%A5%BB%A5%C3%A5%C8%A4%CE%C2%D0%B1%FE%B4%D8%B7%B8 > > > > ・特に，CP51932とeucJP-msは，Windows対応という同一コンテキストで使われ > > るにも関わらず，非互換であるためにクライアント側とサーバ側の間のデータ > > 交換に支障が出てしまう． > > 「Windows 対応」 *らしい* ということ(名前からの印象)と > どちらも EUC-JP のスーパーセットだ > ということで、互換であると思ってしまいます cp51932はeucJPのスーパーセットではないですよね。まぎらわしい。 > > それは結構大きな問題ですね． > > > > > もし，eucJP-msは後方互換性のためにだけ必要ということでしたら，今後新し > > く追加するのはCP51932だけにし，その理由も明記するという選択肢がよさそ > > うに思えてきましたが，どうでしょうか？ 既にeucJP-msでデータが蓄積されている以上、後方互換性だけとは いえないでしょう。 > 個別のコードについてどう、というのはよくわからないのですが > いずれかのタイミングで、問題を最低限に抑えられる > migration path の提示、というのが、欲しいと思っています ガイドラインにマイグレーションの記述は必要ですね。 よ -- Hiro Yoshioka CTO/Miracle Linux Corporation http://blog.miraclelinux.com/yume/ From hyoshiok ＠ miraclelinux.com Fri May 19 22:09:39 2006 From: hyoshiok ＠ miraclelinux.com (Hiro Yoshioka) Date: Fri, 19 May 2006 22:09:39 +0900 (JST) Subject: [LE-talk-ja 216] =?iso-2022-jp?b?UmU6IDUvMTcgGyRCJSolVSVpJSQbKEI=?= =?iso-2022-jp?b?GyRCJXMlXyE8JUYlIyVzJTAkXiRIJGEbKEI=?= In-Reply-To: References: <551E684C-C70E-454F-BED0-3612AF169F08@mac.com> <20060519211234.89D5.MORIYAMA@miraclelinux.com> Message-ID: <20060519.220939.43028841.hyoshiok@miraclelinux.com> From: Kazuhiro Kazama > 森山さん，どうもありがとうございます． > > On 2006/05/19, at 21:27, MORIYAMA Masayuki wrote: > >> On 2006/05/19, at 14:41, Shigeo Nishida wrote: > >>> - JIS X 0213 対応は? > >>> PostgreSQL で JIS X 0213 対応と称して新しい LE 追加の動きが > >>> ある > >>> ということが報告された。 > >> > >> これって，具体的に何を追加するって話だったでしょうか？ > >> Shift_JIS-2004と > >> か全部？EUC-JP-2004だけ？ > >> > >> ＃ すみません．鶏頭なので…特にアルコールが入ると…（泣）． > > > > 次の話になります。 > > > > PostgreSQLにおけるJIS X 0213サポートに関する考察メモ > > http://www2b.biglobe.ne.jp/~caco/pgpage/jisx0213.html > > > > [pgsql-jp: 36949] JIS X 0213のサポート > > http://ml.postgresql.jp/pipermail/pgsql-jp/2006-March/020509.html > > > > DB に格納する際のエンコーディングとして EUC-JIS-2004 (EUC_JIS_2004) を > > 追加、クライアントのエンコーディングには、Shift_JIS-2004 も追加という > > 事のようです。 > > EUC-JIS-2004しか記憶の片隅に残っていませんでした（泣笑） > > EUC-JIS-2004は，(問題はありますが)レガシーシステムのままでJIS X 0213に > 対応しなければいけない時の最後の手段（例，UTF-8<->EUC-JIS-2004）だとは > 思うのですが，Windows VistaはShift_JIS-2004をサポートしないってことを > 知らないみたいですね．誰か教えてあげられないでしょうか？ euc-jis-2004を使いたくなるのは、既にeucJP-msでデータベースを 構築していて、JISX0213をサポートしなければいけない時かと思う のですが、euc-jis-2004とeucJP-msは既に非互換なので、データコンバージョン (誰もが絶対やりたがらない終局の作業)をしないとできないと 思います。 ということで、euc-jis-2004こそ使われないコードのような気がします。 よ -- Hiro Yoshioka CTO/Miracle Linux Corporation http://blog.miraclelinux.com/yume/ From yw3t-trns ＠ asahi-net.or.jp Fri May 19 22:13:28 2006 From: yw3t-trns ＠ asahi-net.or.jp (Tadamasa Teranishi) Date: Fri, 19 May 2006 22:13:28 +0900 Subject: [LE-talk-ja 217] =?iso-2022-jp?b?UmU6IDUvMTcgGyRCJSolVSVpJSQbKEI=?= =?iso-2022-jp?b?GyRCJXMlXyE8JUYlIyVzJTAkXiRIJGEbKEI=?= References: <20060519201544.89C9.MORIYAMA@miraclelinux.com> <0687E6EA-23EE-4F23-9518-959600496C76@mac.com> <20060519205753.AB15.M-KOSAKI@ceres.dti.ne.jp> <792A0DD4-564E-4082-A709-3DFB815F44DF@mac.com> Message-ID: <446DC478.C845417E@asahi-net.or.jp> 寺西です。 # あまりの膨大なメールのため、全然追っかけて読めていませんが...。 # ちらっと見たものの中に、ちょっと気になったのがあったので。 Kazuhiro Kazama wrote: > > ・ただし，eucJP-msを内部形式として持ち，クライアントとはCP932でしか情 > 報交換しない場合(例，Samba?)には，この問題は起こらない． > > つまり，eucJP-msを外部形式として持つ実装が，問題だということですか． ここでいう内部と外部が何で、問題とはどのような問題を指しているのかは わからないですが、と前置きしておいて。 例として出されている Samba はあてはまらないのではないかと思います。 Samba? と「?」が付いているものにコメントするのも何ですが、 eucJP-ms の使用例とて Samab は有名なものですので誤解されるといけ ないのでコメントしておきます。 Samba では、CP932 のファイル名を eucJP-ms で変換したものが UNIX 側の ファイル名になります。 Windows からしかファイルの作成、読み出しを行わなければ問題は起こら ないでしょう。 しかし、UNIX 側で作成したファイルのファイル名(EUC-JP)を Windows から 読み出すと、CP932 にない文字があれば、変換できないため問題が生じます。 # 問題の次元が違うかもしれませんけど....。 Windows 側から UNICODE でアクセスすることもできるはずなので、その 場合は、また、事情が違うでしょう。 それに加えて、UNIX 側のベンダー依存文字が未だ生きているのかどうか 知りませんが、異なる機種依存文字の混在する可能性はなくもないような 気はします。 結局、運用次第で問題が起きなくはないわけです。 -- ===================================================================== 寺西 忠勝(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 May 19 22:16:32 2006 From: kazama ＠ mac.com (Kazuhiro Kazama) Date: Fri, 19 May 2006 22:16:32 +0900 Subject: [LE-talk-ja 218] =?iso-2022-jp?b?UmU6IDUvMTcgGyRCJSolVSVpJSQbKEI=?= =?iso-2022-jp?b?GyRCJXMlXyE8JUYlIyVzJTAkXiRIJGEbKEI=?= In-Reply-To: <20060519.220503.137832236.hyoshiok@miraclelinux.com> References: <20060519205753.AB15.M-KOSAKI@ceres.dti.ne.jp> <792A0DD4-564E-4082-A709-3DFB815F44DF@mac.com> <1dba65f30605190532h33b3cccdw6e06347dc986ecf5@mail.gmail.com> <20060519.220503.137832236.hyoshiok@miraclelinux.com> Message-ID: <8BCB16CC-C647-4021-AC33-360C9091264D@mac.com> On 2006/05/19, at 22:05, Hiro Yoshioka wrote: > 森山さんの図を見れば一目瞭然っす。 > > euc-jpに対し、 > cp51932は上位互換ではない。 > eucJP-msは上位互換である。 > euc-jp-2004は上位互換ではない。 確か森山さんの図にはEUC-JPはありませんが，EUC-JPはJIS X 0212もサポート している点で問題が出てくるということで正しいでしょうか？ >>> もし，eucJP-msは後方互換性のためにだけ必要ということでしたら，今後 >>> 新し >>> く追加するのはCP51932だけにし，その理由も明記するという選択肢がよ >>> さそ >>> うに思えてきましたが，どうでしょうか？ > > 既にeucJP-msでデータが蓄積されている以上、後方互換性だけとは > いえないでしょう。 データが蓄積されていても内部形式にすぎなければ，影響を与えないでしょ う．ただ，外部形式として普通に使われているとアウトですね． --- 風間 一洋 (kazama ＠ mac.com) From umq.876 ＠ gmail.com Fri May 19 22:19:48 2006 From: umq.876 ＠ gmail.com (Hirohisa Yamaguchi) Date: Fri, 19 May 2006 22:19:48 +0900 Subject: [LE-talk-ja 219] =?iso-2022-jp?b?UmU6IDUvMTcgGyRCJSolVSVpJSQbKEI=?= =?iso-2022-jp?b?GyRCJXMlXyE8JUYlIyVzJTAkXiRIJGEbKEI=?= In-Reply-To: <20060519.220503.137832236.hyoshiok@miraclelinux.com> References: <20060519205753.AB15.M-KOSAKI@ceres.dti.ne.jp> <792A0DD4-564E-4082-A709-3DFB815F44DF@mac.com> <1dba65f30605190532h33b3cccdw6e06347dc986ecf5@mail.gmail.com> <20060519.220503.137832236.hyoshiok@miraclelinux.com> Message-ID: <1dba65f30605190619u6ff862b6p82723185f64320e3@mail.gmail.com> やまぐちです On 5/19/06, Hiro Yoshioka wrote: > > > ・EUC-JPに対して，CP51932，eucJP-ms，EUC-JP-2004はそれぞれ上位互換である． > 森山さんの図を見れば一目瞭然っす。 > euc-jpに対し、 > cp51932は上位互換ではない。 > eucJP-msは上位互換である。 > euc-jp-2004は上位互換ではない。 > > 森山さんが図示してくださってるので、それも見つつ > > http://legacy-encoding.sourceforge.jp/wiki/index.php?%B3%C6%A5%AD%A5%E3%A5%E9%A5%AF%A5%BF%A5%BB%A5%C3%A5%C8%A4%CE%C2%D0%B1%FE%B4%D8%B7%B8 > > > ・特に，CP51932とeucJP-msは，Windows対応という同一コンテキストで使われ > > > るにも関わらず，非互換であるためにクライアント側とサーバ側の間のデータ > > > 交換に支障が出てしまう． > > 「Windows 対応」 *らしい* ということ(名前からの印象)と > > どちらも EUC-JP のスーパーセットだ > > ということで、互換であると思ってしまいます > cp51932はeucJPのスーパーセットではないですよね。まぎらわしい。 すみません _( )_ EUC-JP (の JIS X0208 部分)のスーパーセット ならまだ幾分ましかもしれませんが 正確ではありませんでした -- end やまきゅう umq.876 ＠ gmail.com From hyoshiok ＠ miraclelinux.com Fri May 19 22:29:33 2006 From: hyoshiok ＠ miraclelinux.com (Hiro Yoshioka) Date: Fri, 19 May 2006 22:29:33 +0900 (JST) Subject: [LE-talk-ja 220] =?iso-2022-jp?b?UmU6IDUvMTcgGyRCJSolVSVpJSQbKEI=?= =?iso-2022-jp?b?GyRCJXMlXyE8JUYlIyVzJTAkXiRIJGEbKEI=?= In-Reply-To: <8BCB16CC-C647-4021-AC33-360C9091264D@mac.com> References: <1dba65f30605190532h33b3cccdw6e06347dc986ecf5@mail.gmail.com> <20060519.220503.137832236.hyoshiok@miraclelinux.com> <8BCB16CC-C647-4021-AC33-360C9091264D@mac.com> Message-ID: <20060519.222933.982933378.hyoshiok@miraclelinux.com> From: Kazuhiro Kazama > On 2006/05/19, at 22:05, Hiro Yoshioka wrote: > > 森山さんの図を見れば一目瞭然っす。 > > > > euc-jpに対し、 > > cp51932は上位互換ではない。 > > eucJP-msは上位互換である。 > > euc-jp-2004は上位互換ではない。 > > 確か森山さんの図にはEUC-JPはありませんが，EUC-JPはJIS X 0212もサポート > している点で問題が出てくるということで正しいでしょうか？ cp932のIBM拡張文字の一部はeucJPのJIS X0212の領域にマップされますよね。 ですので、クライアントがcp932の場合、JISX0212の領域にデータがあると いうのは十分ありえる話だと思います。 > >>> もし，eucJP-msは後方互換性のためにだけ必要ということでしたら，今後 > >>> 新し > >>> く追加するのはCP51932だけにし，その理由も明記するという選択肢がよ > >>> さそ > >>> うに思えてきましたが，どうでしょうか？ > > > > 既にeucJP-msでデータが蓄積されている以上、後方互換性だけとは > > いえないでしょう。 > > データが蓄積されていても内部形式にすぎなければ，影響を与えないでしょ > う．ただ，外部形式として普通に使われているとアウトですね． 内部形式にすぎないというのはどういう意味でしょう？ よ -- Hiro Yoshioka CTO/Miracle Linux Corporation http://blog.miraclelinux.com/yume/ From umq.876 ＠ gmail.com Fri May 19 22:40:41 2006 From: umq.876 ＠ gmail.com (Hirohisa Yamaguchi) Date: Fri, 19 May 2006 22:40:41 +0900 Subject: [LE-talk-ja 221] =?iso-2022-jp?b?UmU6IBskQj1FSiNJZDlmMj1KODt6GyhC?= In-Reply-To: <2f11576a0605181905m6e0e3520h540ced0fb15a2429@mail.gmail.com> References: <446D063D.2070105@airemix.com> <20060519.084842.70206264.nozomi@biol.tsukuba.ac.jp> <446D1080.7060405@airemix.com> <20060519.095756.31433706.nozomi@biol.tsukuba.ac.jp> <2f11576a0605181905m6e0e3520h540ced0fb15a2429@mail.gmail.com> Message-ID: <1dba65f30605190640q3e569983w59a17d9b266c606a@mail.gmail.com> やまぐちです On 5/19/06, 小崎資広 wrote: > 脱線しちゃいますが、 > 向こうの人から見たら、レガシーエンコーディング対応ってのはuglyな行為なわけ。 > で、僕らはuglyなのは分かった上で、頻度が高すぎるから現実をみて押し込もうと > してるわけでしょ。 > そこで、頻度が低いモンがまじってたら、向こうからしたらこちらの活動全体が > あいつらは規格のスミをつついてありもしない問題を大げさに騒いでいるだけだ。 > と映るんじゃないかと危惧しています。 > 結構大変ですよ。説得。逆にUnicodeとかマジメに勉強した人の方が。 > 向こうは、どのぐらい頻繁に困っているかが肌で分からないからスジ論に陥りがちで > 「えーい、おまえら黙って正規のShiftJIS使え」って話に１０回ぐらいは話を > 戻されるんですから。 「向こう」って、どこからどこまでかわからないですけど 「表外」の文字を含む文字集合が何種もあるというのは 日本語だけなんでしょうか KS C5601(あるいは KS X1001)の表外領域の文字が とか Big5 の定義外の文字が とか聞いたことがないのは単に日本に住んでて知らないからなのか 定義外の領域を勝手に使うのが日本特有の習慣なのか 調べたことがないもので。 そうであれば、 iconv のように名前で変換する方法には 日本のレガシーエンコーディング事情では (文字セットと符号化方式の両方を特定する名前付けが困難なので) 対応が難しい ということ、をそもそも想像できないと思います。 -- end やまきゅう umq.876 ＠ gmail.com From kazama ＠ mac.com Fri May 19 22:43:36 2006 From: kazama ＠ mac.com (Kazuhiro Kazama) Date: Fri, 19 May 2006 22:43:36 +0900 Subject: [LE-talk-ja 222] =?iso-2022-jp?b?UmU6IDUvMTcgGyRCJSolVSVpJSQbKEI=?= =?iso-2022-jp?b?GyRCJXMlXyE8JUYlIyVzJTAkXiRIJGEbKEI=?= In-Reply-To: <20060519.222933.982933378.hyoshiok@miraclelinux.com> References: <1dba65f30605190532h33b3cccdw6e06347dc986ecf5@mail.gmail.com> <20060519.220503.137832236.hyoshiok@miraclelinux.com> <8BCB16CC-C647-4021-AC33-360C9091264D@mac.com> <20060519.222933.982933378.hyoshiok@miraclelinux.com> Message-ID: <68DD9DFE-F09B-493F-A6B6-E5CAF297A0F3@mac.com> On 2006/05/19, at 22:29, Hiro Yoshioka wrote: >>> 森山さんの図を見れば一目瞭然っす。 >>> >>> euc-jpに対し、 >>> cp51932は上位互換ではない。 >>> eucJP-msは上位互換である。 >>> euc-jp-2004は上位互換ではない。 >> >> 確か森山さんの図にはEUC-JPはありませんが，EUC-JPはJIS X 0212もサ >> ポート >> している点で問題が出てくるということで正しいでしょうか？ > > cp932のIBM拡張文字の一部はeucJPのJIS X0212の領域にマップされますよね。 > ですので、クライアントがcp932の場合、JISX0212の領域にデータがあると > いうのは十分ありえる話だと思います。 いや，そういう話じゃなくて，互換性に問題が出る理由は…ということです． >> データが蓄積されていても内部形式にすぎなければ，影響を与えないでしょ >> う．ただ，外部形式として普通に使われているとアウトですね． > > 内部形式にすぎないというのはどういう意味でしょう？ たとえば，UCS正規化方式はシステム内部でUnicode形式で保持しますが，外部 からは一見EUC-JPだけで動いているシステムのように振る舞うことができるの で，それと似た場合を想定していました．ただ，寺西さんの指摘で，それが成 り立たないことがわかりました． On 2006/05/19, at 22:13, Tadamasa Teranishi wrote: > 例として出されている Samba はあてはまらないのではないかと思います。 > Samba? と「?」が付いているものにコメントするのも何ですが、 > eucJP-ms の使用例とて Samab は有名なものですので誤解されるといけ > ないのでコメントしておきます。 > > Samba では、CP932 のファイル名を eucJP-ms で変換したものが UNIX 側の > ファイル名になります。 > Windows からしかファイルの作成、読み出しを行わなければ問題は起こら > ないでしょう。 > > しかし、UNIX 側で作成したファイルのファイル名(EUC-JP)を Windows から > 読み出すと、CP932 にない文字があれば、変換できないため問題が生じます。 > > # 問題の次元が違うかもしれませんけど....。 いや，的確です． > 結局、運用次第で問題が起きなくはないわけです。 問題はなくならない，だから運用で解決するしかないというわけですね． --- 風間 一洋 (kazama ＠ mac.com) From kazama ＠ mac.com Fri May 19 22:54:26 2006 From: kazama ＠ mac.com (Kazuhiro Kazama) Date: Fri, 19 May 2006 22:54:26 +0900 Subject: [LE-talk-ja 223] =?iso-2022-jp?b?UmU6IDUvMTcgGyRCJSolVSVpJSQbKEI=?= =?iso-2022-jp?b?GyRCJXMlXyE8JUYlIyVzJTAkXiRIJGEbKEI=?= In-Reply-To: <20060519.220939.43028841.hyoshiok@miraclelinux.com> References: <551E684C-C70E-454F-BED0-3612AF169F08@mac.com> <20060519211234.89D5.MORIYAMA@miraclelinux.com> <20060519.220939.43028841.hyoshiok@miraclelinux.com> Message-ID: On 2006/05/19, at 22:09, Hiro Yoshioka wrote: > euc-jis-2004を使いたくなるのは、既にeucJP-msでデータベースを > 構築していて、JISX0213をサポートしなければいけない時かと思う > のですが、euc-jis-2004とeucJP-msは既に非互換なので、データコンバー > ジョン > (誰もが絶対やりたがらない終局の作業)をしないとできないと > 思います。 > > ということで、euc-jis-2004こそ使われないコードのような気がします。 結局，ISO-2022-JP-2004もShift_JIS-2004もEUC-JIS-2004も，産業界としては すべていらないと言い切ってしまっていいわけですかね． --- 風間 一洋 (kazama ＠ mac.com) From yw3t-trns ＠ asahi-net.or.jp Fri May 19 22:56:56 2006 From: yw3t-trns ＠ asahi-net.or.jp (Tadamasa Teranishi) Date: Fri, 19 May 2006 22:56:56 +0900 Subject: [LE-talk-ja 224] =?iso-2022-jp?b?UmU6IDUvMTcgGyRCJSolVSVpJSQbKEI=?= =?iso-2022-jp?b?GyRCJXMlXyE8JUYlIyVzJTAkXiRIJGEbKEI=?= References: <551E684C-C70E-454F-BED0-3612AF169F08@mac.com> <20060519211234.89D5.MORIYAMA@miraclelinux.com> <20060519.220939.43028841.hyoshiok@miraclelinux.com> Message-ID: <446DCEA8.C878D09E@asahi-net.or.jp> 寺西です。 Hiro Yoshioka wrote: > > > EUC-JIS-2004は，(問題はありますが)レガシーシステムのままでJIS X 0213に > > 対応しなければいけない時の最後の手段（例，UTF-8<->EUC-JIS-2004）だとは > > 思うのですが，Windows VistaはShift_JIS-2004をサポートしないってことを > > 知らないみたいですね．誰か教えてあげられないでしょうか？ > > euc-jis-2004を使いたくなるのは、既にeucJP-msでデータベースを > 構築していて、JISX0213をサポートしなければいけない時かと思う > のですが、euc-jis-2004とeucJP-msは既に非互換なので、データコンバージョン > (誰もが絶対やりたがらない終局の作業)をしないとできないと > 思います。 eucJP-msでデータベースを構築してしまったのなら、いずれデータコンバー ジョンをしないといけなくなるのではないかと思います。 (コンバージョンする前に、そのデータベースの寿命が尽きれば別ですが。) ずっと CP932 にある文字だけ扱うというわけにはいかないでしょう。 ただ、その時に euc-jis-2004 に変換するのが良い選択とは思いませんが。 > ということで、euc-jis-2004こそ使われないコードのような気がします。 クライアントが Windows で、データベースの内部で使うという意味なら そうなのかもしれませんが、euc-jis-2004 が使われないコードかどうかは また別な話だと思います。 個人的には euc-jis-2004 を使いたいとは思いませんが、 > > EUC-JIS-2004は，(問題はありますが)レガシーシステムのままでJIS X 0213に > > 対応しなければいけない時 に遭遇した人は(データーベースに限らず)使いたがるのではないかと思い ます。人名とか、どうしても第3,4水準の文字を使いたい業界とか。 (歯科医師用記号とかもあるはずなので、歯科医師関係とか) -- ===================================================================== 寺西 忠勝(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 Sun May 21 21:17:46 2006 From: taca ＠ back-street.net (Takahiro Kambe) Date: Sun, 21 May 2006 21:17:46 +0900 (JST) Subject: [LE-talk-ja 225] =?iso-2022-jp?b?UmU6IDUvMTcgGyRCJSolVSVpJSQbKEI=?= =?iso-2022-jp?b?GyRCJXMlXyE8JUYlIyVzJTAkXiRIJGEbKEI=?= In-Reply-To: <20060519.144126.115906589.nishida@miraclelinux.com> References: <20060519.144126.115906589.nishida@miraclelinux.com> Message-ID: <20060521.211746.95893209.taca@back-street.net> 思い付きですが、 In message <20060519.144126.115906589.nishida ＠ miraclelinux.com> on Fri, 19 May 2006 14:41:26 +0900 (JST), Shigeo Nishida wrote: > * ISO-2022-JP-MS > - 名前がだめ > 違う名前にするべき ISO-2022-CP932 やっぱり、ダメか? :-) -- 神戸 隆博 / Takahiro Kambe From m-kosaki ＠ ceres.dti.ne.jp Sun May 21 21:24:05 2006 From: m-kosaki ＠ ceres.dti.ne.jp (kosaki) Date: Sun, 21 May 2006 21:24:05 +0900 Subject: [LE-talk-ja 226] =?iso-2022-jp?b?UmU6IDUvMTcgGyRCJSolVSVpJSQbKEI=?= =?iso-2022-jp?b?GyRCJXMlXyE8JUYlIyVzJTAkXiRIJGEbKEI=?= In-Reply-To: <20060521.211746.95893209.taca@back-street.net> References: <20060519.144126.115906589.nishida@miraclelinux.com> <20060521.211746.95893209.taca@back-street.net> Message-ID: <20060521212303.D7D3.M-KOSAKI@ceres.dti.ne.jp> kosakiです。 > on Fri, 19 May 2006 14:41:26 +0900 (JST), > Shigeo Nishida wrote: > > * ISO-2022-JP-MS > > - 名前がだめ > > 違う名前にするべき > ISO-2022-CP932 > > やっぱり、ダメか? :-) これは森山さんが > ここのメーリングリストで、新しい名前を作るという事に関しては、反対され > ていますので、ISO-2022-CP932 にしたところで反対されるのだろうと思います。 > > ISO-2022-JP-MS ではなく、CP50221 の方を実装する方が好ましいという意見 > が複数でていますので、CP50221 の方を実際に実装する方向で考えています。 と発言されているので収束方向のようです。 -- kosaki From naruse ＠ airemix.com Mon May 22 01:25:22 2006 From: naruse ＠ airemix.com (NARUSE, Yui) Date: Mon, 22 May 2006 01:25:22 +0900 Subject: [LE-talk-ja 227] =?iso-2022-jp?b?UmU6IBskQj1FSiNJZDlmMj1KODt6GyhC?= In-Reply-To: <20060519.154500.77414785.nozomi@biol.tsukuba.ac.jp> References: <446D1080.7060405@airemix.com> <20060519.095756.31433706.nozomi@biol.tsukuba.ac.jp> <2f11576a0605181905m6e0e3520h540ced0fb15a2429@mail.gmail.com> <20060519.154500.77414785.nozomi@biol.tsukuba.ac.jp> Message-ID: <44709472.9020803@airemix.com> 成瀬です。 Nozomi Ytow wrote: > これは、CP932 から Unicode への変換の話で、CP932 とたとえば > CP51932 の間の変換の根拠にはなりませんよね。 基本的に CP* というのは Unicode 対応表のことである、 とわたしは理解しているので、根拠になるかと。 > Unicode が中間にあるのだ、という実装を仕様に押しつけることなく、 > CP932 と CP51932 なりの間の変換が現実的なやりかた、つまり > 文字集合の組毎のコンバータを作らずに間に Unicode を使うやりかたで > 実現できるなら、CP932 と CP51932 なりの変換仕様としてはむしろ > 適切なのではないでしょうか。 よって、むしろこちらが独自拡張でしょう。 そもそも、このプロジェクトはLegacy Encodingを 使いやすくするプロジェクトではなく、 Legacy Encodingをなるべく早期に混乱なく葬るプロジェクトのはずですので、 Unicodeで区別できない文字をレガシー間で区別して 変換する枠組みを整備しようというのはその趣旨にも反します。 また、CP51932にはIBM拡張文字がありませんし。 > 「間に入るのがいかんせん Unicode だからねぇ」というのは > 必ずしも仕様を束縛すべきではないでしょう。やり方が全くないなら > 仕方ありませんが、VS を使えばできなくはありません。 すみません、VS ≠ IVS なのはわたしの誤解ですね。 VSについては、正式な規格と衝突する可能性は少なそうですが、 外字まがいの手法であることは確かです。 そのような裏技的な手法をこのプロジェクトで用いるのには反対です。 「内部処理用」というのが言い訳にならないことは、 Shift_JISやEUCが外部に流れてしまっている事例等もありますし。 他の機関が既に標準化していること以外は避けたいところ。 > あとは、それを利用して仕様を定義するか、利用せずに実装を > 優先するかという問題だと思います。 実装指向なプロジェクトであると解しています。 レガシーから移行する際に必要な情報を集めて公開し、 また移行に必要な実装を提供するプロジェクトであると。 -- NARUSE, Yui DBDB A476 FDBD 9450 02CD 0EFC BCE3 C388 472E C1EA From nozomi ＠ biol.tsukuba.ac.jp Mon May 22 02:22:27 2006 From: nozomi ＠ biol.tsukuba.ac.jp (Nozomi Ytow) Date: Mon, 22 May 2006 02:22:27 +0900 (JST) Subject: [LE-talk-ja 228] =?iso-2022-jp?b?UmU6IBskQj1FSiNJZDlmMj1KODt6GyhC?= In-Reply-To: <44709472.9020803@airemix.com> References: <2f11576a0605181905m6e0e3520h540ced0fb15a2429@mail.gmail.com> <20060519.154500.77414785.nozomi@biol.tsukuba.ac.jp> <44709472.9020803@airemix.com> Message-ID: <20060522.022227.23023748.nozomi@biol.tsukuba.ac.jp> "NARUSE, Yui" wrote: > 基本的に CP* というのは Unicode 対応表のことである、 > とわたしは理解しているので、根拠になるかと。 その対応表の、Unicode でない方の集合は、何と呼べば 良いのでしょうか。 > そもそも、このプロジェクトはLegacy Encodingを > 使いやすくするプロジェクトではなく、 > Legacy Encodingをなるべく早期に混乱なく葬る > プロジェクトのはずですので、 「使いやすくする」かどうかはさておき、早期に葬るなら サポートしないというのが正解でしょう。 「基本仕様書」の 0.1 版では相互変換が目的とされて います。 「既存の物まで含めて全部 UTF-8 に移せ」というのは 現実的でないというのが背景にある認識だと思うのですが 違いましょうか。 > VSについては、正式な規格と衝突する可能性は少なそうですが、 > 外字まがいの手法であることは確かです。 > そのような裏技的な手法をこのプロジェクトで用いるのには反対です。 裏技的かどうかが重要なのではなく、工夫すれば区別できるものを 区別できなくしてしまう事を仕様とするかどうかが重要でしょう。 実装はその次の話です。もちろん「そんな実装マージで困る」 というのはありえるでしょうが、実装する前に「仕様としてこう なっちゃうんだけど、実装したらどうする?」とマージ先に相談 すれば良いことだと思います。 > 「内部処理用」というのが言い訳にならないことは、 > Shift_JISやEUCが外部に流れてしまっている事例等もありますし。 たとえば mule コードを外部的に積極的には使っている人というのを 聞いたことはないのですが、それはさておき、「流れてしまっている」 のは流した人の責任ではないでしょうか。包丁と殺人の関係と似た 様なものでしょう。 > 実装指向なプロジェクトであると解しています。 > レガシーから移行する際に必要な情報を集めて公開し、 > また移行に必要な実装を提供するプロジェクトであると。 だったら Unicode へのコンバータ作るだけで良いのでは。 それで解決すれわけないでしょ、というのが、このプロジェクトの 必要性の一つだと理解していますが。 -- のぞみ From yanagisw ＠ gmail.com Mon May 22 03:26:45 2006 From: yanagisw ＠ gmail.com (Yanagisawa) Date: Sun, 21 May 2006 11:26:45 -0700 Subject: [LE-talk-ja 229] =?iso-2022-jp?b?UmU6IBskQiUqJVUlaSUkJXMlXyE8GyhC?= =?iso-2022-jp?b?GyRCJUYlIyVzJTAkThsoQiobJEI4RD9NRSokShsoQiobJEI1RE9AGyhC?= =?iso-2022-jp?b?GyRCJE4kXiRIJGEbKEI=?= In-Reply-To: <884D65C0-153D-4F2B-BA57-FF40424F252C@mac.com> References: <20060516184928.894D.MORIYAMA@miraclelinux.com> <70DB9439-5AA0-42A2-B846-44B050ECF741@mac.com> <20060518005639.GA12382%numata@jp.fujitsu.com> <20060518062703.GA18052%numata@jp.fujitsu.com> <87k68joj8q.wl%shinichiro@stained-g.net> <884D65C0-153D-4F2B-BA57-FF40424F252C@mac.com> Message-ID: On May 18, 2006, at 3:42 AM, Kazuhiro Kazama wrote: > > On 2006/05/18, at 18:59, Tomoyuki Asakawa wrote: >>> 今，Mac OS Xで標準のMailを使ってJIS X 0212の >>> 文字を入れて出してみたとこ >>> ろ，黙ってUTF-8で送信しました． >> >> なんと！、クサナギをいれたら。CP932で出ました。 > > これが昨日聞いていたCP932問題ですか（苦笑） ところで、これの何が問題かと、修正の仕方に関してこ の ML 上ではなたも言及されていない... ですよね? それらを私が推測するに、修正法としては 1) CP932 は正式な IANA name ではないので、エンコー ディングはそのままで、ヘッダーを charset=windows-31j と修正する。 2) CP932 は（何らかの理由で）メールには適切なエン コーディングでないので、別のエンコーディング、 例えば UTF-8 を使う。 3) その他 などがあると思います。実際にはどれが適切なんでしょうか? -- 柳沢 剛 From naruse ＠ airemix.com Mon May 22 05:59:16 2006 From: naruse ＠ airemix.com (NARUSE, Yui) Date: Mon, 22 May 2006 05:59:16 +0900 Subject: [LE-talk-ja 230] =?iso-2022-jp?b?UmU6IBskQj1FSiNJZDlmMj1KODt6GyhC?= In-Reply-To: <20060522.022227.23023748.nozomi@biol.tsukuba.ac.jp> References: <2f11576a0605181905m6e0e3520h540ced0fb15a2429@mail.gmail.com> <20060519.154500.77414785.nozomi@biol.tsukuba.ac.jp> <44709472.9020803@airemix.com> <20060522.022227.23023748.nozomi@biol.tsukuba.ac.jp> Message-ID: <4470D4A4.1040208@airemix.com> 成瀬です。 Nozomi Ytow wrote: > "NARUSE, Yui" wrote: > >> 基本的に CP* というのは Unicode 対応表のことである、 >> とわたしは理解しているので、根拠になるかと。 > > その対応表の、Unicode でない方の集合は、何と呼べば > 良いのでしょうか。 CP* に対応する文字集合、じゃないですかね。 CP932 でしたら Windows-31J でしょうが。 >> そもそも、このプロジェクトはLegacy Encodingを >> 使いやすくするプロジェクトではなく、 >> Legacy Encodingをなるべく早期に混乱なく葬る >> プロジェクトのはずですので、 > > 「使いやすくする」かどうかはさておき、早期に葬るなら > サポートしないというのが正解でしょう。 サポートしなかったら既存のデータは移行できませんね。 > 「基本仕様書」の 0.1 版では相互変換が目的とされて > います。 ISO-2022-JP-MS に象徴されるように、 このプロジェクトはしばしば目的と手段が混同されている気がします。 相互変換が目的ならば、円記号・波ダッシュ問題は 課題には上がらないはずです。 > 「既存の物まで含めて全部 UTF-8 に移せ」というのは > 現実的でないというのが背景にある認識だと思うのですが > 違いましょうか。 「今すぐ移せ」を加え、「背景にある」を削れば同意します。 >> VSについては、正式な規格と衝突する可能性は少なそうですが、 >> 外字まがいの手法であることは確かです。 >> そのような裏技的な手法をこのプロジェクトで用いるのには反対です。 > > 裏技的かどうかが重要なのではなく、工夫すれば区別できるものを > 区別できなくしてしまう事を仕様とするかどうかが重要でしょう。 仕様としてしまうのが妥当かと思います。 どうしても区別したい場合は、文字コードのレイヤーでなく、 一つ上のレイヤーで区別したほうが幸せになれるかなーと。 >> 「内部処理用」というのが言い訳にならないことは、 >> Shift_JISやEUCが外部に流れてしまっている事例等もありますし。 > > たとえば mule コードを外部的に積極的には使っている人というのを > 聞いたことはないのですが、それはさておき、「流れてしまっている」 > のは流した人の責任ではないでしょうか。包丁と殺人の関係と似た > 様なものでしょう。 Mule と iconv は少々事情が異なると感じます。 基本的にMule は Mule コードをそのまま外に流すようなことはしませんよね。 libiconv の場合は外に流れるケースが少なからずあるかと思います。 >> 実装指向なプロジェクトであると解しています。 >> レガシーから移行する際に必要な情報を集めて公開し、 >> また移行に必要な実装を提供するプロジェクトであると。 > > だったら Unicode へのコンバータ作るだけで良いのでは。 > それで解決すれわけないでしょ、というのが、このプロジェクトの > 必要性の一つだと理解していますが。 Unicode へのコンバータ作るだけで実装自体は終わりますね。 それだけで相互変換も可能になりますし。 -- NARUSE, Yui DBDB A476 FDBD 9450 02CD 0EFC BCE3 C388 472E C1EA From nozomi ＠ biol.tsukuba.ac.jp Mon May 22 06:19:09 2006 From: nozomi ＠ biol.tsukuba.ac.jp (Nozomi Ytow) Date: Mon, 22 May 2006 06:19:09 +0900 (JST) Subject: [LE-talk-ja 231] =?iso-2022-jp?b?UmU6IBskQj1FSiNJZDlmMj1KODt6GyhC?= In-Reply-To: <4470D4A4.1040208@airemix.com> References: <44709472.9020803@airemix.com> <20060522.022227.23023748.nozomi@biol.tsukuba.ac.jp> <4470D4A4.1040208@airemix.com> Message-ID: <20060522.061909.35675663.nozomi@biol.tsukuba.ac.jp> "NARUSE, Yui" wrote: > > その対応表の、Unicode でない方の集合は、何と呼べば > CP* に対応する文字集合、じゃないですかね。 > CP932 でしたら Windows-31J でしょうが。 そうですか、知りませんでした。 Unicode サポートしてなかったころからコードページと言っていた 記憶があったので、「コードページ(code page)とは文字セットのこと」 というマイクロソフトの説明を鵜呑みにしていました。 http://msdn2.microsoft.com/ja-JP/library/2x8et5ee.aspx > > 裏技的かどうかが重要なのではなく、工夫すれば区別できるものを > > 区別できなくしてしまう事を仕様とするかどうかが重要でしょう。 > 仕様としてしまうのが妥当かと思います。 > どうしても区別したい場合は、文字コードのレイヤーでなく、 > 一つ上のレイヤーで区別したほうが幸せになれるかなーと。 うーん。round trip や source code separation は 優先順位が高いと私は思いますが、人それぞれなのですね。 > Mule と iconv は少々事情が異なると感じます。 > libiconv の場合は外に流れるケースが少なからずあるかと思います。 どうやって? > Unicode へのコンバータ作るだけで実装自体は終わりますね。 > それだけで相互変換も可能になりますし。 では iconv が今回対象の文字コードをサポートしているのだから もういい事になってしまうのでは? -- のぞみ From kazama ＠ mac.com Mon May 22 12:40:14 2006 From: kazama ＠ mac.com (Kazuhiro Kazama) Date: Mon, 22 May 2006 12:40:14 +0900 Subject: [LE-talk-ja 232] =?iso-2022-jp?b?UmU6IBskQiUqJVUlaSUkJXMlXyE8GyhC?= =?iso-2022-jp?b?GyRCJUYlIyVzJTAkThsoQiobJEI4RD9NRSokShsoQiobJEI1RE9AGyhC?= =?iso-2022-jp?b?GyRCJE4kXiRIJGEbKEI=?= In-Reply-To: References: <20060516184928.894D.MORIYAMA@miraclelinux.com> <70DB9439-5AA0-42A2-B846-44B050ECF741@mac.com> <20060518005639.GA12382%numata@jp.fujitsu.com> <20060518062703.GA18052%numata@jp.fujitsu.com> <87k68joj8q.wl%shinichiro@stained-g.net> <884D65C0-153D-4F2B-BA57-FF40424F252C@mac.com> Message-ID: <34DCB6F0-E94A-42CF-8FE2-02CC6A0409EB@mac.com> 柳沢さん On 2006/05/22, at 3:26, Yanagisawa wrote: >>>> 今，Mac OS Xで標準のMailを使ってJIS X 0212の >>>> 文字を入れて出してみたとこ >>>> ろ，黙ってUTF-8で送信しました． >>> >>> なんと！、クサナギをいれたら。CP932で出ました。 >> >> これが昨日聞いていたCP932問題ですか（苦笑） > > ところで、これの何が問題かと、修正の仕方に関してこ > の ML 上ではなたも言及されていない... ですよね? > それらを私が推測するに、修正法としては > > 1) CP932 は正式な IANA name ではないので、エンコー > ディングはそのままで、ヘッダーを charset=windows-31j > と修正する。 > 2) CP932 は（何らかの理由で）メールには適切なエン > コーディングでないので、別のエンコーディング、 > 例えば UTF-8 を使う。 > 3) その他 > > などがあると思います。実際にはどれが適切なんでしょうか? 鋭いですね． たぶん，問題は3つに分けられるんじゃないかなと思います． 1) CP932はIANAに登録されていない（Windows-31JとcsWindows31Jは登録）＆ 歴史的経緯で使われているわけでもない（x-ms-cp932はWindowsでは処理可 能）． 2) 指定されている文字符号化でサポートされていない文字があった場合に， どの文字符号化にフォールバックさせるべきか． 3) フォールバックの切り替えポイントはどうなのか． それで，私が指摘したのは1)だけです．まあ，これは論外でしょう． ただ，2)は現在の日本の方向性に合わせてUTF-8になると思っています．ただ， ISO-2022-JP-1などにフォールバックする実装も世の中にあるとしたら，それ は将来的には直してもらった方がよさそうです． 問題は3)です．結局，IANA登録名に，より文字レパートリーが広い別の文字符 号化を割り当てているケースがあり，その場合には切り替えポイントが合致し なくなります． たとえば，UCS正規化方式のメーラだと，文字符号化変換APIで指定した文字符 号化で変換時にエラーが発生した時を切り替える目安にしていると思われるの で，上記のような変更がある場合にはやりたくない解決法（今までレガシーエ ンコーディングの実装を変えるか，国際化フレームワークの範囲を逸脱してア ドホックに対応するとか）しか思いつきません．この辺はいろいろ議論の余地 がありそうです． なお，MSの阿南さんには，この前の御礼を兼ねて，これらのことも報告してお こうと思っていますので，意見があれば教えてください． --- 風間 一洋 (kazama ＠ mac.com) From naruse ＠ airemix.com Mon May 22 15:51:20 2006 From: naruse ＠ airemix.com (NARUSE, Yui) Date: Mon, 22 May 2006 15:51:20 +0900 Subject: [LE-talk-ja 233] =?iso-2022-jp?b?UmU6IBskQj1FSiNJZDlmMj1KODt6GyhC?= In-Reply-To: <20060522.061909.35675663.nozomi@biol.tsukuba.ac.jp> References: <44709472.9020803@airemix.com> <20060522.022227.23023748.nozomi@biol.tsukuba.ac.jp> <4470D4A4.1040208@airemix.com> <20060522.061909.35675663.nozomi@biol.tsukuba.ac.jp> Message-ID: <44715F68.10809@airemix.com> 成瀬です。 Nozomi Ytow wrote: > "NARUSE, Yui" wrote: > >>> その対応表の、Unicode でない方の集合は、何と呼べば >> CP* に対応する文字集合、じゃないですかね。 >> CP932 でしたら Windows-31J でしょうが。 > > そうですか、知りませんでした。 > Unicode サポートしてなかったころからコードページと言っていた > 記憶があったので、「コードページ(code page)とは文字セットのこと」 > というマイクロソフトの説明を鵜呑みにしていました。 > http://msdn2.microsoft.com/ja-JP/library/2x8et5ee.aspx 確かに由来はそうですし、語義もそうですが、 XMLにおけるencodingと同じものと理解しています。 >>> 裏技的かどうかが重要なのではなく、工夫すれば区別できるものを >>> 区別できなくしてしまう事を仕様とするかどうかが重要でしょう。 >> 仕様としてしまうのが妥当かと思います。 >> どうしても区別したい場合は、文字コードのレイヤーでなく、 >> 一つ上のレイヤーで区別したほうが幸せになれるかなーと。 > > うーん。round trip や source code separation は > 優先順位が高いと私は思いますが、人それぞれなのですね。 高いのは確かですが、重複符号化された文字まで分ける必要があるかというと、 疑問には感じます。 >> Mule と iconv は少々事情が異なると感じます。 >> libiconv の場合は外に流れるケースが少なからずあるかと思います。 > > どうやって? アプリケーションからlibiconvを用いて、文字列を CP932からNEC特殊文字とIBM拡張文字を区別するUnicodeに変換し、 そのままその文字列を外に流しちゃう人って絶対いますよね。 >> Unicode へのコンバータ作るだけで実装自体は終わりますね。 >> それだけで相互変換も可能になりますし。 > > では iconv が今回対象の文字コードをサポートしているのだから > もういい事になってしまうのでは? Perl/Encode等はiconvを使いませんから。 これらが自前で抱えているコンバータにも手を入れませんと。 -- NARUSE, Yui DBDB A476 FDBD 9450 02CD 0EFC BCE3 C388 472E C1EA From moriyama ＠ miraclelinux.com Mon May 22 16:22:10 2006 From: moriyama ＠ miraclelinux.com (MORIYAMA Masayuki) Date: Mon, 22 May 2006 16:22:10 +0900 (JST) Subject: [LE-talk-ja 234] =?iso-2022-jp?b?UmU6IBskQj1FSiNJZDlmMj1KODt6GyhC?= In-Reply-To: <20060519.154500.77414785.nozomi@biol.tsukuba.ac.jp> References: <2f11576a0605181905m6e0e3520h540ced0fb15a2429@mail.gmail.com> <20060519.154500.77414785.nozomi@biol.tsukuba.ac.jp> Message-ID: <20060522142159.89F0.MORIYAMA@miraclelinux.com> 森山です。 Nozomi Ytow wrote: > 少し考え直しました。 > > > * Microsoftも正規化している > > http://support.microsoft.com/default.aspx?scid=kb;ja;JP170559 > > これは、CP932 から Unicode への変換の話で、CP932 とたとえば > CP51932 の間の変換の根拠にはなりませんよね。ただ、たまたま > Unicode を中間コードに用いているから、影響があるかもしれない > 事ではあるわけです。で、 CP51932 や eucJP-ms、CP5022X では、CP932 での IBM拡張文字とNEC選定IBM 拡張文字を区別して扱う事は出来ませんので、Unicode への変換が絡まなくて も重複符号化文字のレガシーエンコーディング間の変換では、Unicode と CP932 との間の変換と同様の問題が生じます。 レガシーエンコーディング間の変換で重複符号化文字を維持したまま変換可能 にする事に関しては、Windows と異なる重複符号化文字の扱いをする事は、メ リットよりもデメリットの方が多くなってしまうのではないかと思います。 重複符号化文字を区別して扱う必要のあるケースというのがあるのかもしれま せんが、そのようなケースは稀なケースと思われるので、そのように区別して 扱う必要のあるソフトウェアで、それぞれの事情に合わせて個別対応していく のが良いのではないでしょうか? ちなみに、Windows では、たとえば次の文字を、いわゆる機種依存文字のコー ドポイントで入力しようとしても困難を極めるので、入力データとしては、ほ とんど現れないといっても良い状況にあります。 ∪∩∠⊥≡≒√∵∫¬ -- 森山 将之 moriyama ＠ miraclelinux.com ミラクル・リナックス株式会社 From moriyama ＠ miraclelinux.com Mon May 22 16:31:56 2006 From: moriyama ＠ miraclelinux.com (MORIYAMA Masayuki) Date: Mon, 22 May 2006 16:31:56 +0900 (JST) Subject: [LE-talk-ja 235] =?iso-2022-jp?b?UmU6IBskQj1FSiNJZDlmMj1KODt6GyhC?= In-Reply-To: <20060522142159.89F0.MORIYAMA@miraclelinux.com> References: <20060519.154500.77414785.nozomi@biol.tsukuba.ac.jp> <20060522142159.89F0.MORIYAMA@miraclelinux.com> Message-ID: <20060522162517.89F3.MORIYAMA@miraclelinux.com> 森山です。 MORIYAMA Masayuki wrote: > ちなみに、Windows では、たとえば次の文字を、いわゆる機種依存文字のコー > ドポイントで入力しようとしても困難を極めるので、入力データとしては、ほ > とんど現れないといっても良い状況にあります。 > > ∪∩∠⊥≡≒√∵∫¬ ちょっと説明不足でした。 CP932 では、次のコードポイントがデータとして現れる事は、ほとんど無いと いう意味で、上記の文字の JIS のコードポイントの方は入力でき、普通に使 えます。 NEC特殊文字 NEC選定IBM拡張文字 IBM拡張文字 -- ----------- ------------------ ----------- ∪ 0x879C ∩ 0x879B ¬ 0xEEF9 0xFA54 ∠ 0x8797 ⊥ 0x8796 ≡ 0x8791 ≒ 0x8790 √ 0x8795 ∵ 0x879A ∫ 0x8792 -- 森山 将之 moriyama ＠ miraclelinux.com ミラクル・リナックス株式会社 From nozomi ＠ biol.tsukuba.ac.jp Mon May 22 23:04:48 2006 From: nozomi ＠ biol.tsukuba.ac.jp (Nozomi Ytow) Date: Mon, 22 May 2006 23:04:48 +0900 (JST) Subject: [LE-talk-ja 236] =?iso-2022-jp?b?UmU6IBskQj1FSiNJZDlmMj1KODt6GyhC?= In-Reply-To: <20060522142159.89F0.MORIYAMA@miraclelinux.com> References: <2f11576a0605181905m6e0e3520h540ced0fb15a2429@mail.gmail.com> <20060519.154500.77414785.nozomi@biol.tsukuba.ac.jp> <20060522142159.89F0.MORIYAMA@miraclelinux.com> Message-ID: <20060522.230448.77415405.nozomi@biol.tsukuba.ac.jp> MORIYAMA Masayuki wrote: > CP51932 や eucJP-ms、CP5022X では、CP932 での IBM拡張文字とNEC選定IBM > 拡張文字を区別して扱う事は出来ませんので、Unicode への変換が絡まなくて > も重複符号化文字のレガシーエンコーディング間の変換では、Unicode と > CP932 との間の変換と同様の問題が生じます。 それは変換の端点となる文字コードの制約によるものなので不可避でしょう。 ASCII に JIS X 0208 の殆んどの文字はマップできない、というのと同じ カテゴリです。そうではなくて、端点文字コードだけの指定では区別して マップできるのに、中間コードの制約で区別できなくなる事をどうするか、 という話です。 > レガシーエンコーディング間の変換で重複符号化文字を維持したまま変換可能 > にする事に関しては、Windows と異なる重複符号化文字の扱いをする事は、メ > リットよりもデメリットの方が多くなってしまうのではないかと思います。 それはそれで理解できますが、round trip を保証しなかったり、区別できる ものを区別しなかったりというのは、いくら元の文字集合が集合になって いないからとは言え変換系としては「えっ」思わせるので、ドキュメントに メリットデメリットを列挙した上で、それでもこういう仕様にするのだと 書いておくべきだと思います。 「現実問題としてコードの登場頻度が少ないだろう」という理由よりは、 内部コードへの依存性が高まってしまうので共通の文字コード変換 仕様としてはモジュラリティの観点から適当でない、という理由の方が 説得力があると思います。 -- のぞみ From nozomi ＠ biol.tsukuba.ac.jp Mon May 22 23:15:00 2006 From: nozomi ＠ biol.tsukuba.ac.jp (Nozomi Ytow) Date: Mon, 22 May 2006 23:15:00 +0900 (JST) Subject: [LE-talk-ja 237] =?iso-2022-jp?b?UmU6IBskQj1FSiNJZDlmMj1KODt6GyhC?= In-Reply-To: <44715F68.10809@airemix.com> References: <4470D4A4.1040208@airemix.com> <20060522.061909.35675663.nozomi@biol.tsukuba.ac.jp> <44715F68.10809@airemix.com> Message-ID: <20060522.231500.34750961.nozomi@biol.tsukuba.ac.jp> "NARUSE, Yui" wrote: > 確かに由来はそうですし、語義もそうですが、 > XMLにおけるencodingと同じものと理解しています。 「XML の encoding 属性と同じ」という理解がどうして 「CP932 というのはある文字集合と Unicode との対応表」 という理解になるのかわかりませんが、コードページの語義が 対応表でないなら、対応表だという理解を根拠とされても... > >> libiconv の場合は外に流れるケースが少なからずあるかと思います。 > > どうやって? > アプリケーションからlibiconvを用いて、文字列を > CP932からNEC特殊文字とIBM拡張文字を区別するUnicodeに変換し、 > そのままその文字列を外に流しちゃう人って絶対いますよね。 仮に libiconv が「区別するUnicodeに変換」することを許すなら、 それはもはや内部コードではないでしょう。 > >> Unicode へのコンバータ作るだけで実装自体は終わりますね。 > > では iconv が今回対象の文字コードをサポートしているのだから > > もういい事になってしまうのでは? > Perl/Encode等はiconvを使いませんから。 > これらが自前で抱えているコンバータにも手を入れませんと。 だから、「今すぐ」でなくとも移行というのが現実的でない ということなのでは? いままで移行してないなら、では一体 いつになったら移行するのです? 今使えているシステムの 「寿命」が尽きる時というのがせいぜいではないのですか? -- のぞみ From naruse ＠ airemix.com Mon May 22 23:37:01 2006 From: naruse ＠ airemix.com (NARUSE, Yui) Date: Mon, 22 May 2006 23:37:01 +0900 Subject: [LE-talk-ja 238] =?iso-2022-jp?b?UmU6IBskQj1FSiNJZDlmMj1KODt6GyhC?= In-Reply-To: <20060522.231500.34750961.nozomi@biol.tsukuba.ac.jp> References: <4470D4A4.1040208@airemix.com> <20060522.061909.35675663.nozomi@biol.tsukuba.ac.jp> <44715F68.10809@airemix.com> <20060522.231500.34750961.nozomi@biol.tsukuba.ac.jp> Message-ID: <4471CC8D.1030502@airemix.com> 成瀬です。 Nozomi Ytow wrote: > "NARUSE, Yui" wrote: >> 確かに由来はそうですし、語義もそうですが、 >> XMLにおけるencodingと同じものと理解しています。 > > 「XML の encoding 属性と同じ」という理解がどうして > 「CP932 というのはある文字集合と Unicode との対応表」 > という理解になるのかわかりませんが、コードページの語義が > 対応表でないなら、対応表だという理解を根拠とされても... Codepageそれぞれの定義が、Unicode との対応関係によって、 定義されているという趣旨です。 例えば、CP932 の定義は http://www.microsoft.com/globaldev/reference/dbcs/932.mspx にありますが、Unicodeとの対応で定義されていますよね。 「CP932 というのはある文字集合と Unicode との対応表」 という表現に語弊があるならば、 * Unicodeとの対応によって定義された文字集合 や * Unicode の サブセット でしょうか。 > 仮に libiconv が「区別するUnicodeに変換」することを許すなら、 > それはもはや内部コードではないでしょう。 ですよね。 >>>> Unicode へのコンバータ作るだけで実装自体は終わりますね。 >>> では iconv が今回対象の文字コードをサポートしているのだから >>> もういい事になってしまうのでは? >> Perl/Encode等はiconvを使いませんから。 >> これらが自前で抱えているコンバータにも手を入れませんと。 > > だから、「今すぐ」でなくとも移行というのが現実的でない > ということなのでは? いままで移行してないなら、では一体 > いつになったら移行するのです? 今使えているシステムの > 「寿命」が尽きる時というのがせいぜいではないのですか? 「寿命」が尽きた時に移行できるように、という話でしょう。 もちろん、いつまでも移行できない部分もあるでしょうが。 -- NARUSE, Yui DBDB A476 FDBD 9450 02CD 0EFC BCE3 C388 472E C1EA From kazama ＠ mac.com Tue May 23 05:44:01 2006 From: kazama ＠ mac.com (Kazuhiro Kazama) Date: Tue, 23 May 2006 05:44:01 +0900 Subject: [LE-talk-ja 239] =?iso-2022-jp?b?UmU6IBskQj1FSiNJZDlmMj1KODt6GyhC?= In-Reply-To: <20060522.230448.77415405.nozomi@biol.tsukuba.ac.jp> References: <2f11576a0605181905m6e0e3520h540ced0fb15a2429@mail.gmail.com> <20060519.154500.77414785.nozomi@biol.tsukuba.ac.jp> <20060522142159.89F0.MORIYAMA@miraclelinux.com> <20060522.230448.77415405.nozomi@biol.tsukuba.ac.jp> Message-ID: <8866FF6D-47CA-4FD2-A47B-223CBF006759@mac.com> On 2006/05/22, at 23:04, Nozomi Ytow wrote: >> レガシーエンコーディング間の変換で重複符号化文字を維持したま >> ま変換可能 >> にする事に関しては、Windows と異なる重複符号化文字の扱 >> いをする事は、メ >> リットよりもデメリットの方が多くなってしまうのではないかと思 >> います。 > > それはそれで理解できますが、round trip を保証しなかった > り、区別できる > ものを区別しなかったりというのは、いくら元の文字集合が集合に > なって > いないからとは言え変換系としては「えっ」思わせるので、ドキュメ > ントに > メリットデメリットを列挙した上で、それでもこういう仕様にするの > だと > 書いておくべきだと思います。 結局レガシーエンコーディングに関しては，バグ（問題）も仕様（泣） なのかもしれないと思います．前向きな方法で問題を完全に解消できれ ばいいのですが，結局過去の因縁を引きづりすぎていて，完全に解消で きない．としたら，変えない方が，少なくとも問題をこれ以上増やさな いことになるからです．問題を増やされるのは非常に困ります． ところで，今この種の「バッドノウハウ」をまとめることを考えていま す．たとえば，MSの国際化本の新版には，"Risky Characters"という章があり（たぶん新設），ここに問題を起こしそう な文字とその状況が分析されていて，非常に興味深いです． 同じような，日本語関連のレガシーエンコーディングの「バッドノウハ ウ」や「危険な文字」を，とりあえずフリー形式で蓄積していこうかな というわけです．他の人は，どう思われるでしょうか？(あまり 同意が得られなければ，個人的にやろうと思っていますが) なお，最終的には，それをさらにまとめあげてドキュメントに追加する のが良いと思います．実装者に詳細な文字コードに関する知識を要求す るのは過酷ですが，eucJP-msとCP51932の議論で，この実 装・利用に関する判断はとても簡単じゃないぞ…と感じたので，少なく とも問題が生じるような状況の使い分けの目安は明確に示唆すべきでは ないかと． そして，さらに進んだ知識を得たい人のために，バッドノウハウ集を残 しておく（最終ドキュメントを作るための資料という形か，ドキュメン トの付録という形かはわからないけど）というのがよいかと． > 「現実問題としてコードの登場頻度が少ないだろう」という理由より > は、 > 内部コードへの依存性が高まってしまうので共通の文字コード変換 > 仕様としてはモジュラリティの観点から適当でない、という理由の方が > 説得力があると思います。 確かに頻度を例として挙げるのは，あまりよくありませんね． あと，UCS正規化方式では，内部コードの状態で流出する可能性も (特に今後は)高いという点もあるでしょう． ＃ 今日は出張でメールが読めません． --- Kazuhiro Kazama kazama ＠ mac.com From nozomi ＠ biol.tsukuba.ac.jp Tue May 23 07:31:44 2006 From: nozomi ＠ biol.tsukuba.ac.jp (Nozomi Ytow) Date: Tue, 23 May 2006 07:31:44 +0900 (JST) Subject: [LE-talk-ja 240] =?iso-2022-jp?b?UmU6IBskQj1FSiNJZDlmMj1KODt6GyhC?= In-Reply-To: <8866FF6D-47CA-4FD2-A47B-223CBF006759@mac.com> References: <20060522142159.89F0.MORIYAMA@miraclelinux.com> <20060522.230448.77415405.nozomi@biol.tsukuba.ac.jp> <8866FF6D-47CA-4FD2-A47B-223CBF006759@mac.com> Message-ID: <20060523.073144.98876592.nozomi@biol.tsukuba.ac.jp> > 結局レガシーエンコーディングに関しては，バグ（問題）も仕様（泣） > なのかもしれないと思います． レガシーに限らず、誤りは人の常でしょう。 > たとえば，MSの国際化本の新版には ポインタ求む。 > 同じような，日本語関連のレガシーエンコーディングの「バッドノウハ > ウ」や「危険な文字」を，とりあえずフリー形式で蓄積していこうかな > というわけです．他の人は，どう思われるでしょうか？(あまり > 同意が得られなければ，個人的にやろうと思っていますが) 是非やりましょう。このプロジェクトの副産物としても良いと思います。 「折角使えるものがあってもどう使ってよいかわからない状態」を 避ける上で確かに助かると思います。 > あと，UCS正規化方式では，内部コードの状態で流出する可能性も > (特に今後は)高いという点もあるでしょう． これはそうしちゃう奴の問題、内部と外部の区別のない実装の 問題ではないかと。 -- のぞみ From m-kosaki ＠ ceres.dti.ne.jp Tue May 23 12:30:00 2006 From: m-kosaki ＠ ceres.dti.ne.jp (=?ISO-2022-JP?B?GyRCPi46ajtxOS0bKEI=?=) Date: Tue, 23 May 2006 12:30:00 +0900 Subject: [LE-talk-ja 241] =?iso-2022-jp?b?UmU6IBskQj1FSiNJZDlmMj1KODt6GyhC?= In-Reply-To: <8866FF6D-47CA-4FD2-A47B-223CBF006759@mac.com> References: <2f11576a0605181905m6e0e3520h540ced0fb15a2429@mail.gmail.com> <20060519.154500.77414785.nozomi@biol.tsukuba.ac.jp> <20060522142159.89F0.MORIYAMA@miraclelinux.com> <20060522.230448.77415405.nozomi@biol.tsukuba.ac.jp> <8866FF6D-47CA-4FD2-A47B-223CBF006759@mac.com> Message-ID: <2f11576a0605222029v17b0aec3q68442ea5b14e977e@mail.gmail.com> 小崎です。 > 結局レガシーエンコーディングに関しては，バグ（問題）も仕様（泣） > なのかもしれないと思います．前向きな方法で問題を完全に解消できれ > ばいいのですが，結局過去の因縁を引きづりすぎていて，完全に解消で > きない．としたら，変えない方が，少なくとも問題をこれ以上増やさな > いことになるからです．問題を増やされるのは非常に困ります． > > ところで，今この種の「バッドノウハウ」をまとめることを考えていま > す．たとえば，MSの国際化本の新版には，"Risky > Characters"という章があり（たぶん新設），ここに問題を起こしそう > な文字とその状況が分析されていて，非常に興味深いです． ISBNとかASIN（Amazonコード）とか教えていただけると、みなさんハッピーになれるかと（＾−＾＊ > 同じような，日本語関連のレガシーエンコーディングの「バッドノウハ > ウ」や「危険な文字」を，とりあえずフリー形式で蓄積していこうかな > というわけです．他の人は，どう思われるでしょうか？(あまり > 同意が得られなければ，個人的にやろうと思っていますが) 実は同じことを考えていました。 もうすぐ自分のブログの記事にまとめようとしていますが、 現状日本のBlog界はEUC-JPがデファクトで、IEとfirefox の動作として EUC-JPのPOSTに関してIEとfirefoxはそれぞれ以下の仕様になります。 IE firefox NEC特殊文字（１３区） 生EUC ←に同じ IBM拡張文字 生EUC（INEC選定IBM拡張文字に変換) ←に同じ NEC選定IBM拡張文字 生EUC ←に同じ 補助漢字 数値文字参照に変換 生EUC EUC-JP外文字（ハングルとか） 数値文字参照に変換 ←に同じ と補助漢字だけIEとfirefoxで異なっており、 ・firefoxで補助漢字を入力し、かつ ・IEでそれを閲覧したとき のみ文字化けが発生します。 以上から、「セーブ・ザ・オーガィ」プロジェクトとして、ブラウザのjavascriptでPOST直前に 補助漢字をすべて数値文字参照（HTMLの &#xxxx; 形式）に変換してからPOSTしてやる スクリプトを作って配布してあげると、結構な割合で幸せになれるような気がします。 こちらのコードの作成も遅々として進行中です。 そもそも補助漢字をわざわざ入力する人が少ないのに、なにが結構な割合か。 という指摘はあるかと思いますが（＾＾； なお、はてなだとまる１をトラックバック用にutf-8に変換する処理がバグっていて トラックバックのとき（のみ）まる１が化けますが、これは別の問題 ＞おもにhyoshiokさん これはこれで別途記事にまとめます。 僕は当面、主にブログ界にターゲットを絞って interoperabilityを妨げている 各ブログの独自仕様（へんな変換）を改善してもらうように、動いていこうかなと 思っています。 （まだ、思っているだけ） なお，最終的には，それをさらにまとめあげてドキュメントに追加する > のが良いと思います．実装者に詳細な文字コードに関する知識を要求す > るのは過酷ですが，eucJP-msとCP51932の議論で，この実 > 装・利用に関する判断はとても簡単じゃないぞ…と感じたので，少なく > とも問題が生じるような状況の使い分けの目安は明確に示唆すべきでは > ないかと． > > そして，さらに進んだ知識を得たい人のために，バッドノウハウ集を残 > しておく（最終ドキュメントを作るための資料という形か，ドキュメン > トの付録という形かはわからないけど）というのがよいかと． まず、第一歩として、このソフトでEUCといっているのはホンマのEUC、 このソフトでEUCといっているのはeucJP-ms、 このソフトでEUCといっているのはCP50932、というのをまとめると いいんじゃないでしょうか。 普通、自分のEUCの細かい定義は知らなくても使ってるソフトの名前ぐらい言えますよねぇ(n'ω'`) > 「現実問題としてコードの登場頻度が少ないだろう」という理由より > > は、 > > 内部コードへの依存性が高まってしまうので共通の文字コード変換 > > 仕様としてはモジュラリティの観点から適当でない、という理由の方が > > 説得力があると思います。 > > 確かに頻度を例として挙げるのは，あまりよくありませんね． > > あと，UCS正規化方式では，内部コードの状態で流出する可能性も > (特に今後は)高いという点もあるでしょう． > いや、僕は逆にプロジェクトゴールを相互運用性と言い切ってしまって （すいません、先走ってすでにFAQをそのように書き換えてしまいました） 具体的に困っているコミュニティの名前があげられるようなトラブル以外は 一切を無視する。 という方針がいいと思います。 風間さんの言葉でいいかえると、あたらしい混乱を増やさない事優先。 オイラの言葉で無理やり説明すると、TCP/IPの相互接続性ってのはRFCを守ってるだけでは 全然不十分で、すくなくともBSDスタックと通信したときに、ちゃんと通信できる、 性能も出るってのが事実上ほぼ必須要件。 BSDスタックがヘタレな時もみんなブーブーいいつつ、BSDスタックと相性問題がおきないように みんなコードを書き直した。 文字コードもそういう世界になっちゃってるんじゃないかと。 雑多な内容のメールになってしまい申し訳ない。 いつもまとまりがなくて・・・(n'ω'`) -------------- next part -------------- HTMLの添付ファイルを保管しました... URL: http://lists.sourceforge.jp/mailman/archives/legacy-encoding-talk-ja/attachments/20060523/0f23f402/attachment.htm From ogwata ＠ wb4.so-net.ne.jp Tue May 23 13:07:57 2006 From: ogwata ＠ wb4.so-net.ne.jp (Ogata Katsuhiro) Date: Tue, 23 May 2006 13:07:57 +0900 Subject: [LE-talk-ja 242] =?iso-2022-jp?b?UmU6IBskQj1FSiNJZDlmMj1KODt6GyhC?= In-Reply-To: <20060523.073144.98876592.nozomi@biol.tsukuba.ac.jp> References: <20060522142159.89F0.MORIYAMA@miraclelinux.com> <20060522.230448.77415405.nozomi@biol.tsukuba.ac.jp> <8866FF6D-47CA-4FD2-A47B-223CBF006759@mac.com> <20060523.073144.98876592.nozomi@biol.tsukuba.ac.jp> Message-ID: <791D53D5-7E9C-43A9-8BC3-6DCADBBB2C35@wb4.so-net.ne.jp> 小形です。 On 2006/05/23, at 7:31, Nozomi Ytow wrote: >> たとえば，MSの国際化本の新版には > > ポインタ求む。 ご本人、出張中のようなので代わりにお答えしますと、 恐らく下記の本とと思います。 Developing International Software 2nd Edition http://www.amazon.co.jp/gp/product/0735615837/249-0596983-8900351? v=glance&n=1000 主な見出しを書きだしてみます Sauce of Risky Characters Risky Unicode Characters Risky Characters in Windows Code Pages East Asian Risky Characters ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 小形克宏 (うさぱら有限会社)/ OGATA Katsuhiro (USAPARA corp.) ogwata ＠ mxa.mesh.ne.jp From sio-0 ＠ rh.to Tue May 23 22:31:55 2006 From: sio-0 ＠ rh.to (Koichi Hyodo) Date: Tue, 23 May 2006 22:31:55 +0900 Subject: [LE-talk-ja 243] =?iso-2022-jp?b?UmU6IBskQj1FSiNJZDlmMj1KODt6GyhC?= In-Reply-To: <2f11576a0605222029v17b0aec3q68442ea5b14e977e@mail.gmail.com> Message-ID: 兵藤です > From: 小崎資広 > Date: Tue, 23 May 2006 12:30:00 +0900 > Subject: [LE-talk-ja 241] Re: 重複符号化文字 > > まず、第一歩として、このソフトでEUCといっているのはホンマのEUC、 > このソフトでEUCといっているのはeucJP-ms、 > このソフトでEUCといっているのはCP50932、というのをまとめると > いいんじゃないでしょうか。 > 普通、自分のEUCの細かい定義は知らなくても使ってるソフトの名前ぐらい言えますよねぇ > (n'ω'`) いいですね。 符号化方式と文字集合の組み合わせは幾通りもあって 符号化方式によっては収容不可能な文字があるのに 単に符号化方式だけしか表明していないソフトが多くて困っていました。 EUCやSJISのローマ字集合の部分も 環境によってASCIIだったりJISローマ字だったり様々ですよね。 同じ部分を「共通の名前」で簡潔明確に表現できるようになると助かります。 From naruse ＠ airemix.com Wed May 24 03:46:00 2006 From: naruse ＠ airemix.com (NARUSE, Yui) Date: Wed, 24 May 2006 03:46:00 +0900 Subject: [LE-talk-ja 244] =?iso-2022-jp?b?UmU6IBskQj1FSiNJZDlmMj1KODt6GyhC?= In-Reply-To: <8866FF6D-47CA-4FD2-A47B-223CBF006759@mac.com> References: <2f11576a0605181905m6e0e3520h540ced0fb15a2429@mail.gmail.com> <20060519.154500.77414785.nozomi@biol.tsukuba.ac.jp> <20060522142159.89F0.MORIYAMA@miraclelinux.com> <20060522.230448.77415405.nozomi@biol.tsukuba.ac.jp> <8866FF6D-47CA-4FD2-A47B-223CBF006759@mac.com> Message-ID: <44735868.3070807@airemix.com> 成瀬です。 Kazuhiro Kazama wrote: > 同じような，日本語関連のレガシーエンコーディングの「バッドノウハ > ウ」や「危険な文字」を，とりあえずフリー形式で蓄積していこうかな > というわけです．他の人は，どう思われるでしょうか？(あまり > 同意が得られなければ，個人的にやろうと思っていますが) 大賛成です。 やってはいけないことと、やらない方がいい事、 やらないで済ませたいけどやらざるをえない事が混ざっている中、 そのような文書はとても役立ちそうです。 -- NARUSE, Yui DBDB A476 FDBD 9450 02CD 0EFC BCE3 C388 472E C1EA From moriyama ＠ miraclelinux.com Wed May 24 14:16:04 2006 From: moriyama ＠ miraclelinux.com (MORIYAMA Masayuki) Date: Wed, 24 May 2006 14:16:04 +0900 (JST) Subject: [LE-talk-ja 245] =?iso-2022-jp?b?UmU6IBskQj1FSiNJZDlmMj1KODt6GyhC?= In-Reply-To: <8866FF6D-47CA-4FD2-A47B-223CBF006759@mac.com> References: <20060522.230448.77415405.nozomi@biol.tsukuba.ac.jp> <8866FF6D-47CA-4FD2-A47B-223CBF006759@mac.com> Message-ID: <20060524141524.B0CE.MORIYAMA@miraclelinux.com> 森山です。 Kazuhiro Kazama wrote: > 同じような，日本語関連のレガシーエンコーディングの「バッドノウハ > ウ」や「危険な文字」を，とりあえずフリー形式で蓄積していこうかな > というわけです．他の人は，どう思われるでしょうか？(あまり > 同意が得られなければ，個人的にやろうと思っていますが) ぜひやりましょう。 メーリングリストでは、あとからの参照がしずらいと思いますので、Wiki な り、掲示板に書き込むようにした方が良いのではないかと思いますが、Legacy Encoding Project の Wiki にバッドノウハウを書き込むためのページを作っ て、気がついた点をどんどん書き込んでいくようにしましょうか。 > > 「現実問題としてコードの登場頻度が少ないだろう」という理由より > > は、 > > 内部コードへの依存性が高まってしまうので共通の文字コード変換 > > 仕様としてはモジュラリティの観点から適当でない、という理由の方が > > 説得力があると思います。 > > 確かに頻度を例として挙げるのは，あまりよくありませんね． 例としては、あまりよくなかったですね。 ただ、非互換にしてまで、実際に使われる可能性の低いものを実装する必要が あるのかどうか。また、複雑化させる事により、文字コードの問題に精通して いる者にしか適切に使えないものになってしまう恐れがあるのではないかと考 えています。 -- 森山 将之 moriyama ＠ miraclelinux.com ミラクル・リナックス株式会社 From sio-0 ＠ rh.to Wed May 24 15:48:47 2006 From: sio-0 ＠ rh.to (Koichi Hyodo) Date: Wed, 24 May 2006 15:48:47 +0900 Subject: [LE-talk-ja 246] =?iso-2022-jp?b?UmU6IBskQj1FSiNJZDlmMj1KODt6GyhC?= In-Reply-To: <8866FF6D-47CA-4FD2-A47B-223CBF006759@mac.com> Message-ID: 兵藤です > From: Kazuhiro Kazama > Date: Tue, 23 May 2006 05:44:01 +0900 > Subject: [LE-talk-ja 239] Re: 重複符号化文字 > 結局レガシーエンコーディングに関しては，バグ（問題）も仕様（泣） > なのかもしれないと思います．前向きな方法で問題を完全に解消できれ (その仕様が今となっては問題ですが ^^;) 重複符号化されているのはバグではなく仕様でしょう。 > ばいいのですが，結局過去の因縁を引きづりすぎていて，完全に解消で > きない．としたら，変えない方が，少なくとも問題をこれ以上増やさな > いことになるからです．問題を増やされるのは非常に困ります． 既存の動作を変えないこと、新たな混乱の種をつくらないようにすること に、私も同意します。その点でこのプロジェクトで既存のencodingの動作 を変更しないという方針はいいものだと思います。 新たな変換表を作ったり、変換器の外(変換器を使うアプリにとっては内部 だが明らかにそれは外 ^^;)に新たな符号化をもたらすようなアイデアは 極めて慎重に考えるべきだとも、思います。 OSを作るわけではないので、既存の変換が必要なアプリのために、既存の 変換器が使えるようになっていれば、変換器が置き換えられてしまうとい う危惧・反対の余地がなくなりますし :-) > 同じような，日本語関連のレガシーエンコーディングの「バッドノウハ > ウ」や「危険な文字」を，とりあえずフリー形式で蓄積していこうかな > というわけです．他の人は，どう思われるでしょうか？(あまり > 同意が得られなければ，個人的にやろうと思っていますが) 賛成です。 文字集合(扱うことのできる文字の範囲・選択)が違うのだということを 強調していただけると助かります。 JISでいうGLの部分が、ASCIIとして解釈されたり、JISローマ字 として解釈されたり、ベンダ独自の解釈をされたりすることも、 加えていただければ、なお助かります。 PS. 余談ですが (^^; いわゆる旧JISの呼出符号が間違っているのは、JIS規格票印刷時の レイアウトミス(バグ)だという話ですよね。その後も確認せず他書を 孫引きしたライターが相次いで既成事実になってしまったという…。 From sio-0 ＠ rh.to Wed May 24 19:37:59 2006 From: sio-0 ＠ rh.to (Koichi Hyodo) Date: Wed, 24 May 2006 19:37:59 +0900 Subject: [LE-talk-ja 247] =?iso-2022-jp?b?V2lraSAbJEIkTkRzMEYbKEIgMyA=?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= Message-ID: 兵藤です http://legacy-encoding.sourceforge.jp/wiki/index.php?%C4%F3%B0%C63 この提案3に書かれている 「cp5022X のユーザ定義文字 (ESC $ B で G0 集合に JIS X 0208 が指示 されている状態で \x7F\x21〜\x92\x7E のコード範囲を使って表現) を受け 取った場合の動作は不定とする」 の部分ですが、単なる'不定'にするよりは'実装依存'にして どのように実装したか明記することを要求するほうが よりよいのではないでしょうか。 From tom ＠ asakawa.ne.jp Thu May 25 08:13:26 2006 From: tom ＠ asakawa.ne.jp (Tomoyuki Asakawa) Date: Thu, 25 May 2006 08:13:26 +0900 Subject: [LE-talk-ja 248] =?iso-2022-jp?b?UmU6IBskQj1FSiNJZDlmMj1KODt6GyhC?= In-Reply-To: References: Message-ID: <8BFF7ED6-4D34-454A-86D0-0E8228C1047E@asakawa.ne.jp> あさかわ > > OSを作るわけではないので、既存の変換が必要なアプリのために、既 > 存の > 変換器が使えるようになっていれば、変換器が置き換えられてしまう > とい > う危惧・反対の余地がなくなりますし :-) この危惧は、承知していますといより、わたしは置き換える事を想定し ています。 もちろん積極的に置き換えを推進しません。 しかし、仮にその置き換えが、よく使われるなら、それがデファクトに なります。 よくつかわれなくても、必要な人が、必要な時に使われるのであれば 新たな、亜種の出現を抑制できます。 この後者のメリットを主張します。 > 新たな変換表を作ったり、変換器の外(変換器を使うアプリに > とっては内部 > だが明らかにそれは外 ^^;)に新たな符号化をもたらすような > アイデアは > 極めて慎重に考えるべきだとも、思います。 内部か、外部かは、概念上のレイヤです。 一般民からすれば、変換器を使うアプリが、境界であって その内部の構造は無関係です。 プログラマが見ると、そこが見えてしまうので、話が、ややこしくなる。 内部／外部の議論は、実装ではなく、応用レベルでする必要がある。 なので、Windowsのみで構成されてる、ネットワークは すべて内部だと考えます。 そこに、MACを、接続したなら、MACは、Winodwsの 内部コードに 「あわせる」べきである。と思います。 で、事実上、このWindwosのネットワークは 社内とか、組織内ではなく、世界に広がってるわけです。 ならば、非Windowsシステムが、Windwowsに「あわせる」 為に必要なものは、用意されていてしかるべきと思うわけです。 わたしは、制限しても、意味が無いというのが、主張です。 過去になんども議論されてると思いますが。 制限論者は、制限しておくと、亜種を作るのが面倒なので、抑制につな がる という主張だとおもいますが。 しかし、制限しても、必要な人は作ります。 実際、制限していたが故に、複数の実装が増えて混乱してるのが現状だ と思うのです なので、現在想定される、実装を、変換器で用意することで 亜種の増殖を抑制できると考えるのです。 亜種のリファレンスモデルを用意するベキというのが私の主張です。 From tom ＠ asakawa.ne.jp Thu May 25 08:21:17 2006 From: tom ＠ asakawa.ne.jp (Tomoyuki Asakawa) Date: Thu, 25 May 2006 08:21:17 +0900 Subject: [LE-talk-ja 249] =?iso-2022-jp?b?UmU6IFdpa2kgGyRCJE5EczBGGyhCIDMg?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: References: Message-ID: あさかわ > の部分ですが、単なる'不定'にするよりは'実装 > 依存'にして > どのように実装したか明記することを要求するほうが > よりよいのではないでしょうか。 不定や、実装依存にするよりも。 「実装」してしまう方が良いと思います 理由は[LE-talk-ja 248]に書いた様に >しかし、制限しても、必要な人は作ります。 >実際、制限していたが故に、複数の実装が増えて混乱してるのが現状だ >と思うのです >なので、現在想定される、実装を、変換器で用意することで >亜種の増殖を抑制できると考えるのです。 という事からです。 From moriyama ＠ miraclelinux.com Thu May 25 19:18:57 2006 From: moriyama ＠ miraclelinux.com (MORIYAMA Masayuki) Date: Thu, 25 May 2006 19:18:57 +0900 (JST) Subject: [LE-talk-ja 250] =?iso-2022-jp?b?UmU6IFdpa2kgGyRCJE5EczBGGyhCIDMg?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: References: Message-ID: <20060525190326.B0F1.MORIYAMA@miraclelinux.com> 森山です。 Tomoyuki Asakawa wrote: > あさかわ > > > の部分ですが、単なる'不定'にするよりは'実装 > > 依存'にして > > どのように実装したか明記することを要求するほうが > > よりよいのではないでしょうか。 > > 不定や、実装依存にするよりも。 > 「実装」してしまう方が良いと思います ISO 2022 を忠実に実装している場合に、0x7F および 0x80〜0x9F は、1バイ トの制御コードとして処理されるでしょう。元の ISO-2022-JP-MS を含め、提 案1〜3 などは、そういった実装をしている場合に、特別な対応を行わなくて も、ISO-2022-JP-MS、案1〜3を追加実装できるように配慮したものになってい ます。 あくまでも、GL での 2バイトコードの範囲は 1バイト目 0x21〜0x7E、 2バイト目 0x21〜0x7E であり、2バイトコードの 1バイト目のコードとして 0x7F〜0x9F を用いるのは間違い(バグ)であるという考えに基づいています。 バグであっても互換性維持のために実装すべきという事であれば、CP5022X と いう名前で Windows の実装に合わせるのが良いと考えています。 -- 森山 将之 moriyama ＠ miraclelinux.com ミラクル・リナックス株式会社 From m-kosaki ＠ ceres.dti.ne.jp Mon May 29 18:33:39 2006 From: m-kosaki ＠ ceres.dti.ne.jp (kosaki) Date: Mon, 29 May 2006 18:33:39 +0900 Subject: [LE-talk-ja 251] =?iso-2022-jp?b?RmlyZWZveBskQiROGyhCRVVD?= =?iso-2022-jp?b?GyRCJE8kSSQmJCIkRCQrJCYkWSQtJCsbKEI=?= Message-ID: <20060529181213.F46F.M-KOSAKI@ceres.dti.ne.jp> 小崎です。 今日は、弾さんからもらったBlogのトラックバックにお返し記事を書こうとして、 結構なボリュームの記事を書いていたのですが、 現在ノートPCの暗号化ソフトの調子が悪くて My Documentsの暗号化が復号できないと言う非常事態に（T_T 更新が大幅に滞りそうな雰囲気の今日この頃、みなさまはいかが お過ごしでしょうか（ｗ さて、ちょっと過疎気味のこのＭＬに話題を投下しようと思い、 作為的にネタを振っているのですが、FirefoxのEUC問題はどうするべきでしょうねぇ・・・ http://mkosaki.blog46.fc2.com/blog-entry-154.html で書いたように現在のBlog界のデファクトはEUCという名前のCP51932 なのですが、Firefoxだけが独自EUC（CP51932+補助漢字）で送ってきており、 サーバー側でUTF-8に変換しようとしたとき （RSSはUTF-8で送らないとほとんどのRSSリーダーが読めない） CP51932 → UTF-8 コンバーターを使っても EUC-JP → UTF-8 コンバーターを使っても文字化けするという ステキな状況になっています。 なお、もじら組の見解は http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=4873 > 結局この問題、Mozillaユーザにとっては何の問題もなく、IEユーザのために機能を削減 > する、というところが問題です。IEユーザのために、Mozillaユーザが不利益を被るとい > うは、私は受け入れがたいです。(これは、IEから乗り換えたユーザを裏切ることになら > ないでしょうか?) という意見によりWont Fix うーん、おっしゃる通りなんだけどね。 たしかにこの文字化けが発言する条件は ・Firefoxで書いたEUCコメントをFirefox以外(の全ブラウザ)で見たとき。 または ・Firefoxで書いたEUCコメントをサーバー側で別の文字コードに 変換しようとしたとき。 の２パターンなので、Firefoxだけで閉じた世界で考えると今の仕様でも いいのかもしれない。 でも、2006年のWebにおいてBlogってそんなに無視していいほどシェア 小さかったっけ？？ というのが割と疑問だったり。 みなさまのご意見をお聞かせくださいませ。 ここで、森山さんあたりが「いやぁ、僕がFirefox EUCに対応したコンバータ作るよ」 とか言い出したら議論が盛り上がる事間違いなしですぞ（マテ あと、もじら組の人をこのＭＬに呼んでこれませんかね？ ＞ 誰ぞツテのあるひと P.S. 弾さん、multipart/form-data でも文字化けは改善しないですよ。 ％エスケープを解いた後に補助漢字が（3byteの）生EUCで出てくるか 数値文字参照で出てくるかがキモですから。 P.S.2 オイラは元々Web屋さんじゃなくて、ブラウザ屋さんなので 論点ずれていたら指摘よろしくです(n'ω'`) -- kosaki From m-kosaki ＠ ceres.dti.ne.jp Mon May 29 20:51:08 2006 From: m-kosaki ＠ ceres.dti.ne.jp (kosaki) Date: Mon, 29 May 2006 20:51:08 +0900 Subject: [LE-talk-ja 252] =?iso-2022-jp?b?UmU6IEZpcmVmb3gbJEIkThsoQkVVQw==?= =?iso-2022-jp?b?GyRCJE8kSSQmJCIkRCQrJCYkWSQtJCsbKEI=?= In-Reply-To: <20060529181213.F46F.M-KOSAKI@ceres.dti.ne.jp> References: <20060529181213.F46F.M-KOSAKI@ceres.dti.ne.jp> Message-ID: <20060529205026.F477.M-KOSAKI@ceres.dti.ne.jp> 小崎です なんか、動くようになったので、Blog記事を更新しました。 コメントいただけると嬉しいっす(n'ω'`) http://mkosaki.blog46.fc2.com/blog-entry-158.html -- kosaki From naruse ＠ airemix.com Mon May 29 22:09:36 2006 From: naruse ＠ airemix.com (NARUSE, Yui) Date: Mon, 29 May 2006 22:09:36 +0900 Subject: [LE-talk-ja 253] =?iso-2022-jp?b?UmU6IEZpcmVmb3gbJEIkThsoQkVVQw==?= =?iso-2022-jp?b?GyRCJE8kSSQmJCIkRCQrJCYkWSQtJCsbKEI=?= In-Reply-To: <20060529181213.F46F.M-KOSAKI@ceres.dti.ne.jp> References: <20060529181213.F46F.M-KOSAKI@ceres.dti.ne.jp> Message-ID: <447AF290.2040902@airemix.com> 成瀬です。 kosaki wrote: > http://mkosaki.blog46.fc2.com/blog-entry-154.html > で書いたように現在のBlog界のデファクトはEUCという名前のCP51932 > なのですが、Firefoxだけが独自EUC（CP51932+補助漢字）で送ってきており、 > サーバー側でUTF-8に変換しようとしたとき > （RSSはUTF-8で送らないとほとんどのRSSリーダーが読めない） Firefox が CP51932 で送ってくるのは知っていましたが、 補助漢字も送っていたとは・・・、知りませんでした。 > CP51932 → UTF-8 コンバーターを使っても > EUC-JP → UTF-8 コンバーターを使っても文字化けするという > ステキな状況になっています。 結局のところ、どの EUC-JP 関連仕様にも沿っていないということですよね。 > なお、もじら組の見解は > http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=4873 > >> 結局この問題、Mozillaユーザにとっては何の問題もなく、IEユーザのために機能を削減 >> する、というところが問題です。IEユーザのために、Mozillaユーザが不利益を被るとい >> うは、私は受け入れがたいです。(これは、IEから乗り換えたユーザを裏切ることになら >> ないでしょうか?) > > という意見によりWont Fix Mozilla の独自拡張ですので、機能削減するべきでしょう。 標準への準拠が彼らの正義だったはずですし。 CP51932 か eucJP-ms のどちらかにそろえるべきでは。 > でも、2006年のWebにおいてBlogってそんなに無視していいほどシェア > 小さかったっけ？？ > というのが割と疑問だったり。 Firefoxで補助漢字を投稿する人がいるEUC-JPのblogと限定すると、 ちょっと微妙かもしれません。 > みなさまのご意見をお聞かせくださいませ。 > > ここで、森山さんあたりが「いやぁ、僕がFirefox EUCに対応したコンバータ作るよ」 > とか言い出したら議論が盛り上がる事間違いなしですぞ（マテ nkf のEUCデコーダはちょうどこれですよ。 なので、nkf で戻せます。 # なのでeucJP-msのユーザ定義文字が死にます # 出力はしません:) > あと、もじら組の人をこのＭＬに呼んでこれませんかね？ > ＞ 誰ぞツテのあるひと 普通にそのバグに、 「CP51932に準拠しつつ、補助漢字を変換するのは独自拡張」 と書くついでに宣伝してくればよろしいかと。 -- NARUSE, Yui DBDB A476 FDBD 9450 02CD 0EFC BCE3 C388 472E C1EA From tommy ＠ tmtm.org Mon May 29 23:05:46 2006 From: tommy ＠ tmtm.org (=?ISO-2022-JP?B?GyRCJEgkXyQ/JF4kNSRSJG0bKEI=?=) Date: Mon, 29 May 2006 23:05:46 +0900 Subject: [LE-talk-ja 254] =?iso-2022-jp?b?UmU6IEZpcmVmb3gbJEIkThsoQkVVQw==?= =?iso-2022-jp?b?GyRCJE8kSSQmJCIkRCQrJCYkWSQtJCsbKEI=?= In-Reply-To: <447AF290.2040902@airemix.com> References: <20060529181213.F46F.M-KOSAKI@ceres.dti.ne.jp> <447AF290.2040902@airemix.com> Message-ID: <20060529230546.4e85cfcf.tommy@tmtm.org> とみたです。 今までROMってました… というかついていけてないので、外してたらすいません。 On Mon, 29 May 2006 22:09:36 +0900 "NARUSE, Yui" wrote: > Mozilla の独自拡張ですので、機能削減するべきでしょう。 > 標準への準拠が彼らの正義だったはずですし。 > CP51932 か eucJP-ms のどちらかにそろえるべきでは。 CP51932 とか eucJP-ms が「標準」という認識があるかどうかですね。 > 普通にそのバグに、 > 「CP51932に準拠しつつ、補助漢字を変換するのは独自拡張」 > と書くついでに宣伝してくればよろしいかと。 なんか、「CP51932だってマイクロソフトの独自拡張じゃないか」と返されそ うな気もするのですが…。 -- とみたまさひろ 3469 42CC 4D32 F53C AD98 65A5 8C37 FF09 69C1 6040 From m-kosaki ＠ ceres.dti.ne.jp Mon May 29 23:29:46 2006 From: m-kosaki ＠ ceres.dti.ne.jp (kosaki) Date: Mon, 29 May 2006 23:29:46 +0900 Subject: [LE-talk-ja 255] =?iso-2022-jp?b?UmU6IEZpcmVmb3gbJEIkThsoQkVVQw==?= =?iso-2022-jp?b?GyRCJE8kSSQmJCIkRCQrJCYkWSQtJCsbKEI=?= In-Reply-To: <20060529230546.4e85cfcf.tommy@tmtm.org> References: <447AF290.2040902@airemix.com> <20060529230546.4e85cfcf.tommy@tmtm.org> Message-ID: <20060529231440.EAD2.M-KOSAKI@ceres.dti.ne.jp> 小崎です。 マルチレスです。 > > ここで、森山さんあたりが「いやぁ、僕がFirefox EUCに対応したコンバータ作るよ」 > > とか言い出したら議論が盛り上がる事間違いなしですぞ（マテ > > nkf のEUCデコーダはちょうどこれですよ。 > なので、nkf で戻せます。 > # なのでeucJP-msのユーザ定義文字が死にます > # 出力はしません:) おおお、絶対サポートするソフトが現れないと思っていた Firefox EUCにこんな伏兵が。 とすると現状 Rails がFirefox語を解する空前、そしておそらく絶後の フレームワークなわけですな。 思いっきり脱線ですが、極めて興味深い。 > > Mozilla の独自拡張ですので、機能削減するべきでしょう。 > > 標準への準拠が彼らの正義だったはずですし。 > > CP51932 か eucJP-ms のどちらかにそろえるべきでは。 > > CP51932 とか eucJP-ms が「標準」という認識があるかどうかですね。 eucJP-msはWebではまったくマイナーなのでそれはナシかなぁ・・・ ＃これ以上混乱を拡大して欲しくない 僕的には ASCII + JIS X 208だけの狭いEUC or CP51932 ですかねぇ。 どうせ数値文字参照で全Unicode code point サポートできるんだから プロトコル的にどこまでを生データで流すかなんて飾りですよ。 ＃エライ人にはそれが分からんのです ま、現状いろいろ通信相手ソフトにバグがあるのでむやみに 数値文字参照をオススメできない部分もあるんですが・・・(n'ω'`) > > 普通にそのバグに、 > > 「CP51932に準拠しつつ、補助漢字を変換するのは独自拡張」 > > と書くついでに宣伝してくればよろしいかと。 > > なんか、「CP51932だってマイクロソフトの独自拡張じゃないか」と返されそ > うな気もするのですが…。 Mozilla-org のstandard, non-standardという区分からは おっしゃるとおりだと思います。 しかし私は２つの点で反論したい。 まず第一に、http://mkosaki.blog46.fc2.com/blog-entry-158.htmlで 書いたようにMozillaの連中はstandard な決まりがなくてIEルールと NNルールがあるけど、IEルールのほうがスジがいいからIEルールに合わせるよう に変更するよん。 といって、今の仕様になっているわけで。 日本語の範囲だけ、言ってることとやってることが違うだろ状態なわけです。 またCP51932はたしかにマイクロソフト発で公的な機関のお墨付きは なにもありませんが、彼らはCP51932の仕様をドキュメント化した上で 将来的にも勝手に変えないよん。と約束してくれています。 片やFirefoxはドキュメントなしの実装をリバースエンジニアリングしてね 状態です。 かつ、将来的に挙動が変わらない保障はどこにもありません。 この状態ではFirefoxにあわせてEUCを実装するのに二の足を踏むのが 大方の開発者の反応ではないでしょうか。 つまり、Firefox EUCを理解するパッチを作ってもコミュニティにマージされて いかないんじゃないの。ってのを気にしています。 -- kosaki From hyoshiok ＠ miraclelinux.com Mon May 29 23:41:05 2006 From: hyoshiok ＠ miraclelinux.com (Hiro Yoshioka) Date: Mon, 29 May 2006 23:41:05 +0900 (JST) Subject: [LE-talk-ja 256] =?iso-2022-jp?b?UmU6IEZpcmVmb3gbJEIkThsoQkVVQw==?= =?iso-2022-jp?b?GyRCJE8kSSQmJCIkRCQrJCYkWSQtJCsbKEI=?= In-Reply-To: <20060529231440.EAD2.M-KOSAKI@ceres.dti.ne.jp> References: <447AF290.2040902@airemix.com> <20060529230546.4e85cfcf.tommy@tmtm.org> <20060529231440.EAD2.M-KOSAKI@ceres.dti.ne.jp> Message-ID: <20060529.234105.653229975.hyoshiok@miraclelinux.com> よしおかです。 > 小崎です。 > マルチレスです。 こんにちは、 ああ、各論にはなるべくはいりこまないようにしようとしたのですが > まず第一に、http://mkosaki.blog46.fc2.com/blog-entry-158.htmlで > 書いたようにMozillaの連中はstandard な決まりがなくてIEルールと > NNルールがあるけど、IEルールのほうがスジがいいからIEルールに合わせるよう > に変更するよん。 > といって、今の仕様になっているわけで。 > 日本語の範囲だけ、言ってることとやってることが違うだろ状態なわけです。 個人的なことを言えばIEコンパチビリティ優先かと思います。 なので、Firefoxにハックだ〜 よ -- Hiro Yoshioka CTO/Miracle Linux Corporation http://blog.miraclelinux.com/yume/ From hyoshiok ＠ miraclelinux.com Mon May 29 23:48:34 2006 From: hyoshiok ＠ miraclelinux.com (Hiro Yoshioka) Date: Mon, 29 May 2006 23:48:34 +0900 (JST) Subject: [LE-talk-ja 257] =?iso-2022-jp?b?GyRCRWo5RjxUJUglQyVXGyhCMzA=?= Message-ID: <20060529.234834.336481900.hyoshiok@miraclelinux.com> よしおかです。 昨日までの投稿者ランキングをとってみました。 $ time egrep '^From:' /tmp/le.txt|sort|uniq -c|sort -r|cat -n 1 48 From: kazama at mac.com (Kazuhiro Kazama) 2 43 From: moriyama at miraclelinux.com (MORIYAMA Masayuki) 3 31 From: tom at asakawa.ne.jp (Tomoyuki Asakawa) 4 23 From: yw3t-trns at asahi-net.or.jp (Tadamasa Teranishi) 5 22 From: nozomi at biol.tsukuba.ac.jp (Nozomi Ytow) 6 22 From: naruse at airemix.com (NARUSE, Yui) 7 11 From: hyoshiok at miraclelinux.com (Hiro Yoshioka) 8 9 From: m-kosaki at ceres.dti.ne.jp (kosaki) 9 8 From: umq.876 at gmail.com (Hirohisa Yamaguchi) 10 6 From: taca at back-street.net (Takahiro Kambe) 11 4 From: msyk at mtg.biglobe.ne.jp (MORIYAMA Masayuki) 12 3 From: sio-0 at rh.to (Koichi Hyodo) 13 3 From: ogwata at wb4.so-net.ne.jp (Ogata Katsuhiro) 14 3 From: numata at jp.fujitsu.com (NUMATA Toshinori) 15 3 From: motoyuki at bc4.so-net.ne.jp (OGAWA Motoyuki) 16 3 From: m-kosaki at ceres.dti.ne.jp (=?ISO-2022-JP?B?GyRCPi46ajtxOS0bKEI=?=) 17 3 From: Kazuhiro Kazama 18 2 From: yanagisw at gmail.com (Yanagisawa) 19 2 From: y.naoi at glamour.co.jp (NAOI Yasushi) 20 1 From: shinichiro at stained-g.net (Shinichiro HIDA) 21 1 From: nishida at miraclelinux.com (Shigeo Nishida) 22 1 From: murata656 at oki.com (Toshiki Murata) 23 1 From: legacy-encoding-talk-ja-bounces ＠ lists.sourceforge.jp [mailto:legacy-encoding-talk-ja-bounces ＠ lists.sourceforge.jp] On Behalf Of Tomoyuki Asakawa 24 1 From: OGAWA Motoyuki 25 1 From: Nozomi Ytow 26 1 From: MORIYAMA Masayuki 27 1 From: LE-talk-ja.hata at ml.mailso.net (Hata) 28 1 From: "Hirohisa Yamaguchi" real 0m32.726s user 0m32.685s sys 0m0.044s From:が微妙に違う人もいるんですが適当に手で集計しちゃって ください。 それよか、びっくりしたのはgrepが異様に遅いのですが LANG=ja_JP.UTF-8 だといけないみたいで、 $ time egrep '^From:' /tmp/le.txt|wc 258 1521 12538 real 0m32.285s user 0m32.376s sys 0m0.024s $ time LANG=C egrep '^From:' /tmp/le.txt|wc 258 1521 12538 real 0m0.156s user 0m0.151s sys 0m0.005s 200倍違うんですけど、そーゆーもんなんすか？＞grep どうもmbrtowcでいちいちwcharにしているのが無駄に 遅いみたいですね。 よ -- Hiro Yoshioka CTO/Miracle Linux Corporation http://blog.miraclelinux.com/yume/ From m-kosaki ＠ ceres.dti.ne.jp Mon May 29 23:49:29 2006 From: m-kosaki ＠ ceres.dti.ne.jp (kosaki) Date: Mon, 29 May 2006 23:49:29 +0900 Subject: [LE-talk-ja 258] =?iso-2022-jp?b?UmU6IEZpcmVmb3gbJEIkThsoQkVVQw==?= =?iso-2022-jp?b?GyRCJE8kSSQmJCIkRCQrJCYkWSQtJCsbKEI=?= In-Reply-To: <20060529.234105.653229975.hyoshiok@miraclelinux.com> References: <20060529231440.EAD2.M-KOSAKI@ceres.dti.ne.jp> <20060529.234105.653229975.hyoshiok@miraclelinux.com> Message-ID: <20060529234552.EAD5.M-KOSAKI@ceres.dti.ne.jp> 小崎です。 どもです。 > > まず第一に、http://mkosaki.blog46.fc2.com/blog-entry-158.htmlで > > 書いたようにMozillaの連中はstandard な決まりがなくてIEルールと > > NNルールがあるけど、IEルールのほうがスジがいいからIEルールに合わせるよう > > に変更するよん。 > > といって、今の仕様になっているわけで。 > > 日本語の範囲だけ、言ってることとやってることが違うだろ状態なわけです。 > > 個人的なことを言えばIEコンパチビリティ優先かと思います。 > なので、Firefoxにハックだ〜 んじゃ、まず http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=4873 で Wont FixになっちゃってるEUC問題を reopenするので、 説得も援護射撃よろしくです -- kosaki From kbk ＠ kt.rim.or.jp Tue May 30 00:40:04 2006 From: kbk ＠ kt.rim.or.jp (KIMURA Koichi) Date: Tue, 30 May 2006 00:40:04 +0900 Subject: [LE-talk-ja 259] =?iso-2022-jp?b?UmU6IBskQkVqOUY8VCVIJUMlVxsoQjMw?= In-Reply-To: <20060529.234834.336481900.hyoshiok@miraclelinux.com> References: <20060529.234834.336481900.hyoshiok@miraclelinux.com> Message-ID: <447B15D4.6060609@kt.rim.or.jp> 木村です。 初投稿がこれというのもなんなのだろうかと思いますが(^^; Hiro Yoshioka さんは書きました (2006/05/29 23:48): > それよか、びっくりしたのはgrepが異様に遅いのですが > LANG=ja_JP.UTF-8 だといけないみたいで、 > > $ time egrep '^From:' /tmp/le.txt|wc > 258 1521 12538 > > real 0m32.285s > user 0m32.376s > sys 0m0.024s > $ time LANG=C egrep '^From:' /tmp/le.txt|wc > 258 1521 12538 > > real 0m0.156s > user 0m0.151s > sys 0m0.005s > > 200倍違うんですけど、そーゆーもんなんすか？＞grep GNU grep でしょうか? だとしたらそういうものです。 たびたび「バグだろう」とレポートされている代物です。 日本語環境でなくても、en_US.UTF-8 とか de_DE とかでも なります。以前profileとって少し調べたのですが、wchar_tへの 変換もそうですが、動的にDFAを生成しているのが(マルチバイト文字 対応ルーチンのときに)かなり重いみたいです。 -- 木村浩一 I thought what I'd do was, I'd pretend I was one of those deaf-mutes. mail kbk at kt.rim.or.jp web www.kt.rim.or.jp/~kbk/zakkicho/ homepage3.nifty.com/farstar/ From naruse ＠ airemix.com Tue May 30 01:18:44 2006 From: naruse ＠ airemix.com (NARUSE, Yui) Date: Tue, 30 May 2006 01:18:44 +0900 Subject: [LE-talk-ja 260] =?iso-2022-jp?b?UmU6IEZpcmVmb3gbJEIkThsoQkVVQw==?= =?iso-2022-jp?b?GyRCJE8kSSQmJCIkRCQrJCYkWSQtJCsbKEI=?= In-Reply-To: <20060529230546.4e85cfcf.tommy@tmtm.org> References: <20060529181213.F46F.M-KOSAKI@ceres.dti.ne.jp> <447AF290.2040902@airemix.com> <20060529230546.4e85cfcf.tommy@tmtm.org> Message-ID: <447B1EE4.5070603@airemix.com> 成瀬です。 とみたまさひろ wrote: >> 普通にそのバグに、 >> 「CP51932に準拠しつつ、補助漢字を変換するのは独自拡張」 >> と書くついでに宣伝してくればよろしいかと。 > > なんか、「CP51932だってマイクロソフトの独自拡張じゃないか」と返されそ > うな気もするのですが…。 JIS由来のマッピングをしてその主張ならばわかります。 けれどもあえて CP51932 を採用したわけで、 そこでさらに独自拡張するのはなんか違う気はします。 もっとも、俺仕様を作ることを厭わなければ、極めて妥当な拡張でしょう。 現実的に考えれば、eucJP-moz で入力許すのもアリかなぁとも思いますが :( -- NARUSE, Yui DBDB A476 FDBD 9450 02CD 0EFC BCE3 C388 472E C1EA From hyoshiok ＠ miraclelinux.com Tue May 30 09:34:37 2006 From: hyoshiok ＠ miraclelinux.com (Hiro Yoshioka) Date: Tue, 30 May 2006 09:34:37 +0900 (JST) Subject: [LE-talk-ja 261] =?iso-2022-jp?b?UmU6IBskQkVqOUY8VCVIJUMlVxsoQjMw?= In-Reply-To: <447B15D4.6060609@kt.rim.or.jp> References: <20060529.234834.336481900.hyoshiok@miraclelinux.com> <447B15D4.6060609@kt.rim.or.jp> Message-ID: <20060530.093437.846947875.hyoshiok@miraclelinux.com> よしおかです。 > 木村です。 おはよーございます。 > 初投稿がこれというのもなんなのだろうかと思いますが(^^; いえいえ、ようこそいらっしゃいました。 > Hiro Yoshioka さんは書きました (2006/05/29 23:48): > > > それよか、びっくりしたのはgrepが異様に遅いのですが > > LANG=ja_JP.UTF-8 だといけないみたいで、 > > > > $ time egrep '^From:' /tmp/le.txt|wc > > 258 1521 12538 > > > > real 0m32.285s > > user 0m32.376s > > sys 0m0.024s > > $ time LANG=C egrep '^From:' /tmp/le.txt|wc > > 258 1521 12538 > > > > real 0m0.156s > > user 0m0.151s > > sys 0m0.005s > > > > 200倍違うんですけど、そーゆーもんなんすか？＞grep > > GNU grep でしょうか? だとしたらそういうものです。 やっぱり、そういうものなんですか。 > たびたび「バグだろう」とレポートされている代物です。 > > 日本語環境でなくても、en_US.UTF-8 とか de_DE とかでも > なります。以前profileとって少し調べたのですが、wchar_tへの > 変換もそうですが、動的にDFAを生成しているのが(マルチバイト文字 > 対応ルーチンのときに)かなり重いみたいです。 oprofileしてみますた。 LANG=ja_JP.UTF-8 の場合 # head /tmp/grep_op_l1.txt CPU: P4 / Xeon with 2 hyper-threads, speed 3200.6 MHz (estimated) Counted GLOBAL_POWER_EVENTS events (time during which processor is not stopped) with a unit mask of 0x01 (mandatory) count 10000 samples % app name symbol name 8793343 28.8152 libc-2.3.4.so __gconv_transform_utf8_internal 5348911 17.5281 oprofiled (no symbols) 4036581 13.2276 libc-2.3.4.so mbrtowc 1697574 5.5628 libc-2.3.4.so _IO_vfscanf 1015466 3.3276 oprofile (no symbols) 609007 1.9957 libc-2.3.4.so __i686.get_pc_thunk.bx 529516 1.7352 libc-2.3.4.so memmove LANG=Cの場合は以下のとおり # head /tmp/grep_op_lC.txt CPU: P4 / Xeon with 2 hyper-threads, speed 3200.6 MHz (estimated) Counted GLOBAL_POWER_EVENTS events (time during which processor is not stopped) with a unit mask of 0x01 (mandatory) count 10000 samples % app name symbol name 327913 14.1844 oprofiled (no symbols) 184812 7.9943 libc-2.3.4.so __gconv_transform_utf8_internal 141363 6.1149 libc-2.3.4.so memmove 138621 5.9963 bash (no symbols) 137707 5.9567 oprofile (no symbols) 120875 5.2286 libc-2.3.4.so mbrtowc 119299 5.1605 libc-2.3.4.so _IO_vfscanf うーむ、いかんですね。 よ -- Hiro Yoshioka CTO/Miracle Linux Corporation http://blog.miraclelinux.com/yume/