プロフィール

kosaki

Author:kosaki
連絡先はコチラ

ブログ検索
最近の記事
最近のコメント
最近のトラックバック
リンク
カテゴリー
月別アーカイブ
RSSフィード
FC2ブログランキング

スポンサーサイト このエントリーをはてなブックマークに追加

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。


スポンサー広告 | 【--------(--) --:--:--】 | Trackback(-) | Comments(-)

FirefoxのEUCの独自拡張のセンスが最低な件について このエントリーをはてなブックマークに追加

前回の記事について、説明が不足していたようで、404 Blog Not Found様からmultipart/form-data を忘れている
とお叱りを頂いてしまいました。

えっと、誤解です。
multipart/form-dataを使っても状況はまったく変わらないことが分かったので説明を省略しただけです。


誤解をとくために前回の調査結果を簡単にまとめさせてください。

・Webの世界でEUCといったらCP51932がデファクトスタンダードである
・これは本来のEUCから補助漢字をなくして、かわりにWindows機種依存文字を
追加したものである。
・しかし、FirefoxだけはCP51932+補助漢字という独自拡張EUCを採用している。
・これはURL Encoding の%エスケープを解いたあとのデータが補助漢字に
ついて生EUCとするか、数値文字参照とするか、という違いとして現れてくる。
・結果、IEで送信した文字列は内容によらず、IEでもFirefoxでも見れる。
でも、Firefoxで送信した文字列は補助漢字が含まれていると、
Firefoxでしか見れない。



という結論が得られた。
つまり、%エスケープをほどいた後の話なので%エスケープをしない multipart/form-data でも状況はまったく変わらないのです。


さて、この件、世間様の反応をちょいと調べてみるとBlog界では結構大きな問題になっていることが分かる。

たとえば、はてなアイデアで「文字化け」で登録されているバグのうち、すくなくとも

Unicodeのページから文字を取得する各サービス(ダイアリ(含むasinページ)、
アンテナ)で、EUC-JPに変換できない文字および3バイトEUCになる文字は
数値文字参照にしてほしい


コメント欄でフランス語などが文字化けしないようにしてほしい。

機種依存文字の自動置換もしくは警告。特に○付き数字は利用例が多いが
Macでは(日)(月)(火)もしくは!”#などと見え、意味が伝わり難い。
人力検索は公共性が高いので配慮を。


ユーザから投稿された投稿内容のうち、0x8f で始まる
JIS補助漢字を(非漢字のものだけでも)数値文字参照に変換する。
IE での文字化け防止のため。 http://d.hatena.ne.jp/fenestrae/20050519#c


以上のトラブルは、このFirefoxのUglyな仕様に起因している。



じゃあ、もじらな人々がどういった反応をしているかというと
Bugzilla-jp: bug4873 EUC-JPエンコーダは補助漢字を変換すべきではない において


この問題、私はmixiで知ったんですけど、mixiは&を&に変換しないので、数値文字参
照が送信されても数値文字参照として表示されず、文字として置換表示されますので、こ
のようないい加減なWebアプリでは、ある意味問題無いというか、だからこそ問題が出た
というか。




で、もし数値文字参照として送信した場合なんですが、多くのWebアプリケーションが
やっているように、&を&に置き換えていた場合、結局ただのregressionにしかならな
いと思うんですよ。



とmixiが悪いという見解。
私、ぜんぜん知らなかったんですけれども多くのWebアプリケーションは&を
& に置換しているはず。という主張。
ソースが示されていないので、じゃあなぜ数値文字参照を送っているIEは困っていないのかが
分かりませんでした。
(IEを無視しているWebアプリケーションってあるのかしらん)




ただ、Linuxのユーザグループなんかでは、EUC-JPの使用率高そうな気がしますが、そう
いったところでFedora以外のLinuxが標準で使っているEUC-JPの文字のうちの一部が生で
使えなくなる、ということの方が問題な感じがします。



その後、この発言が WONT-FIX への流れを決めてしまったように見えるが、この発言で数値文字参照を出力することにより困難が生じるコミュニティやソフトウェアの名前は一切明らかになっていないように思える。
ハングルとかが数値文字参照で送られてくるのは処理できるのに、補助漢字が数値文字参照で送られてくると発狂するソフトウェアって逆に難しいと思う・・・・


さらに調査を続けると、Mozillaで数値文字参照で送出する仕様が実装されたのは比較的最近であることが分かった。
すくなくとも、MozillaのEUCの実装よりかはだいぶ後。


Bugzilla bug-117422 トルコ語が文字化けするぞ。というバグ
が 2001-12-30 04:12 PDT にOpenされ、そこで、

コメント19 において


For example, if user put in "abc" + Two chinese characters + "eft" , the unicode
converter will convert "abc" . in 6.2.1, it will convert to "abc" + two question
mark + "eft" since we set the error behavior to repalce fallback to '?' but
someone remove that code (in the current GetEncoder, youc can see that part of
code got commented out ). this is very bad because user could type "Software "
+ Japanese names + " hardware car" when they search google. if we convert to
"software ??? hardware car" then at least the search engine can match "software"
"hardware" and "car", but the current behavior will only send out "software"

the "?" approach is not idea but acceptable. However, when I look at IE6, it
seems they use NCR to encode these "cannot be converted" character, this is not
specified in any standard but nor any standard currently address this issue. I
think it is better to fix this to the IE6-non-standard way, instead of to fix it
to the old Netscape-non-standard way. And since there are currently no standard
which address it, we don't need to worry about standard issue here.



この問題は標準がなく、IEもNetscapeも独自拡張だが、IEの方法のほうがスジがいいので
そちらに挙動を変えよう。
という発言が通って 2002-03-01 12:46 PDT に check-in および verifyが完了している。


本当はこの時にEUC-JPも直せばGoodだったんだけど、まあトルコ語問題で始まったバグをいちいちウォッチしてられないというのも想像に難くないので、ある意味仕方ないのかな。

さて、時は進んで2006年今現在、いまさらEUC-JPのエンコーディング方法を変えるのはどうなのだろう、という議論は識者と一度してみたい。
僕は変えたほうがいいと思っているのだけれど。

僕の知っている範囲で列挙すると論点は以下

・現在のWeb環境でサーバ側のソフトはほぼ漏れなくUnicodeで動作している
(Javaとかperlとか)
・現在のFirefoxの送出するEUCは独自拡張EUCなのでサーバー側で
Unicodeに変換するときに "EUC-JP"→"Unicode" 変換をおこなっても、
"CP51932" → "Unicode" 変換をおこなっても文字化けする
・"CP51932" → "Unicode" コンバータをFirefox独自拡張にも
対応してもらうのは極めて困難が予想される。
CP51932は独自拡張とはいえ、Microsoftが仕様をMSDNや書籍で提示して
将来も変更しない事を明言しているので
海外のメンテナにもURLあそこの仕様を実装したよん。で通じるけれども、
Firefoxのはドキュメントなし独自拡張。
かつIEと違ってデファクトの地位も握っていない。
・もし、サーバー側で個別対処するのであれば
(この時点でサーバ屋さんから猛反発来そうだ)、
Unicodeに変換する前に "補助漢字" → "数値文字参照" 変換を
しなければならないが、
現在の多くのスクリプト言語でそれは不可能である。
かってに、Unicode変換されてしまうケースが多いから。
・通信相手がFirefoxに限られIEの事を考えなくてもよいクローズドな環境で、
かつ補助漢字が3byteで送出されてくると
期待するソフトがあった場合にFirefoxを数値文字参照を送るように変更すると
レベルダウン修正になるがはたしてそんな環境・ソフトは実在するか
・(僕が詳しくないので誰か教えて)Mac では数値文字参照と生EUC補助漢字の
どちらが幸せなのか。



この件に関しては、はてなの中の人とかもじらの中の人とかレガシーエンコーディングプロジェクトの識者の面々とかと今後議論していきたい。あんまりツテがないので大変だけど ;-<



で、ここで終わるとユーザにとって前向きな記事にならないので、もうちょっと対処療法織り交ぜ柔軟に考えてみる。
たぶん、ユーザが幸せになるには以下の方法のどれかを実行すれば言いと思う(排他条件じゃないので注意)

1.GreacemonkeyスクリプトをつくってサーバーにPOSTする前に
数値文字参照に変換
ユーザがわざわざインストールしないといけないのが欠点だが、
たとえばフランス語が文字化けして
死ぬほど困ってる人だったら入れてくれるかも。
(Greacemonkeyって何?ってひとはこちらをどぞ
http://firefox.geckodev.org/index.php?Greasemonkey)
2.JavaScript libraryでサーバーにPOSTする前に数値文字参照に変換
1と似ているけれども、普通のJavascriptライブラリとして提供。
Blogの管理者がこのScriptを設置してくれれば
文字化けがなおるというもの。
1と違い、エンドユーザは明示的にインストールする必要がないのが長所。
はてなのようなユーザーが自分のScriptを置けないようなブログでは使えないのが欠点。
3.補助漢字to数値文字参照 perl library を提供
まあ、Blogのバックエンドはperlが多いだろうと勝手に決めうって
補助漢字を数値文字参照に変換するライブラリを
つくってブログ屋さんに組み込んでよーと宣伝していくというい方法。
ある意味正攻法。うまくいったらクライアント側で何も
対処がいらないって意味で。
でも汚い。激しく汚い。
しかもこういう日本語決めうち特殊処理はi18nなソフトでは
決して受け入れられない。
4.CP51932コンバータをFirefox独自拡張に対応
もう、CP51932を文字通りの意味じゃなくWebで流通してる
EUCという広い意味でとらえてFirefox拡張も
受け入れてしまうという案。
残念なことにFirefox EUCは仕様が公開されていない
(実装が仕様)状態なので、このコンバータが
コミュニティに受け入れられる可能性はきわめて低い。
5.Firefoxを直す
本文でも書いたけど、補助漢字を3バイトEUCで送ってくれないと
破綻するソフトって実在するの?
ってのが争点かと。
実在したらレベルダウン修正になってしまいますからね。


4以外は僕でも出来そうな気がするので(5はパッチが受け入れるか極めて怪しいけど)、意見がある人は○○キボンヌ とかだけでもコメント残して言ってくれるとうれしい。


追記:
5を望む人はここじゃなく、Bugzillaで意思表明をしてもらったほうがいいかな。ここで意思表明してもチラシの裏なので
初稿では僕の書き方が悪かったです。ごめん

では!

関連記事


文字コード | 【2006-05-29(Mon) 20:21:47】 | Trackback:(1) | Comments:(13)
コメント

興味深い内容だったもんで、分からない言葉を調べつつ一生懸命読んだんだけどさ。
右側が上手く改行されずに、またスタイルにも収まっていないのか、切れちゃってて読めん。
うちの環境だけですか?
FFは一旦アンインスコしてるんで、あとでまた最新版入れてみるよ。
今んとこIE6.0で見てます。
文字コードに関しては丁度今色々勉強中だったりするので、こういうエントリは個人的に嬉しいです。
ンジャマタ|Д´)ノシ
2006-05-29 月 09:27:45 | URL | mink #- [ 編集]

ほんまや。直します。ごめん
2006-05-29 月 09:28:43 | URL | 革命の日々 #- [ 編集]

なるせさん曰く、nkfは偶然にもFirefox EUCを解釈できるようです。
さすがというかなんというか・・・
2006-05-29 月 09:42:58 | URL | 革命の日々 #- [ 編集]

おや、なんかはてぶニュースにのったみたい。
文字コードなんてマイナーな分野で、なんとまあ酔狂な
2006-05-29 月 22:11:28 | URL | 革命の日々 #- [ 編集]

現実に困るじゃんという話を無視して建前論を言ってしまうと、本当は CP51932 なのに EUC-JP を名乗るのも、あるいは CP51932+補助漢字 なのに EUC-JP を名乗るのも、どちらも悪いのでは?
両方とも IANA の registry に登録して使うのが正しいような。
2006-05-31 水 21:51:36 | URL | soda #- [ 編集]

建前に寄り添いつつ、やや中間的な視点から言うと、Firefoxの実装は、IANAに登録されているEUC-JPをサポートした上で「ちょっと融通を利かせてる」ってかんじですよね。一方、IEの実装は「code set 3: JIS X0212-1990 (a double 7-bit byte set) restricted to A0-FF in the first byte and 21-7E in the second byte」をサポートしてないわけで、IEのほうがダメじゃんという気がするのですが。
2006-06-01 木 04:08:57 | URL | NAOI #fzXxwl2E [ 編集]

sodaさん>
ご指摘ありがとうございます。
おっしゃるとおりですね。
この記事はW3CのWebの未来はUTF-8だぜー。って主張を鵜呑みにして、Webに関してはレガシーエンコーディングは for compatibility な機能として、規格的な正しさよりも、現状を悪化させないほうを優先したほうがいいと思っているよん。というのが暗黙のうちに仮定されている悪文です。
これは後日ちゃんと別記事にて補足入れようと思います。
すいません。

ところで、知っていたら教えていただきたいのですが、
奥村先生のblogで
http://oku.edu.mie-u.ac.jp/~okumura/blog/node/794
>しかしiconvにcp50932なんてないぞ。

という発言があるのですが、これはもしやBSD系全般でサポートされていない?
もっと言えば、わたくしがパッチ作ったらacceptされる可能性はあるかしら?

NAOIさま>
なるほど、私のこの記事での論点だけ読むとまさにその通りですね。
これは私の書き方に問題があると思います。申し訳ありません。
実は i18n関係者には将来的にはUTF-8に移行していこうね。それを阻害するようなソフトは作らないよう紳士協定を結ぼうね。という共通認識があり、レガシーエンコーディングにかんして、サブセットには寛大ですが、スーパーセットに関してはものすごく反対されるのです(てゆーか、私も反対する)
将来的には、みんながUTF-8を使うというのが一番幸せなのは間違いなので、その世界へ移行できなくなるような独自拡張は極めて嫌疑の目でみられるのです。
2006-06-04 日 00:16:54 | URL | 革命の日々 #- [ 編集]

NAOIさん>
Firefox の EUC-JP はエンコード時(EUC-JPからUnicodeへの変換)には、「ちょっと融通を利かせてる」と言えますが、デコード時(UnicodeからEUC-JPへの変換)には、JIS X 0212 補助漢字であっても、CP51932 にも同じ文字がある場合は、CP51932 のコードポイントを優先してしまうので、EUC-JP をサポートしていると言えるのか微妙だったりします。
具体的には、Firefox の EUC-JP は POST 時に、草ナギ剛の「ナギ」の文字を JIS X 0212 補助漢字のコードポイントではなく、CP51932 の機種依存文字のコードポイントで POST します。

kosakiさん>
「FirefoxのEUCの独自拡張のセンスが最低」と喧嘩をふっかけてしまっては、売り言葉に買い言葉になってしまう危険がありますね。
難しいことではありますが、お互いが歩み寄れるような提案の仕方をした方が良いのではないでしょうか。
元々 CP51932 のようなものは事実上の標準ではあるかもしれませんが、正式な標準ではなく対応する必要が無いものであると言われれば、それまでなわけですし。
2006-06-05 月 02:51:55 | URL | 森山 将之 #4LGIOTDw [ 編集]

森山さん>
いやあ、まったくおっしゃるとおり、大反省中です(n'ω'`)
元々はもっとギャグ満載の記事だったんで、タイトルもねたとして浮いてなかったんですけど、あとから本文が綺麗になるときにタイトルが残っちゃったんですね。だから真面目に罵倒しているようにも見える(とゆーか、そうとしか見えない)というダメダメっぷり。
そしてさらに失敗したのが、bugzillaにポストするまえに、moz users MLでタイトルはねただから無視して見てねんというポストをしたんだけど、どうも、そっちは技術系の人は誰もみてなかったらしいんだな。
で、bugzillaに書くときにbugzillaのUIに不慣れで(また、失敗するとTextAreaのコメントが全部消えてしまう、ふざけた仕様なんだ。これが)、やっと投稿成功したときは、超無愛想な、ケンカ売り挨拶っすよ。
あれは、あとから読み返してちょっとへこんだ。
中野さんには謝りたいねぇ。ほんと
本気で気分を悪くしてるのが伝わってきたもん。
どこかで飲む席でも作れればいいんだけどねぇ。
2006-06-05 月 04:53:33 | URL | 革命の日々 #- [ 編集]
前回、声がかかっていなかった各種OSSコミュニティを集めてまた弊社でピザ&ビアをやりたいと思います。できれば6月中に。広い範囲で広報したいと思います。
その時は御協力を。
2006-06-06 火 08:15:21 | URL | hyoshiok #OLXj00Ls [ 編集]

おおお、ぜひよろしくお願いいたします~
2006-06-06 火 08:59:32 | URL | 革命の日々 #- [ 編集]
このコメントは管理人のみ閲覧できます
2007-09-01 土 18:34:37 | | # [ 編集]
このコメントは管理人のみ閲覧できます
2007-10-10 水 09:09:59 | | # [ 編集]
繋繫 前回、「秀丸エディタとEUC補助漢字(「繋がる」と「繫がる」)」で書きま
【2006-11-09 Thu 17:41:46】 | WEBプログラミング NOW!
  1. 無料アクセス解析
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。