岩室です。

In message "[mysql 09483] Re: 日本語対応上の問題点"
    on 04/05/31, とみたまさひろ <tommy@xxxxxxxxxx> writes:
> > しかし! その情報はアプリケーションが動いている環境でしか取得できなくて、
> > 端末エミュレータを動かしている環境では把握できないのですよ!!ヘ(T_T)へ
> 
> すいません、良くわかりません…。端末エミュレータって kterm とか 
> teraterm とかのことですよね。

はい。

> kterm や teraterm でどっかのサーバにログインして、アプリケーション
> (たとえば vi コマンド)を動かしている場合は、そのアプリケーションがマ
> ルチバイトの情報を得られればいいですよね…。

はい。

# 端末に出力したら1カラムなのにアプリケーションは2カラムだと思っている、
# とかその逆とかが問題になるわけなので。

> setlocale() の枠組みの中でカラム数を調べる場合は OS 依存だし、複数のロ
> ケールを扱うアプリケーションの場合は、アプリレベルで頑張るしかない… 
> っていうのは、今までと変わらないと思います。

EUC-JPやShift_JISを扱っている限りはそれだけあれば実用上の問題は出ない
と思うんですが、Unicodeがからむ場合はそれだけでは解決できない問題がい
ろいろあって、何か新しい枠組が必要なのではないか、とも思わないではない
です。

> 今まで日本語の扱いに苦労してきた身からすると、結局 Unicode なんて、新
> しいロケールが一つ(もっとか)増えたに過ぎないってことですな :-)

あー、よく考えれば、ロケールが一つである必然性はないんですよね。
Unicodeに関するエンコーディングも「UTF-8」だけである必要はないし。
(EUC-JPにもEUC-JP-openとかEUC-JP-msとかあるようですし)

以下のようにすれば解決するでしょうか。

新エンコーディング名: UTF-8-α-β-γ

α - 標準規格に由来する文字であるにもかかわらずコードポイントがベンダ
     依存であるものを判断するための識別子。「ms」「mac」「java」の値を
     取る(※後述)
β - Unicode正規化形式。「d」「c」「kc」「kd」の値を取る。(cの場合、濁
     点、半濁点付きの文字は単独の文字で表されるが、dの場合、結合文字で
     表現される)
γ - East Asian WidthがAmbiguousな文字幅の取扱い。「h」なら1、「f」なら2

※代表的な例を以下に示す。(他にもいっぱいあるよーですが)
  ・ms
   「〜」= FULLWIDTH TILDE
   「−」= FULLWIDTH HYPHENMINUS
   「￣」= FULLWIDTH MACRON
  ・mac
   「〜」= WAVE DASH
   「−」= MINUS SIGN
   「￣」= OVERLINE
  ・java
   「〜」= WAVE DASH
   「−」= MINUS SIGN
   「￣」= FULLWIDTH MACRON

とりあえず、

・UTF-8-ms-c-h
・UTF-8-ms-c-f
・UTF-8-mac-d-h
・UTF-8-mac-d-f
・UTF-8-java-c-h
・UTF-8-java-c-f

があれば実用上は十分でしょう。

# うっわー、頭わる〜(;_;)

## でも、真面目な話、例えば「プロジェクト報告書2004年5月31日〜6月4日」
## というデータをUTF-8でDBに格納したとして、上の3種類
## (ms-c/mac-d/java-c)で全部バイトパターンが違うんですよ?
## 実際問題、どーします?

### 冗談のつもりなんですが、まぢめにどこかに提案するのも良いかもしれない……。
-- 
岩室元典 [E-Mail: vmi@xxxxxxxxxx / iwa@xxxxxxxxxx]
「……雑でした」(「Fate/stay night」TYPE-MOON)