パスワードを忘れた? アカウント作成
2009年1月 記事 / 日記 / コメント / タレコミ
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
2009年1月18日の人気コメントトップ10
48357 comment

taklのコメント: Re:受け取れない奴が悪い (スコア 5, 興味深い) 213

暴論です。

e-mail の場合、送信者と受信者だけでなく中継者も考えに入れる必要があります。
昔は8ビット目をクリアしてしまう中継者がたくさん居ました。
運悪くそのような中継者に当たってしまうと、文字化けします。
そのような中継者が絶滅したと言い切れないのであれば、
iso-2022-jp を使うべきです。

# もう絶滅したよね、と思ってたら2006年に遭遇しました…。
# いい加減滅ぼしてくれよ。
48389 comment

kei100のコメント: Re:HDD業界の過去事例 (スコア 5, 参考になる) 119

by kei100 (#1493638) ネタ元: Seagate社、自社製HDDの不具合を認める

HGST信者の戯言と流して頂ければ結構ですがHGSTは以前DTLAでやらかしたからなのか、
WD/Seagate/HGST/三星の中だと一番ファームが安定してる感じがします。

今回の件に関しては1.5TBの時のkrazyさんのファームが酷いという発言がまんま表に出てきたという感じですねぇ。

IDE時代でから、WDはSingleとか言うモードじゃないと動かないとか(ネゴが下手)、
SeagateはUDMAの実装ミスでデータ化けさせたりとかありましたし。
SATA入ってからもWDはFirmware不良でStaggered Spin Upが解除出来ないとか(RocketRAID使用者がハマった)、
Seagateはキャッシュ容量の認識ミスとか。

それに対してHGSTは比較的ATA規格をきっち守っている感じがします。
が、P7K500の例なんかもまんまですが規格を馬鹿正直に守るのでホスト側が適当に実装していると落とし穴に落ちます。
あと、ジャンパがないのでIDE互換インターフェースを持ちGen2/SSCが有効でもちゃんと使える環境を1つ用意しておかないと認識出来ず悲しい思いをする可能性があります。

7K1000.Bはまだ数をそろえてないので評価は先送りですが、P7K500は結構良い感じでした。
シーク遅いですが、WDGPよりはシステム寄りですね。
7K1000.Bで1台比較的早期に不良セクタ置換が出たのが初期不良なのか否か気になる所です。
後はヘッドやプラッタが世代的に遅れがちなのが性能重視な方にはウケなさそうです。

48472 comment

gingaのコメント: なんのための文字コードの規約・約束事か? (スコア 5, すばらしい洞察) 213

問題をよく考えましょう.
  • 単独で動作するアプリケーションの話ではなく,不特定多数の相手との通信アプリケーション
  • 直接に相手の(文字コードなどの)能力仕様を確認する手順を踏まずに, 仮定(相手が ISO-2022-JP 等を処理できると決めうち)の上でいきなり送りつける (SMTPによる MTA 間のやり取りはEHLO 等で仕様確認して調整する余地があるが, MUA間のやり取りは RFC822,RFC2822,RFC5322 などの仕様で書かれたものを,完全一方通行で送る)
  • (とりあえず 8bit through かどうかはまた別の問題ということで置いておく)

さてここで,歴史的に考えるとこんな感じになります.

  1. 原始時代: 英語? ローマ字?(私はよく知らない)
  2. pre-MIME時代: メッセージには JIS(≒ISO-2022-JP)を使うという プロトコル外の「共通の了解事項」を設定することにより 「日本語メール」が決められて日本語で送受信が可能に
  3. MIMEの登場: 送る側については,前記の「暗黙の了解」に頼らずに 文字コードを指定する方法が登場.ただし符号化方式と文字セットのごった煮問題とか, 受信側との「文字コード対応能力判定」みたいな機能はないことに注意. (また,従来方法も現在に至るまで若干併存)

日本語限定でなくいろいろな言語・文字コードが飛び交うようになり 「ISO-2022-JP のみ」が若干時代遅れという印象を持つ人もいるかも知れませんが, 実は「文字コードを何にしないといけないか」はほとんど変わっていないはずです.

多国語を扱いたいとかの要望も含めてutf-8 等の需要は高まっているかも知れませんが, 実はいまでもかなり多くのシステムが MIME の文字コードにすらきちんと従っていません.

"charset=iso-2022-jp" と宣言しておきながら,実際には本文を shift_jis で送ってくる MUA

のなんと多いことか. (これはある意味 「ISO-2022-JP 対応で十分」とは言えない理由ともいえるかもしれませんが) 結局のところ,多くのシステムは MIME 情報も参考にしつつ, 「ISO-2022-JP 決めうち(時々変態からの shift_jis や utf-8 に例外的に対応)」 などということを,今でもしているのではないでしょうか.

MIME 対応すら正しい実装が完全に普及したとは言えないときに, 特殊な文字セットを使いたいとかの場合以外は,「勝手に」変える理由は何もありません. むしろ実装の種類が星の数ほど増え,ユーザーも極めて多種多様になった現在, 旧来の仕様を廃止して全員が納得する「新しい合意」を作るのは以前より遥かに難しいでしょう. 「utf-8 を使いたい」という人がいても良いですが,それは 「相互に utf-8 を使うということに合意がとれている2者間」ないし 「同様の合意のある特定のコミュニティ内」に 閉じて使われるべき話であろうと考えます.

48149 comment

nodocumentsのコメント: Re:ヤマモト・ヨーコかと思った…… (スコア 4, 参考になる) 113

第4章58条 攻撃の影響に対する予防措置。
(a)第4条約第49条を害することなく、自国の支配の下にある平和的住民、個々の文民及び非軍事物を軍事目標の周辺地域から移動させるように努めること
(b)人口密集の地域内またはその付近に軍事目標を設置することを避けること
(c)自国の支配の下にある平和的住民、個々の文民及び非軍事物を、軍事行動から生じる危険から保護するため、必要なその他の予防措置を取ること。

48161 comment

KuRo-CaTのコメント: 追記その2 (スコア 4, 参考になる) 119

by KuRo-CaT (#1493304) ネタ元: Seagate社、自社製HDDの不具合を認める

本文中に入れておいたはずですが、ソース元がリンクされていなかったので追記。
http://seagate.custkb.com/seagate/crm/selfservice/search.jsp?Tab=search&Module=selfservice&TargetLanguage=selfservice&DocId=207931&NewLang=en

#採用された場合は、編集者さんに本文中に取り込んで頂ければ嬉しい。

48273 comment

KuRo-CaTのコメント: 追記その3 (スコア 4, 参考になる) 119

by KuRo-CaT (#1493434) ネタ元: Seagate社、自社製HDDの不具合を認める

どうやら海外のForumに投稿された情報によると問題があるのは特定シリアルの個体のみの様子。
http://www.msfn.org/board/index.php?showtopic=128092&st=720
また、2chのSeagateスレッドに投稿された情報によると20日あたりにシリアルチェッカー用のWebサイトが公開されるとのこと。
http://pc11.2ch.net/test/read.cgi/jisaku/1232178230/
上記スレッドの287レス目を参照。

いずれにしても真偽のほどは不明なので注意されたい。

48279 comment

ksh2ksk4のコメント: Re:緑茶 (スコア 4, おもしろおかしい) 68

私もコーヒーは大好きですが,

> この辺をしっかりしてもらわないと、コーヒーだけが槍玉にあげられているように感じて、
> 私も含めたコーヒー好きの人間にとって、ただ不快感を与えるだけとしか思えないのですが。

ここまでの被害妄想はありません.

コーヒーの飲み過ぎではないですか?
48351 comment

moriwakaのコメント: 現状のContent-Type対応は十分ではありません (スコア 4, 参考になる) 213

Mozilla系のMUAはRFCに近い実装ですが Outlook Expressは
最初に検出したエンコードで全体をデコードするため
subjectのエンコードと異なるcontent-typeでは問題がでるなど、
MIMEの扱いはぼろぼろです。

さらにIMAPでは検索などでサーバ側でもMIMEを扱うためこちらの対応状況も問題になります。

メーリングリストでも、アーカイブ作成時の変換やSubjectの書換などで
エンコード/デコードが必要となります。

これらについて、現状ではiso-2022-jpであることや、
メール全体が同じエンコーディングであることを仮定したハックによる
対応が行われているものが散在し、Content-Typeに従った対応が
全般に渡ってされていると仮定するのは無理があります。

typodupeerror

弘法筆を選ばず、アレゲはキーボードを選ぶ -- アレゲ研究家

読み込み中...