857コメント312KB

EUCボクメツ委員会

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

0001ﾓ･ｸ･ﾍ･ｹ菽ｦｯ

01/10/16 00:18ID:ZujZqkcr

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

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 ローマ文字）はアリみたいなんで
すが。極少でも、間違いじゃないなら面倒見るべきでは。

0504login:Penguin

03/12/02 06:54ID:0RsR6Dsz

>>503
EUC は CES ですが、EUC-JP は CCS です。
EUC-JP では、code set 0 は ASCII に決まってます。

http://www.iana.org/assignments/character-sets の MIBenum: 18

0505login:Penguin

03/12/03 02:46ID:UUcL758a

0506login:Penguin

03/12/03 14:18ID:6d4CdMx0

どっちでもいいからどっちかに統一しろや無能どもが。

0507login:Penguin

03/12/03 16:56ID:B3zlXzir

>>506
統一したらしたで文句言うんだろう？カスが。

0508login:Penguin

03/12/04 19:14ID:9n6DOrlU

>>504
CESとCSSはなんの略でしょうか?
教えてください。

0509login:Penguin

03/12/05 00:06ID:TihMjOjI

Character Encoding Scheme (文字符号化方式)
Coded Character Set (符号化文字集合)

CCS は文字の集合を表現するもの。CES は一つ、あるいは複数の CCS を実際の
バイト列というかビット列というか、そういう表現に写像するもの。

0510508

03/12/05 04:19ID:mdRn2HdJ

>>509
ということは、EUC-JPもCESじゃないでしょうか?

私は、ISO-2022の状態遷移を持たずに済むようにしたサブセットがEUCで、
EUCの文字集合を具体的に定義したものがEUC-JPだと理解していますが
どうなんでしょうか?

0511login:Penguin

03/12/05 21:19ID:WmOgE02Z

>>499
http://www.jisc.go.jp/ から読めたりしますが。
ただし「解説」は読めないみたい。

あと、JIS X 0208と0213は規格協会から出版されている
『増補改訂 JIS漢字字典』に縮刷版が入ってたりする。

0x5cが円記号か逆斜線かは、コードの由来に立ちかえれば明快。
・シフトJIS: JIS X 0201の8ビットコードの拡張なので円記号(YEN SIGN)
・EUC: ASCIIの拡張なので逆斜線 (REVERSE SOLIDUS)

>>510
CCS, CESという定義の仕方はあまりうまくないので、真面目に考えるだけ損。

0512login:Penguin

04/01/04 13:24ID:KetwKeXM

なんでわざわざ規格が2つもあるんだか。普通に考えておかしいじゃん。
両方とも、他方の欠点についてくだらん言い訳をグダグダのたまうんだろうけど
結局のところこの統一されてない状態が一番不便なのがわからんのかクソども。

0513login:Penguin

04/01/05 05:56ID:AOcZ5fo2

どんな文字コードでも使える実装をほどこせばいいんでない？
とか言うのはソフトを書くわけでもない素人の意見なのかな、やっぱり……

0514login:Penguin

04/01/05 10:29ID:gmkRu+uW

>>513
はい。

0515login:Penguin

04/01/12 16:06ID:Z4GWGJfa

　　　　　　 lヽﾉ l　　　　　　　　ｌ l　ｌヽ　　ヽ
　 )'ｰーノ(　 |　|　 | ､　　　　　 / l｜ｌ　ハヽ　　|ｰ‐''"ｌ
　/　Ｃ　　|　|　|／| ﾊ　　/ / ,/ /|ﾉ /l /　ｌ l ｌ|　ｌ　Ｃヽ
　l 　･　　i´ |　ヽ､| |ｒ|| |　//--‐'" 　｀'メ､_ｌﾉ| /　・　 /
　|　Ｓ　　l　トー-トヽ| |ノ　''"´｀　　　ｒｰ-/// |　Ｓ　｜
　|　･　　 |／　　　 | l ||､　''"""　 j　""''/ | |ヽｌ　・　｜
　|　Ｉ　 |　　　　 | l |　ヽ,　　― 　／　| |　ｌ　Ｉ　 |
　| 　 !!　 |　　　 /　| | |　　 ` ｰ-‐ ' ´||　,ﾉ| |　|　　!!　｜
ノｰ‐---､,|　　 /　│ｌ､l　　　　　　　 |ﾚ' ,ﾉﾉ　ﾉハ､_ノヽ
　/ 　　　　／　ノ⌒ヾ､　ヽ　　　ノハ,　　　　 |
,/ 　　　　,イーｆ'´ /´　　＼　| ,／´ ｜ヽl　　　　 |
　　　　／-ト、|　┼―- ､_ヽﾒr'　, -=ｌ''"ハ　　　　|　ｌ
　　 ,／　　|　ヽ　＼　　_,ノｰｆ' ´　　ﾉノ　ヽ　　｜　|
､_　　　 _ ‐''ｌ　　`ー‐―''" ⌒'ｰ--‐'´｀ヽ､_ 　　_,ノ　ノ
　￣￣　　 |　　　　　　　　　　／　　　　　￣

0516login:Penguin

04/01/21 04:54ID:l6i+YvvA

Post

0517login:Penguin

04/01/24 12:36ID:OGcyA9QE

GBやKSやCNSって文字名を規定するように改訂されてるんですか?
されてなかったら文字名による同定なんて絵に描いた餅だと思うんですが。
少なくともGB2312は廃止されてGB18030になったんだから
改訂版は存在しないですよね?

0518login:Penguin

04/01/27 17:53ID:Vqw8VTxA

>>517
少なくともISO/IEC 8859シリーズやJIS X 0201/0208/0213は文字名を規定してる。
他の奴は調査のうえ報告きぼん。

0519login:Penguin

04/01/27 18:02ID:CYFtYKQ6

>>518
それは知ってます。だからGB/KS/CNSについて聞いてみたわけです。
JIS X 0212の文字名は「参考」しか存在しないですね。

0520login:Penguin

04/01/28 01:38ID:yXeHWwGb

GB18030の仕様書?
http://www.anycities.com/gb18030/standard.htm

0521login:Penguin

04/01/28 09:30ID:zcjMBZrl

>>520
やっぱり絵に描いた餅っぽいな
JISの範囲に限定してもけっこう破綻してるし

0522login:Penguin

04/01/31 00:53ID:0gxSoMh4

Unicode Normalization派には全ての文字集合が破綻して見える。
CSI派にはUnicodeが破綻して見える。
いじょ。

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