よくよく調べてみると、どうやら ASCII コード文字以外は対応していないらしい。
ということで、python3.x のインストールやり直し確定。
まぁ codec.open() 使って、あとで頑張ってパースするのもいいんですが、3.x 系で対応してるなら、わざわざ無駄な労力払わないくても、それ使えばいいじゃないですか。
どうりで、さくらのレンタルサーバだとpython 2.x系が標準で提供されてるのにもかかわらず、python 3.x 系をわざわざインストールしてる人と（いうか記事）が多いなぁと思ったら、こういうことだったのか。
2.x 系と 3.x 系の間には、文字コード関係をはじめ、かなり大きな進化点があるんですね。
なんだか 昔の Perl を思い出したよ。
jcode.pl, jcode.pm とか、懐かしいな。。。
RHEL（RedHat Enterprise Linux） 5 での場合。他のブランドは知らん。
原因は、他の VMWare ホストに乗せ替えた時点で、MACアドレスが変わってしまい、それをnetconfigコマンドが「『NICが新規に刺された』と誤認識」（?）してしまうため。
以前の eth0 で設定していた情報が eth1 に移動し、移動先のVMWare ホストから割り当てられた MAC アドレスで、eth0 が作成されます。
そして、残った eth1 の情報は当然、前の VMWare ホストで稼働していた際のNICなので、このままにしておいても、何の役にも立ちません。
しかもそのままにしておくと、起動時に eth1 の情報を読み込んで、存在しないデバイスをOS内に格納されているNICデバイスドライバを総当りで探しに行ってしまいます。
その結果、起動が遅くなるうえ、起動時のメッセージがゴミだらけになります。
という訳で eth1 の情報は、残していてもあまり役に立たないので、削除するか、残しておくならば、何処かに移動してしまいましょう。
削除（移動）すべきファイルは、/etc/sysconfig/network-scripts/ の中にある ifcfg-eth1 というファイルです。
本家のバージョン4.1.0 では、開発された時点でのSSHの暗号アルゴリズムが少ないので、NVR500に搭載されているSSHサーバの暗号アルゴリズムが解読できないみたい。
なので、オープンプロジェクト以降のバージョン4.3.0b以降～を使うのが良いかと。
まぁ、ルータが壊れたので、急遽新調。
その際にNVR500を購入したので、その備忘録。
1.「かんたん設定」で、LANのDHCP割当IPの設定までやる。
ここでは、以下のような感じで。
2.「かんたん設定」でSSHで接続できるようにする。
あとSSHでログインするためには、ルータ（に組み込まれているOSへのログイン）ユーザ登録も必要になので、登録する。
3.静的IPを割り当てたい機材のMACアドレスを調べておく。
（実はこれが一番面倒。 ）
4.SSHクライアント（TeraTermPro とか Poderosa とか）でルータにSSHログイン。
(1)管理者に成る。
> Administrator
（ここで管理者パスワードを聞かれるので、
「かんたん設定」で登録した管理者パスワードを入力。）
#管理者になれたらプロンプトが「>」から「#」に変わる。
(2)静的割当するIPとMACを登録。（やっと本題）
# dhcp scope bind 1 192.168.100.6 ethernet 12:34:56:78:9a:bc
#(3)最後は「保存」のコマンドを実行。
# save
#これを忘れると、ルータの電源切ったり再起動した時に登録した情報がすべてパーとなる。
(4)確認するときは show config コマンドの結果の中から、dhcp だけを grep して確認。
#show config|grep dhcp
（結果がここにダラダラでてくる）
#ルータを新調したので、DHCP の IP 静的割当を設定したのだが、Drobo FS の MAC アドレス探しがちょっと面倒だったので、備忘録。
まぁ Drobo FS 本体に貼られているラベルを見れば、MAC アドレスは判るんだけども、肝心のラベルが本体底面に貼られているので、引っ繰り返さないと確認できないのが難点。
我が家の場合、ラベルを確認するためには、Drobo FS の電源を切って、Drobo FS 本体が格納されているラックから引き剥がす必要があって、これがラックの場所とかの関係で、ちょっと大変。
ちなみに、IP アドレスとかサブネットとかは Drobo Dashboard から設定するものなので、そこから確認できるものの、MACアドレスは確認できない。（まぁ所詮米国製なので、こういうツールの「痒いところに手が届かない」のは、 米国の仕様（＝御国柄と同意）。）
ということで、パソコンからは少し面倒ではあるが、Drobo FS の組み込み Linux にアクセスして調べることに。
という訳で以下手順。
1. DroboAppsから「dropbear」(SSHサーバ)をインストール
2. SSHクライアント（TeraTermProとかPoderosaとか）でDroboFSにSSHログイン。
ここでSSHの接続が確立できない場合は、DroboApps の挙動がおかしい可能性がある。
その場合は、Drobo Dashboard の管理者設定の「DroboApps を有効化」を一度切ってから、再度入れ直す。
ちなみに Drobo FS 再起動しても、接続は改善できない。必ず上記操作が必要。
3. ログインできたら、以下のコマンド実行
# /sbin/ifconfig
（ここにMACアドレスなどのネットワーク情報が表示される。）
#（パスが通ってないので、最初に/sbin付けて、絶対パスでコマンド実行。）
これで本体をひっくり返さずに、MACアドレスの確認ができる。
とはいえ、とても面倒。
使用していたPCのうち1台が御役御免になったので、臨時（とはいえ向こう3年ぐらいは使いそうな）VHSテープ動画編集機として換装してみました。
4年ぐらい前に買ったドスパラのショップブランドPCです。今までのスペックは以下
これを、当初は以下の通り、編集機として必要な換装するだけにしようかと思ってました。
そんなこんなで、とりあえず手始めにCPUとメモリを手配して換装してみた。
まぁ、換装する前からOEM版マザーボードはBIOSアップデートができない（）と情報を得ていたので、もしかしたら「CPUがマザーボードに対応していないかもなぁ」と思っていましたが。
結局のところ、当時の BIOS が、その後に発売された CPU に対応していないことが原因。
まぁ、チップセットなどをみる限り、BIOS をアップデートすれば問題なさそうだというのが判明したのだが、そこで更に問題が。
OEM 版の BIOS の提供はマザーボードのメーカーからの提供ではなく、本体を組成したメーカーに提供委ねられることが多い 。
まぁ、JS ヘルパーを使うことによって、jQuery の記述を分離する必要がなくなるのは利点といえば利点。
でもそれ以上の不利もある。
まぁ JS ヘルパーに限らず、全体的にヘルパーというのは、使用した際に最終的にどのような HTML になるかを少なからず想像しなくてはならないものなのだが、JS ヘルパーはその想像が難しい。
しかも CakePHP 御大が提供しているドキュメントがウンコで、とても判りにくい。結局、JS ヘルパーの場合、ヘルパーのコアソースを追うのが一番早かった。
あと、Ajax ヘルパー（prototype.js）のように、jQuery の経年による陳腐化した際の仕様変更や廃止も怖い。
こうなると javascript（jQuery）は、ヘルパーを使わずに普通に記述したほうがよいのかもしれない。
でも、JS ヘルパーを利用することにより、ソースコーディング量が減るもの事実。
実際 javascript（jQuery）を記述するよりも、ソースコーディングは減った。（結果的に生成される HTML は、javascript（jQuery）を記述するよりも大きいのだが。）
正直なところ、直接、テーマのスタイルやPHPソースファイルを修正したほうが手っ取り早いです。参考書籍でさえ、そのような記述が為されているものが多いです。
でも折角なので、なるべく TwentyTen のテーマを構成しているソースの構成をベースに残したまま、メッセージを修正してみます。
ちなみに、WordPress の日本語版に同梱されている TwentyTen テーマは、日本語ローカライズに対応していて、元文書のPHPソースを修正せず、設定ファイルみたいな物を介して、該当箇所の英語メッセージを日本語に置換して表示しています。
今回はこの仕組みをそのまま利用するための修正方法です。
テーマをカスタマイズしている場合、特に TwentyTen などWordPress のデフォルトテーマをベースに style.css などをカスタマイズしている場合は、必ずバックアップを取得する事。
バックアップせずにバージョンアップするとテンプレートも上書きされてしまいます。
まぁ、やってしまった本人が語っているので、間違いない。。。(T_T)
Web サーバのメンテナンスや整備で、phpMyAdmin のディレクトリを移動し、phpMyAdmin のログインからユーザ名とパスワードを入力し「実行する」をクリックした際、
エラーが出たためセッションを開始できませんでした。
PHP やウェブサーバのログファイルに出ているエラーを確認して、PHP を正しく設定してください
というエラーに出くわすことがある。
phpMyAdmin のディレクトリを移動する前はログインできていたのに、移動した途端に動かなくなった場合、cookie 内に保存しているセッションが不整合を起こしている可能性があり。
config.inc.php の中に
$cfg['Servers'][$i]['auth_type'] = 'cookie';
と設定している場合は、セッションは cookie に格納されている。
ただし、これでもエラーが発生する場合や、上記の場所とは違う画面や操作でセッションのエラーが発生している場合、php.ini の設定など別の問題が考えられるので、ググって確認するべし。