02/01/30 23:20.net
あ、任意のoctetって事ね。スマソ。
51:名無しさん＠お腹いっぱい。
02/01/30 23:22.net
>49
うるさいよ厨房。勉強して出直せ。
「お前のいうところの」シフトコードとやらは、少なくともEUC_JPにはあると思うぞ（げら
single shift で googleしる。
52:名無しさん＠お腹いっぱい。
02/01/31 01:18.net
>18
おおお。樋浦さんの原稿だ。
53:名無しさん＠お腹いっぱい。
02/01/31 01:25.net
M$一味のUnicodeがなければUTF-8がまともに
出来上がってすべて丸く収まったろうに。
54:名無しさん＠お腹いっぱい。
02/01/31 01:26.net
>53
そういうのを引かれ者の小唄っていうんだよ。
世の中理想論だけじゃ動かないんだから、政治的に立ち回れない方が
負けるのは性がない。
55:おねがい☆りなっくす
02/01/31 01:40.net
でもＭＳがコードを乱してくれたお陰でコード変換というお仕事に
ありつけたプログラマーもいるのれす。。。
わたし？むふふふふ。。。
56:名無しさん＠お腹いっぱい。
02/01/31 01:48.net
IT で生産性は上がらない、と。
57:名無しさん＠お腹いっぱい。
02/01/31 01:51.net
(◕ฺ∀◕ฺ)
>>49 URLﾘﾝｸ(euc.jp) を読むとヨイデスYO
58:31
02/02/03 23:08.net
>>34
UTFならOK。若干メモリ使用量が増えることが不満だが、そんな不満は今時古いか。
59:名無しさん＠お腹いっぱい。
02/02/03 23:22.net
どっちかっつーとEUC撲滅して欲しいよ。
60:過激派
02/02/03 23:37.net
日本語撲滅!!!
61:名無しさん＠お腹いっぱい。
02/02/03 23:39.net
>60
フランス語も。
62:歌劇派
02/02/03 23:45.net
漢字撲滅!!!
63:結構マジ
02/02/03 23:47.net
アメリカ撲滅!!!
64:名無しさん＠お腹いっぱい。
02/02/03 23:52.net
そして人類は滅亡した。
65:おれもﾏｼﾞ
02/02/03 23:52.net
今アメリカがいなくれなれば世界は平和
66:禿同
02/02/03 23:52.net
鬼畜米英!!!
67:諸悪の根源
02/02/03 23:55.net
ASCII撲滅!!!
68:名無しさん＠お腹いっぱい。
02/02/03 23:57.net
>67
Impressもついでに撲滅!!
69:名無しさん＠お腹いっぱい。
02/02/03 23:59.net
sb
70:名無しさん＠お腹いっぱい。
02/02/03 23:59.net
良スレあげ
と。
71:名無しさん＠お腹いっぱい。
02/02/04 00:03.net
週刊ASCII廃刊!!
72:名無しさん＠お腹いっぱい。
02/02/04 00:04.net
>71
噂の真相もついでに撲滅!!
73:名無しさん＠お腹いっぱい。
02/02/04 00:21.net
さすがにネタ切れか?
74:過激派
02/02/04 00:34.net
俺撲滅!!!
75:歌劇派
02/02/04 00:51.net
お前ら!撲滅!!!
76:名無しさん＠お腹いっぱい。
02/02/04 00:53.net
僕滅!!!
77:名無しさん@XEｍａｃｓ
02/02/04 01:07.net
>76
ﾜﾗﾀ
78:名無しさん＠お腹いっぱい。
02/02/04 01:26.net
おれ的には社内の負の遺産「JEF」をどこかにおいやって欲しい・・・
79:名無しさん＠お腹いっぱい。
02/02/04 01:42.net
>>76
やられた…
80:名無しさん＠お腹いっぱい。
02/02/04 01:49.net
>>49
EUC には一応 SS2 と SS3 っていうシフトコードはあるよ。
シングルシフトだからすぐ解除されるけど。
81:名無しさん＠お腹いっぱい。
02/02/04 02:10.net
>80
51にて既出
82:作田
02/02/04 02:11.net
UNICODE委員会の日本語・中国語・ハングルの似たような漢字を統一させようと
いうのは、非漢字圏の横暴だったと思う。欧州のアルファベット異体字には寛容
なのに。
次世代３２ビットUNICODEは４３億まで可能と言うから、早いとこ策定して文系
研究者が文字に苦しまなくて済むようにして欲しい。今はレジェメ作成の為だけに
『今昔文字鏡』なんてソフト導入してるし。
あ、MSがUNICODEに乗ってこないとどの道意味無いか・・・
83:過激派
02/02/04 02:33.net
>>82
がいしゅつだけど linux 板の euc 撲滅スレは
興味深い話題がいくつかあるよ
84:名無しさん＠お腹いっぱい。
02/02/04 03:19.net
>>82
漢字統合は、別に横暴でもなんでもないとおもうが、0208 の変換テーブルが
山ほどあるのはたまらんな、ってーか、そっちをちゃんと統合しろや、ｺﾞﾙｧ > Unicode.org
それはそうと、MSがUNICODEに乗ってこないだろうと判断した根拠はなんじゃろな?
85:名無しさん＠お腹いっぱい。
02/02/04 07:51.net
>>82
>次世代３２ビットUNICODE
ってなに?
86:名無しさん＠お腹いっぱい。
02/02/04 07:51.net
age
87:名無しさん＠お腹いっぱい。
02/02/04 10:42.net
>>82
MS はもう Unicode 移行してるぞ。Windows で内部的には Unicode 扱えるようになってる。
必要なところがアプリ作れと言う立場だと思う。
IME や日本語 MS アプリの対応が進んでないのは、日本法人が必要性感じてないからだろう。
他メーカーも同様。
88:名無しさん＠お腹いっぱい。
02/02/04 10:51.net
ここだけ5年前のスレですか?
89:名無しさん＠お腹いっぱい。
02/02/04 11:10.net
>>88
そうです。
90:名無しさん＠お腹いっぱい。
02/02/04 12:12.net
>>87
Win9x系はVFAT以外Unicodeサポート無しなので、MSに限らずまだしばらく
の間は対応が進む事は無いと思われ。
91:名無しさん＠お腹いっぱい。
02/02/04 12:28.net
>>90
WinXP は NT 系だから対応が進まないということはないと思われ
92:名無しさん＠お腹いっぱい。
02/02/04 12:37.net
おい！
恵比寿を忘れんな！
93:名無しさん＠お腹いっぱい。
02/02/04 19:17.net
>>92
恵比寿ってなに?
94:名無しさん＠お腹いっぱい。
02/02/04 19:18.net
>93
ビール工場しかない東京の街
95:日立グループ社員
02/02/04 19:53.net
>>91
> WinXP は NT 系だから対応が進まないということはないと思われ
社内のマシンはまだWin95ですが何か？
96:名無しさん＠お腹いっぱい。
02/02/04 20:46.net
>>82
まったくだ。英語圏の人は、やっぱ漢字文化が分からないのかな？
Unicodeもまだまだ良くない感じです。
97:名無しさん＠お腹いっぱい。
02/02/04 20:48.net
>>92
恵比須大工で統一するには、さらに困難を伴うと思われ
98:名無しさん＠お腹いっぱい。
02/02/08 01:39.net
FreeBSDでSJISの入った/bin/shスクリプトを起動するとshがcoreはくのはなぜ？
回避策あるの？ sjisサポートshとか。
99:名無しさん＠お腹いっぱい。
02/02/08 01:49.net
bashをスタティックリンクして/bin/shに仕立ててみるとか…
100:名無しさん＠お腹いっぱい。
02/02/15 10:35.net
m17n/i18n/l10n 統合スレ@unix板はここですか？
101:名無しさん＠お腹いっぱい。
02/02/15 16:58.net
このスレの1はMarkusだな?
102:名無しさん＠お腹いっぱい。
02/02/15 17:11.net
>>101
ｲﾏｲﾁ｡
ﾏｲﾅｽ10ﾏｶｰｽ｡
(1ﾏｶｰｽ=10ｳﾞｫｲﾄﾞ)
103:名無しさん＠お腹いっぱい。
02/02/16 01:39.net
>>100
> m17n/i18n/l10n 統合スレ@unix板はここですか？
プログラム技術版に作ったら？
WinやMacOS Xなんかも対象になった方が面白いし。
104:名無しさん＠お腹いっぱい。
02/02/16 01:44.net
>>98
core 吐くのはバグに決まってるじゃん。send-pr すれ。
105:100
02/02/16 02:31.net
>>103
うーん、
今サラっと見てきたら類似スレは見当たらなかったし
作っちゃおうかなあ。
ワタクシ個人的はここで十分なんですが、、、
106:マイナス10マカース
02/02/16 03:43.net
>>105
Unix i18n framework関連へのリンク(がいしゅつ以外)。
# あんまり大した物はない、スマソ。
1. 国際化ソフトウェア・プログラミング・ガイド (Compaq Tru64 Unix)
URLﾘﾝｸ(digital.compaq.co.jp)
URLﾘﾝｸ(digital.compaq.co.jp)
# 無くなったと思ったらまだ有った(w
2. The Single UNIX(R) Specification, Version 2
URLﾘﾝｸ(www.opengroup.org)
URLﾘﾝｸ(www.opengroup.org)
URLﾘﾝｸ(www.opengroup.org)
URLﾘﾝｸ(www.opengroup.org)
URLﾘﾝｸ(www.opengroup.org)
URLﾘﾝｸ(www.opengroup.org)
URLﾘﾝｸ(www.opengroup.org)
URLﾘﾝｸ(www.opengroup.org)
URLﾘﾝｸ(www.opengroup.org)
URLﾘﾝｸ(www.opengroup.org)
3. The FreeBSD C99 & POSIX Conformance Project
URLﾘﾝｸ(people.freebsd.org)
4. C99の新機能 (参考)
URLﾘﾝｸ(seclan.dll.jp)
こんだけでは足りないだろうで、他の方々補足キボンヌ。
107:マイナス10マカース
02/02/16 03:56.net
ちなみにム板だと
「おい、お前らUNICODEを絶滅させて下ちい。」
ｽﾚﾘﾝｸ(tech板)l50
こんなレベルで終わってしまいそうで鬱。
つーか、linux板のEUC撲滅と、ここと上のリンク、
全部の1を集めて戦わせればいーんじゃネーノ?
# まさか全部同一人物?
108:103
02/02/16 10:43.net
>>107
確かに、ム板だとレベル低くなっちゃうかもね。
109:名無しさん＠お腹いっぱい。
02/02/16 11:47.net
>>104
おお、そうなのか。
なんかポリシー持ってる人が持ち込んだ仕様だと思ってました。
バージョンが進むたびにcoreするスクリプトが多くなって困ってた。
しがらみでSJISしか食わないコンパイラ使ってるのでスクリプトがEUCだと
エディタやターミナルの切り替えが不便。
110:100
02/02/16 18:00.net
>>107
うーん
スレあったんですね。
なんか後半はカナモジカイ話になっちゃってどうかなあ(w
そもそもスレタイがなあ...ここもあっちもむこうも(w
>>108
ム板ってhaskellスレ以外見てないんですけど
レベル低いんですか？
ココより？(w
まあココが国際化に関しては一番被害者多そうだけど(w
>>106
Citrus Project
URLﾘﾝｸ(citrus.bsdclub.org)
li18nux
URLﾘﾝｸ(www.li18nux.org)
URLﾘﾝｸ(freestandards.org)
111:名無しさん＠お腹いっぱい。
02/02/16 22:54.net
tronコードってどうなの？全世界の文字扱えるんでしょ？
112:名無しさん＠お腹いっぱい。
02/02/16 23:17.net
>110
そりゃHaskellスレのレベルが高いだけ。
113:ﾏｲﾅｽ10ﾏｶｰｽ
02/02/17 01:45.net
TRONとかiso2022なんかのモード切替でm17nを実現してるCESで、
collationはどういう扱い && どういう実装なんだろと疑問に思ったので
ちょっとgoogleしたけど驚くぐらい情報少なっ!
# しかも有効なページ見つかんなかった。
探し方悪かったかなぁ…
っていうか…LC_COLLATEて皆さん必要なんですか?(爆)
114:名無しさん＠お腹いっぱい。
02/02/17 01:55.net
>>113
> (爆)
なんで爆発するんですか？(w
115:名無しさん＠お腹いっぱい。
02/02/17 02:08.net
SJISみたいな腐ったフォント使ってる奴痛すぎなのですが…
116:名無しさん＠お腹いっぱい。
02/02/17 02:10.net
>115
この板であんまり適当なことを書くと怒られちゃうよ。
117:名無しさん＠お腹いっぱい。
02/02/17 02:12.net
>>116
115がイタすぎて起こる気すらおきないっつーか。
118:名無しさん＠お腹いっぱい。
02/02/17 02:12.net
>>115
SJIS のフォントって何? 見せてみ。
とかね。
119:名無しさん＠お腹いっぱい。
02/02/17 02:42.net
フォントのエリアス名にSJISってつけたら
SJISフォントのできあーがりっと
120:ﾏｲﾅｽ10ﾏｶｰｽ
02/02/17 02:47.net
うお! googleってる間にすっかり糞スレに!!
もういっちょリンク
Unicode Collation Algorithm
URLﾘﾝｸ(www.unicode.org)
121:100
02/02/17 03:39.net
>>113
言語によっては必要or有用そうな気がする。LC_COLLATE。
日本語は、、、読みがわからないと辞書順にならないからなあ(w
stateful encoding については、
とりあえず wchar に直す、でいいんじゃない？
122:103
02/02/17 04:14.net
Collationって符合化方式じゃなくて、文字集合の問題だよね。
123:名無しさん＠お腹いっぱい。
02/02/17 04:27.net
>SJISみたいな腐ったフォント
フォントのインデックスがsjisだとか。
>とりあえず wchar に直す、でいいんじゃない？
WindozeXPでわ、wchar_tで、サロゲートをサポートするらしい。
つまり、stateful(ﾜﾗ
URLﾘﾝｸ(www.rimarts.com)
とか。
124:ﾏｲﾅｽ10ﾏｶｰｽ
02/02/17 04:43.net
wcscoll(西夏文字, 亀甲獣骨文字)とした場合、
やっぱり文字が発明された順序で評価するべきなんですか(w
結局collationっていう概念自体がm17nとはそぐわない気がするんですよね。
まあCCS間で順位を決めちまうのは簡単なんですけど、
stateful encodingの場合ってcollationのコストって
かなりのシロモノだと思うんですが(汗
# なんか勘違いあったらもっとハードに叩いてください。
125:ﾏｲﾅｽ10ﾏｶｰｽ
02/02/17 05:09.net
>122
日本語に限った話だと、collationって結局>121の仰る通り、
漢字の読みによって変化してしまうので、実装は事実上不可能なんで
符号化の順序=collationになってしまいますよね…
# 中国語だと今度は発音の違いもcollationの対象かぁ(w
126:ﾏｲﾅｽ10ﾏｶｰｽ
02/02/17 05:11.net
>125
> # 中国語だと今度は発音の違いもcollationの対象かぁ(w
s/発音/アクセント/g でした(四声とかいう奴)。
127:100
02/02/17 05:25.net
>>124
発明された順番なんて関係ないでしょ。
どこかに発明順に文字を並べる文化があって、
そこの locale を使っているんでもないかぎり(w
一旦 wchar にしてしまえば、
stateful だから高コストということはないと思われます。
ごめん、、性格が柔和なので(w あんまりハードに叩けないや(w
>>125
画数順にするとか...(w
128:100
02/02/17 05:28.net
>>123
それは普通 stateful とは言わないのでは？
129:100
02/02/17 05:31.net
それはそうと
windows もサロゲートサポートするんだ...
てっきり 16bit only で押し通すのかと(w
# unicode も勉強しなきゃなあ..
130:名無しさん＠お腹いっぱい。
02/02/17 10:02.net
>>129
顧客を抱えている企業なわけだから、Extension B に続々と
漢字が入りつつあるような昨今、今更 16 bit で押し通すな
んて無理なことでしょう。
押し通したら、喝采するけどな(W
131:名無しさん＠お腹いっぱい。
02/02/17 10:09.net
wchar_tは16bitのまま、という意味では押し通してるけど。。。
132:名無しさん＠お腹いっぱい。
02/02/17 10:19.net
imodeでSJISしか使えないぞです！
FOMAもSJISしか使えないぞです！
みんなでドコモごとSJISを撲滅してくれよです！
おいどんがドコモの社長になったら、全部EUCにするぞです！
社内文書もSJIS禁止だぞです！
133:名無しさん＠お腹いっぱい。
02/02/17 10:30.net
>>132
SJIS だと何か困りますか?
134:名無しさん＠お腹いっぱい。
02/02/17 10:37.net
ｽﾚﾘﾝｸ(kao板)
こういうｽﾚが困ります
135:名無しさん＠お腹いっぱい。
02/02/17 10:39.net
>>134
それは、SJISのせいではありません。
136:名無しさん＠お腹いっぱい。
02/02/17 10:40.net
>>134
おーい。そのスレ、SJIS で無い文字が大量に入ってるぞ(わら
Unicode を実体参照でだしてあるんだよ。
137:134
02/02/17 10:44.net
>133に対して、SJISだと(ちゃんと表示されなくて)困る、って話だが
138:名無しさん＠お腹いっぱい。
02/02/17 11:32.net
どーして符号化文字集合と文字エンコーディングスキームの
区別が出来ない奴がこうも多いの？
139:名無しさん＠お腹いっぱい。
02/02/17 11:34.net
JISが悪い。
そしてASCIIが悪い。
140:名無しさん＠お腹いっぱい。
02/02/17 11:42.net
ＵＮＩＸでもSJIS使えばいいのに。
141:名無しさん＠お腹いっぱい。
02/02/17 11:44.net
>140
名言だ。伝説になるよ。
142:名無しさん＠お腹いっぱい。
02/02/17 11:52.net
1バイト=32ビットにしる!
143:名無しさん＠お腹いっぱい。
02/02/17 14:04.net
印刷屋はつらいよ。
とほほ。
144:ﾏｲﾅｽ10ﾏｶｰｽ
02/02/17 15:50.net
ありゃ、やっぱちここで続けるにはタイトルが悪すぎるかも。
>138と>139に禿しく同意。
このスレとかEUCスレ、Unicodeスレの>1みたいな人は
内容が平易で判り易い本 && 簡単に手に入るので
「パソコンにおける日本語情報処理／文字コードハンドブック」川俣 晶
URLﾘﾝｸ(www.amazon.co.jp)
くらいまず読んでおいた方がいいと思う。
他には
「日本語情報処理」ケン ランディ
URLﾘﾝｸ(www.amazon.co.jp)
が名著らしいけど、手に排卵。
あとはCマガのバックナンバーある人は
1999/6月号の第一特集「日本語処理」とか。
>132を好意的に受け止めてみると
i-modeの絵文字
URLﾘﾝｸ(www.nttdocomo.co.jp)
がJISX0213-2000で廃止された外字領域を侵略してることを非難してる?(w
145:ﾏｲﾅｽ10ﾏｶｰｽ
02/02/17 15:53.net
あらら、あげちまった。
>127
ISO2022は文字集合を切り替えるが、言語を切り替えるわけじゃないからって
ことですよね。その前提に則れば、アラビア文字のcollationも、
言語が日本語なら日本語としてのcollationのruleを用意しなければならないけど、
実装を考えたらこれってアラビア語のcollation流用しますよね…普通。
146:ﾏｲﾅｽ10ﾏｶｰｽ
02/02/17 17:55.net
うー、どうも勘違いしてるな、漏れ。
上の例でいうなら日本語のcollation databaseをlocaledefで生成するとき、
アラビア文字のcollation定義ファイルをincludeしても構わない、ってだけだ。
よって文字集合が切り替わってもcollate databaseを切替る必要は
全くといって無いわけだ。
すんまそん、逝ってきます。
147:100
02/02/17 21:03.net
まあ、日本(語)ロケールにおいてアラビア文字とサンスクリット混合テキストの
collation どーすんだ、データ用意するの面倒じゃ、というのは確かにあるかも。
使用頻度の高いところ以外は適当でもいいかなあって
個人的には思ってるんですが、ダメ？(w
solaris の utf なロケールではどうしてるのかしら。
148:103
02/02/17 22:34.net
>>146,147
どういう利用を想定している訳? 例えば、
英文字英単語すべて
アラビア文字アラブ系言語単語すべて
漢字平仮名日本語単語すべて
という順に並べるの?
それとも、カタカナ読みの順番に混在して並べる事を想定しているの?
TeXなんかだと後者は、indexed wordのsort keyに読みを記述するよね。
つまり、アプリケーションがcollationを直接扱っていて、
文字の層に任せるのは、「読み」に使う「仮名」のcollationだけ。
149:103
02/02/17 22:38.net
あ、前者の方も、localeで対応すべき事かしら?
計算機技術書だと、記号、英単語、日本語の順にindexを作成する事が多いけど、
文系書籍の場合、日本語、英単語の方が多い。
これも応用に依存すると思う。
文字のcollationとは別の話だと思う。
150:名無しさん＠お腹いっぱい。
02/02/17 23:17.net
一言言っとくが、AIXのデフォルトの日本語コードはSJISだぞ！！
151:100
02/02/17 23:19.net
>>148-149
どういう利用かというと端的には sort(1) ですが。
% LC_ALL=ja_JP.UTF8 sort < 多言語テキスト
みたいな。
LC_COLLATE に限って言えば、文字列の順序づけの定義ということで
辞書順を想定してましたが、違うのかな。
辞書順というか、その locale で一般的な並べかた、かな？
ただ、ja locale でアラビックの一般的な並べかたなんてないので、
たとえば solaris ではどうしてるのかなあ、と思ったわけです。
sus とか読むかぎり、alphabet等の辞書順≒文字順な例ばっかりのようなので、
そうでない漢字等に関してちゃんとした定義があるのかちょっと疑問。
いいかげんな事ばっかり書いてスマソ。
応用によって並べかたが違うというのはその通りですが、
そんなこと言ってたらなにも定義できないのでは:-)
または各応用ごとに locale を用意する、という手もありますし。
152:101に改名
02/02/18 01:31.net
>151
日本語だけ考えれば
JISX4061-1996日本語文字列照合順番
ということなんでしょうかね。
# 中身は見た事無いので、他のJIS符号化文字集合との整合性は知りません。
(参考?)
URLﾘﾝｸ(www.asahi-net.or.jp)
うーん、>149の仰るようにLC_COLLATEは
「文字」照合で、「文字列」照合ではないのかな?
確かにUnicodeのcollation
URLﾘﾝｸ(www.unicode.org)
では全く意識してないっぽい。
LinuxのLC_COLLATEの実装もUnicodeのcollation依存のようです。
URLﾘﾝｸ(oss.software.ibm.com)
「Collation table is generated from collation key table
provide by Unicode org.」
# ますますこんな機能はアプリで用意せいとか思ったり。
153:100
02/02/18 01:51.net
>>152
>JISX4061-1996日本語文字列照合順番
ああ、こんなのあるんですね。サンクス。
とはいえ、金ないので読めませんが..(w
LC_COLLATE は
文字*列*照合でいいと思います。
すくなくとも、sus 的には。
154:100
02/02/18 01:58.net
>>152
># ますますこんな機能はアプリで用意せいとか思ったり。
どうやって？
155:101
02/02/18 18:23.net
すんまそん、平日はactivity下がります。
>>154
LC_COLLATEが提供すべき機能が「文字列」照合だと
LC_COLLATE=ja_JP@読み50音順
LC_COLLATE=ja_JP@画数順
LC_COLLATE=ja_JP@ローマ字@ヘボン式@ABC順
と無制限に増えるのがぞっとするということですかね。
# アラビア語も日本語読みしてヘボン式ローマ字に変換? w)
実装or定義自体は置いといてframeworkは用意すべきなのでしょうかね...
# ヘタレなわたしには想像できないんですけど。かっこええ。
こうなるとオーバースペックな気がするので
実用上問題ない「文字」照合でとどめる方がいいかなと。
# それ以上必要なら、アプリが自分で管理しろと。
それと、読み返してみるとSUSv2ではLC_COLLATEには
charactor and multi-charactorとあって、stringとは出て来ないんです。
multi-charactorは"は" + 半濁点で "ぱ"ですかね。
Tru64のdocでは「伝統的なスペイン語では、ch という文字の組合せが
文字 c と d の間にソートされます」との例があります。
結局のところwcscoll()以外は、「文字列」照合する必要は無いわけで、
wcscollの結果は「文字」照合の結果で構わないのかなと。
# やぱしI18Nハンドブックは買って読まんと駄目かな...
# 一つレスするにも自信が無い(w
156:100
02/02/18 21:13.net
>>155
> と無制限に増えるのがぞっとするということですかね。
アプリでやっても無制限に増えると思いますが。
それも各アプリに(w
> こうなるとオーバースペックな気がするので
> 実用上問題ない「文字」照合でとどめる方がいいかなと。
文字照合にとどめたら無制限に増えなくなるかというと、
そんなことはないと思います。
> haractor and multi-charactorとあって、stringとは出て来ないんです。
string は一杯出てきますが..
sort-rules(order_start で指定するやつ) は string でないと意味ないですし。
157:うひひ
02/02/19 10:20.net
しかし何だね。むつかしいコトはわかんねーけどsjis浸かってれば
幸せなんじゃねーの？
ウィソの存在はでかいし
SJISであんま困ったことねーな
158:名無しさん＠お腹いっぱい。
02/02/19 10:31.net
たとえばsjisの「ソ」なんかは2バイト目がバックスラッシュと同じコードなんで、
バックスラッシュをエスケープするような厨房コードを書くと日本語通らんのよ。
159:名無しさん＠お腹いっぱい。
02/02/19 11:39.net
nn
160:うひひ
02/02/19 13:16.net
>>158
ソ－なんだぁ。
なんか犬産婆でそんな時の逃げパタン見た気がする
僕はコド書かないから気楽に生きてるよ
僕のがバクスラをプチ￥使うのもそんな感じなのか
161:101
02/02/19 13:25.net
>>157
SJISはもうお腹いっぱいです。
SJIS-JISX0213もかなり無理してます。
# 誰かxttをJISX0213対応させません?
# せっかく拡張渡辺明朝あるのに。
>>156
> それも各アプリに(w
再発明はこの世の常かと(w
> 文字照合にとどめたら無制限に増えなくなるかというと、
> そんなことはないと思います。
そうでした。「文字」照合であっても無制限に増えますね。
誤りでした。漢字一つとっても
ja_JP@全体の画数
ja_JP@偏とつくりの画数順
...無数にできるな。
結局LC_COLLATEは
・いかなるユーザ定義も想定しる。
・デフォルトの定義を用意すれ
ってことですかあ、大変だ。
> sort-rules(order_start で指定するやつ) は string でないと意味ないですし
ゲフ、もいっかいちゃんと読みに逝って来ます。
日本語ロケールでアラビア文字を扱う場合、
アラビア文字の照合順序を定義することは
mustではないような気がして来ました。
# 知らなきゃ無視すりゃいいだけのような。
# でもEINVALなげていいのか?
どうですかね...
リンク忘れ。
UI-OSF 日本語環境実装規約
URLﾘﾝｸ(www.li18nx.org)
locale databaseのサンプル
URLﾘﾝｸ(www.li18nx.org)
162:10
02/02/19 21:09.net
>>158
それは SJIS が..というより厨房コードを直すべきでは..(w
# samba みたいなアプリでは、しかたないところもありますが...
まあ、厨房プログラマにも自動的or簡単に正しいコードが書けるように
なったらそれはそれで素晴らしいですが。(java ？)
wchar じゃダメかなあ...ダメだろなあ(w
>>161
> # 知らなきゃ無視すりゃいいだけのような。
無視というか、
定義にない文字は UNDEFINED symbol の重みにするように
どっかに書いてあったような。たぶん。
163:何を？
02/02/23 11:53.net
（ ﾟДﾟ)＜ボクメーツ
164:100
02/02/24 10:48.net
いまごろ気付いたけど
>>162 は 10 ではなくて 100 です。スマソ。>10
165:名無しさん＠お腹いっぱい。
02/03/09 09:55.net
SJISよりUTF8のほうが便利なのにどうして使わないの？
166:名無しさん＠お腹いっぱい。
02/03/09 12:33.net
>>162
厨房コードというより、外国のコードに多いよ。
167:名無しさん＠お腹いっぱい。
02/03/10 10:31.net
>>165
文字数少ないから。
168:名無しさん＠お腹いっぱい。
02/03/14 02:52.net
>>166
まあ、
どっちにしろ SJIS が悪いわけではないよね。
169:名無しさん＠お腹いっぱい。
02/03/23 17:33.net
i-Mode用コンテンツ作るのにShift-JIS強要がいやん。
170:
02/03/23 17:53.net
ＵＮＩＸ側がSJISに会わせよう
171:名無しさん＠お腹いっぱい。
02/03/23 20:28.net
やだ
172:名無しさん＠お腹いっぱい。
02/03/23 20:36.net
NEWS-OS も 日本語 HP-UX も SJIS デフォじゃなかったっけ？
昔の国産 Unix はそういうのが多かったと思うけど。
173:名無しさん＠お腹いっぱい。
02/03/23 21:21.net
あくまでも、「昔の国産」ね。オルタナティブがある今は考えが
別になってもおかしくないでしょ。
174:名無しさん＠お腹いっぱい。
02/03/23 22:46.net
>>168
> まあ、
> どっちにしろ SJIS が悪いわけではないよね。
SJISも悪いんじゃないの。Codingの面倒さだけ言えば、
EUC-JP > Shift_JIS >> ISO-2022-JP でしょ。
175:名無しさん＠お腹いっぱい。
02/03/23 22:49.net
>>172
> 昔の国産 Unix はそういうのが多かったと思うけど。
ΣはEUC-JPでしたが…
176:名無しさん＠お腹いっぱい。
02/03/23 22:50.net
あ、東芝のSun3の日本語化もEUC-JPでした。
名前はJOSだったかどうか…
177:
02/03/24 02:31.net
だれかｇｃｃのＳＪＩＳパッチの情報教えて！！
他のベンダコンパイラと互換をとるのが面倒だから。
（ベンダコンパイラで日本語オプションを外せばよいのは分かってるけど）
178:名無しさん＠お腹いっぱい。
02/03/24 11:19.net
>177
LANG=ja_JP.SJISで良かったりしない？
179:名無しさん＠お腹いっぱい。
02/03/24 12:38.net
>>177
使うlibraryもShift_JISを理解する必要があることは理解しますか?
e.g. printf().
180:177
02/03/25 00:35.net
>178
リテラルで「表」とかってコーディングする時、ｇｃｃだとエスケープが
必要だけど、ベンダコンパイラにはオプション指定でエスケープを不要に
できるものがあるでしょう？
＞179
セットロケールの動作の話してんの？
181:名無しさん＠お腹いっぱい。
02/03/25 01:15.net
gccでもgcc3系はLANG見てsjisもエスケープ無しでコンパイルできるとか
どっかで見たような...
手元に環境無いから確認できんけど。
182:名無しさん＠お腹いっぱい。
02/03/25 16:16.net
>>174
悪いのは SJIS や ISO2022 ではなくフレームワークの不在。
LC_CTYPE じゃ全然不十分だし。
filter アプリなら間に合うのかもしれないが..。
eucJP なら厨房コードでも OK かというと、
そうは思わない。まあ SJIS よりは実用上マシな場合も多いのも
確かだが、そういうエンコード依存はそろそろやめにしたい。
CSIマンセー。
183:名無しさん＠お腹いっぱい。
02/03/26 19:41.net
フレームワーク…。X11R5 の Xwc…。
184:名無しさん＠お腹いっぱい。
02/04/01 00:44.net
Xutf...(w
185:名無しさん＠お腹いっぱい。
02/06/20 23:42.net
で、JIS X 0213で追加された文字はいつUnicodeに入るの?
186:名無しさん＠お腹いっぱい。
02/06/20 23:52.net
>>180
>>178が言っているのはコンパイルが通っても
関数で対応してないときちんと処理されるかどうか
わかんないよって言う意味でしょ。
たぶん。
187:名無しさん＠お腹いっぱい。
02/06/21 23:17.net
>>185
もう入ってるよ。
URLﾘﾝｸ(www.unicode.org)
188:名無しさん＠お腹いっぱい。
02/09/10 13:56.net
age
189:名無しさん＠お腹いっぱい。
02/09/13 14:03.net
半角カナの使えるロケール定義ファイルはないものだろうか?
190:名無しさん＠お腹いっぱい。
02/09/13 14:04.net
Linuxでね、半角カナ使いたいんだけどさ。
191:名無しさん＠お腹いっぱい。
02/09/13 15:08.net
ロケールつってもいろいろあるが。。。
半角カナ使いたいってのもどこでつかうのか意味不明。
192:名無しさん＠お腹いっぱい。
02/09/13 15:48.net
>>189
jp_JP.eucJPで何の問題もないと思うが。
/usr/share/i18n/charmaps/EUC-JP.gz これじゃ不満なの?
193:名無しさん
03/01/03 02:11.net
／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣＼
Λ＿Λ | 君さぁ こんなスレッド立てるから |
（ ´∀｀）＜ 厨房って言われちゃうんだよ |
（ ΛΛ つ ＞――――――――――‐＜
( ﾟДﾟ) ＜ おまえのことを必要としてる奴なんて |
/つつ | いないんだからさっさと回線切って首吊れ |
＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿_／
(-＿-) ﾊﾔｸｼﾝﾃﾞﾈ… (-＿-) ﾊﾔｸｼﾝﾃﾞﾈ… (-＿-) ﾊﾔｸｼﾝﾃﾞﾈ…
(∩∩) (∩∩) (∩∩)
(-＿-) ﾊﾔｸｼﾝﾃﾞﾈ… (-＿-) ﾊﾔｸｼﾝﾃﾞﾈ… (-＿-) ﾊﾔｸｼﾝﾃﾞﾈ…
(∩∩) (∩∩) (∩∩)
(-＿-) ﾊﾔｸｼﾝﾃﾞﾈ… (-＿-) ﾊﾔｸｼﾝﾃﾞﾈ… (-＿-) ﾊﾔｸｼﾝﾃﾞﾈ…
(∩∩) (∩∩) (∩∩)
194:名無しさん＠お腹いっぱい。
03/01/03 03:08.net
文字コードの話してるのに、どうして(いわゆる)半角カタカナや全角英数使ってるバカがいるんだろうか。
195:名無しさん＠お腹いっぱい。
03/01/03 03:36.net
＞＞１９４
ｳﾙｾｰﾊﾞｶ！
196:名無しさん＠お腹いっぱい。
03/01/03 04:44.net
お前ら、自分で自分の首絞めてる印象。
197:名無しさん＠お腹いっぱい。
03/01/03 12:28.net
>>195
使うなよボケ
198:_
03/01/03 12:33.net
URLﾘﾝｸ(freeweb2.kakiko.com)
199:名無しさん＠お腹いっぱい。
03/01/03 13:02.net
唐突だけど、、Emacs(MULE)のエンコーディングの処理は優れてると思いませんか？
たぶんunicodeみたいなcoded character setの統一は不可能だと思う。
で、多種多様な文字を扱うにはemacs muleみたいな内部コードを作るしかないかと。
これだったら臨機応変にcoded character setを増やしたり減らしたりできる。
200:名無しさん＠お腹いっぱい。
03/01/03 13:11.net
>>199
URLﾘﾝｸ(savannah.gnu.org)
201:名無しさん＠お腹いっぱい。
03/01/03 13:17.net
要するに内部コード方式が維持されればいいと思うわけで。
でもunicodeに影響され過ぎてると思うけどなぁ。
utf-8-emacs is backwards compatible with the UTF-8 encoding of Unicode.
とか
202:名無しさん＠お腹いっぱい。
03/01/03 13:20.net
ps. トンパ文字とかその他まだsetされてない文字はどうするわけ？増やした
い文字なんて無尽蔵に増えるだろうに。
203:名無しさん＠お腹いっぱい。
03/01/03 13:24.net
あ、後方互換性だから関係ないか。
204:名無しさん＠お腹いっぱい。
03/01/03 13:27.net
>>200 は結局なにを言いたかったのかな？内部コードがunicodeのサブセットになるわけじゃない。
答えてくれ。
205:名無しさん＠お腹いっぱい。
03/01/03 13:39.net
>>194 どうして使っちゃいけないの？
206:名無しさん＠お腹いっぱい。
03/01/03 14:04.net
トンパ文字を使う民族がPC使うかが問題やな
いくつ種類あるんだYO!
207:名無しさん＠お腹いっぱい。
03/01/03 14:58.net
>>206
日本にルーズソックスを履いて棲息しているという噂を耳にしたことが
あります。
208:名無しさん＠お腹いっぱい。
03/01/03 16:22.net
>>205
全角の「?」使うなよ...
JIS X 0208 読んだこと無いのか?
はっきり「使うな」って書いてある。
209:!205
03/01/03 16:36.net
>>205 そうなんだ？ 知らなかったよ。
210:209
03/01/03 16:37.net
s/205/208
211:名無しさん＠お腹いっぱい。
03/01/03 16:45.net
>>209 >>210
> そうなんだ？ 知らなかったよ。
面白くないよ。
> s/205/208
一文字足りないのでは?
212:名無しさん＠お腹いっぱい。
03/01/03 17:31.net
>>200
utf-8-emacsか。-emacsを付けるところはやっぱり偉いね。
213:名無しさん＠お腹いっぱい。
03/01/03 19:27.net
>>204
書いてない事を憶測されても困るんですが、、、
単にFYIでリンクを貼っただけで、何らかの主張があるならそれも書きますってば。
214:名無しさん＠お腹いっぱい。
03/01/03 20:47.net
現状で問題なし。っていう人がマジョリティでしょ。
215:209
03/01/04 03:08.net
>>211
最近 sed 使ってないから忘れてたよ。vim だとそれでオツケイなんだけどね。
216:名無しさん＠お腹いっぱい。
03/01/04 04:02.net
結局 Han unification の問題はどうなったんですか?
日本と中国の漢字を違う glyph で表示できるんでしょうか.
>>200
utf-8-emacs が内部的に使われるとなると,
iso2022 で実現できていた multi encoding 環境は
どうなるんですかね. 従来のも使えると書いてあるから
かわらないのかな.
217:名無しさん＠お腹いっぱい。
03/01/04 21:38.net
どれでもいいから一つにしてくれ・・・
218:山崎渉
03/01/15 13:03.net
（＾＾）
219:名無しさん＠お腹いっぱい。
03/01/24 13:10.net
「Shit JIS」でググると結構な数ヒットするんですが、
みなさん、故意に書いてるんですかね?
220:糞JIS撲滅
03/01/24 13:49.net
DoCoMo 用の CGI のコメントに故意に書いたことならあります。
221:山崎渉
03/03/13 17:30.net
（＾＾）
222:
03/03/14 00:28.net
半角カナのないコードは糞!
223:名無しさん＠お腹いっぱい。
03/03/20 00:05.net
とりあえず、2ch見ているうちは半カナは必須かな？と言ってみる。
224:名無しさん＠お腹いっぱい。
03/03/21 02:49.net
>>222
半角ｶﾅのないコードってあるの？
225:名無しさん＠お腹いっぱい。
03/03/21 04:09.net
jis ってあったっけ?
そういえば unicode はどうなの?
226:224
03/03/21 07:16.net
>>225
ISO-2022-JP も EUC-JP も Unicode も半角ｶﾅあると思うんだけど？
227:名無しさん＠お腹いっぱい。
03/03/21 08:12.net
それはねこみみです
228:名無しさん＠お腹いっぱい。
03/03/21 10:17.net
>>226 では ISO-2022-JP で「半角カナ」を使う方法を教えてください。
229:名無しさん＠お腹いっぱい。
03/03/21 10:52.net
>>228
カナの幅が高さの半分くらいのフォントを使う。
230:名無しさん＠お腹いっぱい。
03/03/21 11:34.net
はい次。
231:224
03/03/21 15:44.net
>>228
すいません、勘違いをしておりました。
JIS で定義されてる ESC ( I は、ISO-2022-JP (RFC1468) には無いのでつね。
232:名無しさん＠お腹いっぱい。
03/03/24 02:08.net
>>228
URLﾘﾝｸ(www2d.biglobe.ne.jp)
233:名無しさん＠お腹いっぱい。
03/03/24 03:18.net
ＩＳＯ－２０２２－ＪＰ 【通信用語:情報符号編】
[アイエスオウにーまるにーにージェイピー] (ISO-2022-JP) 〔固有名詞／+規格〕
/COMP/MARK/CHR/CODE/ENC/JA … 日本語
◇複数の言語文字 (文字集合) を切り替えて利用する ISO-2022 のサブセット規格で,
日本語文字コードの符号化を規定した仕様. RFC 1468 で規定されている.
◇JIS X0201 前半の英数記号と, JIS X0208 第 1・2 水準漢字, そして旧 JIS 漢字
集合の JIS C6226 互換 (JIS X0208:1973) をサポートしている. つまり, JIS X0201
後半のカナ (通称半角カナ) はサポートされていない.
◇この後継仕様に, ISO-2022-JP-1 (RFC 2237) や ISO-2022-JP-2 (RFC 1554) など
がある.
※コラム（サポートする文字集合）
reg# character set ESC sequence designated to
─────────────────
6 ASCII ESC 2/8 4/2 ESC ( B G0
14 JIS X0201-Roman ESC 2/8 4/10 ESC ( J G0
42 JIS C6226:1978 ESC 2/4 4/0 ESC $ @ G0
87 JIS X0208:1983 ESC 2/4 4/2 ESC $ B G0
─────────────────
234:名無しさん＠お腹いっぱい。
03/03/24 03:20.net
jis もいっぱいあって、わかんないよ!!!
235:名無しさん＠お腹いっぱい。
03/04/11 01:34.net
ネジの規格もJISだしね!!!
236:名無しさん＠お腹いっぱい。
03/04/11 02:51.net
iso2022 の G0 とか G1 とか GR とか GL とか、
わけわかんない概念はどっからきたの?
237:名無しさん＠お腹いっぱい。
03/04/11 04:14.net
フォントロード可能な文字端末
別にわけわかんないことはないでしょ?
ただ今となっては一段間接が余分だね。
238:名無しさん＠お腹いっぱい。
03/04/11 04:15.net
あ、フォントロード可能なプリンタもね。
239:山崎渉
03/04/17 12:23.net
（＾＾）
240:あぼーん
あぼーん.net
あぼーん
241:名無しさん＠Ｅｍａｃｓ
03/04/27 01:20.net
お前ら、新しいエサですよ。
Unicode 4.0 Released!
URLﾘﾝｸ(www.unicode.org)
242:あぼーん
あぼーん.net
あぼーん
243:名無しさん＠お腹いっぱい。
03/04/27 02:28.net
変なのが食いついてるよ。
244:あぼーん
あぼーん.net
あぼーん
245:名無しさん＠お腹いっぱい。
03/06/14 17:09.net
I hate UNICODE :-)
246:名無しさん＠お腹いっぱい。
03/07/01 02:39.net
unicodeで表示できてJIS系で表示できない漢字はなにがありますか？
247:名無しさん＠お腹いっぱい。
03/07/01 06:18.net
JIS X 0221:2001はExtension Bが未収録(Unicode 3.2未対応)なので、
ざっと45,000字ぐらいは表示どころか扱うこともできねい筈だす
248:名無しさん＠お腹いっぱい。
03/07/01 14:01.net
>>246
とりあえずマルチポストいくない。
必要なければ UTF-8 にする事はお勧めしない。
249:名無しさん＠お腹いっぱい。
03/07/01 21:51.net
>>246
表示つーのがもうどう答えていいもんだか分からないけど、
JISで定義されてない漢字はJIS系では扱えないだろ。大陸の奴とか。
>>247
それ、JIS X 0221:2001で扱えるけど、Unicodeだと扱えない漢字(だけじゃないけど)じゃん。
丸つき数字なんかは永久に入らないんだろうな。
第3,4水準南無～
250:名無しさん＠お腹いっぱい。
03/07/01 22:02.net
Unicode って字を組み合わせる規格なかったっけ?
〇と 1 とか。
251:名無しさん＠お腹いっぱい。
03/07/01 22:46.net
あるけどさ。
口{〇, 1} こんな感じで三文字に。(丸付き一)
口{〇, ∥{3, 4}} こんな感じで四文字に。(丸付き三十四)
こういうので済むなら、丸つき数字を文字集合に含める必要ないしな。
白抜きがどうにもならんし。
252:あぼーん
あぼーん.net
あぼーん
253:あぼーん
あぼーん.net
あぼーん
254:名無しさん＠お腹いっぱい。
03/08/14 07:57.net
へーこんな仕組みできたなんて知らなかった。
管直人もいろいろ工夫してるもんだね。なにが条件になってるんだろう？
255:あぼーん
あぼーん.net
あぼーん
256:名無しさん＠お腹いっぱい。
03/08/14 17:05.net
SJISよりも関西弁を撲滅してください
257:名無しさん＠Ｅｍａｃｓ
03/08/15 01:19.net
>>256
なんでやねん?
258:あぼーん
あぼーん.net
あぼーん
259:あぼーん
あぼーん.net
あぼーん
260:ヽ(´ー`)ノ
03/08/18 11:21.net
>>254
山崎渉って From に書くと fushianasan になるんじゃなかったっけ？
261:名無しさん＠お腹いっぱい。
03/10/09 04:56.net
www.cbook24.com/bm_detail.asp?sku=4901676156
262:名無しさん＠お腹いっぱい。
03/10/09 23:45.net
SJISはいいけどCP932を撲滅しる。
263:名無しさん＠お腹いっぱい。
03/10/10 17:57.net
互換性がなくなるから無理
264:名無しさん＠お腹いっぱい。
03/10/11 00:36.net
つーかCP932が非互換の元凶。
265:名無しさん＠お腹いっぱい。
03/10/11 02:02.net
うにコードだって、別にUTF-8だけじゃないしなぁ・・・
いわゆる駄スレってこれのことか？
266:名無しさん＠お腹いっぱい。
03/10/11 13:43.net
UCS-4 で満足だとでも？
267:名無しさん＠お腹いっぱい。
03/10/11 14:25.net
ゼロから作りなおさないかぎり Unicode はすべてクソ。
268:名無しさん＠お腹いっぱい。
03/10/11 14:39.net
>>267
ゼロは無だと思うから「作りなおす」ことはできない
ゼロから作りあげるが適切
269:名無しさん＠お腹いっぱい。
03/10/11 21:41.net
UnicodeはBOMがウザい。誰だよあんな余計なもの考えた奴は。
まぁ、実際は文字コード以上に改行コードの違いがウザい訳だが。
270:名無しさん＠お腹いっぱい。
03/10/12 02:43.net
URLﾘﾝｸ(www.alanwood.net)
271:名無しさん＠お腹いっぱい。
03/10/12 13:05.net
どれでもいいからひとつにしてくれ・・・マジで
272:名無しさん＠お腹いっぱい。
03/10/12 23:18.net
>>232
> URLﾘﾝｸ(www2d.biglobe.ne.jp)
そのWebサイトに書いてあることは嘘があったり重要なことが抜けてたりするので
あまり参考にしない方がいい。
たいていの場合、JIS X 0201の片仮名用図形文字集合(いわゆる半角カタカナ)は
使ってはいけない。ISO-2022(例外あり)もISO-2022-JPもShift JISもEUC-JPも
UTF-8もUTF-16も。
同様にJIS X 0208の一部の文字(いわゆる全角英数)も使ってはいけない。
「?」や「/」のJIS X 0208の方もダメ。
273:名無しさん＠お腹いっぱい。
03/10/12 23:40.net
UTF-8撲滅sage
274:名無しさん＠お腹いっぱい。
03/10/12 23:55.net
>>272
で、使ってはいけない理由を言おうとはしないわけですね。
275:名無しさん＠お腹いっぱい。
03/10/13 00:11.net
>>272
> そのWebサイトに書いてあることは嘘があったり重要なことが抜けてたりするので
たとえばどの辺ですか?
276:名無しさん＠お腹いっぱい。
03/10/13 00:30.net
「半角片仮名」という言葉が間違いで「JIS X 0201片仮名」というのが
正しいのだ、と覚えた人には、単に言葉を置き換えればよいと思って
いる場合があるようだ。これは肝心なところを誤解している。
何が誤解かというと、JIS X 0201に含まれる片仮名は、普通の「片仮名」
なのであって、「半角片仮名」でもなければ「『JIS X 0201の片仮名』
という名の特殊な片仮名」でもないということ。普通の片仮名なのだから、
JIS X 0208に含まれている片仮名と何の違いもない。
つまり、シフトJISのようにJIS X 0201と0208を組み合わせたコードでは、
同じ「ア」という文字に対して(1バイトと2バイトの)ふたつの異なる
符号化表現を割り当てている(重複符号化)のであって、「半角ア」と
「全角ア」という(あるいは「JIS X 0201のア」などと呼ぶにせよ)
2つの異なる文字があるのではないということ。ここを勘違いした議論は、
どこまでいっても勘違いに終わっている。
勘違いの典型は、「UnicodeでJIS X 0201の片仮名は使えますか?」などと
いう質問で、「JIS X 0201の片仮名」などという特殊な片仮名がこの世に
存在しない以上、「Unicodeには片仮名はありますよ」と答えるほかない。
(意地悪な答えだけど)
277:272
03/10/13 03:18.net
ISO-2022-JP、EUC-JPの場合:
使ってはいけない理由の根本はISO/IEC 2022にあります。JISでいうとJIS X
0202。「7.5 図形文字の一意な符号化」にはこう書かれています。
----ここから引用----
同じ文字が8ビット又は7ビットの符号の符号要素のG0, G1, G2及びG3として、指
示される複数の図形文字集合に現れることがある。このような文字は、二つの集
合を定義する仕様又はISO符号化文字集合の国際登録簿で同じ名前をもつ場合、
同じ文字とみなされる。
同一の文字が複数の集合に割り当てられている場合、その文字は、その文字が割
り当てられた任意の符号要素のG0, G1, G2又はG3から取り出された符号化表現で
表現されてよい。
この規格を適用する場合、情報交換の際にすべての文字が一意の符号化表現をも
つことを要求されるとき、符号の版の規定(10.1参照)で、その制限を明らかにし
なければならない。
符号の一意化の制限を適用した場合、その文字が割り当てられた最下位番号の符
号要素(G0, G1, G2及びG3の順)から符号化表現が表現される。この場合、たとえ、
高位番号の符号要素が既に呼び出されていて、かつ、その文字が割り当てられて
いる下位番号の符号要素が呼び出されていないときでも、高位番号の符号要素の
文字の符号化表現は、使用しない。
----ここまで引用----
「二つの集合を定義する仕様」というのはこの場合JIS X 0201とJIS X 0208です。
さて、例の「使うとまずい文字」の名称はどうなっているか? なんとJIS X 0201
とJIS X 0208でまったく同じです。たとえば「ア」は両方とも「KATAKANA
LETTER A」ですし「?」は「QUESTION MARK」です。つまり半角と全角の二つの文
字があるのではなく、「ア」という文字があってそれが二つの集合に存在するわ
けです。続きを読みます。
278:272
03/10/13 03:19.net
・一意の符号化表現が要求された場合はG0～G3のうち、若い数字の方を使う。
・そうでなければG0～G3のどれを使っても良い。
ISO-2022-JPはASCII、JIS X 0201 ラテン、JIS X 0208をG0に指示して使います。
EUC-JPはASCIIをG0、JIS X 0208をG1、JIS X 0201 片仮名をG2、JIS X 0212をG3
にあらかじめ指示してあります。ですから、EUC-JPで一意の符号化表現が要求さ
れた場合は、JIS X 0201 片仮名とJIS X 0208の一部は使えません。
ところで、ISO-2022-JPはそもそもJIS X 0201 片仮名を含んでいません。なので
ISO-2022-JPでJIS X 0201 片仮名を使おうとするのは「論外」です。ちなみに
ISO-2022-JP-2、ISO-2022-JP-3にも含まれていません……。
閑話休題。実は、ISO-2022-JPやEUC-JP自身は一意の符号化表現を要求していま
せん。よってかぶっている文字はJIS X 0201とJIS X 0208のどちらを使ってもか
まわないわけです。結局同じ文字なのですから、そもそも使い分け自体が無意味。
日本語を処理したり表示するときには、二つともまったく同じ文字として扱わな
ければいけません。現存する処理系は壊滅状態ですね。
さて本当にどちらを使ってもいいのかというと、これはJISで決まっていて、JIS
X 0208のかぶっている方については「過去との互換性が要求されるとき以外は使
うな」と書いてあります(JIS X 0208の7.2, 7.3, 9.2)。
まとめますと、
ISO-2022-JP……全角英数は使えない。半角カナは存在しないので論外。
EUC-JP……全角英数は使えない。半角カナは一意の符号化表現が要求されない場
合問題ない。ただし、その場合は全角カナとまったく同じ表示・処理にすること。
しかし、実現出来ていない現状では半角カナは使わない方がいいと思います。
Shift JISの場合:
JIS X 0208の4.2, 4.3, 4.5に書いてあります。「全角英数・半角カナは使うな」
あとJIS X 0201 片仮名の割り当ては削除の予定だそうです。
279:272
03/10/13 03:20.net
例外として、ISO-2022-JP、Shift JIS、EUC-JPで過去との互換を目的として、二
つの文字を区別したい場合はどうするか。JIS X 0208の付属書5にあるように、
JIS X 0201 片仮名にHALFWIDTH、JIS X 0208 数字・ラテン文字・特殊文字に
FULLWIDTHをつけた代替名称を使って区別します。この場合のみ、かぶっている
二つの文字は別物として扱うことが出来ます。
Unicodeの場合:
○East Asian Scripts
・Halfwidth and Fullwidth Forms: U+FF00?U+FFEF
(省略)
As with other compatibility characters, the preferred Unicode encoding
is to use the nominal counterparts of these characters and use rich text
font or style bindings to select the appropriate glyph size and width.
まずい方の文字は使うな、ということです。ただし全角・半角は別物として扱う
ようです。
280:名無しさん＠お腹いっぱい。
03/10/13 07:21.net
>>272
> UTF-8もUTF-16も。
こりゃ言い過ぎだ。
281:名無しさん＠Ｅｍａｃｓ
03/10/13 14:18.net
>>276-279
理想論をただ書き連ねただけのオナニーだな。
実際のアプリケーションでは、過去の文書データと
一切関わりなく使用されるようなことはまずない。
「過去との互換性が要求されるとき以外は使うな」というのは
文字コードの世界ではほとんど意味のない制限だ。
UnicodeもCP932も、いわゆる「半角ｶﾅ」も「機種依存文字」も
既に存在しているものであり、技術者の一方的な都合で
「なかったこと」にすることはできない。
282:名無しさん＠お腹いっぱい。
03/10/13 14:22.net
>>281
> UnicodeもCP932も、いわゆる「半角*ｶﾅ*」も「機種依存文字」も
今あなたが書いたのは「新規」のものだろう。
どこに必要性があるんだ。使うなよ。
283:281
03/10/13 15:00.net
>>282
いやあ、ｽﾏﾝｽﾏﾝ。
本当は「オナニー」の部分も半角ｶﾅで書くつもりだったんだけどね。
「文字コード」ってのは、コミュニケーションの手段である文章を
どうやってデジタルデータに落とすかって話の一部でしかなく、
規格書に記述されていることが全てではない。
半角カナを使って煽りの気持ちを表現したり、
Ascii artのように文字のグリフだけに意味を持たせたりと、
そういう規格書では定義されていない「文化」が
既にあちこちで使われている。
そういう背景を無視して、機械的に「半角カナ→全角カナ」のような
フィルタをかけ、(行間じゃなく)文字コードの間に込められた意味を
消してしまうのは、技術者のエゴじゃないかなと漏れは思うわけよ。
284:名無しさん＠お腹いっぱい。
03/10/13 15:11.net
>>283
そういうのは上のレイヤーでやるべきことで、文字自身にもたせるものではないんです。
所詮、フォントを変えただけで消し飛ぶようなものですから。
285:281
03/10/13 15:22.net
>>284
> そういうのは上のレイヤーでやるべきことで、文字自身にもたせるものではないんです。
> 所詮、フォントを変えただけで消し飛ぶようなものですから。
もちろん漏れも技術者のはしくれなんで、そういう「理想論」は理解できる。
# つーか、仕事でも文字コード関連の問題には何度もぶち当たっているし。
ただ、そういう事情を理解した上で、
「結局、『理想論』は理想論でしかない。」
と言いたいわけよ。
286:名無しさん＠お腹いっぱい。
03/10/13 15:33.net
>>285
> # つーか、仕事でも文字コード関連の問題には何度もぶち当たっているし。
ぶつかるだけなら日本語を含むHTMLを書くだけでもぶつかります。
JISは読みましたか?
> ただ、そういう事情を理解した上で、
全然理解してないですね。
> いやあ、ｽﾏﾝｽﾏﾝ。
> 本当は「オナニー」の部分も半角ｶﾅで書くつもりだったんだけどね。
こんなことを書く程度ですし。
287:名無しさん＠お腹いっぱい。
03/10/13 15:33.net
手書きでも半角カタカナとか全角英数字を浸透させちゃえばいいんだよ。
288:名無しさん＠お腹いっぱい。
03/10/13 15:39.net
四半角仮名や四倍角英数字が Unicode に入るのはいつですか?
289:名無しさん＠お腹いっぱい。
03/10/13 15:47.net
>>286
かっかし過ぎ。
290:名無しさん＠お腹いっぱい。
03/10/13 15:59.net
>>289
かっかしてるわけじゃなくてね、>>281 程度の認識しか持たない人が
しばしば愚かなことを書くからガッカリしてるの。>>281 程度の話は、
今まで数え切れないほど行われてきた。>>276-279 を読めば、こちらが
もっと上のレベルの話をしたいってことは分かると思うんだけどね……
本当は >>276 の人と意見を交換したくて、がんばって長文を書いたんだけど
出てこないかなぁ。
291:名無しさん＠お腹いっぱい。
03/10/13 16:01.net
>>290
> もっと上のレベルの
レイヤは上かもしれないが
レベルは上じゃねーよ。
過去の実装を無視して規格だけこねくりまわしても無意味。
292:名無しさん＠お腹いっぱい。
03/10/13 16:03.net
>>291
そういうのは規格を読んでから言ってね。
293:292
03/10/13 16:11.net
> そういうのは規格を読んでから言ってね。
こんなことを書くと、またアホが「規格規格とうるさい原理主義者」とか言いかねないので
補足しておく。まともな技術者なら、なにかを実装したりする場合一次情報にあたるのは
当然のことなんだ。たとえばHTMLを扱うならW3Cの勧告を読むのは当然だし、もしかすると
HTTPのRFCを読まないといけないかもしれない。
こちらが言っているのは、「規格は至上のものである」ということじゃなくて、日本語の処理を
するなら、読んで当然だってことなんだ。
294:名無しさん＠お腹いっぱい。
03/10/13 16:13.net
厨な質問ですいませんが、たとえば、２ちゃんねるなんかは、
「半角ｶﾅ」と「全角カタカナ」の使い分けが当然のように行われているわけですが、
これは「過去との互換性が要求されるとき」に合致するのではないの？
295:291
03/10/13 16:31.net
「だけ」と書いたのが読めんのか。
296:名無しさん＠お腹いっぱい。
03/10/13 16:39.net
>>295
だから、規格さえ読んでない人は論外なんだって。
297:281
03/10/13 17:28.net
>>286
> > # つーか、仕事でも文字コード関連の問題には何度もぶち当たっているし。
> ぶつかるだけなら日本語を含むHTMLを書くだけでもぶつかります。
> JISは読みましたか?
当然読んでいる。
技術者として、JISやW3Cなどの規格を読むのが
最低限必要なことなのは言われなくてもわかっている。
おそらく、>>286はHTML3.2などで(規格に厳密に従った場合)
日本語を使用することができないってことなどを言いたいんだと思うが、
そういう国際化の規格が決まる前から多くの実装で
日本語を含むHTMLを扱うことができていた。
規格ってのは、その実装ができる前から(もしくはリファレンス実装の作成と並行して)
作られるものもあるが、現状の実装を後追いする形で決まるものも多い。
そのような実装の後追いで決まった規格を使う場合は、
過去の実装や慣例についても十分考慮する必要がある。
特に文字コードのように、「非技術者」に対する影響も非常に大きい分野では、
「規格で推奨されていないから」という理由だけで
過去の慣例を排除するのは、現状を見ていない技術者のエゴでしかない。
# 完全に技術的分野で閉じた話なら構わんと思うがね。
> > いやあ、ｽﾏﾝｽﾏﾝ。
> > 本当は「オナニー」の部分も半角ｶﾅで書くつもりだったんだけどね。
> こんなことを書く程度ですし。
じゃあ、>>281のはじめの一文は
「<煽り>理想論をただ書き連ねただけのオナニーだな。</煽り>」
とでも書くべきだったのか?
俺は「2chでの慣習」に従った書き方をしているだけだ。
298:名無しさん＠お腹いっぱい。
03/10/13 17:55.net
>>297
> そのような実装の後追いで決まった規格を使う場合は、
> 過去の実装や慣例についても十分考慮する必要がある。
はい、そのとおりです。
しかしながらまだその先があります。
たとえば既存の実装が規格とずれていた場合、次の改訂の際に規格に合わせてく
る可能性があるわけです。改訂版では過去との互換性があるとは限りません。
また未知・未来の実装は、基本的に規格どおりに実装する可能性が高いでしょう。
このとき、自分が確認して合わせた実装との互換性をとってくれるとは限りません。
ようするに過去の実装より、規格の方を重視すべきなのです。
もちろんこれは原則にすぎず、他のシステムとやりとりである以上、可能な限り
データ交換可能なものにするべきです。
つまり、「規格より過去の実装の方が重要」という点が間違っているということ
です。規格の重みづけをする場合、過去の実装以外にも考慮しなければいけない
要素がある、ということ。
> 「<煽り>理想論をただ書き連ねただけのオナニーだな。</煽り>」
> とでも書くべきだったのか?
「煽り」とか書いてる時点で人間的にどうかと思います。
それは置いておくとしても、
> 俺は「2chでの慣習」に従った書き方をしているだけだ。
これはただの責任転嫁ですよ。
299:281
03/10/13 19:09.net
>>298
> たとえば既存の実装が規格とずれていた場合、次の改訂の際に規格に合わせてく
> る可能性があるわけです。改訂版では過去との互換性があるとは限りません。
> また未知・未来の実装は、基本的に規格どおりに実装する可能性が高いでしょう。
> このとき、自分が確認して合わせた実装との互換性をとってくれるとは限りません。
> ようするに過去の実装より、規格の方を重視すべきなのです。
それが現実を見ていない理想論に過ぎないと言いたいわけ。
GNU libiconvにcp932パッチがあるのは何故だ?
過去の実装や慣習を無視して新たな規格や実装を作っても、
それは新たな混乱を招くだけ。
300:名無しさん＠お腹いっぱい。
03/10/13 20:00.net
>>299
ちゃんと >>298 を読みましたか?
あなたは「過去の実装」だけしか考えていないので、規格の重みづけが
低すぎるといっているのです。「過去の実装との互換性」以外にも、規格
の重みづけの要素はあるんだよ、と。
> GNU libiconvにcp932パッチがあるのは何故だ?
Microsoftが他者(他社・Unicodeコンソーシアム)と協調してShift JISの
マッピングテーブルを決めるべきところを、無視して独自に実装したためです。
Microsoftのテーブルは個人的には現実的だと思っていますが、まさに
> 過去の実装や慣習を無視して新たな規格や実装を作っても、
> それは新たな混乱を招くだけ。
こういうことです。
301:名無しさん＠お腹いっぱい。
03/10/13 20:58.net
そういえば、どっかの携帯会社が規格の予約領域を勝手に使っていましたね。
302:名無しさん＠お腹いっぱい。
03/10/13 22:17.net
で、何番の発言が AoiMoe なの?
303:281
03/10/13 22:42.net
>>300
> あなたは「過去の実装」だけしか考えていないので、規格の重みづけが
> 低すぎるといっているのです。
そうか? 別に規格をないがしろにしている気はないのだが。
ただ、「Shift JISにおいてJIS X 0201片仮名が割り当てられている部分の
文字のグリフが、JIS X 0208の部分のものの半分の横幅になると
期待すること」および「そういう表示のされ方を期待して、
JIS X 0201片仮名とJIS X 0208片仮名を使いわけること」は
慣習として既に広まっていることだし、
今更目くじらを立てることではないと思っているのだが。
> > GNU libiconvにcp932パッチがあるのは何故だ?
これは俺の表現がまずかった。
俺が言いたかったのは、「何故cp932パッチが本家に統合されずに
別々に配布されなきゃならんのか」ってこと。
確かに>>300の言う通り、cp932のマッピングテーブルはMicrosoftが
勝手に決めてしまったもの。そのためGNU libiconv本家は
cp932パッチの統合をかたくなに拒んでいる。
しかし、日本でiconvを使う場合、cp932のサポートは
もはや必須と言えるため、日本の多くのユーザが
GNU libiconvにわざわざcp932パッチを当てて使っている。
規格至上主義に走り過ぎると、かえってユーザの利便性が
損なわれることがあるって例のつもりだったんだけどね。
304:281
03/10/13 22:46.net
>>302
少なくとも俺は違うぞ。(w
305:名無しさん＠お腹いっぱい。
03/10/13 22:48.net
>>303
> 確かに>>300の言う通り、cp932のマッピングテーブルはMicrosoftが
> 勝手に決めてしまったもの。そのためGNU libiconv本家は
> cp932パッチの統合をかたくなに拒んでいる。
少し前に、libiconvのCVSの方に入ってます。
306:281
03/10/13 22:52.net
>>305
> 少し前に、libiconvのCVSの方に入ってます。
おお、それは良かった。
1.9.1にも入らなかったから、もうダメかなとあきらめていたんだけど。
パッチのマージに尽力された方々にこの場を借りてお礼を申し上げます。
307:名無しさん＠お腹いっぱい。
03/10/13 23:34.net
>>303
> ただ、「Shift JISにおいてJIS X 0201片仮名が割り当てられている部分の
> 文字のグリフが、JIS X 0208の部分のものの半分の横幅になると
> 期待すること」および「そういう表示のされ方を期待して、
> JIS X 0201片仮名とJIS X 0208片仮名を使いわけること」は
> 慣習として既に広まっていることだし、
広まってませんよ。WindowsのMS UI Gothicを使ったことはありますか?
そんな期待はフォントが違うだけで無意味になる程度のものです。
> 今更目くじらを立てることではないと思っているのだが。
やれやれ……
あなたのような適当な考えによる実装が、今の混乱を引き起こしているのです。
予想では今後、Unicodeへの移行によってさらに種は増えるでしょう。
・CJK間で、かなり異なったグリフの漢字が統合されていることによる問題。
上のレイヤーで解決すればいいのですが(たとえばHTMLのlang指定)、
安易な方法としてUnicodeの言語タグを使って実装されてしまう。
言語タグの使用は推奨されていません。
・JIS X 0208の和字間隔、いわゆる全角空白の扱い。
存在が微妙なので、実装のされ方に互換性が無くなる可能性があります。
> 規格至上主義に走り過ぎると、
不適切な例でしたね。こちらは至上主義じゃないって言ってるのに。
予想(>>290)どおりの愚かな展開(平行線)になってしまった。
規格自身について話を振っているのに、「規格なんて二の次だ」なんて的はずれな
返事を返すなんて……。もうちょっと認識のある人の意見を望みます。
308:名無しさん＠お腹いっぱい。
03/10/13 23:44.net
>>281
> 技術者の一方的な都合で「なかったこと」にすることはできない。
日本文藝家協会の方ですか?
309:名無しさん＠お腹いっぱい。
03/10/14 01:35.net
>>307
> 返事を返すなんて……。もうちょっと認識のある人の意見を望みます。
気持ちはわかるが、そういう書き方をするから不毛なやり合いになる。
310:名無しさん＠お腹いっぱい。
03/10/14 12:42.net
>たとえば既存の実装が規格とずれていた場合、次の改訂の際に規格に合わせてく
>る可能性があるわけです。改訂版では過去との互換性があるとは限りません。
日本で作られたソフトは、まず無いと思う。
今までそれが行われていれば、今のような状況とは違ったと思うが。
もっとも、JIS X 0208:1983 やら、うにコードのように、
規格自体が腐ってる事が多い
311:名無しさん＠お腹いっぱい。
03/10/14 13:12.net
＞＞307 あなたのような適当な考えによる実装が、今の混乱を引き起こしているのです。
どのような考えによる、どのような実装が、規格にもなるべく沿いつつ現実的である事ができるでしょうか。
今まで 272 さんは「規格の話をしている」と仰ってました。その通り、276-279 は規格では
否定しているという話にすぎない訳です。（その後は主観の争いになってますが…）
JISは中国のGB18030とは違い、何の強制力もありません。「いけません」と言ったところで、
結局はどこかに落ち着かなければ使い物にならないのが現実ですよね。
312:名無しさん＠お腹いっぱい。
03/10/14 14:21.net
>>311
とはいっても、>>307が言うように、
fullwidth/halfwidthは過去のものにすべく努力していくべきだろ?
313:フグ/ハリセン本について
03/10/14 16:48.net
フグ/ハリセン本について
CJKV日中韓越情報処理
Ken Lunde著
2002年12月発行 12,800円
URLﾘﾝｸ(www.oreilly.co.jp)
Data Table & Sample Code
URLﾘﾝｸ(examples.oreilly.com)
Ken Lunde's Home Page
URLﾘﾝｸ(www.praxagora.com)
314:名無しさん＠お腹いっぱい。
03/10/16 04:31.net
>>311
> 今まで 272 さんは「規格の話をしている」と仰ってました。その通り、276-279 は規格では
> 否定しているという話にすぎない訳です。
そ、それで終わりですか?
あの話は掘り下げるところがまだまだあると思うのですが……
> （その後は主観の争いになってますが…）
人の意見・主調なんてすべて主観です。問題はその妥当性。
> どのような考えによる、どのような実装が、規格にもなるべく沿いつつ現実的である事が
> できるでしょうか。
普通、実装をするまえに規格を洗って、それを整理しますよね。
それをおざなりにして、いきなり実装をしてもまともなものは出来ないでしょう。
過去の実装との互換性があればいい、という適当な考えならいざしらず。
> JISは中国のGB18030とは違い、何の強制力もありません。
強制力とかそんなのはどうでもよくて、使うべきではない文字は使うべきではないのです。
例えばある通信プロトコルで、RFC違反のデータを送受信することは簡単です。互換性
などの理由で、やらざるをえないこともあるでしょう。しかしそれは基本的には「やるべきで
はない」のです。理由は分かりますよね?
315:名無しさん＠お腹いっぱい。
03/10/16 23:26.net
>>314
>強制力とかそんなのはどうでもよくて、使うべきではない文字は使うべきではないのです。
「使うべきではない文字」ってのを誰がどうやって決めるかっていうと、それは
情報の送り手と受け手、両者の合意によるわけだ。
「規格」というのも結局、すべての二者関係毎に個別に合意を取り付ける
手間を省くためのものだし。
316:名無しさん＠お腹いっぱい。
03/10/17 02:21.net
通信かよ!?
317:名無しさん＠お腹いっぱい。
03/10/17 07:44.net
通信だよ
318:名無しさん＠お腹いっぱい。
03/10/17 12:34.net
問題は、技術者だけではなく、ソフトウェアの顧客がそのことを理解して、
いわゆる半角カナを JIS X 0208コードに修正する費用と時間を出してくれるかということもある。
319:名無しさん＠お腹いっぱい。
03/10/18 20:41.net
いまだにJEFつかってる銀行なんか多いくらいなので、、、
やっぱ変更せずに走らせるケースが多いのでは？
320:名無しさん＠お腹いっぱい。
03/10/24 01:00.net
> 嘘があったり
「使うべきでない」を「使ってはいけない」と表現したり
まさかMUSTとSHOULDの区別も付かないわけじゃないですよね
> 重要なことが抜けてたりするので
「過去との互換を目的として」とかの例外事項を無視して
「使ってはいけない」としか書かなかったり
しかも知ってて抜かすんだからより悪質ですね
321:名無しさん＠お腹いっぱい。
03/10/24 01:03.net
文字コードが通信が終わったら端から消えていくなら
実装を変えればそれで終わりだろうけど実際には
データとしてどんどん蓄積されていくから途中で変えて
はいおしまい、過去のデータは全部捨ててください
なんて簡単に言えるわけない。
322:名無しさん＠お腹いっぱい。
03/10/24 01:43.net
そういえば>>232の何が結局「嘘」なのかも説明してませんね。
323:名無しさん＠お腹いっぱい。
03/10/24 20:06.net
> 「規格」というのも結局、すべての二者関係毎に個別に合意を取り付ける
> 手間を省くためのものだし。
はい、そのとおりです。
> 問題は、技術者だけではなく、ソフトウェアの顧客がそのことを理解して、
> いわゆる半角カナを JIS X 0208コードに修正する費用と時間を出してくれるかということもある。
実装の話が好きですね……。
さかのぼって修正する必要はないんでは? そのために「過去との互換性」うんぬんの
くだりがあるわけだし。したいのなら止めませんが。
324:名無しさん＠お腹いっぱい。
03/10/24 20:08.net
> 「使うべきでない」を「使ってはいけない」と表現したり
> まさかMUSTとSHOULDの区別も付かないわけじゃないですよね
「使うべきではない」ものを、相当の理由なく使おうとしている場合、
「使ってはいけない」と伝えても問題ないでしょう。
> 「過去との互換を目的として」とかの例外事項を無視して
> 「使ってはいけない」としか書かなかったり
> しかも知ってて抜かすんだからより悪質ですね
また低レベルな、平行線の話を繰り返したいのですね。
> はいおしまい、過去のデータは全部捨ててください
> なんて簡単に言えるわけない。
どうして捨てる必要があるのでしょうか?
新規で使わなければいいだけなのに。
> そういえば>>232の何が結局「嘘」なのかも説明してませんね。
>>277-279 を読みましたか? 読んでも分かりませんか?
そこに含めてあるんですが……
325:名無しさん＠お腹いっぱい。
03/10/24 21:55.net
>>324
> 新規で使わなければいいだけなのに。
"今まで使えてただろ！ どうにかしろ ！"
326:名無しさん＠お腹いっぱい。
03/10/24 21:56.net
> "今まで使えてただろ！ どうにかしろ ！"
そんな人いますか?
327:名無しさん＠お腹いっぱい。
03/10/25 01:28.net
とりあえず、既存の規格を無視するやつをなんとかしろよ。
docomo とか。
328:名無しさん＠お腹いっぱい。
03/10/25 07:05.net
わざと無死してるわけですが
329:名無しさん＠お腹いっぱい。
03/10/26 03:22.net
>>326
います
330:名無しさん＠お腹いっぱい。
03/10/27 17:01.net
> 「使うべきではない」ものを、相当の理由なく使おうとしている場合、
誰がそんなことしてるんですか?
> また低レベルな、平行線の話を繰り返したいのですね。
そもそも>>272が低レベルな煽りから始まっているのです。
そういうのを自業自得といいます。
> どうして捨てる必要があるのでしょうか?
新しい実装で読めないからです。
331:名無しさん＠お腹いっぱい。
03/10/27 17:04.net
> さかのぼって修正する必要はないんでは? そのために「過去との互換性」うんぬんの
> くだりがあるわけだし。
それこそがまさに「相当の理由」でしょうが。
332:名無しさん＠お腹いっぱい。
03/10/27 17:11.net
> >>277-279 を読みましたか? 読んでも分かりませんか?
> そこに含めてあるんですが……
順番に検証してみようか。
>>276
リンク先のどこにも「JIS X 0201のカタカナ」が特殊なカタカナだ
なんて一言も書いてない。自分以外の愚民は使うべきでないものを
使いたくて使いたくてたまらないから「JIS X 0201のカタカナ」と
書かれていたらそれは即特殊な意味を持たせていてそれ以外の
解釈はありえないとか妄想したけりゃしてもいいけど。
333:名無しさん＠お腹いっぱい。
03/10/27 17:16.net
> ISO-2022-JPで
リンク先は「ISO-2022-JPで」使うなんて話はしていない。
7bit-JISの話なら出てくるけど。
> EUC-JP
> Shift JIS
そもそも「使ってはいけない」が嘘だから論外
334:名無しさん＠お腹いっぱい。
03/10/27 17:20.net
> Unicodeの場合:
リンク先にはUnicodeの話などまったく出てこないが。
そもそもJIS X 0201の話をしてるのにUnicodeが出てくること自体
ヘンだとお前さんが自分で言ってるだろ。
> 勘違いの典型は、「UnicodeでJIS X 0201の片仮名は使えますか?」などと
> いう質問で、
総論:
リンク先とは無関係な、誰に言ってるのかも不明な論を
一方的にまくし立ててるだけ。
> ６：一見関係ありそうで関係ない話を始める
で、どこが嘘なの?
335:名無しさん＠お腹いっぱい。
03/10/27 17:26.net
> 広まってませんよ。WindowsのMS UI Gothicを使ったことはありますか?
> そんな期待はフォントが違うだけで無意味になる程度のものです。
区別しない実装が存在することは区別しない慣習が存在することの
否定にはならない。単に区別しない場合もあれば(規格上区別する
理由はないんだから当然だが)慣習上区別する場合もあるという
だけのこと。
だいたい使い分ける慣習が本当に存在しないならあんたの
大好きな規格書はありもしない慣習との互換性に配慮するために
わざわざページを割いてるの?
こんな初歩的な詭弁にすらツッコミが入らないようじゃ
確かにレベル低いかもね
336:名無しさん＠お腹いっぱい。
03/10/27 17:40.net
> 区別しない実装が存在することは区別しない慣習が存在することの
訂正
区別しない実装が存在することは区別する慣習が存在することの
337:名無しさん＠お腹いっぱい。
03/10/27 20:50.net
とりあえず引用トークはムカつくっつーことだけは
よ～くわかった。
338:名無しさん＠お腹いっぱい。
03/10/27 21:13.net
>>337
> とりあえず引用トークはムカつくっつーことだけは
fjを思い浮かべるからかな。
などと引用してみるテスト。
339:名無しさん＠お腹いっぱい。
03/10/29 03:53.net
>> また低レベルな、平行線の話を繰り返したいのですね。
>そもそも>>272が低レベルな煽りから始まっているのです。
> そういうのを自業自得といいます。
責任転嫁をしないように。
低レベルな話を持ち込んだのは、あなた自身の責任です。
さて、>>330-336 には、簡単に分かる間違いがいくつかあります。
・認識不足による誤解・間違いが4つ
・引用部分とは関連のない話を持ち出して、返答しているのが1つ
それぞれどこでしょう。
>>330-336 の人は分からないでしょうから、他の方で結構です。
考えてみてください。
それから、>>330-336 を書いた人への課題も出しておきます。
>> ISO-2022-JPで
> リンク先は「ISO-2022-JPで」使うなんて話はしていない。
> 7bit-JISの話なら出てくるけど。
「7bit-JIS」とは?
340:名無しさん＠お腹いっぱい。
03/10/29 03:57.net
間違い探しクイズなんてしてないでハッキリ言う方が良いのでは？
と傍観者は思うのでした。
341:名無しさん＠お腹いっぱい。
03/10/29 04:04.net
死めよ。おぬーら。
342:名無しさん＠お腹いっぱい。
03/10/29 18:58.net
>>340
論理的思考が出来ない人間とのメタ議論は、しばしば発散するからです。
343:名無しさん＠お腹いっぱい。
03/10/29 22:26.net
>>341
はっきり言いすぎですYO!
344:名無しさん＠お腹いっぱい。
03/10/29 23:18.net
すんません! この系統に関してはドシロウトなんですが...
o コードセットとグリフの関係とか
o ウニコードとステートフル(ってゆうのか?)なコード体系の関係
とか
に関して, そこそこまとまった資料って, どこ参照すればええんで
すか?
# グリフの合理的指定方法があれば何とかなるもんちゃうの???
345:名無しさん＠お腹いっぱい。
03/10/29 23:32.net
>>339
手抜きせずに書いてやれよ。
>>276 と >>277-279 はあきらかに別人。
>>333-334 は >>272 の↓部分の補足であるものを、リンク先についての言及だと
曲解している。
>たいていの場合、JIS X 0201の片仮名用図形文字集合(いわゆる半角カタカナ)は
>使ってはいけない。ISO-2022(例外あり)もISO-2022-JPもShift JISもEUC-JPも
>UTF-8もUTF-16も。
>同様にJIS X 0208の一部の文字(いわゆる全角英数)も使ってはいけない。
>「?」や「/」のJIS X 0208の方もダメ。
>>335 に対しては、互換性が残されているのは、文字幅の慣習とは無関係。
あと >>272 は >>232 のリンク先について誤解していると思う。
あのページは誤りであることを承知の上で、JIS コード（と言われている文字コード）で
JIS X0201 の文字集合を使う方法を紹介している。
232氏はネタのつもりだったのでは。
346:名無しさん＠お腹いっぱい。
03/10/30 01:59.net
質問
jisx0213の文字って全部unicodeに反映されたの?
347:名無しさん＠お腹いっぱい。
03/10/30 02:13.net
されてない
348:名無しさん＠お腹いっぱい。
03/10/30 10:49.net
>>347
どの程度反映されてるんでせうか?それともまったく?
349:名無しさん＠お腹いっぱい。
03/11/02 00:02.net
補助漢字にある奴は全部あるでしょ。
丸付き数字のような合成文字系は全部拒絶されてんじゃない?
350:名無しさん＠お腹いっぱい。
03/11/02 01:48.net
丸付き数字系は全て追加されました。
351:名無しさん＠お腹いっぱい。
03/11/02 01:55.net
>>349-350
つーことは一部を覗いてほとんど入れられてるって事ですか。
ありがとうございました。
352:名無しさん＠お腹いっぱい。
03/11/02 01:56.net
sage忘れた…すいません。
353:名無しさん＠お腹いっぱい。
03/11/02 01:59.net
確か追加されてないのはひらがなとアクセント付きの発音記号だけだったと思う。
354:名無しさん＠お腹いっぱい。
03/11/03 13:58.net
Unicodeでの外字の扱いってどうなってんの?
使えんの？
355:名無しさん＠お腹いっぱい。
03/11/03 16:55.net
PUAでいいんじゃね？
356:名無しさん＠お腹いっぱい。
03/11/03 22:55.net
>>353
ひらがなってのは、'ん'+'゛'みたいなやつのこと?
357:名無しさん＠お腹いっぱい。
03/12/06 17:00.net
>>353
Unicode側の言い分では「全部入れた」ことになっているんだろうけどね。
「合成で済むだろゴルァ」って感じで。
358:名無しさん＠お腹いっぱい。
03/12/08 11:28.net
結局混乱を増しただけだと思うんだけどなー。
あぁ、日本以外じゃ困らんから、テキトーな国際化には役に立っとるんか。
359:名無しさん＠お腹いっぱい。
04/02/25 00:35.net
ｽﾚﾘﾝｸ(software板)
>>874
格納がしっかりしてれば文字コードが必ずSJISになり
どの文字コードで格納するか調べる必要も無いでしょう。
>>875
予想だろうがそれが根拠で問題だと『俺は』思う。
俺の思う理由を聞いておいてそれは無いだろう。
360:名無しさん＠お腹いっぱい。
04/02/25 00:47.net
>>876
その必要が有る人のみ守ってるだけでは？
普通は日本語使わないけどね。
>>877
殆どはASCIIで書かれてるからな。ASCIIはSJISで無いぞ。
稀に見かける日本語を使った書庫ではeucを使ってる。
でもSJISを使ってるのは見たこと無いとも書いたが。
>>878
作者は仕様を守るべきなんじゃない？
それが出来ないなら作らなければ良いだけ。
仕様を制定するのが自分なら殆ど負担は無いだろう。
361:名無しさん＠お腹いっぱい。
04/02/25 01:19.net
>UNIX上でも SJIS 使ったのしか見たこと無いね。
俺は無いな、少なくとも配布されてるものに関しては。
>仕様を制定したのと、UNIX版作ってる人は別人。
>同一人物でも仕様をコロコロ変えるのはどーかと思われ。
これは誤解を生んじゃったな。
lhaの事じゃなくソフトウェア作者の苦労の事を書いただけだから
その辺の事は分かってるし同意。
>仕様が無い場合という仮定の話なので文字コードは SJIS とは限らない。
格納をしっかりすれば仮定の話は何の意味も無い。
362:名無しさん＠お腹いっぱい。
04/02/25 01:35.net
>それらの書庫はファイル名に関する仕様を守ってる。
日本語ファイル名を格納してる書庫の話でしょうが。
ASCIIファイル名は日本語扱うときはSJISでって仕様を満たしている訳じゃない。
>必要がある人は自力で実装すれば良い、
>という事のどこに問題があるのかサッパリわからん。
それじゃぁ自力で実装する力の無い人、そもそもそんな事考えて無い人が作った
書庫は不正書庫になってしまうじゃないか。
大抵の人はlhaにそんな仕様が有る事すら知らないだろう。
何べんも書くけど守られない仕様は仕様の機能を果たさない。
仕様がしっかり守られるならば解凍時の文字コードも気にしなくて良い。
363:名無しさん＠お腹いっぱい。
04/02/25 01:38.net
>ファイル名に関する仕様が無い場合、
>UTF-8 でも SJIS でも EUC でも仕様的に問題なく「しっかり格納」できる。
lhaはSJISで格納すると言う仕様が有るんでしょ。勝手になくさないで。
364:名無しさん＠お腹いっぱい。
04/02/25 01:59.net
>ファイル名に関する仕様は満たしてる。
日本語のファイル名の話をしてるんだから・・・。
関係ない話を持ち出さない。
>何べんも書くけど仕様は概ね守られてる。
>例えば、信号無視する人間が延べで 5%居た場合、信号は機能を果たしてないのか？
たとえ話は嫌いだが、、、この場合その5%は必ず事故るわけだから信号の機能を果たしてるとは言いがたい。
365:名無しさん＠お腹いっぱい。
04/02/25 16:30.net
向こうで暴れてる困ったちゃんをどうにかしろよ
366:名無しさん＠お腹いっぱい。
04/02/25 16:44.net
lhaの書庫はパス名にShift JISを使うって仕様だったのか。知らなかった。
どこに書いてあるんだろう。
367:名無しさん＠お腹いっぱい。
04/02/25 17:57.net
>>365
ここで暴れてる困ったちゃんもどうにかしてください。
368:名無しさん＠お腹いっぱい。
04/02/26 08:55.net
>>366
昔のlhaのドキュメント
369:名無しさん＠お腹いっぱい。
04/02/26 09:36.net
>>368
Vectorにある吉崎氏の実行ファイルとソースのアーカイブ内には
そういう記述はみあたらなかった。
URLﾘﾝｸ(www.vector.co.jp)
「昔のlha」は持ってないしなぁ。
ただ、UTIL.Cにiskanji(c)というマクロがあって、それはShift JISを
想定しているっぽい。
#define iskanji(c) ((uchar)(c) >= 0x80 && (uchar)(c) <= 0x9f || \
(uchar)(c) >= 0xe0 && (uchar)(c) <= 0xfd)
370:名無しさん＠お腹いっぱい。
04/02/26 11:18.net
>>369
lha for UNIXの方だったかもしれん。
だったらそんなに昔じゃないなｽﾏｿ
371:名無しさん＠お腹いっぱい。
04/02/26 15:56.net
詳しくは知らんが、YosshiがSysopやってたflaboでは
過去ログ(LZHで固めた奴)にSJISファイル名使ってたような…
372:名無しさん＠お腹いっぱい。
04/02/26 16:35.net
いや、当初はMS-DOSしかっていうか何も考えなくて生SJISにしたはずなんだけど、
どっかでそれを仕様として確定したと思うんだよ。
それがlha for UNIX以前か以後かがよー分からん。
373:名無しさん＠お腹いっぱい。
04/02/26 16:40.net
よーわからんけどlha for UNIX以前か以後かって区分は重要なの？
374:名無しさん＠お腹いっぱい。
04/02/26 16:57.net
>>372
> いや、当初はMS-DOSしかっていうか何も考えなくて生SJISにしたはずなんだけど、
だろうね。
> どっかでそれを仕様として確定したと思うんだよ。
これが、「誰が」「どこで」確定したのか情報希望。
375:名無しさん＠お腹いっぱい。
04/02/26 18:46.net
よーわからんけど「誰が」はともかく「どこで」は重要なの？
376:名無しさん＠お腹いっぱい。
04/02/26 23:01.net
☆ ﾁﾝ ﾏﾁｸﾀﾋﾞﾚﾀ～
ﾏﾁｸﾀﾋﾞﾚﾀ～
☆ ﾁﾝ 〃 ∧＿∧ ／￣￣￣￣￣￣￣￣
ヽ ＿＿_＼（＼・∀・） ＜ 「誰が」「どこで」確定したのか情報まだ～？
＼＿／⊂ ⊂＿ ) ＼＿＿＿＿＿＿＿＿
／￣￣￣￣￣￣ ／|
|￣￣￣￣￣￣￣| |
| .愛媛みかん. |／
377:名無しさん＠お腹いっぱい。
04/02/26 23:06.net
>>375
> よーわからんけど「誰が」はともかく「どこで」は重要なの？
必ずしも吉崎氏が策定する必要は無いんだよ。
仮に「LHA Open Group」でもいいわけだし。
そういう意味の「どこで」ってこと。
378:名無しさん＠お腹いっぱい。
04/02/27 00:38.net
>>377
> 仮に「LHA Open Group」でもいいわけだし。
それは「誰が」だと思うんだが…
まぁどっちでも良いけど。
ところで「LHA Open Group」って実在する組織なん？
379:名無しさん＠お腹いっぱい。
04/02/27 00:40.net
>>378
> ところで「LHA Open Group」って実在する組織なん？
いやー俺の脳内団体だよ。「誰が」だけだと「吉崎氏に決まってるだろ」と
なりかねないので書いたのだけれど、よけい混乱させちゃったみたいで
申し訳ない。
380:名無しさん＠お腹いっぱい。
04/03/01 10:58.net
過去の経緯としてはShift JISが仕様だったのかもしれないが、
# 補助漢字や第三/四水準はどうなっているのだ?
それだとASCIIな人と日本語な人以外は困るから、
アーカイブ内のパス名はUTF-16で保存することにして、
システムごと、あるいはロケールごとに、iconvして展開するのがいいんじゃないの?
アーカイブ形式に形式のバージョンを持てないの?
大体、今やWindowsやMac OS Xだって、
UTF-8のパス名持てるんだから、Shift JISのままじゃ困るんじゃないの?
381:名無しさん＠お腹いっぱい。
04/03/01 11:06.net
>>380
そこでなぜUTF-16。こういう場合はUTF-8だろう。
lhaは圧縮形式としてlh5, lh6, lh7などが選べたはず。
これが規定するレイヤーによっては、「lh8はUTF-8」という風にも
出来るだろうね。多分やらないだろうけど。
382:380
04/03/01 11:16.net
>>381
追記。なぜ「やらない」かというと、lhaは歴史的な経緯では小型の
システム(DOS)で使われてきたし、現在もそういう風に使われている
(マザーボードのBIOSとかね)。ここでUnicodeをサポートために巨大な
変換テーブルを持たせるのは、lhaの方向性にあわないだろう。
そういうのが必要なら、もっと富豪なアルゴリズムを持つ書庫の仕様に
含めればいいのだ。
383:名無しさん＠お腹いっぱい。
04/03/02 03:34.net
>>380
> それだとASCIIな人と日本語な人以外は困るから、
日本人以外は使ってないので困らない。
> アーカイブ形式に形式のバージョンを持てないの?
持てません。
384:名無しさん＠お腹いっぱい。
04/03/02 03:41.net
>>381
> これが規定するレイヤーによっては、「lh8はUTF-8」という風にも
面白いアイデアだと思うけど、
全く問題無しってわけにもいかないと思うよ。
例えば この新仕様に対応してないバージョンで、
書庫->書庫で圧縮されたファイルコピーする際に
SJIS(元書庫)->EUC(中間処理用)->SJIS(先書庫) みたいな変換
食らった場合、元書庫で UTF-8 使ってると化ける可能性がある。
385:381
04/03/02 09:04.net
おっと、382を書いたのは381だ。名前欄は間違い。
386:名無しさん＠お腹いっぱい。
04/03/02 09:27.net
>>384
「規定するレイヤー」っていうのは、「lh5, lh6, lh7などが書庫の形式のレイヤーを
規定しているなら」って意味で書いた。でもどうやらファイル一つ一つの圧縮方法
にしかすぎないようだね。というわけで俺の案は没。理由は384の言うとおり。
387:( ﾟДﾟ)＜ﾎﾞｸﾒｰﾂ ◆uhiboKUMEQ
04/03/05 10:17.net
( ﾟДﾟ)＜呼ばれた気がした
388:名無しさん＠お腹いっぱい。
04/03/05 20:23.net
＞今現役でSJISつかってるのMSくらいだし。
NTはunicodeだろ。
むしろsjisもjisもeucも無くなれ
uncode以外のコードは要らん
389:名無しさん＠お腹いっぱい。
04/03/05 20:57.net
>>388はMarkus Kuhn
390:名無しさん＠お腹いっぱい。
04/03/06 14:12.net
Markus ｷﾀｰ。
アイツは頭がオカシイとしか思えん。
391:名無しさん＠お腹いっぱい。
04/03/06 20:10.net
388 が欲しいのは
「うんこーど」。
Markus とベクトルは違えど頭がオカシイのです。
392:名無しさん＠お腹いっぱい。
04/03/08 08:40.net
>>388
普通のプリンタの内部コードはJISだろ。そうじゃないのもあるのかな？
393:名無しさん＠お腹いっぱい。
04/03/08 11:51.net
>>389
Markus KuhnとMarkus Scherer(@IBM)は別人なんだね。混同してた。
Markus Kuhnのいかれたエピソード希望。語ってください。
394:名無しさん＠お腹いっぱい。
04/03/08 12:27.net
i18n@XFree86.orgで「UTF-8以外のlocaleを廃止してしまえ。」とか言ってた。
この人の辞書にはsoft landingという言葉はないと思われ。
395:名無しさん＠お腹いっぱい。
04/03/08 12:33.net
>>394
> i18n@XFree86.orgで「UTF-8以外のlocaleを廃止してしまえ。」とか言ってた。
> この人の辞書にはsoft landingという言葉はないと思われ。
なんだその程度か。いいんでない? 俺もそう思ってるし。
「漢字なんて絵文字。使ってる奴らはバカ」くらい言ってるのかと思ってた。
396:名無しさん＠お腹いっぱい。
04/03/08 13:52.net
> なんだその程度か。いいんでない? 俺もそう思ってるし。
今は随分状況が改善されてるけど、3年くらい前にこんなこと言われたら
正直たまらんですよ。まあそれはそれとしてこんなのもあった。
URLﾘﾝｸ(slashdot.jp)
URLﾘﾝｸ(slashdot.jp)
397:名無しさん＠お腹いっぱい。
04/03/08 14:00.net
返す返すも中国がうらやましい
398:名無しさん＠お腹いっぱい。
04/03/08 14:09.net
>>396
昔の i18n-ML 読めないんだな。
特に 4.0.2 リリースの頃の発言とか、迷言ばかりだったと思うんだが。
> 今は随分状況が改善されてるけど、3年くらい前にこんなこと言われたら
> 正直たまらんですよ。
改善？
本質を理解せずに、国際化・多言語化はとりあえず Unicode にしとけ、
なんて間違った認識が広まりすぎただけだと思うが。
399:名無しさん＠お腹いっぱい。
04/03/08 14:13.net
>>396
おー、ありがとう。読んでみた。
まぁ気持ちは分かる。
そもそもターミナルエミュレータは右から左に書くことを想定して作られて
いないんだから、もっとリッチな環境でのみサポートしろってことだよな。
「不合理な宗教的な理由で使われている」っていうのは滅茶苦茶だが。
関係ないけど、縦書きターミナルエミュレータってあるのかなぁ。
400:名無しさん＠お腹いっぱい。
04/03/08 14:29.net
mlterm は縦表示できますよ。
401:名無しさん＠お腹いっぱい。
04/03/08 15:45.net
>>398
日本語のロケールとしてUTF-8を採用するかという話では
ないのですか
402:名無しさん＠お腹いっぱい。
04/03/08 15:57.net
>>401
(ﾟДﾟ)？
403:名無しさん＠お腹いっぱい。
04/03/08 16:03.net
>>401
XUtf8*系のAPIを突っ込もうとしていたときの話。(*1)
つか、UTF-8以外のlocaleを捨てるなら、そもそもそんなものを突っ込む
必要あるのかよと小一時間(ry
*1) 結局4.0.2というマイナーリリースに駆け込みで突っ込まれた。
正直「XFree86のリリースマネージメント終わってるな」と思ったが。
404:名無しさん＠お腹いっぱい。
04/03/08 21:45.net
禿げどう
405:名無しさん＠お腹いっぱい。
04/03/08 23:49.net
うにこん最強
406:名無しさん＠お腹いっぱい。
04/03/09 11:07.net
>>401みたいな的外れなレスが付くあたり、原理主義者の布教は上手く行ったんだろうな。
407:401
04/03/12 15:37.net
> 今は随分状況が改善されてるけど、
についてだったんだが
408:名無しさん＠お腹いっぱい。
04/03/13 15:09.net
誰か XF86 fork して Xutf8* 消して CSI xterm 入れてくれYO。
409:名無しさん＠お腹いっぱい。
04/03/13 15:25.net
>>408
それってまんまOpenI18Nじゃね？
410:名無しさん＠お腹いっぱい。
04/03/13 21:24.net
>>409
openi18n.orgって規格団体みたいのじゃないの？
他に同名のがあるの？
411:名無しさん＠お腹いっぱい。
04/03/16 16:27.net
>>410
openi18n.orgでXLib-I18Nとitermが開発されている。
XLib-I18NはXFree86のクライアントライブラリのfork。
itermはCSIなターミナルでフレームバッファ版とX11版がある。