変奏現実

当初MoEカテゴリーのURLは、
https://ssiscirine.iobb.net/archives/category/game/master-of-epic
だったのですが、WordPressのあるアップデートで勝手に
https://ssiscirine.iobb.net/category/game/master-of-epic
に変わり、
MoE ANTENA管理者さんにリンク先を変更していただいたのですが、
また3.1.1のアップデートでURLが
https://ssiscirine.iobb.net/archives/category/game/master-of-epic
元に戻っていたようです。
もう、APACHEのredirectで対応した方が良いような気がしてきた。
ps. 2011/04/22
# for MoE ANTENA
redirect /category/game/master-of-epic    https://ssiscirine.iobb.net/archives/category/game/master-of-epic
# service httpd reload
httpd を再読み込み中:                                      [  OK  ]
実行済み

JavaScriptの内部文字コードは何だろう。
ココを読むとUTF-16であることが判る。
出来たのがUTF-8なんて無かった頃なんだろう。
UTF-8が出来た本当の理由は、

Unicodeの振りをできるから・・・

だったのを今でも覚えている。
UNICODEと云えばEUCというのがあった。（今でもある。MRTGとかいろいろ）
Extended UNIX Codeの略で本来はUNIX用だった。
MSのシフトJIS同様に文字コードの衝突があり、日本語・支那語・朝鮮語を混ぜた表記が出来なかった（笑）ので、
HTMLに三ヶ国語の挨拶を一緒に表記できない？とか
国境を越えてサイトを見たりカキコしたり、
とかが普通に起きるようになると
？？？だらけの事態になる。
そんな訳で、UTF-16/8の様に無理やりでも世界中の文字を混ぜる方が無難だと思われた。
・・・
しかし、そのUNICODEを使ったオンラインゲームで８カ国多国籍パーティにいった時は
ログが多国籍文字だらけになりボクには読めなかった。　orz（反省）
同行のUSさんは半角カナが化けまくりで泣きそうだったそうです。
結局 ＲＰＧ語が無難で楽でした。
g.
u stp.
cm bk.
++.
sor.
np.
※この空気は実際のゲームの雰囲気から読んでください。
・・・
そんなこんなで、JavaScriptを使うならEUCやMS932を避けるのが簡単でいい。

1. MS932からUTF-16に変換できず？に化ける文字
2. MS932⇒UTF-16⇒MS932と変換すると違う文字コードになる文字

をどうするか悩むことになるからだ。
どうせJavaScriptでパソコンのファイルを直接読む機会なんてまず無い。
いづれにしても一旦サーバーまで送らないと読めない。
※１：WSHでよく使うFileSystemObjectをJavaScriptで使えば読めなくもない。
※２：但し、何かに感知されるとアトミックパワーがPOPUPしサイレンが部屋中に鳴り響く事になる。
※ ３：常時、耐音響爆雷防御姿勢（ヘッドフォンを首にかける）をとっていると吉。
また、

str = String.fromCharCode(0x41, 0x42, 0x43);

alert(str); // “ABC” が表示される

のように、半角文字（SBCS）しか使わないサンプルでも、
デフォでコードページはUTF-16だと踏んで、

str = String.fromCharCode(0x3042,0x3044,0x3046,0x3048,0x304A);

alert(str);　　// “あいうえお” が表示される。

ってもOK。
それからHyperScriptだから、都合よく型変換してしまうので、
引数を遭えて文字列にして、

str = String.fromCharCode(“0x3042″,”0x3044″,”0x3046″,”0x3048″,”0x304A”);

alert(str); // “あいうえお” が表示される

になる。
だから、Javaのpropertiesの/Uエンコードも意外とあっさり変換できる。ハズ
逆は、

int char_code=StringGetChar(“abcdefgh”, 3);

とか

var chArray = new char[6];

StringGetChars(0,6,chArray,”abcdefgh”);

とかかな。
たまに文字列を文字の配列にしたくて困るときは、

var  ar = “あいうえお”.split(”);

splitの引数のデリミタを空文字列にすると、一文字づつ区切ってくれる。
※残念だが、toArray() なんか知らんとIE8もFireFoxも云う。
※引数を指定しないと　”あいうえお”　一個が配列の[0]に入る。
文字の種類はどうしようか、
String.getType()も未実装らしいのでガリガリするしかない。
 
ここまで書いてて気が付いたんだけど、
JavaScriptの実装って雑ってより、手抜きだよね。

PHPを使うとセキュアじゃないって信じてる人もいるくらい嫌われてるPHPです。（大笑
１．簡単だから。
２．Perlで簡単にできることがPHPでは難しそうだから。
３．PerlのCPANみたいなライブラリのシンクタンクが無い。
4．ApacheのDocumentRootの中にソースを置くのが怖い。
あたりかな・・・。
実際使ってみると、ソースを修正して、すぐ動かせるのは非常に気分がいい。
一文字修正してもWEBサーバーごと再起動なんてデバッグはやってられなくなる。（笑
そして当然のことだが、全部PHPで書こうなんて思う必要が無い。
PHP用のモジュールそのものを別の言語で好きに作ればいい。
セキュアなシステムを作るのはPHPに限らずどの言語でも難しい。
例えば、Java系システムでよく使うJSPなんかは難問中の難問だろう。
JSP自体に例外処理を書けるけど、書くと後悔する。
※ストリームに文字を詰め込んでる最中にthrow しても手遅れですよね。（ ^ ^ ;
だから、JSPが呼び先をセキュアに作ろうとして、
ActionクラスやActionFormなどのメソッドを全部
try
catch
で括ることになる。
その結果は、不幸しかない。
※やっぱり、ストリームに文字を詰め込んでる最中にthrow しても手遅れですよね。（ ^ ^ ;
だからセキュアで安心なものにしたければ、
大雑把に安全なものを考えるしかない。
MVCなんかもそんな大雑把なパターン。
そうなれば、どの言語を使っても大差ないんだよね。
ええ、PHPでもMVCできますよ。（笑
ここで使ってるWordPressもそうじゃないかな？
後は好き嫌いの問題だけ。