前回の記事について、説明が不足していたようで、404 Blog Not Found様からmultipart/form-data を忘れている
とお叱りを頂いてしまいました。
えっと、誤解です。
multipart/form-dataを使っても状況はまったく変わらないことが分かったので説明を省略しただけです。
誤解をとくために前回の調査結果を簡単にまとめさせてください。
という結論が得られた。
つまり、％エスケープをほどいた後の話なので％エスケープをしない multipart/form-data でも状況はまったく変わらないのです。
さて、この件、世間様の反応をちょいと調べてみるとBlog界では結構大きな問題になっていることが分かる。
たとえば、はてなアイデアで「文字化け」で登録されているバグのうち、すくなくとも
以上のトラブルは、このFirefoxのUglyな仕様に起因している。
じゃあ、もじらな人々がどういった反応をしているかというと
Bugzilla-jp: bug4873 EUC-JPエンコーダは補助漢字を変換すべきではない において
とmixiが悪いという見解。
私、ぜんぜん知らなかったんですけれども多くのWebアプリケーションは&を
& に置換しているはず。という主張。
ソースが示されていないので、じゃあなぜ数値文字参照を送っているIEは困っていないのかが
分かりませんでした。
（IEを無視しているWebアプリケーションってあるのかしらん）
その後、この発言が WONT-FIX への流れを決めてしまったように見えるが、この発言で数値文字参照を出力することにより困難が生じるコミュニティやソフトウェアの名前は一切明らかになっていないように思える。
ハングルとかが数値文字参照で送られてくるのは処理できるのに、補助漢字が数値文字参照で送られてくると発狂するソフトウェアって逆に難しいと思う・・・・
さらに調査を続けると、Mozillaで数値文字参照で送出する仕様が実装されたのは比較的最近であることが分かった。
すくなくとも、MozillaのEUCの実装よりかはだいぶ後。
Bugzilla bug-117422 トルコ語が文字化けするぞ。というバグ
が 2001-12-30 04:12 PDT にOpenされ、そこで、
コメント１９ において
この問題は標準がなく、IEもNetscapeも独自拡張だが、IEの方法のほうがスジがいいので
そちらに挙動を変えよう。
という発言が通って 2002-03-01 12:46 PDT に check-in および verifyが完了している。
本当はこの時にEUC-JPも直せばGoodだったんだけど、まあトルコ語問題で始まったバグをいちいちウォッチしてられないというのも想像に難くないので、ある意味仕方ないのかな。
さて、時は進んで2006年今現在、いまさらEUC-JPのエンコーディング方法を変えるのはどうなのだろう、という議論は識者と一度してみたい。
僕は変えたほうがいいと思っているのだけれど。
僕の知っている範囲で列挙すると論点は以下
この件に関しては、はてなの中の人とかもじらの中の人とかレガシーエンコーディングプロジェクトの識者の面々とかと今後議論していきたい。あんまりツテがないので大変だけど ;-<
で、ここで終わるとユーザにとって前向きな記事にならないので、もうちょっと対処療法織り交ぜ柔軟に考えてみる。
たぶん、ユーザが幸せになるには以下の方法のどれかを実行すれば言いと思う（排他条件じゃないので注意）
４以外は僕でも出来そうな気がするので（５はパッチが受け入れるか極めて怪しいけど）、意見がある人は○○キボンヌ とかだけでもコメント残して言ってくれるとうれしい。
追記：
５を望む人はここじゃなく、Bugzillaで意思表明をしてもらったほうがいいかな。ここで意思表明してもチラシの裏なので
初稿では僕の書き方が悪かったです。ごめん
では！
とお叱りを頂いてしまいました。
えっと、誤解です。
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され、そこで、
コメント１９ において
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補助漢字の
どちらが幸せなのか。
この件に関しては、はてなの中の人とかもじらの中の人とかレガシーエンコーディングプロジェクトの識者の面々とかと今後議論していきたい。あんまりツテがないので大変だけど ;-<
で、ここで終わるとユーザにとって前向きな記事にならないので、もうちょっと対処療法織り交ぜ柔軟に考えてみる。
たぶん、ユーザが幸せになるには以下の方法のどれかを実行すれば言いと思う（排他条件じゃないので注意）
１．GreacemonkeyスクリプトをつくってサーバーにPOSTする前に
数値文字参照に変換
ユーザがわざわざインストールしないといけないのが欠点だが、
たとえばフランス語が文字化けして
死ぬほど困ってる人だったら入れてくれるかも。
（Greacemonkeyって何？ってひとはこちらをどぞ
http://firefox.geckodev.org/index.php?Greasemonkey）
２．JavaScript libraryでサーバーにPOSTする前に数値文字参照に変換
１と似ているけれども、普通のJavascriptライブラリとして提供。
Blogの管理者がこのScriptを設置してくれれば
文字化けがなおるというもの。
１と違い、エンドユーザは明示的にインストールする必要がないのが長所。
はてなのようなユーザーが自分のScriptを置けないようなブログでは使えないのが欠点。
３．補助漢字to数値文字参照 perl library を提供
まあ、Blogのバックエンドはperlが多いだろうと勝手に決めうって
補助漢字を数値文字参照に変換するライブラリを
つくってブログ屋さんに組み込んでよーと宣伝していくというい方法。
ある意味正攻法。うまくいったらクライアント側で何も
対処がいらないって意味で。
でも汚い。激しく汚い。
しかもこういう日本語決めうち特殊処理はi18nなソフトでは
決して受け入れられない。
４．CP51932コンバータをFirefox独自拡張に対応
もう、CP51932を文字通りの意味じゃなくWebで流通してる
EUCという広い意味でとらえてFirefox拡張も
受け入れてしまうという案。
残念なことにFirefox EUCは仕様が公開されていない
（実装が仕様）状態なので、このコンバータが
コミュニティに受け入れられる可能性はきわめて低い。
５．Firefoxを直す
本文でも書いたけど、補助漢字を３バイトEUCで送ってくれないと
破綻するソフトって実在するの？
ってのが争点かと。
実在したらレベルダウン修正になってしまいますからね。
４以外は僕でも出来そうな気がするので（５はパッチが受け入れるか極めて怪しいけど）、意見がある人は○○キボンヌ とかだけでもコメント残して言ってくれるとうれしい。
追記：
５を望む人はここじゃなく、Bugzillaで意思表明をしてもらったほうがいいかな。ここで意思表明してもチラシの裏なので
初稿では僕の書き方が悪かったです。ごめん
では！
なんか、Adsenseが表示されないと思ったら、FC2全体がAdsense八分中らしい。
以前紹介した、URLからAdsenseが認識しているページテーマを抽出してくれるページ でチェックしても、反応ナシ。
まいったね。
5/31追記
どうやら復活したらしいですね。おめでとう(σ・∀・)σ
以前紹介した、URLからAdsenseが認識しているページテーマを抽出してくれるページ でチェックしても、反応ナシ。
まいったね。
5/31追記
どうやら復活したらしいですね。おめでとう(σ・∀・)σ
605 名前：602[sage] 投稿日：03/02/21 23:46 ID:fSdOLeRm
>>604
え？
汎用＝広く一般的なこと
凡庸＝特に秀でた面が無いこと＝一般的
なんか違うの？
607 名前：ガンオタ[sage] 投稿日：03/02/21 23:51 ID:0FxGpTz1
汎用モビルスーツというとガンダムだが
凡庸モビルスーツだとジムになってしまうね
「セーブ・ザ・鷗外」プロジェクトは
「セーブ・ザ・オウガィ」プロジェクトに改名されました
・・・だって、http://blog.livedoor.jp/dankogai/archives/50480727.htmlのトラックバッグが文字化けしてるんだもの(n'ω'`)
オーガも感動！ ランキング！
「セーブ・ザ・オウガィ」プロジェクトに改名されました
・・・だって、http://blog.livedoor.jp/dankogai/archives/50480727.htmlのトラックバッグが文字化けしてるんだもの(n'ω'`)
オーガも感動！ ランキング！
最近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)
ちなみに当サイトに訪れるユーザのブラウザの割合は以下のような感じで、
バージョン違い、亜種をまとめると
という感じでIEとFirefoxだけがちゃんと調べないといけなくて、あとは誤差って感じだ。
調べ方は単純、自分のはてなダイアリーの日記欄に色々なブラウザで同じコメント書いてみて、 etherealでパケットキャプチャー。
どのような文字コードを送出しているか調べるというものだ。（ちなみに、はてなダイアリーの文字コードはEUC-JPである）
脱線だが有名Blogの文字コードをいくつか調べたところ
という結果になったので、EUCとUTF-8さえ押さえれば、Blog界の文字化け問題の対応としてはだいたいＯＫと言えそうである。
まず、ASCII文字（アルファベット）
すべて同じ結果。
ASCIIしか使わない限りにおいて文字化けは発生しないという、非常に当たり前の結果になった。
次、JIS X 208 のひらがな
すべて同じ結果。
さすがに、この程度では文字化けしない。まあ当たり前である。
ここで、規格の復習。
HTMLの規格上、ブラウザは文字列をPOSTするのに、
で、最近ヒトサマの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界の文字化け問題の対応としてはだいたいＯＫと言えそうである。
まず、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するのに、
最近、トラックバック記事で知ったイタリア人の真実の口の恐るべき使いかた
｢真実の口｣
偽りの心がある者は手が抜けなくなるという伝説があります。
Σ(ﾟДﾟ；ナニｰｯ!
負けた。負けたよ。
すごいよイタリア人。
｢真実の口｣
偽りの心がある者は手が抜けなくなるという伝説があります。
Σ(ﾟДﾟ；ナニｰｯ!
負けた。負けたよ。
すごいよイタリア人。
PC Watchの難航するVistaの国内デジタル放送対応という記事によるとWindows Media Centerの日本対応が難航しているらしい。
これを見て僕は「ああ、やっぱり」と思ってしまった。
まず、Microsoftのプレゼンで No formal certification と批判されている部分であるが、これはある意味正しい。
日本のＴＶは認可事業じゃないので、ＴＶの販売にお国の認可はいらない。
（たしかアメリカはFCCの認可がいるはずなので、この点は日米で異なる）
ARIBはformal standard を配布する場所であって、formal certificationを行う場所でも
違反業者を取り締まる場所でもない。
（JISが犯罪者を取り締まる機関じゃないのと一緒）
また上記記事のルールと解釈の説明はちょいと語弊があって、上記記事で指摘されている”解釈”の話は
世の中の規格といわれているものは全部そうであって、ARIB特有の話ではまったくない。
HTMLの規格書を読んでもブラウザの内部実装はまったく書いてないし、MPEG2の規格書を読んでも
Decoderはこう動くよん。というのだけが定義されてあって、それに合うようにEncodeしろ。
という定義である。
あたりまえである。なんでわざわざ実装など説明しないといけないのだ。
じゃあ、何が問題とされているかというとARIBの規格書・運用規定の日本語がとにかく難解なのだ。
特に運用規定はひどい。
なぜ酷い文章になるかというと理由はいくつかあるのだが、そもそも形式言語でフォーマルに定義できるものは
運用じゃなくて規格の方に入っちゃってるよねー。ふつう。って話もあるが書いている人間が文章書きのプロじゃないことが挙げられると思う。
そもそもARIBは極めて貧乏な組織で
（あたりまえだ。ARIBの規格書を買う人間が、どれだけいるというのだ）
ARIBが発行している規格書・運用規定はテレビ局やメーカーから手弁当で集まった委員会で書いている、
そうした分科会でテレビ局の人間とメーカーの実装が分かる人間が集まって相互運用性の問題を
話し合って、これを文章に落としていくのだけれどMPEG2 Systemをまったく知らない局の人間と
実装を知りすぎちゃってるメーカーの人間で実装中立なドキュメントを起こすのはひどく難しいのだ。
結果、どこでもちゃんと定義されていない用語がバンバン出てくる規格書としてはちょっと困ったちゃんな
不思議ドキュメントが出来上がってくる。
中にはここはチラシの裏じゃないと小一時間（ｒｙ という文章もあるにはあるが、困ったことに
主だったメーカは分科会に出席していて行間の意図を読めるのであまり破綻していない。
していないから、運用規定のバージョンアップ時にも改善されない。という悪循環がある。
これがアメリカだと、局と懇意にしているメーカーがデファクトになって、それ以外のメーカーは
アンドキュメントなまま、デファクトの動作を解析して、同じになるようにしないといけないから、
どちらがいいかは微妙なところだが・・・・
じゃあ、どうすればいいのかと考えてみたのだが、これが思いのほか難しい。
メーカーにとって現状先行者利益があるから、課長クラスの高給取りを手弁当で
送り込んでいるのであって、認証団体をつくるからメーカーは金をだせ。といわれても
そんなメーカーに利益のまったくない話に交渉の余地は０だろう。
じゃあ、手弁当モードをやめればいいかというと、そもそもの人材不足の問題からは
右斜めにずれた方向に話がいっている気がするし、ARIBのどこにそんなお金があるの？
って気がする。
多分、役人の無駄遣いが批判されまくっている昨今の日本の現状だと政府からARIBにガンガンお金を出すってのも通りにくい。
日本はテレビ局もメーカーも複数あるから相互運用性が難しくなるのでもっと淘汰されれば話が簡単になるにはなるんだろうが、テレビ局が減ったら僕らユーザの利益を確実に害するよね(n'ω'`)
いったいどうしたらいいのかしら？
ちょっと考えさせられる記事である。
これを見て僕は「ああ、やっぱり」と思ってしまった。
ARIBの運用規定とはどういうものなのだろう。ある機器ベンダのエンジニアは運用規定について「憲法のようなもの」と指摘する。運用規定で規定されているのは、こういったルールで運用しましょう、こういうことにはなっちゃダメよ、ということであって、実際にどのようなスペックのものを採用したらよいかという具体的な仕様が多く規定されているわけではないという。例えば、コピーワンスの運用の場合、同じものが何秒以上同時に存在してはいけない、などの“ルール”は規定されているが、それをどのようにして実現するかはメーカー側の“解釈”に任されているのだ。
まず、Microsoftのプレゼンで No formal certification と批判されている部分であるが、これはある意味正しい。
日本のＴＶは認可事業じゃないので、ＴＶの販売にお国の認可はいらない。
（たしかアメリカはFCCの認可がいるはずなので、この点は日米で異なる）
ARIBはformal standard を配布する場所であって、formal certificationを行う場所でも
違反業者を取り締まる場所でもない。
（JISが犯罪者を取り締まる機関じゃないのと一緒）
また上記記事のルールと解釈の説明はちょいと語弊があって、上記記事で指摘されている”解釈”の話は
世の中の規格といわれているものは全部そうであって、ARIB特有の話ではまったくない。
HTMLの規格書を読んでもブラウザの内部実装はまったく書いてないし、MPEG2の規格書を読んでも
Decoderはこう動くよん。というのだけが定義されてあって、それに合うようにEncodeしろ。
という定義である。
あたりまえである。なんでわざわざ実装など説明しないといけないのだ。
じゃあ、何が問題とされているかというとARIBの規格書・運用規定の日本語がとにかく難解なのだ。
特に運用規定はひどい。
なぜ酷い文章になるかというと理由はいくつかあるのだが、そもそも形式言語でフォーマルに定義できるものは
運用じゃなくて規格の方に入っちゃってるよねー。ふつう。って話もあるが書いている人間が文章書きのプロじゃないことが挙げられると思う。
そもそもARIBは極めて貧乏な組織で
（あたりまえだ。ARIBの規格書を買う人間が、どれだけいるというのだ）
ARIBが発行している規格書・運用規定はテレビ局やメーカーから手弁当で集まった委員会で書いている、
そうした分科会でテレビ局の人間とメーカーの実装が分かる人間が集まって相互運用性の問題を
話し合って、これを文章に落としていくのだけれどMPEG2 Systemをまったく知らない局の人間と
実装を知りすぎちゃってるメーカーの人間で実装中立なドキュメントを起こすのはひどく難しいのだ。
結果、どこでもちゃんと定義されていない用語がバンバン出てくる規格書としてはちょっと困ったちゃんな
不思議ドキュメントが出来上がってくる。
中にはここはチラシの裏じゃないと小一時間（ｒｙ という文章もあるにはあるが、困ったことに
主だったメーカは分科会に出席していて行間の意図を読めるのであまり破綻していない。
していないから、運用規定のバージョンアップ時にも改善されない。という悪循環がある。
これがアメリカだと、局と懇意にしているメーカーがデファクトになって、それ以外のメーカーは
アンドキュメントなまま、デファクトの動作を解析して、同じになるようにしないといけないから、
どちらがいいかは微妙なところだが・・・・
じゃあ、どうすればいいのかと考えてみたのだが、これが思いのほか難しい。
メーカーにとって現状先行者利益があるから、課長クラスの高給取りを手弁当で
送り込んでいるのであって、認証団体をつくるからメーカーは金をだせ。といわれても
そんなメーカーに利益のまったくない話に交渉の余地は０だろう。
じゃあ、手弁当モードをやめればいいかというと、そもそもの人材不足の問題からは
右斜めにずれた方向に話がいっている気がするし、ARIBのどこにそんなお金があるの？
って気がする。
多分、役人の無駄遣いが批判されまくっている昨今の日本の現状だと政府からARIBにガンガンお金を出すってのも通りにくい。
日本はテレビ局もメーカーも複数あるから相互運用性が難しくなるのでもっと淘汰されれば話が簡単になるにはなるんだろうが、テレビ局が減ったら僕らユーザの利益を確実に害するよね(n'ω'`)
いったいどうしたらいいのかしら？
ちょっと考えさせられる記事である。
カーネル読書会デビューすることにしました。
6/9 あたりにaltanativeマクロの話をする予定
＃うちのIMEは毎回、「カー寝る」と変換する。なぜ？？
6/9 あたりにaltanativeマクロの話をする予定
＃うちのIMEは毎回、「カー寝る」と変換する。なぜ？？
はてなRINGとかに参加するときに、あるカテゴリだけの新着情報RSSが欲しいときがある。
こういったニッチなニーズにもFC2は対応していて
http://mkosaki.blog46.fc2.com/?xml&category=5
のように、RSSのURLの後ろに ＆カテゴリーナンバーをつければいい。
自分のカテゴリーナンバーはカテゴリープラグイン（普通画面左にカテゴリーというリンク集があるはず）を使うか
管理ページから
カテゴリー編集
RSSの文字をクリック
で得られる。
以上、ちょいねたでした
こういったニッチなニーズにもFC2は対応していて
http://mkosaki.blog46.fc2.com/?xml&category=5
のように、RSSのURLの後ろに ＆カテゴリーナンバーをつければいい。
自分のカテゴリーナンバーはカテゴリープラグイン（普通画面左にカテゴリーというリンク集があるはず）を使うか
管理ページから
カテゴリー編集
RSSの文字をクリック
で得られる。
以上、ちょいねたでした
いばらの王
古城脱出劇なホラーもの。
序盤の盛り上げ方は、すばらしい。
しかしラスト付近はご都合が増えてしまって残念な所。
ややネタバレになってしまうが、この話には双子トリックが使われているのだが、個人的には自分が双子なこともあって「それはねーだろ！」と思ってしまった。
どうして漫画だと双子をそう何でもありに使うかね。
失踪日記
なんか、近所の本屋にいったら平積みされてた。また売れ出したらしい。
この人の漫画はコミカルなのに、回が進むと主人公（作者本人）が禿げてきたりお腹がダメ方向にスクスク成長したりして、妙に芸が細かい
一部で熱烈なファンがいる漫画である。
出てくるキチガイどもがなかなかいい味だしてると思う。
1 ：失恋パンティきのこ＠ゴッドおまコンφ ★ ：2006/05/18(木) 11:43:43
前回、ヤンキース松井秀喜の左手首骨折直後の地元メディアの様子をお伝えしたが、今回のアクシデントはその後全米のメディアにもう１つの衝撃を与えることとなった。
それは骨折翌日の１２日、手術後に広報を通じて松井から出された声明が原因だ。
英語で出されたもので「連続試合出場に向けて、毎試合、起用してくれたことに関してはトーリ監督にとても感謝しています。申し訳ないと思うと同時に、チームメイトを落胆させたことに私も失望しています」という内容。
松井らしい誠実で、悔しさに溢れたコメントだが、これがアメリカのスポーツ・メディア関係者にはビックリするものだったのだ。
その理由は「アイ・フィール・ベリー・ソーリー」と、最上級の謝罪の言葉が使われていたためである。
アメリカのスポーツ関係者がこのようなコメントを発表する際、まずこのような“謝罪”を口にすることはない。
残念、落胆といった種類の言葉はあっても、誰かに“謝る”ということはないのである。それが麻薬やステロイドといった問題によるものであってもだ。
この“謝らない”傾向は個人主義色の強いアメリカ社会には元々強いが、スポーツ界では契約問題などビジネス面もあって特に先鋭化してしまっているのが現実である。
それ故、松井が出したこの声明はさまざまな人々に衝撃を与えることになったのだ。
http://blog.nikkansports.com/baseball/mlb/watanabe/2006/05/post_50.html#more
21 ：名無しさん＠恐縮です ：2006/05/18(木) 11:47:09 ID:crQs9slw2
アメリカ人は謝られ馴れてないっていうのかな、ちょっとのことで謝るとすごく驚かれるよね。
おれなんかむかし桜の枝を折ったことを正直に謝ったくらいで美談とされたもん。
何回調べても忘れてしまうシリーズ
今回はmtraceの使い方。
mtraceというのはmallocやfreeなどのメモリ管理系の関数をHookして、メモリリークを追跡してくれる便利なライブラリ関数です。
glibc付属なので特殊なソフトのインストールが必要ないのが利点。
使い方の注意点と手は Electric Fence などのmallocを乗っ取るライブラリと共用できないこと（アタリマエだ）
malloc/freeのたびにファイルに書くので結構なオーバーヘッドを伴うこと。
スレッドセーフじゃないこと（これはmallocのhookの仕組みがタコいんです）
mtrace()関数を呼び出すとトレースを開始する。というセマンティクスなのでシェルなどからイマイチ使いづらい所も欠点と言える。
まあ、実例を見てください。
まず、こういうファイルを用意
適当に、メモリリークしてるファイルを用意
コンパイル＆実行
mtraceコマンドにa.outを渡さなければCallerがアドレスで表示されるのでマクロを駆使していて行番号だけでは分からんときはそれで。
しかし、なんでいちいち自分で共有ライブラリ作らんとあかんのよ。不親切だなぁ
○○○リーク！ ランキング！
今回は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がアドレスで表示されるのでマクロを駆使していて行番号だけでは分からんときはそれで。
しかし、なんでいちいち自分で共有ライブラリ作らんとあかんのよ。不親切だなぁ
○○○リーク！ ランキング！
みなさん、バッドノウハウという言葉は聞いたことがあるだろうか。
現在は、いやなブログさんによる、バッドノウハウの本来の定義からやや拡張されて、
uglyなソフトに人間のほうが間尺を合わせるダメな行為を指す意味で使われることが多いように思う。
しかし、これはほとんどエンジニアリング世界（だけ）で通じる言葉でマネージメントの世界でこういう言い方はまずしない。
たとえば、一部で悪名高い、「動いているコードは触るな」メソッドを考えよう。
これはエンジニアから見たら極めて悪辣かつバッドな行為だ。コードを理解せずに対処療法的に問題が出た部分だけを修正してしまうわけだから。
こういうのが積み重なると、こっちを直せばあっちが飛び出し、あっちを直せばこっちが火を噴く。というシステムが簡単に出来上がる。
で、これが何年も前から言われているのに全然なくならない。無くならないどころか減っていく気配すら見えないのは、マネージャーにとって、これは全然「バッド」なノウハウじゃないからだと思う。
マネージャーの仕事ってのは極論すれば「出来るエンジニアがいてもいなくても結果を出す。出せるように手配をする」のが仕事である。たまたま部下にいいエンジニアがいる時にだけ成功するプロジェクト運営方針ってのは明らかに間違ってる。
とするとエンジニアに「ちゃんと理解して修正しろ」と指示するのは間違っているわけだ。ダメエンジニアは理解したつもりで余計トンデモないコードを仕込んでデグレード障害を起こすから。
マネージメントの世界ではこういう教科書的にはちょっとアレゲでも経験的にうまくいく手法をとても大切にする。マネージメントの教科書には書いてないけれども経験的にうまくいく手法を、ベストプラクティスとして蓄積していくわけだ。
でも、これってこの２人の間には深い断絶があるのよね。だってマネージャーはエンジニアに
「お前がバグを入れるかもしれないから理解しろとは言えないし、分かっているから直させろといわれても信じられないんだ。」
とは言えないじゃない。
実はこういう話は一杯あって、エンジニアあがりの新米マネジャーが苦労する一因になっていると考えている。
結論としては、経験則重要、現実を見よう。って事が言いたかったんだけど、この話の流れだとちっともそういう風に見えないな。
反省
・・・・しかし、こういう話をレガシーエンコーディングの話で盛り上がった直後に思いついてしまうのはそれはそれでどうなんだ。
現在は、いやなブログさんによる、バッドノウハウの本来の定義からやや拡張されて、
uglyなソフトに人間のほうが間尺を合わせるダメな行為を指す意味で使われることが多いように思う。
しかし、これはほとんどエンジニアリング世界（だけ）で通じる言葉でマネージメントの世界でこういう言い方はまずしない。
たとえば、一部で悪名高い、「動いているコードは触るな」メソッドを考えよう。
これはエンジニアから見たら極めて悪辣かつバッドな行為だ。コードを理解せずに対処療法的に問題が出た部分だけを修正してしまうわけだから。
こういうのが積み重なると、こっちを直せばあっちが飛び出し、あっちを直せばこっちが火を噴く。というシステムが簡単に出来上がる。
で、これが何年も前から言われているのに全然なくならない。無くならないどころか減っていく気配すら見えないのは、マネージャーにとって、これは全然「バッド」なノウハウじゃないからだと思う。
マネージャーの仕事ってのは極論すれば「出来るエンジニアがいてもいなくても結果を出す。出せるように手配をする」のが仕事である。たまたま部下にいいエンジニアがいる時にだけ成功するプロジェクト運営方針ってのは明らかに間違ってる。
とするとエンジニアに「ちゃんと理解して修正しろ」と指示するのは間違っているわけだ。ダメエンジニアは理解したつもりで余計トンデモないコードを仕込んでデグレード障害を起こすから。
マネージメントの世界ではこういう教科書的にはちょっとアレゲでも経験的にうまくいく手法をとても大切にする。マネージメントの教科書には書いてないけれども経験的にうまくいく手法を、ベストプラクティスとして蓄積していくわけだ。
でも、これってこの２人の間には深い断絶があるのよね。だってマネージャーはエンジニアに
「お前がバグを入れるかもしれないから理解しろとは言えないし、分かっているから直させろといわれても信じられないんだ。」
とは言えないじゃない。
実はこういう話は一杯あって、エンジニアあがりの新米マネジャーが苦労する一因になっていると考えている。
結論としては、経験則重要、現実を見よう。って事が言いたかったんだけど、この話の流れだとちっともそういう風に見えないな。
反省
・・・・しかし、こういう話をレガシーエンコーディングの話で盛り上がった直後に思いついてしまうのはそれはそれでどうなんだ。
ワシントン少年の逸話
297 ：おさかなくわえた名無しさん ：2006/04/05(水) 14:46:12 ID:2x6vw2rM
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
||ワシントンは桜の木を切ったことを||
||素直に父に告白しました || ∧_∧
||父親はワシントンを咎めず || (･ω･`)
||許しました。何故許したのか？ ＿||___ Ｏ□⊂)
￣￣￣￣￣￣￣￣￣￣￣￣￣￣ ￣￣|￣￣￣￣|
∧ ∧ |＿＿＿＿|
( ∧ ∧
〜（＿( ∧ ∧
〜（＿( )＜ワシントンがまだ斧を持っていたからだと思います！
〜（__ ＿,,)