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

EUCボクメツ委員会

■ このスレッドは過去ログ倉庫に格納されています
0001ﾓ･ｸ･ﾍ･ｹ菽ｦｯ01/10/16 00:18ID:ZujZqkcr
Javaとかのマルチプラットフォームなアプリでも文字コードをいじらないと化けるし。
ICQクローンで Shift_JIS<=>EUC の相互変換をするように加工とか小細工して使ってるのには泣けたＹＯ
せっかく多言語対応の環境で作られたソフトでも日本ローカルのパッチ作んなきゃいけないんじゃ
意味ないじゃん！
Winに比べて少ないアプリがさらに選択肢が狭まっちゃってどうしようもないYO
Linuxにおける日本語の標準コードはWinに倣いShift-JISをメインにすべきである。
0102login:Penguin01/10/19 23:03ID:dckKBkBJ
4バイトでUniqueになればいいじゃないか。
0103login:Penguin01/10/20 06:16ID:g2GqcdkH
どうやら、このスレには、ちゃんと理解しているのが３人しかおらず、
それ以外はコード表（どれか１つでも）も見たことがない奴らだけの
ようだ
まだ、青木光恵の旦那の方が３８倍ましって感じ
0104ななしさん＠おなかいっぱい01/10/20 07:28ID:a3ky6FMM
>>103
「ちゃんと理解している」のが3人もいれば2ch的には充分のような気も。
あと、そーいうことをいう人には、どのポストに正しいことが書いてあるの
か指摘してもらえると嬉しいかな、とか。
0105login:Penguin01/10/20 11:51ID:mRQL8QGY
>>56
やっぱり謎の中国人に「アイヤー、漢字特盛りにしちゃうアルヨー」
と言わせてほしかったな。
0106login:Penguin01/10/20 13:09ID:2B2NfqxB
>>102
それについては、>>65の言う通りで、>>56が詳しい(w
「もうUnicode捨てたいんと違うんか？」と小１時間問い詰めたい。

http://euc.jp/i18n/ucsnote.ja.html
Unicodeの安易さが持ち込んだ問題で、10646が腐るのは困る。

<!-->>102はHan Unificationの問題「だけ」を言っているのかな？-->
0107login:Penguin01/10/20 16:11ID:8ZJLlTqR
このスレッド面倒だから読んでいない。
重複する内容だったら失礼。

シフトジスになぜしないかというとシフトジスには欠点があるから。
その代表的なものは0x5c問題。
0x5cはダブルコーテーションという記号だがシフトジスの漢字はこれを含む
漢字もある。
アスキーコード0x5cが文字列に入っているとシフトジスはおかしくなる。
プログラムでこの問題を回避する処理を入れないといけないがそれは大変だ。
実際、WINDOWS版のソフトでこの問題を回避できていないソフトは多い。
EUCだと、8ビット目を殺さないようにするだけで無変更でコンパイラなどが
日本語をソースに入れても問題なく使える。
それによってgccなどは英語版そのものを使ってもEUCなら日本語を入れたソース
をコンパイルできる。
しかしシフトジスだと0x5c問題にかかるので改造しないと使えない。
改造しても行の先頭から順番に読んでいかないと半角か全角か判断できないと
いうシフトジスの大きな欠点のため速度が遅くなるという欠点が出る。
仮にシフトジスに変えてしまうとほとんどのLinuxソフトが日本語使えなくなる。
かといってシフトジス対応という膨大な作業を誰がするというのだろう。
シフトジス対応すると本家と英語版とソースが分岐するので古いバージョンを
使わざる得ないとか不都合がたくさんでる。
結果的にシフトジス標準は不可能だ。こんなことはプログラマーならわかると思うが 1 はユーザー専門なんだろう。
0108login:Penguin01/10/20 17:52ID:cvBqh8vR
このスレ案外詳しいよ. スレッド名に反して役に立った.
0109login:Penguin01/10/20 17:53ID:n/co2nXu
文字の割り当ての正当さなんぞ気にしていたら
あと何百年かかるかわからんだろ。
「てめーら勝手にしろ」でコード領域広く取って
各地域24ビットぐらい割り当てちまえばよい。
で日本では従来のJISを突っ込んで終わり。
グリフだのなんだのとわめいていたら、孫の代まで
に完成しねえぞ。
0110login:Penguin01/10/20 19:04ID:2B2NfqxB
>>109
それで解決するのは、Han Unificaionだけで、
http://euc.jp/i18n/ucsnote.ja.htmlの問題はどんどん拡大する。
# 各国内での互換性を維持できたわけだし、>>109はそれでもいいと言っているのだろうが。

しかし、以下は妥当な文字非統合だろうか？(上のURLから一部だけ抜き出した)
U+002D HYPHEN-MINUS (ASCIIのマイナス)
U+00AD SOFT HYPHEN 語中の折り返し可能個所、表示されないかもしれない
U+2011 NON-BREAKING HYPHEN (右端でも折り返されないハイフン)
U+2010 HYPHEN 複合語などの一般的なハイフン
U+2212 MINUS SIGN マイナス
:
互換性を求めて既存のを無制限に突っ込んだ挙げ句がこれ…
0111login:Penguin01/10/20 19:11ID:DsyBUQBQ
>>110
それでもいい。
それは子孫の時代に解決する問題。
現状では再コンパイル一発で将来の文字コードに
対応できるインフラの整備が大事だと思う。
0112login:Penguin01/10/20 19:48ID:XktlMTUg
>>107
>このスレッド面倒だから読んでいない。
>重複する内容だったら失礼。
こういっちゃなんだが、すでに、ビット並びの字面(とでもいうのか?)の話はし
てないです。

ワイドキャラクタを使用しない、m17nな独自内部コードとしては、開発効率の観点
からビットの字面が大事(UTF-8を使わざるをえない)なんていう話はでたけど話
のレイヤがかなり違う。

>シフトジス対応すると本家と英語版とソースが分岐するので古いバージョンを
>使わざる得ないとか不都合がたくさんでる。
localeとはなにか？と、mbstowcs関数をはじめとした、ワイドキャラクタを
利用したプログラムの書き方でも覚えてくれ。

すると、分岐せずに(=localizeせずにinternationalizeすることで)Shift_JIS
に移行できなくはないことがわかる。ソースコードは改変する必要はあるかも
しれんし（本家に統合は可能だろう）、OSのlocaleまわりもいじらないとい
かんかもしれないが。

蛇足だが、
何度か言われているが、character set と encoding を区別してくれ。
ISO 2022 とはなにかを理解してくれ。暇があれば UCS, UTF とはなにか
を学んでくれ。書籍もいくつかでてるが、まずは http://euc.jp/ を読む
とよい。

理解した上の発言ならすまん。
0113login:Penguin01/10/20 21:03ID:7W8DCi3g
>>110
文字コードと文字集合を世界で統一しようという
アイデア自体には大賛成だが、ここまで致命的な問題点を
見せられると困るな。
日本だけを見てもこの状況だから、他の諸外国でも
いろんな問題があるんだろうな。
ほんと孫の代になるまで解決しそうにないな。
漏れが現役の間は EUC-JP で頑張るしかないかな。
0114login:Penguin01/10/21 01:58ID:3nI2LT/o
Flashの日本語が読めないのは誰のせい…
0115login:Penguin01/10/22 00:36ID:vff311A1
結局, 中国語と日本語を両方ともまともに使う人から見て,
Unicode の CJK Unified は満足できるものなんでしょうか?

結局どっちかをメインとして使わないと文面の字面がキモくなる
ような気がするんですが.

それなら Emacs で ISO 2022 で違う font を使って表示した方が
ましのような.
0116login:Penguin01/10/22 07:46ID:EJ6V2X5S
16bitに無理矢理収めたくてUnifyしたのに、
>>56にあるように9万(>2^16)字になっちゃったんです。意味ないんですぅ
Unifyの意味ないのに、UnifyされたのがISO 10646.1(>>65)になっちゃったんですぅ
しかも>>110にあるように漢字以外のUnifyの基準が使いものにならないですぅ
Unicodeは文字コードの世界に新しく増えた負の遺産なんですぅ

//最近のtechnical reportは面白いのあるけど。
0117login:Penguin01/10/22 08:00ID:RZQUGhKz
Emacsの内部コードって何つかってんの?
0118login:Penguin01/10/22 09:01ID:7trpRy3z
HTMLってSJISは論外としてEUCとJISのどっちで書くのがいいの？
0119login:Penguin01/10/22 09:08ID:Pupx5KWC
>>118
あんまり考えずに全文検索とかするためにはバッティングしない
EUCの方が楽なんじゃない？
0120login:Penguin01/10/22 13:05ID:U0CK64Pe
iso-2022-jpでしょ。>>118
0121login:Penguin01/10/22 13:28ID:w9iNU5fE
ネスケの 4.x だと
たまに ISO-2022-JP を認識できないことがある。
ネスケのバグ?
0122login:Penguin01/10/22 15:33ID:cV0J5a3p
charset= が間違ってるとかじゃなくて？
0123login:Penguin01/10/22 15:54ID:dRSBo2ui
>>120
根拠は?
0124login:Penguin01/10/22 17:12ID:uLX7lQZs
surrogate して使う文字は utf-8 で encoding すると普通の
漢字より byte 数を食いますか?

あまりかわらないんだったらそっちにいろいろ文字入れれば
Han Unification も救いようがあると思うんですけど.
0125login:Penguin01/10/22 18:36ID:WlYpkgCt
>>118
ちゃんとコード指定するならSJISでも全く問題ないよ。
俺は各種処理が楽なので、今のところ EUC-JP 使ってる。
0126login:Penguin01/10/22 18:52ID:+lMZ2zFA
>>125
ちょっと問題あるかもね。
charset=Shift_JIS は文字セットが曖昧だから:)

とはいえ、Windows-31J とか書いても理解してくれるブラウザは…
>>123
漢字コードの自動判別がしやすいからでしょ。
そもそも charset 書かないのがよろしくないんだけどさ。
0127login:Penguin01/10/22 21:30ID:WlYpkgCt
>>115
RTF とか HTML とか XML とかマークアップ言語使って
ラッピングして使うってのがもう実用的につかわれてるよん。
さらばプレーンテキスト。一回 Outlook とか使ってみそ。よくできてるから。

あ、プレーンテキスト用の「言語タグ」ってのも一応表にはのっかってる
けど使うなって書かれてます。わはは。

Solairs の UTF版　Motif の実装も似たようなことしてるはず
だけど使ったことないから詳細不明。あと、GTK で pango が UTF-8
ベースなんだけど、こいつもオリジナルのマークアップかけることで、
ちゃんと「多言語」処理できるようになってるね。

もう世の中の流れ的には、少なくとも新しいものを実装する上では、
困ったところをうだうだ言うフェーズは終わってるといえるかもね。
0128login:Penguin01/10/23 12:54ID:CcIiXv/t
>>124
RFC 2044 からいんにょー:
UCS-4 range (hex.) UTF-8 octet sequence (binary)
0000 0000-0000 007F 0xxxxxxx
0000 0080-0000 07FF 110xxxxx 10xxxxxx
0000 0800-0000 FFFF 1110xxxx 10xxxxxx 10xxxxxx

0001 0000-001F FFFF 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
0020 0000-03FF FFFF 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
0400 0000-7FFF FFFF 1111110x 10xxxxxx ... 10xxxxxx

つまり、BMP 内だったら最高でも 3 オクテット、
surrogate pair が必要な文字(U+10000〜U+10ffff)は 4 オクテット。
012912401/10/23 15:41ID:ODoryf+d
>>128
したらやっぱり surrogate pair に jisx0208 をまるごと入れて
使うというのは実用的じゃないですね.
0130UNIFYダメ01/10/23 21:36ID:TioyS6YQ
http://news.2ch.net/test/read.cgi/news/1003826777/

統合など不可能。
できもしないことを高望みしないほうが良い。
0131login:Penguin01/10/24 01:13ID:eNcfec5S
>>118
wget でwebページを取得するとき、ISO-2022-JPでHTML書いてあると
うまく取得できない。 wgetがASCII前提のソフトだからだけど。
EUC-JPで書いてあるのがいちばんいいと思う。
0132login:Penguin01/10/24 02:14ID:mCLLGjB8
>>131
んなこたーないだろ
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 のほう
がまだ実装が楽だぞ。
■ このスレッドは過去ログ倉庫に格納されています