徒然なるままに

MariaDB＋PHPにて PHPでDB上のデータを大量に処理するプログラムを書いていて、おかしな現象に出くわした。 1万件＋42万件＋43万件のjoinで、必要なもののみ取り出して、updateをかけるという手作業ではやる気にならない処理なので、サクッと書いてぶん回すしかない…。 ローカルでmysqlモニタを使用してSQLを叩くと、問題なく結果が返ってくる。 でもって、サーバ上で実行すると、結果がEmpty…。 あれれ？ 試しに、phpmyadmin上でSQLだけ叩いてみる。 ローカルと同じ結果になる。 何かがおかしい。 　： 　： $mysqli = new mysqli("localhost",$username,$password); if($mysqli->connect_error){   print('<p>データベースへの接続に失敗しました</p>'.$mysqli->connect_error);   exit(); } $mysqli->select_db($dbname); $mysqli->set_charset("utf-8"); $sql="SELECT bill.bill_id,bill_item.bill_item_id,bill_item_detail.bill_item_detail_id,              bill.billing_id,bill.bill_month,bill.bill_date,bill.deposit_receive_date   FROM `bill_item_detail`   join bill_item on bill_item_detail.bill_item_id=bill_item.bill_item_id   join bill on bill.bill_id=bill_item.bill_id   WHERE `bill_item_detail`.`name` LIKE '繰越残高' AND 　： 　：   order by bill.bill_date"; $result = $m

WindowsでもLinuxでもMacでも使いたい 設定や、ソフト書いた時とか必要なツールはだいたい決まっている。 エディタにコマンドライン用の各種ツール…。 当然、好き嫌いはあるだろうし、良い物も使いにくいものもある。 その中でも定番なのは、lessやdiff、grepなんかは必須です。 でも、diffに関して言えば、GUIも使いやすのは事実。 WindowsだとExamDiffなんかはお世話になった。 UbuntuではMeldを使っていた。 Macは？ よく考えたら、Macでは使っていない。 Virtualboxを常備しているので、中のUbuntuで作業することが多いせいだろうか… 気になったので、調べてみた。 「ソフトアンテナブログ」の「 Mac用日本語GUI diffを検討する 」なんて記事があったので、参考に試してみる。 Xcodeは入れたはあるが、起動に時間がかかりすぎて、サッと使うには適していない。 しかも、日本語でエラーって…。この記事自体が2010年のものなので、今は改善しているかもしれないけれど…。 次に行ってみる。 DiffMerge も日本がダメらしい。 今度は、単純なツールっぽいので、試してみることに。 DiffMergeのサイトに行って、早速ダウンロードする。 スクリーンショットを見る限りは、良さそう。 アイコンが少しかっこいい。 起動してみると、画面はいたってシンプル。 アイコン左から、フォルダのDiff、ファイルのDiff、ファイルのmergeとこれだけ。 試しに、テキストファイルを食わせてみる。 問題なく、表示もいい感じ。 さて、日本語だけれど、デフォルト設定では文字化けする。 でも、環境設定を見ると、使用するフォントなどが選べるようになっているので、大丈夫なんじゃ？と思わせる。 設定を変えて試してみたら、ちゃんと日本語でもOKじゃないですか！！ 設定を変更したのは、文字コードと、使用フォントのみ。 まずは、一番上のDefault Rulesを編集する。 でもって、UTF-8を使うように設定する。 フォントは、好きな日本語フォントを選べばOK。僕はOsakaにした。

今さらEUC_JPって感じだけど すでにサーバ環境がUTF-8をデフォルトとするようになって、随分経っているので必要となるケースは少ないんだけど、今回はハマりました。 通常であれば、UTF-8でDBを構築していけば、特に問題もなく引っかかるようなところは何もないのだけれど…。 サーバの移行のため、仕方なくEUC_JPを使うことに。 旧データベースは、プログラムもEUC_JPで構築されている。 プログラムの書き換えは動作検証に時間がかかるので、そのまま動かしたい。 まぁPostgreSQLは文字コードを選べるので、問題ないだろうと…。 サーバにPostgreSQLをインストール これは問題なく、いつも通りapt-getで入れてオシマイ。 何も引っかかるところはありません。 ついでに、phppgadminも入れておく。 これで作業が簡単になる。 旧サーバにも入っているので、確認がしやすいですな。 若干、バージョンが異なっているので、その点だけ要注意と。 さてphppgadminを使ってDBをEUC_JPで作ろうとしたら、上手くいかない。 createdb: database creation failed: ERROR:  encoding EUC_JP does not match locale en_US.UTF-8 見慣れぬエラーですね…。しかもDBは作成してくれない。 何か操作を間違えたのかと、見直すが、特に手順に問題はない。 「ERROR:  encoding EUC_JP does not match locale en_US.UTF-8」でググってみると 、最初に答えが見つかった。 「 名称未設定：Ubuntu12.04LTSのPostgreSQLでEUC_JPのデータベースを作る 」とまんま同じ内容だった。 これによると、 createdb -T template0 -E EUC_JP --locale=C dbname と、localをCで作りなさいということらしい。 試しに、コンソールから試してみると、確かに文句も言われず作成してくれる。 phppgadminでもできるはず  この方法は、postgresユーザで作業するコンソ

文字コードではまる wordのデータを整形して、csvにして欲しいと頼まれた。これ自体無茶な話しではあるんだけれど…。リストになっているものを表形式に…。 とりあえず、テキストエディタにコピーして、正規表現で何とか整形する事ができた。 作業は全てUTF8で行っていた。 さて、そのデータをExcelに貼り付けて、カラム数が合っているか等チェックして、CSV形式で保存した。 ここに、失敗があった。word→テキストエディタは意識して文字コードutf8を気にかけていたものの、Excel→CSVの確認を忘れていた。 officeは内部コードをUTFで処理するようになったというのが、変に意識に残っていたのかもしれない。 cp932では表現できない文字コードが含まれていたため、後の処理で引っかかってしまった。 ExcelもCSVで保存する時に、そういったメッセージは出ないしなぁ。 エディタで、特定の文字を置換して切り抜けましたゎ～