Nucleus(JP)フォーラム

NucleusCMS日本語版ユーザーのためのサポートフォーラムです。疑問が生じたらまずは記事検索をご利用ください。

ログインしていません。

#1 2011-06-23 21:59:34

Mocchi
メンバー
登録日: 2006-11-19
投稿: 438

Re: [4.0の開発 - 1] 展望とマルチバイト符号化文字処理の実装

本家でNucleus CMS 4.0の開発がスタートしました。細かな要件は以下となっています。

  • UTF-8ベースにしてさらなる多言語化を図る

  • マルチバイト文字列処理の実装でアジア圏の言語サポートを拡充

  • globalfunctions.phpに含まれる関数をいくつかのクラスに細分化する。後方互換性のためにラッパー関数を残す

  • PHP4系のサポートを完全に終了し、ソースからPHP4向けのコードを取り去る

  • MySQL3系のサポートを終了。TYPE変数ではなくENGINE変数に切り替えなど

私の担当はマルチバイト処理実装なのですが、この数日を使って本家のソースに反映しました。以下で参照できます。

http://nucleuscms.svn.sourceforge.net/v … k/nucleus/

本家ソースは現在、私が試したところではコードをひとつ追加するだけで日本語環境として使える状態となっています。

本家開発チームも開発で手一杯でリリースの日取りまでは決めていません。今回は構造の大きな変化もあるため、テストをかなり慎重に行うことになるかと思います。そのため、おそらくアルファリリース→ベータリリース→リリースキャンディデート→正式リリースという4段階を踏むことになります。

ラッパー関数を用意するなどしてプラグインに対しての後方互換も配慮していますが、4.0で大きな構造の変化があるため、プラグイン開発のフレームワークも少しだけ変化するかと思います。たとえば、「これまでmbstring拡張あるいはmb_emulatorに頼っていたマルチバイト処理を、iconvをバックエンドとする静的クラスであるi18nクラスの静的関数で行う」といった変化が挙げられます。

プラグイン開発のためのドキュメントなどは、おそらくベータあたりで公表することになるかと思います。私としては、これをきっかけにしてPHP4ベースの古いプラグインをPHP5ベースの新しいプラグインに再開発する動きが広まってくれたらなぁと思っていたりします。

これからも何か動きがあったらここにポストしようかなと思います。ベータリリースのテストの際など、再びみなさんに広くご協力いただければ助かります。

オフライン

#2 2011-07-07 14:39:17

kotorisan
メンバー
登録日: 2007-01-17
投稿: 49

Re: [4.0の開発 - 1] 展望とマルチバイト符号化文字処理の実装

動作に影響はないのですが

nucleus/libs/BLOG.php
    function getID() {
のintvalのVが大文字になっています。

オフライン

#3 2011-07-08 00:15:58

ftruscot
メンバー
登録日: 2009-01-21
投稿: 28

Re: [4.0の開発 - 1] 展望とマルチバイト符号化文字処理の実装

Fixed in 1551. Thanks, kotorisan.

オフライン

#4 2011-07-08 13:14:52

Mocchi
メンバー
登録日: 2006-11-19
投稿: 438

Re: [4.0の開発 - 1] 展望とマルチバイト符号化文字処理の実装

kotorisanどうもありがとうございます。私も見つけたバグのうち軽微な=明らかに議論不要なものは直してコミットするようにしていますので、他にもあったら教えて下さると助かります。

Thanks, Kotorisan.
I also fix apparent easy bugs with commit into SVN but I cannot cover whole Core scripts. I welcome reports about the other bugs.

オフライン

#5 2011-07-08 21:29:55

yama
Administrator
登録日: 2005-07-07
投稿: 1,265
ウェブサイト

Re: [4.0の開発 - 1] 展望とマルチバイト符号化文字処理の実装

管理画面のデザインが刷新されるとよいなーと思ってます。もしよければやりますよー。

オフライン

#6 2011-07-09 00:00:14

Mocchi
メンバー
登録日: 2006-11-19
投稿: 438

Re: [4.0の開発 - 1] 展望とマルチバイト符号化文字処理の実装

そのような議論を必要とする部分に関しては、別途開発者メーリングリストに持ち込んで下さい。。。

オフライン

#7 2011-07-09 01:59:14

yama
Administrator
登録日: 2005-07-07
投稿: 1,265
ウェブサイト

Re: [4.0の開発 - 1] 展望とマルチバイト符号化文字処理の実装

あー、いえ。そこまでは。いい調子で進んでるところに水を差してすいません。
(面白そうじゃん。という反応があればやってみようかなという程度でした)
それでは今後もよろしくです

オフライン

#8 2011-07-09 10:49:47

Mocchi
メンバー
登録日: 2006-11-19
投稿: 438

Re: [4.0の開発 - 1] 展望とマルチバイト符号化文字処理の実装

他の方に誤読を与えるのを防ぐために少々書きます。

[list=]
[*]本家開発において私は多言語化のための開発を一任されているひとりの開発者に過ぎず、リーダーではありません[/*]
[*]yama.kymsさんがNucleus CMSをどのように変えていきたいのか、そのために何をしたいのか、不明瞭で私にはよくわからなかったです[/*]
[*]yama.kymsさんは本家の開発者メーリングリストに参加しています[/*][/list]

乗り気とか乗り気じゃないとか以前のお話となります。

本フォーラムの投稿: PDO で考えを公表しているkotorisanはその点、話の持って行き方がとても上手だなと思います。

どのように変えていきたいのか
→Nucleus CMSをSQLiteバックエンドでも動作するようにしたい
そのために何をしたいのか
→Nucleus CMSが発行するクエリ全体の見直し
→インストラーの改良
(以上をパッチという形で示している)

このように伝えていただけると、私も開発者と話がしやすいですし、協力者を得るのが楽になるかと思います。私も多言語化周りの作業が一段落したら協力したいなと考えています。

(なおkotorisanは 本家のフォーラムへの投稿: [sqlapi] patch でも重要な改善を提案されており、開発者からの信頼を獲得しつつあります。)

運び方が上手ですので、Nucleus CMSのSQLiteバックエンド動作は、おそらく4.0で実現するでしょう。kotorisanはかなり熟練した開発者とお見受けします。

オフライン

#9 2011-07-09 12:07:11

yama
Administrator
登録日: 2005-07-07
投稿: 1,265
ウェブサイト

Re: [4.0の開発 - 1] 展望とマルチバイト符号化文字処理の実装

Mocchi さんの発言:

他の方に誤読を与えるのを防ぐために少々書きます。
[list=]
[*]本家開発において私は多言語化のための開発を一任されているひとりの開発者に過ぎず、リーダーではありません[/*]
[*]yama.kymsさんがNucleus CMSをどのように変えていきたいのか、そのために何をしたいのか、不明瞭で私にはよくわからなかったです[/*]
[*]yama.kymsさんは本家の開発者メーリングリストに参加しています[/*][/list]

乗り気とか乗り気じゃないとか以前のお話となります。

えー、「以前」の話で、そこまで要求されるのですか。

普通にブレストでいいじゃないですか。デザインの話なんて、人によって求めるものが全然違うし。

ていうか「誤読」って。誰がどう誤読するんですか。相変わらず、きっつい言葉使いますね。
Mocchiさんがその3カ条を書くことで防げる誤読ってことは、なんだか私に問題があるということですね。多言語化のための開発をしてるだけでリーダーでもなんでもないMocchiさんに対して、無関係なデザインの刷新を要求していて、そもそも私は何を要求しているのか不明瞭で、しかもメーリングリストに参加しているにも関わらずわざわざフォーラムに書いているんですよ、皆さん。ってことですか?

そもそも問題発言をしたつもりは全然なかったですが。

運び方が上手ですので、Nucleus CMSのSQLiteバックエンド動作は、おそらく4.0で実現するでしょう。kotorisanはかなり熟練した開発者とお見受けします。

なんでkotorisanの話が。上手なのは私もそう思いますが、全然関係ないでしょ。

このように伝えていただけると、私も開発者と話がしやすいですし、協力者を得るのが楽になるかと思います。私も多言語化周りの作業が一段落したら協力したいなと考えています。

デザインを新しくしようというだけでは「不明瞭」なんですか。いいですけど。

きっとモチベーションの種類がMocchiさんとは違うのだと思います。私はNucleus自体にはあまり思い入れがありません。長い付き合いで愛着はあるので、ちょっと便利になるなら何かやってみようかな?くらいはいつも考えてますが、その程度です。

「面白そうじゃん」という反応があったらやってみようかなと思っただけの話です。
いちいちこんなふうに食いつかれるのであれば、黙っておけばよかったですね。
今後そうします。失礼しました。

オフライン

#10 2011-07-09 23:02:25

Mocchi
メンバー
登録日: 2006-11-19
投稿: 438

Re: [4.0の開発 - 1] 展望とマルチバイト符号化文字処理の実装

私も、適当に「今後もよろしく」とか言われたので、かなり頭に来てます。更新作業中の人に対して「よろしく」とか、マジ信じられん。

自分が正しいとか、yama.kymsさんが正しいとか、そういうのはほんとどうでもいいです。

brain stormingのコツ、知ってますか?その場にいる人数に合わせて適切な課題を設定することですよ。漠然なことばかり言ってても、だーれも動きやしませんよ。少なくとも、私は確信を持って、「管理画面のデザイン変えようぜ」だけだと、意見のひとつも出てこないぞって言い切れますよ。

モチベーションとなっているものが人によって違うなんて、当たり前じゃないですか。だから人によって仕事の仕方が違うし、チームとして補いあっていけるんですよ。自分だけでなにかしたかったら独立して、自分専用プラグインとか作ってて下さい。

私も管理画面に対する不満あります。カスタムCSSとかheliumスキンとか、もっと手軽に使えたらいいのにとかとっても思います。だから他のユーザーもその願望はあると思います。

ですから、私がyama.kymsさんに求めているのは、せっかくいいアイディアとか、人望とか、これまでの実績とかを積み上げてきているんだから、「Nucleus自体にはあまり思い入れが」みたいな適当な言い訳とか、brain stormingがどうとか適当なこと言ってないで、自分の手を動かして自分のアイディアを形にして自分の手で見せてくださいよ、ってこと。とにかくスクリーンショットの1枚でもいいから成果物出して下さいよ。そうじゃなきゃなにも始まらないですよ、この手の話。

話が前後して矛盾関係に満ち溢れてますけど、正直かなり頭に来てるので、こんな感じです。

オフライン

#11 2011-07-09 23:49:09

yama
Administrator
登録日: 2005-07-07
投稿: 1,265
ウェブサイト

Re: [4.0の開発 - 1] 展望とマルチバイト符号化文字処理の実装

「頭に来てる」とのことですので、お互いさまということで私も言わせていただきます。

Mocchi さんの発言:

brain stormingのコツ、知ってますか?その場にいる人数に合わせて適切な課題を設定することですよ。

そんな理屈は言ってないですよ。最初からなんべんも言ってますが、面白そうと思う人がいればやってみようかなという程度です。「適切な課題を設定」て、、、そんなきっちり、「brain storming」を形式どおりやろうなんて提案してないし。何を考えてんですかw
こんなこと言うと「ブレスト感覚でと言ったじゃないか」とかつっこまれそうだけどなー。

Mocchi さんの発言:

私も、適当に「今後もよろしく」とか言われたので、かなり頭に来てます。更新作業中の人に対して「よろしく」とか、マジ信じられん。

応援してますよという意味でしかありませんよ。実際応援してるし。何が頭に来てんですか?
本当に頭にきているようなので、理由は分かりませんが、それは申し訳ないですねとは思います。

Mocchi さんの発言:

自分が正しいとか、yama.kymsさんが正しいとか、そういうのはほんとどうでもいいです。

おっしゃるとおり、どうでもいいじゃないですか。なんでそんな話がここで出てくるんですか?
どっちが正しいとかいう話、なんで出てくるんですか?
Mocchiさんは圧倒的に正しいと思いますよ。もう、気持ち悪いくらい正しい。だけど私は今回の件では実際に不満がある。そういう意味で、ほんとどうでもいい。

Mocchi さんの発言:

漠然なことばかり言ってても、だーれも動きやしませんよ。少なくとも、私は確信を持って、「管理画面のデザイン変えようぜ」だけだと、意見のひとつも出てこないぞって言い切れますよ。

いいじゃないですか、それならそれで。誰を動かそうとかいう話は全くしてないですよ?この時点で「デザイン変えてみる?」という話に興味を持つ人が一人もいなければ、この件はそれで終わり。それだけ。そんなの、いつものことです。Mocchiさんだけが変に理屈をつけて文句を言ってきているだけです。リーダーではないってことなら、ほっとけばいいのに。

実際には、たまたま共感して「俺もそう思うよ、ちょっと変えていこうよ」ってことで盛り上がってどんどん前に進んでいくことも「私は」多いですよー。Mocchiさんはそういう考え方を持たない人なので全く理解できないのだと思いますが、自分なりに結果と満足を得る方法を知っているようなので反論不要でよいですね?反論したけりゃしていいけど。

Mocchi さんの発言:

モチベーションとなっているものが人によって違うなんて、当たり前じゃないですか。だから人によって仕事の仕方が違うし、チームとして補いあっていけるんですよ。自分だけでなにかしたかったら独立して、自分専用プラグインとか作ってて下さい。

自分専用プラグイン?言われなくても昔から日常的にそうしてますよ。何を言ってんですかー。意味分からんわ。っていうか、知らんだけだったらすいませんな。

モチベーション云々を言わせていただいたのは、Mocchiさんの発言に非常に押・し・つ・け・がましいものを感じたからです。Mocchiさんが熱心なのは分かりますが、私はそこまでではない。kotorisanもいい仕事をなさっているしすごいと思うけど、それを参考にしろと言われてもなという感じでして。

Mocchi さんの発言:

私も管理画面に対する不満あります。カスタムCSSとかheliumスキンとか、もっと手軽に使えたらいいのにとかとっても思います。だから他のユーザーもその願望はあると思います。

ですから、私がyama.kymsさんに求めているのは、せっかくいいアイディアとか、人望とか、これまでの実績とかを積み上げてきているんだから、「Nucleus自体にはあまり思い入れが」みたいな適当な言い訳とか、brain stormingがどうとか適当なこと言ってないで、自分の手を動かして自分のアイディアを形にして自分の手で見せてくださいよ、ってこと。とにかくスクリーンショットの1枚でもいいから成果物出して下さいよ。そうじゃなきゃなにも始まらないですよ、この手の話。

あのねMocchiさん。

「せっかくいいアイディアとか」
「人望とか」
「これまでの実績とか」

そういうのを「上から目線」って言うんですよ。で、そういうふうに言われるのは非常に頭に来ますね。あなたは何様なんですか?kotorisanは立派に活動していて、私はまだまだ足りないと。努力しなさいと。そうしないとチームの理解は得られませんよと。このOSSの世界で、どういう立場の人がそんなことを言えるのかと思いますね。やる気のある人が自分のペースでやりたいだけやればいいし、興味のない人はほっとけばいいんです。Mocchiさんは、私に対してよけいな説教をしたいだけじゃないんすか。

で、「適当な言い訳」ですか?どこがどう「言い訳」なのやら。Mocchiさんに対して言い訳することなんて、1ミリもございませんが。

「とにかくスクリーンショットの1枚でもいいから成果物出して下さい」

何日も前に、とっくに作ってますけどね。もう出しませんけど。管理画面をカスタマイズしやすくするための関数も、稚拙ながら作りました。見たければフランクに聞いてください。興味ないだろうけど。先に手を動かしてから提案するやり方なんて、日常的にやってます。実際に試してみて「誰の助けもなくて自分一人しかいなくてもできる」と確認してから提案するわけです。

Mocchi さんの発言:

話が前後して矛盾関係に満ち溢れてますけど、正直かなり頭に来てるので、こんな感じです。

はーい、私もかなり頭に来ておりますよ。とにかくMocchiさん、なぜか私に対しては去年からずっとこうですからね。私に対してなんの恨みがあるのか知りませんが、なめた態度をとるのはいい加減にしてくださいね?Google Codeのプロジェクトを用意した時も、「そんなのは不要」みたいな態度をとられましたよね?Mocchiさんが具体的な要望を言ってこない中で、できるだけの配慮をしたつもりですが、いちいち「余計なお世話だ、むしろ迷惑だ」みたいな反応には正直辟易しました。じゃあ誰にも文句を言わないで、それこそ自分で独自プロジェクト立てるなりしてNucleusの再興を図ればよかったのに。「打ち捨てた」とか、誰に対して向けた言葉かと思います。Mocchiさん、あなたの態度はいろいろひどいですよ。それをカバーする能力と行動力をお持ちなので、おかげでNucleusは前進することができましたが、個人的には複雑な思いがありますね。

まあどう考えても、私はもうこのプロジェクトには関わらない気がしますが・・

追記 00:06
Google Codeの件はすいません。言い過ぎました。具体的にどうするという話がなかったのはお互い同じだったし、実際のところそんなに腹が立った話でもなかったです。Google Codeじゃなくてフォーラムの管理権限あたりの話だったかと。

オフライン

#12 2011-07-11 12:02:38

kotorisan
メンバー
登録日: 2007-01-17
投稿: 49

Re: [4.0の開発 - 1] 展望とマルチバイト符号化文字処理の実装

Nucleus CMSのSQLiteバックエンド動作は、おそらく4.0で実現するでしょう。

これは、ちょっと無理です。
本家の方がいわれているように、まず、sql_関数への移行が完了し、
プラグインが追随して移行して、その後の段階になると思います。

その他にも追加したデータベースエンジンのきちんとしたインストールプログラムの整備や
アップグレードスクリプトの整備、
データベース間のデータ移行プログラムの整備、ヘルプにその解説の追加などが必要になります
本体で試験的に対応しても、プログラミングができない一般ユーザーレベルでは
すぐに利用できるようにはならないと思います。

個人的には、truncを修正してテスト用にsqliteで動くようにしてますが
まだ、ローカル環境でぽちぽち押したり入力したり不具合がでる箇所ないかみている段階です。
エラーがでたところと、エラーがでそうな周囲の修正・確認しかしておらず
目視によるsql全コードの確認も済んでいません。

コアで対応できても
プラグイン側で対応ができていないと誤動作とセキュリティ上の問題を引き起こしますので
最終的には、SqlAPiでは、SqlApiを返すように、
なんらかのフラグをarray('mysql','sqlite')みたいな感じで返すように追加で用意して、
このデータベースは対応しています。というようにプラグインが値を返す仕様にする必要があると思います

オフライン

#13 2011-07-11 12:17:19

kotorisan
メンバー
登録日: 2007-01-17
投稿: 49

Re: [4.0の開発 - 1] 展望とマルチバイト符号化文字処理の実装

修正が必要な箇所
・i18n::strftime
(1)parse_archivedateなどが無効な変数$templateを参照しています。
  (2)テンプレートの値 $template['LOCALE'] を反映していません。
  (3)OS(Windows Japanese)によっては、strftimeで得た値をさらにutf8などにconvertする必要があります。

オフライン

#14 2011-07-11 23:44:02

h1028
メンバー
登録日: 2006-08-11
投稿: 80

Re: [4.0の開発 - 1] 展望とマルチバイト符号化文字処理の実装

勝手プラグイン作ってわるかったです。すんまそん!

オフライン

#15 2011-07-12 02:44:33

Mocchi
メンバー
登録日: 2006-11-19
投稿: 438

Re: [4.0の開発 - 1] 展望とマルチバイト符号化文字処理の実装

Mocchiです。

つい先ほど本家のソースに、MySQLコネクション周りのコードを本家ソースにコミットしました。リビジョン1557となります。
http://nucleuscms.svn.sourceforge.net/v ... ision=1557

事情により、日本語を扱うためには、MySQLサーバーに作成するデータベースのデフォルト照合順序を「utf8_general_ci」にする作業が必要です。もしこれをしない場合は、多分日本語がすべて「?」に変換されます。

詳しく知りたい方は、こちらの投稿を参照して下さい。

とりあえずこれにて、(バグはあるものの)他言語化のための共通の処理基板が整いました。後はインストーラーの改善や検索スクリプトの見直し、デフォルトスキンの見直し、管理画面のhead要素の見直し、header()関数の見直し、テンプレートに含む日付指定の国際化、ドキュメント整備などの作業が残るでしょう。

本家ではまだアルファリリースに伴うテストの話は出てきてませんが、フィード
バックはいつでも受け付けていますので、興味のある方は以下のURIのページ下
部Download GNU tarballから試してみて下さい。
http://nucleuscms.svn.sourceforge.net/v ... k/nucleus/

私はハードワークを避けるために1週間くらいお休みをもらったあと、検索スク
リプトの見直しを始めようと思います。(MySQLのインデクサーはそれほど理想
的な実装じゃなかった気がするが・・・)

そのためここでもいろいろな返信が滞りますが、ご了承下さい。

オフライン

#16 2011-07-12 04:01:09

Katsumi
メンバー
From: CA
登録日: 2005-06-24
投稿: 637
ウェブサイト

Re: [4.0の開発 - 1] 展望とマルチバイト符号化文字処理の実装

オープンソースの開発の世界では、誰かが他の誰かのために何かをするっていうのは、基本的にないのではと思っています。つまり皆、自分のためにやってるという事です。だから、義務的に「xxをやらなければならない」という事は、無いのではないでしょうか?それぞれみんな、自分のリズムでやって良いはずだと思いますよ。「アイデアあるんだけれど、一緒にやる人居ない?」 「そうか、居ないか」というのも、アリかと。

Nucleusの発展のことについて、議論したこともありました。「そこまで熱意を持ってやりたいのなら、本家の人たちとじかに議論したほうが良い」と言ったこともあったかと思います。だからといって、すべての人がその手続きを踏まないといけないということにはならないのではないですか?

色々なやり方があって良いはずです。SVNやGitでブランチを作ってやっても良いし、日本語版Nucleusの独自仕様として取り入れても良いし(実際、そういう独自仕様がすでに幾つかあります)、独自版としてやってみて、出来たものを評価するなりパッチを作って本家に見せるなりしても良いし。

オープンソースでの開発って、そういったコミュニティーのあり方を含めて考えるべきものだと思います。種々雑多な考えや色々な方向性の能力を持った人が集まっていて、それぞれの熱意の大きさの元、それぞれできる範囲で、それぞれが費やすことのできる時間を使って参加する、そんな雰囲気があるところに、自然と人が集まってくるではないでしょうか。

追伸:「自分のリズムで」という事で言えば、ずいぶん前になりますが、私自身もすこしコミュニティーをかき回してしまったかなという時があったかと思うので、そこは反省しています…。

オフライン

#17 2011-07-13 11:41:01

kotorisan
メンバー
登録日: 2007-01-17
投稿: 49

Re: [4.0の開発 - 1] 展望とマルチバイト符号化文字処理の実装

truncで 気がついたこと

・lib/sql/mysql.php , pdo.php
  sql_resultの最小引数が違います。
  mysql.php  function sql_result($res, $row, $col)
  pdo.php    function sql_result($res, $row = 0, $col = 0)

・libs/BaseActions.php: parse_parsedinclude関数
  現行バージョン NucleusCMS_3.64 jp の機能が削られています
  SKINのパース 関係、 日本語版と英語版のファイルを比較するとすぐにわかります。
  英語版には もともとないような・・・
3.64日本語版から4.0への移行時は困ることになるでしょう。

オフライン

#18 2011-07-13 22:12:18

Mocchi
メンバー
登録日: 2006-11-19
投稿: 438

Re: [4.0の開発 - 1] 展望とマルチバイト符号化文字処理の実装

kotorisan

修正が必要な箇所
・i18n::strftime
(1)parse_archivedateなどが無効な変数$templateを参照しています。
(2)テンプレートの値 $template['LOCALE'] を反映していません。

$templateに前もって値が代入されていないことによるWarningが出るという理解をしました。

「など」ということで$templateが関係してくる箇所を逐一見ないといけないですが、まずはACTIONS.phpから見てみました。私が確認する限り、ACTIONS::parse_archivedate()だけが当該の警告を発生するように見えました。

function parse_archivedate($locale = '-def-') {
	global $archive;
	
	if ( $locale == '-def-' )
	{
		setlocale(LC_TIME,$template['LOCALE']);
	}
	else
	{
		setlocale(LC_TIME,$locale);
	}
(以下、処理内容のみ)
アーカイブの日付を取得
フォーマットの設定
i18n::strftimeの出力をecho
}

$localeの指定がない場合の処理として
1. 現在のテンプレートからLOCALE情報を参照するなら、$templateに先に値を代入する処理が必要。
2. もしそうでなければ、$template['LOCALE']はデフォルトの値に書き換える必要がある。

1. もし前者なら、ACTIONSクラスはメンバーにテンプレート情報を持たないようなので、ACTIONS::parse_archivedate()の引数にテンプレートを示すものが必要。
2. 後者ならデフォルトの値を定める必要がある。空文字列を渡すと環境変数の値を参照する。

というように理解しました。この場合、どちらの実装が適しているんだろう?

参考
スキン変数:archivedate @ Nucleus管理用ヘルプ
setlocale > String関数 @ PHPマニュアル

オフライン

#19 2011-07-13 22:24:13

Mocchi
メンバー
登録日: 2006-11-19
投稿: 438

Re: [4.0の開発 - 1] 展望とマルチバイト符号化文字処理の実装

kotorisan さんの発言:

修正が必要な箇所
・i18n::strftime
(3)OS(Windows Japanese)によっては、strftimeで得た値をさらにutf8などにconvertする必要があります。

下記の問題ですね。

日付表示の文字化けについての相談です。 @ 日本語フォーラム

i18n::strftimeでは$template変数を%を目印にして配列化して処理しているんですが、この処理だと不十分だと理解しました。

開発環境にUnix/Linuxを利用していることもあり、このあたりの挙動に関して詳しいことを把握しておりませんので、ご存知のことを教えていただけると助かりますm(_ _)m

その他の件はまた後日。。。

オフライン

#20 2011-07-14 20:59:53

Mocchi
メンバー
登録日: 2006-11-19
投稿: 438

Re: [4.0の開発 - 1] 展望とマルチバイト符号化文字処理の実装

一時間程度で抽出できましたが、おそらく漏れもあるかとは思います。こちらはまた後ほど、どれをオリジナルに反映してどれを省略するか見通しを立てたいなと思います、1ヶ月後くらいになるでしょうか。

atom.php
フィードの出力をUTF8に変換

createaccount.php
多言語化

bookmarklet.php
出力対象HTMLの修正

install.php
install.sql
install_lang_japanese.php

installをディレクトリに分けるか分けないか

ACTION.php
ACTION::forgotPasswordでヘッダを出力

ACTIONS.php
ACTIONS::_ifAdminの返り値
ACTIONS::_searchlinkのcase indexの$uri
ACTIONS::parse_addlinkの条件
ACTIONS::parse_archivedateの$template
ACTIONS::action_regfilのSHIFT_JIS変換

globalfunctions.php
標準のタイムゾーン設定
encoding_check
sendContentTypeのencoding_check
selectorのstartUpError
selectorのdeny access部分
selectBlogのgetBlogIDFromNameに条件付け
selectSkinの条件付け
selectCategoryの$catidがない条件
selectCategoryの$itemidがない条件
parseFileのdoErrorの他言語化
ticketForPluginの$p_translatedの条件
ticketForPluginのexitの他言語化
encode_descの$data修正
getBookmarkletのescapeをencodeURIComponentに

ITEM.php
ITEM::createDraftFromRequestの符号化方式変換

showlist.php
日本語阪の追加修正

backup.php
多言語化

skinie.php
SKINIMPORTのreadFileで符号化方式の変換
SKINIMPORTのgetCharacterDataで符号化方式の変換
SKINIMPORTのexportで文字符号化方式の変換

xmlrcp.inc.php
mb_detect_encodingによる符号化方式変換をどう扱うか

xml-rss.php
mb_convert_encodingによる符号化方式変換

オフライン

#21 2011-07-16 11:04:06

Mocchi
メンバー
登録日: 2006-11-19
投稿: 438

Re: [4.0の開発 - 1] 展望とマルチバイト符号化文字処理の実装

本家のソースのリビジョン1557において、install.sqlの修正が加わりました。修正内容は、Nucleus CMSの設けるすべてのテーブルにおいてUTF-8を指定するというものです。

リビジョン1567における変更点

これにより、MySQLに設けるテーブルはその文字符号化方式にUTF-8を使うことになります。照合順序(collation)は、MySQLサーバーがUTF-8に対して与えているデフォルト設定、おそらくutf8-general-ciになるかと思います。

MySQLデータベース的には、バージョン4.1以降であればUTF-8を標準で利用できるようですので、多言語化のためには必要不可欠であるとのチームの決定を私は支持しています。
9.5. Unicode のサポート @ MySQL 4.1 リファレンスマニュアル
9.7. Unicodeのサポート @ MySQL 5.1 リファレンスマニュアル

※下記の記述には誤記が含まれます

さて、EUC-JPをこの先どうしていくのかという点に関しては、現在、どうしたらいいのか考えているところです。

私的には、PHP5のdefault_charsetディレクティブにeucjpがセットされている環境への対策という理解をしています。仮にそういう状態であったとしても、以下の理由でUTF-8で運用可能と理解しています。
1. Nucleus CMSのコアのコードがすべてASCIIに含まれる文字種で構成されている
=EUC-JPであってもUTF-8であっても、ASCIIに含まれる文字種は同じ方法で符号化され、同じ文字は同一のビット列になるから
2. PHP5で処理する文字列はUTF-8で構わない
=文字に対して処理を行っているわけではなく、「ビット列」に対して処理を行っているため

問題があるとするなら、スキンやプラグインで日本語文字列をEUC-JPによって符号化したファイルがある場合に限定されます(そしてそれは大きな問題です)。私の理解では、この場合、EUC-JPに従って符号化した日本語をUTF-8によって符号化されたものとしてPHP側で読もうとします。それによって、文字化けが発生する可能性があります。

PHP側でEUC-JPで運用し、MySQLのテーブルはUTF-8で運用するということを可能とするためには、以下の2つの方策を考えることができます。
1. MySQLコネクションを適切に設定しMySQLコネクションでクエリの符号化方式の変換をする
2. PHPスクリプト側であらかじめ、すべてのクエリに対して符号化方式の変換処理を加える

オフライン

#22 2011-07-19 11:09:38

kotorisan
メンバー
登録日: 2007-01-17
投稿: 49

Re: [4.0の開発 - 1] 展望とマルチバイト符号化文字処理の実装

Mocchi さんの発言:
kotorisan さんの発言:

・i18n::strftime
(3)OS(Windows Japanese)によっては、strftimeで得た値をさらにutf8などにconvertする必要があります。

開発環境にUnix/Linuxを利用していることもあり、このあたりの挙動に関して詳しいことを把握しておりませんので、ご存知のことを教えていただけると助かりますm(_ _)m

php windows
%Bなどを書式にいれると文字化けします。
値が、shift_jisコードで返ってくるためです

php関数のstrftime
Windowsが標準でサポートしている言語設定の文字コードで返ってくるようです。
日本語の場合Shift_JIS

Windows API関数の_wsetlocaleとwcsftimeを直接呼び出してみていないのでよくわかりませんが

おそらくphp側内部の問題で
unicode版の関数ではなく
strftimeの Ansi版の関数を呼び出しているか何かで
この問題が発生しているのではないかと推測しています。

オフライン

#23 2011-07-20 22:22:24

kotorisan
メンバー
登録日: 2007-01-17
投稿: 49

Re: [4.0の開発 - 1] 展望とマルチバイト符号化文字処理の実装

phpのソースを調べてみました。

phpのstrftime関数は、
php-5.3.6/ext/date/php_date.h : php_strftime関数
で定義されていて
  コードを見る限り、_tcsftimeやwcsftime分岐コードがないので
常にansi版のtime.hのstrftime が呼び出されると思います

次にsetlocaleについてphpソースをみてみます。
php-5.3.6/ext/standard/string.c : PHP_FUNCTION(setlocale)
は、ループで成功するまでphp_my_setlocaleを呼び出しています。
php_my_setlocaleは
#define php_my_setlocale setlocale
で setlocaleで定義されているので、
Cコンパイラ+OS依存と言うことになります。

MSDNには、setlocaleは3バイト以上のコード体系をサポートしていないとかなんとか書いてあります。

setlocaleを簡単に試験するコードを作りました
(参考コードを参照)

【検証結果(たぶん)】
日本語 Linuxでは、 EUC-JPとUTF-8を指定できるようです
  UTF-8の指定がない場合は、EUC-JPが返ってきました。
日本語 Windowsでは、 SHIFT_JISのみのようです
  phpがansi版の関数を使っているため

正しい値はコアの定義済みの定数の PHP_OS
setlocale設定後に返ってきた値で総合判断するしか方法がないようです。

ユーザーが設定したlocale文字列を書き換えて、setlocaleに渡すとある程度文字化けは回避できそうです。
他の国ではどういう値をとるかもわかりませんし、
この問題は根が深そうです。
文字化けするのは、週と月の書式なので
文字化けしたら、直接スキンやテンプレートで対応してくださいとか
日本語localeでは「%B」ではなく「%m月」を使ってくださいとか
日本語localeでは%a%Aを使わないでくださいとか
日本語ヘルプに注意書き程度でいいような気もします。
思い切って日本語のsetlocaleを設定できないようにするとか
i18n::strftimeで書式をすり替えるとか
ACTIONS.phpに%Bが使われているので、その辺の調整が必要になります。

月と週程度の文字なら、言語ファイルで定義すれば、書式置換で対応できると思います。

Linux,Windows共通で使えるのが、「japanese」のようです。
しかし、 _CHARSET への変換が必要になります

(参考)
intl - 国際化関数 (PHP 5.3.0 以降に同梱)
関数を試した結果、UTF8の値が返ってくるようです。
書式がstrftimeと異なります。

(参考)
公式配布のphpでの結果(Windows)

php 5.3.6 WINNT
※strftimeの結果の値は、全部SHIFT_JISコード(マルチバイト)で返ってきました
[env]  setlocale(LC_TIME , "");
   --> Japanese_Japan.932
  [7月] : strftime("%B"); 
[system?]  setlocale(LC_TIME , "japanese");
   --> Japanese_Japan.932
  [7月] : strftime("%B"); 
[shift_jis]  setlocale(LC_TIME , "Japanese_Japan.932");
   --> Japanese_Japan.932
  [7月] : strftime("%B"); 
[shift_jis]  setlocale(LC_TIME , ".932");
   --> Japanese_Japan.932
  [7月] : strftime("%B"); 
[EUC-JP]  setlocale(LC_TIME , ".20932");
   --> Japanese_Japan.20932
  [7月] : strftime("%B"); 
[iso-2022-jp]  setlocale(LC_TIME , ".50220");
   --> Japanese_Japan.50220
  [7月] : strftime("%B"); 
[iso-2022-jp]  setlocale(LC_TIME , ".50222");
   --> Japanese_Japan.50222
  [7月] : strftime("%B"); 
[US]  setlocale(LC_TIME , "english");
   --> English_United States.1252
  [July] : strftime("%B"); 
[Dutch_Netherlands]  setlocale(LC_TIME , "nld_nld");
   --> Dutch_Netherlands.1252
  [juli] : strftime("%B"); 
[cn]  setlocale(LC_TIME , "Chinese");
   --> Chinese_Taiwan.950
  [七月] : strftime("%B"); 
[kr]  setlocale(LC_TIME , "Korean");
   --> Korean_Korea.949
  [7?] : strftime("%B"); 

failed[9] :
  .51932 (euc-jp) , ja_jp (system?) , ja-jp (system?) ,
  ja_JP (system?) , ja_JP.UTF-8 (UTF-8) , ja_JP.EUC-JP (EUC-JP) ,
  en_US (?) , en (?) , zh_TW (zh) ,

公式配布のphpでの結果(Debian 64bit)

php 5.3.3-7 Linux
[env]  setlocale(LC_TIME , "");
   --> ja_JP.UTF-8
  [7月(UTF-8)] : strftime("%B"); 
[system?]  setlocale(LC_TIME , "japanese");
   --> japanese
  [7月(EUC-JP)] : strftime("%B"); 
[system?]  setlocale(LC_TIME , "ja_JP");
   --> ja_JP
  [7月(EUC-JP)] : strftime("%B"); 
[UTF-8]  setlocale(LC_TIME , "ja_JP.UTF-8");
   --> ja_JP.UTF-8
  [7月(UTF-8)] : strftime("%B"); 
[EUC-JP]  setlocale(LC_TIME , "ja_JP.EUC-JP");
   --> ja_JP.EUC-JP
  [7月(EUC-JP)] : strftime("%B"); 

failed[15] :
  Japanese_Japan.932 (shift_jis) , .932 (shift_jis) , .20932 (EUC-JP) ,
  .51932 (euc-jp) , .50220 (iso-2022-jp) , .50222 (iso-2022-jp) ,
  ja_jp (system?) , ja-jp (system?) , en_US (?) ,
  en (?) , english (US) , nld_nld (Dutch_Netherlands) ,
  Chinese (cn) , Korean (kr) , zh_TW (zh) ,

Vidual studio 2008での結果

php(Windows) での結果と同じ

PHP用テストコード

<?php

if (version_compare(PHP_VERSION,"5.99.99",">"))
{ // php6
}
// Windows                                                 strftime("%B", time())
// ok
//   mb_internal_encoding("SJIS");  mb_http_output('UTF-8'); // utf-8
//   mb_internal_encoding("UTF-8");  mb_http_output('pass'); // sjis
//   mb_internal_encoding("EUC-JP"); mb_http_output('pass'); // sjis
// x
//   mb_internal_encoding("UTF-8"); mb_http_output('SJIS');  // 破損
//   mb_internal_encoding("UTF-8"); mb_http_output('UTF-8'); // 破損
   date_default_timezone_set('Asia/Tokyo');

    printf("php %s\r\n" , PHP_VERSION." ".PHP_OS);
	$items = array(
		"", "env"
		,"japanese", "system?"
		,"Japanese_Japan.932", "shift_jis"
		,".932", "shift_jis"
		,".20932", "EUC-JP"
		,".51932", "euc-jp"
		,".50220", "iso-2022-jp"
		,".50222", "iso-2022-jp"
		,"ja_jp", "system?"
		,"ja-jp", "system?"
		,"ja_JP", "system?"
		,"ja_JP.UTF-8", "UTF-8"
		,"ja_JP.EUC-JP", "EUC-JP"
		,"en_US", "?"
		,"en", "?"
		,"english", "US"
		,"nld_nld", "Dutch_Netherlands"
		,"Chinese","cn"
		,"Korean","kr"
		,"zh_TW","zh"
		);

	$t = strtotime('2011-07-07');
	$list_failed  = array();
	$list_success = array();
	for($i = 0; $i<count($items); $i=$i+2)
	{
//		$res = setlocale(LC_TIME , 'C'); // set dummy locale
		$res = @setlocale(LC_TIME , $items[$i]);
		if ($res !== false)
		  {
			printf("[%s]  setlocale(LC_TIME , \"%s\"); \r\n  --> %s \r\n",$items[$i+1],$items[$i] , $res);
			printf(" [%s] : strftime(\"%%B\");  \r\n", strftime("%B", $t) );
		  }
		  else
		   {
		       $list_failed[] = sprintf("%s (%s)", $items[$i],$items[$i+1]);
		   }
	}
	$s = sprintf("failed[%d] :\r\n  ", count($list_failed));
    for($i = 0; $i<count($list_failed); $i++)
	{
	    $s .= $list_failed[$i]." , ";
	    if (($i+1) % 3 == 0) $s .= "\r\n  ";
	}
      printf("\r\n%s\r\n" , $s);
/*
	foreach(array("ja","ja_JP","zh_TW","kr","en_US","fr_FR","de_LU","it_IT") as $l)
	{
	    $fmt = datefmt_create( $l ,IntlDateFormatter::FULL, IntlDateFormatter::FULL,
				null, null  ,"MMMM/dd/yyyy");
		printf(" ICU[%s] : %s;  \r\n", $l , datefmt_format($fmt , $t) ); // result utf-8
	}
*/	
?>

C用テストコード

// "C:\Program Files\Microsoft Visual Studio 9.0\Common7\Tools\vsvars32.bat"
// cl file.c
#include <stdio.h>
#include <time.h>
#include <locale.h>

main()
{
	int i,j, ct_f;
	char *ptr,*ptr2;
	char text_failed[20000]; 
	char * items[] = {
		"", "env"
		,"japanese", "system?"
		,"Japanese_Japan.932", "shift_jis"
		,".932", "shift_jis"
		,".20932", "EUC-JP"
		,".51932", "euc-jp"
		,".50220", "iso-2022-jp"
		,".50222", "iso-2022-jp"
		,"ja_jp", "system?"
		,"ja-jp", "system?"
		,"ja_JP", "system?"
		,"ja_JP.UTF-8", "UTF-8"
		,"ja_JP.EUC-JP", "EUC-JP"
		,"en_US", "?"
		,"en", "?"
		,"english", "US"
		,"nld_nld", "Dutch_Netherlands"
		,"Chinese","cn"
		,"Korean","kr"
		,"zh_TW","zh"
		};
	ptr2 = &text_failed[0];
	(*ptr2) = (char) 0;
	ct_f = 0;
	for(i = 0; i<sizeof(items)/sizeof(char *); i=i+2)
	{
	   ptr = setlocale(LC_TIME , items[i]);
	   if (ptr != NULL) 
	    {
			printf("[%s] setlocale(LC_TIME , \"%s\"); \n  --> %s \n",items[i+1],items[i] , ptr);
	    }
	   else
	    {
			ct_f ++;
			if (ct_f % 3 == 0)
				j =  sprintf(ptr2, "%s (%s) , \n  ", items[i], items[i+1]);
			 else
			    j =  sprintf(ptr2, "%s (%s) , ", items[i], items[i+1]);
			if (j>0) { ptr2 += j; (*ptr2) = (char) 0; }
	    }
	}

	if (ct_f>0)
      printf("failed[%d] :\n  %s\n" , ct_f, text_failed);
}

オフライン

Board footer