UNICODEをどう組み込む

takusi 曰く，"ソフトウェアのi18n(国際化)の切り札と目されているUNICODE。しかし、このUNICODEはUTF-16、UTF-8などのいくつかのエンコードや、実装を支援するための、IBMのICUやGNUのgtextのような多数のライブラリがあります。UNICODEはどのようにプログラムに組み込むのが吉でしょうか？(当然、OSや言語によって様々でしょう)"

確かに悩ましい。iconv() 1つ取ってもさまざまな仕様があったりするし、Samba 日本語版などでは MS の CodePage の仕様から、結局 iconv() に頼ることなく自前で実装してたりする。悩むくらいならば自前でやるぜと思う人もいるかと思うが、それはそれでメンテナンスの面で悩ましい。さて、どうするのが吉か？

i18n の範疇ならば

[oku (4610)]

何も iconv や Unicode に関わらずとも wchar_t⇔char + メッセージカタログで 十分ではありませんか？

m17n だと内部コードはやっぱり UCS-4 (or UTF-32) かな～とか 考えざるを得なくなるのかも知れませんが。

Re:ＵＮＩＣＯＤＥなんて

[oku (4610)]

英語だけ == 8bit clean の事であれば まあ世界中の大概の人は困らないでしょうね。
# 私も適当に誤魔化して使うと思う。
でも US-ASCII 限定の意味だとすると ISO-8859 人にも使えなくなってしまいますよ？

Re:ＵＮＩＣＯＤＥなんて

[Anonymous Coward]

その提案が２バイト日本語でなされているのがイタイ(w

Re:他人に売れる物が作れるか

[oku (4610)]

「他人に売れるものが作れるか」
ということを念頭におかないのであれば

1. まずは 8bit clean で作りました。ソース公開します
2. 誰か i18n 対応してください > i18n が必要な人
3. 誰か m17n 対応してください > m17n が必要な人

という解もありうるのではないかと思いますが。

# Ext-B への需要とか Unicode 以外の日本語処理の
# 部分については大筋で御意です。

Re:i18n の範疇ならば

[brake-handle (5065)]

メッセージカタログというのは、i18nの全体像から考えるとUCS-4などのcharsetよりも上位に来る概念ではないですか? メッセージカタログに含まれる各ロケールのメッセージを記述するために例えばiso-8859-1やUCS-4などのcharsetを選ぶという位置づけになるので。

ただし、世の中を見渡してみるとメッセージを出さないツールなんてほとんどないんですよね。したがって、用意されているロケールのどれか1つを選択することは必須です。このとき、実際にあるロケールを選択することによって、それによって選べるcharsetが限定されてしまう(場合によってはUCSを除くとuniqueになってしまう)ことがしばしばあります。その点からするとUCS-4はいささかオーバースペックに見えます(間違いなく使わない文字が大量に残ってしまう)。

そう考えてみると、UCS-4が魅力を持つためには、複数のロケールを併用する場面を作り出すことが必要になってきそうです(そんな場面あるのか?)。

初心者の敵だ

[Anonymous Coward]

JavaはUNICODEを使うようになってるので国際化は全部解決してるみたいな甘い言葉に誘われて手を出してみたらエディタやらデータ入出力等あらゆるところで文字コード変換が必要で死ぬかと思った。　ごめんなさい、初心者のボクにはJavaは無理でした。うそです。弱音は吐きません。がんばって文字コードの泥沼を横断するです。

Pythonでは

[bravo (1225)]

PythonでUNICODEするときは「日本語環境で Python (Idle) を使う (utf-8編)」が有益です。

Unicode 移行のメリットとデメリット

[kubota (64)]

まず、Unicode (UTF-8) のほうがいい理由。

• フル規格の ISO-2022 の実装は大変すぎてとてもできない。
• ISO-2022 は、そこそこのサブセットでさえ、実装するのは面倒。
• stateless である。つまり、「状態」を持たない。エスケープシーケンスもない。というわけで、サロゲートペアで批判されている UTF-16 でさえ、ISO-2022 よりもはるかにシンプル。ISO-2022-JP よりもシンプルと言える。
• 必要に迫られていて、かなりの能力と時間がある人でないと実装ができないので、対応ソフトウェアがいつまでたっても増えない。
• CJK の漢字はたしかに CJK で区別できるといろいろと利点があるが、 ISO-8859-* に載っている文字 (たとえば、ISO-8859-1 [の右半分] にも ISO-8859-2 [の右半分] にも同じ文字 [たとえば 0xc4 はウムラウトのついた A] が入っている [というか、大部分が共通な文字]) は区別しないほうがいい。

次に、どちらでもいい、もしくは、どちらともいいがたい点。

• 結合文字や bidi (bi-direction、アラビア文字やヘブライ文字のように右から左へと文字が進むのを許す実装) は、Unicode でも ISO-2022 でも手間は同じ。
• 漢字のうち、CJK で字形が同じものについては、賛成、反対どちらも意見がある。賛成の意見で有名なのは「grep 毛沢東」だろう。(反対は「grep 手紙」かな?)

最後に、Unicode に移行したほうが悪くなる点。

• CJK 統合漢字のうち、字形が異なるもの。「骨」とかが有名だが、「直」に至っては中国の字形はたいていの日本人には判読不能と思われる。ただしこれも、U+E0000 からのタグや、もうひとつレベルを上げてマークアップで区別することが可能だが、実装が大変。
• JIS X 0208 と Unicode との相互変換テーブルが、さまざまな実装があって統一されていない。漢字部分については Unicode Consortium がきちんと変換テーブルを用意しているので問題がないが、記号部分については各社ばらばら (英語ですみませんが、ぼくの書いた文書 [debian.or.jp]の Conversion tables differ between venders を参照してください)。 Unicode Consortium は、参考扱いの変換テーブルを用意していたが、 最近それも obsolete (廃止) 扱いにしてしまった (http://www.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/ [unicode.org])。 完全に移行しきってしまえば問題とはならないはずだけども。 ちなみに、GNU libc は、上記の OBSOLETE なテーブルのうちの JIS0208.TXT をもとに、上記拙文の EUC-JP round-trip compatibility に記載されている問題を回避する目的で、JIS X 0208 の 0x2140 (「＼」) を U+005C から U+FF3C に変更したものを使っています。 XFree86 は、JIS0208.TXT そのままでしたが、GNU libc 式に追随するパッチが受け入れ待ちとなっています。
• 文字幅問題。これは、ターミナルエミュレータなど、固定幅フォントを使う場面において、どの文字が倍角扱いになるかが、EUC-JP などで広く使われていたデファクトスタンダード (JIS X 0208 や JIS X 0212 に含まれている文字はすべて全角、ASCII や JIS X 0201 に含まれている文字はすべて半角) とは異なる。詳しくは、上記拙文 [debian.or.jp]の Width problems を参照 (英語)。 ただしこれも、完全に移行してしまえば問題でなくなる。
• EUC-JP や Shift_JIS で、2バイト文字 = 全角、という世界では、マルチバイト文字に対応していないソフトウェアもごまかして使うことができる場合があったが、UTF-8 だとそうはいかなくなる。

完全にユーザである (開発は一切おこなわない) のなら、対応ソフトウェアの状況で、移行するほうがいいかどうかを決めればいいと思います。

Re:Unicode 移行のメリットとデメリット

[numa (4467)]

私はこれ、かなり疑問に思ってます。100% pure Unicodeな環境下で、IMEから「～」を入力した場合、それはWAVE DASHなんでしょうか? それともFULLWIDTH TILDEなんでしょうか? 「―」、「∥」、「－」についても同様の問題がありますよね。

JIS X 0208 の範囲だけでもそれだけ問題になる文字があるわけですが，Unicode に移行すると対象になる文字はさらに増えます．

たとえば「Å」は，JIS X 0208 の範囲なら U+212B ANGSTROM SIGN でしょうけれど，その限定をなくせば，

• U+00C5 LATIN CAPITAL LETTER A WITH RING ABOVE かもしれないし
• U+0041 LATIN CAPITAL LETTER A の後ろに U+030A COMBINING RING ABOVE が続いたもの (意味的に上と同じですが) かもしれないし
• U+0391 GREEK CAPITAL LETTER ALPHA の後ろに U+030A COMBINING RING ABOVE が続いたものかもしれないし
• U+0410 CYRILLIC CAPITAL LETTER A の後ろに U+030A COMBINING RING ABOVE が続いたものかもしれない

わけですから．他にも，Σやμは2つずつあるし(ギリシャ文字アルファベットとしてのものと，記号としてのものと)，「中点のような文字」や「横棒のような文字」や「空白のような文字」に至っては，数えるのが嫌になるほどあります．

ＵＮＩＣＯＤＥなんて

[Anonymous Coward]

使わなければいい。英語だけでたくさん。

Re:ＵＮＩＣＯＤＥなんて

[argon (3541)]

なんだか、モデレータ氏がフレームを煽っているような気がします。

ところで UTF-16 で書いたソースコードを扱えるＣコンパイラってあるのでしょうか？

Re:ＵＮＩＣＯＤＥなんて

[oku (4610)]

ところで UTF-16 で書いたソースコードを扱えるＣコンパイラってあるのでしょうか？

存在の有無については寡聞にして存じ上げないわけですが。
そのコンパイラは

puts("�a5;n");

をどう解釈するのでしょうね？ :-)
# いや、\xa5\x6e が正しいと言うのは
# 頭では分かってはいるんですけどね...

あなたには（Re:ＵＮＩＣＯＤＥなんて）

[kyle (3923)]

LANG=ja_JP.romaji を使う覚悟があるのですか？ 読みにくいぞー、慣れの問題かも知れんが。

それ「だけ」では

[oku (4610)]

i18n 上、何の解決にもなっていないと思いますが。
# きちんと入力を Byte[] で受けて
# 自前で操るのであれば別ですけど...
# ひょっとして考えているターゲットがズレてます？

Re:あなたには（Re:ＵＮＩＣＯＤＥなんて）

[oku (4610)]

英語だけなので locale.h 自体が なかったりするのではありませんか？ :-)

Re:i18n の範疇ならば

[brake-handle (5065)]

どこにshiftが入るかわからない素の文字列でgrepするとひどいことになるのは事実です。しかし、

• shiftで区切られる部分文字列について、minimum charsetを用いる(iso-8859-1など)
• shiftの連続について、最後のshift以外を除去

ぐらいをやってやれば、uniqueなエンコーディング(同時に最簡形でもある)を得ることができるのでは?

この手の需要はすでにIntenet message headerなどで存在し、かつ実装もあります(From: の内容で検索できるなど)。

Re:初心者の敵だ

[brake-handle (5065)]

うーん、私の近くにもJavaを勉強している人がいるんで(私自身は使ってない)いろいろ話が聞けるんですが...

文字列というのは現代の(あるいは昔から?)計算機では数え切れないほど多くの場面で使われています。とならば、ある局所的な部分だけで高い機能を実現しても、現実に存在するほかの部分との整合性をとらなければオモチャで終わってしまいます。Javaが世の中の全てになればいいですが、おそらくそうはならないでしょう(C当たりは永遠に残る可能性が高い、こいつがないとOSが書けないので仕事にならん)。

ところで、複数localeは何に対して定義しているんでしょうか? UTF-16じゃlocaleなんて概念は要らないし、もし部分文字列に対して定義できるというんだったらiso-2022と全く変わらない。あるいはlocale情報を持つオブジェクトがあるのかも知れないが、localeを切り換えるやり方とどう違うのかよくわからない...

Re:初心者の敵だ

[Anonymous Coward]

Locale とエンコーディングは本来は直交した概念だよ。 C ロケールではロケールにエンコーディングわりふってる けどね。仮にすべてで UTF-16 をつかってても Locale 的な考え方は必須。

んで、Javaでは、Locale関連情報を扱うクラスが あって、任意にオブジェクトを生成できます。 それを引数にとることで、日付とか数値の書式とか メッセージ処理とか、文字種判定とか、メッセージ 境界判定とかとか、文字列の比較処理とか、GUIで 扱うフォントとかの挙動を部分的に変更できるわけ。 もちろんC的にデフォルトロケール指定もできますが、 もし、Cのように系全体での変更しかできないと、 アプリケーションの動的な追従ができないのね。 ストリームのエンコード指定はロケールとは別に できます。Cではこの種の処理はロケール非依存の 従来のストリームとiconv 使えばある程度は いけるけど、書いてると死ねるし環境依存が激しい から使いたくならんですな。 C/C++の少なくともエンコード処理周りを java 並に しようと思うなら、IBM がJava と機能的に同等の クラスライブラリを提供してるので、それを使うと いいんじゃないかな。 局所的に高機能でも･･･のくだりなんだけど、現実では 他と整合とる必要なんてないと思うよ。局面に応じて 必要十分な能力が発揮できる言語をつかえばよいだけ のこと。Javaがすべてになればなんて考える こと自体ナンセンス。

Re:Unicode がもたらすものは

[redbrick (4865)]

なんでこのコメントがScore:-1なんですか？
＃非常に参考になったと思ったんですけど・・・。

ちゃんと目開けて、頭動かして見てます？＞モデレータ諸氏

--
---- redbrick

wchar_t (Re:i18n の範疇ならば)

[rug (55)]

何も iconv や Unicode に関わらずとも wchar_t⇔char + メッセージカタログで 十分ではありませんか？

これってportabilityあるのですか? 今でもOpenBSDみたいにmultibyte localeに対応していないシステムがあるし、そもそもwchar_tが1 byteしかない環境さえある。WindowsもNTは問題ないけど9xはmbからwcに変換できなかったと思う。

技術者の負け

[wawawa (3653)]

若かりし頃、わたしも「英語でいいじゃーん」な人だったんで
お気持ちは分かります。

でもね

学校で子供たちがWebページ作りを学ぶ、という実習で、
現在のWebインフラでは、安心して日本語のディレクトリ名や
ファイル名を扱えない。結局子供にローマ字でディレクトリ/
ファイル名をつけるよう指導した。

こんな話を聞くと、ソフト屋の端くれとして、悲しくなります。

# もちろん特定環境に限定すれば日本語OKですよ。
# IIS + IEとかね、でも、本件は Apache

これ自体はURLのエンコードの話なんで、直接UNICODEの話題
ではないし、UNICODEが全てを解決するとは思わないけど、
世界中の人が自分の言語で普通にコンピューティング可能な
環境を作るってのは崇高かつ重要な目標だと思いますよ。

できれば美しい機構がいいけど、現実に困っている人がいるの
なら、ベタな方法だろうとその解法を提示するのも、また
必要な事です。

Unicodeは避けて通れない

[rug (55)]

MS Office文書やXML文書を扱おうと思ったらUnicodeは避けて通れないと思いますが。

off topic

[rug (55)]

私は内容よりも表現の仕方の方が重要だと思いますが。 やはりいくら素晴らしくても相手に届かないと。

相手にもよると思いますが。というか、どんな表現でもそれが届かない相手というのは存在し得るでしょう。いちいち気にしていたら何も書けなくなると思いますが。

それに、表現をどうとらえるかというのは読み手自身の問題だと思いますが。ある文字列を見てカッとなったことがモデレートに影響を及ぼすなんて愚の骨頂です。

Re:ISO-2022とISO-2022-JP(いわゆるJIS)

[nekopon (1483)]

Unicodeの利点って

日本語でも中国語でも毛沢東が一発検さ(もういい

# というネタはともかく、↑がうれしいかどうかは、大いに疑問に感じています。必要ならシソーラス用意すればいい話でしょうに。

Re:wchar_t (Re:i18n の範疇ならば)

[oku (4610)]

OpenBSD だと、昔の Linux (libc5) みたいに X の locale を代替品に使えないんでしょうか？
# 実は自宅の Slackware を OpenBSD に差替えようかと
# 妄想してたんですが...

Re:Java V.S. C (Re:初心者の敵だ)

[zeissmania (3689)]

＞ライブラリ／実装なんかはいくらでもある訳だし
だから問題なんじゃないかと思いますけど (^^;;;
統一したライブラリ/実装にならないと「解決」にはならないでしょう。
そういう意味では「選択肢のない」方がましな気もしますよ。
＃Unicodeがましな選択とは思いませんけどね。

Re:英語なんて所詮ヤンキーの言葉さ

[char (1245)]

人口からいうと、中国語だと思う

北京語と広東語の違いは方言の域を超えているという話だ。
「中国語」としてひとまとめにするのは乱暴ではないかな。

--
char *A;
モータースポーツ部 [slashdot.jp]

Re:i18n の範疇ならば

[oku (4610)]

確かに ISO-10646 を指示するための ISO-2022 エスケープシーケンスが ISO-10646 側の文書で定義されていたような 記憶はありますけど...
あれって使用は推奨されないんではありませんでした？

Re:ISO-2022とISO-2022-JP(いわゆるJIS)

[argon (3541)]

日本語でも中国語でも「花子」が一発検索。

さて、モデレートはどうくるかな？

Re:ISO-2022とISO-2022-JP(いわゆるJIS)

[argon (3541)]

＞「意味が違うのに，字面が同じだからといって，違うものが一緒になってしまうのはおかしい」という話だと思います．

おかしいと思うのは、言語を指定しないナンセンスを無視して字面で検索しようとすることに意味があるのだろうかという点です。
grep 毛沢東 が嬉しい方は、英字「Ａ」ギリシャ文字「Α」ロシア文字「А」が統合されていないことをどう考えるのか、
Unicode の豊富な「空白文字」はどう考えるのか、というあたりが気になります。

Re:ISO-2022とISO-2022-JP(いわゆるJIS)

[argon (3541)]

詳しい説明ありがとうございます。

漢字は言語によらず同じ script と見なされているので統合されています． (そこで，日本語と中国語を同じ script と見なすかどうかで意見が分かれるのです．)

「ラテン文字とギリシャ文字とキリル文字」を分けるように、日本漢字、簡体字、繁体字を分けるという話であったらよかったのに。
16bits に収めようとして Unification が行われたそうですが、日本も中国も文字追加の提案をしているそうですし、これでは UTF-16 は I18N の選択肢にしかならないような。

他人に売れる物が作れるか

[naka64 (4590)]

ということを念頭に置くと、金田研究室ならいざ知らず、国内の顧客の連絡先を蓄積するような用途で「英語だけ」を扱うプログラムというのはその出力を結局人間が手作業で解釈し直さなければならない欠陥を持つため、十分な利益を得られないと言う意味で「他人に売れる物は作れない」ということになるでしょう。
日本語処理については「避けて通れない時にどうするか」という仮定を置かないと収拾がつかないと思う。
Unicodeも、Ext-Bあたりのレパートリに対する要求は決して少なくないレベルに来ていると思う。ただ、まだ日本語処理でUnicode以外の手段を取る余地はあると思う。
というわけで、親コメントには「んなもの売れない。だからご提案は謹んで無視させていただく。」としかならないと思う。以上。

Re:i18n の範疇ならば

[kyle (3923)]

同意。Linux の各ディストリビューションでも、 UTF 化のモチベーションが高まりきらないのは、 現状で足りているからだと思います。

i18n で足りている人に UTF 化の モチベーションを与える論理を、だれか頼む！ お願い、マジで。移行したいんだもん。

Re:あなたには（Re:ＵＮＩＣＯＤＥなんて）

[Anonymous Coward]

locale.h がないと、Single UNIX Specification に準拠できませんので、準拠するためだけに存在する可能性は高いです。

Re:i18n の範疇ならば

[kyle (3923)]

（シフトを用いる 7bit 符合の ISO-2022 エンコーディングに 話を限らせてもらうと） grep ができません。

fixed width iso2022

[Anonymous Coward]

NetBSD current の iso2022 rune みたいに、iso2022 の実用上十分なサブセットを作って、wchar_t にマッピングする方法論が実用的です。
# 日本では、割と昔からやってるんだけどなぁ。
# 上の rune の元になってる nvi-m17n とか、
# XMulti の HTML モジュールとか。

Re:i18n の範疇ならば

[redbrick (4865)]

>ISO-2022-JP は、エスケープシーケンスがうっとおしくて、
>内部処理（切ったり貼ったり）に向きません。伝送用です。

あのー・・・EUCはエスケープコード使ってないって、ご自分で示された
リンク先に書いてあるんですけど(汗)。

ISO-2022という大きなくくりで考えるなら、もっと実際に使われる
encoding側に話の焦点を移さないと論点がぼやけませんか？

＃個人的には、内部コードに特定のencodingをそのまま使うのって
＃意味のないことだと思ってます。
＃現状はencoding方式間の変換からは逃れられないし、
＃Unicodeで世界統一なんて、現状は夢のまた夢だし。
＃それに、真の意味でのm17n文書なんて作るとき
＃(英語と中文と日本語が混じった文書など)に、Unicodeって、
＃それらをテキストレベルできっちり識別して表示できるんですかね？
＃それができなけりゃ、「単なるもうひとつの選択肢」ってだけで、
＃Unicode使う意味なんて見いだせないのだけど・・・。

--
---- redbrick

M17N 化がどれくらい必要ですか？

[Anonymous Coward]

> UCS-4はいささかオーバースペックに見えます

素晴らしい洞察 :D
Unicode の筋の悪すぎるところはここなんですよねー。

世の中文書ごとに 1 言語しか使わないことのほうが多くて、せいぜい文書ごとに言語が切り替えられれば十分な場合がほとんどなんで、M17N 化に伴うコストは、M17N という、使用頻度が非常に低いものが必要な奴らが極力背負うべきなんですが、Unicode は I18N のレベルで十分な人々にも大きな負担を背負わせるコード構造なんですね。
新しく M17N 向きのシステムを作るとしたら、M17N も見据えつつ、でも、一番使用頻度の高い 単一言語下での利用がなるべく軽く行えるように熟慮するべきなんですが(その分、M17N が必要な時に要求リソースが余計に大きくなったとしても許す)、Unicode はそうなってませんねー。

で、組み込みだとこれはそれなりに重大。あと、UNIX 限定の話をすれば、Unicode べたべたにしたいんなら、今の X のフォントの仕組みを棄てないと辛い。

Re:あなたには（Re:ＵＮＩＣＯＤＥなんて）

[Anonymous Coward]

> LANG=ja_JP.romaji を使う覚悟があるのですか？

それは英語ではない :D
# 用字と言語は別です。

Re:i18n の範疇ならば

[Anonymous Coward]

> ＃(英語と中文と日本語が混じった文書など)に、Unicodeって、
> ＃それらをテキストレベルできっちり識別して表示できるんですかね？

Unicode の言語タグを使えばできますよね。
言語情報を入れられない ISO-2022 よりはかなりマシかと。

枕は高くして寝たいものだ

[Anonymous Coward]

1 The Unicode Standard, Version 3.0 を買う
2 The Unicode Standard, Version 2.0 を古本屋で買う
3 The Unicode Standard Worldwide Character Encoding. Version 1.0 の 2 冊本を根性で入手する
4 JIS X 0221-1:2001 の規格票を買う
5 JIS X 0221-1995 の規格票を入手する
6 ISO/IEC-10646-1:2000を取り寄せる
7 ISO/IEC-10646-1:1993 を図書館で借りる

で、こいつらを枕にして寝る悪夢を見てさらにunicode.org のこんな頁を見ちゃったりして結局 RFC 1815 しかないんぢゃない ? とかうそぶく。

はい。というわけで規格オタクの出来上がり (^^;

Re:i18n の範疇ならば

[redbrick (4865)]

>Unicode の言語タグを使えばできますよね。

ふーむ、やはりそういったシステムは作られているのですね。
＃ちょっと安心・・・。

ちなみに、現状の8bitコード体系でどうやってそのような追加情報
(ですよね? 本来encodingに関わらない、地域、言語範疇の情報の追加だし)
を入れているのか、方式等について、ポインタだけでもお教え願えませんか？
＃Unicode規格書読んだら載ってます？
＃それともISO-2022の最新の規格書にあるのかな？
＃UnicodeもISO-2022の規格に入るはずだったと思うけど、違ったかな(汗)？

--
---- redbrick

Re:ＵＮＩＣＯＤＥなんて

[baby_face (5007)]

でも、真剣に英語を地球人の公用語にすれば
いろいろ便利でいいのになぁ、なんてことは
ありますね。

んで、我々にとって日本語は、第二国語。

ここはひとつ……

[Dark Knight (5476)]

　超漢字を標準にしてしまうのダ。

＃もちろんオープンソースで。
＃でもUNIX用がないのね(^^;)

--
/* Written by Takayuki Masuda */

ユーザーを見ないプロダクトに

[Nowake (5100)]

意味はない．
何のためにプログラムを作ってるの？

アルファベットならいいけれど

[Pooh (4850)]

アルファベットだけ字形が同じでも元の言語が違えば別コードを割り振ってるわけですが、
モンゴル文字とかは字形が同じならunicode的には同じコードですよね。
「wa」とよむ「は」と「ha」と読む「は」は日本語の場合なぜか字形ベースで同じコード番号なのですが
「ha」は文頭に来ないからソートとか助かってますよね。
これがあっちこっちにある言語の処理は泣き泣きです。
デバナガリというかインド系文字も中途半端に文字合成が前提ですが
合成規則はタミル語とか使用言語によって違うのでアルファベットなみに別にコードが欲しいな。
言語タグだとタグ位置をフォローしないと切り張りできないからiso2022以上のメリットないし。
昔、部首から漢字を合成するフォント処理系がありましたが、漢字ですらこけたわけで。
いっそunicode＝フォントメーカー用字形カタログコードと定義してくれた方が楽です。
pdfなんかは内部処理コードと字形コードは全く別ですね。

記事の体裁？

[redbrick (4865)]

オフトピに反応してすみませんが(汗)、ご説明いただきどうもありがとうございます。
＃わたしとしては、もっとi18n/m17nの話を進めたい/読みたいんですけど・・・。
＃Unicodeの話も結局そこが一つの大きな話題の焦点だと思うし。

>真相はわからんけど、文章の最後が 2chの吉野屋ネタだったので、
>それを嫌った人がいたのかもね。
>あるいは、ネタの体裁を取るなら、もっとうまくやれ。
>ってことかも。

つまりは、内容吟味せず表層だけ見て判断したというわけですか・・・。
＃質低すぎ(汗)＞さっきのモデレーション

わたしは2ch利用者じゃないんで、元コメントの何がどう悪いか、
何に対して過敏反応したのか、はっきり言って理解できなかったんです。
情報量や参考意見としてなら、評価に値するものではないかと思ったのです。

ま、納得できない意見の表明に対しては、わたしは積極的に批判するつもりですし、
他の方がモデレーション上書きし直したみたいですね。
＃しかし、メタモデレーションは時間が経ちすぎててあまり意味をなしてないよなぁ。

--
---- redbrick

Re:i18n の範疇ならば

[argon (3541)]

IBM DOS 2000 の売り文句に ユーロ記号対応とあったような。
あれは Unicode ではないと思いますが。

日本における辞書順

[kMak (6359)]

＞スラッシュドットって
＞トップページからはずれても発言が続くんですね。

いや、モデレーション全然付かないあたりからして、大多数には忘れ去られてる。

＞国語辞典では熟語の記載は文字順でなくて５０音順ですよね。
＞「有明」と「有名」は全然別のページです。

考え方が微妙に間違ってます。
手元の「新明解国語事典・第三版」の「編集方針」を見たら明記はなかったんですが、国語事典の排列は、暗黙の『大前提』として、見出し語の見出しへの表記は仮名で正規化し、(その仮名による) 見出しに従って配列を決定する、ことになっています。この新明解には先頭に「漢字索引」という、漢字から索ける索引が付いてますが (^^;

ちなみに、ありとあらゆる、ありうる読みに対して重複コーディングし、コードに従ってソートすれば読みによるソートが完了 ! という凶悪な技もあります。つまり、コード順に文字を見ていくと「荒→有→或」というような並びがあって、さらに「唯→有→床」というような並びがある、というように。つまり、入力する時には正しい読みに合ったコードが入るようにしないといけない、ということ。OCR には文章認識が必要ですね。熟字訓もうまくコードを振ってやれば対応できます。

日本語でやろうとするのは事実上不可能ですが、この世には既にそのようにして作られた重複のある規格が実在します (KS X 1001・既に TRON コードに既収録。どうすんだ ?)

--
640K バイトはだれにとっても十分と思われたそうな

Re:各国語でのファイル名のあり方は？

[kubota (64)]

＃ここでのEBCDICって、文脈に合わない気がするんですけど(汗)、

いえ、そうではありません。現在、EBCDIC を使っている人が非常に少なく、ASCII (およびその上位互換なエンコーディング) を使っている人がほとんどなので、ASCII 以外を無視してものごとを進めることが多いわけです (たとえば、ASCII をファイル名に使い、それを誰かに送っても構わない、ということ)。日本語がファイル名として利用可能になるには、同じように、日本語を含むエンコーディング (たとえば、EUC-JP、UTF-8 など) が現在の ASCII と同じような地位に立つことが必要です。日本語を含むエンコーディングの中で、将来世界中で使われるようになる可能性があるのは Unicode でしょう、ということです。ただ、いまの議論ではそれを実装する手段が Unicode かどうかというのはどうでもいいことで、仮に世界が ISO-2022 でまとまりそうな気配であれば、ぼくは ISO-2022 を推したことでしょう。

それに、多くの小学生が、何の疑問もなく日本語名のファイルを使うような事態は、 わたしはむしろ避けるべきだと思ってます。

＃最低でも、日本語実装ありで、理由とマナーを一緒に教えないとダメ。

ただ、日本語名のファイルが作れるから取っつきやすさが上がるってのは、完全に同意です。

＃しかし・・・、日本語圏だけでそんな限定された環境作るみたいな事してていいんですかね？
＃かえって、子供が触れる世界を狭めてしまってないか、ちょっと不安も感じます。

この件については、ファイル名とファイル内容との区別は意味をなさないです。ファイルは内容が見えてこそ意味があるのですから。ファイル名とファイル内容とが決定的に違うのは、削除やコピーができるかどうか、というだけであって、しかもそれは「間違って」送られたときに限ります。日本語が読めない相手に配慮して英文字のファイル名をつけた、日本語の内容のファイルを故意に送るなんてことはありえません。

で、日本語でファイル名やファイル内容を書くことができれば、世界が狭まりますか? 日本語で書くことを強制されれば、狭まるでしょうが、それだと、ファイル内容を日本語で書くのも「マナーが悪い」としなければなりません。ぼくは日本語のファイル名も Windows 上なら使いますが (UTF-8 に移行すれば Linux 上でも使い始めたいと思ってます)、ぼくは狭い世界に生きているのでしょうか。日本語を使うと英語能力が低下する、なんてことでもない限り、そんなことはありません。

比率がわずかというのは、何に対して想定していますか？

世の中のあらゆるファイルを、以下のように分類したとします。

• まったく個人利用のファイル
• 同じ言語圏の他人と共有するファイル
• 違う言語圏の他人と共有するファイル

問題になるのはこの 3 番目だけですが、その割合が小さい、というつもりです。日本語を使うのは確かに世界の 1/50 くらいの人口ですが、中国語を使うのは世界の 1/5 くらいですし、ほかにもいろんな言語があります。かれらにもかれら自身の「個人利用」「国内利用」のファイルがあるので、全世界を見ても、上記分類の 3 番目が少数なのは同じです。

nativeがascii文字であるファイルシステム上で日本語を使うってのは そういった制度上の制限に逆らっているようなものだと、ふと思ったんですが・・・。

nativeがascii文字であるファイルシステムというのがどういう意味かわかりませんが、ascii文字以外も使えるように拡張しようというのが、ぼくが何度も書いてきた「開発」の意味です。ですので、その「制度」そのものの改変を目指していると考えてください。

いえ、そこまで考えておられたとはわからなかったので、先のコメントを書きましたが、 そういった方法があれば、基本的な部分では問題ないと思います。

＃ただ、その方法をどうやって日本語圏以外に広めるか、が一番の問題だと思いますけど・・・。
＃用意してあっても、使い方が普及しないと意味ないし・・・。
＃少なくとも、日本語圏以外にも旨味を保たせないといけないですよね？

そんな、日本語だけなんてケチなことはこれっぽっちも考えてません。世界各国の人が自分自身の好きな文字を使えるようになればいいなと思います。ですので、日本語圏から外に広める、ということが課題になるとは考えていません。日本語のためだけの仕組みを考えてそれを世界中の人に使ってもらおうなんて、そんな不公平な考えは持っていません。

ただし、ワイルドカードの拡張、とかについては、べつに具体的なアイディアがあるわけでもないし、ぼく自身は特に必要性を感じていません。ないよりは、あるほう