ぼ～っとしてるとついやってしまう…。
char(9)は9文字の固定長文字列ですが、何かの本にchar(n)はn*MAX_LEN byteの文字列が格納できると書いてあった。

utf8のキャラクターセット(MAX_LEN=3)だと
'123456789' = 9文字 = 9byte
'あいうえおかきくけ' = 9文字 = 27byte
でしょ。
1byte文字の場合は、まだ入るじゃん！
と思って
'123456789123456789123456789' = 27文字 = 27byte
で、入れると
'123456789'になる…。

にゃんでぇ。本の嘘つきぃ
結局、ｎ文字ってコトね。

でもさぁ、固定長文字列だからデータが9byteか27byteかって大きな違いじゃない？固定長でしょ！
データは27byte分確保してるのにあまるじゃん

実害として、ブログのタイトルでデザイン的に「日本語２０文字だな」って思ってvarchar(20)にして、←（余裕を持てよ）
たまたま、1バイト文字（英語）だけのタイトルを付けようとしたら切られた…。

WYSIWYGについて考えてみた。
「FCKeditor」など、高機能なものなどありますけど、ホントにこれでいいのかなぁ？
CMSにはよくある機能ですが…。

というのは5W1H
who だれ？ - HTMLの「え」の字も知らない人が
when いつ？ - いつでも
where どこ？ - Web上で
what 何？ - リッチ？な文章を作成
why なぜ？ - カッコイイから
how どのように？ - Microsoft Office Wordのように
でしょ。

で、気になるのが「who」と「what」です。
「FCKeditor」は実際使用した感じでは、カナリ高機能です。一言で言うと「何でもできるの？」です。
しかし、WYSIWYGを使用する一般的なユーザーのスキルを考えるとオーバースペックな気がします。
仕事上、いろんな人が作成した文章を拝見することがありますが、スキルはマチマチです。
WYSIWYGでどの程度のリッチテキストを実現すべきか？

という問題。

技術的にも、いろいろ問題あるし。

あっさりデキタ。

あっ、という間でした。

au CRCチェックバリュークラス
↑PHP5のテキストね

auで何かをダウンロードさせるには、CRCチェックバリューとやらをファイルに付けなきゃいけにゃい

で、
ローカル環境でそんなコトしてくれるプログラムは有りますが、Web上でしかも、リアルタイム？でしてくれるプログラムが欲しいよね。

無いよね。（探せないだけか？）

じゃぁ、作るしかないよね。

幸いにも、CRCチェックバリュー付加プログラム (サンプル)がある。
これをPHPに移植すりゃいいんでしょ？

ってこれCですか？
でた～。
C知らない…。

【方針】
・PHP5
・元のファイルを変更しない
【完成イメージ】
コントラクターでファイル名を引数に
PublicなMethodは２つ（サイズ取得、ファイル出力）
↑いや、これはExtendsなクラスだなぁ。
親クラスとしてCRC計算だけのクラスがあれば、他にも応用できるかも…。
【poor plan】
今回のプログラムは２部構成（ファイル２つだな）


できたのがこれ

【emg えも～じ】
５キャリアの絵文字変換テーブルを簡単に編集できるツールを公開。

てきと～に作った変換テーブルなのでミスとう有ります。
なので、使う人が自分で直して使いなさいよ！的な発想。

エアコンの設定温度は28℃です。

【その１】
携帯5キャリア絵文字変換emgえも～じ1.3になりました。

今回の更新は、あまり利用頻度は少ないと思いますが、DoCoMoの隠し絵文字に対応しました。
auにも隠し絵文字？が有るみたいですが、全然調べてません。

【その２】
Poor Source更新。今回はテンプレート処理について。
「テンプレートエンジン」というと大げさです。

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クラスの詳細設計（まじ？）