Hiro Yoshioka
hyosh****@mirac*****
2006年 5月 18日 (木) 14:57:56 JST
よしおかです。 昨日は出席いただきありがとうございました。 From: Kazuhiro Kazama <kazam****@mac*****> Subject: [LE-talk-ja 128] Re: LE-talk-ja での議論のまとめ Date: Thu, 18 May 2006 13:59:30 +0900 Message-ID: <22441****@mac*****> > 当日も本人に（前半部分を）言いましたが，このまとめに補足します． > > 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は簡単． > ・それ以外でも，レガシーエンコーディングを特定すれば難しくない．ただ > し，一般的には曖昧性があるので，アプリケーション依存で実装することにな > るかも（まあ，できないとは言いませんが…）． > > という感じになるのかもしれません．どうでしょう？ > --- > 風間 一洋 (kazam****@mac*****) > > > _______________________________________________ > Legacy-Encoding-talk-ja mailing list > Legac****@lists***** > http://lists.sourceforge.jp/mailman/listinfo/legacy-encoding-talk-ja
