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