2013年8月27日火曜日

php fputcsvを使わないでCSVファイルをダウンロードする

自サーバでDBのでーたをCSVファイルにしてダウンロードするロジックを検証していました。

(WordPressのプラグインを利用しています。)

(トラブル現象)
1、3件出なければいけないところ、2件しかCSVファイルに出てこない。
2、CSVファイルの見出しのひとます目に「・ソ」「x'EFBBBF'」が入り、文字化けした。

(原因)
1、については、レコードは三件きちんとデータとして吐き出されている。しかし、一番最後のレコードの一番最後のアイテムのデータが壊れていることが分かりました。

2、については、ファイルの先頭三バイトに「x'EFBBBF'」が挿入されていてこれがもとで最初のアイテムが文字化けしてしまっていることが分かりました。この三バイトがどこでセットされているかは、推測ですが、アウトプット・バッファーにデータをfputcsvしたときでは?と思います。

※この三バイト「x'EFBBBF'」は後にBOM付きUTF-8ファイルと呼ばれる品物であることが判明。


(対応)

1、CSVの項目の区切りを「”」、各項目ごとの区切りを「,」にして変換しているロジックを
mb_str_replace()を使ってコンバートする。
※mb_str_replace()は、予め、ダウンロードして、稼動DIRに設置しておく。

2、アウトプットバッファーのクリーニングを、ob_end_clean()を使ってお掃除した上で
fwrite()を使ってファイルプットする。

3、CSVデータ1レコードの終わりに改行コード\r\nをつける。

4、fputcsvとmb_str_replaceを参考に問題プログラムを修正する。

修正コードCSVレコードGenerate部分

function prv_fputcsv($fp, $data, $encoding="") {
 require_once 'mb_str_replace.php';

 $csva = '';
 foreach ($data as $col) {
  $col = mb_str_replace('"', '""', $col, $encoding);
  $csva .= "\"$col\",";
 }
 fwrite($fp, "$csva\r\n");
} 

ファイルダウンロード部分

     
$file_size = @filesize($full_file_name);
     ob_end_clean();
     ini_set("zlib.output_compression","0");
     header("Pragma: public");
     header("Expires: 0");
     header("Cache-Control: must-revalidate, post-check=0, pre-check=0");
     header("Cache-Control: public");
     header("Content-Type: text/csv");
     header("Content-Disposition: attachment; filename=".$file_name);
     header("Content-Length: ".$file_size);
     @readfile($full_file_name);
     @unlink($full_file_name);

このように、二箇所の修正を行いました。

(結果)

前出のトラブル現象はずべて解消しました。

めでたし、めでたし。

※ソースの部分に、SyntaxHhgilighterを当ブロガーに導入しました。
 導入方法は追ってアップできればと思っています。

2013年8月18日日曜日

XAMPP 1.7.7 MySql 文字コードセットをUTF-8に変更する方法

文字コードの設定は重要です。

クライアントサーバ間の文字のやり取りをする場合、文字化けの虞のある場所です。

そこで、私の使っているXAMPP1.7.7のMySql設定を確認することにした。

コマンドプロンプトからMySqlにログインし、

mysql> show variables like 'char%';

を入力すると



このように、

character-set-client = cp932
character-set-conection = cp932
character-set-database = latin1
character-set-server = latin1
character-set-system = utf-8

ばらばらな文字コード設定になっていました。

そこで、この文字コードをUTF-8に統一することになりました。

変更方法は、MySqlの設定ファイル、My.iniに下記を設定することにより行います。

[mysqld]
skip-character-set-client-handshake
character-set-server = utf8
collation-server = utf8_general_ci
init-connect = SET NAMES utf8

MySql,Apacheの再起動を行い、先ほどのコマンドを入力すると変更結果が得られます。


character-set-client = utf-8
character-set-conection = utf-8
character-set-database = utf-8
character-set-server = utf-8
character-set-system = utf-8

このように、すべて、UTF-8に設定されました。

多くのブログに掲載されている、「default-character-set=utf8」を、My.iniの[mysqld][mysql][client][mysqldump]に設定する記述に応えてそのまま設定すると、MySqlが動きませんでした。

この、パラメータはxampp MySqlには使えません。


2013年8月9日金曜日

WordPress 固定ページ編集で、HTTP304発生

昨日まで編集できていたWordPressの固定ページの編集が、今日、いきなり、できなくなっています。


編集窓に変更を加えた後、更新ボタンを押すと、サーバーからアクセス拒否を表す、HTTP403

が返されてきます。

昨日、何やったかな?

1、変更をいっぱいくわえたので、WordPressのDBバックアップ、ファイルバックアップを実施。
2、レンタルサーバにある機能で、「WAFセキュリティー」設定を全部セット
  (XSS対策、SQL対策、ファイル、メール、コマンド、PHPの各対策)

この二つくらいでした。

具体的にどのような症状かというと・・・・

A.管理画面の固定ページを編集画面で特定のページは、更新ボタンを押すと、編集していても、い なくても、HTTP403が返される。

B.他のページは、編集していても、いなくても、更新ボタンを押すと更新できる。

A.について編集窓には、<iframe>タグを用いた記述をいている。
B.については、普通の文字列のみの記述をしている。

こんな感じでした。

まず、昨日行った「バックアップ」にエラーがないかログをチェックしたところ、DB,
FILE共にNORMAL ENDしていて特に問題となるようなことはありませんでした。

次にやったWAFセキュリティー設定。

これは、サーバー管理ツールのWAF設定の画面に行って、説明書きをよーく読んでみました。

-----------------------------------------------------------------
■ 検出時に動作について

検出された場合には、アクセスが拒否されエラーページが表示されます。
----------------------------------------------------------------

と書かれていました。

これって

HTTP403

のことだよね。

うんうん。

さっさとWAF設定を全部解除設定にしました。

暫くして、Aの編集は、滞りなく編集できるようになりました。(汗)

今回の場合、XSSの設定だけはずせばいいと思いましたが、念のため全解としました。

開発中は、こんなもの設定しないほうが良いですね。




2013年8月7日水曜日

WordpressにIE安全じゃないよ!と怒られる-IE10なのに・・・

Wordpressで開発していますが、突然、管理画面のダッシュボード画面に赤い警告が出ました。

------------------------------------------------------
お使いのブラウザは安全ではありません!


Internet Explorer の安全ではないバージョンをお使いのようです。
古いブラウザを使っていると、コンピューターを危険に曝してしまいます。
WordPress のすばらしさを実感するには、ブラウザーを更新してください。


Internet Explorer をアップグレードするか ブラウザの選択肢を知る
Browse Happyサイト を訪れてみてください。


非表示にする
-------------------------------------------------------

こんな文言が入っていました。

おかしいな?

IE10なのに・・・

それと、テンプレートとか崩れていることも発覚。

パンくずリストも、「○○>■■>△△」というように横並びに表示されるはずが、

「○○>
■■>
△△」

このように、縦になっている。

そこで、

Google先生にお尋ねしてみました。

「wordpress ie10 安全ではない」

すると、

シロップ さんのパソコン修理日誌パソコン修理日誌にたどり着きました。

中身を拝読すると

むむむ!

おんなじ現象あるね。

解決方法は、なんと、IEのアドレス窓に虫眼鏡、南京錠、紙がち切れたイメージとリロードマーク
が並んでいるうちの

「紙がちぎれたイメージ」

これが原因でした。

現状、「青くなっている」

これをクリックすると

あら不思議

私意図したもとの状態に戻っているではありませんか。

これを押すと互換表示されるようです。

あまり深い意味は探りませんでしたが、不具合解消ということで

先に進むことにしました。

シロップ さん、感謝です。(^^)

2013年8月1日木曜日

SSL環境下でWordPressの管理画面、ログイン画面を使う

SSL環境でWordPressを運用するには、公開ページに対してSSL運用が可能となって

ホットするのもつかの間で、ログイン画面、管理画面に入れなくなります。

私、あせりました。

そもそもの間違いは、SSL申請中にWordPressを導入し、チョコチョコイジッテイタこと

でした。

WordPressの導入時は、http://example.comで運用中で、何の問題もありませんでした。

しかし、SSLの申請上、WWW.あり、なしを決定したり、.htaccessの設定を変えたりで

サーバーの環境が刻々と変わり、挙句、SSL用にIPが変わった。

(1)www.wxample.com IP:nnn.nnn.nn.nn

(2)example.com       IP:mmm.mmm.mm.mm

となっていました。

まづこれを上の(2)のIPを(1)のIPに合わせるようにDNS設定を変更する。

次に、WordPressのインストール先をexample.comだったのでwww.example.comにするため、

一度

WordPress本体をサーバーからUninstallする。また、MySql DB を削除する。

こうして、サーバーからWordPressとMySqlを削除した上で、再度WordPressをインストールする。

(DBも新規作成したうえで)

こうして、作成しなおした環境下で本題の「WPのログイン・管理画面をSSL環境下で稼動するよう設定変更を行う」

これを実現するには、WordPressの環境設定ファイル「wp-config.php」を修正する。

サーバのドキュメントルートし下にWordPressを導入した場合

www.example.com/

以下に当該ファイルは存在するはずです。

このファイルの適当な箇所に以下のパラメータを設定することで、うまくいきました。

--------------------------------------------
/** SSL ログイン・管理画面アクセスを強制する */
define('FORCE_SSL_ADMIN', true);
--------------------------------------------

この環境変数設定は、管理画面、ログイン画面に対し、強制的にSSLアクセスする
パラメータです。

このほかにログイン画面だけ強制的にSSLアクセスするパラメータがあります。
-------------------------------------------
define('FORCE_SSL_LOGIN', true);
-------------------------------------------

参照

http://wpdocs.sourceforge.jp/Administration_Over_SSL

やっと、SSL環境下での開発が始められます。