「PostgreSQL9.1に更新」の結果

旧データベースサーバーは

2006年12月
パソコン工房　BTO MT518X2（OSなし）86,980円
CPU AMD Athlon64 X2デュアルコア・プロセッサー3800++/2.0GHz/L2chache 512KB X2
メモリー　DDR2 667 2GB X2
チップセット　NVIDIA Geforce6100
ハードディスク　200GB 7200rpm ATA

新データベースサーバーは

2011年12月
DOS/Vパラダイス　　Prime Magnate IM （OSなし）42,980円
CPU　インテル Core i5-2400 (クアッドコア/定格3.10GHz/TB時最大3.40GHz/L3キャッシュ6MB)
チップセット　インテル H67 Express チップセット
　　　　　マイクロATXマザーボード (不具合対策済み B3 Stepping チップセット)
メモリー　4GB DDR3 SDRAM(PC3-10600/2GBx2/デュアルチャネル)
ハードディスク　500GB HDD

５年経って随分、安くなったもんです。スペックは倍、価格は半分です。

特にこれといった問題もなく運用していますが、スピードは前回更新した時（約３倍速くなった）ほどの効果はありませんでした。サーバーと同じフロアのPCについては、使用感はほぼ変わりません。PostgreSQLのダンプが速くなったくらいです。ただ、VPN経由でサーバーに接続しているPCについては、伝票更新が速くなりました。どこがボトルネックなのかよくわかりません。

今日から運用、やはり外字が

今日からCentOS6.2＋PosgreSQL9.1.2の運用開始です。Solaris10+PosgreSQL8.1のダンプデータがあっさりリストアできたので、問題なく運用できるのかと思っていましたが、やはりトラブルが。
以前、PostgreSQL8.1のデータを8.2にリストアしようとして外字が原因でうまくいかなかったことがありました。

http://blog.goo.ne.jp/mach5481/e/02610f4f7031fbc9eddbe1ab2d10c4c6
http://blog.goo.ne.jp/mach5481/e/358bfa26b970fe8f4293254a9ac80c2a

その時はリストアそのものができなかったのですが、9.1.2ではリストアできるのですが、外字を含んだテーブルをAccessで表示させようとすると、文字バケしたり、ODBCエラーがでて、Accessが落ちてしまいます。やはりWindows95時代に登録した外字が原因です。

結局、上記ブログで書いたように

/usr/local/src/postgresql9.1.2/src/backend/utils/mb/Unicode/euc_jp_to_utf8.map

に外字の変換データを追加してmakeし直さなければなりませんでした。
一応、下記を追加しました。

{0xf5a1, 0xe282ac}
{0xf5a2, 0xe282ac}
{0xf5a3, 0xe282ac}
{0xf5a4, 0xe282ac}
{0xf5a5, 0xe282ac}
{0xf5a6, 0xe282ac}
{0xf5a7, 0xe282ac}
{0xf5a8, 0xe282ac}
{0xf5a9, 0xe282ac}
{0xf5aa, 0xe282ac}
{0xf5ab, 0xe282ac}
{0xf5ac, 0xe282ac}
{0xf5ad, 0xe282ac}
{0xf5ae, 0xe282ac}

外字をユーロ記号に変換しています。外字はミリリットルとかリットルなのですが、今となってはどのコードがミリリットルなのかわかりません。なので、全てユーロ記号に変換しました。実際、ユーロ記号が表示されていれば、それが何を意味していた外字だったか判断が付くので、その時々に直せば良いと思っています。

上記データを含んでmakeしなければならないのですが、以下その手順です。

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
既に一度、上記変換デーブルを含まない形でmakeしているものとして、２回目にmakeする場合の手順。

１．/usr/local/src/postgresql9.1.2/src/backend/utils/mb/Unicode/euc_jp_to_utf8.mapの編集
EUC_JP側のコード順に上記データを追加。
２．postgresで
$ cd /usr/local/src/postgresql9.1.2/src
$ ./make unintall
$ ./make clear （これがないと、修正後の変換テーブルを参照しない）
$ ./configure
$ ./make all
$ ./make install

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
もし、一度もmakeしていない状態から行うなら、

euc_jp_to_utf8.map編集後、

$ cd /usr/local/src/postgresql9.1.2/src
$ ./configure　（オプションなし）
$ ./make all
$ ./make install

環境設定を/home/postgre/.bashrcに追加
PATH="$PATH":/usr/local/pgsql/bin
export POSTGRE_HOME=/usr/local/pgsql
export PGLIB=$POSTGRE_HOME/lib
export PGDATA=$POSTGRE_HOME/data
(manは入っていなかったので省略）

$ source /home/potgre/.bashrc
$ initdb --encoding=EUC_JP --no-locale

後は自動起動設定、pg_hba.confの編集、postgresql.confの編集
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

今後、元データに外字コードが含まれているので、PostgreSQL更新時には必ず、上記作業が必要になります。
面倒なら、あっさりUTF8に移行するしかないのですが。

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
＜続き＞ (2012/1/13)
今度はクライアント側でユーロ記号が含まれているレコードは更新できないというエラーが。

「UTF8の『0xe282ac』が変換できない！」と言ってきます。

PostgreSQLのmake時に「euc_jp_to_utf8.map」に外字を追加したように「utf8_to_euc_jp.map」に

{0xe282ac, 0xf5a1}

といったようなmapを追加してやらなければならないのかもしれません。
そのためには、また、また、データベースを止めてPostgreSQLのmakeをしなければならないのですが、そう止めてもいられないので、このODBCエラーが出た時は外字を一個づつ修正しています。

ScanSnap S1500を買ってしまった４

８．雑感
以前は一週間に一度は本屋に行っていたと思いますが、最近はせいぜい月に１回行くかどうかです。そんな状態なので本屋で本と買うということがありません。他の品物にしてもそうですが、買い物はほとんどネットです。本はAmazonで新本、中古本を買います。
ネットで買う本の冊数を加えてみても、本の購入数は非常に減りました。昔はパソコン関係でわからないことがあれば、本屋に行って参考になる本を買いました。文庫本と違って、技術本は結構高いので随分財布が痛んだものです。現在はわからないことがあれば、ネットで調べるので全く技術本は買わなくなりました。新しいことを学習なくなったということもあります。
また、昨年５０歳になりましたが、認めたくないにしても徐々に老眼が入ってきて、小さな文字を読むのが何となく苦痛になってきました。それでなくてもド近眼なのに、大金をかけて遠近両用メガネを作る気にもなりません。ということもあって楽しみとしての紙製の本での読書とはトンと遠ざかっていました。読んでも携帯電話でZBF形式の電子ブックを読む程度でした。なので、読みたい本がZBFファイルで提供されていないという状態になってしまった時、本当に困りました。全く本が読めない、読む本がない。
そんな状態で藁にもすがる思いで買ったのがiPhoneでした。しかし、実際にiPhoneを使ってみると、購入した電子ブックは使い勝手がよくありませんでした。iTunesに接続して更新する度にシオリの位置が変わってしまい、読んだところまで戻るのが面倒だったり、文字の大きさが小さめだったり。iPhoneはZBFファイルが表示できないのが本当に痛かった。
そんな最中に 週刊「碁」のiPad用が発売されました。中古のiPadを買って週刊「碁」の方は十分楽しめました。今度はiPadで電子ブックを読んでみました。もちろん文字の大きさは問題ありません。十分大きくなります。こうなると、いろんな本をiPadで読んでみたくなります。
いざ、読みたい電子ブックをネットで捜してみると、ほとんどありません。漫画はかなり充実しているのですが、例えば「眠狂四郎」シリーズを読んでみたいと思っても、電子ブックはありません。文庫本は持っているのですが、文字が小さすぎて今となっては読めません。
昨年(2011年)は電子ブック元年と言われていたように思いますが、相変わらずこれといった進展がみられなかったように思います。少なくとも個人的には電子ブック環境が改善されたとは思えません。仕方なく自炊することになりました。
現在のような出版業界の電子ブックの取り組みははっきり言って自殺行為ではないかと思います。購入したい電子ブックが無い。団塊の世代が高齢化して読書をしようにもタブレットPCで読む電子ブックがない。せっかく延びるはずの市場が育っていません。著作権の問題はもちろん大きいですが、発行した電子ブックに購入者の識別コードを付加するだけで十分なコピーガードができるのではないかと思います。ebookjapanのような完全な管理は普及を妨げていると思います。

ScanSnap S1500を買ってしまった３

６．読むのはiPadとiPhone
スキャンした電子ブックを読むのは、iPadとiPhoneです。
当初はスキャンした文庫本はiPhoneで読もうと思っていましたが、一頁全体を画面に表示してしまうと、文字が小さすぎて読めません。文庫本の大きさはiPhoneより大きいので、こうなってしまいます。文字の大きさを大きくして一行を読むのにドラッグしながら、行を送っていくのは面倒なので、文庫本の読書にはiPhoneは向いていないと思います。iPad程度の大きさがあれば老眼の入った目にも優しい。
自炊した電子ブックをiPhoneで読むか、iPadで読むかは一行の文字数によります。文字の大きさはピンチアウトすれば調整できるので、あとは読書中にいかに作業を少なくできるかです。iPhoneで一行読むのにドラッグしなければならないようなら、その電子ブックはiPhoneでは実際的に読めません。
スキャンした本の一行の文字数を調べてみると、

文庫本　　　　　　　４３文字／行　　　iPad向き
一頁２段組の単行本　２９文字／行　　　iPad向き
一頁３段組の単行本　２１文字／行　　　iPhoneでも読める

ちなみにiPhoneアプリの「産経新聞」は１５～１６文字／行です。
読むのに苦にならない文字の大きさは個人差があるので何とも言えませんが、私の場合一行２０文字が一応の目安になるのではないかと思っています。
iPhoneアプリ「産経新聞」は当初、「iPhoneの小さな画面で新聞の大紙面が読めるわけがない！」と思っていましたが、実際に読んでみると結構読みやすい、文字が大きくなる分、紙製の新聞より読みやすい。購読している毎日新聞をやめてしまおうかと思いました。（妻が「ダメ！」っていうので購読していますが、女房がスマートフォンにするようなら、本当にやめてしまいます。一番良く見るテレビ欄は地デジになってテレビ画面で確認できるので、新聞のテレビ欄は必ずしも必要ありません。）
新聞の場合、見出しの文字が大きいのでiPhoneの小さなディスプレイで全画面表示しても見出しは読めます。ねらいをつけてピンチアウトすれば、一行１６文字程度なので、一行が余裕をもって画面に治まります。特に新聞の場合、一段の行数が多いので、次の段に行く回数が少なくなり、特に読み易いです。チョコチョコ、チョコチョコ読んでいると、いつの間にか一ページ全部読んでしまっていて、紙製の新聞よりよく読んでいます。

７．裁断機について
自炊セットには裁断機が含まれていることが多いです。しかし、裁断機は結構高い。３万円くらいでしょうか。私は裁断機は必要ないのではないかと思います。
実際、非常に厚い本は予め分割しておかなければ裁断機でも背中をカットすることはできません。また、留め金で裁断機の刃をダメにしてしまったという、記事もネットで見ます。
背中のカットはカッターナイフで十分ではないかと思います。ただ、手を切ってしまわないようにしなければなりません。私の場合はステンレス製のＬ形アングルを使用しています。アングルの縦の部分が手を保護してくれます。
Ｌ形アングルを使用して問題なのは、手を保護してくれるアングルの縦部分が邪魔をしてカッターの刃が本に対して直角に当たらないということです。厚手の本だと斜めに刃が入ってしまうので、本の下側は背中からかなり内側に入ったところでカットしてしまいます。なので、裁断機を使用する場合以上にカットする本の厚さを予め薄めに分けておかなければなりません。
その点を考慮しても、裁断機とカッターナイフの価格を考えると、やはりカッターナイフを使用した方が良いのではないかと思います。カッターナイフの場合、結構、刃先がなまってくるので、余裕をもって刃先を割っていった方がいいです。刃がなまってくると、うまく切れなくなって、カット線が汚くなってしまいます。

ScanSnap S1500を買ってしまった２

４．私の「Scanボタンの設定」は
本には文字だけのページもあれば、白黒の写真があったり、図があったりします。また、表紙もあるので、一つのスキャンモードだけでは思ったような画質が得られません。なので、ページ、ページでスキャンモードを変更しています。これは結構面倒だけど、仕方ないです。
私の場合は次のような設定でスキャンしています。
「クイックメニューを使用する」にチェックを入れて、「カスタマイズ」で使用します。
「オプション」は「文字をくっきりにします」と「白紙ページを自動的に削除します」にチェックを入れています。「白黒読み取りの濃度」は「標準」。（あれ、「文字列の傾きを自動的に補正します」と「原稿の向きを自動的に補正します」のチェックをはずしてる？）

（１）通常の文書
画質の選択：「スーパーファイン（カラー／グレー：300dpi、白黒:600dpi相当）
カラーモードの選択：　「白黒」
読み取り面の選択:　「両面読み取り」
継続読み取りを有効:　チェック入れる
（２）白黒写真、図
画質の選択：「エクセレント（カラー／グレー：600dpi、白黒:1200dpi相当）
カラーモードの選択：　「グレー」あるいは「白黒」
読み取り面の選択:　「両面読み取り」
継続読み取りを有効:　チェック入れる
（３）表紙
画質の選択：「エクセレント（カラー／グレー：600dpi、白黒:1200dpi相当）
カラーモードの選択：　「カラー」
読み取り面の選択:　「両面読み取り」
継続読み取りを有効:　チェック入れる

当面、「画質の選択」「自動」は使用していません。
カラー写真は今のところ、スキャンしたことがないのですが、表紙は最高画質でスキャンしています。

５．Adobe Acrobat 9 Standard
私が購入したのは、現在販売されているS1500Aの一つ前の型番なので、標準添付されているAcrobatは「9 Standard」でした。S1500Aは「Adobe Acrobat X Standard」が添付されています。
「9」と「X」の違いはよくわかりませんが、今のところAcrobatは「結合」「ファイルを単一のPDFに結合」くらいしか使用していないので、あまり有効に使用していません。「OCRテキスト認識」機能を使用していないのでPDFの特徴を生かした使い方をしていないといえます。
まあ、読んで、GoodReaderでチェックラインを入れる程度の使い方なので当面これで良いかと思っています。
スキャン後、「表紙」「白黒写真」「通常文書」などを結合して電子ブックの完成です。