今日はLinuxのインストール

使い慣れたVineにします。（使用歴７年 内訳GUI４年、CUI３年）
今回も極小インストールで！
apt-getとwgetさえ使えりゃ後で何とかなるでしょ


昔からCD１枚というコンセプトと日本語化
英語は苦手ではないですが、日本語インターフェイスは誤操作を防ぎます。知ったかぶりで英語は使わない方がいいと思ってさ。


ところで、「Vine Linux」はなんと読むのが正しいか？
「ヴァイン」（英語）「ヴィー」（フランス語）
↑
フランス語な呼び方する人もいますが、有限会社ヴァインカーブがあるので英語読みでいいのかな？？

今回はフレームワークの整理が目的です。

何でもかんでも使ってると大変なことになってきたので…。

いっそ仮想化で１台にフレームワークごとの仮想環境を作った方がいいのだと思いますが…。
サーバーが非力過ぎるので止むを得ない

au CRCチェックバリューの件です。

なんか「au CRC」意外に検索上位なんですけど…。

なんで誰も公開してなかったんだろうね…。

需要がないのか？

それとも公開に値しないくらいみんな独自で処理してるだけ？

ってかこれ動作検証してないや…。（おっきなファイルの）

気になるのは、チェックバリュー計算のforループですね。
freadでファイル全体を読み込んでますが、ループでポインターあげていった方がいいんじゃない？でもunpackがループ内にあるのも好きじゃないなぁ
↑
これは単純にCをPHPに移植したときにそのままにしたからです。

あっさりデキタ。

あっ、という間でした。

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

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

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

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

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

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

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

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


できたのがこれ

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

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

【その１】
携帯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クラスの詳細設計（まじ？）

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

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

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