2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

SJIS撲滅運動

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




2 :名無しさん@お腹いっぱい。:02/01/30 04:55
UNi印普及まで5年待て。

3 :名無しさん@お腹いっぱい。:02/01/30 04:59
Linux板についでここでもかよ。
いつものように忠告してやるが、CCSとCESの区別はつくか? ISO2022って何だか知ってるか?

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



4 :名無しさん@お腹いっぱい。:02/01/30 05:01
HP-UXでja_JP.SJIS
Solarisでja_JP.PCK

5 :名無しさん@お腹いっぱい。:02/01/30 05:10
>>3
そんなに SJIS好きなん?

6 :名無しさん@お腹いっぱい。:02/01/30 05:16
どちらかというと2022系のほうが好きだ。
単に>>1が厨房だとこの上ないクソスレになるだろうから聞いてみただけ。



7 :ほげ:02/01/30 05:18
2022なんて作らずにEUCでいったらいいんです。
2022無駄。古くからあるのでいいんじゃない?

8 :1:02/01/30 05:19
CCS...Console Communication System
CES...Crew Esacpe System

ですがなにか?

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

9 :ほげ:02/01/30 05:22
>> 2022無駄、SJISも無駄。

10 :名無しさん@お腹いっぱい。:02/01/30 05:23
確かに資源の無駄使いだな。

11 :名無しさん@お腹いっぱい。:02/01/30 05:32
> 2022なんて作らずにEUCでいったらいいんです。
いやだからさ、こういう発言をしちゃう厨房があふれるでしょ?と言ってる。


12 :名無しさん@お腹いっぱい。:02/01/30 05:32
iso-2022-jp と junet ってどうちがうの。


13 :名無しさん@お腹いっぱい。:02/01/30 05:47
MS>>>>>>>>>>>>>>>>>>>>>>>>>>>>others

14 :名無しさん@お腹いっぱい。:02/01/30 05:50
iso-2022-jp-2 とかは...
とりあえず、unification より multiplication マンセー。

15 :名無しさん@お腹いっぱい。:02/01/30 05:51
でもランダムアクセスが出来るってのは捨てがたいかもしれない。>unification


16 :名無しさん@お腹いっぱい。:02/01/30 07:35
最新流行は CSI。これ。

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


17 :名無しさん@お腹いっぱい。:02/01/30 08:36
Coding System Independent?
ううーん、わからない。調べまーす。

18 :名無しさん@お腹いっぱい。:02/01/30 08:38
おしかった!
CodeSet Independence でした。

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


19 :名無しさん@お腹いっぱい。:02/01/30 08:55
Unix板で文字コードを云々したいなら
CCS/CESぐらいしっとけ。
http://www.unicode.org/unicode/reports/tr17/

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


20 :名無しさん@お腹いっぱい。:02/01/30 09:15
つか、文字セットとエンコード、じゃだめなんか?
むやみに略語増やすのやめて欲しい、と泣いてみる。別に略語に
してもかっこよくないぞ?

21 :名無しさん@お腹いっぱい。:02/01/30 10:15
別にかっこいいから略してるわけじゃ
ないと思うが。


22 :名無しさん@お腹いっぱい。:02/01/30 10:49
文字セットはCCSとACR、
文字エンコーディングはCEFとCESにほぼ対応しますな。

23 :名無しさん@お腹いっぱい。:02/01/30 11:11
CEFってunicode以外で聞いたことないんだけど、
他でも使ってる?


24 :名無しさん@お腹いっぱい。:02/01/30 11:30
世界中のみんなが納得するのが存在すればいいけど
実際存在しないんでしょ?

25 :某ポストモダン評論家:02/01/30 11:39
そもそも文字を抽象的実体としてコード化するなどという
発想じたいが、哀しいまでに現代人が西洋合理主義的思考に
染まってしまったことのあらわれである。

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


26 :名無しさん@お腹いっぱい。:02/01/30 12:31
>>25
代案は?

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


27 :名無しさん@お腹いっぱい。:02/01/30 12:48
>>26
昔、fj.comp.misc あたりで当用海亀がそんなこと逝ってたのを思い出した...
# 奴が2chに降臨されたらとてもうざいので伏せ字。

28 :名無しさん@お腹いっぱい。:02/01/30 13:07
>>26
富豪的だね。
でもどう処理するのか想像出来ない洩れは一生下級プログラマなんだろな...
文字列を保持するバッファがとんでもなくでかくなりそ。
32 bit じゃアドレス空間足りないね。

29 :名無しさん@お腹いっぱい。:02/01/30 14:37
ttp://www.euc.jp は勉強になるよ.
あと linux 板の EUC 撲滅スレも.

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

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


31 :名無しさん@お腹いっぱい。:02/01/30 14:57
UNICODEはともかく「EUCに統一」というのは納得イカン。
文字列の先頭から舐めないと文字の判別が出来ないから嫌。

32 :名無しさん@お腹いっぱい。:02/01/30 15:27
UNICODEのバーションはどれが良い?

33 :名無しさん@Meadow:02/01/30 15:32
shift_jis は 2ch.net がつかってるよん。

34 :名無しさん@お腹いっぱい。:02/01/30 15:41
>>31
それじゃあ、UTF-7, UTF-8も駄目?

35 : :02/01/30 15:42
文字撲滅。早く脳とUSB接続しようよ。

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

37 :名無しさん@お腹いっぱい。:02/01/30 15:54
で、1 が 2ch で吠えると SJIS が撲滅できるの?

38 :名無しさん@お腹いっぱい。:02/01/30 16:03
>今現役でSJISつかってるのMSくらいだし
Appleは?

39 :名無しさん@お腹いっぱい。:02/01/30 16:05
ところで、Lynxで表示はEUC、書き込みはS-JISってできませんか?
Lynxで2ch使いたいんですがうまく行かなくて。


40 :名無しさん@お腹いっぱい。:02/01/30 16:06
w3m 使えば?

41 :名無しさん@お腹いっぱい。:02/01/30 16:11
>34
UTF-8は、任意のoctetの上位2bitを見れば
A) 1バイト文字
B) 多バイト文字の1バイト目
C) 多バイト文字の2バイト目以降
のいずれなのかを見分けられる。
だから最大でも1文字分戻ればよい。
ShiftJISやEUCのように、「文字の境界」が見つかるまで戻る必要はない。


42 :名無しさん@emacs:02/01/30 16:59
>>39
lynxじゃなくてnavi2chを使ったらどう?
Webブラウザじゃないけども、emacs側さえ設定すれば簡単だよん。
ちなみに俺は表示も入力もSJISだ、、、、、


43 :名無しさん@お腹いっぱい。:02/01/30 17:36
>>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 使ったほうが楽じゃない?


44 :名無しさん@お腹いっぱい。:02/01/30 18:31
>>36
SolarisはCSIだよ。
Shift_JIS dependentなpatchは、本家に取り入れられないでしょ。

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

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

46 :名無しさん@お腹いっぱい。:02/01/30 19:49
w3m + nvi-m17n。これ最強。

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


47 :北京 ◆5rr1Eed6 :02/01/30 22:06
MacOSX使いです。
Unicodeに統一激キボーンです。
ウィナーのIとかIIが(藍)とか表示されて困る。

48 :名無しさん@お腹いっぱい。:02/01/30 22:58
  ハハハ
  ∧_∧  / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
 ( ^∀^)<  あほか >>47
 ( つ ⊂ ) \_________
  .)  ) )
 (__)_)     (^∀^)ゲラゲラ

49 :名無しさん@お腹いっぱい。:02/01/30 23:17
>>41
ハァ? Shift_JISやEUCにシフトコードは無いだろ??

50 :49:02/01/30 23:20
あ、任意のoctetって事ね。スマソ。

51 :名無しさん@お腹いっぱい。:02/01/30 23:22
>49
うるさいよ厨房。勉強して出直せ。
「お前のいうところの」シフトコードとやらは、少なくともEUC_JPにはあると思うぞ(げら
single shift で googleしる。


52 :名無しさん@お腹いっぱい。:02/01/31 01:18
>18

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


53 :名無しさん@お腹いっぱい。:02/01/31 01:25
M$一味のUnicodeがなければUTF-8がまともに
出来上がってすべて丸く収まったろうに。

54 :名無しさん@お腹いっぱい。:02/01/31 01:26
>53
そういうのを引かれ者の小唄っていうんだよ。
世の中理想論だけじゃ動かないんだから、政治的に立ち回れない方が
負けるのは性がない。

55 :おねがい☆りなっくす:02/01/31 01:40
でもMSがコードを乱してくれたお陰でコード変換というお仕事に
ありつけたプログラマーもいるのれす。。。
わたし?むふふふふ。。。

56 :名無しさん@お腹いっぱい。:02/01/31 01:48
IT で生産性は上がらない、と。

57 :名無しさん@お腹いっぱい。:02/01/31 01:51
(◕ฺ∀◕ฺ)
>>49 http://euc.jp/ を読むとヨイデスYO

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

59 :名無しさん@お腹いっぱい。:02/02/03 23:22
どっちかっつーとEUC撲滅して欲しいよ。

60 :過激派:02/02/03 23:37
日本語撲滅!!!

61 :名無しさん@お腹いっぱい。:02/02/03 23:39
>60
フランス語も。

62 :歌劇派:02/02/03 23:45
漢字撲滅!!!

63 :結構マジ:02/02/03 23:47
アメリカ撲滅!!!

64 :名無しさん@お腹いっぱい。:02/02/03 23:52
そして人類は滅亡した。

65 :おれもマジ:02/02/03 23:52
今アメリカがいなくれなれば世界は平和

66 :禿同:02/02/03 23:52
鬼畜米英!!!


67 :諸悪の根源:02/02/03 23:55
ASCII撲滅!!!


68 :名無しさん@お腹いっぱい。:02/02/03 23:57
>67
Impressもついでに撲滅!!

69 :名無しさん@お腹いっぱい。:02/02/03 23:59
sb

70 :名無しさん@お腹いっぱい。:02/02/03 23:59
良スレあげ


と。


71 :名無しさん@お腹いっぱい。:02/02/04 00:03
週刊ASCII廃刊!!

72 :名無しさん@お腹いっぱい。:02/02/04 00:04
>71
噂の真相もついでに撲滅!!

73 :名無しさん@お腹いっぱい。 :02/02/04 00:21
さすがにネタ切れか?


74 :過激派:02/02/04 00:34
俺撲滅!!!

75 :歌劇派:02/02/04 00:51
お前ら!撲滅!!!

76 :名無しさん@お腹いっぱい。:02/02/04 00:53
僕滅!!!

77 :名無しさん@XEmacs:02/02/04 01:07
>76
ワラタ


78 :名無しさん@お腹いっぱい。:02/02/04 01:26
おれ的には社内の負の遺産「JEF」をどこかにおいやって欲しい・・・

79 :名無しさん@お腹いっぱい。:02/02/04 01:42
>>76
やられた…

80 :名無しさん@お腹いっぱい。:02/02/04 01:49
>>49
EUC には一応 SS2 と SS3 っていうシフトコードはあるよ。
シングルシフトだからすぐ解除されるけど。

81 :名無しさん@お腹いっぱい。:02/02/04 02:10
>80
51にて既出


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

83 :過激派:02/02/04 02:33
>>82
がいしゅつだけど linux 板の euc 撲滅スレは
興味深い話題がいくつかあるよ

84 :名無しさん@お腹いっぱい。:02/02/04 03:19
>>82
漢字統合は、別に横暴でもなんでもないとおもうが、0208 の変換テーブルが
山ほどあるのはたまらんな、ってーか、そっちをちゃんと統合しろや、ゴルァ > Unicode.org

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


85 :名無しさん@お腹いっぱい。:02/02/04 07:51
>>82
>次世代32ビットUNICODE
ってなに?


86 :名無しさん@お腹いっぱい。:02/02/04 07:51
age


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

88 :名無しさん@お腹いっぱい。:02/02/04 10:51
ここだけ5年前のスレですか?

89 :名無しさん@お腹いっぱい。:02/02/04 11:10
>>88
そうです。


90 :名無しさん@お腹いっぱい。:02/02/04 12:12
>>87
Win9x系はVFAT以外Unicodeサポート無しなので、MSに限らずまだしばらく
の間は対応が進む事は無いと思われ。

91 :名無しさん@お腹いっぱい。:02/02/04 12:28
>>90
WinXP は NT 系だから対応が進まないということはないと思われ

92 :名無しさん@お腹いっぱい。:02/02/04 12:37
おい!
恵比寿を忘れんな!

93 :名無しさん@お腹いっぱい。:02/02/04 19:17
>>92
恵比寿ってなに?


94 :名無しさん@お腹いっぱい。:02/02/04 19:18
>93
ビール工場しかない東京の街

95 :日立グループ社員:02/02/04 19:53
>>91
> WinXP は NT 系だから対応が進まないということはないと思われ
社内のマシンはまだWin95ですが何か?

96 :名無しさん@お腹いっぱい。:02/02/04 20:46
>>82
まったくだ。英語圏の人は、やっぱ漢字文化が分からないのかな?
Unicodeもまだまだ良くない感じです。

97 :名無しさん@お腹いっぱい。:02/02/04 20:48
>>92
恵比須大工で統一するには、さらに困難を伴うと思われ

98 :名無しさん@お腹いっぱい。:02/02/08 01:39
FreeBSDでSJISの入った/bin/shスクリプトを起動するとshがcoreはくのはなぜ?
回避策あるの? sjisサポートshとか。


99 :名無しさん@お腹いっぱい。:02/02/08 01:49
bashをスタティックリンクして/bin/shに仕立ててみるとか…

100 :名無しさん@お腹いっぱい。:02/02/15 10:35
m17n/i18n/l10n 統合スレ@unix板はここですか?


101 :名無しさん@お腹いっぱい。:02/02/15 16:58
このスレの1はMarkusだな?

102 :名無しさん@お腹いっぱい。:02/02/15 17:11
>>101
イマイチ。
マイナス10マカース。
(1マカース=10ヴォイド)


103 :名無しさん@お腹いっぱい。:02/02/16 01:39
>>100
> m17n/i18n/l10n 統合スレ@unix板はここですか?

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

104 :名無しさん@お腹いっぱい。:02/02/16 01:44
>>98
core 吐くのはバグに決まってるじゃん。send-pr すれ。


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

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


106 :マイナス10マカース:02/02/16 03:43
>>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/

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

107 :マイナス10マカース:02/02/16 03:56
ちなみにム板だと

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

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

108 :103:02/02/16 10:43
>>107
確かに、ム板だとレベル低くなっちゃうかもね。

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


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

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

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

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

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


111 :名無しさん@お腹いっぱい。:02/02/16 22:54
tronコードってどうなの?全世界の文字扱えるんでしょ?

112 :名無しさん@お腹いっぱい。:02/02/16 23:17
>110
そりゃHaskellスレのレベルが高いだけ。

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

探し方悪かったかなぁ…

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

114 :名無しさん@お腹いっぱい。:02/02/17 01:55
>>113
> (爆)
なんで爆発するんですか?(w


115 :名無しさん@お腹いっぱい。:02/02/17 02:08
SJISみたいな腐ったフォント使ってる奴痛すぎなのですが…

116 :名無しさん@お腹いっぱい。:02/02/17 02:10
>115
この板であんまり適当なことを書くと怒られちゃうよ。

117 :名無しさん@お腹いっぱい。:02/02/17 02:12
>>116
115がイタすぎて起こる気すらおきないっつーか。

118 :名無しさん@お腹いっぱい。:02/02/17 02:12
>>115
SJIS のフォントって何? 見せてみ。


とかね。


119 :名無しさん@お腹いっぱい。:02/02/17 02:42
フォントのエリアス名にSJISってつけたら
SJISフォントのできあーがりっと


120 :マイナス10マカース:02/02/17 02:47
うお! googleってる間にすっかり糞スレに!!

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

121 :100:02/02/17 03:39
>>113
言語によっては必要or有用そうな気がする。LC_COLLATE。

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

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


122 :103:02/02/17 04:14
Collationって符合化方式じゃなくて、文字集合の問題だよね。

123 :名無しさん@お腹いっぱい。:02/02/17 04:27
>SJISみたいな腐ったフォント
フォントのインデックスがsjisだとか。

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

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


124 :マイナス10マカース:02/02/17 04:43
wcscoll(西夏文字, 亀甲獣骨文字)とした場合、
やっぱり文字が発明された順序で評価するべきなんですか(w

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

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

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

125 :マイナス10マカース:02/02/17 05:09
>122

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

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

126 :マイナス10マカース:02/02/17 05:11
>125
> # 中国語だと今度は発音の違いもcollationの対象かぁ(w

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

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

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

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

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


128 :100:02/02/17 05:28
>>123
それは普通 stateful とは言わないのでは?


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

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


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

131 :名無しさん@お腹いっぱい。:02/02/17 10:09
wchar_tは16bitのまま、という意味では押し通してるけど。。。

132 :名無しさん@お腹いっぱい。:02/02/17 10:19
imodeでSJISしか使えないぞです!
FOMAもSJISしか使えないぞです!
みんなでドコモごとSJISを撲滅してくれよです!
おいどんがドコモの社長になったら、全部EUCにするぞです!
社内文書もSJIS禁止だぞです!


133 :名無しさん@お腹いっぱい。:02/02/17 10:30
>>132
SJIS だと何か困りますか?


134 :名無しさん@お腹いっぱい。:02/02/17 10:37
http://choco.2ch.net/test/read.cgi/kao/1013358333/
こういうスレが困ります

135 :名無しさん@お腹いっぱい。:02/02/17 10:39
>>134
それは、SJISのせいではありません。


136 :名無しさん@お腹いっぱい。:02/02/17 10:40
>>134
 おーい。そのスレ、SJIS で無い文字が大量に入ってるぞ(わら
 Unicode を実体参照でだしてあるんだよ。

137 :134:02/02/17 10:44
>133に対して、SJISだと(ちゃんと表示されなくて)困る、って話だが

138 :名無しさん@お腹いっぱい。:02/02/17 11:32
どーして符号化文字集合と文字エンコーディングスキームの
区別が出来ない奴がこうも多いの?

139 :名無しさん@お腹いっぱい。:02/02/17 11:34
JISが悪い。
そしてASCIIが悪い。


140 :名無しさん@お腹いっぱい。:02/02/17 11:42
UNIXでもSJIS使えばいいのに。

141 :名無しさん@お腹いっぱい。:02/02/17 11:44
>140
名言だ。伝説になるよ。

142 :名無しさん@お腹いっぱい。:02/02/17 11:52
1バイト=32ビットにしる!

143 :名無しさん@お腹いっぱい。:02/02/17 14:04
印刷屋はつらいよ。
とほほ。

144 :マイナス10マカース:02/02/17 15:50
ありゃ、やっぱちここで続けるにはタイトルが悪すぎるかも。
>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

145 :マイナス10マカース:02/02/17 15:53
あらら、あげちまった。

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


146 :マイナス10マカース:02/02/17 17:55
うー、どうも勘違いしてるな、漏れ。

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

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

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

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


148 :103:02/02/17 22:34
>>146,147
どういう利用を想定している訳? 例えば、

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

という順に並べるの?

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

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


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

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

150 :名無しさん@お腹いっぱい。:02/02/17 23:17
一言言っとくが、AIXのデフォルトの日本語コードはSJISだぞ!!


151 :100:02/02/17 23:19
>>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
>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.」

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

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

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


154 :100:02/02/18 01:58
>>152
># ますますこんな機能はアプリで用意せいとか思ったり。
どうやって?


155 :101:02/02/18 18:23
すんまそん、平日は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
>>155
> と無制限に増えるのがぞっとするということですかね。
アプリでやっても無制限に増えると思いますが。
それも各アプリに(w

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

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


157 :うひひ:02/02/19 10:20
しかし何だね。むつかしいコトはわかんねーけどsjis浸かってれば
幸せなんじゃねーの?
ウィソの存在はでかいし
SJISであんま困ったことねーな


158 :名無しさん@お腹いっぱい。:02/02/19 10:31
たとえばsjisの「ソ」なんかは2バイト目がバックスラッシュと同じコードなんで、
バックスラッシュをエスケープするような厨房コードを書くと日本語通らんのよ。

159 :名無しさん@お腹いっぱい。:02/02/19 11:39
nn

160 :うひひ:02/02/19 13:16
>>158
ソ−なんだぁ。

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


161 :101:02/02/19 13:25
>>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


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

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

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


163 :何を?:02/02/23 11:53
( ゚Д゚)<ボクメーツ


164 :100:02/02/24 10:48
いまごろ気付いたけど
>>162 は 10 ではなくて 100 です。スマソ。>10


165 :名無しさん@お腹いっぱい。:02/03/09 09:55
SJISよりUTF8のほうが便利なのにどうして使わないの?

166 :名無しさん@お腹いっぱい。:02/03/09 12:33
>>162
厨房コードというより、外国のコードに多いよ。


167 :名無しさん@お腹いっぱい。:02/03/10 10:31
>>165
文字数少ないから。

168 :名無しさん@お腹いっぱい。:02/03/14 02:52
>>166
まあ、
どっちにしろ SJIS が悪いわけではないよね。


169 :名無しさん@お腹いっぱい。:02/03/23 17:33
i-Mode用コンテンツ作るのにShift-JIS強要がいやん。

170 : :02/03/23 17:53
UNIX側がSJISに会わせよう

171 :名無しさん@お腹いっぱい。:02/03/23 20:28
やだ

172 :名無しさん@お腹いっぱい。:02/03/23 20:36
NEWS-OS も 日本語 HP-UX も SJIS デフォじゃなかったっけ?
昔の国産 Unix はそういうのが多かったと思うけど。


173 :名無しさん@お腹いっぱい。:02/03/23 21:21
あくまでも、「昔の国産」ね。オルタナティブがある今は考えが
別になってもおかしくないでしょ。

174 :名無しさん@お腹いっぱい。:02/03/23 22:46
>>168
> まあ、
> どっちにしろ SJIS が悪いわけではないよね。

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

175 :名無しさん@お腹いっぱい。:02/03/23 22:49
>>172
> 昔の国産 Unix はそういうのが多かったと思うけど。

ΣはEUC-JPでしたが…

176 :名無しさん@お腹いっぱい。:02/03/23 22:50
あ、東芝のSun3の日本語化もEUC-JPでした。
名前はJOSだったかどうか…

177 : :02/03/24 02:31
だれかgccのSJISパッチの情報教えて!!
他のベンダコンパイラと互換をとるのが面倒だから。
(ベンダコンパイラで日本語オプションを外せばよいのは分かってるけど)

178 :名無しさん@お腹いっぱい。:02/03/24 11:19
>177
LANG=ja_JP.SJISで良かったりしない?

179 :名無しさん@お腹いっぱい。:02/03/24 12:38
>>177
使うlibraryもShift_JISを理解する必要があることは理解しますか?
e.g. printf().


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



181 :名無しさん@お腹いっぱい。:02/03/25 01:15
gccでもgcc3系はLANG見てsjisもエスケープ無しでコンパイルできるとか
どっかで見たような...
手元に環境無いから確認できんけど。

182 :名無しさん@お腹いっぱい。:02/03/25 16:16
>>174
悪いのは SJIS や ISO2022 ではなくフレームワークの不在。

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

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


183 :名無しさん@お腹いっぱい。:02/03/26 19:41
フレームワーク…。X11R5 の Xwc…。

184 :名無しさん@お腹いっぱい。:02/04/01 00:44
Xutf...(w


185 :名無しさん@お腹いっぱい。:02/06/20 23:42
で、JIS X 0213で追加された文字はいつUnicodeに入るの?


186 :名無しさん@お腹いっぱい。:02/06/20 23:52
>>180
>>178が言っているのはコンパイルが通っても
関数で対応してないときちんと処理されるかどうか
わかんないよって言う意味でしょ。
たぶん。

187 :名無しさん@お腹いっぱい。:02/06/21 23:17
>>185
もう入ってるよ。
http://www.unicode.org/unicode/reports/tr28

188 :名無しさん@お腹いっぱい。:02/09/10 13:56
age

189 :名無しさん@お腹いっぱい。:02/09/13 14:03
半角カナの使えるロケール定義ファイルはないものだろうか?

190 :名無しさん@お腹いっぱい。:02/09/13 14:04
Linuxでね、半角カナ使いたいんだけどさ。

191 :名無しさん@お腹いっぱい。:02/09/13 15:08
ロケールつってもいろいろあるが。。。
半角カナ使いたいってのもどこでつかうのか意味不明。

192 :名無しさん@お腹いっぱい。:02/09/13 15:48
>>189
jp_JP.eucJPで何の問題もないと思うが。

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


193 :名無しさん:03/01/03 02:11
       / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄\
Λ_Λ  | 君さぁ こんなスレッド立てるから          |
( ´∀`)< 厨房って言われちゃうんだよ             |
( ΛΛ つ >―――――――――――――――――――‐<
 ( ゚Д゚) < おまえのことを必要としてる奴なんて         |
 /つつ  | いないんだからさっさと回線切って首吊れ     |
       \____________________/

(-_-) ハヤクシンデネ… (-_-) ハヤクシンデネ… (-_-) ハヤクシンデネ…
(∩∩) (∩∩) (∩∩)

(-_-) ハヤクシンデネ… (-_-) ハヤクシンデネ… (-_-) ハヤクシンデネ…
(∩∩) (∩∩) (∩∩)

(-_-) ハヤクシンデネ… (-_-) ハヤクシンデネ… (-_-) ハヤクシンデネ…
(∩∩) (∩∩) (∩∩)


194 :名無しさん@お腹いっぱい。:03/01/03 03:08
文字コードの話してるのに、どうして(いわゆる)半角カタカナや全角英数使ってるバカがいるんだろうか。


195 :名無しさん@お腹いっぱい。:03/01/03 03:36
>>194
ウルセーバカ!


196 :名無しさん@お腹いっぱい。:03/01/03 04:44
お前ら、自分で自分の首絞めてる印象。

197 :名無しさん@お腹いっぱい。:03/01/03 12:28
>>195
使うなよボケ

198 :_:03/01/03 12:33





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







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


200 :名無しさん@お腹いっぱい。:03/01/03 13:11
>>199
http://savannah.gnu.org/cgi-bin/viewcvs/emacs/emacs/etc/NEWS?rev=1.613.2.1


201 :名無しさん@お腹いっぱい。:03/01/03 13:17
要するに内部コード方式が維持されればいいと思うわけで。
でもunicodeに影響され過ぎてると思うけどなぁ。
utf-8-emacs is backwards compatible with the UTF-8 encoding of Unicode.
とか

202 :名無しさん@お腹いっぱい。:03/01/03 13:20
ps. トンパ文字とかその他まだsetされてない文字はどうするわけ?増やした
い文字なんて無尽蔵に増えるだろうに。


203 :名無しさん@お腹いっぱい。:03/01/03 13:24
あ、後方互換性だから関係ないか。

204 :名無しさん@お腹いっぱい。:03/01/03 13:27
>>200 は結局なにを言いたかったのかな?内部コードがunicodeのサブセットになるわけじゃない。
答えてくれ。


205 :名無しさん@お腹いっぱい。:03/01/03 13:39
>>194 どうして使っちゃいけないの?


206 :名無しさん@お腹いっぱい。:03/01/03 14:04
トンパ文字を使う民族がPC使うかが問題やな
いくつ種類あるんだYO!

207 :名無しさん@お腹いっぱい。:03/01/03 14:58
>>206
日本にルーズソックスを履いて棲息しているという噂を耳にしたことが
あります。

208 :名無しさん@お腹いっぱい。:03/01/03 16:22
>>205
全角の「?」使うなよ...

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


209 :!205:03/01/03 16:36
>>205 そうなんだ? 知らなかったよ。

210 :209:03/01/03 16:37
s/205/208

211 :名無しさん@お腹いっぱい。:03/01/03 16:45
>>209 >>210

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

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

212 :名無しさん@お腹いっぱい。:03/01/03 17:31
>>200
utf-8-emacsか。-emacsを付けるところはやっぱり偉いね。

213 :名無しさん@お腹いっぱい。:03/01/03 19:27
>>204
書いてない事を憶測されても困るんですが、、、
単にFYIでリンクを貼っただけで、何らかの主張があるならそれも書きますってば。

214 :名無しさん@お腹いっぱい。:03/01/03 20:47
現状で問題なし。っていう人がマジョリティでしょ。

215 :209:03/01/04 03:08
>>211
最近 sed 使ってないから忘れてたよ。vim だとそれでオツケイなんだけどね。

216 :名無しさん@お腹いっぱい。:03/01/04 04:02
結局 Han unification の問題はどうなったんですか?
日本と中国の漢字を違う glyph で表示できるんでしょうか.

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

217 :名無しさん@お腹いっぱい。:03/01/04 21:38
どれでもいいから一つにしてくれ・・・

218 :山崎渉:03/01/15 13:03
(^^)

219 :名無しさん@お腹いっぱい。:03/01/24 13:10
「Shit JIS」でググると結構な数ヒットするんですが、
みなさん、故意に書いてるんですかね?

220 :糞JIS撲滅:03/01/24 13:49
DoCoMo 用の CGI のコメントに故意に書いたことならあります。

221 :山崎渉:03/03/13 17:30
(^^)

222 : :03/03/14 00:28
半角カナのないコードは糞!

223 :名無しさん@お腹いっぱい。:03/03/20 00:05
とりあえず、2ch見ているうちは半カナは必須かな?と言ってみる。

224 :名無しさん@お腹いっぱい。:03/03/21 02:49
>>222
半角カナのないコードってあるの?

225 :名無しさん@お腹いっぱい。:03/03/21 04:09
jis ってあったっけ?
そういえば unicode はどうなの?

226 :224:03/03/21 07:16
>>225
ISO-2022-JP も EUC-JP も Unicode も半角カナあると思うんだけど?

227 :名無しさん@お腹いっぱい。:03/03/21 08:12
それはねこみみです

228 :名無しさん@お腹いっぱい。:03/03/21 10:17
>>226 では ISO-2022-JP で「半角カナ」を使う方法を教えてください。

229 :名無しさん@お腹いっぱい。:03/03/21 10:52
>>228
カナの幅が高さの半分くらいのフォントを使う。

230 :名無しさん@お腹いっぱい。:03/03/21 11:34
はい次。

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

232 :名無しさん@お腹いっぱい。:03/03/24 02:08
>>228
http://www2d.biglobe.ne.jp/~msyk/charcode/jisx0201kana/

233 :名無しさん@お腹いっぱい。:03/03/24 03:18
ISO−2022−JP 【通信用語:情報符号編】
[アイエスオウにーまるにーにージェイピー] (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
jis もいっぱいあって、わかんないよ!!!

235 :名無しさん@お腹いっぱい。:03/04/11 01:34
ネジの規格もJISだしね!!!

236 :名無しさん@お腹いっぱい。:03/04/11 02:51
iso2022 の G0 とか G1 とか GR とか GL とか、
わけわかんない概念はどっからきたの?

237 :名無しさん@お腹いっぱい。:03/04/11 04:14
フォントロード可能な文字端末

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


238 :名無しさん@お腹いっぱい。:03/04/11 04:15
あ、フォントロード可能なプリンタもね。

239 :山崎渉:03/04/17 12:23
(^^)

240 :あぼーん:あぼーん
あぼーん

241 :名無しさん@Emacs:03/04/27 01:20
お前ら、新しいエサですよ。

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

242 :あぼーん:あぼーん
あぼーん

243 :名無しさん@お腹いっぱい。:03/04/27 02:28
変なのが食いついてるよ。

244 :あぼーん:あぼーん
あぼーん

245 :名無しさん@お腹いっぱい。:03/06/14 17:09
I hate UNICODE :-)

246 :名無しさん@お腹いっぱい。:03/07/01 02:39
unicodeで表示できてJIS系で表示できない漢字はなにがありますか?

247 :名無しさん@お腹いっぱい。:03/07/01 06:18
JIS X 0221:2001はExtension Bが未収録(Unicode 3.2未対応)なので、
ざっと45,000字ぐらいは表示どころか扱うこともできねい筈だす

248 :名無しさん@お腹いっぱい。:03/07/01 14:01
>>246
とりあえずマルチポストいくない。
必要なければ UTF-8 にする事はお勧めしない。

249 :名無しさん@お腹いっぱい。:03/07/01 21:51
>>246
表示つーのがもうどう答えていいもんだか分からないけど、
JISで定義されてない漢字はJIS系では扱えないだろ。大陸の奴とか。

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

250 :名無しさん@お腹いっぱい。:03/07/01 22:02
Unicode って字を組み合わせる規格なかったっけ?
〇と 1 とか。

251 :名無しさん@お腹いっぱい。:03/07/01 22:46
あるけどさ。
口{〇, 1} こんな感じで三文字に。(丸付き一)
口{〇, ‖{3, 4}} こんな感じで四文字に。(丸付き三十四)
こういうので済むなら、丸つき数字を文字集合に含める必要ないしな。
白抜きがどうにもならんし。

252 :あぼーん:あぼーん
あぼーん

253 :あぼーん:あぼーん
あぼーん

254 :名無しさん@お腹いっぱい。:03/08/14 07:57
へーこんな仕組みできたなんて知らなかった。
管直人もいろいろ工夫してるもんだね。なにが条件になってるんだろう?

255 :あぼーん:あぼーん
あぼーん

256 :名無しさん@お腹いっぱい。:03/08/14 17:05
SJISよりも関西弁を撲滅してください

257 :名無しさん@Emacs:03/08/15 01:19
>>256
なんでやねん?


258 :あぼーん:あぼーん
あぼーん

259 :あぼーん:あぼーん
あぼーん

260 :ヽ(´ー`)ノ:03/08/18 11:21
>>254
山崎渉って From に書くと fushianasan になるんじゃなかったっけ?


261 :名無しさん@お腹いっぱい。:03/10/09 04:56
www.cbook24.com/bm_detail.asp?sku=4901676156

262 :名無しさん@お腹いっぱい。:03/10/09 23:45
SJISはいいけどCP932を撲滅しる。

263 :名無しさん@お腹いっぱい。:03/10/10 17:57
互換性がなくなるから無理

264 :名無しさん@お腹いっぱい。:03/10/11 00:36
つーかCP932が非互換の元凶。

265 :名無しさん@お腹いっぱい。:03/10/11 02:02
うにコードだって、別にUTF-8だけじゃないしなぁ・・・









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

266 :名無しさん@お腹いっぱい。:03/10/11 13:43
UCS-4 で満足だとでも?

267 :名無しさん@お腹いっぱい。:03/10/11 14:25
ゼロから作りなおさないかぎり Unicode はすべてクソ。

268 :名無しさん@お腹いっぱい。:03/10/11 14:39
>>267
ゼロは無だと思うから「作りなおす」ことはできない
ゼロから作りあげるが適切

269 :名無しさん@お腹いっぱい。:03/10/11 21:41
UnicodeはBOMがウザい。誰だよあんな余計なもの考えた奴は。

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

270 :名無しさん@お腹いっぱい。:03/10/12 02:43
http://www.alanwood.net/

271 :名無しさん@お腹いっぱい。:03/10/12 13:05
どれでもいいからひとつにしてくれ・・・マジで

272 :名無しさん@お腹いっぱい。:03/10/12 23:18
>>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の方もダメ。

273 :名無しさん@お腹いっぱい。:03/10/12 23:40
UTF-8撲滅sage

274 :名無しさん@お腹いっぱい。:03/10/12 23:55
>>272
で、使ってはいけない理由を言おうとはしないわけですね。

275 :名無しさん@お腹いっぱい。:03/10/13 00:11
>>272
> そのWebサイトに書いてあることは嘘があったり重要なことが抜けてたりするので
たとえばどの辺ですか?

276 :名無しさん@お腹いっぱい。:03/10/13 00:30
「半角片仮名」という言葉が間違いで「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
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
・一意の符号化表現が要求された場合は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
例外として、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
>>272
> UTF-8もUTF-16も。

こりゃ言い過ぎだ。

281 :名無しさん@Emacs:03/10/13 14:18
>>276-279
理想論をただ書き連ねただけのオナニーだな。

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

282 :名無しさん@お腹いっぱい。:03/10/13 14:22
>>281

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

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


283 :281:03/10/13 15:00
>>282
いやあ、スマンスマン。
本当は「オナニー」の部分も半角カナで書くつもりだったんだけどね。

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

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

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

284 :名無しさん@お腹いっぱい。:03/10/13 15:11
>>283

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

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

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

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

286 :名無しさん@お腹いっぱい。:03/10/13 15:33
>>285

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

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

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

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

> いやあ、スマンスマン。
> 本当は「オナニー」の部分も半角カナで書くつもりだったんだけどね。

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

287 :名無しさん@お腹いっぱい。:03/10/13 15:33
手書きでも半角カタカナとか全角英数字を浸透させちゃえばいいんだよ。

288 :名無しさん@お腹いっぱい。:03/10/13 15:39
四半角仮名や四倍角英数字が Unicode に入るのはいつですか?

289 :名無しさん@お腹いっぱい。:03/10/13 15:47
>>286
かっかし過ぎ。

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

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

291 :名無しさん@お腹いっぱい。:03/10/13 16:01
>>290
> もっと上のレベルの
レイヤは上かもしれないが
レベルは上じゃねーよ。
過去の実装を無視して規格だけこねくりまわしても無意味。

292 :名無しさん@お腹いっぱい。:03/10/13 16:03
>>291
そういうのは規格を読んでから言ってね。

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

294 :名無しさん@お腹いっぱい。:03/10/13 16:13
厨な質問ですいませんが、たとえば、2ちゃんねるなんかは、
「半角カナ」と「全角カタカナ」の使い分けが当然のように行われているわけですが、
これは「過去との互換性が要求されるとき」に合致するのではないの?

295 :291:03/10/13 16:31
「だけ」と書いたのが読めんのか。

296 :名無しさん@お腹いっぱい。:03/10/13 16:39
>>295
だから、規格さえ読んでない人は論外なんだって。

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

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

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

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

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

298 :名無しさん@お腹いっぱい。:03/10/13 17:55
>>297
> そのような実装の後追いで決まった規格を使う場合は、
> 過去の実装や慣例についても十分考慮する必要がある。

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

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

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

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

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

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

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

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

300 :名無しさん@お腹いっぱい。:03/10/13 20:00
>>299

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

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

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

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

こういうことです。

301 :名無しさん@お腹いっぱい。:03/10/13 20:58
そういえば、どっかの携帯会社が規格の予約領域を勝手に使っていましたね。

302 :名無しさん@お腹いっぱい。:03/10/13 22:17
で、何番の発言が AoiMoe なの?

303 :281:03/10/13 22:42
>>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
>>302
少なくとも俺は違うぞ。(w

305 :名無しさん@お腹いっぱい。:03/10/13 22:48
>>303
> 確かに>>300の言う通り、cp932のマッピングテーブルはMicrosoftが
> 勝手に決めてしまったもの。そのためGNU libiconv本家は
> cp932パッチの統合をかたくなに拒んでいる。

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


306 :281:03/10/13 22:52
>>305
> 少し前に、libiconvのCVSの方に入ってます。

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

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

307 :名無しさん@お腹いっぱい。:03/10/13 23:34
>>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
>>281
> 技術者の一方的な都合で「なかったこと」にすることはできない。

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

309 :名無しさん@お腹いっぱい。:03/10/14 01:35
>>307
> 返事を返すなんて……。もうちょっと認識のある人の意見を望みます。
気持ちはわかるが、そういう書き方をするから不毛なやり合いになる。

310 :名無しさん@お腹いっぱい。:03/10/14 12:42
>たとえば既存の実装が規格とずれていた場合、次の改訂の際に規格に合わせてく
>る可能性があるわけです。改訂版では過去との互換性があるとは限りません。

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

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

311 :名無しさん@お腹いっぱい。:03/10/14 13:12
>>307 あなたのような適当な考えによる実装が、今の混乱を引き起こしているのです。
どのような考えによる、どのような実装が、規格にもなるべく沿いつつ現実的である事ができるでしょうか。

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

312 :名無しさん@お腹いっぱい。:03/10/14 14:21
>>311
とはいっても、>>307が言うように、
fullwidth/halfwidthは過去のものにすべく努力していくべきだろ?

313 :フグ/ハリセン本について:03/10/14 16:48
フグ/ハリセン本について

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/

314 :名無しさん@お腹いっぱい。:03/10/16 04:31
>>311
> 今まで 272 さんは「規格の話をしている」と仰ってました。その通り、276-279 は規格では
> 否定しているという話にすぎない訳です。

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

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

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

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

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

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

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

315 :名無しさん@お腹いっぱい。:03/10/16 23:26
>>314
>強制力とかそんなのはどうでもよくて、使うべきではない文字は使うべきではないのです。

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

316 :名無しさん@お腹いっぱい。:03/10/17 02:21
通信かよ!?

317 :名無しさん@お腹いっぱい。:03/10/17 07:44
通信だよ

318 :名無しさん@お腹いっぱい。:03/10/17 12:34
問題は、技術者だけではなく、ソフトウェアの顧客がそのことを理解して、
いわゆる半角カナを JIS X 0208コードに修正する費用と時間を出してくれるかということもある。

319 :名無しさん@お腹いっぱい。:03/10/18 20:41
いまだにJEFつかってる銀行なんか多いくらいなので、、、

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


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

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

322 :名無しさん@お腹いっぱい。:03/10/24 01:43
そういえば>>232の何が結局「嘘」なのかも説明してませんね。

323 :名無しさん@お腹いっぱい。:03/10/24 20:06
> 「規格」というのも結局、すべての二者関係毎に個別に合意を取り付ける
> 手間を省くためのものだし。

はい、そのとおりです。

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

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


324 :名無しさん@お腹いっぱい。:03/10/24 20:08
> 「使うべきでない」を「使ってはいけない」と表現したり
> まさかMUSTとSHOULDの区別も付かないわけじゃないですよね

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

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

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

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

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

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

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

325 :名無しさん@お腹いっぱい。:03/10/24 21:55
>>324
> 新規で使わなければいいだけなのに。
"今まで使えてただろ! どうにかしろ !"

326 :名無しさん@お腹いっぱい。:03/10/24 21:56
> "今まで使えてただろ! どうにかしろ !"

そんな人いますか?

327 :名無しさん@お腹いっぱい。:03/10/25 01:28
とりあえず、既存の規格を無視するやつをなんとかしろよ。
docomo とか。

328 :名無しさん@お腹いっぱい。:03/10/25 07:05
わざと無死してるわけですが

329 :名無しさん@お腹いっぱい。:03/10/26 03:22
>>326
います


330 :名無しさん@お腹いっぱい。:03/10/27 17:01
> 「使うべきではない」ものを、相当の理由なく使おうとしている場合、
誰がそんなことしてるんですか?

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

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

331 :名無しさん@お腹いっぱい。:03/10/27 17:04
> さかのぼって修正する必要はないんでは? そのために「過去との互換性」うんぬんの
> くだりがあるわけだし。
それこそがまさに「相当の理由」でしょうが。

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

333 :名無しさん@お腹いっぱい。:03/10/27 17:16
> ISO-2022-JPで
リンク先は「ISO-2022-JPで」使うなんて話はしていない。
7bit-JISの話なら出てくるけど。
> EUC-JP
> Shift JIS
そもそも「使ってはいけない」が嘘だから論外

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

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

で、どこが嘘なの?

335 :名無しさん@お腹いっぱい。:03/10/27 17:26
> 広まってませんよ。WindowsのMS UI Gothicを使ったことはありますか?
> そんな期待はフォントが違うだけで無意味になる程度のものです。

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

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

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

336 :名無しさん@お腹いっぱい。:03/10/27 17:40
> 区別しない実装が存在することは区別しない慣習が存在することの
訂正
区別しない実装が存在することは区別する慣習が存在することの

337 :名無しさん@お腹いっぱい。:03/10/27 20:50
とりあえず引用トークはムカつくっつーことだけは
よ〜くわかった。

338 :名無しさん@お腹いっぱい。:03/10/27 21:13
>>337
> とりあえず引用トークはムカつくっつーことだけは
fjを思い浮かべるからかな。


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

339 :名無しさん@お腹いっぱい。:03/10/29 03:53
>> また低レベルな、平行線の話を繰り返したいのですね。
>そもそも>>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
間違い探しクイズなんてしてないでハッキリ言う方が良いのでは?
と傍観者は思うのでした。

341 :名無しさん@お腹いっぱい。:03/10/29 04:04
死めよ。おぬーら。

342 :名無しさん@お腹いっぱい。:03/10/29 18:58
>>340

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


343 :名無しさん@お腹いっぱい。:03/10/29 22:26
>>341
はっきり言いすぎですYO!


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



345 :名無しさん@お腹いっぱい。:03/10/29 23:32
>>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
質問
jisx0213の文字って全部unicodeに反映されたの?

347 :名無しさん@お腹いっぱい。:03/10/30 02:13
されてない


348 :名無しさん@お腹いっぱい。:03/10/30 10:49
>>347
どの程度反映されてるんでせうか?それともまったく?

349 :名無しさん@お腹いっぱい。:03/11/02 00:02
補助漢字にある奴は全部あるでしょ。
丸付き数字のような合成文字系は全部拒絶されてんじゃない?

350 :名無しさん@お腹いっぱい。:03/11/02 01:48
丸付き数字系は全て追加されました。


351 :名無しさん@お腹いっぱい。:03/11/02 01:55
>>349-350
つーことは一部を覗いてほとんど入れられてるって事ですか。
ありがとうございました。

352 :名無しさん@お腹いっぱい。:03/11/02 01:56
sage忘れた…すいません。

353 :名無しさん@お腹いっぱい。:03/11/02 01:59
確か追加されてないのはひらがなとアクセント付きの発音記号だけだったと思う。


354 :名無しさん@お腹いっぱい。:03/11/03 13:58
Unicodeでの外字の扱いってどうなってんの?
使えんの?

355 :名無しさん@お腹いっぱい。:03/11/03 16:55
PUAでいいんじゃね?

356 :名無しさん@お腹いっぱい。:03/11/03 22:55
>>353
ひらがなってのは、'ん'+'゛'みたいなやつのこと?

357 :名無しさん@お腹いっぱい。:03/12/06 17:00
>>353
Unicode側の言い分では「全部入れた」ことになっているんだろうけどね。
「合成で済むだろゴルァ」って感じで。


358 :名無しさん@お腹いっぱい。:03/12/08 11:28
結局混乱を増しただけだと思うんだけどなー。
あぁ、日本以外じゃ困らんから、テキトーな国際化には役に立っとるんか。

359 :名無しさん@お腹いっぱい。:04/02/25 00:35
http://pc2.2ch.net/test/read.cgi/software/1044162360/
>>874
格納がしっかりしてれば文字コードが必ずSJISになり
どの文字コードで格納するか調べる必要も無いでしょう。

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

360 :名無しさん@お腹いっぱい。:04/02/25 00:47
>>876
その必要が有る人のみ守ってるだけでは?
普通は日本語使わないけどね。

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

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

361 :名無しさん@お腹いっぱい。:04/02/25 01:19
>UNIX上でも SJIS 使ったのしか見たこと無いね。
俺は無いな、少なくとも配布されてるものに関しては。

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

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



362 :名無しさん@お腹いっぱい。:04/02/25 01:35
>それらの書庫はファイル名に関する仕様を守ってる。
日本語ファイル名を格納してる書庫の話でしょうが。
ASCIIファイル名は日本語扱うときはSJISでって仕様を満たしている訳じゃない。

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

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

364 :名無しさん@お腹いっぱい。:04/02/25 01:59
>ファイル名に関する仕様は満たしてる。
日本語のファイル名の話をしてるんだから・・・。
関係ない話を持ち出さない。

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

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


365 :名無しさん@お腹いっぱい。:04/02/25 16:30
向こうで暴れてる困ったちゃんをどうにかしろよ

366 :名無しさん@お腹いっぱい。:04/02/25 16:44
lhaの書庫はパス名にShift JISを使うって仕様だったのか。知らなかった。
どこに書いてあるんだろう。

367 :名無しさん@お腹いっぱい。:04/02/25 17:57
>>365
ここで暴れてる困ったちゃんもどうにかしてください。

368 :名無しさん@お腹いっぱい。:04/02/26 08:55
>>366
昔のlhaのドキュメント

369 :名無しさん@お腹いっぱい。:04/02/26 09:36
>>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)


370 :名無しさん@お腹いっぱい。:04/02/26 11:18
>>369
lha for UNIXの方だったかもしれん。
だったらそんなに昔じゃないなスマソ


371 :名無しさん@お腹いっぱい。:04/02/26 15:56
詳しくは知らんが、YosshiがSysopやってたflaboでは
過去ログ(LZHで固めた奴)にSJISファイル名使ってたような…

372 :名無しさん@お腹いっぱい。:04/02/26 16:35
いや、当初はMS-DOSしかっていうか何も考えなくて生SJISにしたはずなんだけど、
どっかでそれを仕様として確定したと思うんだよ。
それがlha for UNIX以前か以後かがよー分からん。

373 :名無しさん@お腹いっぱい。:04/02/26 16:40
よーわからんけどlha for UNIX以前か以後かって区分は重要なの?

374 :名無しさん@お腹いっぱい。:04/02/26 16:57
>>372
> いや、当初はMS-DOSしかっていうか何も考えなくて生SJISにしたはずなんだけど、
だろうね。

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

375 :名無しさん@お腹いっぱい。:04/02/26 18:46
よーわからんけど「誰が」はともかく「どこで」は重要なの?

376 :名無しさん@お腹いっぱい。:04/02/26 23:01
         ☆ チン     マチクタビレタ〜
                         マチクタビレタ〜
        ☆ チン  〃  ∧_∧   / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
          ヽ ___\(\・∀・) <  「誰が」「どこで」確定したのか情報まだ〜?
             \_/⊂ ⊂_ )   \________
           / ̄ ̄ ̄ ̄ ̄ ̄ /|
        | ̄ ̄ ̄ ̄ ̄ ̄ ̄|  |
        | .愛媛みかん.  |/

377 :名無しさん@お腹いっぱい。:04/02/26 23:06
>>375
> よーわからんけど「誰が」はともかく「どこで」は重要なの?
必ずしも吉崎氏が策定する必要は無いんだよ。
仮に「LHA Open Group」でもいいわけだし。
そういう意味の「どこで」ってこと。

378 :名無しさん@お腹いっぱい。:04/02/27 00:38
>>377
> 仮に「LHA Open Group」でもいいわけだし。
それは「誰が」だと思うんだが…
まぁどっちでも良いけど。

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

379 :名無しさん@お腹いっぱい。:04/02/27 00:40
>>378
> ところで「LHA Open Group」って実在する組織なん?
いやー俺の脳内団体だよ。「誰が」だけだと「吉崎氏に決まってるだろ」と
なりかねないので書いたのだけれど、よけい混乱させちゃったみたいで
申し訳ない。

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

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

381 :名無しさん@お腹いっぱい。:04/03/01 11:06
>>380
そこでなぜUTF-16。こういう場合はUTF-8だろう。

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

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

383 :名無しさん@お腹いっぱい。:04/03/02 03:34
>>380
> それだとASCIIな人と日本語な人以外は困るから、
日本人以外は使ってないので困らない。

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

384 :名無しさん@お腹いっぱい。:04/03/02 03:41
>>381
> これが規定するレイヤーによっては、「lh8はUTF-8」という風にも
面白いアイデアだと思うけど、
全く問題無しってわけにもいかないと思うよ。

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

385 :381:04/03/02 09:04
おっと、382を書いたのは381だ。名前欄は間違い。

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

387 :( ゚Д゚)<ボクメーツ ◆uhiboKUMEQ :04/03/05 10:17
( ゚Д゚)<呼ばれた気がした

388 :名無しさん@お腹いっぱい。:04/03/05 20:23
>今現役でSJISつかってるのMSくらいだし。

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

389 :名無しさん@お腹いっぱい。:04/03/05 20:57
>>388はMarkus Kuhn

390 :名無しさん@お腹いっぱい。:04/03/06 14:12
Markus キター。
アイツは頭がオカシイとしか思えん。

391 :名無しさん@お腹いっぱい。:04/03/06 20:10
388 が欲しいのは
「うんこーど」。
Markus とベクトルは違えど頭がオカシイのです。

392 :名無しさん@お腹いっぱい。:04/03/08 08:40
>>388
普通のプリンタの内部コードはJISだろ。そうじゃないのもあるのかな?

393 :名無しさん@お腹いっぱい。:04/03/08 11:51
>>389
Markus KuhnとMarkus Scherer(@IBM)は別人なんだね。混同してた。
Markus Kuhnのいかれたエピソード希望。語ってください。

394 :名無しさん@お腹いっぱい。:04/03/08 12:27
i18n@XFree86.orgで「UTF-8以外のlocaleを廃止してしまえ。」とか言ってた。
この人の辞書にはsoft landingという言葉はないと思われ。


395 :名無しさん@お腹いっぱい。:04/03/08 12:33
>>394
> i18n@XFree86.orgで「UTF-8以外のlocaleを廃止してしまえ。」とか言ってた。
> この人の辞書にはsoft landingという言葉はないと思われ。

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

396 :名無しさん@お腹いっぱい。:04/03/08 13:52
> なんだその程度か。いいんでない? 俺もそう思ってるし。

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

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


397 :名無しさん@お腹いっぱい。:04/03/08 14:00
返す返すも中国がうらやましい

398 :名無しさん@お腹いっぱい。:04/03/08 14:09
>>396
昔の i18n-ML 読めないんだな。
特に 4.0.2 リリースの頃の発言とか、迷言ばかりだったと思うんだが。

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


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

400 :名無しさん@お腹いっぱい。:04/03/08 14:29
mlterm は縦表示できますよ。

401 :名無しさん@お腹いっぱい。:04/03/08 15:45
>>398
日本語のロケールとしてUTF-8を採用するかという話では
ないのですか

402 :名無しさん@お腹いっぱい。:04/03/08 15:57
>>401
(゚Д゚)?

403 :名無しさん@お腹いっぱい。:04/03/08 16:03
>>401
XUtf8*系のAPIを突っ込もうとしていたときの話。(*1)
つか、UTF-8以外のlocaleを捨てるなら、そもそもそんなものを突っ込む
必要あるのかよと小一時間(ry

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




404 :名無しさん@お腹いっぱい。:04/03/08 21:45
禿げどう

405 :名無しさん@お腹いっぱい。:04/03/08 23:49
うにこん最強

406 :名無しさん@お腹いっぱい。:04/03/09 11:07
>>401みたいな的外れなレスが付くあたり、原理主義者の布教は上手く行ったんだろうな。

407 :401:04/03/12 15:37
> 今は随分状況が改善されてるけど、
についてだったんだが

408 :名無しさん@お腹いっぱい。:04/03/13 15:09
誰か XF86 fork して Xutf8* 消して CSI xterm 入れてくれYO。


409 :名無しさん@お腹いっぱい。:04/03/13 15:25
>>408
それってまんまOpenI18Nじゃね?

410 :名無しさん@お腹いっぱい。:04/03/13 21:24
>>409
openi18n.orgって規格団体みたいのじゃないの?
他に同名のがあるの?


411 :名無しさん@お腹いっぱい。:04/03/16 16:27
>>410
openi18n.orgでXLib-I18Nとitermが開発されている。
XLib-I18NはXFree86のクライアントライブラリのfork。
itermはCSIなターミナルでフレームバッファ版とX11版がある。


412 :名無しさん@お腹いっぱい。:04/03/16 21:31
debian では xiterm って名前なのか。
今まで探してもなかったわけだ…

413 :名無しさん@お腹いっぱい。:04/03/17 09:09
それと fbiterm とにわかれてるからなあ。


414 :410:04/03/18 06:32
>>411
thx


415 :名無しさん@お腹いっぱい。:04/03/23 18:55
SJIS2000ってのが有るんだな。
これってどうよ?

416 :名無しさん@お腹いっぱい。:04/03/23 21:05
>>415
それってJIS X 0213をねじ込んだShift JISのこと?
何年前の話題だ……。

417 :名無しさん@お腹いっぱい。:04/03/24 00:43
2000つーぐらいだから少なくとも4年以上前?

418 :\:04/04/16 18:22
\

419 :名無しさん@お腹いっぱい。:04/04/17 00:09
>>417
2000は、JIS X 0213 2000の2000ね。
JIS X 0213をJIS2000って言う人もいるらしい。(俺は聴いたことないけど)
http://seclan.dll.jp/ccjx0213.htm

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


420 :名無しさん@お腹いっぱい。:04/04/17 09:38
つーかOS Xのクリップボードのテキストはまさに
JISX0213をねじ込んだShift_JISなわけだが

421 :名無しさん@お腹いっぱい。:04/04/17 17:18
OS X って UTF-8 じゃなかったっけ ?
それともクリップボードだけ Shift JIS なん ?

422 :名無しさん@お腹いっぱい。:04/04/18 10:53
>>419
JIS X 0213は今年2月に改正されたんで、今後はJIS2004とでも呼ぶのかな?

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


423 :名無しさん@お腹いっぱい。:04/04/18 16:42
JISX0213イラネ

424 :名無しさん@お腹いっぱい。:04/04/18 21:12
まあしかし国内で規格化しておいた方が、
その中の文字がUnicode.orgで採用されやすいし。

425 :名無しさん@お腹いっぱい。:04/04/23 12:37
>>422
IANAへの登録マダー? (AAry

426 :名無しさん@お腹いっぱい。:04/04/23 14:33
まず厨房mohtaをどうにかしないと。

427 :名無しさん@お腹いっぱい。:04/04/24 07:38
登録申請ってRFC2978の手続きに従ってietf-charsetsにメールを投げれば
誰でもできるんじゃないの?

428 :名無しさん@お腹いっぱい。:04/04/24 18:09
その手続きを踏むこともロクにできなかったmohta氏って・・・

429 :名無しさん@お腹いっぱい。:04/04/25 01:01
mohtaなんか無視して必要だと思う奴が登録申請すればいいじゃん。
漏れはUnicodeでいいと思うからやらないけど

430 :名無しさん@お腹いっぱい。:04/05/07 15:22
ねぇねぇ、なんでいつまでも文字コードだけ貧乏くさい発想の元でやってるの?

431 :名無しさん@お腹いっぱい。:04/05/07 15:54
>>430
貧乏くさい発想ってのは何をさしてるの?

432 :名無しさん@お腹いっぱい。:04/05/08 03:03
一文字に 32bit なり 64bit なりをババーンと割り当ててしまえってことだろ。

433 :名無しさん@お腹いっぱい。:04/05/08 05:46
とりあえずおれが今まで書いた文章全部ババーンと変換してよ。

434 :名無しさん@お腹いっぱい。:04/05/08 11:20
重複符号化や異体字検索のデータベースもババーンと作ってよ
空間だけならISO 10646はすでに31ビットあるし

435 :名無しさん@お腹いっぱい。:04/05/12 05:09
S−JIS・EUCなんて糞

今後はGB2312だ

436 :名無しさん@お腹いっぱい。:04/05/12 13:07
大陸でも捨てられたものを使えとは…

437 :名無しさん@お腹いっぱい。:04/05/13 01:48
ISO 2022もTRONも中国語に関してはGB2312に毛が生えたレベル

438 :名無しさん@お腹いっぱい。:04/05/17 03:24
1文字64bit固定
1言語につき100,000,000文字分のスペース
後はお好きに

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

439 :名無しさん@お腹いっぱい。:04/05/17 11:42
> これでどこからも異論の声は上がらない
誰も実装しないまま消えていくおかげでな(w

440 :名無しさん@お腹いっぱい。:04/05/17 19:46
誰も実装できないのか
駄目だな

441 :名無しさん@お腹いっぱい。:04/05/20 00:10
「たった」47000字くらいのExtension Bすらろくに実装されてないもんな

442 :名無しさん@お腹いっぱい。:04/05/21 06:03
42711字だった

443 :名無しさん@お腹いっぱい。:04/06/18 16:03
>>438
これいいな。採用!

444 :名無しさん@お腹いっぱい。:04/06/19 01:33
少しは過去ログ嫁よ。
これだから漢字文化圏の連中は(ry

445 : :04/06/22 15:54
.

446 :名無しさん@お腹いっぱい。:04/07/08 23:41
EUC使いたがるプログラマは目的と手段が入れ替わった発想しかできなくなってる

447 :名無しさん@お腹いっぱい。:04/08/02 11:13



448 :名無しさん@お腹いっぱい。:04/09/02 13:13
.

449 : :04/11/05 18:39:19



450 : :05/01/07 12:57:00



451 :名無しさん@お腹いっぱい。:05/01/17 16:39:56
>>125
># 中国語だと今度は発音の違いもcollationの対象かぁ(w

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

452 :名無しさん@お腹いっぱい。:05/01/18 16:04:56
全角チルダ化け何とかしてくれ

453 :名無しさん@お腹いっぱい。:05/02/20 02:28:59
>>451
フィッシング詐欺にはもってこいですね

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

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

455 :名無しさん@お腹いっぱい。:2005/07/14(木) 11:55:46
保守

456 :名無しさん@お腹いっぱい。:2005/07/18(月) 23:33:56
nihonjin kanji tukauna!
hirakana katakana only.
The great country is China!

457 :名無しさん@お腹いっぱい。:2005/09/20(火) 16:44:11
KPS9566にすりゃいいじゃん

458 :名無しさん@お腹いっぱい。:2005/09/20(火) 17:09:47
( ゚∀゚)アハハ八八ノヽノヽノヽノ \ / \ /  \ /  \ /  \ /  \

459 :名無しさん@お腹いっぱい。:2006/05/24(水) 19:48:34
今や、世界の標準になりつつある。
http://en.wikipedia.org/wiki/Shift_JIS_art


460 :ISO2022原理主義者:2006/05/29(月) 18:21:43
UTFやめてiso-2022-jp-*復活希望。
UNICODEの文字セットも呼出せるESCシーケンスも定義すれば良い。

461 :名無しさん@お腹いっぱい。:2006/05/31(水) 00:23:28
>>460
すでにあるんだけど...ちゃんと仕様書読みな。

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

462 :名無しさん@お腹いっぱい。:2006/05/31(水) 02:49:35
共産党員は全員共産党宣言だのなんだのを読んでるんだよもん?


463 :名無しさん@お腹いっぱい。:2006/05/31(水) 05:35:08
>>462
頭悪そうな突っ込みw

464 :名無しさん@お腹いっぱい。:2006/05/31(水) 10:21:40
どこがどう頭悪そうか書かない奴も同程度。


465 :名無しさん@お腹いっぱい。:2006/06/02(金) 16:52:15
>>438
人類の生活圏が全宇宙に広がった頃には足りなくなります

466 :名無しさん@お腹いっぱい。:2006/06/02(金) 20:20:03
2ちゃんねるって SJIS だよな。
てか、Windows-31j かな。


467 :名無しさん@お腹いっぱい。:2006/06/09(金) 02:35:13
SJISって嫌われてるの?
自作printf作った時は2byte文字コードが追っかけやすくて便利だった記憶があるんだけど?

468 :名無しさん@お腹いっぱい。:2006/06/09(金) 06:25:50
0x5cが2byte文字中に入る時点で嫌だ。

469 :名無しさん@お腹いっぱい。:2006/06/14(水) 22:28:57
つうか、Unicode でいいじゃん

470 :名無しさん@お腹いっぱい。:2006/06/15(木) 06:59:54
だから、SJISを撲滅するんだろ?

471 :名無しさん@お腹いっぱい。:2006/06/16(金) 10:28:11
UTF-8/UTF-16/UTF-32
があるのだから

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

472 :名無しさん@お腹いっぱい。:2006/06/16(金) 23:04:28
>>471はUTF-5を使ってください。

473 :名無しさん@お腹いっぱい。:2006/06/20(火) 09:58:48
SJIS撲殺天使

474 :名無しさん@お腹いっぱい。:2006/07/19(水) 23:43:22
UTF-65536

475 :名無しさん@お腹いっぱい。:2006/07/23(日) 22:49:52
UTF-37564

114 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)