857コメント312KB

EUCボクメツ委員会

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

0001ﾓ･ｸ･ﾍ･ｹ菽ｦｯ

01/10/16 00:18ID:ZujZqkcr

Javaとかのマルチプラットフォームなアプリでも文字コードをいじらないと化けるし。
ICQクローンで Shift_JIS<=>EUC の相互変換をするように加工とか小細工して使ってるのには泣けたＹＯ
せっかく多言語対応の環境で作られたソフトでも日本ローカルのパッチ作んなきゃいけないんじゃ
意味ないじゃん！
Winに比べて少ないアプリがさらに選択肢が狭まっちゃってどうしようもないYO
Linuxにおける日本語の標準コードはWinに倣いShift-JISをメインにすべきである。

0403login:Penguin

02/11/29 12:40ID:raYwjZ0J

>char s[] = {0x82, 0xA0, 0x10};

なぜ \0 で終端しない?

>そもそもL'あ'なんてロケールko_KR.eucKRの時に意味を為さないもん。

xfd -fn '-*-ksc5601.1987-0' してみろよ?

0404login:Penguin

02/11/29 14:22ID:MQGqKzTm

> なぜ \0 で終端しない?
入力ミスでつ、失礼。

> xfd -fn '-*-ksc5601.1987-0' してみろよ?
おお、KSC5601とかGB2312、BIG5あたりにも平仮名ってあったのね、Thx.
じゃー s/ko_KR.eucKR/ru_RU.KOI8-R/とでもしとおきまつ。

0405login:Penguin

02/12/01 05:03ID:wdAcIpdA

0406login:Penguin

02/12/15 02:05ID:Ra09IIC2

血液型の存在意義ってあるんでしょうか？

0407login:Penguin

02/12/15 04:06ID:JcBJBO9o

overload? pcが燃えたりしない？

0408login:Penguin

02/12/15 04:35ID:95NNaRk1

ところで、何で ShiftJIS は M$ が作ったことになってるの？

0409login:Penguin

02/12/15 21:24ID:7gUpNzER

>>408
ASCIIがMS-BASIC, MS-DOSのために考えたから。

0410login:Penguin

02/12/16 01:54ID:bS9goAzK

文字（漢字なども含めて）をアトミックな情報と考えずに、
バイトの列と捉えること自体が、既に既存のASCII的
英米中心主義に足をとられている証拠だ。文字の実現が
何バイトであるかを知らずとも、char が文字１つを
あらわし、文字は何か特別な処理（函数を呼び出すなど）を
しないかぎり、内部構造を見られないものとして、プログラムが
かけなければ、いつまでたっても、ぐちゃぐちゃのいきあたり
ばったりでわけのわかりにくいソースコードの地獄から抜け出られないよ。
実数（単精度でも倍精度）でも、通常は、内部の二進表現がどうであるか
を気にしなくてもプログラムがかけるように、文字も内部で同表現されて
いるかによらずにソースプログラムがかけるようなインフラの土台を
作るべきなんだ。
　そのためにも、一番適当なのは、いまや３２ビット固定幅の文字であり、
従来のシステムからの移行の便宜を考えるならば、コンパイラには、
ソースがどういう従来の文字コード体系でテクストとしてかかれているかを
オプションとして引数に渡し、でてくるオブジェクトは、すべて３２ビット
固定幅の文字コードを前提とした出力とするのがよい。
　とにかく、英米以外の国々は、行き当たりばったりの変な文字コードと
その処理の複雑さや函数の仕組みなどにより、ASCIIオンリーでプログラミング
ができる場合に比べて過大ともいえる苦労を強いられてきた。バグも多くなる。
開発コストも高い。　いまや多少の性能、容量のオーバーヘッドを犠牲にして
でも、ソフトが自然に、まるでASCIIのみしかない場合のように書けて、
32ビットに収まるほぼ全世界の文字をひとつのソースで、ロケールなど気にせずに
処理できる、そういう理想郷が必要だ。
　面倒で不便なその場当たりなコードのために英米に比べて日本などの国々は
著しい文化的不利益を被ってきたし、このままだと被りつづけることになる。
今こそ、この状況を跳ね返して、英米中心主義のコード体系、計算機言語や
ライブラリーにNOといおう。
　

0411login:Penguin

02/12/16 01:58ID:CE1D5wUJ

そうなるためには僕達は具体的に何をすればいいですか？

0412login:Penguin

02/12/16 02:44ID:kZumFsPJ

>>409
MS-DOS が出る以前に ShiftJIS を見たのは幻だったのか…

0413login:Penguin

02/12/16 06:44ID:4qHLRA5W

>>410
せめて、「包接基準」程度の言葉を覚えてから書こうね。

0414login:Penguin

02/12/16 07:26ID:FwnNqLr5

>「包接基準」
この字でええんかと小一時間

0415login:Penguin

02/12/16 18:51ID:klsjmqv9

ttp://www.nara-edu.ac.jp/~inoue/sizen/kaeru/housetu.htm

0416login:Penguin

02/12/18 04:11ID:pxr5ilKA

いまや我等は従来の英米中心主義を廃すへし。

0417login:Penguin

02/12/18 04:17ID:9zCa8KtI

>「包茎基準」
萎えた状態で 3mm でも皮被ってたら包茎ですか？
カリ首が見えないとダメですか？

0418login:Penguin

02/12/21 01:50ID:EFgh3ncW

>>413

>>410
> 32ビットに収まるほぼ全世界の文字をひとつのソースで、
> ロケールなど気にせずに処理できる、そういう理想郷が必要だ。
まあ、ロケールが文字コードだけの問題と思っているようじゃ...

0419IP記録実験

03/01/08 22:08ID:+M/1sqI1

IP記録実験
http://qb.2ch.net/test/read.cgi/accuse/1042013605/

1 名前：ひろゆき ◆3SHRUNYAXA ＠どうやら管理人 ★ 投稿日：03/01/08 17:13 ID:???
そんなわけで、qbサーバでIPの記録実験をはじめましたー。

27 名前：心得をよく読みましょう投稿日：03/01/08 17:20 ID:yL/kYdMc
SETTING.TXT管轄でないということは全鯖導入を視野に、か？

38 名前：ひろゆき ◆3SHRUNYAXA 投稿日：03/01/08 17:22 ID:rLfxQ17l
>>27
鋭いです。

73 名前：ひろゆき ◆3SHRUNYAXA 投稿日：03/01/08 17:27 ID:rLfxQ17l
＞ところで、IPが抜かれて何か今までと変わることってあるのでしょうか？
・今までより、サーバが重くなる。
・裁判所や警察からの照会があった場合にはIPを提出することがある。

0420login:Penguin

03/01/09 01:25ID:0uJfVOg+

>>348悪ざない。バカだと。

0421login:Penguin

03/01/09 01:36ID:0uJfVOg+

記念カプリコ

0422IP記録実験

03/01/09 02:01ID:Eya/RVup

0423login:Penguin

03/01/09 02:09ID:I0ACnG/A

(・´з`・) ＜ひろゆきは1000狙ってるよ

0424login:Penguin

03/01/09 02:48ID:h7UDho/F

>>1さん
IPを記録しないでくださいお願いします

0425login:Penguin

03/01/09 03:31ID:mK/aEqnH

多分一ヶ月くらいで新しい掲示板が出来るんだろうな

0426山崎渉

03/01/15 11:30ID:+BGYmUVc

（＾＾）

0427login:Penguin

03/02/18 02:10ID:pSq8jkiV

保守

0428login:Penguin

03/02/24 13:15ID:xcdIcF3X

>>1
馬鹿ですか？8ビットコードをSJIS無くしてEUC統一ならともかく。

0429login:Penguin

03/02/24 14:27ID:mKA/Y3vi

>428
今更EUCに8ビットコードを統一なんて非現実的な事をいうほどは馬鹿じゃない。

0430login:Penguin

03/02/24 18:43ID:JRC7EHKD

でも、16bitに統一だ～とか非現実的なことを今でもいっているバカは欧米方面に
数多く存在する模様。

0431login:Penguin

03/02/25 14:08ID:v6xxx70E

>>1
> Javaとかのマルチプラットフォームなアプリでも文字コードをいじらないと化けるし。
> ICQクローンで Shift_JIS<=>EUC の相互変換をするように加工とか小細工して使ってるのには泣けたＹＯ
> せっかく多言語対応の環境で作られたソフトでも日本ローカルのパッチ作んなきゃいけないんじゃ
> 意味ないじゃん！
> Winに比べて少ないアプリがさらに選択肢が狭まっちゃってどうしようもないYO
> Linuxにおける日本語の標準コードはWinに倣いShift-JISをメインにすべきである。

何を言うかっ!
お主が真のJava使いならShift_JISを選ぶべきではない！
UTF-8にするはずじゃ！
XMLもUTF-8が標準なのじゃぞ！

0432おしえてくれいー

03/03/01 00:31ID:rr6x418h

ぼくもUTF-8がいいとおもう

SJISは2バイト目のコードがMSB立っていないのでやだ。

0433login:Penguin

03/03/01 01:36ID:7knwdp6R

元々、EUCってAT&Tとかが決めた国際標準じゃなかった？

0434名無しさん＠Ｅｍａｃｓ

03/03/03 12:45ID:5UTxkYrg

まだこのスレあったのかよ

0435login:Penguin

03/03/27 05:06ID:Ys6voNX5

ユー、ワカッテナイネ．
ジャップガナニヲイッテモミーニングレスネ．
アメリカンガエンコーディングヲキメルノダ．
スベテノソフトウェアハアメリカデツクラレル．
ジャップハソレヲカウダケ．
ソノカワリノースコリアヲコウゲキシテアゲヨウ．

0436login:Penguin

03/03/27 05:24ID:jeN9lawM

Shift JISは2バイト目がASCIIと重なる場合があるから嫌い。

0437login:Penguin

03/03/27 23:54ID:BCTYm40e

まぁ、本来ならば「文字」をキャラクタ(バイト)単位で
判定してはいけないわけだが...
(たとえば文字"A"をさがすのに頭から1バイトずつ順にさがすなど)
だからSJISが2バイトめがMSBたっていないからEUCより面倒とかは
「正しい」組み方をしている限りはない。
(プログラムが文字のエンコーディング方法を知っている必要はないので)

そうはいっても古いコードはまだ多く残っているから。
それに、ちゃんと書くのはけっこうめんどい

0438login:Penguin

03/03/28 00:54ID:a3LtJSU8

はやくさっさと、１文字８バイトの桃源郷を作るんだ。

0439login:Penguin

03/03/28 01:56ID:bqsGCLHk

>>437
"内部コードが"CSIなのってSolarisくらいじゃない?
printf()とかさ

0440山崎渉

03/04/17 12:11ID:PWISM87M

（＾＾）

0441山崎渉

03/04/20 06:09ID:X64WTq1+

　　 ∧＿∧
　　（　　＾＾）＜ぬるぽ（＾＾）

0442名無しさん＠Ｅｍａｃｓ

03/04/27 01:19ID:6zN1r8md

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

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

0443login:Penguin

03/04/27 01:25ID:qRyDd44s

(ﾟдﾟ)ﾊｧｰﾝ

0444（　´Д｀）/＜先生！！こんなのが有りますた。

03/04/27 01:31ID:dA76kPz1

0445login:Penguin

03/04/27 04:22ID:AM2rRROs

日本が独自に４バイト固定長あるいは８バイト固定長の国際標準を
ぶちあげようとしたら、急に経済制裁とか空爆とかを受けそうだな。

0446login:Penguin

03/04/27 05:07ID:r9SAhPiw

＞日本が独自に
という時点で
＞国際標準
にはなりえん気もするが。

0447login:Penguin

03/04/27 10:26ID:CIHHY3pY

>>445 >>446
ISOの国際化規格もXの国際化規格もli18nuxも日本人が中心となって
作った。

Linuxの既存の国際化の仕組みに不満があるなら、li18nuxの樋浦さん
あたりに直接文句言えば。

0448login:Penguin

03/04/27 14:04ID:PuFritwf

li18nuxって役に立ってる？
li18nuxの作ったソフトってどこの
ディストリビューションも使ってないよね？

0449login:Penguin

03/04/27 14:17ID:12AnfH8t

法律で、UCS-4以外を使えば犯罪にしてくれ

0450login:Penguin

03/04/27 15:10ID:LPP1MV5m

>>448
li18nuxは標準化グループです。
今すぐ移行できるレベルの標準はわざわざみんなで考える必要はありません。

ディストリビューション屋さんの得意な既存のソフト組合わせ+少々の改造は、
ディストリビューション屋さんに任せましょう。

0451login:Penguin

03/04/27 15:36ID:PuFritwf

でも、いくつかのsubgroupはクソなので困るんだよね。

0452login:Penguin

03/04/27 16:21ID:TW4m7+2W

>> 450
実装も何気に多い罠

1. locale名の標準化とlocaledefの提供
　ja_JP.ujis -> ja_JP.EUC-JP
2. netscape4.xの不正なmultibyte処理で落ちるバグ対策
　mozillaが使い物になりはじめてた時期であんまり意味なし
3. Xlib-I18N
　Xlocaleのdynamic module化 -> XFree86にmerge済(iconv依存部以外)
　XomCTL(by Sun) -> いまどうなってんの？
CSI xterm -> UTF-8 xterm/luitの出現に敗北
4. GNU toolのmultibyte対応化(by IBM)
bash(readline)、grep、sed、gawkなど、現在本家へのmergeが進む
5. その他いろいろ(Big5をISOに～etc...)

あとは前世のNLS分科会での
1. glibc2のmb/wcとlocaledefで日本語が通る為の修正
2. gettext catalogのcontrib
などもあるわけだが。

標準化ならthread-safe localeとかnetwork transparent localeとか
もっと大風呂敷を広げてくれって感じ。
(Open groupのdistributed localeみたいな)

>>451
> いくつかのsubgroupはクソ
maja(ryっすか？

0453login:Penguin

03/04/30 03:11ID:3+jGzA7G

まずは、C言語、C++言語の国際標準を改定させてcharという型名を
バイトの代わりにつかうことを禁止させて欲しい。octet とか、byte
という型名に変えて欲しい。すべてはまずそこからだ。
Fortran言語も、もしも型名characterが本当に採用している文字表記の
文字１字に対応しているのならよいが、そうでないのなら、octetとか
asciiとかbyteというような型名に国際規格を変更して欲しい。

0454login:Penguin

03/04/30 03:35ID:3ObV2i6L

>>453
int8_t～int64_tとかuint8_t～uint64_tとかquad_tとかご存知無い？
stdint.hとかC99の仕様を一読してから再度ご来場願いたい

0455login:Penguin

03/04/30 05:40ID:3+jGzA7G

char がC/C++言語として使える限り、あれを文字型と称するかぎり、
コードからcharを文字のデータに使うコーディングが無くなる
ことはない。

0456(・∀・)ｙ－~~~　

03/04/30 06:32ID:1OhVc4dx

http://homepage3.nifty.com/coco-nut/

0457login:Penguin

03/04/30 06:42ID:cbI0AZKf

型なんて飾りです、若い香具師にはそれがそれが判らんのです
最近はJavaあたりの影響か、くだらんこと気にする香具師が増えたのか？
char = iso646ってことで、文字型と呼んどきゃいいじゃん

0458login:Penguin

03/04/30 11:41ID:tIYWtx7i

>>455
規格書、ちゃんと読んだ方がいいんじゃない?
charのbit幅について、とかさ。

君がchar = UCS-4な実装するのは誰も止めないぞ。

さらにスレ違い。

0459login:Penguin

03/04/30 22:48ID:lotq/ow/

plain Cで書くのを禁止にすれ。

0460login:Penguin

03/05/04 13:33ID:E/rgpU1m

結論として、多言語混在の文書を書くには、
UTF-8がベストなのか？

0461login:Penguin

03/05/04 22:04ID:LYzzLtSd

>>460

> 多言語混在
UTF-8/UnicodeだとHan-Unification問題、fontの問題がありますが何か？
言語タグで解決するくらいならISO2022で良かった。

0462山崎渉

03/05/22 02:03ID:VfjbtMwi

━―━―━―━―━―━―━―━―━[JR山崎駅（＾＾）]━―━―━―━―━―━―━―━―━―

0463login:Penguin

03/05/29 14:48ID:njol5Zmj

欧米人には utf-8 めちゃくちゃ受けがいいんだよ。
らくちんだもんな。

0464login:Penguin

03/06/01 02:26ID:fkUOiXAk

>>461
ISO 2022マンセーなのは日本人だけ。

>>463
ISO-8859-1→ISO-8859-15よりISO-8859-1→UTF-8の方が都合がいいんだろ。

0465login:Penguin

03/06/01 15:14ID:xEapgirA

保全age

0466login:Penguin

03/06/02 00:06ID:RU4bgj1/

ISO-8859-1以外だと即変換テーブル必要になるUnicodeはアフォ。

0467login:Penguin

03/06/02 04:55ID:CmpL8QI9

よく知らんが、
サーゲなんとかペアで Han Unification は解決できるの?
というか、iso-2022 <-> unicode の変換が一意にできるような標準は
できてないの?

0468login:Penguin

03/06/08 00:06ID:wjasDkQy

>>467
> サーゲなんとかペアで Han Unification は解決できるの?

サロゲートペアってのは16bitで足りねーから建て増ししたってだけの話。
Han-Unificationってのは同じコードポイントであってもCJ(K)でグリフが違うって話。
よって両者は無関係。
過去のUnicodeと互換性を無くしてまでこれらの文字に新しくコードを
割り当てる英断を期待しろとでも？

> というか、iso-2022 <-> unicode の変換が一意にできるような標準は

ISO2022は文字コードではないぞ。
Unicodeは過去の文字コードとの互換性をISO8859-1以外一切無視してるので
計算による変換は不可能。変換テーブルはftpで公開してるが内容についてはかなりアヤシイ。

0469login:Penguin

03/06/08 01:08ID:ZOaY8FC3

「言語タグ」を使えば理論的には可能じゃない？
まあ、実装する奴がいるとは思えないが(ｗ

0470login:Penguin

03/06/08 18:33ID:wjasDkQy

Unicode 14面に入ってるからいずれ実装せざるを得ないんだろね＞言語タグ
もしくはxmlのlang属性とかpangoとかplain textで直接文字列操作しないのがあたりまえになるか。

0471login:Penguin

03/06/09 04:56ID:jVTEBnNx

>>468
> 過去のUnicodeと互換性を無くしてまでこれらの文字に新しくコードを
> 割り当てる英断を期待しろとでも？

結局 unicode では、漢字圏の多国語同時表示はいつまでたっても
期待できないんですか? emacs の iso-2022-7bit の方がまし?

0472login:Penguin

03/06/09 08:22ID:8Cy1V2dg

漢字圏の多国語同時表示なんかより、☆とか⌒…とか、記号すらまともに表示できない糞環境をなんとかすれ。

0473login:Penguin

03/06/09 23:02ID:/M+iPP4I

>>471
いや、出来るよ。固定16bit幅の文字エンコーディングじゃなくなっただけで。
まあ、内部的には21bitあれば、固定幅に出来るけども。

0474山崎渉

03/07/15 11:28ID:doz396Fq

　__∧＿∧_
　|（　　＾＾）|　＜寝るぽ（＾＾）
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉
　　 ~￣￣￣￣

0475ぼるじょあ ◆yBEncckFOU

03/08/02 05:35ID:GfRe8vK7

　　　　∧＿∧　 ∧＿∧
ﾋﾟｭ.ｰ　（　・３・） (　　＾＾）＜これからも僕たちを応援して下さいね（＾＾）。
　　＝〔~∪￣￣￣∪￣￣〕
　　＝ ◎――――――◎ 　　　　　　　　　　　　　　　　　　　　　山崎渉&ぼるじょあ

0476login:Penguin

03/08/07 06:03ID:13nJB4vb

ja_JP.EUC-JP って、なんか意味あるんですか？
実は ja_JP.eucJP とは微妙に違うコードセットだったりするん
でしょうか？
全く同じコードセットだとすると、また新しくlocale名の変種が
増えるだけで、ソフトウェア作成の手間が増えて不便になるだけ
のような気がするんだけど。

ひょっとして、MIMEのcharset名が全てlocaleのコードセット名と
しても使えるようになるんですか？
en_US.ISO_8859-1 とか ja_JP.CSEUCPKDFMTJAPANESE も可能に
なるの？

0477476

03/08/07 06:05ID:13nJB4vb

失礼、age忘れました。

0478login:Penguin

03/08/07 17:06ID:ZrTxZZCU

http://lists.debian.or.jp/debian-devel/200306/msg00011.html
[debian-devel:15660] Re: ja_JP locale name

0479login:Penguin

03/08/07 21:05ID:13nJB4vb

つまり、コードセット名は全て大文字にしなきゃいけない
ことに新しく決まったから eucJP から EUC-JP に変えるっ
てことなのか。

で、なんで全て大文字にしなきゃいけないってことになったの？
互換性を崩してまで統一するメリットってなんなんだろう？

0480476

03/08/07 21:07ID:13nJB4vb

またもage忘れ。すんません。

0481login:Penguin

03/08/07 22:23ID:OLNWypPZ

んなどーでもいいことやる暇があったらja_JP.CP932でもサポートした方が良さそうだが。

0482login:Penguin

03/08/07 22:37ID:/bM3o4Ra

>>481
ja_JP.SJISがサポートされない理由についてはBruno Haibleが
バックスラッシュがどうたらこうたら言ってたという話を
どこかで見たような気がする。

0483login:Penguin

03/08/07 23:04ID:OLNWypPZ

>>482
サポートしている商用Unixもあるんだから技術的には不可能ではないと思うのだが、やっぱりめんどくさいからなのかな。

0484login:Penguin

03/08/13 01:01ID:vZiKmtQp

とにかく文字はアトミックなデーターとして、内部構造に依存せずに
プログラム言語から素直に処理できるのが良い。３２ビットを
１文字にするのが、絶対にいいよ。

0485login:Penguin

03/08/13 01:49ID:Hpn4pIg2

そうは言っても、Unicodeは半角全角問題とか、
ハイフン問題とか、decomposed正規化とか、
サロゲートペアとかあって一筋縄ではイカンわな。

毛ちょっと何とかしてほしひ。

0486login:Penguin

03/08/15 15:29ID:CM17UZsB

この文脈でのatomicの意味が分からん。
statelessなencodingのことをいってんのか
thread-safeなlocaleとwchar_t(たとえばwchar_tをUCS4にするとか)のことを
いってるのかｻﾊﾟｰﾘ。
そもそも文字コードといってるのはCCSかCESどっちよ？

0487login:Penguin

03/08/15 20:48ID:d8HSbf3p

↑皿仕上げ

0488login:Penguin

03/08/15 22:05ID:uQ1Z8d9X

定期的に
http://www.ietf.org/rfc/rfc2130.txt
http://www.unicode.org/unicode/reports/tr17/
http://www.w3.org/TR/1999/WD-charmod-19991129/
あたりすら読まん厨がage続けるスレはここですか？

0489山崎渉

03/08/15 22:08ID:dil3w4kp

　　　 (⌒V⌒)
　　　│ ＾＾ │＜これからも僕を応援して下さいね（＾＾）。
　　⊂|　　　　|つ
　　　（＿）（＿）　　　　　　　　　　　　　　　　　　　　　　山崎パン

0490山崎渉

03/08/15 22:38ID:dil3w4kp

0491login:Penguin

03/08/16 10:25ID:+/Q/RORk

ATOMICということは、その言語の通常の操作では、内部構造がなくて、
分割できない塊としてのみ操作ができるという意味だよ。

たとえばＰａｓｃａｌ言語では、整数型や実数型、文字型、ポインタ型
などのデータは、その内部構造や内部表現にはＰＡＳＣＡＬ言語としては
立ち入ることが出来ない。（もちろん普通は実数も整数も、バイト単位
で構成されていたり突き詰めれば二進数ビットで符号化されているわけだが、
言語仕様上は、そのような内部事情にはアクセス手段がない。だから
化学での原子のように扱える。内部に核があって電子があって、陽子中性子
があるというようなことはとりあえず考えないでいこうということ。）

0492login:Penguin

03/08/17 14:20ID:fizQt/ca

で、どのレイヤを指して文字ってんのよ？

0493login:Penguin

03/08/18 11:47ID:qg3zTJIe

超今更だが、>>37が過ちを犯している。utf-8の漢字は3byteな。

0494login:Penguin

03/08/20 00:41ID:mKHd8Wgb

>>493
最小で3byteですが最大では6byteですよ

0495login:Penguin

03/10/20 03:44ID:Z7b4Bpl5

(゜ω゜)ポカーン.....

0496login:Penguin

03/11/30 01:44ID:57WnbG8d

すいませーん、
オンラインで EUC-JP の規格を参照できるようなサイトはありますか?
文字テーブル（コードvs典型的なグリフ）とかもあると助かるのですが。

>> 165
結局、EUC-JP の 0x21 から 0x7E のあたりって、ASCII なんでしたっけ、
それとも JIS X 0201 ローマ字を使うんでしたっけ?
なんとなく ASCII だと思い込んでいたんですが。。。
Unicode と旧来のエンコーディングを行ったり来たりする処理を使うことが
ときどきありますが、この「ASCII か JIS X 0201 ローマ字か」でいつも
頭が痛いんです。困っているのは僕だけじゃないと思いますが....
どうにかしてくれ > 偉い人

0497login:Penguin

03/11/30 03:21ID:W0msD5oz

muleに付いている文書、ISO2022.jaを読めば?
http://www.iana.org/assignments/character-sets もね。
そもそも http://www.unicode.org/Public/UNIDATA/ じゃないのか?

0498login:Penguin

03/12/01 03:18ID:SviQyXwA

どうもさんくすです。
> muleに付いている文書、ISO2022.jaを読めば?
これは「規格」なのかどうかはよくわかりませんが、
xemacs を調べてみると、etc/CODINGS というファイルで euc-japan は
ASCII を使うようになってるみたいですね。（僕が見方を間違えていなければ）

> http://www.iana.org/assignments/character-sets もね。
こちらも、ASCII っぽいですね... ってことで ASCII と思っていいのかな?

> そもそも http://www.unicode.org/Public/UNIDATA/ じゃないのか?
えーと Unicode の方は規格を知らないということじゃなくて、
例えば Unicode -> ShiftJIS での reverse solidus 問題とかの、
既存のエンコーディングとのからみの話です。もはや、Unicode と既存のエン
コーディングの対応が整備/修正されるのは諦めるしかないのかなあ、なんて
思ったりして。
たぶん、これってもう何度も何度も繰り返された話題でしょうね、ｽﾏｿ。

0499>>497

03/12/01 04:03ID:YFXe237k

>>498
規格読みたければ、JISの規格票買えよ。Copyrightがあるからwebでは読めん。

> 文字テーブル（コードvs典型的なグリフ）とかもあると助かるのですが。

もすっきり解決するぜ。印刷に使っているfontも完璧(?)だから。

>>498
> 例えば Unicode -> ShiftJIS での reverse solidus 問題とかの、
> 既存のエンコーディングとのからみの話です。

風間Java国際化本読め。

大体文字使っている奴が reverse solidus として使っているか、
yen sign として使っているか、全くわからんのだから、
文章書いた奴以外完全な解決はできん。そいつも忘れてるかもしれん。

ただ、EUC_Japanなら 0x5c を yen sign として(間違って)使ってる奴は極少だろうがな。

0500login:Penguin

03/12/01 11:02ID:bqzp7dFQ

>格読みたければ、JISの規格票買えよ。Copyrightがあるからwebでは読めん。
ヴァカですか？

>風間Java国際化本読め。
営業ですか？

0501login:Penguin

03/12/01 11:03ID:bqzp7dFQ

>格読みたければ、JISの規格票買えよ。
ヴァカですか？

>風間Java国際化本読め。
営業ですか？

0502login:Penguin

03/12/01 11:33ID:doVY1QDl

EUC-JP って JIS に入ってたっけ?

0503login:Penguin

03/12/02 04:37ID:Ld5fw5ew

>>499
>> 文字テーブル（コードvs典型的なグリフ）とかもあると助かるのですが。
>もすっきり解決するぜ。印刷に使っているfontも完璧(?)だから。
は。ちなみに Unicode だとそういうのがオンラインであるわけで、
こうやって普及に差が出るのかなあって思う。

>文章書いた奴以外完全な解決はできん。
そうです。で文章書いた奴の意図を汲むための処理 (UI 等) が必要なわけ。
でもそういう処理を用意するのは面倒だし、さらに文字コードのことを深く
知らないユーザから見たら奇異だよね。
で、それって別に原理的にそうなんじゃなくて単に規格がダメなせいでしょ、
って話。

>ただ、EUC_Japanなら 0x5c を yen sign として(間違って)使ってる奴は極少だろうがな。
http://kanji.zinbun.kyoto-u.ac.jp/~yasuoka/kanjibukuro/japan.html や
http://euc.jp/i18n/charcode.ja.html の「5.1 EUC」
を見ると、EUC でも ISO 646（JIS X 0201 ローマ文字）はアリみたいなんで
すが。極少でも、間違いじゃないなら面倒見るべきでは。

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