☆ A M B ☆
☆ A M B ☆
検証ありがとうございますー。ちょっと安心。今日の夜にでもパッチ一式を提出してみます。
関係有りそうなアクションは一通り試したつもりですが、特に文字化けはありませんでした。
DBの中も一通り覗いてみましたが、正常な日本語で表示されています。
言ってみるもので、チカッパに関しては僕が報告を入れた数日後に対応いただけました。今後立ち上げる新サーバに関しては適切な設定を施すそうです。だけどそれでもまだ文字化けが発生する箇所が実際あって今回のパッチを作っているので、collation以外にも合わせるべき箇所がまだあるみたいです。実際、MySQLの設定値の一覧を見てみると、デフォルトで「latin1_swedish_ci」になってる箇所が他にもいくつかあります。xreaの場合はきれいにutf8やunicodeで揃ってるのですが。collationだけならphpMyAdminを使ってユーザがデフォルト値を変更できます。
そうですね～ 特にMySQLサーバ自体のcollation(MySQL自体の設定ファイル(my.cnfでしたっけ?)に記述しなければならない設定)がデフォルトのままだとlatin1_swedish_ciだったりするんで、そこはユーザーからは触れなかったりしますもんね。ユーザーが声を上げて指摘するしかないですね～ まぁ、MySQLのバージョン自体が未だに4.0系だったりするところも多いですから...
強めにしつこく主張していくしかないみたいですね。どうも、英語圏の人相手には強めに主張してちょうどいいくらいのようですが。開発チーム自身も文字化け対応には真剣に取り組んでいて SET CHARACTER の組み込みにも手間をさいているのだろうし、文字化け対応大国の日本ユーザの声にもう少し耳を傾けてもらえるといいなと個人的には思います。
私もそう思います。けど、26文字のアルファベットで事足りる世界の方々にそれがご理解頂けるのかな～?
おしいっす、このイベント テンポラリーファイルから実際のファイルに移動した後で呼ばれてるんで・・・。
アップロードファイルの日本語ファイル名については、僕はNucleusではtime( ).jpgなどに
置き換えるアプローチをファイルマネージャに組み込んでます。サムネイルが表示されるので
ファイル名はどうでもいいんじゃないかと思えるし、実際、大手のレンタルブログサービスでは
ファイル名を出さなかったりしますよね。htmlのソースでのぞいてみるとハッシュ値っぽい
ファイル名になってたりしますが。
これってシステムイベントOnFileManagerUploadあたりを使って、処理をプラグイン化できないかな？
アップロードファイルの日本語ファイル名については、僕はNucleusではtime( ).jpgなどにアップロードファイルの日本語ファイル名を日時やハッシュ等に変換する件ですが、
置き換えるアプローチをファイルマネージャに組み込んでます。サムネイルが表示されるので
ファイル名はどうでもいいんじゃないかと思えるし、実際、大手のレンタルブログサービスでは
ファイル名を出さなかったりしますよね。htmlのソースでのぞいてみるとハッシュ値っぽい
ファイル名になってたりしますが。
☆ A M B ☆
☆ A M B ☆
イベントを追加するのって、簡単にできそうでしょうか。開発チームに提案するのもいいかなと思ったので。
おしいっす、このイベント テンポラリーファイルから実際のファイルに移動した後で呼ばれてるんで・・・。
このイベントの上の方にある
move_uploaded_file($userfile[’tmp_name’], $_POST[’path’]."/".$userfile[’name’])
の$userfile[’name’]をやまさん式の日時.xxxに変えちゃえばいいんですけどね
☆ A M B ☆
そもそも、FileManagerって何のためにあるの? ってところが定まってないような気もしますが、私個人としては、スニペットがIncludeするファイルや言語ファイルなどをちょこまかと直す時に使ってます。ですので、ほぼ100％がmodxのエンコーディングと同じエンコーディングが必要です。UTF-8で運用していて、EUCなファイルを書き出したいというケースはまずありません。このあたりが違うと、人によって求められる機能も違ってきちゃいますよね～
ファイルマネージャーについてのベストソリューションってどうなるでしょうか
あとは、書き出しの処理が必要ですね。元々のエンコーディングを記憶しておいて、Web画面上での修正結果をこのエンコーディングに戻して書き出すということになるんでしょうか。
・ファイルマネージャーでソース表示する際に、当該ファイルのエンコード形式を検地
・エンコード形式が、管理画面に使用されている文字コードと異なる場合、管理画面に合致させる形で
一時的に文字コードを変換
・変換済みの文字コードをファイルマネージャーで表示
0.9.6.2が出た時に、文字化けのクレームは各国から出ていましたよ。スカンジナビア系とか。Aの上に丸が付いてるような文字とかが化けるなんて言ってました。だから、エンコードの問題は決して東洋系の漢字文化だけの問題ではないと思います。
8ビット構成つまりシングルバイト系のiso8859系エンコードでもいろいろあって、化ける時は化けるんですね。だから対応は必要。（だと思う、たぶん。）
PHP素人の私の無責任な推測ですが、ファイルからfget()で読み出したものをhtmlentities()をかまして出力しています。このhtmlentities()関数は、第3引数でエンコーディングの指定をしないとデフォルトとして「ISO-8859-1」と解して処理されるようです。この処理で化けちゃうんじゃないんでしょうかね? ちなみに、保存の方は$_POSTで受け取ったデータをそのままfwrite()でファイルに書き出しているように見えます。
そもそもphpの処理的に、ファイルを読み込んだままを出力してるのなら、ブラウザのエンコード検出もちゃんとできてるのになぜ化けるのかなと素人的な疑問は感じますが・・