Kazuhiro Kazama
kazam****@mac*****
2006年 5月 18日 (木) 12:44:45 JST
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は誰もつかってない/必要と してないよねえ」という状況が根底にあります． --- 風間 一洋 (kazam****@mac*****)
