岩室です。

# MySQLの話題からはちょっと外れますが……。

In message "[mysql 09445] Re: 日本語対応上の問題点"
    on 04/05/27, seiji takegata <takegata@xxxxxxxxxx> writes:
> もはやキャラクタ端末での表示がどうなるかを気にする人はあまり多くないの
> ではないでしょうか？

数の大小で言えば少数派であることは明らかなのですが、コンピュータ利用環
境におけるCUI/CLIの重要度が減じることはないと思いますし、ことデータベー
スシステムにおいては、管理を行うのにsshなどを利用してリモート操作を行
うケースは非常に多いのではないでしょうか。

> どちらかというと、プロポーショナルなフォントを表示した場合に所定の領
> 域に収まるかどうかが問題になる場合が多いと思います。

GUIアプリならそうかもしれないのですが、CUI/CLIアプリでは問題の所在が違
います。

GUIの場合、指示された情報をどのように表示するかはそれをレンダリングす
るアプリケーションやツールキットに閉じた問題なので、フォントやレイアウ
トの話に帰着するのでしょう。

しかし、CUI/CLIでは、端末の表現能力にかかわる情報を扱う標準的なインター
フェースが(現状では)termcap/terminfoくらいしかなくて(私が知らないだけ
なのかもしれませんが)、それ以外はアプリケーションを実行する環境に閉じ
た情報なので、アプリ側の想定と端末側の想定が一致していないと画面が崩壊
したりカーソル移動がおかしくなったりして使いものにならなくなる場合があ
ります。

# 簡単な例。(※Debian woody+Emacs-21.2で試してみました)
# 「αβγ」と書かれたEUC-JP のファイルを用意して、iconvでこれをUTF-8 
# に変換し、UTF-8環境の元、ターミナルエミュレータでEmacsを用いて両者を
# 同時表示してみます。すると、端末にはどちらも同じ文字コードが送られて
# いるのにEmacs内部ではEUC-JP側は2カラム、UTF-8側は1カラム想定になって
# いるので、カーソル移動などがおかしくなります。

## 個人的には、これと「〜」「−」問題がUTF-8環境への移行を妨げる(もの
## すごく)大きな壁になっています……。
-- 
岩室元典 [E-Mail: vmi@xxxxxxxxxx / iwa@xxxxxxxxxx]
「……雑でした」(「Fate/stay night」TYPE-MOON)