build1024
本家サイトでは別名義(hira)でやっています。concrete5の内容はconcrete5サイトに、それ以外は本家サイトに分ける予定(concrete5サイトは開発途上です)。
コミュニティバッジ
投稿
41から50までを表示 (計50) |
---|
Re: Re: パッケージ領域の優先順位についてtaoさん、ありがとうございます。
Posted on 1月 04, 2011 at 1:21 午前
|
パッケージ領域の優先順位についてconcrete5.4.1.1用のパッケージ制作を試しているとき、表題の件について疑問に思ったので質問させてください。
Posted on 1月 04, 2011 at 12:35 午前
|
Re: Re: ファイル名のマルチバイト文字対応私も、日本語URLの動向を見てからでも遅くないと思います。本家との乖離が進み過ぎると危ないですしね。
Posted on 1月 03, 2011 at 2:05 午前
|
Re: Re: ファイル名のマルチバイト文字対応個人的にはサーバ上にはハッシュ等のユニークな名前で保存し、ダウンロード時に設定された元のファイル名でダウンロードする様にした方がよいかな?と考えています。 元のファイル名でダウンロードさせることについては、現に上で提示したものもそのような仕様にしてあります。 ただ、ハッシュを適用した名前でサーバー上に保存すると、既存システムに適用したときにファイルが呼び出せなくなると思い、現状では「Punycodeのエンコード結果を利用」という形にしています。 実は日本語のURLについてもずいぶん前に「urlencodeではなく、Punycodeではどうか?」という議論がありました。 確かに重さの点は重要ですね。現段階での仕様としては、データベースにはマルチバイト入りのファイル名をそのまま格納しており、サーバー上のファイルを呼び出すときにその都度変換を施しています(よってデコード処理を一切使っていません)。データベースの構造を変えなくていいので楽ですが、負荷の面は考える必要がありますね。 ただ、日本語URLと違い、ファイル名の場合はurlencodeだとファイルシステムの限界(255バイトなど)を簡単に超えそうで怖いのです(日本語1文字に対して、UTF-8では典型的には3バイトで、1バイトが %81 のように変換されるので、エンコード結果は都合9バイトになりますね。30文字弱で限界を超えます)。もちろんサーバー上のファイル名としてハッシュ関数の結果を使うならこの限りではありませんが。 今回の5.4.1.1でも日本語ファイル名の対応は議題にあがりましたが、時間切れで次期バージョンに保留となってしまいました。 そうですね、エンコード方法の選択やその長短も含めて議論の余地があるでしょうから、次期バージョンのリリースまでにゆっくりと、という感じになるでしょうか。
Posted on 1月 03, 2011 at 1:40 午前
|
ファイル名のマルチバイト文字対応5.4.1.1がひとまずリリースに至りましたね(まだ問題もあるようですが)。開発陣の皆さんお疲れ様でした。
添付:
mb_filename.zip
Posted on 1月 02, 2011 at 10:09 午後
|
Re: concrete5のアップグレード方法についてWarning: date() [function.date]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Asia/Tokyo' for 'JST/9.0/no DST' instead in /(サーバの階層)/public_html/concrete5/concrete/libraries/cache/default.php on line 91 エラーメッセージが言うには「date.timezoneを設定するかdate_default_timezone_set()関数を使え」ということですね。 というわけで、date.timezoneを.htaccessから設定してしまうのはいかがでしょうか。concrete5ルートの.htaccess(なければ新規作成してください)に php_value date.timezone Asia/Tokyo の1行を追加して保存してみてください。 ただ、使用条件のページには PHP 5.2.0 以上推奨 (PHP5.3はバージョン5.3.3以降で対応。5.3.1.1以降から PHP 5.1.0以上になりましたが、タイムゾーンのサポートをしている5.2.0以降を推奨しています。) と書いてあります。要するに、concrete5.3.2はPHP5.3.3には対応しないということですね(concrete5とPHPのバージョン番号が近いのでややこしい…)。その旨を理解された上で運用されるか、concrete5をバージョンアップする必要があると考えられます。concrete5とPHPのバージョンが適合していれば、.htaccessの設定はしなくても大丈夫ではないかと思います。 またアップグレードはphpのバージョンを上げる前にconcrete5のアップグレードから行ったほうが良いのでしょうか? concrete5のバージョンと要求されるPHPバージョンの兼ね合いを考えると、「concrete5のアップグレード→PHPのアップグレード」のほうが無難なのかもしれません。逆だからできないということはないと思いますが。 もし不明な点があれば気軽に返信してくださいね。100%回答できる自信はありませんが。
Posted on 12月 29, 2010 at 11:51 午後
|
Re: 5.4.1.1.b5 日本語版アップb2, b4についてのテスト結果を報告した者です。b5でもチェックしてみました。
Posted on 12月 29, 2010 at 11:12 午後
|
Re: Re: Re: Re: 5.4.1.1.b4 日本語版ベータ配布開始!と言うか是非日本語版のコミッターになりませんか? こういう動作テストなどでよければ、協力は惜しみません。メインの開発メンバーというわけにはいかないと思いますが…(あくまでユーザー寄りの立場での意見になるかと思います)。 ただ即決するのもどうかと思いますので、少し考えさせてください。 加入しようと思えば「メンバー募集中」から必要事項を送信すればよいのですかね? .htaccessの設定ですが、internalencodingの他にlanguageの設定が必要です。 教えていただいた設定を行ってみましたが、どうも変わらないようです。 ただ、たとえ文字化けせずに表示されたとしても「03:50 午後」のようにちょっと間抜けな表示になるので、config/site.php あたりで日時表示のロケールをいじるほうがいいのか(例えばen_USにするとか)と思ったりもします。日付のところが(strftimeの %x で返される日付が)「12/24/10」のようなフォーマットになってしまうので、それはそれで日本人にとっては変ではあるのですが。 調べてみると「iconvを使って対応せよ」という情報があったりもしますが、これだとスクリプト自体の変更になるので、あまり気が進まない感じではあります(ロケールくらいならsite.phpでやってもいいですが…)。 ちなみに、ベータ版なのでローカル環境にしかインストールしていませんが、本番環境で使うサーバー(symphonic-net.com)でstrftime関数の挙動を調べますと、%P が「午前」「午後」ではなく「AM」「PM」を返しましたので、このような文字化けの問題はないと思われます。 何度もお手数をおかけします…。 P.S. ロケールの設定はプロセス単位に影響が及ぶようなので、共有サーバーでかつPHPがモジュールモードで動いているとまずいかもしれませんね…。 ちなみにsymphonic-netサーバーでは setlocale(LC_TIME, 'ja_JP.UTF8'); でOKのよう(strftimeの %x が「2010年12月24日」のように日本語に展開され、%P の文字化けも問題なし)ですが、Windowsではこの設定が反映されないようでした。
Posted on 12月 24, 2010 at 5:03 午後
|
Re: Re: 5.4.1.1.b4 日本語版ベータ配布開始!b2の問題を報告させていただいたbuild1024です。b4にアップグレードしてみましたので、先日報告した点について再確認した結果を書いておきます。
Posted on 12月 24, 2010 at 4:07 午後
|
Re: Re: 今度は 5.4.1.1.ja.b2 日本語版ベータはじめまして、concrete5.4.1.1.ja.b2をWindows 7上のXAMPPでテストしております。
Posted on 12月 13, 2010 at 11:03 午後
|