あせった…。
フォントビューアーからインストールしたからどこにインストールされたのか分からず…
ネット上には~/.font/にある的なことが書いてありましたが存在せず。
fc-list|less | grep Meiryo
したら出てきた
~/.local/share/fonts/の中にいた
中身を削除して
fc-cache -f -v
でキャッシュ更新しておk
あせった…。
フォントビューアーからインストールしたからどこにインストールされたのか分からず…
ネット上には~/.font/にある的なことが書いてありましたが存在せず。
fc-list|less | grep Meiryo
したら出てきた
~/.local/share/fonts/の中にいた
中身を削除して
fc-cache -f -v
でキャッシュ更新しておk
PHPをコマンドラインで実行しようとするとこういうのがたくさんでる
PHP Warning: PHP Startup: Unable to load dynamic library ‘/usr/local/lib/php/extensions/curl.so’ – /usr/local/lib/php/extensions/curl.so: cannot open shared object file: No such file or directory in Unknown on line 0
なんかないんだって。
curl.soはなんだか別の場所にあったから/usr/local/lib/php/extensions/にコピペしてみてもそれでもエラーがでた
そしたら
http://qiita.com/k_o_gj/items/01191e19cbda4a93ba58
にそれっぽいものが!
ソースから入れてたのにモジュールをyumで入れたからなんかおかしかったのかなぁ?
上記のサイトにあるようにphpizeをしようとしたら管理者権限の時だけコマンドが見つかりませんって出る。
そうじゃないときはちゃんと頑張ろうとしたけど権限ないよ!って言ってくれるのに。
そういう時ってなんかあった気がするけどコマンドまでのパス調べるの面倒くさかったのでパス直打ちで回避。
合ってるはずなのに…
JSON.parse: unexpected character at line 1 column 1 of the JSON data
ってひたすら表示される。
調べてみたらJSON.parseはjQuery1.4以降は使えない的な情報見つけたけどほんの数件しか出てこなくてよく分からず…
おかしい…
合ってるはずなのに…
動作確認でphp側に書いたprintも表示されない…
まさかphpファイルが読み込まれていない?
でもsuccess以下でconsole.log(‘a’);的なことしてみるとちゃんと表示される。
どういうこと?
散々悩んでそういえばphpの表示されないprintに気を取られてphpから返してもらったデータの表示は試みていないことに気づく。
1 2 3 |
success: function(data){ console.log(data); } |
すると返してもらったデータの手前にくっつく形で別の何かが表示されている‥
これは動作確認でphp側に書いてあったprintの中身…
ってところまで下書きしてて何言おうとしたのか忘れた…。
とりあえずprint消したら動いたぉ
WordPressのメディアライブラリに画像が表示されない、挿入出来ない、対処方法
を参考にしました。
wp-admin/admin-ajax.php
の
1 |
@header( 'Content-Type: text/html; charset=' . get_option( 'blog_charset' ) ); |
を
1 2 3 4 5 |
if(in_array($_POST['action'], array('query-attachments', 'send-attachment-to-editor'))){ @header('Content-Type: application/json; charset=' . get_option('blog_charset')); }else{ @header( 'Content-Type: text/html; charset=' . get_option( 'blog_charset' ) ); } |
にする
3日悩んだ。
.htaccessは
apacheの設定で
AllowOverride none
になってたりすると全てシカトされる。
なってました\(^o^)/
AllowOverride All
にしたら動きましたん。
ディスク空き容量がないらしい。
sudo apt-get clean
したらいけた。
GDが入ってなかったので、入れ方を調べてみたのだが
・yumでgd入れただけではうまくいかず
・php-common再インストールは避けたい
PHP再コンパイルしました。
Shinta’s s i t e様「PHPでグラフを作ろう! (gd/JpGraph編)」を参考に必要なものをまず入れる。
./configureのオプションに関しては
上記サイト様他
kishi-r.com様「phpでGDを使う場合のconfigure」
Home@けんどもネット様「PHP のコンパイル –with-gd」
など参考にさせていただきました。
過去にコンパイルしたときの./configureのオプションは
ソースディレクトリがある場所のconfig.nice、もしくはconfig.statusに書いてあります。
保存場所の所有者の問題だった。
chown -R apache:apache 保存場所
とかやったら出来た。
前回の続き
1 |
$str = mb_convert_encoding($_POST["test"], "UTF-8", "ASCII"); |
ってやっても表示が変わっただけで文字は化けたままでした。
「テスト」という文字が
テスト
ってなってました。
もしやと思い、HTML QuickFormを使わずに無事表示出来た方のHTMLソースを見てみると画面上では「テスト」と表示されているものが、ソースでは「テスト」と表示されていました。
&#から始まるこの文字列は文字参照というものらしいです。
1 |
$str = mb_convert_encoding($_POST["test"], "UTF-8", "HTML-ENTITIES"); |
こうするとちゃんと表示されるらしい。
でもこれじゃ確認画面でのフォーム内の文字列は変わってなかった。
おそらく、HTML QuickForm自身が中で保持してる値を弄ってあげないとダメなのかもしれない…
$form->applyFilter('__ALL__', 'Class_Name::method_Name');
で、Class_Nameというクラス内に作ったmethod_Nameというメソッドに要素全部飛ばして
1 2 3 4 5 6 7 8 9 10 11 12 |
public static function method_Name($str){ foreach($_POST as $key => $val){ if('text' == Option::$form->getElementType($key) || 'textarea' == Option::$form->getElementType($key)){ $el = Option::$form->getElement($key); $el->setValue(mb_convert_encoding($val, "UTF-8", "HTML-ENTITIES")); } } return mb_convert_encoding($str, "UTF-8", "HTML-ENTITIES"); } |
returnのとこのmb_convert_encodingやらないと全角カタカナで入力してくださいってルールに引っかかる。
フォームにはちゃんとカタカナで入力されてるように表記されてるのに…。
これでやっと動くようにはなったけど
このやり方が正しいとはとても思えない…w
散々調べてformでファイルとかアップするときのmultipart/form-dataでは文字コードの変換が行われないってのは分かったのですが
直らないんですよ。文字化け。
まずは文字コードを取得してみました。
mb_detect_encoding($_POST['hoge']);
UTF-8らしいです。
これは正しい。
それで文字化けしていると言うことは、本当は別の文字コードで表示するべきものを、UTF-8で表示しちゃってるから化けてるんだよね?
というわけで、私も皆さんに習って
mb_convert_encoding("文字列", "変換後の文字コード", "変換前の文字コード");
やってみました。
変換前の文字コードってなんだろ。
多分Shift-JISかな?
1 2 |
$str = mb_convert_encoding($_POST["test"], "UTF-8", "SJIS"); print $str; |
その結果表示されたもの
ッテッスット
うん、惜しいw
私が表示したい正しい文字列は「テスト」
なんか余分なものがついてるwww
皆これで直ってるっぽいんだけどなぁ…
とりあえず現状確認
print_r(mb_get_info());
結果
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
Array ( [internal_encoding] => UTF-8 [http_input] => ASCII [http_output] => SJIS [http_output_conv_mimetypes] => ^(text/|application/xhtml\+xml) [func_overload] => 0 [func_overload_list] => no overload [mail_charset] => ISO-2022-JP [mail_header_encoding] => BASE64 [mail_body_encoding] => 7bit [illegal_chars] => 0 [encoding_translation] => On [language] => Japanese [detect_order] => Array ( [0] => ASCII [1] => JIS [2] => UTF-8 [3] => EUC-JP [4] => SJIS ) [substitute_character] => 63 [strict_detection] => Off ) |
あれ?ASCII??
http_input が ASCII ってありなのかな?
調べてみたところ、php.iniの
detect_order = auto
ってなってると上の結果の配列の順番で文字コード選ばれるらしい。
確かに先頭配列にASCII入ってるわ。
こいつを
mbstring.detect_order = UTF-8,SJIS,EUC-JP,JIS,ASCII
書き換えてApache再起動
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
Array ( [internal_encoding] => UTF-8 [http_input] => ASCII [http_output] => SJIS [http_output_conv_mimetypes] => ^(text/|application/xhtml\+xml) [func_overload] => 0 [func_overload_list] => no overload [mail_charset] => ISO-2022-JP [mail_header_encoding] => BASE64 [mail_body_encoding] => 7bit [illegal_chars] => 0 [encoding_translation] => On [language] => Japanese [detect_order] => Array ( [0] => UTF-8 [1] => SJIS [2] => EUC-JP [3] => JIS [4] => ASCII ) [substitute_character] => 63 [strict_detection] => Off ) |
確かに配列の順番が変わった。
んだけどもhttp_input は ASCII のままだぞ?
いいのか?
試しにFORMタグに
accept-charset="ASCII"
を追加して
1 2 |
$str = mb_convert_encoding($_POST["test"], "UTF-8", "ASCII"); print $str; |
表示されました。
ちゃんとテストって表示されました。
でも、このフォーム、本来HTML QuickFormを使って作成しているのですが
それだと送信ボタンを押した後の確認画面でやっぱり文字化けしてました。