[LE-talk-ja 241] Re: 重複符号化文字

Back to archive index

小崎資広 m-kos****@ceres*****
2006年 5月 23日 (火) 12:30:00 JST


小崎です。




> 結局レガシーエンコーディングに関しては,バグ(問題)も仕様(泣)
> なのかもしれないと思います.前向きな方法で問題を完全に解消できれ
> ばいいのですが,結局過去の因縁を引きづりすぎていて,完全に解消で
> きない.としたら,変えない方が,少なくとも問題をこれ以上増やさな
> いことになるからです.問題を増やされるのは非常に困ります.
>
> ところで,今この種の「バッドノウハウ」をまとめることを考えていま
> す.たとえば,MSの国際化本の新版には,"Risky
> Characters"という章があり(たぶん新設),ここに問題を起こしそう
> な文字とその状況が分析されていて,非常に興味深いです.


ISBNとかASIN(Amazonコード)とか教えていただけると、みなさんハッピーになれるかと(^−^*




> 同じような,日本語関連のレガシーエンコーディングの「バッドノウハ
> ウ」や「危険な文字」を,とりあえずフリー形式で蓄積していこうかな
> というわけです.他の人は,どう思われるでしょうか?(あまり
> 同意が得られなければ,個人的にやろうと思っていますが)


実は同じことを考えていました。
もうすぐ自分のブログの記事にまとめようとしていますが、

現状日本のBlog界はEUC-JPがデファクトで、IEとfirefox の動作として
EUC-JPのPOSTに関してIEとfirefoxはそれぞれ以下の仕様になります。


IE                                                       firefox
NEC特殊文字(13区)            生EUC
←に同じ
IBM拡張文字                         生EUC(INEC選定IBM拡張文字に変換)    ←に同じ
NEC選定IBM拡張文字            生EUC
←に同じ
補助漢字                               数値文字参照に変換
生EUC
EUC-JP外文字(ハングルとか) 数値文字参照に変換                              ←に同じ

と補助漢字だけIEとfirefoxで異なっており、
・firefoxで補助漢字を入力し、かつ
・IEでそれを閲覧したとき
のみ文字化けが発生します。

以上から、「セーブ・ザ・オーガィ」プロジェクトとして、ブラウザのjavascriptでPOST直前に
補助漢字をすべて数値文字参照(HTMLの &#xxxx; 形式)に変換してからPOSTしてやる
スクリプトを作って配布してあげると、結構な割合で幸せになれるような気がします。
こちらのコードの作成も遅々として進行中です。

そもそも補助漢字をわざわざ入力する人が少ないのに、なにが結構な割合か。
という指摘はあるかと思いますが(^^;

なお、はてなだとまる1をトラックバック用にutf-8に変換する処理がバグっていて
トラックバックのとき(のみ)まる1が化けますが、これは別の問題  >おもに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の添付ファイルを保管しました...
下載 


Legacy-Encoding-talk-ja メーリングリストの案内
Back to archive index