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

EUCボクメツ委員会

■ このスレッドは過去ログ倉庫に格納されています
0001ﾓ･ｸ･ﾍ･ｹ菽ｦｯ01/10/16 00:18ID:ZujZqkcr
Javaとかのマルチプラットフォームなアプリでも文字コードをいじらないと化けるし。
ICQクローンで Shift_JIS<=>EUC の相互変換をするように加工とか小細工して使ってるのには泣けたＹＯ
せっかく多言語対応の環境で作られたソフトでも日本ローカルのパッチ作んなきゃいけないんじゃ
意味ないじゃん！
Winに比べて少ないアプリがさらに選択肢が狭まっちゃってどうしようもないYO
Linuxにおける日本語の標準コードはWinに倣いShift-JISをメインにすべきである。
0133login:Penguin01/10/24 03:14ID:crtkuShb
>>130
ごめん. そのスレがどう関係するのかわからないんだけど.
0134login:Penguin01/10/24 03:30ID:SXmLmgbB
もし Unicode 3.x をフル実装できるのならば、ISO-2022 は楽勝でフル実装でき
るだろうなぁ。

結局、statefull かつ可変長コードな体系がもうひとつできただけか…。
013513101/10/24 04:00ID:eNcfec5S
>>132
実際できないよ。たとえばここ。
wget -r -l0 -np kanji.zinbun.kyoto-u.ac.jp/~yasuoka/JavaScript/
とやっても、取得できないページがある。
そもそも ISO-2022-JP って、Shift_JIS の 0x5cどころじゃなく
2byte文字の中にASCII領域が出てきまくる、というかASCII領域だけ使ってるからなぁ。
ASCIIやISO-8859-1前提のソフトとは非常に相性わるい。
8bit目を使わないことで転送データ量は増えるし、ISO-2022-JPにする利点は
今となっては少ないんじゃないかな。
0136login:Penguin01/10/24 04:11ID:SXmLmgbB
>>135
wget 1.7 で何の問題もないんだけど。robots.txt を読みにいって失敗している
のを気にしているの?
013713101/10/24 04:33ID:eNcfec5S
wget 1.6での話でした...でなおしてきます
0138login:Penguin01/10/24 05:05ID:Rq945OPL
wget なんて中身がなにかなんて気にしてないだろ。
バイナリだってとれるんだから。ふつーに。
0139login:Penguin01/10/24 05:22ID:osZWRGWi
>>138
-rを使ったことないアフォ発見。
014013101/10/24 05:23ID:JalIbsLX
いやそうじゃなくて、HTMLを解析してリンク先のファイルも取得するよう指定 ( -rオプション) したとき、HTMLの解析に失敗していた、ということ。
wget1.6のHTML解析ルーチンは、ISO-2022-JPと相性がわるかった、と。
0141login:Penguin01/10/24 09:14ID:TG+/cFwo
>ごめん. そのスレがどう関係するのかわからないんだけど.
誤用によって日本語が日々変化していると見るけど。
最初は誤用→やがて一般化と思える。
0142login:Penguin01/10/24 13:01ID:kWLrrN8M
>>140
あー確かに <> が入ってナニなことになる可能性はあるかもねー
0143login:Penguin01/10/24 20:00ID:4dNCtF18
eucってなに？
0144login:Penguin01/10/24 20:06ID:XZp0N0cm
>>143
EUC isn't Useful Code
0145login:Penguin01/10/24 21:24ID:mCLLGjB8
>>144
ウマイ
0146login:Penguin01/10/25 01:50ID:xeHLuFXc
EUC is Useful Code.
0147login:Penguin01/10/27 21:03ID:FAMIO6An
age
0148ネタにツコム01/10/27 22:17ID:GBl4KnAH
>>145　全然うまくない。
GNUの場合はgnuっていう英単語があるから語呂合わせになっているの。
AUC,BUC,CUC,DUC、でも良くなっちゃうし。そも語呂合わせになっていない。
よっと全然うまくない。ネタとしてもいまいち。
0149login:Penguin01/10/28 02:02ID:8H0orc/X
良スレ age といきたいが, そもそものタイトルがよくないな
0150pu01/10/28 13:12ID:uad7byVd
EUCは撲滅すべきだろSJISといっしょにな─
0151login:Penguin01/10/28 20:19ID:N4TbNfCy
UTF-8って、一般的な圧縮への相性はどうですか？
理想的な圧縮なら、同一の文ならEUCと同じになるはずなんだから、
ディスク上だろうがネット上だろうが、UTF-8で統一して問題無しと思うが。
0152login:Penguin01/10/28 20:23ID:N4TbNfCy
同一って、同一bit列って意味じゃ無く、バイト数ね。（笑
0153login:Penguin01/10/28 20:28ID:N4TbNfCy
同一の文なら、圧縮後のバイト数は、エンコードによらず同一バイト数にできるはず。
プレーンテキストのバイト数を問題視するのは、古臭いって言いたい訳だ。
0154login:Penguin01/10/29 01:03ID:Wi7PNY4l
GNUの場合もgnuっていう英(?)単語はあるぞ。
ネタもこのスレにマッチしてる。
0155login:Penguin01/10/29 01:33ID:HLzkzUYP
>>153
原理的にはそうかも知れないが, 実際の圧縮では理想的に
data を解析してくれる訳ではないので, エンコーディングの仕方によって
大きさは変化するように思う.
だから実際は utf-8 の方が大きくなるような気がする.
もっとも大した問題でもないと思うけど.
0156login:Penguin01/10/29 02:48ID:TzGAB923
>>155
だね。plain text のデータ量なんて気にする必要まるでないし。
だからこそ、XML で markup して…なんていう話だって出てくるわけだし。
0157login:Penguin01/10/29 03:30ID:H1KcL6kF
>plain text のデータ量なんて気にする必要まるでないし。

そんなもん内容と利用頻度によるだろ。
XMLが限られた場面でしか使われないのは、その辺りが問題視
されてんじゃねえのか?
0158login:Penguin01/10/29 04:18ID:4Zx5WUc3
56は、歴代２ｃｈコピペ史上もっとも頭いいコピペだな。
あまりにも楽屋オチすぎるが、アニオタ系楽屋落ちギャクよりかはマシだし。
0159login:Penguin01/10/29 06:12ID:gPKsJk4L
しっかし、XMLでmark upしないと本格的には
使えないようなcode体系って悲しいよな〜
0160login:Penguin01/10/29 08:42ID:fAUo4XEm
第1水準、第2水準など無視して部首順に並べ直した時点で
よく使う漢字のコード領域が連続してないので、どんなに
圧縮したとしても同じだけには縮まない。

せめて両仮名だけでもU+07ffまでに入れておけば、UTF-8で
日本語を書いた時のデータ量が2割ほど縮んだのに。
もし、基本的な punctuation と漢字の頻度上位500文字(率
では8割を超える。)も2バイトで表せる範囲にあったなら、
EUCの数%増し程度だったのに…。

大陸中国・台湾・日本全部ひっくるめた使用頻度計算する
のって、客観的方法が無くて難しいだろうけどさ。
0161login:Penguin01/10/31 09:14ID:rxyU2JEX
中国と日本で同じ字でも意味がぜんぜん違ったりするのは
割とあることだし。
中国人はそもそも包摂されることに抵抗はないらしい。
文化大革命でさんざん文字を弄くったお国柄だしな。
韓国はハングル文字にしか興味ないみたいだし。

日本が ISO から意見を求められたときに、国内できちんと
した議論をした上での包摂規準を提示できなかったのが痛い。
結局痺れを切らした外人が Unicode 作っちゃったわけだし。

ISO10646 の問題は、裏返すと言語学としての「日本の漢字」
の研究がいかに貧弱だったかを揶揄してるように思う。
もういまさら「ほら貝」を鵜呑みにしてる人もいないよね。
0162login:Penguin01/10/31 09:44ID:aL+2nYNF
日本のJISってISOから馬鹿にされてそうだもんな。
全角英数字は入れちゃうし、互換性の無い変更をしちゃうしな。
よく問題になる半角カタカナってのも、規格の連続性を考えれば
全角の方を使わないべきなんだろうし…
欧米からUnicodeで良いじゃん、と思われても自業自得。
0163login:Penguin01/10/31 11:27ID:QUoePdRs
>>161
日本人が文字の形にこだわりだしたのは戦後に漢字についての
法令がいろいろ出だしてからだそうですね。特にJIS漢字制定されて
コンピュータで扱うようになってからが顕著。それ以前はやっぱ手書き
メインだから、文字にゆらぎがあるのはあたりまえのことで、
少々変わってもだれも気にしなかったの。

>>162
規格読んだことないっしょ。
全角英数字は JIS X 0208/0213 の中では単独でしか存在しないんだから
入ってて当然。アルファベットは現在日本語で一般的に使う文字で、
JIS文字は現在日本語の記述に使うための文字だからね。

その上で、別の文字集合を組み合わせて使う場合は、「同じ文字」は、
ISO-2022に従って、割り当て領域の番号が小さいほうを使うことになってる。
だから、英数字は ASCIIのものを使うし、カタカナは208のものを使うんだよん

ま、実装の努力が欠けてるのは事実だし、その点で Unicode に完全に
遅れをとっちゃったのは事実だねん。

馬鹿にするとかそういったレベルの話ではないでしょ。
そもそも目的が違う規格なんだから。
0164エディタを作ってる人01/10/31 11:52ID:FRmV6cBQ
エディタを作っているのですが、全角と半角英字の区別は
それほど問題ではないのですね。
２バイトのうち使ってる部分がどこかってだけの違いですから。
面倒なのは半角カナです。半角なのにEUCでは２バイト使っている。
この場合わけがかなり大変です。
0165login:Penguin01/10/31 11:52ID:WSuL6NVB
EBCDIC は置いといても、
ASCII と ISO 646 だって似たようなもの。
チルダとかキャレットとかマイナスハイフンとか。
集合が小さいから傷口が小さく見えるだけ。

83 JIS はともかく、78 JIS は、専用機ワープロの
世界までが、それ以前のメインフレームや写植機のような
独自コードの嵐になるのを水際で食い止めるのに、
ぎりぎりの妥協でケリを付けて間に合わせたということで、
評価は高くていい。

むろん、そのあと議論を継続できなかった。
83 JIS が最悪だったのは確かで、関係者の言語屋にも
日本語屋にも計算機屋にも責任はある。

10646 と Unicode に対して返事をロクに出来なかった
と言えばそうだが、そうすぐに返事をできるような
問題ではない。(議論を継続してりゃ出来たかもしれんが)
これは日本ばかりの問題ではなく、他の Unicode に
ぶちこまれてる言語も多くがまともに研究をされないまま
欧米の理屈で放り込まれてる。

0201 の右半分は DBCS をサポートできない系のためのもので、
0208 が使えるのなら使うなというのは妥当。

\ を ￥ の代わりに使うのやめれ、という主張が妥当か
どうかは微妙だな。そういう意味で SJIS とか EUC(jp) って、
地が 0201 なのか ASCII なのか決めとったのかな ?

SJIS はわざわざ右半分の空きを使うんだから 0201 で、
EUC は ISO 2022 に則っているから GL は ASCII って
ことでいいんかな。
0166login:Penguin01/10/31 11:54ID:U8Ydp6qc
> 結局痺れを切らした外人が Unicode 作っちゃったわけだし。

うーむ、君、全然経緯を知らないのね。
現在の Unicode の CJK ideogram を決めたグループには、日本人もちゃんと
入ってたんだよ。何が問題だったかっていうと、利用可能なコードの範囲が決
まっていたため、本来は包摂すべきじゃないような文字まで、包摂しちゃった
ことなのさ。
実際、初期の日本案では、もっと包摂基準は厳密だったんだけど (たとえば、
「直」は分離していた)、それだとコードの範囲を食い過ぎるという圧力に負
けて、今みたいな包摂になっちゃったの。で、結局、今になってやっぱり
16bit じゃ納まらないからといって、数万字の漢字を追加しているし。
そんなことしたって、既に包摂しちゃった文字は分離できないんだから
(分離して文字コードが変わったら、どこかの国がバチをかぶるんだから、
国際問題モノ。よって分離不能) 手遅れもいいとこ。
言語タグや variant タグで救済とか言っているけど、本来分離すべき文字を
包摂しておいて、扱いの面倒な方法で胡麻化すなんて、非常にババいやり方。
統合漢字は、ちゃんと時間をかけてきっちり決めれば確かにそれはそれで素晴
らしいんだけど、Unicode のやり方は、あまりにひどすぎ。

当たり前だけど、上記の問題があるので、Unicode フォントは、CJK ideogram
を使う国では、共有できません。Unicode フォントを使うと幸せになるとか
言う人間を見るたびに、ヘナヘナになる日々…
0167login:Penguin01/10/31 12:03ID:WSuL6NVB
>>164

半角で表すかどうかは規格で決めてるこっちゃない。

NEC PC-9801 のキャラジェネは漢字を半分だけ出せるような
仕様だったんで、PC-9801 ローカルな「 SJIS 2 バイト半角」
なんてものもあった。
0168login:Penguin01/10/31 12:18ID:RZr+0hFu
半角全角なんてのは、日本ローカルのプロポーショナルフォントなんで、
固定ピッチのフォントで使うのは駄目でしょ。
つうか、日本のフォントと言いながら、英数字を正確に1/2や2/3で表示できない
プロポーショナルフォントって何？
0169login:Penguin01/10/31 12:32ID:ZVg2pVZt
>163
規格としてのそういう事になってると言っても、
それまで蓄積されてた0201のコードをテーブル変換しなきゃならない
0208って悪しき前例でしょう。
それなら、Unicodeでも変換すれば良いって事になる訳ですからね。

さらに結局、ポケベル・携帯で、同じトラブルを繰り返してるんですから、
EUCを考える時に、また非力な環境が主流になるかも？と考えられる
人が居なかったのが悔やまれる。
0170login:Penguin01/10/31 12:49ID:WSuL6NVB
>>169

だったら、日本人は永遠に 0201 に縛られて濁点が
サフィックスになってるコード系を使い続けてれば
よかった、ってこと ?

ポケベル・携帯の時にはすでに十分明らかになってた問題点。
回避すべきはポケベル・携帯側。
DBCS が使えないポケベルはともかく。
0171login:Penguin01/10/31 13:47ID:QUoePdRs
>>165
当時すでに各社処理系が同種のコードをつかいはじめてたんだけど、
物によって ASCII だったり 201 だったりまざってたはず。
で、それはよくなかろうってことで、集まって相談して、
今の形の日本語EUCを決めたはず。
0172login:Penguin01/10/31 18:22ID:peF8TTWo
>170
濁点付の仮名を追加の形で付けるべきだったのでしょう。
ソートを問題視する人も居そうですが、ひらがなカタカナ混ぜてのあいうえお順
じゃなければ同じ事ですからね。

漢字が使えるポケベルも有ったのでは?コードは分かりませんが。
少しも回避する気が無かったようですからねえ。
積極的に1バイトカナを使いたがってたと思われます。
0173login:Penguin01/11/03 08:21ID:KZcvtfAV
>>172
> 濁点付の仮名を追加の形で付けるべきだったのでしょう。

それが0208でしょ。
0201 kana(右面)に濁点付の仮名追加出来る余裕ある?
0174login:Penguin01/11/03 09:09ID:yDgQv8+0
0208は0201とカナ配列の順序違うじゃん。
濁点付きカタカナだけなら後ろの31Byteでも良いが、素直に別区に追加で良いっしょ。
「あいうえお」に「゛゜」付きなど全組み合わせを用意してさ。
後から泥沼式に「か゜き゜く゜け゜こ゜」を追加する羽目になるなんて見苦しい事をせずにね。
0175login:Penguin01/11/03 10:05ID:hLV/0wc3
ん〜うちの会社の人間はEUCとかSJISとかいう
コードがあることじたい知らないのよ。
Linuxで生成したテキストファイル渡したら
バグって言われて怒られる。
「テストしろよ！！」ってね。
#何のテストするんだよ。ただのテキストファイルなのに
#その前にWinのメモ帳しか使わないってのやめて欲しい。
こういったユーザが大量にいる限りSJISとEUCが混在する
状況は続くでしょうねぇ
0176login:Penguin01/11/03 10:58ID:mF3ySVcJ
>>175
バグと判断するバカは放置するとして、
テキストファイルの形式統一するのが普通であ?
最近だと、特に必要が無いかぎり SJIS、CRLF改行、拡張子.TXT
にするもんでない? (多数あわせ)
0177login:Penguin01/11/03 11:09ID:FDfHjWDB
>>176
おれは、ファイル名の最後に文字コードを入れるべきと思う。
Linuxとかなら、hoge.euc
Macなら、hoge.sjis
Windowsなら、hoge.ms932
0178名無しさん@XEｍａｃｓ01/11/03 19:29ID:Dw5uXiEf
>175
あはは。おいらも経験したよ。そゆこと(w
そゆヤツって、なぜかエラそうなんだよな(^^;

>176
うん、基本的に shift_jis-dos にしてるけど、たまーに、
うっかり euc-jp-unix で渡しちゃうコトがあったりして…
0179login:Penguin01/11/04 00:22ID:cPtnoBo6
今時のテキストファイルで、拡張子.TXTなら、SJISじゃなきゃ文句言われてもしかたないな。
知識の無い人に合わせないとトラブルばかり。
複数用意すれば、EUCが分かる人なら、拡張子.eucの方を見るでしょう。
0180login:Penguin01/11/04 00:26ID:qR29LF7G
>>179
はぁ？
0181login:Penguin01/11/04 00:37ID:cPtnoBo6
バグとか言っちゃう人に渡る可能性のある文書についての話。
README.TXTとかあると、無条件にダブルクリックしてんでしょ？ってね。
0182login:Penguin01/11/04 01:08ID:xlW9G7Cv
つーか、なんでメモ帳は進化しないんだYO!
コード自動認識くらいしてくれ。
0183login:Penguin01/11/04 02:00ID:LLwK6UGW
UTF-8は自動認識するが？＜メモ帳
0184login:Penguin01/11/04 02:11ID:AArIKKka
進化したとしても、MSがEUCなんか気にする訳ないだろ。
0185login:Penguin01/11/04 03:29ID:ou3Z9dK2
MS はあえてそういうことを無視するからな.
消極的な囲い込みのようなものだ.
0186login:Penguin01/11/04 12:34ID:L08xAyfI
>>174
> 濁点付きカタカナだけなら後ろの31Byteでも良いが、素直に別区に追加で良いっしょ。
> 「あいうえお」に「゛゜」付きなど全組み合わせを用意してさ。
> 後から泥沼式に「か゜き゜く゜け゜こ゜」を追加する羽目になるなんて見苦しい事をせずにね。

どういうcoding systemでそれを利用するの? >>169-170の文脈で。
JIS X 0213はShift_JIS埋め込みが考慮されているよね?
# WinもMacもUnicode化で無視されるだろうが…
0187login:Penguin01/11/04 13:29ID:rDLRvc89
> MS はあえてそういうことを無視するからな.
> 消極的な囲い込みのようなものだ.

いや、脱共有プロトコル化をはかっている彼らとしては、
EUC排除は積極的な戦略でしょう。意地でもサポートしないと思うね。

そのうち Internet Explorer で EUCのページを
見れなくなるようにするんじゃないかとさえ思っている。
こないだの MSN締め出し騒ぎを見れば、奴らならやりかねん。どうよ?
0188login:Penguin01/11/04 13:44ID:L08xAyfI
Microsoftがそういう戦略を取っている事は、
MS-C/Borland C、Excel/Lotus 1-2-3、MS-DOS/DR-DOS、
MS-IME/ATOK,、Java VM、ハロイン文書で明らか。

ただ、
1. 半角かなを使ったデータ、プログラム資源の継続性から、Shift_JIS開発(by ASCII)
2. Shift_JISのみの利用
3. UTF-8への段階的な移行
は、1を除いて、そんなに悪い選択ではなかったと思う。

Coding systemが一種類しかないのは楽だから。特に一般ユーザにとっては。
DOS, Win, Macに閉じ籠ればそれで済むわけだし。
0189login:Penguin01/11/04 16:02ID:DGRCTWhd
まだLinuxでも一般ユーザ向けには、Shift_JIS用のディストリビューションが有っても良いよな。
カーネル単体で0201対応してて、半角カタカナをキー入力できるとか、
DOS/V化してあるDOSEmuやWineが最初から使えるとか、
Windowsとのマルチブートでブックマークを共有化とか、
色々敷居を低くする手法が残ってるよな。
0190login:Penguin01/11/05 20:53ID:44wU12jf
> 3. UTF-8への段階的な移行

Windows が移行しようとしている方向は、UTF-8 じゃなくて、UTF-16 の方では？

メモ帳で、「Unicode (← 実際には little endian の UTF-16」と「Unicode
big endian」と「UTF-8」が併記されているのを見ると、まるで
・Unicode は、little endian の UTF-16 がデフォールトで、big endian は
おまけ。
・UTF-8 は、Unicode じゃない
みたいだ。まあ、意図的にこうしているこうしているわけじゃなくて、little
endian UTF-16 オンリー時代の Unicode メモ帳からの、歴史的互換性からこ
うなっているんだろうけど、誤解を招くのは確か。
0191login:Penguin01/11/06 00:11ID:7lli86vQ
>>190
utf-16 っていうのは utf-8 や utf-32 なんかのエンコーディングとは
意味が違うって www.euc.jp に書いてあったけど,
どういうこと? utf-16 は surrogate pair のなんとかで, 他の utf-8 などと
同時に使えるって書いてあったような気がする. 僕は詳しくないので
誰か説明して.
0192login:Penguin01/11/06 00:38ID:qHAMS4vC
>>190
ああ、NTが採用したころは、UCS-2で行くつもりだったわけだな。
ところで、UCS-2でなくUTF-16って名前がMicrosoftのdocumentに出てくるのー?
0193login:Penguin01/11/06 16:04ID:lMX1zb5b
>> 192
UCS-2, UCS-4 は文字セット。
UTF-16 はエンコーディング。
区別しようね。

以下、説明はちょっとはしょってるので用語は不正確かもしれん。

UTF-16 ちうのは 2 バイトであらわされる範囲は UCS-4 の BMP 領域(すなわち UCS-2) の文字番号(?)をそのままコードとして採用する + それ以外はサロゲートペアで表現。

なので、混同するのは無理ないが。
まぁ、UCS-4 の BMP 以外って事実上まだなんとも、なので、現実的には UTF-16 のコード == UCS-2 の文字番号 になってるかな。
Win の UTF-16 ってサロゲートペア対応してるんだろうか？
0194login:Penguin01/11/06 22:38ID:iIXz3U3P
>>191
UCS-2, UCS-4はどの文字(合字は例外)もすべて同じバイト数であらわせる。
それに対して、UTF-8というのは、文字によって、1文字1バイトだったり、1文字6バイトだったりする。
そもそも UTF = UCS Transfer Format、UCSを通信で伝送するためなどに用いる情報交換用エンコーディング。

しかし UTF-16というのは、UTFという名をしていながら通信のためのフォーマットではなくて、UTF-8とはまったく似ていない。
むしろ UCS-2に近い、というか UCS-2の拡張。
どの文字も2バイトまたは4バイトであらわせるし、BMP領域とサロゲート領域ははっきりと分かれているので、ある文字が2バイトで1文字か 4バイトで1文字かを簡単に判別できるので、内部コードに適している。
UTF-16って、UCS-16の名のほうがむしろよかったのかもね。

>>193
> UCS-2, UCS-4 は文字セット。
> UTF-16 はエンコーディング。
確かに UCS = universal CHARACTER SET だけど、UCS-2, UCS-4はエンコーディングにも使われてるよ。

>Win の UTF-16 ってサロゲートペア対応してるんだろうか？
MicrosoftのサイトにあるOpenTypeのドキュメントによれば、OpenTypeは サロゲート対応してるようだ。
そもそもサロゲートペアに対応してないなら、UTF-16じゃなくてUCS-2だ。
019519401/11/06 23:03ID:65m4RrJp
かんちがいだった。UCS-2,UCS-4はエンコーディングには使われてないですね。
確認せずに書いてスマソ。

UCS-2を変換せずそのままエンコーディングに使った場合、それは UCS-2と呼ばず、UTF-16と呼ぶ、ということだな。
0196login:Penguin01/11/06 23:30ID:RTd7nfRF
>>194
OpenType は Apple かんどるからのぅ。
ATSUI はちゃんと対応してるらしい。

ので、MS のいう「UTF-16」が、サロゲートペアも含めてフル実装されとんかいなと怪しんでたり。
BMP領域だけだったらすべて2bytesだから、内部コードとしてはとっても扱いやすいくて、昔からやってるんだと思うのね。
けど、サロゲートペアがでてきてとたんに固定長じゃなくなったところで、実装がナニになりそうとか。
XKPとやらがそうなんだっけ？ < サロゲートペア実装
0197login:Penguin01/11/06 23:44ID:KdJ6KYbO
XKPは外字領域の独自運用じゃなかったっけ？
0198login:Penguin01/11/07 00:01ID:fD9Y8+Ov
>>196
でも サロゲートペアありの UTF-16って、Shift_JISみたいなもんですよね。
Shift_JISの場合、第1バイトは必ず、どの半角文字とも重ならない値が来るけど、第2バイトはASCII領域の文字も来たりする。
UTF-16の場合、サロゲートペアの最初の2バイトは、ほかのどの文字とも重ならない「最初の2バイト専用」の値しか取らないし、次の2バイトも同じく「次の2バイト専用」の値しか取らないので、Shift_JISよりは簡単なはず。
0199login:Penguin01/11/07 02:52ID:ZhpFSFFf
結局 Unicode は本格的に多国語を使うには向いていないってことですか?
CJK でそれぞれの国がそれぞれの国専用のグリフを使うってことで.
0200login:Penguin01/11/07 03:44ID:2zLC4FRt
>>199
どっちかというと、筋の善し悪しの話ですな。

Unicode が貶されるのは、デザインの筋が悪いからなんですね。
でも、他に多言語のことをちゃんと考えてるコード体系がほとんどないので、
今あるコード体系の中では一番多言語化に向いているとは言えよう。
# ヲレ自身は、あんな筋の悪いもんには関りたくないから
# 放置プレイだけどナー :D
0201login:Penguin01/11/07 04:56ID:/7clxDed
Unicode は han unification してまで 2byte 固定長にこだわったはずなのに、
それが不可能ってようやく判った瞬間に、壮大なる失敗としてその使命を終える
べきだった…。Unicode 3.x はやめてくれ〜。あの仕様じゃ、ISO-2022 のほう
がまだ実装が楽だぞ。
0202login:Penguin01/11/07 15:27ID:FmMqLr+t
Unicode なら大変で ISO-2022 なら楽なことなんて
ほとんどないと思うけどねえ。
Unicode で大きな breakthrough が実現するわけじゃ
ないけど、同じ苦労をするんなら、Unicode のために
労力を使ったほうが将来性があるでしょ。
0203login:Penguin01/11/07 15:42ID:wu03UBOh
一方で　Unicode だと簡単と思っている欧米人もいるからね。
BMP だけあつかってもちゃんと実装するのは大変だと思うけど。
0204login:Penguin01/11/07 16:48ID:FmMqLr+t
Unicode ベースで、自分の言語で困らない程度の処理だけ
しておいてくれればそれでいーんですよ。
他国語も処理したい人がいたら、その人が欲しい言語に必要
な処理を加えりゃいい。8 bit through なだけのソフトを
Shift_JIS とか EUC-JP 対応に書き換えるより遙かに楽なん
じゃないか?

日本語のことだけ考えてると Unicode って楽だよね。combining
character も surrogate pair も普通はいらないだろうから。
0205login:Penguin01/11/07 17:06ID:t1r6lxkM
なんでi-modeはシフトＪＩＳになったの？
0206login:Penguin01/11/07 17:11ID:o3LWW9bh
半角カナが使えるから。
つーのは冗談にしても、規格考えたのがズブの素人なんじゃなかったっけか。
0207login:Penguin01/11/07 17:17ID:BqexFMm1
>>206
つまりドキュソが作ったドキュソ向けサービスってワケだな(w
0208login:Penguin01/11/07 18:29ID:/Lwa9nOE
205 名前：login:Penguin 投稿日：01/11/07 17:06 ID:t1r6lxkM
なんで2chはシフトＪＩＳになったの？

206 名前：login:Penguin 投稿日：01/11/07 17:11 ID:o3LWW9bh
半角カナが使えるから。
つーのは冗談にしても、規格考えたのがズブの素人なんじゃなかったっけか。

207 名前：login:Penguin 投稿日：01/11/07 17:17 ID:BqexFMm1
>>206
つまりドキュソが作ったドキュソ向けサービスってワケだな(w
020919901/11/07 19:05ID:u4pcDQi5
確かに簡単にどの国でも使える soft を書こうとか,
自国の一ヵ国語だけ使えればいいと考えると(ほとんどの人はそうだが),
Unicode も利点があるかも. 欧米人が推進するのは
簡単に internationalize できるからか.
しかしそのせいで漢字文化圏の多国語共存が余計遠のいたような気がする.
0210login:Penguin01/11/08 00:10ID:/qmyo2E8
>>187
そういえばIE5.5 以降だと、charset を指定していないウェブページはShift_JISとして
認識するのがデフォルトになってたよね、確か。
それまでは「日本語（自動選択）」だったのに、ありゃ不便。
0211login:Penguin01/11/08 00:33ID:wFCDcGAs
コードとソフトのマルチリンガル化は直接の関係が無いように
思うが。最近のはリソースレベルで調整効くんじゃねえの?
DQNなソース以外は。
0212login:Penguin01/11/08 00:40ID:axW1aL0x
fgetc(3), ungetc(3)レベルでも、Unicodeでいくには一工夫が必要です。
0213login:Penguin01/11/08 01:49ID:RN8xlcoh
イッ、イクゥー
0214login:Penguin01/11/08 01:55ID:7e4OhXHU
>>212
だーかーら、Cを使わなきゃいいの。
イヤな例だがNTでエクセルのVBAいじってる
やつらのソフトでさえあっさりUnicode.
0215login:Penguin01/11/08 03:09ID:FiqqyvvZ
>>210
そりゃアホな仕様ですな. というかもはや作意的な
脱共有プロトコル化. ゆるせんな.
super power が悪の帝国になるというのは映画の典型だが,
MS はそのまま地でいっている感じ.
0216login:Penguin01/11/08 07:37ID:dq+tXvEy
>>205 >>206 >>207

憶測にすぎんが、
元々の端末が内部コードとして SJIS 使ってた。
↓
DoCoMo から imode 端末試作の要請が来て、
何も考えずに端末屋が作った。
↓
作ったやつの実装からそのまま仕様を起こした。

ちゅう流れでは ?

DoCoMo って、
暴走する前線 (とらば〜ゆからとらば〜ゆな
前線指揮官と、売りまくりの販売店) と、
全てを放置することしかできん総司令部と、
間で苦労する兵站部 (サーバ強化したり、
ゲートウェイでいわゆる i-mode 絵文字が
外に出て行かないように〓 ( 2 区 14 点 ) に
変換したりとかさ) って構図に自分には見え
0217login:Penguin01/11/08 10:51ID:kpRhpY+R
>>205
Windows上でコンテンツ作成するのに楽だから。

・・・と聞いたけど、理由後づけしただけなんじゃないかって気がしてきた（ｗ
0218login:Penguin01/11/12 19:53ID:yqlF4e/+
面白かったのに止まっちゃってやんの。
0219login:Penguin01/11/12 22:32ID:9uypxnba
>>210
IE6だとEUCなページもJISなページもちゃんと見えるぞ。
エンコードを「自動選択」にしただけで。

>>214
あっちは高度なレイヤの言語に属するものなので、裏での文字コードは
どれでも大丈夫という例ですな。Cみたいに低レイヤのI/Oが存在し得な
い（できない）し。

>>216
iモードのプロトタイプ版がWindowsアプリケーションで作られていて、
それなりに評判が良かったので裏のコード体系が何も変更されずそのま
ま広まってしまった。
0220難しい…01/11/13 00:46ID:lJpK2uoN
日本語基礎用語
ttp://www.geocities.co.jp/Hollywood/1751/JISknown.html
これってどうなんでしょうか。

国の公式文書はJISのみとか決まってるんですか？
日韓W杯の人達は何で文書やりとりしてるんだろう？FIFA公用語のみ？
0221login:Penguin01/11/13 02:09ID:AR1g3sje
jis っていっても文字コードとしての jis と
エンコーディング法としての通称 jis があるな.
0222login:Penguin01/11/13 02:38ID:xnt/q9m2
UnicodeだってJISだし。
0223login:Penguin01/11/13 05:11ID:yK//wqHP
どれが符号化文字集合一般の問題で、どれが Unicode 文字集合特有の問題なんですかぁ？
0224login:Penguin01/11/13 08:21ID:UUYcq+J/
>>220
たぶんこれを根拠にJISコードで官公庁向けにドキュメント（完成図書）
を提出したら「読めない」と一蹴される可能性が大きいな・・

ちなみに俺が仕事をした範囲で言うと、官公庁向けに最終的に納品する
ドキュメント（完成図書）は紙に印刷したものが基本だが、電子文書と
して納品する場合はMicrosoft WordフォーマットかAdobe Acrobatフ
ォーマットが基本で、当然の事ながらそれ以外のフォーマットで提出す
ることは官報で告示される工事仕様から外れたものとなってしまう。
0225login:Penguin01/11/13 08:47ID:xshmouS0
>>220
ヲレが評価を書くのは簡単だが意味ネーので。

規格票とかの 1 次文献と、ゴミ山の 2 次文献と、
ともかく片端からツキ合わせて検証するしか。

JIS はハンドブックじゃなくて規格票の方。常識
0226login:Penguin01/11/13 09:57ID:55puEBGN
>>225
> JIS はハンドブックじゃなくて規格票の方。常識
内容違うの?
0227login:Penguin01/11/14 01:34ID:7VltrDCU
>>226
JIS ハンドブックに規格の解説ってついていたっけ?
0228login:Penguin01/11/14 03:02ID:bsExAIai
>>226
ハンドブックは、規格票の抄。fontも違う(w
0229名無しさん＠お腹すいた。。01/11/15 02:10ID:OJKAB9zc
Ｓｈｉｆｔ−ＪＩＳウザイ！！
こんなものがあるから、厨房が増えると思う。
こんなものがあると、日本人は余計に馬鹿になると思う。

※私も　Ｓｈｉｆｔ−ＪＩＳあぼーん　に１票！

しかも、MS社は商売が上手すぎるせいで、
Ｓｈｉｆｔ−ＪＩＳが余計に普及しすぎてしまう。
もともとMS社が考えたShift-JISは、Macでも使われてきている。

自分はMS社は好きだけど、Ｓｈｉｆｔ−ＪＩＳは嫌い。

Ｓｈｉｆｉｔ−ＪＩＳなんかよりは、Extended Unix Code(EUC)が(・∀・)イイね。
それに、インターネット上でSJISは向かない。

UNIX系のOSを使うと、本当にためになると思う。。頭よくなるよ。
逆に、日本でWindowsを使っていると、馬鹿になる可能性がある。

Netscapeで色々なサイトを見てみることが有るけど、
IEに最適化されたページが多すぎて、Netscapeでは
正常に表示できないものがある。
それは、インターネット上に、色々なコンピュータが混在してることを
知らないような厨房がいるからだと思う。
(皆、Windows＋IEにばっかりだと思っているのかなぁ？)

UNIX系のOSを使うようになってくれば、インターネット上に、
色々なコンピュータが混在していることを知ることが
できるようになるのではないだろうか？

Windowsばっかりにとらわれず、ほかのOSを使ってみるというのも良いことでしょう。
EUCという文字コードは、今まで「コンピュータ=Windows」だと思って
いた人に、「コンピュータにもいろいろ有る」ことを
意識させてくれるのではなかろうか？

自分は、まだWebページは作り終わっていませんが、
作成する時は、いろいろな環境で、正常に表示できるように
作りたいと思っています。
(日本語の文字コードは、 JIS を使う予定なのですが・・・)

おっと！長文失礼しました！
自分は、このように考えているのですが、どうでしょうか？
0230login:Penguin01/11/15 02:16ID:noyWS/iX
これって突っ込まれることを期待してワザとやってんの？
0231login:Penguin01/11/15 02:19ID:r2ItaT6s
本気でつっこんであげて下さい. >>230
0232そいじゃ突っ込み01/11/15 05:10ID:PMzBmxUW
> 自分はMS社は好きだけど、Ｓｈｉｆｔ−ＪＩＳは嫌い。
> 逆に、日本でWindowsを使っていると、馬鹿になる可能性がある。

じゃあ 229 はもう馬鹿になってるな(藁
■ このスレッドは過去ログ倉庫に格納されています