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

EUCボクメツ委員会

■ このスレッドは過去ログ倉庫に格納されています
0001モ・ク・ヘ・ケ菽ヲッ01/10/16 00:18ID:ZujZqkcr
Javaとかのマルチプラットフォームなアプリでも文字コードをいじらないと化けるし。
ICQクローンで Shift_JIS<=>EUC の相互変換をするように加工とか小細工して使ってるのには泣けたYO
せっかく多言語対応の環境で作られたソフトでも日本ローカルのパッチ作んなきゃいけないんじゃ
意味ないじゃん!
Winに比べて少ないアプリがさらに選択肢が狭まっちゃってどうしようもないYO
Linuxにおける日本語の標準コードはWinに倣いShift-JISをメインにすべきである。
0002login:Penguin01/10/16 00:24ID:2cXXFpCZ
EUCでもSJISでもUNICODEでもいいから
はよ統一して欲しいね。
0003login:Penguin01/10/16 00:24ID:9B4PVJPA
みんなutf-8に移行したら幸せになれます
0004login:Penguin01/10/16 00:27ID:NZ0m+3Nq
シフト JIS 氏ネ。欠陥コンコーディング。
0005モ・ク・ヘ・ケ菽ヲッ01/10/16 00:29ID:ZujZqkcr
現在の会員数 :3人
0006login:Penguin01/10/16 00:32ID:oDnFuGnj
そうそう、SJISが死んでeuc or JISになればよい。
0007login:Penguin01/10/16 00:42ID:uxyGYFYO
SJISアボーンに一票。
0008login:Penguin01/10/16 00:47ID:rUwtIh7k
jis x 0208
jis x 0201
ISO-2022-jp/kr
0009login:Penguin01/10/16 00:56ID:W0yrYiw7
UTF-8 は言わば文字コードの一枚岩カーネル。世界中の文字をひとつの体系に。
EUC は言わばマイクロカーネル。言語ごとにモジュール化。
SJIS は言わば日本語だけの一枚岩。日本語と英数字が世界のすべて。
0010login:Penguin01/10/16 00:58ID:+wbgAKJH
>>1はヒッキー
0011login:Penguin01/10/16 00:59ID:SUWKfT51
>>9
中国語(繁体字)はUTF-8で網羅できるんだっけ?
0012login:Penguin01/10/16 00:59ID:TsMc1BOC
>>9
日本そのものって感じだね>SJIS
0013login:Penguin01/10/16 01:01ID:0iRzhq4a
どうでも良いけどSJISはメーカや環境ごとに違うので糞です。
>>1はWindowsだけずっと使ってください。
0014901/10/16 01:03ID:W0yrYiw7
オレが特に強調したいのは SJIS は「切り替え」の余地が残されてないこと。
UTF-8 もそうだから根強い反論がある。
0015login:Penguin01/10/16 01:04ID:SUWKfT51
よく考えてみると
Shift-JIS - Windows,Dos,OS/2,Mac
JIS - TRON?
EUC - Linux,HP-UX,Solaris,AS/*,FreeBSD,BSD/OS,NetBSD
どれが多いだろうか?
あと、>>13の言う通り。
0016901/10/16 01:05ID:W0yrYiw7
Windows は特に NT 系で UTF-8 に統一されつつある傾向だがな。
1 はそれを知ってるのかな。
0017login:Penguin01/10/16 01:05ID:yZY6sng4
同じくSJISアボーンに一票。
俺はeucでイイ。
0018login:Penguin01/10/16 01:10ID:W0yrYiw7
Java も UTF-8 だぞ。
何で 1 みたいなのが Linux 板にいるんだ。
0019login:Penguin01/10/16 01:11ID:rUwtIh7k
>>18
ソースとかリソースのことじゃないの?
0020UCS4キボンヌ01/10/16 03:14ID:4zfTGCvs
>Windows は特に NT 系で UTF-8 に統一されつつある
UCS2でしょ。COleStringの内部で盛んにUCS2.
将来、負の遺産になりそ。
0021login:Penguin01/10/16 03:38ID:aWaNxseP
tron-codeってのはどーだ?
出ない字がないんだろ?たしか
0022login:Penguin01/10/16 03:42ID:W81ZfPKp
SJIS なんつーメンドーなエンコーディングはステ
0023login:Penguin01/10/16 03:53ID:devEzPX4
>>21
同じ文字とは何か?定義してないから、
databaseやgrepで困ると思われ
0024login:Penguin01/10/16 04:23ID:4zfTGCvs
>同じ文字とは何か?定義してないから、
>databaseやgrepで困ると思われ
2ちゃん見てるとわかるけど、富士通→富士痛といった
あえて検索性の悪い表現を狙って行うのが人間というも
のだろう。政治家の「善処する」が「何もしない」を意
味する国の人間としてはおそらく逸脱の速度が定義の作
業スピードを追い越すだろうと思われる。
0025login:Penguin01/10/16 04:44ID:N1gEmB5d
>>24
>2ちゃん見てるとわかるけど、富士通→富士痛といった
>あえて検索性の悪い表現を狙って行うのが人間というも

ただのあほ。
0026login:Penguin01/10/16 05:34ID:W81ZfPKp
>>24
それは単なる2ちゃん用語だろ
0027login:Penguin01/10/16 06:19ID:4zNPHE9n
そもそもなんで Shift_JIS なんつー
うざいものができたんだ?
誰か教えてくれ。
0028login:Penguin01/10/16 07:02ID:xR9dpqTG
半角カナ使いたかったから。
0029login:Penguin01/10/16 07:51ID:XM6EXXtB
>>27
EUCとJISに欠陥があるからって言ってた気がする。
0030login:Penguin01/10/16 08:02ID:0RDEkWSQ
つーかEUCにしろSHIFT_JISにしろ、計算機資源の乏しかった
ころの規格だろ。
富豪的コンピューティングでTRONでいいじゃん。
UNICODEもステだな。
0031login:Penguin01/10/16 09:15ID:10niM3hA
っていうか、なぜEUCにこだわる人ってなぜそんなものにこだわる?
理想を求めるならTRON-CODE
今現に多く使われているという現状を追認するならS-JIS
EUCにはどっちの利点も無い。
0032うひひ01/10/16 09:21ID:so9BFYxc
むずかしいことイイからよ
shift_jisバリバリのLinuxあっても良いんじゃねーか?
shift_jisのUnix使ってると連携わりーんだよな実際。
0033login:Penguin01/10/16 09:37ID:Gyb/MKxi
>>31
人生に妥協は必要だよ。
0034login:Penguin01/10/16 09:43ID:devEzPX4
>>31
> っていうか、なぜEUCにこだわる人ってなぜそんなものにこだわる?

m17nに有利だからだろ。
0035login:Penguin01/10/16 11:47ID:W81ZfPKp
>>29
ハァ? 逆だろ。
まず ISO-2022-JP があって、モード付きのエンコーディングだと
プログラムが書きにくいから ShiftJIS が作られた。
でも ShiftJIS は半角カナを 1 バイトの領域に入れてしまったために
一部の記号と日本語のコードがダブってしまって、それを例外として
処理する必要があった。
その辺を教訓として EUC-JP が作られたから、日本語と英数字の
領域は完全に分離されていて最も扱いやすく、I18N に有利である。
0036続き01/10/16 12:51ID:7rh/WYyT
結果、半角カナは2バイトで、外字は3バイトである。
文字コードの何たるかを考えた事もない
ヘタレプログラマにはただただうっと惜しいだけであった。
0037login:Penguin01/10/16 12:50ID:uARHilua
>>35
なんか違うぞ

ISO-2022-JP はそれまで慣習として通信で使われてた7bitJISコード
(ISO-2022にそこそこ準拠)を、fj.* と Internet Mail で使うものとして、
制限つけてRFCとして書き起こしたものだ。名前に反して実は ISO-2022 に
正確には準拠してないのは有名だ。7bit JIS としてなら歴史はあるが、
まとまったのは一番新しい。

まあ、たぶん言いたいことは「ISO-2022 が先にある」ってことなのだろう。
それなら正しい。

ShiftJIS は、Microsoft社が MS-DOSに日本語を導入するにあたって、
半角カナを残しつつ漢字コードをわりこませるためにASCII社に作らせた
もんだ。変態的な変換で気持ち悪いことと、当時既にあった国際規格の
ISO-2022を全部無視したこと以外はそんなに悪いコードじゃない。
いってる通り、不幸の文字があるので、ASCII処理前提でかかれていた
コードは全部書き直しの憂き目にあったのはそのとおり。

んで、EUC-JP は別にそのあたりを教訓にしたのではなくて、
UNIX の国際化を行うにあたって、普通に 8bit 版 ISO-2022
の使い方を日本語用に確定しただけのものだ。これは当時国内でUNIXを
作ってたメーカが、既に同等の手法で自社UNIXを国際化してたのが
細部が異なってたのを統一する形でつくられた。

ISO-2022 のままだと、ステートが爆発するので扱いにくいのは事実。
でも、SJIS と EUC-JP では、正しくまじめに国際化するのなら、質的
には有利/不利の差は存在しない。

ただ、世の中には、「ascii依存」なソースがあまりに多い。で、EUC-JP の
場合、コードが重ならない関係で、8bitスルーにさえなれば、日本語が
壊れず通ってしまう。こういった「手抜き国際化」は EUC-JP のが
やりやすいのは確か。

ちなみにこの条件は UTF-8 も同じだ。だから、最近のあちらさんの
アプリケーションはこれで処理したがってる。ソースをあんまり
修正しなくて良いってことね。

UTF-8 は、互換性は目をつぶるとしても、日本語だけを扱うとしたら
パフォーマンスが悪くなるのと、通信量が膨れ上がるのが欠陥
(漢字は6byteになる)。まあ、マシンパワーの向上が全て解決すると
いわれればそこまでやね。
00382101/10/16 14:42ID:aWaNxseP
>>23
>同じ文字とは何か?定義してないから、
>databaseやgrepで困ると思われ

これは運用の問題だろ?
斎藤と斉藤と齋藤を区別したいときもあれば同じに扱いたい時もある。
なら別々にして必要に応じて変換ライブラリーみたいなの使えばいいと思うぞ。

しかし37読むとEUC-JPかUTFがいいような気がする
0039login:Penguin01/10/16 15:21ID:pLM2+efM
不治痛だろ?
00403701/10/16 15:33ID:uARHilua
結局のところ、マルチバイトキャラクタな状態ってのは、
文字の区切りがよくわからんところが最大の問題で、SJIS で \ を
誤認してしまうのもこれによる。EUCも、結局頭からおいかけないと、
文字の区切りはやっぱりわからん。

てっとりばやくこれを処理するには、ワイドキャラクタ化してから処理
してしまえばよいことになる。この場合、EUCだろうがSJISだろうが関係なくなる

ただ、これをするにはアプリケーションを全部 wchar 用に書き直す必要が
あって、めんどくさがられてる。その点、UTFは、EUCとかと違って、文字の
区切りが一発でわかるようなエンコーディングなんだな。
今見てる場所から、「前の文字」「次の文字」がわかるようになっている。
基本は char のままで、文字処理するとこだけ細工いれればよいので好まれるわけ。

ちなみにこれには罠があって、Unicode がホントに Unicode なら
問題なかったんだけど、Unicode って Unicodeだけでマルチバイト文字
になるので (UCS2/UTF-8 で複数のコードで1文字になる複合文字がある)
そういった文字を扱おうとすると一瞬で破綻してマルチバイト時代に逆戻り。

まあ、欧米の人はこれでこまらんのだ。そんな複合文字なんてつかわんから。
日本人は無縁じゃないぞ。濁音は、処理次第では2つのコードに分離するのだ…
0041login:Penguin01/10/16 17:54ID:dew/Ir09
マルチバイト文字なんか使ううちらが悪い。
外人から見れば英語最高!で国際化なんかやってらんないよ
外人に感謝しよう
0042名無しさん@お腹へった。01/10/16 18:09ID:h02cohTC
SJISを完全に捨てているVineは糞。
って今はどうなの?

PJEの頃は少しましだった気がするが..
0043login:Penguin01/10/16 18:48ID:Gyb/MKxi
>>41は微妙にスレ違いだな・・・

>>42
完全に捨てているというtと、具体的には?
0044>>4101/10/16 19:21ID:OnoFABDw
>>41
誇りを持て
0045login:Penguin01/10/16 19:38ID:q4n1GyJy
情報交換符合と内部表現、
文字セットとエンコーディング、
コードとグリフ、

区別してしゃべってくれ。
■ このスレッドは過去ログ倉庫に格納されています