プロフィール

kosaki

Author:kosaki
連絡先はコチラ

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

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

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


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

プロジェクト「セーブ・ザ・鷗外」 このエントリーをはてなブックマークに追加

最近Legacy Encoding Projectのメーリングリスト(参加はコチラからどうぞ)でEUCの相互運用性(interoperability)を改善しようって話が盛り上がってる。

で、最近ヒトサマのBlogを見ているとBlog界もやっぱりまだまだ文字化けにあふれているようだ。

例えば、浅倉様のはてなもそろそろEncode::EUCJPMSを使ってくれないかなあ
および404 Blog Not Found様のあなたは何の役に立つのか?というエントリのhyoshikさんの ①(まるいち)という文字というエントリからのトラックバックをみるとはてなの吐き出すRSSやPingは「~」「①」は化けるらしい


と、いうわけで、いささか興味がわいたのでちょっと色々調べてみた。
文字化けの原因として、
・ブラウザ側の問題
・サーバー側の問題
・その複合原因
とあるが、今回はブラウザの挙動のみを対象にした。


調査対象のブラウザは以下を選んだ

IE: 6.0.2900.2180.xpsp_sp2_gdr.050301-1519
Firefox: 1.5.0.3
Opera: 8.53(Build 7722)


ちなみに当サイトに訪れるユーザのブラウザの割合は以下のような感じで、

順位 ブラウザ名            パーセント
--------------------------------------
1 Internet Explorer 6 66.19%
2 Firefox 24.44%
3 Safari 2.12%
4 Opera 8 1.28%
5 Internet Explorer 7 1.07%
6 Internet Explorer 5.5 0.94%
7 Opera 8 0.55%
8 Netscape 7 0.48%
9 Internet Explorer 5.0 0.47%
10 Opera 9 0.16%
11 Camino 0.10%
12 Opera 7 0.10%
13 NetFront 0.09%
14 Opera 9 0.05%
15 Netscape 6 0.02%
16 Opera 7 0.02%
17 DoCoMo 0.02%
18 Internet Explorer 4 0.01%
19 Netscape 8 0.01%
20 その他 1.80%


バージョン違い、亜種をまとめると

IE系          68.68% 
Mozilla系 25.05%
Opera系 2.16%
Safari 2.12%
その他 1.91%


という感じでIEとFirefoxだけがちゃんと調べないといけなくて、あとは誤差って感じだ。
調べ方は単純、自分のはてなダイアリーの日記欄に色々なブラウザで同じコメント書いてみて、 etherealでパケットキャプチャー。
どのような文字コードを送出しているか調べるというものだ。(ちなみに、はてなダイアリーの文字コードはEUC-JPである)

脱線だが有名Blogの文字コードをいくつか調べたところ

ブログサーバ    文字コード
---------------------------
はてな EUC-JP
FC2 EUC-JP
livedoor EUC-JP
ココログ UTF-8



という結果になったので、EUCとUTF-8さえ押さえれば、Blog界の文字化け問題の対応としてはだいたいOKと言えそうである。


まず、ASCII文字(アルファベット)

書き込み文字列      abc
------------------------------
IE abc
Firefox abc
Opera abc



すべて同じ結果。
ASCIIしか使わない限りにおいて文字化けは発生しないという、非常に当たり前の結果になった。


次、JIS X 208 のひらがな

書き込み文字列    あいう
--------------------------------------
IE %A4%A2%A4%A4%A4%A6
Firefox %A4%A2%A4%A4%A4%A6
Opera %A4%A2%A4%A4%A4%A6


すべて同じ結果。
さすがに、この程度では文字化けしない。まあ当たり前である。

ここで、規格の復習。
HTMLの規格上、ブラウザは文字列をPOSTするのに、
のmethod属性を設定しないと文字列を URLEncodingというエンコーディングを行ってからPOSTします。
ところが、規格ではASCII の範囲外のエンコーディング方法をちゃんと定めていません。
定めていませんが、大昔、Netscape2.0ぐらいのときにネスケが文字列を「見ている文書がEUCならEUCのバイト列を」
「見ている文書がSJISならSJISのバイト列を」エンコーディングするぜぃ。という実装をしたので、それがデファクトです。
これは歴史があるので、もう守ってない人を見たことがないぐらい強いデファクト。

EUC-JPでは「あ」「い」「う」はそれぞれ

文字    バイト列
------------------
あ A4 A2
い A4 A4
う A4 A6


というバイト列で表される。それを%でエスケープしているだけ。


次は、XML日本語プロファイルで文字化けする文字として、注意を喚起されている記号シリーズ

ASCII で注意喚起されている文字

書き込み文字列     \~
-------------------------
IE %5C%7E
Firefox %5C%7E
Opera %5C%7E


特に問題なし。


次、JIS X 208の記号で注意喚起されている文字

書き込み文字列      ̄―~∥-¢£¥¬~ 
----------------------------------------------------------------------------------
IE %A1%B1%A1%BD%A1%C1%A1%C2%A1%DD%A1%F1%A1%F2%A1%EF%A2%CC%A1%C1%FC%FC
Firefox %A1%B1%A1%BD%A1%C1%A1%C2%A1%DD%A1%F1%A1%F2%A1%EF%A2%CC%A1%C1%FC%FC
Opera %A1%B1%A1%BD%A1%C1%A1%C2%A1%DD%A1%F1%A1%F2%A1%EF%A2%CC%A1%C1%FC%FC


こちらも問題なし。



次からはWindowsの機種依存文字シリーズで攻めてみましょう

まずNEC特殊文字、①とか

書き込み文字列         ①
-----------------------------------------------
IE %AD%A1
Firefox %AD%A1
Opera %AD%A1


すべて同じ。
本当はEUCに無い文字なので、数値文字参照にしないとうまく表示できない可能性がある文字なのだが
全ブラウザ生EUCで送っている。
なお、この独自拡張EUCをMicrosoftはCP51932と呼んでいるので、詳しい仕様はググって頂きたい。

※ ここはすべて同じだから幸せとはまったくいえない状況なので別に詳しく説明する。


次、IBM拡張文字とNEC選定IBM拡張文字

書き込み文字列         髙(はしご高)
-----------------------------------------------
IE %FC%E2
Firefox %FC%E2
Opera %FC%E2


こちらも全ブラウザ生EUCとして(生CP51932として、というべき?)送出している。

この文字はIMEパッドを使わないと入力できないが、NEC選定IBM拡張文字の(SJISで0x7C62)でも
IBM拡張文字の髙(SJISで0xFBFC)でも、NEC選定IBM拡張文字の(SJISで0x7C62, EUCで0xFCE2)に変換されてしまった。
まあ、IBM拡張文字はEUCでエンコード不可能なのでNEC選定に変換するか数値文字参照に変換するかの実質二択なのだけれども。

さあ、これにてWindows機種依存文字オシマイ。



次、JIS X 201カタカナ(半角カタカナ)

書き込み文字列   アイウエオ
----------------------------------------------
IE %8E%B1%8E%B2%8E%B3%8E%B4%8E%B5
Firefox %8E%B1%8E%B2%8E%B3%8E%B4%8E%B5
Opera %8E%B1%8E%B2%8E%B3%8E%B4%8E%B5


すべて同じ.

ここで、ちょっと面白い現象がおこった。
ブラウザはたしかに半角カタカナでアイウエオとPOSTしているのに、掲示板には全角でアイウエオと書かれるのだ。
どうもはてながサーバー側で変換しているっぽい。

これはあまり嬉しくない仕様ですね。
はてなさん、全角カタカナではなく数字文字参照への変換をオススメします。



次、JIS X 212 漢字(補助漢字)

これは説明が必要だろう。
私の使っているWindows XP ではデフォルトの状態では補助漢字は入力できない。
しかしながら、MS IMEのプロパティで「辞書/学習」タブを開き、単漢字辞書のチェックボックスをONにすることで入力が可能になる。

これ、僕みたいに古いユーザーは習慣でONにしているから、知り合いに鷗外(森鴎外の難しいほうの漢字)が入力できない。とか相談されると
「あれ~、うちでは出来るで~」などと素っ頓狂な対応をしてしまうクセモノである。

書き込み文字列    鷗(鴎外の難しいほうの漢字)
-----------------------------------------------
IE %26%2340407%3B
Firefox %8F%EC%BF
Opera %26%2340407%3B


おお!
やっと差異が現れました。バイト列の意味は

文字         EUCバイト列         Unicodeコードポイント
---------------------------------------------------
鷗 %8F%EC%BF U+9DD7(10進だと40407)
& %26
# %23
; %3B


です。
つまりFirefoxは素直に補助漢字として送り出しているが、IEとOperaは &#number; という
HTMLの数値文字参照で送り出していることが分かる。

このサポートしていない文字はHTMLの文字参照に変換してしまう。という実装。
いつごろから出てきたのかどうも記憶がはっきりしない(だれか教えて)が、ひどくスジの悪い実装である。

人間が手で「鷗」 と入力しても「鷗」と入力したのにブラウザが勝手に変換したのでもまったく同じバイト列に変換されてしまって受け取り側で判別不可能であるからだ。
これによって、HTMLのPOST文字列は構造を持たないプレーンテキストだよん。という理念が失われてしまっていると思う。

とはいえ、現在のWebをみるとそもそもPOSTするのは、Web掲示板とBlogが圧倒的なわけで、
現状をよく見ている。ともいえる。

さて、この送出方法の違いがユーザーにどういう影響を与えるだろうか?

・数値文字参照はすべてのブラウザが理解できる
・補助漢字はWindows APIではサポートされない

の2つのルールから
IEで書いたコメントはIEでもFirefoxでもきちんと見られるが、Firefoxで書いたコメントはFirefoxでしか見れないという結論が導かれる。

うーん、だめですねー。フォックス君
いくら補助漢字がEUCの規格的にOKと言っても、相手が理解できない形式で通信を送らないのは相互運用性(Interoperability)の基本ですよ。


次、EUCでは絶対表現できない文字列(ハングル)
これは、「もしかしてFirefoxってPOST時に勝手に数値文字参照に変換」することをまったくサポートしていないブラウザなん?
と疑問に思ったから。
脱線気味だけど、ゆるして

なおハングルを日本語版Windows標準のIMEで入力することは出来ないが、韓国のサイトなどを表示させて、そこからカット&ペーストで文字列コピーしてくることは出来る。
ブラウザが内部Unicodeで動いているおかげである。

書き込み文字列   한글(ハングルって意味だ)
-----------------------------------------------
IE %26%2354620%3B%26%2344544%3B
Firefox %26%2354620%3B%26%2344544%3B
Opera %26%2354620%3B%26%2344544%3B


すべて同じ。
ちなみに、

文字       Unicodeコードポイント
---------------------------------------------------
한 U+D55C(10進で54620)
글 U+AE00(10進で44544)



ね。
ここから、なかなか楽しい結論が導き出される。

現在のBlog環境では、Unicodeがサポートしているありとあらゆる文字が入力・表示できるが、JIS X 212(補助漢字)の範囲だけはFirefoxで入力すると文字化けする。
なお、補助漢字というと漢字だけのようなイメージがあるが、実際にはフランス語のéなどのアクセント付きアルファベットが収録されているのでヨーロッパ系の文字はほぼ全滅(ギリシャ・ロシアはJIS X 208収録なのでセーフ)


・・・・・ダメじゃん( ̄ー ̄)y━・~~~



と、ゆーわけで


ブログ界の文字化けは、あまり単純ではない。
それを何とかする為に我々はプロジェクト「セーブ・ザ・鷗外」を立ち上げることを、ここに宣言する。

活動内容は以下の通り
・文字化け状況の確認。ブラウザが何を送っていてサーバー側でどう変換しているのか
・ブラウザのバグを回避するためのツールなどをユーザーに提供
・ブログ運営会社(はてななど)に文字化けを防ぐためのライブラリやその適切な使い方をコンサル(勝手にw


本家レガシーエンコーディングプロジェクトがオープンソースのソフトがレガシーエンコーディングをまったくサポートしてない事が多い状況をなんとかしよう。というプロジェクトなのに対して、こちらはそれが解決した上でどう使っていったらみんなが幸せになれるかを追求していくプロジェクトです。

なお、参加者はいつでも大募集中です。よろしく!



なお、以下のエントリには多大な影響をうけたので感謝の意を表明したい

未来のいつかの日記: ①(まるいち)という文字
未来のいつかの日記: 文字コードヲタク
numa's diary: 補助漢字
浅倉卓司@blog風味?: はてなもそろそろEncode::EUCJPMSを使ってくれないかなあ
もじのなまえ: Unicodeはなんの役に立つのか?


P.S.
プロジェクト名はもちろん「セーブ・ジ・アース」のパクリなんだけど
こんな↓
森鴎外
いかついオッサンが「たすけてー」と泣いている様は想像するだに楽しいのでこうしてみた。
これが「セーブ・ザ・まるいち」ではこうはいかない(ある意味シュールで楽しいかも)



文字コード | 【2006-05-28(Sun) 16:17:15】 | Trackback:(3) | Comments:(0)

レガシーエンコーディングなオフ会 このエントリーをはてなブックマークに追加

今日、ミラクルリナックスの吉岡さん主催の
「文字コードヲタクで集まってピザとビールを楽しむ会」に参加してきた。
(うそ、本当はレガシーエンコーディング変換機能の開発オフラインミーティング

ちょっと(だいぶ)遅刻してしまいご迷惑をおかけしてしまったのだが、
いやー、ヲタク同士の極めて濃ゆい会話を堪能させていただいた。
普段リアルで顔を会わせる面子で文字コードで盛り上がるなんて不可能だから
こういう集まりは素直にうれしい。


さて、あの場で酒の勢いでいろいろと放言してしまったのだが、
たぶん、今日の酒の量だとほとんどの人は明日には忘れ去られていると思うので
改めてこのブログで意思表明をしたい。


・ISO2022-JP-MSは撤回してほしい、世の中で求められているのは
Outlook Expressが送ってくる拡張ISO2022-JPを受信できることであって
それ以外のエンコーディングは必要ない。
スジがいいとか悪いとかは関係ない。CP5022xでいいじゃん。
現実重視!
・英語ホームページを作って欲しい。アメリカ人の
「なぜUnicode.orgに登録されているマッピングテーブルではダメなの?」
という疑問に答えることはコミュニティに受け入れられる上で極めて重要。
(あってるかどうか自分では確認できないコードをacceptしろと言われるメンテナ
の気持ちを考えよう。そら嫌がるよ)
また、ドキュメントがなければ結局新規ソフトはどんどん森山さん実装と
非互換の実装をしていくので事態はどんどん悪化していく。
・今回開発したレガシーにやさしい変換方式は、
Unicode.orgに登録されているマッピングテーブルと同じファイル形式でも
公開してほしい。
世の中のソフト会社のi18n対応ってのは極めて冷遇されていて、1流の技術者は
コア部分の開発、2流の技術者がnlsサポートみたいなアサインは珍しくない。
するとどうなるかというと、現状、Unicode.orgのマッピングテーブルからコードを
自動生成して対応する。みたいな話は腐るほどある
(特に僕が以前いた組み込みの世界のミドルウェアでは)
だから、ファイルフォーマットに不備があろうがなかろうが、Unicode.orgの
形式重要。ある種のデファクトだから。
・日本の技術者にも、なんでこんなにマッピングがいるのか理解していない技術者は
腐るほどいる。
だから、レガシーエンコーディングWikiに、これこれこういう状況ではxxという
ソフトがこういう送り方をしてくるから受信側でこの変換方式をしていしないと
非互換になって困ってしまうんだ、的な使い方の情報必要。
これがないとマッピングテーブルが増えた分だけ混乱して、
間違った使い方をする人が必ず出てきて非互換がより悪化する
・これはコミュニティの働きかけの問題になってしまうが、
現在の、Windows互換にしようと思ったら、
xxというソフトではCP932と指定する必要があり、
yyというソフトではSJIS-msと指定する必要があり
zzというソフトではMS932と指定する必要があり
また、別のソフトではCP943Cと指定する必要があり、
かつそれをやってもxという文字とyという文字は変換ルールが違うので
文字化け。という状況は無くさなければならないという強い意志をもって欲しい。
(現状、バッドノウハウの塊)
私はWindows31Jと指定したときにソフト・言語によらずマッピングルールが一意に
定まる世界を望む。
そうでなければ、相互運用など出来ない。名前重要!
同じものに同じ名前が付くように働きかけをして欲しい。
・今回進めているレガシーエンコーディングプロジェクトを知らない人はまだ
いっぱいいる。
(てゆーか、僕は知らなかったっす(><;)
もっと宣伝、宣伝。


無論、僕も出来る範囲でお手伝いさせていただきますゆえ・・・


ところで、僕はeucJP-msとCP50932がなぜ両方必要なのかをまだ理解できてません。
だれか教えてくださませ。
お願い


P.S. 芝野いいんちょーと初めて議論させていただきました。やっぱいいんちょーは違うぜ




委員長! ランキング!


文字コード | 【2006-05-18(Thu) 00:35:06】 | Trackback:(5) | Comments:(4)

それは典型的な波ダッシュ問題ではあるまいか このエントリーをはてなブックマークに追加

えー、どうも詳しい人同士で議論して初心者置いてきぼりモードに突入しているようなので、ここでおせっかいにも初心者向け解説を入れてみる

404 blog not foundの「Encode - 規格のバグまでは直せません 」より

b:note: Encodeのナゾ
最近会う機会が無いので、トラックバックします。

$moji = "~";
Encode::from_to($moji, "euc-jp", "utf8");
print $moji;

で出てきた文字をWindowsのメモ帳とか秀丸でみると、~の波形が反対になった文字になってしまいます。

ここでいう「~」はU+FF5E、Fullwidth Tildeのことです。



その答えは、「Unicode Consortiumが用意したJISX0212とUnicodeの変換表がそうだったから」ということになります。Encodeのせいではないのです。




まず、用語をはっきりさせよう。
今、Windowsマシンで普通に打てる全角波線(~)はJIS X 208(いわゆる第一、第ニ水準)に含まれる波ダッシュ(WAVE DASH)という文字です。

つまり、我々が普段使っている日本語Windowsマシンで全角のチルダや半角の波線は存在しない(事になっている)
でも、まあカタチが似てるからみんなごった煮で使うんだけど。

で、JIS X 212、いわゆる補助漢字の規格で全角のチルダ(Full Width Tilda)が追加されてます。

んで、下の表はwikipediaのチルダの項から拝借してきたのだけどMS WindowsのフォントだとWAVE DASHはチルダとは波が逆になっている。

(なぜかこの下にどえらい余白が出来ているが直せない。ごめん)

















記号Unicode実体参照名称
U+FF5E~
~
fullwidth tilde
U+301C〜
〜
wave dash


ま、波打ってる線には違いないから文句をいわれる筋合いはありませんな。

wikipediaの波ダッシュの項を見ると規格で逆向きが正しいんだ~みたいな事が書いてあるので調べてみると

Unicode 3.0(ごめん最新版は持ってないの)の例示字体は確かに逆。
でもJIS X 221:1995(UnicodeのISO規格がISO10646でJIS X 221はその翻訳)ではチルダと同じ向きになっている。
JIS X 221はこの件に限らずUnicode Specificatonと細かなところが色々違うので油断できない。
はっはっは(笑い事じゃないんだけど)


で、話を戻すと、WindowsのフォントはUnicode式に逆向き表示。
なぜ、この逆向きっぷりが普段だれにも気づかれないかというと、Windows APIを使う限りにおいて、なぜか

JIS X 208 WAVE DASH ←→ Unicode Full Width Tilda

という変換がされてるんですな。
ま、Unicode Specificationの表見ながら文字の意味とか考えずに、グリフが近いやつを選ぶとこうなりそうだ。

マイクロソフトがUnicode実装したときはまだ変換表とか公開されてないからUnicodeコンソーシアムの変換表とはこれに限らずいろいろと違う動きをする。
はっはっは(笑い事じゃないってば)


さて、ここまで説明すると何が起こっているのかもうわかっていただけたと思う。
EncodeはJIS X 208 WAVE DASHをUnicode WAVE DASHに変換する。Windowsではそれはチルダとは逆向きの波線に見えるが、Xで表示させるとチルダと同じ向きの波線に見える。
波線がタテマエである以上、どっちも間違ってないのだ。
コレデイイノダ!


・・・ってDANさん。元々の話はJIS X 212(補助漢字)のFull Width Tildaとは全然違う話をしているように見えますが?

結論も僕はちょっと違うと思っていて、Windows以外でもEncode::EUCJPMSを使っておけばどんなフォントでもチルダ形の形に見えてよくありまsん?
Yen problemと違って全角文字はプログラム言語等で特別な意味を持っていないので見た目優先でええんとちゃうかなー



P.S.
この原稿の初期バージョンではUnicode Specificatonの最新を持ってないのを規格書を個人で持ってるなんて変態だ。と書いていただが、よく考えたらUnicode3.0、JIS X 208、JIS X 212、JIS X 221とオウチにそろってる時点で自爆以外の何者でもないので、謹んで削除させていただいた。
はっはっは


予期せぬエラーのありすぎです
Unicodeは! 規格も実装も間違っているので! 大変なんだ! ランキング!



文字コード | 【2006-05-10(Wed) 18:35:54】 | Trackback:(1) | Comments:(14)
前のページ
  1. 無料アクセス解析
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。