を、いまさらながら見つけた(2005年8月バージョン)。
この下の発言の中に、pdf へのリンクが張ってある。
ちなみに、英語のオフィシャルドキュメントは以下 URL。
を、いまさらながら見つけた(2005年8月バージョン)。
この下の発言の中に、pdf へのリンクが張ってある。
ちなみに、英語のオフィシャルドキュメントは以下 URL。
こんどは、PHP5.1.2 の fgetcsv() ではまった…
fgetcsv() で読み込もうとする csv ファイルの文字コードと、PHP の内部文字エンコーディングが違う場合、fgetcsv() で読み込むと、どうしても文字が腐る …
(PHP4 時代[少なくとも 4.3 系統は]は、問題なかった)
【以下みたいな場合】
で、試しに、CSV のエンコードを UTF-8 にして試すと、うまくいんだよなぁ。
色々調べると、PHP5 からどうやらロケール? に左右されるらしい… (参照URL: PHP-devML)
ただ、上記 ML のスレッドでも解決方法(いや解決してないようだが)を試しても、やっぱりダメ。
なら、PHP を ShiftJIS にすればいいじゃん!と思ったが、さすがにそれはプログラマとしてするわけにはいかない。
なので、そもそもバグなのかはわからないけど、いずれ修正されることを期待しつつ、今回も力業で取り急ぎの対処。以下、ソースコードと手順。
$buf = mb_convert_encoding(file_get_contents(“$CSV FilePath”), “utf-8″, “sjis”);
$fp = tmpfile();
fwrite($fp, $buf);
rewind($fp);
手順としては、
これでうまくいった。
コード+4行で動作するのならば、まーいいかな…とは思うけど、相変わらず泥臭い対処方法だと思う。
WordPress。いろいろいじっていたら、早くもはまる。
管理画面の中の WordPress URL 設定を、間違ってアクセス出来ない URL に設定…
(そしたらホントにアクセス出来なくなった!)
そこで焦ってしまい考えついた方法は、DB の直接書き換え。
WoredPress を設定した、MySQL の中を show tables コマンドで確認すると以下のテーブルがある。
まあ、この辺りは見るからに、wp_options がクサイので、そこから調べたらビンゴ。
色々調べていくと、wp_options は汎用的な作りになっていることがわかり、どうやら
option_id = 1 → WordPress URL
option_id = 40 → WordPress Blog URL
に URL が保存されていることが判明。
なので以下 SQL を直打ち。
(WordPress の URL と、Blog の URL が同じ場合)
UPDATE wp_options SET option_value = ‘<<正しいURL>>’ WHERE option_id IN (1, 40);
んで、書き換えられていることを確認。
SELECT option_id, option_value FROM wp_options WHERE option_id IN (1, 40);
その後、ブラウザから確認。
でも、なんと、それだけではアクセスが出来ない…
数分間悩み仕方ないので、ソース読み始めたところ、そしたらまあなんのことはない、WordPress の仕組みとして、DB の内容をファイルにキャッシュしていることがわかったのでその内容を手動削除。
(デフォルトのままだと、[InstallDir]/wp-content/cache/ 以下)
ふー、それでやっとアクセス出来るようになった。
それにしても、我ながら泥臭い方法すぎる。もっとスマートな方法が無いと復旧できない人いそう。
でも、そもそもこんなしょーもないミスする人なんていないような…
PHPでファイルを読み込む際、改行コードが、[CR]の場合、どうしてもうまくいかん…前はうまくいっていたのに。と悩むこと少々。
ちょっと検索かけたところ、マニュアルに記述発見。
どうやら、PHP自体の設定で、区分けしているようだ。
最近(それとも昔から?)は、わざわざ別設定として、読み込む際に、明確に区別していたんですね。
パフォーマンスの問題でしょうか?
ヘンなコード書いちゃう前に設定探せて良かった。
やはり、PHP はマニュアルがいい。
※ ちょっとテストも兼ねて以前別 blog に投稿していたのを再掲。