プロフィール

kosaki

Author:kosaki
連絡先はコチラ

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

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

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


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

2006年のビッグマック指数によると80.6円/$が適切らしい このエントリーをはてなブックマークに追加

ニュースソース: H-Yamaguchi.net: 2006年のビッグマック指数

こういう真面目なネタ記事(あれ?)はマジおもしろい


関連記事
スポンサーサイト
ねた | 【2006-05-31(Wed) 15:09:31】 | Trackback:(0) | Comments:(2)

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)

FC2全体がAdsense八分中だそうな このエントリーをはてなブックマークに追加

なんか、Adsenseが表示されないと思ったら、FC2全体がAdsense八分中らしい。

以前紹介した、URLからAdsenseが認識しているページテーマを抽出してくれるページ でチェックしても、反応ナシ。

まいったね。

5/31追記
どうやら復活したらしいですね。おめでとう(σ・∀・)σ


関連記事
blog | 【2006-05-28(Sun) 22:20:33】 | Trackback:(0) | Comments:(2)

汎用と凡庸の違い このエントリーをはてなブックマークに追加

605 名前:602[sage] 投稿日:03/02/21 23:46 ID:fSdOLeRm 
>>604
え?
汎用=広く一般的なこと
凡庸=特に秀でた面が無いこと=一般的
なんか違うの?


607 名前:ガンオタ[sage] 投稿日:03/02/21 23:51 ID:0FxGpTz1
汎用モビルスーツというとガンダムだが
凡庸モビルスーツだとジムになってしまうね




関連記事
ねた | 【2006-05-28(Sun) 17:45:34】 | Trackback:(0) | Comments:(2)

いきなりですが改名します このエントリーをはてなブックマークに追加

「セーブ・ザ・鷗外」プロジェクトは
セーブ・ザ・オウガィ」プロジェクトに改名されました

・・・だって、http://blog.livedoor.jp/dankogai/archives/50480727.htmlのトラックバッグが文字化けしてるんだもの(n'ω'`)






オーガ
オーガも感動! ランキング!


関連記事
文字コード | 【2006-05-28(Sun) 17:02:00】 | Trackback:(1) | Comments:(5)

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

最近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)

イタリア人すげーーー このエントリーをはてなブックマークに追加

最近、トラックバック記事で知ったイタリア人の真実の口の恐るべき使いかた


真実の口

「真実の口」

偽りの心がある者は手が抜けなくなるという伝説があります。









真実の口の使い方

    Σ(゚Д゚;ナニーッ!


負けた。負けたよ。
すごいよイタリア人。


関連記事
ねた | 【2006-05-26(Fri) 19:19:12】 | Trackback:(0) | Comments:(6)

難航するVistaの国内デジタル放送対応 このエントリーをはてなブックマークに追加

PC Watchの難航するVistaの国内デジタル放送対応という記事によるとWindows Media Centerの日本対応が難航しているらしい。

これを見て僕は「ああ、やっぱり」と思ってしまった。


ARIBの運用規定とはどういうものなのだろう。ある機器ベンダのエンジニアは運用規定について「憲法のようなもの」と指摘する。運用規定で規定されているのは、こういったルールで運用しましょう、こういうことにはなっちゃダメよ、ということであって、実際にどのようなスペックのものを採用したらよいかという具体的な仕様が多く規定されているわけではないという。例えば、コピーワンスの運用の場合、同じものが何秒以上同時に存在してはいけない、などの“ルール”は規定されているが、それをどのようにして実現するかはメーカー側の“解釈”に任されているのだ。



まず、Microsoftのプレゼンで No formal certification と批判されている部分であるが、これはある意味正しい。
日本のTVは認可事業じゃないので、TVの販売にお国の認可はいらない。
(たしかアメリカはFCCの認可がいるはずなので、この点は日米で異なる)

ARIBはformal standard を配布する場所であって、formal certificationを行う場所でも
違反業者を取り締まる場所でもない。
(JISが犯罪者を取り締まる機関じゃないのと一緒)

また上記記事のルールと解釈の説明はちょいと語弊があって、上記記事で指摘されている”解釈”の話は
世の中の規格といわれているものは全部そうであって、ARIB特有の話ではまったくない。
HTMLの規格書を読んでもブラウザの内部実装はまったく書いてないし、MPEG2の規格書を読んでも
Decoderはこう動くよん。というのだけが定義されてあって、それに合うようにEncodeしろ。
という定義である。
あたりまえである。なんでわざわざ実装など説明しないといけないのだ。



じゃあ、何が問題とされているかというとARIBの規格書・運用規定の日本語がとにかく難解なのだ。
特に運用規定はひどい。

なぜ酷い文章になるかというと理由はいくつかあるのだが、そもそも形式言語でフォーマルに定義できるものは
運用じゃなくて規格の方に入っちゃってるよねー。ふつう。って話もあるが書いている人間が文章書きのプロじゃないことが挙げられると思う。
そもそもARIBは極めて貧乏な組織で
(あたりまえだ。ARIBの規格書を買う人間が、どれだけいるというのだ)
ARIBが発行している規格書・運用規定はテレビ局やメーカーから手弁当で集まった委員会で書いている、
そうした分科会でテレビ局の人間とメーカーの実装が分かる人間が集まって相互運用性の問題を
話し合って、これを文章に落としていくのだけれどMPEG2 Systemをまったく知らない局の人間と
実装を知りすぎちゃってるメーカーの人間で実装中立なドキュメントを起こすのはひどく難しいのだ。

結果、どこでもちゃんと定義されていない用語がバンバン出てくる規格書としてはちょっと困ったちゃんな
不思議ドキュメントが出来上がってくる。
中にはここはチラシの裏じゃないと小一時間(ry という文章もあるにはあるが、困ったことに
主だったメーカは分科会に出席していて行間の意図を読めるのであまり破綻していない。
していないから、運用規定のバージョンアップ時にも改善されない。という悪循環がある。

これがアメリカだと、局と懇意にしているメーカーがデファクトになって、それ以外のメーカーは
アンドキュメントなまま、デファクトの動作を解析して、同じになるようにしないといけないから、
どちらがいいかは微妙なところだが・・・・


じゃあ、どうすればいいのかと考えてみたのだが、これが思いのほか難しい。
メーカーにとって現状先行者利益があるから、課長クラスの高給取りを手弁当で
送り込んでいるのであって、認証団体をつくるからメーカーは金をだせ。といわれても
そんなメーカーに利益のまったくない話に交渉の余地は0だろう。

じゃあ、手弁当モードをやめればいいかというと、そもそもの人材不足の問題からは
右斜めにずれた方向に話がいっている気がするし、ARIBのどこにそんなお金があるの?
って気がする。
多分、役人の無駄遣いが批判されまくっている昨今の日本の現状だと政府からARIBにガンガンお金を出すってのも通りにくい。

日本はテレビ局もメーカーも複数あるから相互運用性が難しくなるのでもっと淘汰されれば話が簡単になるにはなるんだろうが、テレビ局が減ったら僕らユーザの利益を確実に害するよね(n'ω'`)

いったいどうしたらいいのかしら?
ちょっと考えさせられる記事である。


関連記事
ビジネスとマーケティング | 【2006-05-26(Fri) 18:41:56】 | Trackback:(2) | Comments:(4)

カーネル読書会 このエントリーをはてなブックマークに追加

カーネル読書会デビューすることにしました。
6/9 あたりにaltanativeマクロの話をする予定

#うちのIMEは毎回、「カー寝る」と変換する。なぜ??

関連記事
linux | 【2006-05-26(Fri) 08:32:32】 | Trackback:(3) | Comments:(10)

FC2でカテゴリ別RSS このエントリーをはてなブックマークに追加

はてなRINGとかに参加するときに、あるカテゴリだけの新着情報RSSが欲しいときがある。

こういったニッチなニーズにもFC2は対応していて

http://mkosaki.blog46.fc2.com/?xml&category=5

のように、RSSのURLの後ろに &カテゴリーナンバーをつければいい。
自分のカテゴリーナンバーはカテゴリープラグイン(普通画面左にカテゴリーというリンク集があるはず)を使うか

管理ページから
カテゴリー編集
RSSの文字をクリック

で得られる。

以上、ちょいねたでした

関連記事
blog | 【2006-05-25(Thu) 08:52:18】 | Trackback:(0) | Comments:(2)

[書評] いばらの王(全6巻) このエントリーをはてなブックマークに追加



いばらの王


古城脱出劇なホラーもの。
序盤の盛り上げ方は、すばらしい。
しかしラスト付近はご都合が増えてしまって残念な所。

ややネタバレになってしまうが、この話には双子トリックが使われているのだが、個人的には自分が双子なこともあって「それはねーだろ!」と思ってしまった。

どうして漫画だと双子をそう何でもありに使うかね。

関連記事
書評(まんが) | 【2006-05-22(Mon) 00:40:01】 | Trackback:(0) | Comments:(8)

[書評] 失踪日記 このエントリーをはてなブックマークに追加



失踪日記


なんか、近所の本屋にいったら平積みされてた。また売れ出したらしい。
この人の漫画はコミカルなのに、回が進むと主人公(作者本人)が禿げてきたりお腹がダメ方向にスクスク成長したりして、妙に芸が細かい

一部で熱烈なファンがいる漫画である。

出てくるキチガイどもがなかなかいい味だしてると思う。

関連記事
書評(まんが) | 【2006-05-22(Mon) 00:30:02】 | Trackback:(1) | Comments:(0)

ヤンキース松井の謝罪、謝らない米国社会に衝撃 このエントリーをはてなブックマークに追加

1 :失恋パンティきのこ@ゴッドおまコンφ ★ :2006/05/18(木) 11:43:43
前回、ヤンキース松井秀喜の左手首骨折直後の地元メディアの様子をお伝えしたが、今回のアクシデントはその後全米のメディアにもう1つの衝撃を与えることとなった。
それは骨折翌日の12日、手術後に広報を通じて松井から出された声明が原因だ。
英語で出されたもので「連続試合出場に向けて、毎試合、起用してくれたことに関してはトーリ監督にとても感謝しています。申し訳ないと思うと同時に、チームメイトを落胆させたことに私も失望しています」という内容。
松井らしい誠実で、悔しさに溢れたコメントだが、これがアメリカのスポーツ・メディア関係者にはビックリするものだったのだ。
その理由は「アイ・フィール・ベリー・ソーリー」と、最上級の謝罪の言葉が使われていたためである。
アメリカのスポーツ関係者がこのようなコメントを発表する際、まずこのような“謝罪”を口にすることはない。
残念、落胆といった種類の言葉はあっても、誰かに“謝る”ということはないのである。それが麻薬やステロイドといった問題によるものであってもだ。
この“謝らない”傾向は個人主義色の強いアメリカ社会には元々強いが、スポーツ界では契約問題などビジネス面もあって特に先鋭化してしまっているのが現実である。
それ故、松井が出したこの声明はさまざまな人々に衝撃を与えることになったのだ。

http://blog.nikkansports.com/baseball/mlb/watanabe/2006/05/post_50.html#more


21 :名無しさん@恐縮です :2006/05/18(木) 11:47:09 ID:crQs9slw2
アメリカ人は謝られ馴れてないっていうのかな、ちょっとのことで謝るとすごく驚かれるよね。
おれなんかむかし桜の枝を折ったことを正直に謝ったくらいで美談とされたもん。





関連記事
ねた | 【2006-05-20(Sat) 15:58:15】 | Trackback:(0) | Comments:(4)

mtraceの使い方 このエントリーをはてなブックマークに追加

何回調べても忘れてしまうシリーズ

今回はmtraceの使い方。
mtraceというのはmallocやfreeなどのメモリ管理系の関数をHookして、メモリリークを追跡してくれる便利なライブラリ関数です。
glibc付属なので特殊なソフトのインストールが必要ないのが利点。

使い方の注意点と手は Electric Fence などのmallocを乗っ取るライブラリと共用できないこと(アタリマエだ)
malloc/freeのたびにファイルに書くので結構なオーバーヘッドを伴うこと。
スレッドセーフじゃないこと(これはmallocのhookの仕組みがタコいんです)
mtrace()関数を呼び出すとトレースを開始する。というセマンティクスなのでシェルなどからイマイチ使いづらい所も欠点と言える。



まあ、実例を見てください。


まず、こういうファイルを用意

 mtrace_on.c
----

#include <mcheck.h>

static void mtrace_start(void) __attribute__((constructor));
static void mtrace_end(void) __attribute__((destructor));

static void
mtrace_start(void)
{
mtrace();
}

static void
mtrace_end(void)
{
muntrace();
}


適当に、メモリリークしてるファイルを用意

  main.c
-----
main(){
void* a;
a = malloc(1000);
}



コンパイル&実行

$ gcc  main.c -g
$ gcc mtrace_on.c -o mtrace_on.so -shared
$ export set MALLOC_TRACE="./mtrace.log"
$ LD_PRELOAD="./mtrace_on.so" ./a.out
$ mtrace a.out mtrace.log

Memory not freed:
-----------------
Address Size Caller
0x6000000000004460 0x3e8 at /home/kosaki/projects/mtrace/main.c:3



mtraceコマンドにa.outを渡さなければCallerがアドレスで表示されるのでマクロを駆使していて行番号だけでは分からんときはそれで。

しかし、なんでいちいち自分で共有ライブラリ作らんとあかんのよ。不親切だなぁ


アンジェリーク
○○○リーク! ランキング!


関連記事
linux | 【2006-05-19(Fri) 12:25:16】 | Trackback:(0) | Comments:(3)

エンジニアのバッドノウハウ、マネージャーのベストプラクティス このエントリーをはてなブックマークに追加

みなさん、バッドノウハウという言葉は聞いたことがあるだろうか。

現在は、いやなブログさんによる、バッドノウハウの本来の定義からやや拡張されて、
uglyなソフトに人間のほうが間尺を合わせるダメな行為を指す意味で使われることが多いように思う。


しかし、これはほとんどエンジニアリング世界(だけ)で通じる言葉でマネージメントの世界でこういう言い方はまずしない。

たとえば、一部で悪名高い、「動いているコードは触るな」メソッドを考えよう。
これはエンジニアから見たら極めて悪辣かつバッドな行為だ。コードを理解せずに対処療法的に問題が出た部分だけを修正してしまうわけだから。
こういうのが積み重なると、こっちを直せばあっちが飛び出し、あっちを直せばこっちが火を噴く。というシステムが簡単に出来上がる。

で、これが何年も前から言われているのに全然なくならない。無くならないどころか減っていく気配すら見えないのは、マネージャーにとって、これは全然「バッド」なノウハウじゃないからだと思う。
マネージャーの仕事ってのは極論すれば「出来るエンジニアがいてもいなくても結果を出す。出せるように手配をする」のが仕事である。たまたま部下にいいエンジニアがいる時にだけ成功するプロジェクト運営方針ってのは明らかに間違ってる。

とするとエンジニアに「ちゃんと理解して修正しろ」と指示するのは間違っているわけだ。ダメエンジニアは理解したつもりで余計トンデモないコードを仕込んでデグレード障害を起こすから。

マネージメントの世界ではこういう教科書的にはちょっとアレゲでも経験的にうまくいく手法をとても大切にする。マネージメントの教科書には書いてないけれども経験的にうまくいく手法を、ベストプラクティスとして蓄積していくわけだ。


でも、これってこの2人の間には深い断絶があるのよね。だってマネージャーはエンジニアに
「お前がバグを入れるかもしれないから理解しろとは言えないし、分かっているから直させろといわれても信じられないんだ。」
とは言えないじゃない。

実はこういう話は一杯あって、エンジニアあがりの新米マネジャーが苦労する一因になっていると考えている。




結論としては、経験則重要、現実を見よう。って事が言いたかったんだけど、この話の流れだとちっともそういう風に見えないな。
反省


・・・・しかし、こういう話をレガシーエンコーディングの話で盛り上がった直後に思いついてしまうのはそれはそれでどうなんだ。




関連記事
ビジネスとマーケティング | 【2006-05-19(Fri) 11:01:05】 | Trackback:(1) | Comments:(0)

ワシントン少年の逸話 このエントリーをはてなブックマークに追加


ワシントン少年の逸話
297 :おさかなくわえた名無しさん :2006/04/05(水) 14:46:12 ID:2x6vw2rM

        _______________
        ||ワシントンは桜の木を切ったことを||
        ||素直に父に告白しました      ||    ∧_∧
        ||父親はワシントンを咎めず     ||    (・ω・`)
        ||許しました。何故許したのか? _||___  O□⊂)
         ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄  ̄ ̄| ̄ ̄ ̄ ̄|
  ∧ ∧                            |____|
  (  ∧ ∧
~(_(  ∧ ∧
  ~(_(   )<ワシントンがまだ斧を持っていたからだと思います!
    ~(__ _,,)





関連記事
ねた | 【2006-05-18(Thu) 19:41:18】 | Trackback:(1) | Comments:(2)

ことえりタン このエントリーをはてなブックマークに追加

404 Blog Not Found様のパンダの死体はスキャンできるか? の米より

>なんでことえりなんか使ってるんです?

ばかっ!
ことえりタンは萌えるからだよ!
名前だけで、dan氏の脳内では擬人化されてるんだよ!

WnnとかSKKとか、そんな萌えない名前のIM使えるかっ!
かんなタンはギリギリセーフ。




そんな事をまじめに言うアナタがいとおしくてたまりません。



タン
タンはいいねぇ! ランキング!




関連記事
ねた | 【2006-05-18(Thu) 18:30:26】 | Trackback:(0) | Comments:(2)

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

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

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


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


・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)

今日は何の日? このエントリーをはてなブックマークに追加

なんか「デスノート 最終回」というサーチワードでものすごいアクセス数があるんですけど、なんかあったの?

関連記事
雑談 | 【2006-05-18(Thu) 00:25:14】 | Trackback:(0) | Comments:(0)

この人はトラックバックを手で打っているのだろうか? このエントリーをはてなブックマークに追加

昨日、それは典型的な波ダッシュ問題ではあるまいか というエントリに「anime(禿)hage 」さんという人からトラックバックもらったのだけれども、クリックしても開けない。

不思議に思って、URLを見てみると

ttp://www1.viroviro.com/


なぜ、2ちゃんねる記法?!
FC2だとトラックバックの内容をこちらで編集できないから直しようがない。
しかし、こんなURLを生成するツールがあるのだろうか?

それともこの人はトラックバックPINGを秀丸とかで書いて送ってくる猛者なのだろうか?

謎は深まるばかりである。


トラック
トラックバック! ランキング!



関連記事
blog | 【2006-05-17(Wed) 08:58:03】 | Trackback:(0) | Comments:(1)

やはり仕組まれていた911 なんてどうでもいいがスペインの量刑制度は気になる このエントリーをはてなブックマークに追加

田中宇の国際ニュース解説というサイトで

やはり仕組まれていた911(1)」という記事が出ている。私としては911が仕組まれていたかはどうもでもいいが、

量刑は検察側の主張(7万4千年の勾留)よりも軽い27年の勾留となった




この記述は気になりすぎる。
量刑7万4千年ってどんなんだよ。


関連記事
雑談 | 【2006-05-16(Tue) 18:41:51】 | Trackback:(0) | Comments:(0)

デスノート最終回 このエントリーをはてなブックマークに追加

どうみても打ち切りです。本当にありが(ry

関連記事
雑談 | 【2006-05-15(Mon) 17:27:31】 | Trackback:(0) | Comments:(5)

[書評] Write Great Code このエントリーをはてなブックマークに追加

いやなブログさんが薦めていたのと、ごとむさんが監修したので、読んでみた。

ソフトウェア屋さんむけの、平易なハードウェア入門って感じの本。正直OSとかいじってる人にはレベルが低すぎると思うけど、

大学生とか、新人さん(とくに組み込み技術者の新人さん)にはぜひとも読んでもらいたい本である。



Write Great Code〈Vol.1〉ハードウェアを知り、ソフトウェアを書く



関連記事
書評 | 【2006-05-15(Mon) 13:39:55】 | Trackback:(0) | Comments:(2)

IA64のレジスタのルール このエントリーをはてなブックマークに追加

自分用備忘録

r1:     グローバルポインタ
r8: 戻り値
r9-r11: 戻り値(でもあんまり使わない)
r12: スタック
r13: スレッド・ローカル・ストレージ(tls)用

br0: 戻りアドレス





関連記事
linux | 【2006-05-15(Mon) 10:24:25】 | Trackback:(0) | Comments:(0)

[書評] さおだけ屋はなぜ潰れないのか このエントリーをはてなブックマークに追加

しばらく前に会社の上司が薦めていたので読んでみた。

筆者の意図としては会計学の入門書なのだろうが、ちょっと入門編過ぎて物足りなかった。
でも、さおだけ屋の正体が分かっただけでも、読む価値はある。



さおだけ屋はなぜ潰れないのか






関連記事
書評 | 【2006-05-15(Mon) 00:18:11】 | Trackback:(0) | Comments:(0)

はてなブックマークの顔アイコン このエントリーをはてなブックマークに追加

はてなブックマークの顔アイコンはどうやって変えるのだろうか?
だれか教えて

関連記事
雑談 | 【2006-05-14(Sun) 17:38:14】 | Trackback:(1) | Comments:(2)

ヒーローウォーズ このエントリーをはてなブックマークに追加

鮎方さんから譲ってもらったヒーローウォーズが、今日届いた。
思ったより大きかったので何かと思いましたよ。


↓ 表紙

ヒーローウォーズ表紙



↓ 中表紙(グレッグのサイン入りww)

グレッグのサイン









なんというか・・・・同人誌?
って感じのステキ完成度。

いや違うな。完成度は高いんだ。
ただ、そこかしこから無性にただよう、分かってる人以外オコトワリな雰囲気。

あー、これは実際にゲームするのは難しいといわれるよね(n'ω'`)


ところで、最初の世界観の説明で3界が衝突して云々ってあたりで、なるしまゆりのプラネットラダーを思い出したのは内緒だだだだ。

きっと、ヒーロークエストで三界の衝突を回避することにより世界の破滅を防ごうとする邪悪な皇帝とか出てくるに違いない(マテ







関連記事
雑談 | 【2006-05-12(Fri) 21:54:30】 | Trackback:(0) | Comments:(0)

中国語がいやになるほど難しい件について このエントリーをはてなブックマークに追加

最近、仕事で中国人と付き合うことが多いのだが、やはり中国人と付き合うのは難しい。

中国語も僕には非常に難しく全然覚わらない。
C言語よりもよほど難しいぞ。



ちなみに、中国語を難しいと思っているのは僕だけではないらしく、

中国語への翻訳が難しい日本語-中国語の翻訳事情 というページでも

よく中国の人と話していると突然何の話題なのかわから時がある。
それは、大体、日本に関する話題の時。彼らは皆、何で日本人なのにしらないのか??と馬鹿にしてくるのだ。例えば、下記の単語
拉奥
托奇
賈基
希恩
これはある有名なテレビの登場人物たちらしい..


拉奥:ラオウ
托奇:トキ
賈基:ジャギ
希恩:シン



と中国語の難しさを伝えている。


白きのこ
そんなの分からないもん! ランキング!



関連記事
雑談 | 【2006-05-12(Fri) 10:07:41】 | Trackback:(0) | Comments:(2)

ひとくちドーナツ このエントリーをはてなブックマークに追加

さいきん、セブンイレブンで売ってるひとくちドーナツがマイヒットである。
携帯で写真に撮ってみたけど全然おいしそうに見えないorz

なじぇー


ひとくちドーナツ



関連記事
雑談 | 【2006-05-11(Thu) 17:36:59】 | Trackback:(0) | Comments:(2)

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

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

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&#65374;
&#xFF5E;
fullwidth tilde
U+301C&#12316;
&#x301C;
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ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。