taklのコメント: Re:受け取れない奴が悪い (スコア 5, 興味深い) 213
e-mail の場合、送信者と受信者だけでなく中継者も考えに入れる必要があります。
昔は8ビット目をクリアしてしまう中継者がたくさん居ました。
運悪くそのような中継者に当たってしまうと、文字化けします。
そのような中継者が絶滅したと言い切れないのであれば、
iso-2022-jp を使うべきです。
# もう絶滅したよね、と思ってたら2006年に遭遇しました…。
# いい加減滅ぼしてくれよ。
アナウンス:スラドとOSDNは受け入れ先を募集中です。
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台比較的早期に不良セクタ置換が出たのが初期不良なのか否か気になる所です。
後はヘッドやプラッタが世代的に遅れがちなのが性能重視な方にはウケなさそうです。
さてここで,歴史的に考えるとこんな感じになります.
日本語限定でなくいろいろな言語・文字コードが飛び交うようになり
「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者間」ないし
「同様の合意のある特定のコミュニティ内」に
閉じて使われるべき話であろうと考えます.
第4章58条 攻撃の影響に対する予防措置。
(a)第4条約第49条を害することなく、自国の支配の下にある平和的住民、個々の文民及び非軍事物を軍事目標の周辺地域から移動させるように努めること
(b)人口密集の地域内またはその付近に軍事目標を設置することを避けること
(c)自国の支配の下にある平和的住民、個々の文民及び非軍事物を、軍事行動から生じる危険から保護するため、必要なその他の予防措置を取ること。
本文中に入れておいたはずですが、ソース元がリンクされていなかったので追記。
http://seagate.custkb.com/seagate/crm/selfservice/search.jsp?Tab=search&Module=selfservice&TargetLanguage=selfservice&DocId=207931&NewLang=en
#採用された場合は、編集者さんに本文中に取り込んで頂ければ嬉しい。
どうやら海外の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レス目を参照。
いずれにしても真偽のほどは不明なので注意されたい。
Mozilla系のMUAはRFCに近い実装ですが Outlook Expressは
最初に検出したエンコードで全体をデコードするため
subjectのエンコードと異なるcontent-typeでは問題がでるなど、
MIMEの扱いはぼろぼろです。
さらにIMAPでは検索などでサーバ側でもMIMEを扱うためこちらの対応状況も問題になります。
メーリングリストでも、アーカイブ作成時の変換やSubjectの書換などで
エンコード/デコードが必要となります。
これらについて、現状ではiso-2022-jpであることや、
メール全体が同じエンコーディングであることを仮定したハックによる
対応が行われているものが散在し、Content-Typeに従った対応が
全般に渡ってされていると仮定するのは無理があります。
>5年保証
Seagateの保証は3年に短縮だそうですよ。
http://www.watch.impress.co.jp/akiba/hotline/20090117/etc_seagate.html
弘法筆を選ばず、アレゲはキーボードを選ぶ -- アレゲ研究家