トップページ⇒linux
857コメント312KB

EUCボクメツ委員会

■ このスレッドは過去ログ倉庫に格納されています
0001ﾓ･ｸ･ﾍ･ｹ菽ｦｯ01/10/16 00:18ID:ZujZqkcr
Javaとかのマルチプラットフォームなアプリでも文字コードをいじらないと化けるし。
ICQクローンで Shift_JIS<=>EUC の相互変換をするように加工とか小細工して使ってるのには泣けたＹＯ
せっかく多言語対応の環境で作られたソフトでも日本ローカルのパッチ作んなきゃいけないんじゃ
意味ないじゃん！
Winに比べて少ないアプリがさらに選択肢が狭まっちゃってどうしようもないYO
Linuxにおける日本語の標準コードはWinに倣いShift-JISをメインにすべきである。
0237login:Penguin01/11/15 12:50ID:UTucAaiV
日本語の文章書くのにＵＳ−ＡＳＣＩＩ（ＪＩＳ　Ｘ　０２０１）使わず
にＪＩＸ　Ｘ　０２０８のみ使う。ただし、引用したプログラムなどでは
ＵＳ−ＡＳＣＩＩのみ使う、というのもありかな。

main() {
printf("Hell, world\n");
}
0238login:Penguin01/11/15 13:38ID:U4qiuSGu
?
0239login:Penguin01/11/15 15:14ID:o+BuNf25
「『全角半角』というものは文字コードに含まれない」とかいいつつ
jisx0208 のアルファベットを使うと「読みにくい」って言うのはヘンじゃない？

「Ｘ−Ｗｉｎｄｏｗｓが動きません」
「違います。X Window System です。あとアルファベットや記号は...」

なんてやりとりを何回も見る。
0240login:Penguin01/11/15 16:32ID:U4qiuSGu
>>239
分かっていると思うが、X-Windowsなんてものは存在しない。
0241login:Penguin01/11/15 17:30ID:ybZRG6lR
>>239

ヘンではない。文脈が違うんだっちゅうの。

文字コードについての議論をしている時に、
全角とか半角とか関係ない概念を持ち込むな、
と言うのと、
( Unicode に FULLWIDTH LATIN CAPITAL LETTER A
とかいう連中がいてさらに話がややこしいのだが。
(コードだと FFxx の処) しかもこれ JIS X 0208 の
記号の救済になってないのよね )

日常のメッセージ交換について、ISO 646 の文字集合に
ある文字を使って構わない文字についてはそっち使え、
というのと、矛盾してないぞ。別に。

しかも >>239 が例示してるやりとりは基本的に
ローカルルールの話。混同すんなよ。

このスレには「半角カナあぼーん」を日頃広言してる
奴が多そうだが、べつにこのスレでは (使ったからって)
何も言わん、それと同じ。

見栄えの問題として“「C 言語」”を“「Ｃ言語」”に
したりする、なんてのはけっこうあると思う。

昔は個人のポリシーとして JIS X 0208 で全部書く
なんてひともいたそうだけど。
0242login:Penguin01/11/15 18:17ID:SZoZtT5l
>>241
mohta さんですな
0243login:Penguin01/11/15 23:44ID:DaDunDH3
日本語の proportional font ってあるんですか?
0244login:Penguin01/11/16 01:17ID:SlO5AIlX
>>243
スレ違い。
まぁ243は MS P Gothic でも使ってなさいってこった。
0245login:Penguin01/11/16 02:29ID:1EP3otcQ
>>225
こんな、電波受信しまくってるシロモノに検証もクソもねーだろ。
ASCIIが129文字あると主張してる奴の相手するだけ時間の無駄。
024622501/11/16 08:41ID:WZsLOO+O
>>245
＞ASCIIが129文字あると主張してる奴の相手するだけ時間の無駄。

俺もそう思ったから自分で検証しなかったし、
検証してない以上、感想的評価しか書けんからね。

ちょっとたずねるが、例えば当用漢字に関わる告示を
全部、今ここで列挙してみろと言われてできるか ?

できないならその「シロモノ」に書いてある、
当用漢字に関する事項については、どこが偽で
どこが真か判断できない筈だが ?
0247login:Penguin01/11/16 16:59ID:JBbeQ7F0
>>246
ヘリクツはやめよーよ
024822901/11/16 21:28ID:Aqdg8YXQ
>>232-236
ご回答、ありがとうございます。。m(_ _)m
色々と参考にもなりました。

ああ、なるほど。。
文字コードが1つだけだったとしても、厨房は減るとも限らないのですね。
言われてみれば、そういう気もしました。

それから、「Ｓｈｉｆｔ−ＪＩＳ」の部分だけ全角英数なのは、
わざとやりました。Ｓｈｉｆｔ−ＪＩＳを馬鹿にしているという意味でもありまして。
唯、日本語OSとしては、Shift-JISは、使いやすい感じなのでしょうかねぇ?

・・・ところで、メルマガで全角英数が沢山使われている
ことについて、どのように思います?

あと、BIGLOBE でも、全角英数が結構使われていたような
気もしたのですが、なぜなんでしょうかねぇ?
0249login:Penguin01/11/16 22:26ID:x9gi1zY9
Unix 使っている人は全角英数を嫌う人が多いけど,
それは単なる好き嫌いの問題だと思う.
こういうことで人を馬鹿にして優越感を得るのはいかんよ.
0250login:Penguin01/11/16 23:16ID:ADpYy+ve
だって読みづらいし検索しづらくないか
0251login:Penguin01/11/16 23:24ID:/sHDqI0/
>>249
嫌われた最大の理由は
-sony-fixed-*-16- と -misc-fixed-*-14- の 0201 の書体デザインが残念すぎたから

という主張をﾋｿｰﾘやってみるテスト。
0252login:Penguin01/11/17 07:55ID:gZOX3LLK
そういえば、かつてのk14の全角英数の書体デザインはなぜかボールド体だったな。
東雲では直っているけど。
あと、BTRON(超漢字)は、デフォルトで英数が全角だな。読みづらいと思うんだが。
0253login:Penguin01/11/17 08:23ID:bbmeDPw2
>>251
0208 ね ?
多分前者は s/-sony-/-jis-/ だと思うが。
JIS X 9051-1984「表示装置用１６ドット字形」
ちなみに「１６」が「16」でないのは、
jsa.or.jp のデータベースの頁からのコピペだから。

>>252
k14 のあれは逆に識別性を上げるために、
わざとやっているのだと自分には思われ。
0254login:Penguin01/11/17 08:36ID:bbmeDPw2
>>252
TRON コードには 0201 も ASCII も 646 も
入ってないんだわ。Unicode2 経由でもって一部に
あるけど。(だから 0201 カナが FFxx にあるぞ)

要するに全角文字・半角文字っていう区別の
コードレベルでのパージを意図してたんだわ。
だから「半角」は、文字拡大/縮小指定付箋で
幅 1/2 を指定して実現されてる。(TAD をダンプ
すりゃわかる) 要するに 0208 の文字を縮小
してるから「ヴ」の半角なんてのもアリ。

で、デフォルトではどんな文字でも全角で表示
しちまうんだが、一部アプリ (コンソール等)
は、0201 の左側にある文字を適当に半角にして
くれたりするんで (ブラウザの一行フォームなんかは
なんでも半角だが) 余計ややこしい。

ま、最近のブラウザとか基本文章編集とかは
プロポーショナル表示に対応しとるよ。
元々半角なのをプロポーショナルで見ると
それはそれで悲惨だが。

純粋にジャポネスクな OS を作ろうとした研究が
他にもあって (IPSJ の論文漁ってみな) それなんかは
0208 オンリーで CHAR_BIT が 16 だか sizeof(char) が
2 だかの (後者だと標準から外れるが) Ｃ言語処理系から
自分達で作ったようで識別子とかに好き放題 0208 が
使えたらしい。
0255login:Penguin01/11/18 03:14ID:VeGGFsw1
>>254
> 純粋にジャポネスクな OS を作ろうとした研究が(略)

農工大のOS omicronかな。
0256login:Penguin01/12/18 21:48ID:61X7j+2e
みんな忘れてないか？age
0257login:Penguin01/12/21 06:06ID:o684insm
良スレ age
0258login:Penguin01/12/21 10:58ID:7GMumlLM
>>257
クソスレだ。ageるな。
0259login:Penguin01/12/21 11:51ID:rzRakEP/
age
0260login:Penguin02/02/04 12:41ID:m17eMVoW
不治痛age
0261青木光恵02/02/06 01:26ID:07Li/whj
青木光恵
0262login:Penguin02/02/06 01:36ID:+3nKE+HU
ダーヤス写真集age
0263login:Penguin02/02/07 13:39ID:12+BCoHT
んー。
文字コード云々の前に「コンピュータ上で扱えたい日本語」を
全部選定（？することは既に完了してるんでしょうか？
「正」の字とかは一画ずつ全五画分必要そうだし
偏だけ、旁だけってのも将来を見通せば必要そうですけど
出来てるんですかね。
0264login:Penguin02/02/07 18:12ID:0AxTDb5J
X向けのcharsetはISO 2022だったよね。
0265login:Penguin02/02/07 20:36ID:txThOpuJ
とりあえず >>15 は嘘。
HP-UX も Solaris も日本語環境を入れる時の
default は SJIS です。
0266login:Penguin02/02/07 20:40ID:txThOpuJ
よーしパパ LASER5 7.2exp の不具合張っちゃうぞ。
http://www.laser5.co.jp/support/l5linux/faq/72exp/index.html (Q6)

使う使わない、個人の好みの問題は別にして
ちゃんとサポートしれ。
0267login:Penguin02/02/09 16:35ID:CI8k4gxh
まあ、Shift-JISみたいな腐れフォント使ってる奴は死ねってことで。
0268login:Penguin02/02/09 16:37ID:9Rjes/Sh
フォント関係あんの？
0269おむこさん志望 ◆GqCwfDSA 02/02/09 17:18ID:QaOYgbNI
>>267
ShiftJISはフォントじゃなくてエンコーディング。
自分でsjisロケールを生成してやればja_JP.SJISでも使える。
0270login:Penguin02/02/09 18:12ID:KVJYho4s
まあ、UTF-16 みたいな腐れエンコーディング使ってるOSは氏ねってことで。
0271login:Penguin02/02/09 21:57ID:gwaFMMy6
>X向けのcharsetはISO 2022だったよね。
何度も何度も何度も何度もガイシュツなように、2022はcharsetではありません。
encoding schemeです。萎えsage


0272login:Penguin02/02/09 23:19ID:5njPVTaC
HTTP で charset= に encoding を書かせるのが誤解をうむ
元だよな...

0273login:Penguin02/02/11 23:09ID:X+cO8gdB
元はMIME。
0274login:Penguin02/02/16 22:54ID:KpHa2nOV
age
0275login:Penguin02/02/16 22:58ID:wiE/aMYf
>>265
Solarisでは、インストール時にUnicode・EUC・SJISのどれかを選択しなきゃいけない。よって、defaultなんてありません。
0276login:Penguin02/02/19 18:13ID:E1V3iarF
age
0277login:Penguin02/02/20 02:17ID:D4zYH0HU
もう面倒だから全部UCS-4で処理しませんか？
0278login:Penguin02/02/20 02:47ID:NRixr7wa
>>272
ふと思ったけど、その表記ってISO-8859圏の人間だけが利用するのを想定してるっぽいな。
ISO-8859系列って、文字集合＝文字エンコーディングだから。
0279login:Penguin02/02/20 08:09ID:E3jll45S
もう面倒だから全部256ビットで処理しませんか？
1文字 16x16 ドットで。
0280login:Penguin02/02/20 14:11ID:dIlnqa5O
>>279
それは便利だ。
けど、そうすると検索性に劣る等の副作用も含む諸刃の剣。

議論が堂々巡りするなぁ、本当にこの話題は…


固定長でエスケープシーケンス無しのエンコードだと拡張性に劣る
↓
エスケープシーケンスで自由に文字集合を切替えられるようにすれば可能性は無限
↓
そうすると、文字列の任意のバイト列を取り出しても判別不能、
最初から最後まで嘗めなければ処理できなくなり、
プログラマの負担増大
↓
じゃあ、いっそ巨大な平面に全部の文字を詰めて固定長で全部処理しよう
↓
異体字を無限に許すことになり、テキストデータ等が溜っても後から検索できない
↓
じゃあ、平面を狭めよう
↓
最初に戻る (ﾟдﾟ)ｳﾏｰ
0281login:Penguin02/02/21 19:15ID:WoLsJseW
>>278
>>272にあるようにMIMEが源だけど、
MIMEってheaderに使うencodingでの空白の扱いが、
単語を空白で区切る分かち書きの世界しか意識してないじゃん。
それって結局ISO-8859圏なわけでしょ。

MIMEとUnicodeは日本からの働きかけに失敗した例だね。
0282login:Penguin02/02/27 10:34ID:Fz3oNkse
>>279
256ビットでは、異体字が多くなり易過ぎて検索が辛いです。
64ビットにしましょう。1文字8x8ドットで充分。少なくともX0208の区別は付くし。
区別が付かない文字は、包括すれば問題無し。（ｗ
0283login:Penguin02/02/27 12:57ID:5Le7VrIb
>>282
包括もそれはそれで問題だと思うぞ。
既にJISでもさんざん問題になっているが。
0284login:Penguin02/02/27 12:59ID:EMez+aas
全角英数とか半角カナとか、なんで廃止しないの？
ネット上のゴミにしかなってないんじゃ。。。
0285login:Penguin02/02/27 13:01ID:2qxooejq
全角英数はよく見る。需要はあんでしょ。
0286login:Penguin02/02/27 13:05ID:Fv8Z2UaF
「包摂」?
0287login:Penguin02/02/27 13:07ID:5Le7VrIb
>>285
見るか見ないかじゃなくて、必要かどうかを言いたいんではないかと。
意味合いも用途も同じなのに別のコードが割り当てられてるのは
プログラム上で同一に扱いたいとき面倒なだけでメリットが何もないし。

# まぁ、いまさら廃止したとしてもユーザが使い続けてる限り
# 撲滅はできないとは思うけども。。。
0288login:Penguin02/02/27 13:24ID:HUK2U80k
全角英数はデータ入力でも有害だから、
(データ処理側で変換するとしても)
IMEではdefaultで半角英数にしておけばいいのにね。

WindowsのPPP接続の電話番号設定ではよくあるトラブルの一つだな。
Dailup widzardが半角変換しないから。ユーザ名とかも。
0289login:Penguin02/02/27 23:41ID:xsQ6CV0u
>>280
そういや，
[0x80〜0xFF]x任意個＋[0x00〜0x7F]で１文字を表すようなコードって
誰も提案しないの？
＃まあ，UTF-8の変形ですかね．
これだったら任意数の文字を表現できるけど，プログラム処理は
そんなに大変にならないと思うんだけど．
029028902/02/27 23:48ID:xsQ6CV0u
自己レス
\とか/とか:とかのコードは外さないと危ないじゃん．
逝ってきます……
0291login:Penguin02/02/28 01:40ID:tMYcWs/N
文字コードとグリフを別々に管理するような
テキストの規格が普及してれば
全角と半角とで苦労したりしなくてすむのに。

ascii と JISX0208 で意味的に重なっている記号を
同一視するとかの問題もなくなるし。
0292login:Penguin02/02/28 03:52ID:hiYdbzc9
全角英数と半角カナはさっさと逝くべき存在。
「メールで半角カナは良くない」っていうのが広まる直前に、
DoCoMoのアホ共が!
ISO-2022-JPに含まれてねーだろ<JIS X 0201カナ集合
0293292の続き02/02/28 03:56ID:hiYdbzc9
IMEも罪重い。
上でも書いてる人いるけど、何故デフォで全角英数にする?
Justsystem何考えてるんじゃー。
それともなんらかのメリットがあるのか?
0294login:Penguin02/02/28 04:51ID:WilwHU5r
>>292
電話会社は今でもどんどん絵文字増やしてるね。

まあencoding schemeが滅茶苦茶なのはもう諦めるから、
せめてcharacter setをちゃんと登録して、
そのcode pointくらい発表して欲しい。
029529202/02/28 05:01ID:hiYdbzc9
>>294
絵文字は論外だと俺は思う。

しかしこれは彼女の話なんだが、
「絵文字をセンス良く使う人は好感がもてる」
有効性(?)って点からは、iモードの絵文字は功罪半ばするところだ。

DoCoMoの絵文字コードポイントは
http://www.nttdocomo.co.jp/mc-user/i/tag/emoji/
もうふやさんでほしい……
0296login:Penguin02/02/28 07:02ID:3yJTluRp
全角英数は、意味のある使われ方もしてますからねえ。
縦書きの時に、縦に書く文字と横に書く文字の違いとして使われている事がある。
そんなのは書式で表現するべきとの意見もあるでしょうが、書式で表現するべき違いか、キャラクターセットで違いを出すべきかは、文化による要素が大きい。

たとえば「…」は、英文の「...」という三点リーダ表現を日本語に取り入れ、縦書きの時に中央揃えになった記号です。
ですので横書きの時には、同じと見なされるべき文字なのです。
さらに「……」と「‥‥‥」という、日本で発達した六点リーダの表現方法が２種類あるキャラクターセットとなってしまっています。
これらに対して、書式で表現するべきで、キャラクターセットが間違っている、と言っても仕方無い話です。
全角英数字も同じ事ですよ。利用実体を認めないと、無意味な議論でしかないです。。
029729202/02/28 09:10ID:hiYdbzc9
>>296
後半は勉強になった。ありがとう

全角英数・半角カナは静かに消えていくべきものなんだから、
新しく「存在理由」を与えないで欲しい。
・(半角かなの場合)メールに文字をたくさん詰め込める
・複数行アスキーアートで使い分け
鬱……
0298login:Penguin02/02/28 09:49ID:qz/FHA4q
>>295
絵文字自体の存在意義と文字コードの割り当ては同一視すべきではないと思うよん。

漢字や平仮名等の文字よりも遙かに流行り廃れの激しい領域だから、
コードを割り振って一般的に使えるようになった頃にはもう必要なく
なっているという事態ではないかと思われるけど。
（それは画像として送ってくれってこと）

結局のところアナログな「表情」や「意志」をデジタルな文字として
表わすこと自体に無理があるといえばそうなんだけど。
029929202/02/28 11:12ID:hiYdbzc9
>>298
DoCoMoがSMTPをコミュニケーションの手段として選んだため、
画像を文章に混ぜるのは(不可能ではないが)難しい。
となると、既存の文字を組み合わせて作る「顔文字」という
方法があるわけだが、端末の画面サイズが決めうちため送信者の
意図通りに表示されないことが多々ありえる。
そのため(問題はあるが)「絵文字」を定義するのが一番コストが少ない。

上は俺の推測。
だから、DoCoMoが勝手に絵文字をぶち込んだのは理解できる。
# むろん納得はできないがな

しかしそれより問題なのは半角カナだ。先のことを考えたなら、
メリットよりデメリットの方が大きいと思うんだが……
0300login:Penguin02/03/01 00:46ID:9t6ixOpM
絵文字は文字コードとしては実際どこに
格納されてるの? sjis の空き?
030129202/03/01 05:04ID:rxMXOdIk
>>300
ユーザ定義文字(外字)用の領域のうち、後ろから10%弱に
つっこまれてる
0302login:Penguin02/03/01 11:27ID:LxuMhOts
>>300
>>295のURLを見よ。
0303login:Penguin02/03/23 12:57ID:qVojErfB
保全age
0304login:Penguin02/04/12 22:58ID:ee9Vglvq
age
0305login:Penguin02/04/19 17:08ID:IRZ7c+3a
age
0306login:Penguin02/05/19 00:25ID:SEv2YXyA
新coding-system提案：
iso-2022-2ch

世界初！各文字の文字幅比まで規定したcoding-system!
0x7e は tilda だが、何故か0x5cは円マークのこと。（藁

＃保全age。
0307unagi02/05/19 00:34ID:HWW5oL9x
unagi
0308login:Penguin02/05/19 03:01ID:mYPYUKFp
これどうよ
Coventive独自のGiga-Character-Set
http://www.coventive.co.jp/gcswhite.html
0309login:Penguin02/05/27 00:32ID:NWrtA+hm
文字符号の歴史 −アジア編−(ISBN4-320-12040-X)
三上喜貴著 Ｂ5変型判，384頁，7500円
http://kyoritsu-pub.topica.ne.jp/shinkan/shin0203_03.html

こんなん出るんだね。
0310login:Penguin02/06/03 22:25ID:SlwuhY0T
・1文字32ビットにする(Charactor Set = Encodingにする)
・UCS4を最初から作り直す

これで全てOKだよ。互換性問題以外は。
0311login:Penguin02/07/02 02:05ID:zRK+hHNj
賛成。１文字を４バイト（４オクテット）にすればよい。
C言語の文字を表す型名char をバイトサイズのデータ型と混同して
プログラミングで使うというスタイルが実に良くない。
既存のCで書かれたソースをすべてchar を byte という型名で置き換え、
Charという型名でもって、４オクテット文字をあらわす型名とし、
従来のアスキーコードは右端のバイトに埋め込み、Charが符号無しか
符号付であるかによって左の３バイトはオールゼロにするか、
あるいは右端のアスキーコードの符号付延長とする。
GCCを改造して、文字は４オクテットとして、データ―タイプbyteを
導入する。たとえばCのソース中に 'a' と文字が書かれていたら、
それは４バイトのデータになるし、"ABCD"と文字列がかかれていたら
それは全部で２０バイトになるという具合だ。
デバイスドライバーや通信プログラムには、従来の
コードとの変換フィルターを作ったりする必要があるかもしれない。
内部コードのみ４バイトとして、通信コードにはJISを用いたり、
必要に応じて圧縮をするべきかもしれない。。。。
ともかく、文字が４バイトの固定長であって、（出来れば符号無しか
符号付かをも含めて統一すべきだ）くれれば、ものごとは
実に単純明快になる。
0312login:Penguin02/07/02 04:50ID:yx04ZA8s
超漢字でつかってる文字集合って4byteで表せるの？
0313login:Penguin02/07/02 05:34ID:W8RRbPwE
>>311

１文字４バイトで、"ABCD"がなぜに２０バイト？
１６バイト？　それとも俺って何かぬかしてる・・・？
文字列終端のNULLも４バイトってこと？




0314login:Penguin02/07/02 10:11ID:J9ewXkSU
>>313
そだろ。
なにか問題でも？高々4倍だろ。しかも、中はスカスカだから、
圧縮率高いし。
0315login:Penguin02/07/03 23:19ID:4sQNVHL5
レス間隔が広いな（わ

Unicodeだのいう前に「シフトJIS」統一してくれ…。
せめて名前の峻別だけでも…頼むよ。
0316login:Penguin02/07/04 02:20ID:oPs3IW0a
CP932でいいじゃん。
0317　　　02/07/17 00:41ID:TeaEgqOV
４バイト文字コードのオープンソース、あるいはGPLのライセンスによる
OSとコンパイラが完成して広まれば、それが各国の言語で共通に使える
プラットホームとなりうる。相違点は、入力フロントエンドとか、
ワープロの文則、禁則の処理の仕様とか、かな？
＃
もしも３バイトで全世界の文字が十分に利用可能であるならば、
上の１バイトは書体をあらわす指定にすることもできるかもしれないな。
（ただ、そういうことをあまやらないほうがいいという考え方もあるな）
0318login:Penguin02/07/17 00:45ID:TK6Nax3r
>>317
できたら教えて。
0319login:Penguin02/07/17 03:31ID:tpoiTIS/
トンパ文字は3バイトで収まりきるのか？
0320login:Penguin02/07/17 14:34ID:ru8f1smn
>>319
超漢字で使えるやつ？
0321login:Penguin02/07/17 23:45ID:kNSTOrUx
>>319 日本玄米茶？ 「コシヒカリっ！」
0322login:Penguin02/07/19 02:49ID:PgHw/Khc
なんで半角カナはあるのに半角ひらがながないんですか？
0323login:Penguin02/07/20 00:52ID:b3Zy3R0n
>>322
なんでだと思いますか？
0324login:Penguin02/07/21 09:46ID:9P133XK7
>>315
いちおう、JISの1997年版で各社の違いが比較され、
JIS版のShift-JISが定義されますが？
0325login:Penguin02/07/21 12:27ID:h3ICbItJ
はるかな未来：

文字コードは 64bit
16bit 種類のベンダーが勝手に決めるコード体系に 32bit 種類の文字／グリフと 16bit 種類のフォント表現
ベンダーの管理するサーバが常時稼動
文書記述したいときは IME にどの語にどの読みとどのベンダーのどのグリフ列を与えるかの辞書を使い
文書を視認したいときはローカルなフォントでなくサーバからその都度フォントを引っ張ってキャッシュ

コード内の各グリフ、各コード間の各グリフで「同じ」か「違う」かを変換するサーバを用意
しかしハイフン様の文字、「か゜」と「が」、AとＡとАとΑを同じとするかどうかのポリシーは
ベンダーが勝手に決めてその多数決、ユーザー有志も常に多数決に投票可
マッチングのたんびに多数決の結果がどうなってるかサーバに問い合わせ

ｱﾋｬﾋｬﾋｬ
0326login:Penguin02/07/21 20:00ID:TcSW6VAc
>>325
多数決より、 option で指定できた方が良いな…
異体字の同一視とかも、その都度指定したい。
0327login:Penguin02/07/22 03:01ID:Wv+UJQXs
>>322
X68000にはあったはず。
1/4角文字とかも。
0328login:Penguin02/07/22 21:51ID:ZW0bDY+f
>>322

MSX にもあったぞ
0329login:Penguin02/07/24 01:18ID:6Xasd6b0
>>315
JIS X 0208:1997附属書1ですね。

せめて「増補改訂 JIS漢字字典」に収録の縮刷版でいいからJIS X0208と
JIS X0213を読んでから書き込んでくれ…頼むよ。
0330　　　02/07/26 15:10ID:hqzfU9HA
確かに、プロ―ドバンドで動画がやりとりできる時代には、
たとえ漢字全体の字の形状データ―といえども、
それほどたいしたデータ―量ではないな。
DNSのシステムのように、各国にその国のコードの体系と字形を
収めたルートサーバーがいくつかあって、階層的にキャッシュ
がされていて、最終的にはローカルマシン、あるいはその直上
にはその会社のフォントキャッシュサーバーへアクセスに
いけばよいということになるかな。文字が64ビットコードであるか
32ビットコードであるかはともかくとして、昔の磁気テープの
ANSIラベルのように、ファイルにはそれに付属したラベルが
あって、そこにどのコード体系（いつの時点、バージョンであるかも
ふくめて）で記述されているかを512オクテット程度の量で指定
したものを、外部公開用のファイルの基本のやり方とすると、
１０年２０年後に、古文章を開くときに、どの文字コードで読めば
よいかということを試行錯誤しなくてよいはずだ。
0331login:Penguin02/07/27 09:31ID:aH8wXR91
>>330
古文書だと、 server の維持が大変そう…
減多に使われないけど、無くなったら誰も其の言語の file を読めなくなっちゃう…
廃れて行く言語って、結構有るみたいだし…

大きさを気にしないなら、全部画像にしちゃった方が良いんじゃないかな。
font が無くても、見る事だけは出来るから。
0332login:Penguin02/08/06 08:27ID:mZ95nMRZ
ruby-talk(Rubyの英語ML)で面白い奴ハケン

http://www.ruby-talk.com/blade/45931
http://www.ruby-talk.com/blade/45933
以下同スレで発言多数

RubyのUNICODE対応に関するスレッドの中で、
Rubyを離れて日本人のUNICODE嫌いについて文句を言っている
I18Nにはそれなりに詳しくて経験あるようだが、
妙に鋭い所とアメ人特有の無神経さが同居しているような気がする

このスレのエラい人にこの人の意見に対する見解キボーン
0333login:Penguin02/08/06 16:58ID:wkw+ALMi
横槍すまソ
私的には、UNICODEはでっかいEUCとして使う利便性だけ得られるかと
実装はUNICODEのアホンダラ!!!!!
0334login:Penguin02/08/06 23:39ID:5RFCcanm
そしてEBCDIC+JISへの回帰

っていうか、[GI] [GO] マンセー
0335login:Penguin02/08/07 20:46ID:q4PusX4L
>> 332
UNICODEって、Ver 1とVer 3の間に互換性がなかったような…
0336login:Penguin02/08/07 21:12ID:1ua9JQMr
そう言えば「電」はどうなった?
■ このスレッドは過去ログ倉庫に格納されています