檜山家に一体なにが((((;ﾟДﾟ)))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ
覚せい剤 安価
このワードでどうやってウチにたどりつけるのか素直に疑問です。
特殊文字 ローマ字 おお
おお は特殊でもなんでもない文字です :)
- 関連記事
-
- 社内で (2006/11/16)
- 今日のサーチワード (2006/10/26)
- はてなブックマークカウンターというものがあるらしい (2006/10/23)
つ http://nais.to/~yto/clog/2006-10-05-1.html
ちなみに、うちのサイトの結果は・・・
でした
少ない！！
- 関連記事
-
- 今日のサーチワード (2006/10/26)
- はてなブックマークカウンターというものがあるらしい (2006/10/23)
- ■[I18N] Windows Vistaの登場で顕在化する問題 (2006/10/20)
つ http://imihu.blog30.fc2.com/blog-entry-2077.html
- 関連記事
-
- ルー語変換 (2007/01/10)
- 仔ブーンが超かわいい件について (2006/10/21)
- なんだかよく分からんが、これはおもしろい (2006/10/15)
ほほー
http://d.hatena.ne.jp/kazama/20061019/p1
- 関連記事
-
- はてなブックマークカウンターというものがあるらしい (2006/10/23)
- ■[I18N] Windows Vistaの登場で顕在化する問題 (2006/10/20)
- ページの横幅を可変にしてみた その２ (2006/10/17)
「もしもし岡田ですけどアァーすいません間違えました」
という電話がかかってきたらしくて、近くの席同士で、
なんだったんだろう？？
という話しをしてた。
ほら、アレだよ。
自分のことを岡田だとずっと信じてきたのに真実に気づいてしまったんだよ。
- 関連記事
-
- Binary Hacks読み終わった (2006/11/12)
- 不思議な電話 (2006/10/19)
- あれー (2006/10/09)
ＩＥのCSSバグ紹介ページとかCSSによる段組レイアウトの紹介ページとかを見ながらハックハックハック！！
CSSってブラウザの互換性問題で、作法が超複雑になっているというのが良く分かった。
マジしんどいっす。
どうも float: leftなdivが２つあって、以下のようにスタイル指定されていた場合、
<div id="div_a" style="float:left; width150px">
</div>
<div id="div_b" style="float:left">
</div>
正しい解釈はdiv_bの横幅の計算でdiv_aのことを考えずに（だってdiv_aはfloatだから）横幅を計算して、結果的に幅100%になって、
あらら、div_a と div_b 足したら親要素の横幅超えるじゃん。
だから、div_bはdiv_aの下に回りこむ。
という事になるらしいのだが、IEはfloatの計算がてきとーらしい。
φ(.. )ﾒﾓﾒﾓ
てゆーか、「見た目を気にしないから」という怠惰（プログラマの美徳の１つ）な理由でwidth削っただけなので、その後始末で何十倍もの時間をとられるとは是如何に？
バグがあると、つい真っ当な形で修正したくなってしまうのはある種の職業病だよなぁ・・・
とかとか。
ところで、ＩＥで見たときのみ、１番目の記事のタイトルだけまだオカシイんだけど、誰か理由教えてくれないかしら？？
追記： そして、今度は印刷プレビューがめちゃくちゃに。うがががが
- 関連記事
-
- ■[I18N] Windows Vistaの登場で顕在化する問題 (2006/10/20)
- ページの横幅を可変にしてみた その２ (2006/10/17)
- 「Amazon おまかせリンク(TM) ベータ版」を評価してみた (2006/10/16)
アルゴリズムの精度が悪すぎてとんちんかんな商品ばかりがリストアップされる。
多分、日本語処理がまだちゃんと実装されていないのではなかろうか。
おかげで、Drk7jpさんとこのアルゴリズムの良さを再確認してしまったよ。おふぅ
- 関連記事
-
- ページの横幅を可変にしてみた その２ (2006/10/17)
- 「Amazon おまかせリンク(TM) ベータ版」を評価してみた (2006/10/16)
- ページの横幅を可変にしてみた (2006/10/16)
見栄えにこだわるブログでもないので、ゆーざびりちー優先にしてみた。
少なくともオイラはこっちのほうが使いやすい( ´ー｀)y-~~
ちょっとした親切！ ランキング！
- 関連記事
-
- 「Amazon おまかせリンク(TM) ベータ版」を評価してみた (2006/10/16)
- ページの横幅を可変にしてみた (2006/10/16)
- Google Analytics、招待制廃止、誰でも利用可能に (2006/08/16)
- 関連記事
-
- 仔ブーンが超かわいい件について (2006/10/21)
- なんだかよく分からんが、これはおもしろい (2006/10/15)
- 最強のモビルスーツ (2006/10/06)
つまらない
うまくいったら、次回の発表ネタにしようと思っていたのに。
カーネルのソースを見る限り取りこぼすほうが自然に見えるので後日反省会をしよう。
- 関連記事
-
- 不思議な電話 (2006/10/19)
- あれー (2006/10/09)
- お風呂の掃除屋さんに来てもらった (2006/10/09)
妖怪とか量産できそう・・・・とか思った。
それはさておき、お風呂・台所が超ピカピカにしてもらったので大変気分がよい。
業者は違うな。
ピカピカの新型！ ランキング！
- 関連記事
-
- あれー (2006/10/09)
- お風呂の掃除屋さんに来てもらった (2006/10/09)
- PS2版ヴァルケンが一部で大人気な件について (2006/10/05)
もったいないので、うｐしてみる。
ただ、お蔵入りしていたあけあって毒入りです。うわはははｈ ヽ(;´Д`)ノ
－－－－－－－－－－－－－－－－－－－－－－－
前回、「firefox EUCが最低」という記事において、ちょっとタイトルが下品だったこともあり、
各方面からお叱りのお言葉を頂いた。
深く反省したい。
ところで、ネットでいくつかご意見を拾ってみると、どうもIEがJIS X 212（補助漢字）を
サポートしていないのが規格違反、Firefoxを責めるのは筋違い。という意見を持つ方が結構いらっしゃるみたい。
IEがEUC-JPのWebページの表示・送受信にCP51932というEUC-JPとは似て非なる文字コードを使っている事はたしかで、
そこに弁解の余地はないのだが、昔はみんなJIS X 212なんか使わないのがマナーだ。とか言われていたのに今はクライアントソフトの欠陥扱いなのね(n'ω'`)
時代は変わるなぁ。
さてさて、そんなこんなでモヤモヤしたものを抱えているうちに、Web検索で、MySQLのMLの過去ログ公開ページにてEUC-JPでは補助漢字はオプショナルという意見をみかけたので（おお、よく見たら、これって森山さんの投稿なのね）
ちょいと定義を調べてみました。
興味のある人は以下のリンクと前後のスレッド文章を適当にあさってみてくださいな。
つ http://www.mysql.gr.jp/mysqlml/mysql/msg/12389
まず、IANAのcharset registryのEUC-JPの定義はこちら
ソース http://www.iana.org/assignments/character-sets
Name: Extended_UNIX_Code_Packed_Format_for_Japanese
MIBenum: 18
Source: Standardized by OSF, UNIX International, and UNIX Systems
Laboratories Pacific. Uses ISO 2022 rules to select
code set 0: JIS Roman (a single 7-bit byte set)
code set 1: JIS X0208-1990 (a double 8-bit byte set)
restricted to A0-FF in both bytes
code set 2: Half Width Katakana (a single 7-bit byte set)
requiring SS2 as the character prefix
code set 3: JIS X0212-1990 (a double 7-bit byte set)
restricted to A0-FF in both bytes
requiring SS3 as the character prefix
Alias: csEUCPkdFmtJapanese
Alias: EUC-JP (preferred MIME name)
これを見ると残念ながら、RFCでも国や標準団体の決めたデジュール・スタンダードでもないので、規格番号とかがなく、「いわゆるEUC-JP」というちょっと悲しいポインタになっていることがわかる。
いちおうUIとかOSFとかいう文字はあるので、
僕が聞いたことがある説の中で一番トンデモな「EUC-JPとはJIS X 213 EUCの事である！」
という説は却下していいと思うが、それ以上は業界の暗黙の合意に頼っているのが現状である。
ところで、これ、将来MSやJIS委員会が自分のスペックの片隅にOSFとかUNIX Internationalとか
いう文字をいれたら「うちのEUCこそはEUC-JPの正式な定義である」と名乗れるんですかね。
＃ いやいや、もちろん冗談ですぞヽ(;´Д`)ノ
でも、まあ、業界内のだいたいの合意というものはあるようで、
UNIX SYSTEM V リリース 4 日本語環境共通規約 第１版
1992/7/10 初版発行
ISBN: 4-8101-8359-7
トッパン
または
UI-OSF 日本語環境実装規約
Version 1.1
1993 年5 月21 日
UI-OSF Japanese Localization Group
を典拠にあげる人が多かった。
んで、まずは「UNIX SYSTEM V リリース 4 日本語環境共通規約 第１版」のほうを
めくってみると（今持ってる人は少ないと思うが）
P11
2.1.2 日本語文字セットに関する共通規約
ここでは各プラットフォームメーカがサポートすべき文字セットについて述べます
(1) サポートを必須とする文字セット
各プラットフォームメーカは以下の文字セットのサポートを必須とします。なお、ここで「文字セットのサポート」とは：
－ 日本語を扱うプログラムは以下の文字セットを日本語として正しく処理できること。
－ 入出力装置が日本語を扱える場合、以下の文字セットの入力や表示、印刷が可能なこと
を示します。
・ ASCII
・ JIS X 208-1990
ただし以下の点に注意が必要です
（中略）
(2) サポートを推奨する文字セット
以下の文字セットはサポートを推奨しますが、これは必須ではありません（レベル２です）。
・ JIS X 201-1976 カタカナ
以下の文字セットは現在サポートを義務付けませんが、将来的にはサポートが必要となるでしょう。
・ JIS X 0212-1990 補助漢字
となっており、なるほど、たしかにJIS X 201カタカナとJIS X 212は必須じゃないね。
次はUI-OSF 日本語環境実装規約を見てみる。こっちはWebでPDFが公開されている。
教えてくださった沼田先生に感謝。
附属書D (参考) 応用プログラム開発者向けのガイド
D.1.1 共通日本語文字集合日本語文字集合としては，次に示す文字集合が共通に使用できます。
(1) ISO 646 IRV (ASCII) 又はJIS X 0201 ローマ字用7 単位符号
(2) JIS X 0208 情報交換用漢字符号
D.1.2 多くの実装で使用できる日本語文字集合
次に示す文字集合は，この実装規約が提供を推奨しているものです。ただし，提供を義務付けられてはいませんので，この文字集合が使えない実装もあります。特に，シフトJIS を使用する場合，C1 制御文字及びJIS X 0212 情報交換用漢字符号{補助漢字は使用できません。
(1) JIS X 0201 片仮名用図形キャラクタ
(2) ISO 6429 が規定するC1 制御文字
(3) JIS X 0212 情報交換用漢字符号{補助漢字
となっており、やはりJIS X 201 や JIS X 212は必須じゃないとされている。
ただし、前述のトッパン本とはややニュアンスが異なるようである。
ただ、この規格書、どうもよく分からないのが、付属C,D全体
（ようするにこの辺で引用しているあたりの章全体）が「参考」情報とされており、
規格本体からはずされてしまっている。
規格と関係ないところで、実装が必須かどうかを定義するってそれ一体何の意味があるのよ？！
と疑問に思わなくも無いが、
出典[UI-OSF-USLP 共同技術資料:日本語EUC の定義と解説(1991 年12 月12 日)]
という一文があったので、もしかしたら、出典は別にあってこっちはタダの引用だよん。
という意思表示のつもりだったのかもしれない。
ただ、この[UI-OSF-USLP 共同技術資料:日本語EUC の定義と解説(1991 年12 月12 日)]という
規格書はいまや完全に入手不可能なので、何が書いてあったのか全然分からない。
まとめると
・EUC-JPの明確な定義はある
・しかし、それはRFCやISOの規格にはなっていない
・JIS X 201(半角カタカナ）と JIS X 212(補助漢字）は必須ではないと書いてある
・しかしながら、書いてある本から察するにどう考えても適用範囲はいわゆるUNIXに限られそう
・んじゃ、UI-OSFに入っていないOSはどう解釈すべきかというと・・・・
世間にまったく合意がないように思える
・たぶん、MSは自分は適用範囲外だから、ルールを逸脱して好き勝手やっても問題ない。
と思って、今のあやしげなIE上のEUC-JPの実装になっていると思われ
・でも、Web上での世間の声を聞いていると、逆に、EUC-JPの文字セット定義は
IANAのcharset registry定義で「定義」されていて、「必須じゃない」という文章が
適用範囲外なので、WindowsはUnixと異なり補助漢字実装必須なんだ。
IEが補助漢字実装しないの許せーーんヽ(;´Д`)ノ
とでも、思っているとしか思えない、IEの補助漢字未実装を責める声多数
うーむ、一体何がここまで混乱を招いた原因なんですかね？
なんとなく、EUC-JPの典拠規格が手に入りにく杉。というのが根本的に問題な気がするけど・・・
あと、つくづく思ったのは昔とは補助漢字の位置づけが変わったな。ということ。
昔は、んなもん使えるマシンの方が少なかったのでネットワーク上でんなもん使うやつがおバカという共通認識があったと思うのですよ。
それがUnicodeの普及によってJIS X 212が使えるマシンのほうが多数派になっちゃったから、規定がいいかげんなEUC-JPは色々運用に不都合が出てきている気がする。
やはり、いっそのことEUCは捨てて、みんなでUTF-8に移行するしかないんかね？
＃携帯サイト問題（携帯電話はUnicodeをサポート事が多い）は残るけど
・・・時代は変わった！
どっちなのさ？！ ランキング！
- 関連記事
-
- なぜかRubyのM17Nの記事からリンクが貼られていた件について (2009/04/01)
- IEがEUCのJIS X 212をサポートしていないのは規格違反なのか (2006/10/08)
- FirefoxのEUCの独自拡張のセンスが最低な件について (2006/05/29)
が、いい話だった。
本編の風呂敷の畳み方については、すでにいろいろなブログで色々と言われているので、ここでは言わない。
正直僕も不満だったけど、読者がエンドレス連載を求めている以上、締めにかかると不評を買うのはある程度は仕方ないかな。とも思った。
が！そんなことはさておき、巻末の付録の読みきり漫画が神マンガな件について！！
どこをどうひねったら、ドラえもんの道具をネタにそんな感動話をでっち上げますか！！
とりあえず、この本を紹介してくれた友達のヨメに感謝しておく。
- 関連記事
-
- 鋼の錬金術師（１５） (2006/12/10)
- ハチミツとクローバー１０巻をやっと読んだ (2006/10/08)
- [書評] もやしもん (2006/09/13)
1 ：以下、名無しにかわりましてVIPがお送りします ：2006/10/04(水) 23:00:42.60 ID:H8K6OXr80
┌───┐
│ ○七 ←ここだけ穴が開いててビームライフルが打てる
│ ├┘|
│ 人 │
└───┘
↑四方八方が盾
もう誰にも負けないんじゃね？
バカスｗｗｗ
以下、つづきはこちらから見れるようです。
微妙に間違ったガンダム！ ランキング！！
- 関連記事
-
- なんだかよく分からんが、これはおもしろい (2006/10/15)
- 最強のモビルスーツ (2006/10/06)
- K&Rが一部でブームになっている件について (2006/10/03)
なお、われらがWikipediaには、こんなステキコメントが
リメイク版に関しては、プラットホームの違いなどから、オリジナルの魅力を引き出せていない部分がある（実際は改悪同然との声が多い）ため、ファンからの評価は厳しいものがある。
リメイク版に対するファンの怒りは激しく、発売元のクロスノーツとその製作スタッフを糾弾するためのホームページまで出現した。
かなりコアなファンには原作の名を汚されたくないあまり、PS2版のヴァルケンをヴァﾉﾚケソと表記し、原作とは別物としている記事が見られる。
又、playstation mk2というPS2レビューサイトでは100点中4点と史上最悪な点数がつけられ、デスクリムゾンOX+の16点を凌いでいる。
ちょ・・・デスクリムゾン越えｗｗｗｗ
デスクリムゾンを超えたい勇者は、ここをクリック！
- 関連記事
-
- お風呂の掃除屋さんに来てもらった (2006/10/09)
- PS2版ヴァルケンが一部で大人気な件について (2006/10/05)
- だまされた (2006/10/05)
っ http://0xcc.net/blog/archives/000133.html
- 関連記事
-
- PS2版ヴァルケンが一部で大人気な件について (2006/10/05)
- だまされた (2006/10/05)
- 企業内イントラって極悪だよね (2006/10/02)
定義よく嫁
- 関連記事
-
- ボヘミアンの勝利(？)だそうな (2006/12/13)
- 今日の謎検索ワード「NEC選定IBM拡張文字 arib」 (2006/10/04)
- (Forum) 私はなぜフレームワークが嫌いか (2006/09/25)
自己反省しつつ転載させていただく(。・ω・)ﾉﾞ
Ｋ＆Ｒは偉大です！ ランキング！
- 関連記事
-
- 最強のモビルスーツ (2006/10/06)
- K&Rが一部でブームになっている件について (2006/10/03)
- 仮面ライダーになりたかった (2006/09/29)
増えること自体は全然ＯＫなのだが、どういう文脈でリンクされているのかこちらからは全然分からないのでお尻がむずむずする。
おーい、陰口言うぐらいならブログコメントで苦情をいってくれ～
- 関連記事
-
- だまされた (2006/10/05)
- 企業内イントラって極悪だよね (2006/10/02)
- 時系列順だの放送順だの (2006/09/29)
一見の価値ありと思うので、ぜひ見てみて欲しい。
で、僕なりにちょっと補足させてもらうと
まずRISCにおいては mallocは8byte alignが事実上必須だよね。という指摘には完全に同意。
で、POSIXに書いてないのはCISCだと必須じゃないじゃーん。って事だと理解してる。
んで、noocyteさんはプラットフォーム非依存のmallocを書くとしたら、結局RISCの制約に引きずられて8byte align必須になるよねー
という話をしているように見える。
一方、みんな大好き僕らのx86はCISCの子孫なのでミスアラインアクセスが発生してもバスエラーにはならないが、SSE命令は16byte alignされてないと性能でないので、性能を意識するなら16byte alignにする必要がある。
じゃあ、なんで glibc malloc がそうなっていないの？
という疑問が沸くが、これがどうもよく分からない。
元々のdlmallocはlibcとは別の yet another malloc なので、CPU毎に#ifdefするのがイヤで
可搬性を考えて8byte alignにした。というのは十分にありえる話だが、
libc でそれをやる理由は解せない。
昔はSSE命令がなかったので、その時代の名残というセンも考えられるが、
SSE命令の使用頻度まで考えて、メモリ使用効率とのトレードオフまで考え抜いたすえに
8byte alignを選択した可能性も０ではない、と。そういう考え方もあるわけで
いや、実はこの問題は７月にLMSで話をしたときにも指摘されていたので既知の話で
かなり確信犯的に、当日は話をわざとぼやかして
聞かれたら答えるけども、自分からは言わないモードにしたわけだね。
大人って汚いね(^^;
＃いいわけしとくと、当日は内容が多かったので時間が押していて
＃講師自ら話を脱線させていくのは、厳しい状況だったんですよぅ(^^;;;
と、いうわけで、x86で16byte alignにするパッチを書けば性能改善する余地はあると思うので誰か試してみない？
しかし、かえすがえすも残念なのはnoocyteさんが当日来てくれていたら、その後の宴会で盛り上がれたのは間違いないと確信できるところ。
いつかぜひお会いしたいものである。
にげろーーー、ランキング！
- 関連記事
-
- Xってどこで起動させてるの？ (2006/12/03)
- x86でもmallocを8byte alignにするのは最適解か？ (2006/10/02)
- 間違えてた (2006/09/30)