【Ktai】PCやiPhoneで携帯のレイアウトを模倣するTips

icon_ktai携帯サイトをiPhoneに対応させたり、デバッグ等で簡易的にPCで携帯サイトを確認したい… そのような用途はあると思います。今回は、そんな方向けの、Ktai Libraryを用いたTipsをご紹介。

携帯向けサイトをそのままPCやiPhoneで表示すると、大抵はレイアウトが異なって表示されてしまいます。特にiPhoneはひどいもので、場合によっては文字が数pixel位の、もの凄~く見にくい画面になってしまいます。まあ、PCやiPhoneは携帯と比べて高解像度なわけで、仕方のないことなんですけど、これをなんとかしたい… そんなことを思われている方もいらっしゃると思います。
単純に、divでスクリーンサイズを(width=240で)固定してしまうのも一つのアイデアですが、それですと今度は高解像度な(SB)携帯で見にくいものとなってしまい、うまくありません。

ちなみに、iPhoneの場合は、コンテンツの横幅をオートで検出して、内容の少ないものは拡大されるのですが、そうでないものは最大980pixelとのことなので、長文が含まれているコンテンツは980pixel目一杯縮小されてしまいます。divで囲う方法で一見解決しそうな感じですが、縦方向に長い場合も縮小されるようで、確実な方法ではありません。
ただ、この件については解決する方法があり、metaタグで横方向のサイズを決めることが出来ます。

というわけで、上記を加味した上で、各端末に対応するための手法をご紹介。
ビューテンプレート(layout)はおおむねこんな感じです。
基本はこの方法でカバーできるかと思います。

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Shift_JIS">
<?php
if($ktai->is_iphone()){
?><meta name="viewport" content="width=260"><?php } ?>
<title><?php $title_for_layout; ?></title>
</head>
<body>
<?php
if(!$ktai->is_ktai()){
?><div style="width: 240px;"><?php } ?>
<font size="2">
<!-- &&layout&& -->

<!-- %%index%% -->
ここに内容を書きます。
<!-- %%index%% -->

<!-- &&layout&& -->
</font>
<?php if(!$ktai->is_ktai()){
?>
</div><?php } ?>
</body>
</html>

宣伝を兼ねて、Tplcutter形式で公開してみたり(笑)。
上記例では、iPhone用メタタグの数値が260となっているのですが、240だとうまくいかなくて、いろいろ調整しての数値です。
多少レガシーなhtmlタグが混じっていますが、これはcssに置き換えてもよろしいかと。

まあこんな感じで、携帯サイト製作の参考になれば。

【Ktai Library】とか言いながらもう次バージョンの話

icon_ktaiまたお騒がせすることになるかもしれません。

先日発表しました「Ktai Library 0.0.2」ですが、今度こそバージョンアップを行い、そしてしばらく打ち止めにして次のプロジェクト(?)に移るつもりでいます。
昨日の一件で、ご迷惑をおかけしたため近日中のバージョンアップは行わないつもりでいたのですが、先ほど片手間に作ってみたものがうまくいったのと、やはり緊急で解決しておいたほうがいいだろうという、先延ばしにしていた機能を搭載したものを追加してリリースすることで、念願だったマイナーバージョンのカウントアップをしようと考えています。

まず「片手間」の方ですが、携帯サイトへの誘導に不可欠な「QRコード生成」に対応します。携帯サイトとしてはあまり意味のない機能ですが、ソース量もとても小さいためメモリの負担もありません。その秘密は「Google chart API」! この素晴らしいAPIのおかげで、一からコーディングしなくて済みました(笑)。そしてこれもあまり意味がないですが、例のストレッチ対応もしております。

それから、これは皆さんも待望されているかと思うのですが、「DoCoMoのセッション対応」を正式に組み込む予定です。実は仕組みを「一般化する」のが難しいと考えていたために逃げていた所があったのですが、解決できそうな手法をひらめいたため、早速実装を進めているところです。ちなみに、セッションスタート時の処理に加え、redirect対応も盛り込みます。
それに伴い、キャリア判別の挙動が少し変わる予定です。普通にお使いの分には変わらないと思うので問題ないとは思いますが、今のところの構想では、プラス若干使い勝手が良くなる予定です。実装が不可能の場合は、もう一つ別の手法を考えていますが、あまりスマートな実装ではないためちょっと考え中です。

ちなみに、打ち止めとは言っていますが、当ライブラリは機種情報のデータをライブラリ内に持っていますので、新機種が発売されたときなどのタイミングで定期的に更新はしていく予定です。その点はご安心ください。

【Ktai】「Ktai Library」バージョンアップ少し延期のお知らせとviewの話

icon_ktai何度もお騒がせしてしまい申し訳ございません。
先ほど「バージョンアップ予定」としましたが、心配していた内容は回避されていたため、少し延期します。

このままでは、やると言ったり止めると言ったり、訳が分からないでしょうから、経緯説明を兼ねて、CakePHPの仕組みについて説明をしようと思います。ちょっとCakePHPの内部の込み入った話をしますので、もしかしたら難しいと感じるかもしれませんが、まあそういうものだと思っていただいてOKです。

発端は、ヘルパーでライブラリ本体である「lib3gk」の初期化をbeforeRender()内で行っているのですが、よくよく考えてみたら、beforeRender()はView::_render()内で「何度も呼ばれてしまうのではないか」という懸念があったからです。というのは、beforeRender()とafterRender()はView::_render()でコールされるのですが、ビューファイルが展開されるたびにView::_render()が呼ばれるからです。ここで言うビューファイルというのは、一般的なビュー以外にもlayoutファイルも含まれ、最低でも2回は毎度呼ばれることになります。つまり、その都度ライブラリがクリアされ、初期化されるようであれば、非常に無駄が発生することになり、バグも生みかねません。

で、結論から言いますと、beforeRenderおよびafterRenderは、ヘルパーが初めて読み込まれた場合、つまり初めてView::_render()が呼ばれた場合だけ行われるため、実害がなかったことが分かりました。なので、現バージョンのままお使いいただいて問題なく、結果バージョンアップは不要だという判断になりました。

そしてその副産物として、今まで不可解だったhelperコールバックのことがやっと少し分かりました。
今回outputがどうしてもうまく受け取れなくて困っていたのですが、この挙動に問題があったようです。

私はCakePHP1.1後期からのCake使いなのですが、RC1が出るまでは、outputはafterRender内でob_get_clean()で受け取るのが一般的な手法で、私もそのように行っていました。ところが、RC1からこの手法が使えなくなり、変わりにView::outputプロパティが受け渡しとして使われるようになりました。そして、この頃からbeforeRender,afterRender以外に「beforeLayout()」「afterLayout()」コールバックが追加されました。

今回KtaiLibraryを実現するにあたり、outputは「afterLayout()」で受け取れば問題なく処理が出来ることが分かりました。方法は

function afterLayout(){
  $view =& ClassRegistry::getObject('view');
  $view->output = mb_convert_encoding($view->output, 'SJIS');
}

という感じです。
ところが、「afterLayoutで受け取れるんだから、初期化はbeforeLayoutだろう」という思惑でいたところ、どうも具合がおかしい。ライブラリのインスタンスが作成されていない状態で、エラーが出てしまいます。初期化はbeforeRenderでやらないとダメなのです。

私は、「beforeLayout()→ (beforeRender()→afterRender()){n} →afterLayout()」の順番で処理が行われると推測していたのですが、初期化はbeforeRenderとなると、「beforeRender()→beforeLayout()→afterLayout()→afterRender()」の順番ではないか? でも実際にはafterRender()では何も入手できない(ob_start()でバッファスタートしているにもかかわらずob_get_clean()では何も入っていない)のです。

想定とは全く違っていました。
「beforeRender()→afterRender()→beforeLayout()→afterLayout()」というのが正しい順番です。

なぜこうなるのか。
それは「View::_render()内で初めてhelperが読み込まれたときだけ」実行されるから、だったのです。
ビューの処理は、まずビューを読み込んでからレイアウト処理を行います。この「まず」の部分でbeforeRenderとafterRenderのコールバックが呼ばれます。次に、レイアウト処理に入って、まずafterLayout。そしてレイアウトファイルをView::_render()を使って読み込むのですが、この中のbeforeRenderとafterRenderは2度目となるので実行されません。そして最後にafterLayoutが呼ばれ、終了…という感じなのです。

なぜこのような仕組みが提供されているのか、その心はさっぱり分かりません。
これでは、afterRenderとbeforeLayoutはほとんど役立たずです。
また、始まりがbeforeRenderで終わりがafterLayoutというのも、なんだかスマートではない…
「beforeLayout()→ (beforeRender()→afterRender()){n} →afterLayout()」という流れが一番自然な気がします。
この流れは改善の余地があるのではないでしょうか?

ちなみに、Ktai Libraryはバージョンアップしたいと言えばしたいです。
うっかりミスをしてしまった箇所がありまして…
なんと、get_version()でとれるバージョン番号が「0.0.2RC4」となってしまっているのです。
バージョン番号を直すのを忘れてしまいました(大汗)。
これだけを直すバージョンアップは、さすがにアレですので(^^;;;

とうわけで、お騒がせしてしまったこと、重ねてお詫び申し上げますm(__)m。

【追記】(2009.11.18)
コールバックの順番ですが、1.2.5(それ以前も?)では修正がされていて、「beforeRender()→beforeLayout()→afterLayout()→afterRender()」の順になっていました。どうやらこの現象はバグだったようです。
icon_ktai何度もお騒がせしてしまい申し訳ございません。
先ほど「バージョンアップ予定」としましたが、心配していた内容は回避されていたため、少し延期します。

このままでは、やると言ったり止めると言ったり、訳が分からないでしょうから、経緯説明を兼ねて、CakePHPの仕組みについて説明をしようと思います。ちょっとCakePHPの内部の込み入った話をしますので、もしかしたら難しいと感じるかもしれませんが、まあそういうものだと思っていただいてOKです。

発端は、ヘルパーでライブラリ本体である「lib3gk」の初期化をbeforeRender()内で行っているのですが、よくよく考えてみたら、beforeRender()はView::_render()内で「何度も呼ばれてしまうのではないか」という懸念があったからです。というのは、beforeRender()とafterRender()はView::_render()でコールされるのですが、ビューファイルが展開されるたびにView::_render()が呼ばれるからです。ここで言うビューファイルというのは、一般的なビュー以外にもlayoutファイルも含まれ、最低でも2回は毎度呼ばれることになります。つまり、その都度ライブラリがクリアされ、初期化されるようであれば、非常に無駄が発生することになり、バグも生みかねません。

で、結論から言いますと、beforeRenderおよびafterRenderは、ヘルパーが初めて読み込まれた場合、つまり初めてView::_render()が呼ばれた場合だけ行われるため、実害がなかったことが分かりました。なので、現バージョンのままお使いいただいて問題なく、結果バージョンアップは不要だという判断になりました。

そしてその副産物として、今まで不可解だったhelperコールバックのことがやっと少し分かりました。
今回outputがどうしてもうまく受け取れなくて困っていたのですが、この挙動に問題があったようです。

私はCakePHP1.1後期からのCake使いなのですが、RC1が出るまでは、outputはafterRender内でob_get_clean()で受け取るのが一般的な手法で、私もそのように行っていました。ところが、RC1からこの手法が使えなくなり、変わりにView::outputプロパティが受け渡しとして使われるようになりました。そして、この頃からbeforeRender,afterRender以外に「beforeLayout()」「afterLayout()」コールバックが追加されました。

今回KtaiLibraryを実現するにあたり、outputは「afterLayout()」で受け取れば問題なく処理が出来ることが分かりました。方法は

function afterLayout(){
  $view =& ClassRegistry::getObject('view');
  $view->output = mb_convert_encoding($view->output, 'SJIS');
}

という感じです。
ところが、「afterLayoutで受け取れるんだから、初期化はbeforeLayoutだろう」という思惑でいたところ、どうも具合がおかしい。ライブラリのインスタンスが作成されていない状態で、エラーが出てしまいます。初期化はbeforeRenderでやらないとダメなのです。

私は、「beforeLayout()→ (beforeRender()→afterRender()){n} →afterLayout()」の順番で処理が行われると推測していたのですが、初期化はbeforeRenderとなると、「beforeRender()→beforeLayout()→afterLayout()→afterRender()」の順番ではないか? でも実際にはafterRender()では何も入手できない(ob_start()でバッファスタートしているにもかかわらずob_get_clean()では何も入っていない)のです。

想定とは全く違っていました。
「beforeRender()→afterRender()→beforeLayout()→afterLayout()」というのが正しい順番です。

なぜこうなるのか。
それは「View::_render()内で初めてhelperが読み込まれたときだけ」実行されるから、だったのです。
ビューの処理は、まずビューを読み込んでからレイアウト処理を行います。この「まず」の部分でbeforeRenderとafterRenderのコールバックが呼ばれます。次に、レイアウト処理に入って、まずafterLayout。そしてレイアウトファイルをView::_render()を使って読み込むのですが、この中のbeforeRenderとafterRenderは2度目となるので実行されません。そして最後にafterLayoutが呼ばれ、終了…という感じなのです。

なぜこのような仕組みが提供されているのか、その心はさっぱり分かりません。
これでは、afterRenderとbeforeLayoutはほとんど役立たずです。
また、始まりがbeforeRenderで終わりがafterLayoutというのも、なんだかスマートではない…
「beforeLayout()→ (beforeRender()→afterRender()){n} →afterLayout()」という流れが一番自然な気がします。
この流れは改善の余地があるのではないでしょうか?

ちなみに、Ktai Libraryはバージョンアップしたいと言えばしたいです。
うっかりミスをしてしまった箇所がありまして…
なんと、get_version()でとれるバージョン番号が「0.0.2RC4」となってしまっているのです。
バージョン番号を直すのを忘れてしまいました(大汗)。
これだけを直すバージョンアップは、さすがにアレですので(^^;;;

とうわけで、お騒がせしてしまったこと、重ねてお詫び申し上げますm(__)m。

【追記】(2009.11.18)
コールバックの順番ですが、1.2.5(それ以前も?)では修正がされていて、「beforeRender()→beforeLayout()→afterLayout()→afterRender()」の順になっていました。どうやらこの現象はバグだったようです。

【Ktai】「Ktai Library」を再度バージョンアップをします

icon_ktai早速新版をダウンロードされた方には大変に申し訳ないのですが、「Ktai Library」を再度バージョンアップしようと思っています。たぶん0.0.2をお使いいただいて問題ないとは思いますが、念のための対処です。機能的には変えないつもりなので、そのまま差し替えていただいてOK だと思います。現在テスト中です。
また、バージョンナンバーは、一応区切りとして0.1.0とします。今後のバージョンナンバーは、機能拡張があった場合は下一桁を、バグフィックスは下二桁をカウントアップすると思います。

取り急ぎの報告ですが、よろしくお願いいたします。

【追記】
影響がないことが分かったため、バージョンアップは中止します。
詳しくは こちら をご覧ください。

【Ktai】「Ktai Library0.0.2」を公開いたします

icon_ktaiお待たせいたしました!
Ktai Library0.0.2を公開いたします。
上記タブにある 専用ページ からダウンロードできます。

本バージョンは前バージョンと比べて桁違いの機能を搭載しております。UTF-8対応をはじめ、画像のストレッチ機能・mailto機能など、おいしい機能満載です。
是非ご活用ください!

ちなみに次のバージョンは、ちょっとやることが満載になってきましたので結構間が空くと思います。やるとしたら、おそらくダウンロード機能かな、と思います。

まあこんな感じですので、機能追加していただける奇特な方がいらっしゃいましたら大歓迎です(笑)。マージ可能なものはしたいと思いますので、是非ご連絡ください。

【Ktai】最終リリース候補版(RC4)をテストしています。

icon_ktaiお待たせして申し訳ございません。
Ktai Library0.0.2の最終リリース候補版(RC4)をテストサイトでテストしています。
問題がなければ、こちらでリリースをします。DoCoMoとAUの携帯でOKの結果が出たらアーカイブを作って上げますので、端末をお持ちの方は申し訳ございませんが是非ご協力をお願いいたします。

▼「Ktai Library」機能チェックサイト
http://ktai-test.ecworks.jp/

生け贄な方(笑)からのご報告をもとに、EUCなどの携帯で一般的にサポートしていない文字コードからでも問題なくコンバートして表示できるように改良しました。絵文字コード関連のソースはかなり改良し、おかげでムダも少なくなりました(逆にdocomoの場合はムダが増えたかもしれませんが)。
emoji関数の引数に変更があり、互換がとれない場合があります。既に導入しているサイトにバージョンアップする際には若干注意が必要です(しかし、大抵は省略されている引数なので問題はないと思います)。

また、大きく変わった点として、文字コードの自動コンバートが追加された点(これはUTF-8に対応した時点でつけました)がありましたが、これと前バージョンからある絵文字の自動変換についてはコンポーネントではなくヘルパーでやることにしました。このため、コントローラで機種判定をするなどの処理をしなければ、コンポーネントは実質不要となります。helperからoutputを取るのに大変に苦労しました。outputの取り方は別記事で書きたいと思います(でも、分かってしまえば「なんだ~」と言ってしまうくらい簡単です)。

【Ktai】機能チェックサイトがVer0.0.2beta3になりました

icon_ktaiお待たせいたしました!
Ktai Libraryのバージョンがbeta3版となり、問題なければこのバージョンをアーカイブ化してリリースしようと考えています。もしよろしければお持ちの携帯でお試しいただき、ボタンクリックで動作確認をご報告いただけますと幸いです。

▼「Ktai Library」機能チェックサイト
http://ktai-test.ecworks.jp/

今回の目玉は、なんと言っても「画像ストレッチ」機能だと思います。この指定をすることで、どの携帯でも同じようなレイアウトで画像が閲覧できるようになります。ソフトバンク携帯の高解像度機種(ビエラ携帯・AQUOS携帯など)での悩みのタネでしたが、これで解決です!!

また、HelperにControllerで指定したパラメータを送り出す仕組みを「結局」搭載しました。
CakePHP1.2では、通常の方法でControllerのインスタンスを参照することが出来なくなってしまいました。なので、仕方がなく「Configure」を活用することにしました。基本的な値の受け渡しはこちらで行うことで、Controller内でKtaiHelper内へ値を送り込むことが出来ます。
コンポーネントを利用する場合は、自動的にConfigureを生成する仕組みがあるため、Helperに値を送ることを気にする必要がありません。コンポーネントを利用しない場合は、独自でConfigure::write()をする必要があります。値が設定されていれば、Helper内で勝手に見つけて反映します。なお、Controller内でいくら値を変えたとしても、結局はrender()を実行するまでHelperは動作しないため、Controller内での処理の最終の値がHelperに渡ることになります。

具体的な使用方法はここでは割愛しますが、出来るだけめんどくさくないようになっています。
また、0.0.1ではパラメータがライブラリ内の値とHelper/Componentそれぞれに別々のコピーがある仕様になっていましたが、全部ライブラリ内の値を参照するようにしたため、変なバグは生まれなくなったかと思います(最初からこうするべきでした)。使い勝手は確実にあがっていますのでご安心ください。

なお、リリース前に生け贄(笑)になりたい方も若干名募集したいです。
もし興味がありましたら、コメント欄にお願いします。
コメントフォーム内にあるメールアドレスにご案内をさせていただきます(確実に連絡の取れるアドレスでお願いします)。なお、コメント欄内のメールアドレスは公開されることはありませんが、コメントについてもこちらで非承認・削除としますので、プライバシーは一応保護されます。

新バージョンリリースまでもう少しですが、もうしばらくお待ちいただきますようお願いいたします。

【Ktai】バージョン0.0.2進捗報告(というかお詫び)

icon_ktai心待ちにされている方には本当に申し訳ございません。

Ktai Library 0.0.2なのですが、リリースが遅れております。
当方の本業の方が大変にテンパっている状況でして、作業時間を割けないのが理由です。毎日終電間際なので、家に帰ってから、というのがなかなか難しい状況でして…
土日も予定が詰まっていまして、本日(4/4)は自宅で引き続き業務をしておりまして、明日の朝未明がデッドラインという状況。明日は免許の更新ということで、鴻巣の免許センターに行ってくるという感じです。夕方頃からようやく時間が出来るかな、という感じですね。

来週は確実に作業時間が持てそうです。
というのは、本業でもKtaiLibraryが動いているのですが、例の「画像ストレッチを早く作ってくれ」という依頼がありましたので、それをやりつつバグフィックスをするという感じで、時期バージョンに搭載するつもりだったものも先取りできそうな感じです。すんなり動いてくれるのなら、こいつも搭載したものが0.0.2となる予定です。

それとは別に少々困った問題もあり、改良するか持ち越そうか迷っているものもあります。というのは、現状の仕様(というか元々のCakePHPの性質なのですが)、コントローラ側からktaiヘルパーの制御が難しく、コンポーネントで設定した内容をヘルパー内でも再定義しなければならないのが非常にめんどくさいため、定義関連をコントローラ内のプロパティにするか、Configure利用で表現しようかと考えています。実は機能確認サイトで文字化けしていたのは、ヘルパーとコンポーネントの文字エンコーディングに差があったことでコンバートがうまくできていなかったのが原因でした(helperのエンコーディングがSJISのままでした)。この改良をすることで、コンポーネントとヘルパーの設定に差が出なくなる(バグを生みにくく出来る)こと、それから毎度ヘルパーを書き直す必要がなくなり、ktaiヘルパーのバージョンアップなどで苦労しなくなる、という事があるので、今のうちに改良してしまいたい方向です。もしご意見ありましたらいただければ…

作業が止まってしまっていることで、お待ちいただいている方には本当に申し訳ございませんが、もう少しお時間をください。

【Ktai】重要度の高いバグのお知らせと対処方法

icon_ktaiバージョンアップ版をなかなか更新できなくて申し訳ございません。仕事の方が緊急で忙しくなってしまい、現在また徹夜です(大汗)。本日がとりあえずの山場になりそうなので、もう少しお待ちください。

お待ちいただく間に、一つ重要度の高いバグを見つけました。ご報告と共に、対処方法をお知らせいたします。

【現象】
リダイレクトを行うと、予定していた場所に飛ばない、もしくはループする。

【理由】
Ktaiコンポーネントのextendsが「Object」ではなく「Component」になっていたため

【対処方法】
1:extendsを修正
class KtaiComponent extends Component {

↓↓↓

class KtaiComponent extends Object {

2:initialize()とshutdown()内に含まれている「parent::~」を削除

以上で正常動作をすると思います。
完全に私のポカミスです。
申し訳ございません。

kenji0302さんが指摘されていましたが、上記の対処が正式だと思います。
いつもありがとうございます。

なお、かる~い進捗ですが、「UTF-8絵文字の報告終了後の文字化け」は、どうやらサイト側の問題でした。文字エンコーディングの設定がされていない部分を見つけましたので、おそらくSJISコードをUTF-8内で表示しているだけだと思います。一応念のために対策をしたコードが用意できましたが、まだサイト等には上げていません。
そしてmailtoの不具合ですが、こちらはまだ未解決です。仕事が忙しくて実際に検証が出来ていません。
他には特に問題が出ていなそうなので、こちらの方を解決した後にとりあえず公開しようかと考えています。一つ厄介な問題を見つけたのですが、こちらは根が深くて考え中が、実害はないとは思います。簡単に書くと「直接emoji()で作った絵文字をさらに全体変換してしまう…つまり二重変換の可能性が出ているのですが、docomoとAUはかぶっているコードがないので、とりあえずは大丈夫ではないか…という感じですね。

げーもう4時過ぎか…
とりあえず仕事に戻ります。

【Ktai】Ktai Library 0.0.2に向けてのご協力のお願い

icon_ktaiお待たせしております「Ktai Library」の新バージョンですが、9割9分完成しました。
今すぐにでもアーカイブして公開しても構わないのかもしれませんが、一応万全を期して、実機テストのご協力をいただいて、その結果良好でしたら公開をしたいと考えております。

大変に申し訳ございませんが、下記のURLに「出来れば携帯で」アクセスしていただき、諸機能が正しく動作しているか確認をいただけますと幸いです。報告方法は、フォームのボタンを1クリックしていただくだけなので、お手軽でしかもプライバシー保護もされているかと思います(^^;;;

特に不安なのが、私の所有していないdocomo、KDDI、EMOBILE、WILLCOMで、とりあえず文字コード生成の一歩手前の数値までは確認していますが、それから先のエンコード結果の文字コードが正しく出ているか不安です。これら端末をお持ちの方は是非ご協力ください!!

なお、現在次の制約があります。一応不具合ではありません。
・PHSの絵文字には対応していません
・PCの絵文字代替のテキストはおざなりのままです(大汗)。
・3G携帯以前の機種情報は対応しておりません(機種名は出てくると思います)

また、「画像のストレッチ」は結局現時点で実現できていませんが、予定していなかった機能として「mailtoリンク作成」の新機能を搭載しました。各キャリアに対応したmailtoが文字化けせずに実現できるかと思います(今回のウリの一つです)。

また、チェックサイトで「UTF-8の絵文字コードが直接挿入された」状態がどうしても作り出せなかったため、数値入力でとりあえずやってあります。もう少しやり方を模索して後日差し替えます。

それではよろしくお願いいたします。

▼「Ktai Library」機能チェックサイト
http://ktai-test.ecworks.jp/

※ちなみに、上記サイトはCakePHP1.2.2を使用しています(日本初?)

【追記】

「期待している結果がどんなものかが分からない」とのご意見がありましたので、どうなったらOKなのかをご説明いたします(本来はスクリーンショットを取れればよいのですが、取れる方法が無いのと、仕事の方が忙しくて現在時間が取れないためにこのような形で申し訳ございません)。

基本的に「【テスト】」と書かれている以下の内容が対象となります。

まず「端末情報関連」ですが、最初の項目は「is_xxxxx()」によるキャリアチェックの結果を○×で表示しています。アクセス端末のキャリア名のみが「○」になっていればOKです。その下はアクセス端末のユーザエージェントを解析した結果で、キャリア名・機種名の他、ライブラリ内が保持している画面サイズなどのデータを表示しています。なお該当キャリアで機種名が特定できない(古い端末やPDAでアクセスした場合)は機種名が「default」となり、各キャリアでの標準的なスペックで一応数値が入っています。数値が全く出なかった場合は明らかな不具合です。数値に関してはたぶん合っているかどうかまでは分からないと思いますのでそこまでは要求していませんが、0など明らかにおかしい値になっていたら報告していただけますと助かります。

絵文字関連は「SJIS」と「UTF-8」とに分かれていて、さらに「絵文字の個別表示」「絵文字の一括変換」の2種類、計4種類がテストされます。「個別表示」は「emoji()」関数を用いて直接絵文字を表示する機能、「一括変換」は「convert_emoji()」を用いてページ全体を一括で絵文字変換しています。絵文字ページは全て同じようなフォーマットとなっていて、注視していただくのは2つ並んでいる絵文字の【右側の部分】です。左が絵文字画像(TypePad絵文字)で、それと同じような「各端末の絵文字」が右側に表示されていればOKです。ただし、項目中に「AUにない絵文字」「SoftBankにない絵文字」があり、この部分は該当キャリアだった場合は左の絵文字画像と同じものになっているはずです。また、PCやPHS、iPhone等絵文字対応していないキャリアでも同じ絵文字画像が表示されているはずです。これが文字化けをしていたり、表示されていなかったりした場合はNGとなります。

最後に「mailtoリンク」ですが、リンクを選択するとメーラーが立ち上がり、アドレスと件名、本文が挿入された形になっているかと思います。本文は改行コード付きのため、改行がされていると思います。文字化けをしていたり、改行がされていなかったり、文章が全く挿入されていなかった場合はNGです。

以上、チェックしていただきたいのはこのような部分ですが、気になった点などございましたらコメント欄でお知らせいただけますと幸いです(例えば、既に上がっているレポートの「accesskeyが化ける」など)。