2006年12月アーカイブ

（（11/6アップ。））

この夏、6年ぶりにフルモデルチェンジした新型カローラに試乗しました。

今度のカローラは全車バックモニターが標準装備です。

写真は1.8Lの最上位モデル。これだとカローラで300万円の見積りが作れるそうです。また、1.5Lより1.8Lの方が売れているそうな。

カメラ（ナンバープレートの左上）の収まりもよくなっています。

トランク。

僕のカローラ･ランクス（後期型）と並べてみました。

旧型カローラとのサイズの違いは、全長が4cm伸びたこと。高さと幅は変わっていません。これ以上大きくなったら5ナンバーじゃなくなります。

エンジン。

トヨタが遂にカローラにCVTを採用しました。加速のワンテンポ遅れ感が評価の分かれるCVTですが、試乗した限りではだいぶ改善が感じられました。慣れの問題でしょう。ただ、急加速のGが好きな人はMTや従来のATの方がまだまだしっくりくると思います。

（（11/5アップ。））

蒲田の隠れ家的和酒バー KOYOI（こよい） へ。半年振りの訪問にも、マイミクでもあるママは覚えていてくれたみたい。

8時過ぎくらいになると、ふんわり開店します。

久しぶりに日本酒を飲んでしまった。カウンター8席に、2人掛けソファが2つのボックス席。こじんまりした良い店です。

こよい
住所｜東京都大田区蒲田4-18-8京急イドヤビル2F
営業時間｜夜
定休日｜日曜日

（（11/4アップ。写真のサイズを320*240から400*300に変更しました。より一層美味しそうにみえるかな。））

蒲田で飲み屋を探す野郎2人。眼中に飛び込んできたのは、炭火、串焼、焼鳥、肉刺、野鳥焼･･･。はい、即入店。

カウンター12席程に、テーブルは26席ほど。

トイレは綺麗に掃除されていました。好印象。

牛タンのたたき。

巻焼き盛り合わせ。

レバ刺。美味いっす〜。ここはかなりお勧めです。生肉好きにはたまりません。

炭火串焼 牛串焼ちゃこーる蒲田東口店
住所｜東京都大田区蒲田5-20-1
営業時間｜15:00-24:00
定休日｜第1,2,3日曜日

スペースタグ社の ST Server をインストールしました。ところが、Tomcat が Not installed になっています。先に Java をインストールしておかないといけないのかな？と思い、一旦アンインストールして JavaSE を入れてから再度インストールしても変化なし。そもそも、インストール時のオプションに Tomcat の項目がありません。 インストール方法をネットをあちこち彷徨って探した結果、「パッケージの内容がシンプルに変わった」ことが判明。Tomcat はなくなったようです。

本ブログでも何度か紹介してきたSpaceTag Serverですが、ST Serverと名前を変えて再出発したようです。再出発と同時に、これまでPostgreSQLからMapServer、Java、Python、XMail、etc...ととにかくWindows上でのサーバ・開発ツールをほとんど統合して、300MB以上の巨大なパッケージになっていたのが、Apache、MySQL、Perl、PHPに絞って76MBと軽量化したパッケージになったようです。

また、スペースタグ社の公式サイトには、

Q. SpaceTag ServerとST Serverは何が違う？ A. ST Serverでは、SpaceTag Serverの機能をWebサーバ（Apache）、データベース（MySQL）、開発言語（PHP、Perl）のみに絞り込み、より安定した性能と軽量化を実現しました。

Q. SpaceTag Serverはもうダウンロードできない？ A. SpaceTag Serverのダウンロードは、2005年9月20日をもって終了させていただきました。それにともない、安定化・軽量化を実現したST Server1.0をリリースしましたので、ぜひお試しください。今後は、ST Serverの機能を拡張した製品なども順次リリースしていく予定です。

などとありました。いやはや残念。軽量化して多機能な前バージョンは廃止するとは本当に思い切った行為です。しかし、Apache + Perl + PHP + MySQL だけでも十分と言えば十分かもしれない。ちなみに、サーバ環境を一括導入するパッケージとしては、「xampp for windows」というものが断然多機能なようです。

■ EUC-JP（別名 : 日本語EUC）
日本語UNIXシステム諮問委員会の提案に基づいて1985年にAT&T社が定めた、複数バイトの文字を扱う文字コードの枠組み。日本語だけでなく複数バイト言語の各国の文字コードが規定されている。日本語のEUCコードを特に「EUC-JP」「日本語EUC」と呼ぶこともある。


■ UTF-8（8-bit UCS Transformation Format）
UCS-2やUCS-4(Unicode)で定義される文字集合を用いて記述された文字列をバイト列(数値の列)に変換する方式の一つ。UTF-8では1文字を1〜6バイトの可変長の数値(バイト列)に変換するようになっているが、現在定義されているUnicode文字をUTF-8で表現した場合、最長で4バイトのバイト列に変換される。

UTF-8では、Unicodeの最初の128文字(UCS-2でいうU+0000からU+007F)を変換した結果がASCIIとまったく同じになるため、従来の処理システムとの親和性が高いという特長がある。一方、日本語などの文字は元々2バイトだったものが3バイトや4バイトで表現されてしまうため、UTF-16と比べてデータサイズが大きくなってしまうという欠点がある。

ちなみに、UTF-16ではUCS-4を完全に表現することはできないが、理論上はUTF-8はUCS-4を完全に表現できる。

（以上、e-wordsより）

■ メリットとデメリットなどに関する書き込み

UTF-8は最初から多言語での記述を前提とされているので、インターネットのように世界中からアクセスされるようなサイトの記述に適している。

EUC-JPはUnix系OSで扱われるだけでなく日本語を前提としているので、日本語版以外を扱うブラウザからアクセスした場合、文字化けする可能性がる。

EUC-JPに対するUTF-8のメリットとしては、
・HTMLやXHTML で使われる文字コードのデフォルトが UTF-8。
・UTF-8（というか Unicode）ならEUC-JPより表現できる文字の範囲が広い。

ツール側の都合で言えば、HTMLのデザイン（またはコーディング）ツールがXMLやXHTMLを扱う機能を必須としてきたため、必然的にUTF-8を扱えるようになった。さらに、UTF-8で書かれたソース側から言えば、多国籍企業の場合、各言語用のサイトで同じテンプレートを使いまわしすることができる。表示する文字の部分だけを、ターゲットとする言語圏の文字に置き換えれば済む。

ISO-2022-JP はそれまで慣習として通信で使われてた7bitJISコード（ISO-2022にそこそこ準拠）を、fj.* と Internet Mail で使うものとして、 制限つけてRFCとして書き起こしたもの。名前に反して実は ISO-2022 に 正確には準拠してないのは有名。7bit JIS としてなら歴史はあるが、まとまったのは一番新しい。

まあ、たぶん言いたいことは「ISO-2022 が先にある」ってことなのだろう。それなら正しい。

ShiftJIS は、Microsoft社が MS-DOSに日本語を導入するにあたって、半角カナを残しつつ漢字コードをわりこませるためにASCII社に作らせたもの。変態的な変換で気持ち悪いことと、当時既にあった国際規格の ISO-2022を全部無視したこと以外はそんなに悪いコードではない。いってる通り、不幸の文字があるので、ASCII処理前提でかかれていたコードは全部書き直しの憂き目にあったのはそのとおり。

そして、EUC-JP は別にそのあたりを教訓にしたのではなくて、UNIX の国際化を行うにあたって、普通に 8bit 版 ISO-2022 の使い方を日本語用に確定しただけのものだ。これは当時国内でUNIXを作ってたメーカが、既に同等の手法で自社UNIXを国際化してたのが細部が異なってたのを統一する形でつくられた。

ISO-2022 のままだと、ステートが爆発するので扱いにくいのは事実。でも、SJIS と EUC-JP では、正しくまじめに国際化するのなら、質的には有利/不利の差は存在しない。

ただ、世の中には、「ascii依存」なソースがあまりに多い。そして、EUC-JP の場合、コードが重ならない関係で、8bitスルーにさえなれば、日本語が壊れず通ってしまう。こういった「手抜き国際化」は EUC-JP のがやりやすいのは確か。

ちなみにこの条件は UTF-8 も同じ。だから、最近のあちらさんのアプリケーションはこれで処理したがってる。ソースをあんまり修正しなくて良いってこと。

UTF-8 は、互換性は目をつぶるとしても、日本語だけを扱うとしたらパフォーマンスが悪くなるのと、通信量が膨れ上がるのが欠陥（漢字は6byteになる）。まあ、マシンパワーの向上が全て解決するといわれればそこまでだ。

なるほど...。