SJIS撲滅運動

UNICODEかEUCに統一してほしい。今現役でSJISつかってるのMSくらいだし。MacもOS-XからほぼEUCとUNICODEだし。
MP3のIDタグが統一できなくて困る！
SJISで書かれたperlとか置かれたら管理しにくくて困る！
タマにはUNIXでも日本語ファイルを堂々とつかってみたい！

UNi印普及まで5年待て。

Linux板についでここでもかよ。
いつものように忠告してやるが、CCSとCESの区別はつくか? ISO2022って何だか知ってるか?

撲滅運動とぬかすからには覚悟しろ。

HP-UXでja_JP.SJIS
Solarisでja_JP.PCK

>>3
そんなに SJIS好きなん？

どちらかというと2022系のほうが好きだ。
単に>>1が厨房だとこの上ないクソスレになるだろうから聞いてみただけ。

2022なんて作らずにEUCでいったらいいんです。
2022無駄。古くからあるのでいいんじゃない？

CCS...Console Communication System
CES...Crew Esacpe System

ですがなにか?

http://www.ksc.nasa.gov/facts/acronyms.html

>> 2022無駄、SJISも無駄。

確かに資源の無駄使いだな。

> 2022なんて作らずにEUCでいったらいいんです。
いやだからさ、こういう発言をしちゃう厨房があふれるでしょ?と言ってる。

iso-2022-jp と junet ってどうちがうの。

MS>>>>>>>>>>>>>>>>>>>>>>>>>>>>others

iso-2022-jp-2 とかは...
とりあえず、unification より multiplication マンセー。

でもランダムアクセスが出来るってのは捨てがたいかもしれない。>unification

最新流行は CSI。これ。

>>15
unification とランダムアクセスは
直接関係ないと思われ。

Coding System Independent?
ううーん、わからない。調べまーす。

おしかった!
CodeSet Independence でした。

ちょっとずれてるけど、
http://www.idg.co.jp/lw/back/200111/20011124_01_solaris.html

Unix板で文字コードを云々したいなら
CCS/CESぐらいしっとけ。
http://www.unicode.org/unicode/reports/tr17/

ていうか、マジ頼むよ。日本の未来は厨房の成長にかかってんだからさ。

つか、文字セットとエンコード、じゃだめなんか？
むやみに略語増やすのやめて欲しい、と泣いてみる。別に略語に
してもかっこよくないぞ？

別にかっこいいから略してるわけじゃ
ないと思うが。

文字セットはCCSとACR、
文字エンコーディングはCEFとCESにほぼ対応しますな。

CEFってunicode以外で聞いたことないんだけど、
他でも使ってる?

世界中のみんなが納得するのが存在すればいいけど
実際存在しないんでしょ？

そもそも文字を抽象的実体としてコード化するなどという
発想じたいが、哀しいまでに現代人が西洋合理主義的思考に
染まってしまったことのあらわれである。

文字コードはすべて廃止しる！！！

>>25
代案は?

絵のまま保存?
容量と検索がなんとかなればそれもまたイイ!

>>26
昔、fj.comp.misc あたりで当用海亀がそんなこと逝ってたのを思い出した...
# 奴が2chに降臨されたらとてもうざいので伏せ字。

>>26
富豪的だね。
でもどう処理するのか想像出来ない洩れは一生下級プログラマなんだろな...
文字列を保持するバッファがとんでもなくでかくなりそ。
32 bit じゃアドレス空間足りないね。

ttp://www.euc.jp は勉強になるよ.
あと linux 板の EUC 撲滅スレも.

>>25のネタはまえにLinuxのEUC撲滅スレでも使ったんだが、
ソートはどうするのかと言われて挫折した。
しかし分類整理なんてのは西洋合理主義的思考以外の何物でもないので無視じゃ！

いずれにせよ、文字認識の APIが strcmp 感覚で使えるようになる日まで
この案の実装はおあずけだろう。

UNICODEはともかく「EUCに統一」というのは納得イカン。
文字列の先頭から舐めないと文字の判別が出来ないから嫌。

UNICODEのバーションはどれが良い？

shift_jis は 2ch.net がつかってるよん。

>>31
それじゃあ、UTF-7, UTF-8も駄目?

文字撲滅。早く脳とUSB接続しようよ。

現状を考えたら、むしろEUCに固執する方がおかしいのかと思われるよ。
なんでS-JISネイティヴな環境を作り得ないのかって思うね。
ま、無理だろうけどね。

で、1 が 2ch で吠えると SJIS が撲滅できるの？

＞今現役でSJISつかってるのMSくらいだし
Appleは？

ところで、Lynxで表示はEUC、書き込みはS-JISってできませんか？
Lynxで2ch使いたいんですがうまく行かなくて。

w3m 使えば？

>34
UTF-8は、任意のoctetの上位2bitを見れば
A) 1バイト文字
B) 多バイト文字の1バイト目
C) 多バイト文字の2バイト目以降
のいずれなのかを見分けられる。
だから最大でも1文字分戻ればよい。
ShiftJISやEUCのように、「文字の境界」が見つかるまで戻る必要はない。

>>39
lynxじゃなくてnavi2chを使ったらどう？
Webブラウザじゃないけども、emacs側さえ設定すれば簡単だよん。
ちなみに俺は表示も入力もSJISだ、、、、、

>>39
1. 日本語 SLANG を入れる。
2. Lynx2.8.4にこのパッチあてる: http://www.unixuser.org/~euske/pub/lynx2.8.3-jp-fix4.patch
3. ./configure --with-screen=slang --enable-cjk && make

でも、めんどくさいので w3m 使ったほうが楽じゃない?

>>36
SolarisはCSIだよ。
Shift_JIS dependentなpatchは、本家に取り入れられないでしょ。

>>43
色々対応策ありがとうございます。
w3mを取りあえず使用しています。
多行テキストボックスごとにxemacs(-nw)が起動するのがアレですが。
xemacsの方で日本語処理に問題があるらしく（こちらの設定ミスだと思います）、
改行コードが化けたりします（telnetクライアント側のIMEで入力）。

見た目は遙かにw3mがいいですね。
取りあえず教えていただいたpatch使ってみます。

w3m + nvi-m17n。これ最強。

>>34 の論理だと、single byte only ですな。
それとも UTF-8 を誤解しているのか。

MacOSX使いです。
Unicodeに統一激キボーンです。
ウィナーのIとかIIが(藍)とか表示されて困る。

　　ﾊﾊﾊ
　 ∧＿∧　　／￣￣￣￣￣￣￣￣￣
　（　＾∀＾）＜　　あほか >>47
　（ つ ⊂ ）　＼＿＿＿＿＿＿＿＿＿
　 .）　 ）　）
　（_＿）＿）　　　　　（＾∀＾）ｹﾞﾗｹﾞﾗ

>>41
ﾊｧ？ Shift_JISやEUCにシフトコードは無いだろ？？

あ、任意のoctetって事ね。スマソ。

>49
うるさいよ厨房。勉強して出直せ。
「お前のいうところの」シフトコードとやらは、少なくともEUC_JPにはあると思うぞ（げら
single shift で googleしる。

>18

おおお。樋浦さんの原稿だ。

M$一味のUnicodeがなければUTF-8がまともに
出来上がってすべて丸く収まったろうに。

>53
そういうのを引かれ者の小唄っていうんだよ。
世の中理想論だけじゃ動かないんだから、政治的に立ち回れない方が
負けるのは性がない。

でもＭＳがコードを乱してくれたお陰でコード変換というお仕事に
ありつけたプログラマーもいるのれす。。。
わたし？むふふふふ。。。

IT で生産性は上がらない、と。

(◕ฺ∀◕ฺ)
>>49 http://euc.jp/ を読むとヨイデスYO

>>34
UTFならOK。若干メモリ使用量が増えることが不満だが、そんな不満は今時古いか。

どっちかっつーとEUC撲滅して欲しいよ。

日本語撲滅!!!

>60
フランス語も。

漢字撲滅!!!

アメリカ撲滅!!!

そして人類は滅亡した。

今アメリカがいなくれなれば世界は平和

鬼畜米英!!!

ASCII撲滅!!!

>67
Impressもついでに撲滅!!

sb

良スレあげ


と。

週刊ASCII廃刊!!

>71
噂の真相もついでに撲滅!!

さすがにネタ切れか?

俺撲滅!!!

お前ら!撲滅!!!

僕滅!!!

>76
ﾜﾗﾀ

おれ的には社内の負の遺産「JEF」をどこかにおいやって欲しい・・・

>>76
やられた…

>>49
EUC には一応 SS2 と SS3 っていうシフトコードはあるよ。
シングルシフトだからすぐ解除されるけど。

>80
51にて既出

UNICODE委員会の日本語・中国語・ハングルの似たような漢字を統一させようと
いうのは、非漢字圏の横暴だったと思う。欧州のアルファベット異体字には寛容
なのに。
次世代３２ビットUNICODEは４３億まで可能と言うから、早いとこ策定して文系
研究者が文字に苦しまなくて済むようにして欲しい。今はレジェメ作成の為だけに
『今昔文字鏡』なんてソフト導入してるし。
あ、MSがUNICODEに乗ってこないとどの道意味無いか・・・

>>82
がいしゅつだけど linux 板の euc 撲滅スレは
興味深い話題がいくつかあるよ

>>82
漢字統合は、別に横暴でもなんでもないとおもうが、0208 の変換テーブルが
山ほどあるのはたまらんな、ってーか、そっちをちゃんと統合しろや、ｺﾞﾙｧ > Unicode.org

それはそうと、MSがUNICODEに乗ってこないだろうと判断した根拠はなんじゃろな?

>>82
>次世代３２ビットUNICODE
ってなに?

age

>>82
MS はもう Unicode 移行してるぞ。Windows で内部的には Unicode 扱えるようになってる。
必要なところがアプリ作れと言う立場だと思う。
IME や日本語 MS アプリの対応が進んでないのは、日本法人が必要性感じてないからだろう。
他メーカーも同様。

ここだけ5年前のスレですか?

>>88
そうです。

>>87
Win9x系はVFAT以外Unicodeサポート無しなので、MSに限らずまだしばらく
の間は対応が進む事は無いと思われ。

>>90
WinXP は NT 系だから対応が進まないということはないと思われ

おい！
恵比寿を忘れんな！

>>92
恵比寿ってなに?

>93
ビール工場しかない東京の街

>>91
> WinXP は NT 系だから対応が進まないということはないと思われ
社内のマシンはまだWin95ですが何か？

>>82
まったくだ。英語圏の人は、やっぱ漢字文化が分からないのかな？
Unicodeもまだまだ良くない感じです。

>>92
恵比須大工で統一するには、さらに困難を伴うと思われ

FreeBSDでSJISの入った/bin/shスクリプトを起動するとshがcoreはくのはなぜ？
回避策あるの？ sjisサポートshとか。

bashをスタティックリンクして/bin/shに仕立ててみるとか…

m17n/i18n/l10n 統合スレ@unix板はここですか？

このスレの1はMarkusだな?

>>101
ｲﾏｲﾁ｡
ﾏｲﾅｽ10ﾏｶｰｽ｡
(1ﾏｶｰｽ=10ｳﾞｫｲﾄﾞ)

>>100
> m17n/i18n/l10n 統合スレ@unix板はここですか？

プログラム技術版に作ったら？
WinやMacOS Xなんかも対象になった方が面白いし。

>>98
core 吐くのはバグに決まってるじゃん。send-pr すれ。

>>103
うーん、
今サラっと見てきたら類似スレは見当たらなかったし
作っちゃおうかなあ。

ワタクシ個人的はここで十分なんですが、、、

>>105

Unix i18n framework関連へのリンク(がいしゅつ以外)。
# あんまり大した物はない、スマソ。

1. 国際化ソフトウェア・プログラミング・ガイド (Compaq Tru64 Unix)
http://digital.compaq.co.jp/unix/docs/V40G/DOCS/HTML/I18NPROG/TITLE.HTM
http://digital.compaq.co.jp/unix/docs/V40G/DOCS/HTML/OS_LIB.HTM
# 無くなったと思ったらまだ有った(w

2. The Single UNIX(R) Specification, Version 2
http://www.opengroup.org/onlinepubs/7908799/xbd/locale.html
http://www.opengroup.org/onlinepubs/7908799/xcu/iconv.html
http://www.opengroup.org/onlinepubs/7908799/xcu/locale.html
http://www.opengroup.org/onlinepubs/7908799/xcu/localedef.html
http://www.opengroup.org/onlinepubs/7908799/xsh/iconv.h.html
http://www.opengroup.org/onlinepubs/7908799/xsh/langinfo.h.html
http://www.opengroup.org/onlinepubs/7908799/xsh/locale.h.html
http://www.opengroup.org/onlinepubs/7908799/xsh/nl_types.h.html
http://www.opengroup.org/onlinepubs/7908799/xsh/wchar.h.html
http://www.opengroup.org/onlinepubs/7908799/xsh/wctype.h.html

3. The FreeBSD C99 & POSIX Conformance Project
http://people.freebsd.org/~mike/c99/

4. C99の新機能 (参考)
ttp://seclan.dll.jp/c99d/

こんだけでは足りないだろうで、他の方々補足キボンヌ。

ちなみにム板だと

「おい、お前らUNICODEを絶滅させて下ちい。」
http://pc.2ch.net/test/read.cgi/tech/1012821170/l50
こんなレベルで終わってしまいそうで鬱。

つーか、linux板のEUC撲滅と、ここと上のリンク、
全部の1を集めて戦わせればいーんじゃネーノ?
# まさか全部同一人物?

>>107
確かに、ム板だとレベル低くなっちゃうかもね。

>>104
おお、そうなのか。
なんかポリシー持ってる人が持ち込んだ仕様だと思ってました。
　
バージョンが進むたびにcoreするスクリプトが多くなって困ってた。
しがらみでSJISしか食わないコンパイラ使ってるのでスクリプトがEUCだと
エディタやターミナルの切り替えが不便。

>>107
うーん
スレあったんですね。
なんか後半はカナモジカイ話になっちゃってどうかなあ(w
そもそもスレタイがなあ...ここもあっちもむこうも(w

>>108
ム板ってhaskellスレ以外見てないんですけど
レベル低いんですか？
ココより？(w

まあココが国際化に関しては一番被害者多そうだけど(w

>>106
Citrus Project
http://citrus.bsdclub.org/

li18nux
http://www.li18nux.org/
http://freestandards.org/

tronコードってどうなの？全世界の文字扱えるんでしょ？

>110
そりゃHaskellスレのレベルが高いだけ。

TRONとかiso2022なんかのモード切替でm17nを実現してるCESで、
collationはどういう扱い && どういう実装なんだろと疑問に思ったので
ちょっとgoogleしたけど驚くぐらい情報少なっ!
# しかも有効なページ見つかんなかった。

探し方悪かったかなぁ…

っていうか…LC_COLLATEて皆さん必要なんですか?(爆)

>>113
> (爆)
なんで爆発するんですか？(w

SJISみたいな腐ったフォント使ってる奴痛すぎなのですが…

>115
この板であんまり適当なことを書くと怒られちゃうよ。

>>116
115がイタすぎて起こる気すらおきないっつーか。

>>115
SJIS のフォントって何? 見せてみ。


とかね。

フォントのエリアス名にSJISってつけたら
SJISフォントのできあーがりっと

うお! googleってる間にすっかり糞スレに!!

もういっちょリンク
Unicode Collation Algorithm
http://www.unicode.org/unicode/reports/tr10/

>>113
言語によっては必要or有用そうな気がする。LC_COLLATE。

日本語は、、、読みがわからないと辞書順にならないからなあ(w

stateful encoding については、
とりあえず wchar に直す、でいいんじゃない？

Collationって符合化方式じゃなくて、文字集合の問題だよね。

>SJISみたいな腐ったフォント
フォントのインデックスがsjisだとか。

>とりあえず wchar に直す、でいいんじゃない？
WindozeXPでわ、wchar_tで、サロゲートをサポートするらしい。
つまり、stateful(ﾜﾗ

http://www.rimarts.com/ml/becky-ml/12500/12594.html
とか。

wcscoll(西夏文字, 亀甲獣骨文字)とした場合、
やっぱり文字が発明された順序で評価するべきなんですか(w

結局collationっていう概念自体がm17nとはそぐわない気がするんですよね。

まあCCS間で順位を決めちまうのは簡単なんですけど、
stateful encodingの場合ってcollationのコストって
かなりのシロモノだと思うんですが(汗

# なんか勘違いあったらもっとハードに叩いてください。

>122

日本語に限った話だと、collationって結局>121の仰る通り、
漢字の読みによって変化してしまうので、実装は事実上不可能なんで
符号化の順序=collationになってしまいますよね…

# 中国語だと今度は発音の違いもcollationの対象かぁ(w

>125
> # 中国語だと今度は発音の違いもcollationの対象かぁ(w

s/発音/アクセント/g でした(四声とかいう奴)。

>>124
発明された順番なんて関係ないでしょ。
どこかに発明順に文字を並べる文化があって、
そこの locale を使っているんでもないかぎり(w

一旦 wchar にしてしまえば、
stateful だから高コストということはないと思われます。

ごめん、、性格が柔和なので(w あんまりハードに叩けないや(w

>>125
画数順にするとか...(w

>>123
それは普通 stateful とは言わないのでは？

それはそうと
windows もサロゲートサポートするんだ...
てっきり 16bit only で押し通すのかと(w

# unicode も勉強しなきゃなあ..

>>129
顧客を抱えている企業なわけだから、Extension B に続々と
漢字が入りつつあるような昨今、今更 16 bit で押し通すな
んて無理なことでしょう。
押し通したら、喝采するけどな(W

wchar_tは16bitのまま、という意味では押し通してるけど。。。

imodeでSJISしか使えないぞです！
FOMAもSJISしか使えないぞです！
みんなでドコモごとSJISを撲滅してくれよです！
おいどんがドコモの社長になったら、全部EUCにするぞです！
社内文書もSJIS禁止だぞです！

>>132
SJIS だと何か困りますか?

http://choco.2ch.net/test/read.cgi/kao/1013358333/
こういうｽﾚが困ります

>>134
それは、SJISのせいではありません。

>>134
　おーい。そのスレ、SJIS で無い文字が大量に入ってるぞ(わら
　Unicode を実体参照でだしてあるんだよ。

>133に対して、SJISだと(ちゃんと表示されなくて)困る、って話だが

どーして符号化文字集合と文字エンコーディングスキームの
区別が出来ない奴がこうも多いの？

JISが悪い。
そしてASCIIが悪い。

ＵＮＩＸでもSJIS使えばいいのに。

>140
名言だ。伝説になるよ。

1バイト=32ビットにしる!

印刷屋はつらいよ。
とほほ。

ありゃ、やっぱちここで続けるにはタイトルが悪すぎるかも。
>138と>139に禿しく同意。

このスレとかEUCスレ、Unicodeスレの>1みたいな人は
内容が平易で判り易い本 && 簡単に手に入るので

「パソコンにおける日本語情報処理／文字コードハンドブック」川俣 晶
http://www.amazon.co.jp/exec/obidos/ASIN/4774107808/qid%3D1013925712/250-4670977-2788237

くらいまず読んでおいた方がいいと思う。

他には

「日本語情報処理」ケン ランディ
http://www.amazon.co.jp/exec/obidos/ASIN/4890527087/qid=1013925522/sr=1-1/ref=sr_1_0_1/250-4670977-2788237

が名著らしいけど、手に排卵。

あとはCマガのバックナンバーある人は
1999/6月号の第一特集「日本語処理」とか。

>132を好意的に受け止めてみると
i-modeの絵文字
http://www.nttdocomo.co.jp/i/tag/emoji/index.html
がJISX0213-2000で廃止された外字領域を侵略してることを非難してる?(w

あらら、あげちまった。

>127
ISO2022は文字集合を切り替えるが、言語を切り替えるわけじゃないからって
ことですよね。その前提に則れば、アラビア文字のcollationも、
言語が日本語なら日本語としてのcollationのruleを用意しなければならないけど、
実装を考えたらこれってアラビア語のcollation流用しますよね…普通。

うー、どうも勘違いしてるな、漏れ。

上の例でいうなら日本語のcollation databaseをlocaledefで生成するとき、
アラビア文字のcollation定義ファイルをincludeしても構わない、ってだけだ。

よって文字集合が切り替わってもcollate databaseを切替る必要は
全くといって無いわけだ。

すんまそん、逝ってきます。

まあ、日本(語)ロケールにおいてアラビア文字とサンスクリット混合テキストの
collation どーすんだ、データ用意するの面倒じゃ、というのは確かにあるかも。
使用頻度の高いところ以外は適当でもいいかなあって
個人的には思ってるんですが、ダメ？(w
solaris の utf なロケールではどうしてるのかしら。

>>146,147
どういう利用を想定している訳? 例えば、

英文字英単語すべて
アラビア文字アラブ系言語単語すべて
漢字平仮名日本語単語すべて

という順に並べるの?

それとも、カタカナ読みの順番に混在して並べる事を想定しているの?

TeXなんかだと後者は、indexed wordのsort keyに読みを記述するよね。
つまり、アプリケーションがcollationを直接扱っていて、
文字の層に任せるのは、「読み」に使う「仮名」のcollationだけ。

あ、前者の方も、localeで対応すべき事かしら?
計算機技術書だと、記号、英単語、日本語の順にindexを作成する事が多いけど、
文系書籍の場合、日本語、英単語の方が多い。
これも応用に依存すると思う。

文字のcollationとは別の話だと思う。

一言言っとくが、AIXのデフォルトの日本語コードはSJISだぞ！！

>>148-149
どういう利用かというと端的には sort(1) ですが。
% LC_ALL=ja_JP.UTF8 sort < 多言語テキスト
みたいな。

LC_COLLATE に限って言えば、文字列の順序づけの定義ということで
辞書順を想定してましたが、違うのかな。
辞書順というか、その locale で一般的な並べかた、かな？
ただ、ja locale でアラビックの一般的な並べかたなんてないので、
たとえば solaris ではどうしてるのかなあ、と思ったわけです。

sus とか読むかぎり、alphabet等の辞書順≒文字順な例ばっかりのようなので、
そうでない漢字等に関してちゃんとした定義があるのかちょっと疑問。
いいかげんな事ばっかり書いてスマソ。

応用によって並べかたが違うというのはその通りですが、
そんなこと言ってたらなにも定義できないのでは:-)
または各応用ごとに locale を用意する、という手もありますし。

>151

日本語だけ考えれば
　JISX4061-1996日本語文字列照合順番
ということなんでしょうかね。
# 中身は見た事無いので、他のJIS符号化文字集合との整合性は知りません。

(参考?)
ttp://www.asahi-net.or.jp/~ez3k-msym/comp/acccoll.htm

うーん、>149の仰るようにLC_COLLATEは
「文字」照合で、「文字列」照合ではないのかな?
確かにUnicodeのcollation
http://www.unicode.org/unicode/reports/tr10/
では全く意識してないっぽい。

LinuxのLC_COLLATEの実装もUnicodeのcollation依存のようです。
http://oss.software.ibm.com/developerworks/oss/locale/ReadMe.txt
「Collation table is generated from collation　key table
provide by Unicode org.」

# ますますこんな機能はアプリで用意せいとか思ったり。

>>152
>JISX4061-1996日本語文字列照合順番
ああ、こんなのあるんですね。サンクス。
とはいえ、金ないので読めませんが..(w

LC_COLLATE は
文字*列*照合でいいと思います。
すくなくとも、sus 的には。

>>152
># ますますこんな機能はアプリで用意せいとか思ったり。
どうやって？

すんまそん、平日は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

>>155
> と無制限に増えるのがぞっとするということですかね。
アプリでやっても無制限に増えると思いますが。
それも各アプリに(w

> こうなるとオーバースペックな気がするので
> 実用上問題ない「文字」照合でとどめる方がいいかなと。
文字照合にとどめたら無制限に増えなくなるかというと、
そんなことはないと思います。

> haractor and multi-charactorとあって、stringとは出て来ないんです。
string は一杯出てきますが..
sort-rules(order_start で指定するやつ) は string でないと意味ないですし。

しかし何だね。むつかしいコトはわかんねーけどsjis浸かってれば
幸せなんじゃねーの？
ウィソの存在はでかいし
SJISであんま困ったことねーな

たとえばsjisの「ソ」なんかは2バイト目がバックスラッシュと同じコードなんで、
バックスラッシュをエスケープするような厨房コードを書くと日本語通らんのよ。

nn

>>158
ソ−なんだぁ。

なんか犬産婆でそんな時の逃げパタン見た気がする
僕はコド書かないから気楽に生きてるよ
僕のがバクスラをプチ￥使うのもそんな感じなのか

>>157

SJISはもうお腹いっぱいです。
SJIS-JISX0213もかなり無理してます。

# 誰かxttをJISX0213対応させません?
# せっかく拡張渡辺明朝あるのに。



>>156

> それも各アプリに(w

再発明はこの世の常かと(w


> 文字照合にとどめたら無制限に増えなくなるかというと、
> そんなことはないと思います。

そうでした。「文字」照合であっても無制限に増えますね。
誤りでした。漢字一つとっても

ja_JP@全体の画数
ja_JP@偏とつくりの画数順

...無数にできるな。


結局LC_COLLATEは
・いかなるユーザ定義も想定しる。
・デフォルトの定義を用意すれ
ってことですかあ、大変だ。


> sort-rules(order_start で指定するやつ) は string でないと意味ないですし

ゲフ、もいっかいちゃんと読みに逝って来ます。


日本語ロケールでアラビア文字を扱う場合、
アラビア文字の照合順序を定義することは
mustではないような気がして来ました。
# 知らなきゃ無視すりゃいいだけのような。
# でもEINVALなげていいのか?

どうですかね...



リンク忘れ。

UI-OSF 日本語環境実装規約
ttp://www.li18nx.org/~numa/uocjle-a4.pdf

locale databaseのサンプル
ttp://www.li18nx.org/~numa/ja_JP.tar.gz

>>158
それは SJIS が..というより厨房コードを直すべきでは..(w
# samba みたいなアプリでは、しかたないところもありますが...

まあ、厨房プログラマにも自動的or簡単に正しいコードが書けるように
なったらそれはそれで素晴らしいですが。(java ？)
wchar じゃダメかなあ...ダメだろなあ(w

>>161
> # 知らなきゃ無視すりゃいいだけのような。
無視というか、
定義にない文字は UNDEFINED symbol の重みにするように
どっかに書いてあったような。たぶん。

（ ﾟДﾟ)＜ボクメーツ

いまごろ気付いたけど
>>162 は 10 ではなくて 100 です。スマソ。>10

SJISよりUTF8のほうが便利なのにどうして使わないの？

>>162
厨房コードというより、外国のコードに多いよ。

>>165
文字数少ないから。

>>166
まあ、
どっちにしろ SJIS が悪いわけではないよね。

i-Mode用コンテンツ作るのにShift-JIS強要がいやん。

ＵＮＩＸ側がSJISに会わせよう

やだ

NEWS-OS も 日本語 HP-UX も SJIS デフォじゃなかったっけ？
昔の国産 Unix はそういうのが多かったと思うけど。

あくまでも、「昔の国産」ね。オルタナティブがある今は考えが
別になってもおかしくないでしょ。

>>168
> まあ、
> どっちにしろ SJIS が悪いわけではないよね。

SJISも悪いんじゃないの。Codingの面倒さだけ言えば、
EUC-JP > Shift_JIS >> ISO-2022-JP でしょ。

>>172
> 昔の国産 Unix はそういうのが多かったと思うけど。

ΣはEUC-JPでしたが…

あ、東芝のSun3の日本語化もEUC-JPでした。
名前はJOSだったかどうか…

だれかｇｃｃのＳＪＩＳパッチの情報教えて！！
他のベンダコンパイラと互換をとるのが面倒だから。
（ベンダコンパイラで日本語オプションを外せばよいのは分かってるけど）

>177
LANG=ja_JP.SJISで良かったりしない？

>>177
使うlibraryもShift_JISを理解する必要があることは理解しますか?
e.g. printf().

>178
リテラルで「表」とかってコーディングする時、ｇｃｃだとエスケープが
必要だけど、ベンダコンパイラにはオプション指定でエスケープを不要に
できるものがあるでしょう？
＞179
セットロケールの動作の話してんの？

gccでもgcc3系はLANG見てsjisもエスケープ無しでコンパイルできるとか
どっかで見たような...
手元に環境無いから確認できんけど。

>>174
悪いのは SJIS や ISO2022 ではなくフレームワークの不在。

LC_CTYPE じゃ全然不十分だし。
filter アプリなら間に合うのかもしれないが..。

eucJP なら厨房コードでも OK かというと、
そうは思わない。まあ SJIS よりは実用上マシな場合も多いのも
確かだが、そういうエンコード依存はそろそろやめにしたい。
CSIマンセー。

フレームワーク…。X11R5 の Xwc…。

Xutf...(w

で、JIS X 0213で追加された文字はいつUnicodeに入るの?

>>180
>>178が言っているのはコンパイルが通っても
関数で対応してないときちんと処理されるかどうか
わかんないよって言う意味でしょ。
たぶん。

>>185
もう入ってるよ。
http://www.unicode.org/unicode/reports/tr28

age

半角カナの使えるロケール定義ファイルはないものだろうか?

Linuxでね、半角カナ使いたいんだけどさ。

ロケールつってもいろいろあるが。。。
半角カナ使いたいってのもどこでつかうのか意味不明。

>>189
jp_JP.eucJPで何の問題もないと思うが。

/usr/share/i18n/charmaps/EUC-JP.gz これじゃ不満なの?

　　　　　　 ／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣＼
Λ＿Λ　　|　君さぁ　こんなスレッド立てるから　　　　　　　　 　|
（　´∀｀）＜　厨房って言われちゃうんだよ　　　　　　　　　 　 　|
（ ΛΛ つ ＞―――――――――――――――――――‐＜
　( ﾟДﾟ) ＜　おまえのことを必要としてる奴なんて　　 　　　　　 |
　/つつ　　|　いないんだからさっさと回線切って首吊れ　　　 　|
　　　　　　 ＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿_／

(-＿-)　ﾊﾔｸｼﾝﾃﾞﾈ… (-＿-)　ﾊﾔｸｼﾝﾃﾞﾈ… (-＿-)　ﾊﾔｸｼﾝﾃﾞﾈ…
(∩∩) (∩∩) (∩∩)

(-＿-)　ﾊﾔｸｼﾝﾃﾞﾈ… (-＿-)　ﾊﾔｸｼﾝﾃﾞﾈ… (-＿-)　ﾊﾔｸｼﾝﾃﾞﾈ…
(∩∩) (∩∩) (∩∩)

(-＿-)　ﾊﾔｸｼﾝﾃﾞﾈ… (-＿-)　ﾊﾔｸｼﾝﾃﾞﾈ… (-＿-)　ﾊﾔｸｼﾝﾃﾞﾈ…
(∩∩) (∩∩) (∩∩)

文字コードの話してるのに、どうして(いわゆる)半角カタカナや全角英数使ってるバカがいるんだろうか。

＞＞１９４
ｳﾙｾｰﾊﾞｶ！

お前ら、自分で自分の首絞めてる印象。

>>195
使うなよボケ

http://freeweb2.kakiko.com/dengeki/indexe.htm

唐突だけど、、Emacs(MULE)のエンコーディングの処理は優れてると思いませんか？
たぶんunicodeみたいなcoded character setの統一は不可能だと思う。
で、多種多様な文字を扱うにはemacs muleみたいな内部コードを作るしかないかと。
これだったら臨機応変にcoded character setを増やしたり減らしたりできる。

>>199
http://savannah.gnu.org/cgi-bin/viewcvs/emacs/emacs/etc/NEWS?rev=1.613.2.1

要するに内部コード方式が維持されればいいと思うわけで。
でもunicodeに影響され過ぎてると思うけどなぁ。
utf-8-emacs is backwards compatible with the UTF-8 encoding of Unicode.
とか

ps. トンパ文字とかその他まだsetされてない文字はどうするわけ？増やした
い文字なんて無尽蔵に増えるだろうに。

あ、後方互換性だから関係ないか。

>>200 は結局なにを言いたかったのかな？内部コードがunicodeのサブセットになるわけじゃない。
答えてくれ。

>>194 どうして使っちゃいけないの？

トンパ文字を使う民族がPC使うかが問題やな
いくつ種類あるんだYO!

>>206
日本にルーズソックスを履いて棲息しているという噂を耳にしたことが
あります。

>>205
全角の「?」使うなよ...

JIS X 0208 読んだこと無いのか?
はっきり「使うな」って書いてある。

>>205 そうなんだ？ 知らなかったよ。

s/205/208

>>209 >>210

> そうなんだ？ 知らなかったよ。
面白くないよ。

> s/205/208
一文字足りないのでは?

>>200
utf-8-emacsか。-emacsを付けるところはやっぱり偉いね。

>>204
書いてない事を憶測されても困るんですが、、、
単にFYIでリンクを貼っただけで、何らかの主張があるならそれも書きますってば。

現状で問題なし。っていう人がマジョリティでしょ。

>>211
最近 sed 使ってないから忘れてたよ。vim だとそれでオツケイなんだけどね。

結局 Han unification の問題はどうなったんですか?
日本と中国の漢字を違う glyph で表示できるんでしょうか.

>>200
utf-8-emacs が内部的に使われるとなると,
iso2022 で実現できていた multi encoding 環境は
どうなるんですかね. 従来のも使えると書いてあるから
かわらないのかな.

どれでもいいから一つにしてくれ・・・

（＾＾）

「Shit JIS」でググると結構な数ヒットするんですが、
みなさん、故意に書いてるんですかね?

DoCoMo 用の CGI のコメントに故意に書いたことならあります。

（＾＾）

半角カナのないコードは糞!

とりあえず、2ch見ているうちは半カナは必須かな？と言ってみる。

>>222
半角ｶﾅのないコードってあるの？

jis ってあったっけ?
そういえば unicode はどうなの?

>>225
ISO-2022-JP も EUC-JP も Unicode も半角ｶﾅあると思うんだけど？

それはねこみみです

>>226 では ISO-2022-JP で「半角カナ」を使う方法を教えてください。

>>228
カナの幅が高さの半分くらいのフォントを使う。

はい次。

>>228
すいません、勘違いをしておりました。
JIS で定義されてる ESC ( I は、ISO-2022-JP (RFC1468) には無いのでつね。

>>228
http://www2d.biglobe.ne.jp/~msyk/charcode/jisx0201kana/

ＩＳＯ−２０２２−ＪＰ 【通信用語:情報符号編】
[アイエスオウにーまるにーにージェイピー] (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
─────────────────────────────────

jis もいっぱいあって、わかんないよ!!!

ネジの規格もJISだしね!!!

iso2022 の G0 とか G1 とか GR とか GL とか、
わけわかんない概念はどっからきたの?

フォントロード可能な文字端末

別にわけわかんないことはないでしょ?
ただ今となっては一段間接が余分だね。

あ、フォントロード可能なプリンタもね。

（＾＾）

あぼーん

お前ら、新しいエサですよ。

Unicode 4.0 Released!
http://www.unicode.org/versions/Unicode4.0.0/

あぼーん

変なのが食いついてるよ。

あぼーん

I hate UNICODE :-)

unicodeで表示できてJIS系で表示できない漢字はなにがありますか？

JIS X 0221:2001はExtension Bが未収録(Unicode 3.2未対応)なので、
ざっと45,000字ぐらいは表示どころか扱うこともできねい筈だす

>>246
とりあえずマルチポストいくない。
必要なければ UTF-8 にする事はお勧めしない。

>>246
表示つーのがもうどう答えていいもんだか分からないけど、
JISで定義されてない漢字はJIS系では扱えないだろ。大陸の奴とか。

>>247
それ、JIS X 0221:2001で扱えるけど、Unicodeだと扱えない漢字(だけじゃないけど)じゃん。
丸つき数字なんかは永久に入らないんだろうな。
第3,4水準南無〜

Unicode って字を組み合わせる規格なかったっけ?
〇と 1 とか。

あるけどさ。
口{〇, 1} こんな感じで三文字に。(丸付き一)
口{〇, ‖{3, 4}} こんな感じで四文字に。(丸付き三十四)
こういうので済むなら、丸つき数字を文字集合に含める必要ないしな。
白抜きがどうにもならんし。

あぼーん

あぼーん

へーこんな仕組みできたなんて知らなかった。
管直人もいろいろ工夫してるもんだね。なにが条件になってるんだろう？

あぼーん

SJISよりも関西弁を撲滅してください

>>256
なんでやねん?

あぼーん

あぼーん

>>254
山崎渉って From に書くと fushianasan になるんじゃなかったっけ？

www.cbook24.com/bm_detail.asp?sku=4901676156

SJISはいいけどCP932を撲滅しる。

互換性がなくなるから無理

つーかCP932が非互換の元凶。

うにコードだって、別にUTF-8だけじゃないしなぁ・・・









いわゆる駄スレってこれのことか？

UCS-4 で満足だとでも？

ゼロから作りなおさないかぎり Unicode はすべてクソ。

>>267
ゼロは無だと思うから「作りなおす」ことはできない
ゼロから作りあげるが適切

UnicodeはBOMがウザい。誰だよあんな余計なもの考えた奴は。

まぁ、実際は文字コード以上に改行コードの違いがウザい訳だが。

http://www.alanwood.net/

どれでもいいからひとつにしてくれ・・・マジで

>>232
> http://www2d.biglobe.ne.jp/~msyk/charcode/jisx0201kana/

そのWebサイトに書いてあることは嘘があったり重要なことが抜けてたりするので
あまり参考にしない方がいい。

たいていの場合、JIS X 0201の片仮名用図形文字集合(いわゆる半角カタカナ)は
使ってはいけない。ISO-2022(例外あり)もISO-2022-JPもShift JISもEUC-JPも
UTF-8もUTF-16も。
同様にJIS X 0208の一部の文字(いわゆる全角英数)も使ってはいけない。
「?」や「/」のJIS X 0208の方もダメ。

UTF-8撲滅sage

>>272
で、使ってはいけない理由を言おうとはしないわけですね。

>>272
> そのWebサイトに書いてあることは嘘があったり重要なことが抜けてたりするので
たとえばどの辺ですか?

「半角片仮名」という言葉が間違いで「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には片仮名はありますよ」と答えるほかない。
(意地悪な答えだけど)

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」です。つまり半角と全角の二つの文
字があるのではなく、「ア」という文字があってそれが二つの集合に存在するわ
けです。続きを読みます。

・一意の符号化表現が要求された場合は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 片仮名の割り当ては削除の予定だそうです。

例外として、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.
まずい方の文字は使うな、ということです。ただし全角・半角は別物として扱う
ようです。

>>272
> UTF-8もUTF-16も。

こりゃ言い過ぎだ。

>>276-279
理想論をただ書き連ねただけのオナニーだな。

実際のアプリケーションでは、過去の文書データと
一切関わりなく使用されるようなことはまずない。
「過去との互換性が要求されるとき以外は使うな」というのは
文字コードの世界ではほとんど意味のない制限だ。
UnicodeもCP932も、いわゆる「半角ｶﾅ」も「機種依存文字」も
既に存在しているものであり、技術者の一方的な都合で
「なかったこと」にすることはできない。

>>281

> UnicodeもCP932も、いわゆる「半角*ｶﾅ*」も「機種依存文字」も

今あなたが書いたのは「新規」のものだろう。
どこに必要性があるんだ。使うなよ。

>>282
いやあ、ｽﾏﾝｽﾏﾝ。
本当は「オナニー」の部分も半角ｶﾅで書くつもりだったんだけどね。

「文字コード」ってのは、コミュニケーションの手段である文章を
どうやってデジタルデータに落とすかって話の一部でしかなく、
規格書に記述されていることが全てではない。

半角カナを使って煽りの気持ちを表現したり、
Ascii artのように文字のグリフだけに意味を持たせたりと、
そういう規格書では定義されていない「文化」が
既にあちこちで使われている。

そういう背景を無視して、機械的に「半角カナ→全角カナ」のような
フィルタをかけ、(行間じゃなく)文字コードの間に込められた意味を
消してしまうのは、技術者のエゴじゃないかなと漏れは思うわけよ。

>>283

そういうのは上のレイヤーでやるべきことで、文字自身にもたせるものではないんです。
所詮、フォントを変えただけで消し飛ぶようなものですから。

>>284
> そういうのは上のレイヤーでやるべきことで、文字自身にもたせるものではないんです。
> 所詮、フォントを変えただけで消し飛ぶようなものですから。

もちろん漏れも技術者のはしくれなんで、そういう「理想論」は理解できる。
# つーか、仕事でも文字コード関連の問題には何度もぶち当たっているし。

ただ、そういう事情を理解した上で、
「結局、『理想論』は理想論でしかない。」
と言いたいわけよ。

>>285

> # つーか、仕事でも文字コード関連の問題には何度もぶち当たっているし。

ぶつかるだけなら日本語を含むHTMLを書くだけでもぶつかります。
JISは読みましたか?

> ただ、そういう事情を理解した上で、

全然理解してないですね。

> いやあ、ｽﾏﾝｽﾏﾝ。
> 本当は「オナニー」の部分も半角ｶﾅで書くつもりだったんだけどね。

こんなことを書く程度ですし。

手書きでも半角カタカナとか全角英数字を浸透させちゃえばいいんだよ。

四半角仮名や四倍角英数字が Unicode に入るのはいつですか?

>>286
かっかし過ぎ。

>>289
かっかしてるわけじゃなくてね、>>281 程度の認識しか持たない人が
しばしば愚かなことを書くからガッカリしてるの。>>281 程度の話は、
今まで数え切れないほど行われてきた。>>276-279 を読めば、こちらが
もっと上のレベルの話をしたいってことは分かると思うんだけどね……

本当は >>276 の人と意見を交換したくて、がんばって長文を書いたんだけど
出てこないかなぁ。

>>290
> もっと上のレベルの
レイヤは上かもしれないが
レベルは上じゃねーよ。
過去の実装を無視して規格だけこねくりまわしても無意味。

>>291
そういうのは規格を読んでから言ってね。

> そういうのは規格を読んでから言ってね。
こんなことを書くと、またアホが「規格規格とうるさい原理主義者」とか言いかねないので
補足しておく。まともな技術者なら、なにかを実装したりする場合一次情報にあたるのは
当然のことなんだ。たとえばHTMLを扱うならW3Cの勧告を読むのは当然だし、もしかすると
HTTPのRFCを読まないといけないかもしれない。
こちらが言っているのは、「規格は至上のものである」ということじゃなくて、日本語の処理を
するなら、読んで当然だってことなんだ。

厨な質問ですいませんが、たとえば、２ちゃんねるなんかは、
「半角ｶﾅ」と「全角カタカナ」の使い分けが当然のように行われているわけですが、
これは「過去との互換性が要求されるとき」に合致するのではないの？

「だけ」と書いたのが読めんのか。

>>295
だから、規格さえ読んでない人は論外なんだって。

>>286
> > # つーか、仕事でも文字コード関連の問題には何度もぶち当たっているし。
> ぶつかるだけなら日本語を含むHTMLを書くだけでもぶつかります。
> JISは読みましたか?
当然読んでいる。
技術者として、JISやW3Cなどの規格を読むのが
最低限必要なことなのは言われなくてもわかっている。

おそらく、>>286はHTML3.2などで(規格に厳密に従った場合)
日本語を使用することができないってことなどを言いたいんだと思うが、
そういう国際化の規格が決まる前から多くの実装で
日本語を含むHTMLを扱うことができていた。

規格ってのは、その実装ができる前から(もしくはリファレンス実装の作成と並行して)
作られるものもあるが、現状の実装を後追いする形で決まるものも多い。
そのような実装の後追いで決まった規格を使う場合は、
過去の実装や慣例についても十分考慮する必要がある。

特に文字コードのように、「非技術者」に対する影響も非常に大きい分野では、
「規格で推奨されていないから」という理由だけで
過去の慣例を排除するのは、現状を見ていない技術者のエゴでしかない。
# 完全に技術的分野で閉じた話なら構わんと思うがね。

> > いやあ、ｽﾏﾝｽﾏﾝ。
> > 本当は「オナニー」の部分も半角ｶﾅで書くつもりだったんだけどね。
> こんなことを書く程度ですし。
じゃあ、>>281のはじめの一文は
「<煽り>理想論をただ書き連ねただけのオナニーだな。</煽り>」
とでも書くべきだったのか?
俺は「2chでの慣習」に従った書き方をしているだけだ。

>>297
> そのような実装の後追いで決まった規格を使う場合は、
> 過去の実装や慣例についても十分考慮する必要がある。

はい、そのとおりです。
しかしながらまだその先があります。
たとえば既存の実装が規格とずれていた場合、次の改訂の際に規格に合わせてく
る可能性があるわけです。改訂版では過去との互換性があるとは限りません。
また未知・未来の実装は、基本的に規格どおりに実装する可能性が高いでしょう。
このとき、自分が確認して合わせた実装との互換性をとってくれるとは限りません。
ようするに過去の実装より、規格の方を重視すべきなのです。
もちろんこれは原則にすぎず、他のシステムとやりとりである以上、可能な限り
データ交換可能なものにするべきです。

つまり、「規格より過去の実装の方が重要」という点が間違っているということ
です。規格の重みづけをする場合、過去の実装以外にも考慮しなければいけない
要素がある、ということ。

> 「<煽り>理想論をただ書き連ねただけのオナニーだな。</煽り>」
> とでも書くべきだったのか?

「煽り」とか書いてる時点で人間的にどうかと思います。
それは置いておくとしても、

> 俺は「2chでの慣習」に従った書き方をしているだけだ。

これはただの責任転嫁ですよ。

>>298
> たとえば既存の実装が規格とずれていた場合、次の改訂の際に規格に合わせてく
> る可能性があるわけです。改訂版では過去との互換性があるとは限りません。
> また未知・未来の実装は、基本的に規格どおりに実装する可能性が高いでしょう。
> このとき、自分が確認して合わせた実装との互換性をとってくれるとは限りません。
> ようするに過去の実装より、規格の方を重視すべきなのです。

それが現実を見ていない理想論に過ぎないと言いたいわけ。
GNU libiconvにcp932パッチがあるのは何故だ?
過去の実装や慣習を無視して新たな規格や実装を作っても、
それは新たな混乱を招くだけ。

>>299

ちゃんと >>298 を読みましたか?
あなたは「過去の実装」だけしか考えていないので、規格の重みづけが
低すぎるといっているのです。「過去の実装との互換性」以外にも、規格
の重みづけの要素はあるんだよ、と。

> GNU libiconvにcp932パッチがあるのは何故だ?

Microsoftが他者(他社・Unicodeコンソーシアム)と協調してShift JISの
マッピングテーブルを決めるべきところを、無視して独自に実装したためです。
Microsoftのテーブルは個人的には現実的だと思っていますが、まさに

> 過去の実装や慣習を無視して新たな規格や実装を作っても、
> それは新たな混乱を招くだけ。

こういうことです。

そういえば、どっかの携帯会社が規格の予約領域を勝手に使っていましたね。

で、何番の発言が AoiMoe なの?

>>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パッチを当てて使っている。

規格至上主義に走り過ぎると、かえってユーザの利便性が
損なわれることがあるって例のつもりだったんだけどね。

>>302
少なくとも俺は違うぞ。(w

>>303
> 確かに>>300の言う通り、cp932のマッピングテーブルはMicrosoftが
> 勝手に決めてしまったもの。そのためGNU libiconv本家は
> cp932パッチの統合をかたくなに拒んでいる。

少し前に、libiconvのCVSの方に入ってます。

>>305
> 少し前に、libiconvのCVSの方に入ってます。

おお、それは良かった。
1.9.1にも入らなかったから、もうダメかなとあきらめていたんだけど。

パッチのマージに尽力された方々にこの場を借りてお礼を申し上げます。

>>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)どおりの愚かな展開(平行線)になってしまった。
規格自身について話を振っているのに、「規格なんて二の次だ」なんて的はずれな
返事を返すなんて……。もうちょっと認識のある人の意見を望みます。

>>281
> 技術者の一方的な都合で「なかったこと」にすることはできない。

日本文藝家協会の方ですか?

>>307
> 返事を返すなんて……。もうちょっと認識のある人の意見を望みます。
気持ちはわかるが、そういう書き方をするから不毛なやり合いになる。

>たとえば既存の実装が規格とずれていた場合、次の改訂の際に規格に合わせてく
>る可能性があるわけです。改訂版では過去との互換性があるとは限りません。

日本で作られたソフトは、まず無いと思う。
今までそれが行われていれば、今のような状況とは違ったと思うが。

もっとも、JIS X 0208:1983 やら、うにコードのように、
規格自体が腐ってる事が多い

＞＞307 あなたのような適当な考えによる実装が、今の混乱を引き起こしているのです。
どのような考えによる、どのような実装が、規格にもなるべく沿いつつ現実的である事ができるでしょうか。

今まで 272 さんは「規格の話をしている」と仰ってました。その通り、276-279 は規格では
否定しているという話にすぎない訳です。（その後は主観の争いになってますが…）
JISは中国のGB18030とは違い、何の強制力もありません。「いけません」と言ったところで、
結局はどこかに落ち着かなければ使い物にならないのが現実ですよね。

>>311
とはいっても、>>307が言うように、
fullwidth/halfwidthは過去のものにすべく努力していくべきだろ?

フグ/ハリセン本について

CJKV日中韓越情報処理
Ken Lunde著
2002年12月発行 12,800円
http://www.oreilly.co.jp/BOOK/cjkv/

Data Table & Sample Code
http://examples.oreilly.com/cjkvinfo/

Ken Lunde's Home Page
http://www.praxagora.com/lunde/

>>311
> 今まで 272 さんは「規格の話をしている」と仰ってました。その通り、276-279 は規格では
> 否定しているという話にすぎない訳です。

そ、それで終わりですか?
あの話は掘り下げるところがまだまだあると思うのですが……

> （その後は主観の争いになってますが…）

人の意見・主調なんてすべて主観です。問題はその妥当性。

> どのような考えによる、どのような実装が、規格にもなるべく沿いつつ現実的である事が
> できるでしょうか。

普通、実装をするまえに規格を洗って、それを整理しますよね。
それをおざなりにして、いきなり実装をしてもまともなものは出来ないでしょう。
過去の実装との互換性があればいい、という適当な考えならいざしらず。

> JISは中国のGB18030とは違い、何の強制力もありません。

強制力とかそんなのはどうでもよくて、使うべきではない文字は使うべきではないのです。
例えばある通信プロトコルで、RFC違反のデータを送受信することは簡単です。互換性
などの理由で、やらざるをえないこともあるでしょう。しかしそれは基本的には「やるべきで
はない」のです。理由は分かりますよね?

>>314
>強制力とかそんなのはどうでもよくて、使うべきではない文字は使うべきではないのです。

「使うべきではない文字」ってのを誰がどうやって決めるかっていうと、それは
情報の送り手と受け手、両者の合意によるわけだ。
「規格」というのも結局、すべての二者関係毎に個別に合意を取り付ける
手間を省くためのものだし。

通信かよ!?

通信だよ

問題は、技術者だけではなく、ソフトウェアの顧客がそのことを理解して、
いわゆる半角カナを JIS X 0208コードに修正する費用と時間を出してくれるかということもある。

いまだにJEFつかってる銀行なんか多いくらいなので、、、

やっぱ変更せずに走らせるケースが多いのでは？

> 嘘があったり
「使うべきでない」を「使ってはいけない」と表現したり
まさかMUSTとSHOULDの区別も付かないわけじゃないですよね
> 重要なことが抜けてたりするので
「過去との互換を目的として」とかの例外事項を無視して
「使ってはいけない」としか書かなかったり
しかも知ってて抜かすんだからより悪質ですね

文字コードが通信が終わったら端から消えていくなら
実装を変えればそれで終わりだろうけど実際には
データとしてどんどん蓄積されていくから途中で変えて
はいおしまい、過去のデータは全部捨ててください
なんて簡単に言えるわけない。

そういえば>>232の何が結局「嘘」なのかも説明してませんね。

> 「規格」というのも結局、すべての二者関係毎に個別に合意を取り付ける
> 手間を省くためのものだし。

はい、そのとおりです。

> 問題は、技術者だけではなく、ソフトウェアの顧客がそのことを理解して、
> いわゆる半角カナを JIS X 0208コードに修正する費用と時間を出してくれるかということもある。

実装の話が好きですね……。
さかのぼって修正する必要はないんでは? そのために「過去との互換性」うんぬんの
くだりがあるわけだし。したいのなら止めませんが。

> 「使うべきでない」を「使ってはいけない」と表現したり
> まさかMUSTとSHOULDの区別も付かないわけじゃないですよね

「使うべきではない」ものを、相当の理由なく使おうとしている場合、
「使ってはいけない」と伝えても問題ないでしょう。

> 「過去との互換を目的として」とかの例外事項を無視して
> 「使ってはいけない」としか書かなかったり
> しかも知ってて抜かすんだからより悪質ですね

また低レベルな、平行線の話を繰り返したいのですね。

> はいおしまい、過去のデータは全部捨ててください
> なんて簡単に言えるわけない。

どうして捨てる必要があるのでしょうか?
新規で使わなければいいだけなのに。

> そういえば>>232の何が結局「嘘」なのかも説明してませんね。

>>277-279 を読みましたか? 読んでも分かりませんか?
そこに含めてあるんですが……

>>324
> 新規で使わなければいいだけなのに。
"今まで使えてただろ！ どうにかしろ ！"

> "今まで使えてただろ！ どうにかしろ ！"

そんな人いますか?

とりあえず、既存の規格を無視するやつをなんとかしろよ。
docomo とか。

わざと無死してるわけですが

>>326
います

> 「使うべきではない」ものを、相当の理由なく使おうとしている場合、
誰がそんなことしてるんですか?

> また低レベルな、平行線の話を繰り返したいのですね。
そもそも>>272が低レベルな煽りから始まっているのです。
そういうのを自業自得といいます。

> どうして捨てる必要があるのでしょうか?
新しい実装で読めないからです。

> さかのぼって修正する必要はないんでは? そのために「過去との互換性」うんぬんの
> くだりがあるわけだし。
それこそがまさに「相当の理由」でしょうが。

> >>277-279 を読みましたか? 読んでも分かりませんか?
> そこに含めてあるんですが……
順番に検証してみようか。
>>276
リンク先のどこにも「JIS X 0201のカタカナ」が特殊なカタカナだ
なんて一言も書いてない。自分以外の愚民は使うべきでないものを
使いたくて使いたくてたまらないから「JIS X 0201のカタカナ」と
書かれていたらそれは即特殊な意味を持たせていてそれ以外の
解釈はありえないとか妄想したけりゃしてもいいけど。

> ISO-2022-JPで
リンク先は「ISO-2022-JPで」使うなんて話はしていない。
7bit-JISの話なら出てくるけど。
> EUC-JP
> Shift JIS
そもそも「使ってはいけない」が嘘だから論外

> Unicodeの場合:
リンク先にはUnicodeの話などまったく出てこないが。
そもそもJIS X 0201の話をしてるのにUnicodeが出てくること自体
ヘンだとお前さんが自分で言ってるだろ。
> 勘違いの典型は、「UnicodeでJIS X 0201の片仮名は使えますか?」などと
> いう質問で、

総論:
リンク先とは無関係な、誰に言ってるのかも不明な論を
一方的にまくし立ててるだけ。
> ６：一見関係ありそうで関係ない話を始める

で、どこが嘘なの?

> 広まってませんよ。WindowsのMS UI Gothicを使ったことはありますか?
> そんな期待はフォントが違うだけで無意味になる程度のものです。

区別しない実装が存在することは区別しない慣習が存在することの
否定にはならない。単に区別しない場合もあれば(規格上区別する
理由はないんだから当然だが)慣習上区別する場合もあるという
だけのこと。

だいたい使い分ける慣習が本当に存在しないならあんたの
大好きな規格書はありもしない慣習との互換性に配慮するために
わざわざページを割いてるの?

こんな初歩的な詭弁にすらツッコミが入らないようじゃ
確かにレベル低いかもね

> 区別しない実装が存在することは区別しない慣習が存在することの
訂正
区別しない実装が存在することは区別する慣習が存在することの

とりあえず引用トークはムカつくっつーことだけは
よ〜くわかった。

>>337
> とりあえず引用トークはムカつくっつーことだけは
fjを思い浮かべるからかな。


などと引用してみるテスト。

>> また低レベルな、平行線の話を繰り返したいのですね。
>そもそも>>272が低レベルな煽りから始まっているのです。
> そういうのを自業自得といいます。

責任転嫁をしないように。
低レベルな話を持ち込んだのは、あなた自身の責任です。

さて、>>330-336 には、簡単に分かる間違いがいくつかあります。

・認識不足による誤解・間違いが4つ
・引用部分とは関連のない話を持ち出して、返答しているのが1つ

それぞれどこでしょう。
>>330-336 の人は分からないでしょうから、他の方で結構です。
考えてみてください。

それから、>>330-336 を書いた人への課題も出しておきます。

>> ISO-2022-JPで
> リンク先は「ISO-2022-JPで」使うなんて話はしていない。
> 7bit-JISの話なら出てくるけど。

「7bit-JIS」とは?

間違い探しクイズなんてしてないでハッキリ言う方が良いのでは？
と傍観者は思うのでした。

死めよ。おぬーら。

>>340

論理的思考が出来ない人間とのメタ議論は、しばしば発散するからです。

>>341
はっきり言いすぎですYO!

すんません! この系統に関してはドシロウトなんですが...
o コードセットとグリフの関係とか
o ウニコードとステートフル(ってゆうのか?)なコード体系の関係
とか
に関して, そこそこまとまった資料って, どこ参照すればええんで
すか?
# グリフの合理的指定方法があれば何とかなるもんちゃうの???

>>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氏はネタのつもりだったのでは。

質問
jisx0213の文字って全部unicodeに反映されたの?

されてない

>>347
どの程度反映されてるんでせうか?それともまったく?

補助漢字にある奴は全部あるでしょ。
丸付き数字のような合成文字系は全部拒絶されてんじゃない?

丸付き数字系は全て追加されました。

>>349-350
つーことは一部を覗いてほとんど入れられてるって事ですか。
ありがとうございました。

sage忘れた…すいません。

確か追加されてないのはひらがなとアクセント付きの発音記号だけだったと思う。

Unicodeでの外字の扱いってどうなってんの?
使えんの？

PUAでいいんじゃね？

>>353
ひらがなってのは、'ん'+'゛'みたいなやつのこと?

>>353
Unicode側の言い分では「全部入れた」ことになっているんだろうけどね。
「合成で済むだろゴルァ」って感じで。

結局混乱を増しただけだと思うんだけどなー。
あぁ、日本以外じゃ困らんから、テキトーな国際化には役に立っとるんか。

http://pc2.2ch.net/test/read.cgi/software/1044162360/
>>874
格納がしっかりしてれば文字コードが必ずSJISになり
どの文字コードで格納するか調べる必要も無いでしょう。

>>875
予想だろうがそれが根拠で問題だと『俺は』思う。
俺の思う理由を聞いておいてそれは無いだろう。

>>876
その必要が有る人のみ守ってるだけでは？
普通は日本語使わないけどね。

>>877
殆どはASCIIで書かれてるからな。ASCIIはSJISで無いぞ。
稀に見かける日本語を使った書庫ではeucを使ってる。
でもSJISを使ってるのは見たこと無いとも書いたが。

>>878
作者は仕様を守るべきなんじゃない？
それが出来ないなら作らなければ良いだけ。
仕様を制定するのが自分なら殆ど負担は無いだろう。

>UNIX上でも SJIS 使ったのしか見たこと無いね。
俺は無いな、少なくとも配布されてるものに関しては。

>仕様を制定したのと、UNIX版作ってる人は別人。
>同一人物でも仕様をコロコロ変えるのはどーかと思われ。
これは誤解を生んじゃったな。
lhaの事じゃなくソフトウェア作者の苦労の事を書いただけだから
その辺の事は分かってるし同意。

>仕様が無い場合という仮定の話なので文字コードは SJIS とは限らない。
格納をしっかりすれば仮定の話は何の意味も無い。

>それらの書庫はファイル名に関する仕様を守ってる。
日本語ファイル名を格納してる書庫の話でしょうが。
ASCIIファイル名は日本語扱うときはSJISでって仕様を満たしている訳じゃない。

>必要がある人は自力で実装すれば良い、
>という事のどこに問題があるのかサッパリわからん。
それじゃぁ自力で実装する力の無い人、そもそもそんな事考えて無い人が作った
書庫は不正書庫になってしまうじゃないか。
大抵の人はlhaにそんな仕様が有る事すら知らないだろう。
何べんも書くけど守られない仕様は仕様の機能を果たさない。
仕様がしっかり守られるならば解凍時の文字コードも気にしなくて良い。

>ファイル名に関する仕様が無い場合、
>UTF-8 でも SJIS でも EUC でも仕様的に問題なく「しっかり格納」できる。
lhaはSJISで格納すると言う仕様が有るんでしょ。勝手になくさないで。

>ファイル名に関する仕様は満たしてる。
日本語のファイル名の話をしてるんだから・・・。
関係ない話を持ち出さない。

>何べんも書くけど仕様は概ね守られてる。
>例えば、信号無視する人間が延べで 5%居た場合、信号は機能を果たしてないのか？

たとえ話は嫌いだが、、、この場合その5%は必ず事故るわけだから信号の機能を果たしてるとは言いがたい。

向こうで暴れてる困ったちゃんをどうにかしろよ

lhaの書庫はパス名にShift JISを使うって仕様だったのか。知らなかった。
どこに書いてあるんだろう。

>>365
ここで暴れてる困ったちゃんもどうにかしてください。

>>366
昔のlhaのドキュメント

>>368
Vectorにある吉崎氏の実行ファイルとソースのアーカイブ内には
そういう記述はみあたらなかった。
http://www.vector.co.jp/vpack/browse/person/an000224.html
「昔のlha」は持ってないしなぁ。

ただ、UTIL.Cにiskanji(c)というマクロがあって、それはShift JISを
想定しているっぽい。

#define iskanji(c) ((uchar)(c) >= 0x80 && (uchar)(c) <= 0x9f || \
(uchar)(c) >= 0xe0 && (uchar)(c) <= 0xfd)

>>369
lha for UNIXの方だったかもしれん。
だったらそんなに昔じゃないなｽﾏｿ

詳しくは知らんが、YosshiがSysopやってたflaboでは
過去ログ(LZHで固めた奴)にSJISファイル名使ってたような…

いや、当初はMS-DOSしかっていうか何も考えなくて生SJISにしたはずなんだけど、
どっかでそれを仕様として確定したと思うんだよ。
それがlha for UNIX以前か以後かがよー分からん。

よーわからんけどlha for UNIX以前か以後かって区分は重要なの？

>>372
> いや、当初はMS-DOSしかっていうか何も考えなくて生SJISにしたはずなんだけど、
だろうね。

> どっかでそれを仕様として確定したと思うんだよ。
これが、「誰が」「どこで」確定したのか情報希望。

よーわからんけど「誰が」はともかく「どこで」は重要なの？

　　　　　　　　　☆ ﾁﾝ　　　　　ﾏﾁｸﾀﾋﾞﾚﾀ〜
　　　　　　　　　　　　　　　　　　　　　　　　　ﾏﾁｸﾀﾋﾞﾚﾀ〜
　　　 　 　 ☆　ﾁﾝ　　〃　 ∧＿∧　　　／￣￣￣￣￣￣￣￣
　 　 　 　 　　ヽ　＿＿_＼（＼・∀・）　＜　　「誰が」「どこで」確定したのか情報まだ〜？
　　 　 　 　 　 　 ＼＿／⊂　⊂＿ )　　　＼＿＿＿＿＿＿＿＿
　　 　 　 　 　 ／￣￣￣￣￣￣ ／|
　　　　　　　　|￣￣￣￣￣￣￣|　 |
　　　　　　　　|　.愛媛みかん.　 |／

>>375
> よーわからんけど「誰が」はともかく「どこで」は重要なの？
必ずしも吉崎氏が策定する必要は無いんだよ。
仮に「LHA Open Group」でもいいわけだし。
そういう意味の「どこで」ってこと。

>>377
> 仮に「LHA Open Group」でもいいわけだし。
それは「誰が」だと思うんだが…
まぁどっちでも良いけど。

ところで「LHA Open Group」って実在する組織なん？

>>378
> ところで「LHA Open Group」って実在する組織なん？
いやー俺の脳内団体だよ。「誰が」だけだと「吉崎氏に決まってるだろ」と
なりかねないので書いたのだけれど、よけい混乱させちゃったみたいで
申し訳ない。

過去の経緯としてはShift JISが仕様だったのかもしれないが、
# 補助漢字や第三/四水準はどうなっているのだ?
それだとASCIIな人と日本語な人以外は困るから、
アーカイブ内のパス名はUTF-16で保存することにして、
システムごと、あるいはロケールごとに、iconvして展開するのがいいんじゃないの?
アーカイブ形式に形式のバージョンを持てないの?

大体、今やWindowsやMac OS Xだって、
UTF-8のパス名持てるんだから、Shift JISのままじゃ困るんじゃないの?

>>380
そこでなぜUTF-16。こういう場合はUTF-8だろう。

lhaは圧縮形式としてlh5, lh6, lh7などが選べたはず。
これが規定するレイヤーによっては、「lh8はUTF-8」という風にも
出来るだろうね。多分やらないだろうけど。

>>381
追記。なぜ「やらない」かというと、lhaは歴史的な経緯では小型の
システム(DOS)で使われてきたし、現在もそういう風に使われている
(マザーボードのBIOSとかね)。ここでUnicodeをサポートために巨大な
変換テーブルを持たせるのは、lhaの方向性にあわないだろう。
そういうのが必要なら、もっと富豪なアルゴリズムを持つ書庫の仕様に
含めればいいのだ。

>>380
> それだとASCIIな人と日本語な人以外は困るから、
日本人以外は使ってないので困らない。

> アーカイブ形式に形式のバージョンを持てないの?
持てません。

>>381
> これが規定するレイヤーによっては、「lh8はUTF-8」という風にも
面白いアイデアだと思うけど、
全く問題無しってわけにもいかないと思うよ。

例えば この新仕様に対応してないバージョンで、
書庫->書庫で圧縮されたファイルコピーする際に
SJIS(元書庫)->EUC(中間処理用)->SJIS(先書庫) みたいな変換
食らった場合、元書庫で UTF-8 使ってると化ける可能性がある。

おっと、382を書いたのは381だ。名前欄は間違い。

>>384
「規定するレイヤー」っていうのは、「lh5, lh6, lh7などが書庫の形式のレイヤーを
規定しているなら」って意味で書いた。でもどうやらファイル一つ一つの圧縮方法
にしかすぎないようだね。というわけで俺の案は没。理由は384の言うとおり。

( ﾟДﾟ)＜呼ばれた気がした

＞今現役でSJISつかってるのMSくらいだし。

NTはunicodeだろ。
むしろsjisもjisもeucも無くなれ
uncode以外のコードは要らん

>>388はMarkus Kuhn

Markus ｷﾀｰ。
アイツは頭がオカシイとしか思えん。

388 が欲しいのは
「うんこーど」。
Markus とベクトルは違えど頭がオカシイのです。

>>388
普通のプリンタの内部コードはJISだろ。そうじゃないのもあるのかな？

>>389
Markus KuhnとMarkus Scherer(@IBM)は別人なんだね。混同してた。
Markus Kuhnのいかれたエピソード希望。語ってください。

[email protected]で「UTF-8以外のlocaleを廃止してしまえ。」とか言ってた。
この人の辞書にはsoft landingという言葉はないと思われ。

>>394
> [email protected]で「UTF-8以外のlocaleを廃止してしまえ。」とか言ってた。
> この人の辞書にはsoft landingという言葉はないと思われ。

なんだその程度か。いいんでない? 俺もそう思ってるし。
「漢字なんて絵文字。使ってる奴らはバカ」くらい言ってるのかと思ってた。

> なんだその程度か。いいんでない? 俺もそう思ってるし。

今は随分状況が改善されてるけど、3年くらい前にこんなこと言われたら
正直たまらんですよ。まあそれはそれとしてこんなのもあった。

ttp://slashdot.jp/journal.pl?op=display&uid=64&id=40155
ttp://slashdot.jp/comments.pl?sid=51843&cid=188174

返す返すも中国がうらやましい

>>396
昔の i18n-ML 読めないんだな。
特に 4.0.2 リリースの頃の発言とか、迷言ばかりだったと思うんだが。

> 今は随分状況が改善されてるけど、3年くらい前にこんなこと言われたら
> 正直たまらんですよ。
改善？
本質を理解せずに、国際化・多言語化はとりあえず Unicode にしとけ、
なんて間違った認識が広まりすぎただけだと思うが。

>>396
おー、ありがとう。読んでみた。
まぁ気持ちは分かる。
そもそもターミナルエミュレータは右から左に書くことを想定して作られて
いないんだから、もっとリッチな環境でのみサポートしろってことだよな。
「不合理な宗教的な理由で使われている」っていうのは滅茶苦茶だが。
関係ないけど、縦書きターミナルエミュレータってあるのかなぁ。

mlterm は縦表示できますよ。

>>398
日本語のロケールとしてUTF-8を採用するかという話では
ないのですか

>>401
(ﾟДﾟ)？

>>401
XUtf8*系のAPIを突っ込もうとしていたときの話。(*1)
つか、UTF-8以外のlocaleを捨てるなら、そもそもそんなものを突っ込む
必要あるのかよと小一時間(ry

*1) 結局4.0.2というマイナーリリースに駆け込みで突っ込まれた。
正直「XFree86のリリースマネージメント終わってるな」と思ったが。

禿げどう

うにこん最強

>>401みたいな的外れなレスが付くあたり、原理主義者の布教は上手く行ったんだろうな。

> 今は随分状況が改善されてるけど、
についてだったんだが

誰か XF86 fork して Xutf8* 消して CSI xterm 入れてくれYO。

>>408
それってまんまOpenI18Nじゃね？

>>409
openi18n.orgって規格団体みたいのじゃないの？
他に同名のがあるの？

>>410
openi18n.orgでXLib-I18Nとitermが開発されている。
XLib-I18NはXFree86のクライアントライブラリのfork。
itermはCSIなターミナルでフレームバッファ版とX11版がある。

debian では xiterm って名前なのか。
今まで探してもなかったわけだ…

それと fbiterm とにわかれてるからなあ。

>>411
thx

SJIS2000ってのが有るんだな。
これってどうよ？

>>415
それってJIS X 0213をねじ込んだShift JISのこと?
何年前の話題だ……。

2000つーぐらいだから少なくとも4年以上前？

\

>>417
2000は、JIS X 0213 2000の2000ね。
JIS X 0213をJIS2000って言う人もいるらしい。(俺は聴いたことないけど)
http://seclan.dll.jp/ccjx0213.htm

JIS X 0212(補助漢字)の方の埋め込みを使っていたシステムあるのか?

つーかOS Xのクリップボードのテキストはまさに
JISX0213をねじ込んだShift_JISなわけだが

OS X って UTF-8 じゃなかったっけ ?
それともクリップボードだけ Shift JIS なん ?

>>419
JIS X 0213は今年2月に改正されたんで、今後はJIS2004とでも呼ぶのかな?

でもってシフトJIS方式の符号化は Shift_JIS-2004 てな名前になったわけ
ですが。(附属書1)

JISX0213イラネ

まあしかし国内で規格化しておいた方が、
その中の文字がUnicode.orgで採用されやすいし。

>>422
IANAへの登録ﾏﾀﾞｰ? (AAry

まず厨房mohtaをどうにかしないと。

登録申請ってRFC2978の手続きに従ってietf-charsetsにメールを投げれば
誰でもできるんじゃないの?

その手続きを踏むこともロクにできなかったmohta氏って・・・

mohtaなんか無視して必要だと思う奴が登録申請すればいいじゃん。
漏れはUnicodeでいいと思うからやらないけど

ねぇねぇ、なんでいつまでも文字コードだけ貧乏くさい発想の元でやってるの？

>>430
貧乏くさい発想ってのは何をさしてるの?

一文字に 32bit なり 64bit なりをババーンと割り当ててしまえってことだろ。

とりあえずおれが今まで書いた文章全部ババーンと変換してよ。

重複符号化や異体字検索のデータベースもババーンと作ってよ
空間だけならISO 10646はすでに31ビットあるし

Ｓ−ＪＩＳ・EUCなんて糞

今後はＧＢ２３１２だ

大陸でも捨てられたものを使えとは…

ISO 2022もTRONも中国語に関してはGB2312に毛が生えたレベル

1文字64bit固定
1言語につき100,000,000文字分のスペース
後はお好きに

これでどこからも異論の声は上がらない

> これでどこからも異論の声は上がらない
誰も実装しないまま消えていくおかげでな（ｗ

誰も実装できないのか
駄目だな

「たった」47000字くらいのExtension Bすらろくに実装されてないもんな

42711字だった

>>438
これいいな。採用！

少しは過去ログ嫁よ。
これだから漢字文化圏の連中は(ry

.

EUC使いたがるプログラマは目的と手段が入れ替わった発想しかできなくなってる

.

>>125
># 中国語だと今度は発音の違いもcollationの対象かぁ(w

ウリナラのKSコードは同じ字体でも発音ごとに違うコードを割り当ててる<丶｀∀´>ﾆﾀﾞ
そのへんがチョッパリの文字コードやメリケンのユニコードとは違う。

全角チルダ化け何とかしてくれ

>>451
フィッシング詐欺にはもってこいですね

# 実際には統合漢字と正規等価だから使えないけど

あーあと北チョソが、今のUnicodeのハングルの並びは科学的じゃないから
より合理的なウリナラの配列に変更するニダとか超愉快な要求も出してたなあ。
もちろん却下されたけど

保守

nihonjin kanji tukauna!
hirakana katakana only.
The great country is China!

KPS9566にすりゃいいじゃん

（ ﾟ∀ﾟ）ｱﾊﾊ八八ﾉヽﾉヽﾉヽﾉ ＼ /　＼　/　　＼ /　　＼ /　　＼ /　　＼

今や、世界の標準になりつつある。
http://en.wikipedia.org/wiki/Shift_JIS_art

UTFやめてiso-2022-jp-*復活希望。
UNICODEの文字セットも呼出せるESCシーケンスも定義すれば良い。

>>460
すでにあるんだけど...ちゃんと仕様書読みな。

コーラン読まないイスラム原理主義者はただのDQNテロリストだよん。

共産党員は全員共産党宣言だのなんだのを読んでるんだよもん?

>>462
頭悪そうな突っ込みw

どこがどう頭悪そうか書かない奴も同程度。

>>438
人類の生活圏が全宇宙に広がった頃には足りなくなります

2ちゃんねるって SJIS だよな。
てか、Windows-31j かな。

SJISって嫌われてるの？
自作printf作った時は2byte文字コードが追っかけやすくて便利だった記憶があるんだけど？

0x5cが2byte文字中に入る時点で嫌だ。

つうか、Unicode でいいじゃん

だから、SJISを撲滅するんだろ?

UTF-8/UTF-16/UTF-32
があるのだから

UTF-64が出てもおかしくないな。

>>471はUTF-5を使ってください。

SJIS撲殺天使

UTF-65536

UTF-37564

まあまあ、そうあわてなさんな。
今にSJISを拡張して、4バイトコードにするから。

エスケープシーケンスの候補は 0xFD, 0xFE, 0xFF。

エスケープシーケンスって何
キーボードで入力できないの？

もう、日本語禁止な！＞＜；

おいおい、エスケープシーケンスも知らずにマルチバイト文字の話かよ。
まったくゆとり教育ってやつぁ...

SJIS 2.0 スペック
0xFD [0xA1-0xFC] [0xA1-0xFC]
0xFE [0xA1-0xFC] [0xA1-0xFC] [0xA1-0xFC]
0xFF [0xA1-0xFC] [0xA1-0xFC] [0xA1-0xFC] [0xA1-0xFC]
を基本路線とし、２バイト目に 0x5C が入らないようにする

まずはSJISを撲滅する。話はそれからだ

eyeD3 --help | grep "\--set-encoding"

--set-encoding=latin1|utf8|utf16-BE|utf16-LE

ざまあ

>>482
eyeD3だからだろ...常識的に考えて。
どうせSJIS突っ込む奴は latin1 に突っ込むし。

>>481
ほぉう、それをSJISで書くのか君は。

ｽ､ｦ､ﾊ､ﾎ､ｫ?ｻ�ﾀｷ､ﾋMozilla1.7b､ﾎﾊｸｻ�･ｳ｡ｼ･ﾉﾀﾟﾄ熙TF-8､ﾋ､ｹ､□ﾈｸﾀ､ｦﾋｽｵﾋｽﾐ､ﾆ､ﾟ､□｣
､ﾇ､□､ﾁ､网ﾀ､ﾈ｡ﾖSJIS､ﾇﾁﾃ､ﾆ､ｯ､ﾀ､ｵ､､｡ﾗ､ﾃ､ﾆ･ｨ･鬘ｼ､ﾋ､ﾊ､□ｸ､网ﾊ､､?
(､ﾋ､ｷ､ﾆ､篦ｾ､ｬｲｽ､ｱ､ｹ､ｮ､ﾆｸｫｶ□ｷ､ｹ､ｮ､□ﾄ)

>>485
もっかいSJISで頼む。

タイ語だのBiDiだので苦労している人達から見れば、
0x5cがどうの、包摂がどうのなんてあまりに贅沢な悩みだろ。
Markus Kuhnが>>396みたいなことを言い出すのも非常にうなずける。
ヨーロッパ人もMとiが同じ幅になるとかハイフネーション出来ないとかを
我慢しながら使っているわけだし。

SJISっていつの時代も現実解でいいよね

>>487

すまそ。Mとiが同じ幅になることとSJIS(ないしSJIS撲滅運動)
との関係が分からんが、SJIS万歳でOK？

いまさら文字コードなんか気にする必要ないじゃーん

>>487
> ヨーロッパ人もMとiが同じ幅になるとかハイフネーション出来ないとかを
> 我慢しながら使っているわけだし。

1950年代にタイムスリップかよ

もしかしてヨーロッパ人は今でもダム端使って、2ｃｈとかみてんの？

文字コードの問題は今後30年たっても解決していない。

文字コードはさらに増えるね

世界の文字コードを統一することに失敗したので、今度は
世界中の単語に統一したコードを振ってみるのはどうだろう？

もちろん同じ意味の単語に同じ値を割り振るわけだ。
多義語の場合はどういう意味で使っているのかを選択する
必要がある。多義語は多値になることもある。

今度は最初から32ビットでいくけどいいよね？

PSOのワードセレクトみたいなものだね
日常で使う単語なら32ビットもあれば十分だろうね

16x16のイメージととみなした256ビットをそのままコードにして必要な時は
on the flyでOCR処理しよう。これで全て解決。

非字形文字はどうすんの？

非図形だった。
制御文字とか各種スペース類とか。

16x16 で全ての文字が表せると思っている時点で
16ビットもあれば充分と思ってたのと同程度

>>497

で、そのやり方の場合、OCR 結果は何コードにするの？

# まるでうちの社長レベルだな

>>501
え？UTF-256 じゃないの？

>>502

いいえ。シフトJISです。

撲滅マダー

>>495
lojban の1200の基礎語彙のことか.

lojban:
・文化的に中立の人工言語
・語彙は1200の語根の合成語としていくらでも拡張できる
・同音異義語が存在しえないよう構成されている

いいアイディアをもらった.

撲滅マダー

大手プロバイダのトップページは大多数がshift_jisだね。
まだまだ安泰だ。

ちなみにyahooはトップはutf-8に変えたけど、
その他ほとんどのページやwebメールはeuc_jpのまま。

>>1

つ Samba

撲滅されそうにないな

UnicodeでもUTF-16は廃止してもいいと思うな。
UTF-16はUCS-4に置き換えたほうがいい。

合成文字あれば、UTF-32(UCS-4)でも64bit以上必要になるぜ?

正規化すると64bitでも足りないということか

>>495
遊方僧とか来ちゃったよ？

半角カナさえ無ければSJISも出てこなかった

今日すごいのかなー。1000円へ

よく歴史を知らないんだが、SJISが初期の頃にすぐさま圧倒的シェア取ったのに、
なんでUNIXではEUCに固執した馬鹿たちが大勢いたの？

ほぼ無改造で大半のソフトが動いたから。SJISはそうはいかなかった。

昔の人は日本語テキストを英語しか想定してないソフトで処理しようとしたのか。

今も昔も日本のUinxerは自分でコードが書けないんだな。

しかしsendmailみたいな8ビット目を落とすソフトウェアまで出てきたりして、
ISO-2022-JPを制定してメールはそちらを使うようになった。
結果として多くの日本語を扱うソフトは3種類のエンコーディングをサポート
する羽目になった。
今はそれに加えてUTF-8もあるし大変だ。

Sendmailが悪いわけじゃないし
「8ビット目を落とすソフトウェアが出てきた」わけじゃない。
7ビットがデフォルトだったところに
8ビットも使えるソフトウェアが出てきた。

それに比べてとMSの対応は素晴らしい。
早期にOS内部はunicodeで統一し、APIを二つ用意して、マクロでラップ。
あらゆる言語をターゲットにしてたOSだけはあるな。