PHPのソースコード

第１弾はHTTPメソッド関連のクラスとテキスト操作のクラス

まぁ、詳しくはこちら

面倒な処理をまとめてやっつけるあたりが、お洒落じゃない？


mb_detect_encoding($str, "ASCII,JIS,UTF-8,SJIS,SJIS-win", true)

でかなり行けそう！
と分かった。

しかし、JISコードに関してはダメダメ。

というのは、携帯電話の絵文字ですが、DoCoMo、SoftBank、Willcomが8bitのJISを使用してるから、mb関数が読み取ってくれない…。
ということは、コンバートも無理か？

７Fより大きい数字を使ってるってコト。
メールソフトやメールサーバーは７Fより大きい数字を切り捨てるコトがあるんだってさ。


Shift-JISの絵文字はmb_detect_encodingが”SJIS-win”で返ってくるのねん。

日本語を含む文字列を扱うプログラミングで、今のところ最大の
敵がエンコーディングと思ってます。
mb_detect_encoding()なんていう関数もあるわけですが、基本的に信用ならない。
日本語のエンコーディングを調べていくと、「あっ、無理かも…」と気づくのです。

でも、不正なエンコーディングによる不具合？脆弱性への攻撃もあるわけで、あきらめるわけにはいかないわけです。
エンコーディングさえ正確に分かれば、不正な文字を除外することは難しくないでしょう。いや難しいかもしれないけど、解決策はあります。

一般的にWeb系では、以下のエンコーディングを扱う
UTF-8
Shift-JIS系
JIS系
EUC-JP系
（系だから、細かいことは気にしないで）
で、とりあえずEUC-JPは、使わないを原則にしたい。
Shift-JISと見分けがつかないことがあるから…。じゃぁ、なぜShift-JISを残すかというと、色々？数々の問題点のあるエンコーディングなのですが、現実を考えるとコレは捨てられない。

EUC-JPを捨てる理由：
「システム環境がそうだから」という理由で使われていることが多いから。つまり、システムの都合で…といういいわけに過ぎない。
可能な限りクライアント環境に合わせるのが普通でしょ。

なので、クライアント環境に多いShift-JISを残す。

よし。これで、見分けるのは３つ（UTF-8、Shift-JIS、JIS）のエンコーディングに絞ることができた。（無理矢理）

JISは意外にうまくいく可能性がある。非常(×１００)に厄介ではあるが、その厄介な特徴が判別だけには役に立つ。というか日本語があれば１００％分かるんじゃない。（たぶん）
このエンコーディングも「システム環境がそうだから」で使われているだけなのですが、EUC-JPと大きく異なるのがクライアント環境が多い（いや、ほとんど。だってメールだよ）

と、いうことで２つだ。（UTF-8、Shift-JIS）
通常はあまりないが、Shift-JISの２文字がUTF-8の１文字になるかもしれない。とかがある。携帯電話の絵文字なんかは危険である。
UTF-8の４byte文字がShift-JISの２byte２文字でパターンマッチするのだろう。
ということで、UTF-8の４byte文字を無視（illegal）にすればいいんじゃない？確かにUTF-8の４byteにはちらほら漢字らしい文字もあるけど、公共の福祉のために除外する。
というか、MySQLとかUTF-8のMaxLenって3じゃん。だとすると４byteは無視すべきなのでは？
もっと厳しい条例をだすと、UTF-8の2byte文字もillegalにするとか。
↑これは学術論文とかギャル文字に弊害が…。

これで行けるか？
以上、Ｐｏｏｒなencodingクラスの詳細設計（まじ？）

携帯5キャリア絵文字変換php
emg えも～じ
やっと公開にこぎ着けた…。

JISコード関連でかなり苦労しましたが、幸いにもmb_convert_encodingがいろんな意味で適当なエスケープシーケンスを返すことで対応できました。

なっ、何なの？JISコードとかISO-2022-JPとか…。

Poor Project
ケータイ絵文字

PHP Data Objects（PDO）で注意したいことは
fetch,fetchAllとかSELECTの結果が全て文字列で返ってくること。
テーブルの型に関係なく…。
空文字をNULLにすることは出来るみたいだけど

なっ、何て言うか…。もう…、あきらめるしかない

携帯電話でも見られるようになったぽい。
結局、３つのメソッドをオーバーライドしてしまった（約100行）
とかいっても、DoCoMoとauしかテストしてない…。

さらに、コメントは出来ない…。
コメント入力はPC版はFlashなので、ケータイでもそうしたい。
Flash LiteはFlexでつくれるのか？（無知）

モバイル系の独自ライブラリはいちおう、DoCoMo,au,SoftBank,Willcom,e-mobileに対応したつもり
しかし、最近登場したiモードブラウザ2.0がくせ者。

個人的にiモードブラウザ2.0の位置づけがわからん。
iモードフルブラウザじゃダメなの？

絵文字ですが、これも独自ライブラリ
携帯５キャリアの相互変換＋変換できない絵文字は画像で対応
死ぬ思いをしたのは、延べ1833個の画像が手作り
なぜ手作りって？
デコレーションメールに対応させるために、どうしても20x20のサイズが欲しかったから。

内部処理をチョコッと変更。

テンプレート指向性をさらにパワーアップ。

これで、ケータイ、スマートフォン向け拡張が容易になった。
１つのメソッドをオーバーライドするだけでできそうな気がする。

個人的に推奨。

ブログ程度のデータベースにMySQL？大げさな…

今後、ブームの予感

手軽さがいい

データベースを使わない際はCSVとかTSV形式でデータを保存してたりしましたが、カンマなんてよく使うでしょ。TSVはお気に入りで、今でも簡単なデータファイル形式として使ってる

両者の欠点は「改行」を含むデータ。<br />とかに変換してもいいんだけど、生データを見るとカッコワルイし

PSB(Poor Script Blog)　ver 20090614 のリリース

ｊQuery以外は１００％オリジナルコードです。

開発経緯：
ブログって０から作るとどうなの？難しいの？
＋
ライセンスに縛られないものが欲しい

特徴：
・テンプレート指向な感じ
・ソースはオブジェクト指向な感じ
・PHP４切り捨て御免
・データベースはSQLiteとかでも行ける感じ

開発中：
・TrackBack（面倒なだけ）
・WYSIWYGな書き込み（コメント含む）←コードを埋め込めるので怖い
・Feedリーダー（mixiのマイミクみたいにしたい）
・モバイル対応（テンプレートを対応させるだけでOK、xmlhttpはどうする？）


そのうちソース公開していきます。

その他、このPSBで利用されているライブラリも公開していきます。
例えば、フィード（RSS,ATOM）とかカレンダー、テンプレートエンジンなど