2012年02月23日
サーチエンジン雑感[ ]
自宅サーバーのデータベースバックアップをautomysqlbackup.shを使用して行っている。
これは、linuxの環境を限定せず様々な環境でバックアップできる良質なデータベースバックアップツールだと思う。
この、automysqlbackup.shであるが、当方が使用しているのは、version 2.5 - (2006-01-15)バージョン(バグ持ちを自分で修正して使用)。
気がつけば2010年から開発が再開されていて、configファイルと実際のシェルが分割されたりしていて、より使いやすくなっている様だ。
このツールは全て英語のツールで、そんなにconfigの設定も難しくないのであるが、今のバージョンは一部のライブラリ(bcコマンド)が入っていないと動かないこともある様だ。
参考記事：MySQLのバックアップで便利な「AutoMySQLBackup プラスター業務日誌 PLUS STARさん より
この記事を見かけて、触らぬ神に祟りなしとばかり、ソフトのバージョンアップをあきらめたのは、過去に某企業でCADのサポート業務を行っていての経験によるものである。
企業としては新バージョンを売る(バージョンアップさせる)事こそ、お金を稼ぐための至上命令なのだが、新バージョンになる度にバグによりトラブルが発生する。そんな顧客を見ていて、もどかしい気持ちに襲われたものだ。
サポートとして本当は新バージョンを勧めたくない気持ちがあるのにも関わらず、今度のバージョンはこんなに便利な機能は追加された…と案内する。
確かに便利になった…のかも知れないが、今問題なく使えているのならば、焦ってバージョンアップする必要はないのだ。
特に、automysqlbackupの様に、他に追加の機能も要らないプログラムは更新する必要性というものは本来的にはないと思う。
ちなみに在籍していた会社ではレベルアップとバージョンアップの意味は明確に分かれていて、レベルアップ＝無料、バージョンアップ＝有料というものでした。
さて、話を戻して、サーチエンジンで「automysqlbackup 設定」のキーワードで検索してみると…
出てくる情報が古い。2010年より前の情報ばかりで、現在のバージョンの設定方法と言うのは検索結果上位にはあまりない。
新バージョンが出ている世で今更旧バージョンの設定の方法を知っても…ねぇ。。。
記事にされないから検索順位が上がらない…と言うのはあるのだけれど、サーチエンジンとして、それはどうなのよ？と。
最近思うのだが、サーチエンジンの検索精度って落ちてないですか？
ブログやらSNSやらツイッターやらが流行って、情報が分散化している時代と言うのは分かるのだが、それでも使える情報にたどり着くのに技量を要する時代になってしまった感がある。
最新の情報が必要なものと、普遍的な項目とそれぞれ情報の鮮度を意識した検索結果にはならないものだろうか。
そうそう、うちのメインサイトも、サイト名を使わないとググれない状態。たぶん、サイトとしてはもっともサーチエンジンと相性が悪いサイト。
でも、そんな状態なのに訪れる人がいるというのは不思議なことだ。
そういえば、ここの所、UFT-8の文字化けの定番項目である「チルダ」「波ダッシュ」について調べていた。
たまたま、テスト環境のデータベースが古くなり、上記のautomysqlbackupで作成していたdumpをテスト環境(http://test.anison.info/)に反映させようとした時のことだが、本番環境とテスト環境でデータベースのデータベース名(＝ユーザー名)が異なっており、一回、dumpのデータに手を入れて、データベース名を修正する必要があった。
この際、sakuraエディタで表示すると「波ダッシュ」の部分が化けていた。そのまま、データベース名だけ修正して、dumpを復元したところ、当然ながら「波ダッシュ」部分は文字化けのまま登録されてしまった。
色々と悩んで、データベース中の「波ダッシュ」を別の文字に置換するプログラムまで作ったが、どうも釈然としない。
何より、linux環境でviコマンドを使用して、データベース名を置換すると、問題のない綺麗なdumpが作られる。
「mysqldump 文字化け」と言ったキーワードで検索すると、データベースの文字コードがlatin1になっているため文字化けする…という様な記事がヒットし、その対処とするとmysqldumpのパラメータに
しかし、このパラメータを追加しても結果は同じであるし、「--default-character-set=latin1」としても結果は同一だった。
そもそも、dumpを見ると文字コードは「utf_unicode_ci」であることが明記されており、文字コードlatin1を使っている訳ではない。
もっとも、mysqlからstatusコマンドを叩いてやると文字コード「latin1」と表示されるので、この辺りも悩んだ理由の一つ。全体の文字コードの初期値として「latin1」が設定されていた様だが、個々に作成したデータベースは「utf_unicode_ci」という事であり、この辺りも原因を曖昧にする一因となっていた。
この文字化けに関しては、結局はsakuraエディタのバージョンが古くて、
sakuraエディタは1.x系でも、UTF-8を扱えるという事がうたい文句の一つだったのも盲点である。いやはや、文字コードの扱いは難しい。
さて、この問題を扱っている際に、文字化けするのであれば、そもそもそのデータを使わない方がいいのではないか？と考え、mysqlで「波ダッシュ」を置換しようとも試みた。
ブラウザ上で「波ダッシュ」は表示されるものの、これを(旧バージョンの)sakuraエディタや、phpエディタにコピペすると文字化けしてしまい、検索文字列として扱うことがそもそも出来なかったため、文字コードで文字を指定して「波ダッシュ」を検索しようとした。
そこで、サーチエンジンで「mysql 文字コード 検索」等と検索したが、mysqlのデータベースの文字コードを何にするか…という話ばかりで、文字列をコードで検索する方法は分からなかった。
結局のところ、phpの文字列変換の関数から調べていてようやく、
一応、波ダッシュ等、特定の文字を別の文字に置換する汎用スクリプトが組めたので、よしとしている。使用はまだしていない。
それにしても、なんだか最近、結果にたどり着くのが遅くなった感がある。
サーチエンジンの劣化も進んでいるが、私自身の劣化も進んでいるようだ…