Yes!!
横浜方面のあたしには嬉しい変更．
本当は4車線を 2-2 で分岐できれば良かったんだろうけどねー．拡幅は無理だしなあの辺ｗ
教条的な「環状線は 2，分岐は 1」みたいな理屈でずっと環状線側に 2車線振ってたけど， 環状線は分岐直後に左からすぐ合流があるんで実質 1車線だったから， この変更は理に適ってるといえよう．
投稿フォームとかの類で wysiwyg な操作で HTML を入力できますよー，っていう， 似たようなのだと TinyMCE とか色々あって， こいつは FCKEditor というのが前身で，それの Ver.3 が CKEditor として開発されましたってことらしい．
ちなみに FCK とか CK って何ぞ． と思って調べたら作者の名前が Frederico Caldeira Knabben でした． なるほど把握．なんで F が取れたのかまでは追ってないので，そのうち調べてみよう．
で，これ自身はクライアント側で動く <textarea> タグの拡張品で， 最終的には普通のテキスト（HTML）が出来上がるものなんだけど， HTML といえば当然，画像も入れないといけません．
今でこそ HTML の中に画像を埋め込んだりとかも出来るけど， 基本的には画像は HTML とは異なるデータとしてサーバに置いてあって， そこへのポインタを HTML 内に書くもの．
ということは CKEditor もクライアント側だけでは話が完結せず， サーバ側と連携を取らないとどうにもならないわけだ．
で，この CKEditor はその画像関係のサーバ側とのやりとりが API 化されていて， それに従ってサーバ側に存在する画像の一覧から選択したりするプログラムを書けば， ローカルの快適な操作感を崩さずに画像の操作を行なえる．
そのサーバ側で動くコードが CKFinder という名で提供されていて， まぁ普通に考えれば「これとセットで使いましょう」なんだけど．
しかしこの CKFinder の方は，普通に仕事で作るサイトで使おうとすると， どうしても有料になってしまうのであります．
めっさ暴利でぼったくりってわけじゃないんだけど，ていうかむしろ大して高くないんだけど まぁ予算に組み込むとかの処理は地味に面倒なので，微妙に使いづらい．
というわけで，CKFinder ほどじゃないけど画像ブラウザを自作します．
なんか前置きが長いのはいつもの事だが内容が短いのもいつもの事で．
まずは公式ドキュメントを参照しつつ，サーバ画像ブラウザを．
ここまではいい．次こっちのページ．「パラメタ」について書いてある．
window.opener.CKEDITOR.tools.callFunction( CKEditorFuncNum, URL );
この JavaScript 関数コールを，サーバブラウザ側のウィンドウで実行してやる． すると，呼び出し側の画像ダイアログに，その URL が入る．わーい．
そして次は画像アップロード処理．これが画像ブラウザと微妙に違う処理が必要でわかりにくい．stackoverflow.comのここも参照する．
その HTML とは：
<html>
<body>
<script type="text/javascript">
window.parent.CKEDITOR.tools.callFunction(
CKEditorFuncNum,
'(URL)',
'(message)'
);
</script>
</body>
</html>ってな感じ．
サーバ側の処理で，処理が成功した場合は (URL) に URL を，(message) は空に．
逆に処理が失敗した場合は (URL) を空に，(message) にエラーメッセージを．
と，まぁ，こんな感じだった．
自作サーバブラウザなら，デザインとか機能（多すぎて困る場合がほとんどだがｗ）も顧客に合わせて色々と出来ていい感じです．
さーまだ仕事あるぞー．がんばろー．
今日は南砂で簡単なサーバ作業． conf を書き換えて httpd をリブートするだけの簡単なお仕事です．
帰りに「とうかんや」で醤油ラーメン味玉チャーシュー大盛り．
まんぞく．
日々仕事漬けだと，ときどき食べる美味しい店の美味しいごはんが大変に美味しいです．
サイトの検索機能とかで，検索文字列を URL に混ぜて GET で検索結果をみれるようにすれば， そのまま検索結果をコピペして他者に渡せたりして便利． なので，かなーーりの黎明期から，検索エンジンは POST でなく GET で処理していたりするわけで．
で，いま仕事で作ってるサイトももちろんそういう風にしようと思ったんだけど， 「自然文検索」なんてのがあるんでふと気になったのが，GET で使える URL の長さ．
なんかすごい昔「255bytes にしとくのが無難」とか聞いた覚えがあるんだけど， 実際 Google Maps とか Amazon とか，明らかにそれ以上の長さの URL を使っているわけで， じゃあどんくらいまでが限界値なのかしら．
自分で色々なブラウザを調べることも出来るんだけど， きっと既に同じ調査を誰かがしているに違いない．
していた．
RFC では規定されておらず，大抵のブラウザは実質的に無制限． IE だけ制限があるのでそれが律している状態ですよと．
ま た I E か ！
ふむむ．さらに Microsoft のサポート情報． POST でも GET でも，URL の長さは 2048文字までですよと．
でだ，検索文字列ってことは当然日本語で， 今時なので当然 utf-8 で， するってーと日本語の 1文字が 3バイトなのにそれが UrlEncode されるんで 9バイト． 2048 のうち実際の URL が（今回の場合は）30バイト未満なので，実質 2000文字ちょい． 9 で割ると 222文字．う，意外と少ない……？
まぁ検索窓に 200文字をぶっ込む猛者はそうそういないだろうとは思うが， なんか微妙に心配な空気感ではある．
ところで MS のページには「2048 characters」とあるけど， 「2048 bytes」ではないのね． ということは UrlEncode しない utf-8 で URL に直接文字列を， とかﾖｺｼﾏな事を考えたけどすごく意味なさそうなので忘れた．