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

EUCボクメツ委員会

■ このスレッドは過去ログ倉庫に格納されています
0001ﾓ･ｸ･ﾍ･ｹ菽ｦｯ01/10/16 00:18ID:ZujZqkcr
Javaとかのマルチプラットフォームなアプリでも文字コードをいじらないと化けるし。
ICQクローンで Shift_JIS<=>EUC の相互変換をするように加工とか小細工して使ってるのには泣けたＹＯ
せっかく多言語対応の環境で作られたソフトでも日本ローカルのパッチ作んなきゃいけないんじゃ
意味ないじゃん！
Winに比べて少ないアプリがさらに選択肢が狭まっちゃってどうしようもないYO
Linuxにおける日本語の標準コードはWinに倣いShift-JISをメインにすべきである。
0452login:Penguin03/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:Penguin03/04/30 03:11ID:3+jGzA7G
まずは、C言語、C++言語の国際標準を改定させてcharという型名を
バイトの代わりにつかうことを禁止させて欲しい。octet とか、byte
という型名に変えて欲しい。すべてはまずそこからだ。
Fortran言語も、もしも型名characterが本当に採用している文字表記の
文字１字に対応しているのならよいが、そうでないのなら、octetとか
asciiとかbyteというような型名に国際規格を変更して欲しい。
0454login:Penguin03/04/30 03:35ID:3ObV2i6L
>>453
int8_t〜int64_tとかuint8_t〜uint64_tとかquad_tとかご存知無い？
stdint.hとかC99の仕様を一読してから再度ご来場願いたい
0455login:Penguin03/04/30 05:40ID:3+jGzA7G
char がC/C++言語として使える限り、あれを文字型と称するかぎり、
コードからcharを文字のデータに使うコーディングが無くなる
ことはない。
0456(・∀・)ｙ−~~~　03/04/30 06:32ID:1OhVc4dx
http://homepage3.nifty.com/coco-nut/
0457login:Penguin03/04/30 06:42ID:cbI0AZKf
型なんて飾りです、若い香具師にはそれがそれが判らんのです
最近はJavaあたりの影響か、くだらんこと気にする香具師が増えたのか？
char = iso646ってことで、文字型と呼んどきゃいいじゃん
0458login:Penguin03/04/30 11:41ID:tIYWtx7i
>>455
規格書、ちゃんと読んだ方がいいんじゃない?
charのbit幅について、とかさ。

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

さらにスレ違い。
0459login:Penguin03/04/30 22:48ID:lotq/ow/
plain Cで書くのを禁止にすれ。
0460login:Penguin03/05/04 13:33ID:E/rgpU1m
結論として、多言語混在の文書を書くには、
UTF-8がベストなのか？
0461login:Penguin03/05/04 22:04ID:LYzzLtSd
>>460

> 多言語混在
UTF-8/UnicodeだとHan-Unification問題、fontの問題がありますが何か？
言語タグで解決するくらいならISO2022で良かった。
0462山崎渉03/05/22 02:03ID:VfjbtMwi
━―━―━―━―━―━―━―━―━[JR山崎駅（＾＾）]━―━―━―━―━―━―━―━―━―
0463login:Penguin03/05/29 14:48ID:njol5Zmj
欧米人には utf-8 めちゃくちゃ受けがいいんだよ。
らくちんだもんな。
0464login:Penguin03/06/01 02:26ID:fkUOiXAk
>>461
ISO 2022マンセーなのは日本人だけ。

>>463
ISO-8859-1→ISO-8859-15よりISO-8859-1→UTF-8の方が都合がいいんだろ。
0465login:Penguin03/06/01 15:14ID:xEapgirA
保全age
0466login:Penguin03/06/02 00:06ID:RU4bgj1/
ISO-8859-1以外だと即変換テーブル必要になるUnicodeはアフォ。
0467login:Penguin03/06/02 04:55ID:CmpL8QI9
よく知らんが、
サーゲなんとかペアで Han Unification は解決できるの?
というか、iso-2022 <-> unicode の変換が一意にできるような標準は
できてないの?
0468login:Penguin03/06/08 00:06ID:wjasDkQy
>>467
> サーゲなんとかペアで Han Unification は解決できるの?

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

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

ISO2022は文字コードではないぞ。
Unicodeは過去の文字コードとの互換性をISO8859-1以外一切無視してるので
計算による変換は不可能。変換テーブルはftpで公開してるが内容についてはかなりアヤシイ。
0469login:Penguin03/06/08 01:08ID:ZOaY8FC3
「言語タグ」を使えば理論的には可能じゃない？
まあ、実装する奴がいるとは思えないが(ｗ
0470login:Penguin03/06/08 18:33ID:wjasDkQy
Unicode 14面に入ってるからいずれ実装せざるを得ないんだろね ＞言語タグ
もしくはxmlのlang属性とかpangoとかplain textで直接文字列操作しないのがあたりまえになるか。
0471login:Penguin03/06/09 04:56ID:jVTEBnNx
>>468
> 過去のUnicodeと互換性を無くしてまでこれらの文字に新しくコードを
> 割り当てる英断を期待しろとでも？

結局 unicode では、漢字圏の多国語同時表示はいつまでたっても
期待できないんですか? emacs の iso-2022-7bit の方がまし?
0472login:Penguin03/06/09 08:22ID:8Cy1V2dg
漢字圏の多国語同時表示なんかより、☆とか⌒…とか、記号すらまともに表示できない糞環境をなんとかすれ。
0473login:Penguin03/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:Penguin03/08/07 06:03ID:13nJB4vb
ja_JP.EUC-JP って、なんか意味あるんですか？
実は ja_JP.eucJP とは微妙に違うコードセットだったりするん
でしょうか？
全く同じコードセットだとすると、また新しくlocale名の変種が
増えるだけで、ソフトウェア作成の手間が増えて不便になるだけ
のような気がするんだけど。

ひょっとして、MIMEのcharset名が全てlocaleのコードセット名と
しても使えるようになるんですか？
en_US.ISO_8859-1 とか ja_JP.CSEUCPKDFMTJAPANESE も可能に
なるの？
047747603/08/07 06:05ID:13nJB4vb
失礼、age忘れました。
0478login:Penguin03/08/07 17:06ID:ZrTxZZCU
http://lists.debian.or.jp/debian-devel/200306/msg00011.html
[debian-devel:15660] Re: ja_JP locale name
0479login:Penguin03/08/07 21:05ID:13nJB4vb
つまり、コードセット名は全て大文字にしなきゃいけない
ことに新しく決まったから eucJP から EUC-JP に変えるっ
てことなのか。

で、なんで全て大文字にしなきゃいけないってことになったの？
互換性を崩してまで統一するメリットってなんなんだろう？
048047603/08/07 21:07ID:13nJB4vb
またもage忘れ。すんません。
0481login:Penguin03/08/07 22:23ID:OLNWypPZ
んなどーでもいいことやる暇があったらja_JP.CP932でもサポートした方が良さそうだが。
0482login:Penguin03/08/07 22:37ID:/bM3o4Ra
>>481
ja_JP.SJISがサポートされない理由についてはBruno Haibleが
バックスラッシュがどうたらこうたら言ってたという話を
どこかで見たような気がする。
0483login:Penguin03/08/07 23:04ID:OLNWypPZ
>>482
サポートしている商用Unixもあるんだから技術的には不可能ではないと思うのだが、やっぱりめんどくさいからなのかな。
0484login:Penguin03/08/13 01:01ID:vZiKmtQp
とにかく文字はアトミックなデーターとして、内部構造に依存せずに
プログラム言語から素直に処理できるのが良い。３２ビットを
１文字にするのが、絶対にいいよ。
0485login:Penguin03/08/13 01:49ID:Hpn4pIg2
そうは言っても、Unicodeは半角全角問題とか、
ハイフン問題とか、decomposed正規化とか、
サロゲートペアとかあって一筋縄ではイカンわな。

毛ちょっと何とかしてほしひ。
0486login:Penguin03/08/15 15:29ID:CM17UZsB
この文脈でのatomicの意味が分からん。
statelessなencodingのことをいってんのか
thread-safeなlocaleとwchar_t(たとえばwchar_tをUCS4にするとか)のことを
いってるのかｻﾊﾟｰﾘ。
そもそも文字コードといってるのはCCSかCESどっちよ？
0487login:Penguin03/08/15 20:48ID:d8HSbf3p
↑皿仕上げ
0488login:Penguin03/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
　　　 (⌒V⌒)
　　　│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
　　⊂|　　　　|つ
　　　（＿）（＿）　　　　　　　　　　　　　　　　　　　　　　山崎パン
0491login:Penguin03/08/16 10:25ID:+/Q/RORk
ATOMICということは、その言語の通常の操作では、内部構造がなくて、
分割できない塊としてのみ操作ができるという意味だよ。

たとえばＰａｓｃａｌ言語では、整数型や実数型、文字型、ポインタ型
などのデータは、その内部構造や内部表現にはＰＡＳＣＡＬ言語としては
立ち入ることが出来ない。（もちろん普通は実数も整数も、バイト単位
で構成されていたり突き詰めれば二進数ビットで符号化されているわけだが、
言語仕様上は、そのような内部事情にはアクセス手段がない。だから
化学での原子のように扱える。内部に核があって電子があって、陽子中性子
があるというようなことはとりあえず考えないでいこうということ。）
0492login:Penguin03/08/17 14:20ID:fizQt/ca
で、どのレイヤを指して文字ってんのよ？
0493login:Penguin03/08/18 11:47ID:qg3zTJIe
超今更だが、>>37が過ちを犯している。utf-8の漢字は3byteな。
0494login:Penguin03/08/20 00:41ID:mKHd8Wgb
>>493
最小で3byteですが最大では6byteですよ
0495login:Penguin03/10/20 03:44ID:Z7b4Bpl5
(゜ω゜)ポカーン.....
0496login:Penguin03/11/30 01:44ID:57WnbG8d
すいませーん、
オンラインで EUC-JP の規格を参照できるようなサイトはありますか?
文字テーブル（コードvs典型的なグリフ）とかもあると助かるのですが。

>> 165
結局、EUC-JP の 0x21 から 0x7E のあたりって、ASCII なんでしたっけ、
それとも JIS X 0201 ローマ字を使うんでしたっけ?
なんとなく ASCII だと思い込んでいたんですが。。。
Unicode と旧来のエンコーディングを行ったり来たりする処理を使うことが
ときどきありますが、この「ASCII か JIS X 0201 ローマ字か」でいつも
頭が痛いんです。困っているのは僕だけじゃないと思いますが....
どうにかしてくれ > 偉い人
0497login:Penguin03/11/30 03:21ID:W0msD5oz
muleに付いている文書、ISO2022.jaを読めば?
http://www.iana.org/assignments/character-sets もね。
そもそも http://www.unicode.org/Public/UNIDATA/ じゃないのか?
0498login:Penguin03/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>>49703/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:Penguin03/12/01 11:02ID:bqzp7dFQ
>格読みたければ、JISの規格票買えよ。Copyrightがあるからwebでは読めん。
ヴァカですか？

>風間Java国際化本読め。
営業ですか？
0501login:Penguin03/12/01 11:03ID:bqzp7dFQ
>格読みたければ、JISの規格票買えよ。
ヴァカですか？

>風間Java国際化本読め。
営業ですか？
0502login:Penguin03/12/01 11:33ID:doVY1QDl
EUC-JP って JIS に入ってたっけ?
0503login:Penguin03/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:Penguin03/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:Penguin03/12/03 02:46ID:UUcL758a
0506login:Penguin03/12/03 14:18ID:6d4CdMx0
どっちでもいいからどっちかに統一しろや無能どもが。
0507login:Penguin03/12/03 16:56ID:B3zlXzir
>>506
統一したらしたで文句言うんだろう？カスが。
0508login:Penguin03/12/04 19:14ID:9n6DOrlU
>>504
CESとCSSはなんの略でしょうか?
教えてください。
0509login:Penguin03/12/05 00:06ID:TihMjOjI
Character Encoding Scheme (文字符号化方式)
Coded Character Set (符号化文字集合)

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

051050803/12/05 04:19ID:mdRn2HdJ
>>509
ということは、EUC-JPもCESじゃないでしょうか?

私は、ISO-2022の状態遷移を持たずに済むようにしたサブセットがEUCで、
EUCの文字集合を具体的に定義したものがEUC-JPだと理解していますが
どうなんでしょうか?
0511login:Penguin03/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:Penguin04/01/04 13:24ID:KetwKeXM
なんでわざわざ規格が2つもあるんだか。普通に考えておかしいじゃん。
両方とも、他方の欠点についてくだらん言い訳をグダグダのたまうんだろうけど
結局のところこの統一されてない状態が一番不便なのがわからんのかクソども。
0513login:Penguin04/01/05 05:56ID:AOcZ5fo2
どんな文字コードでも使える実装をほどこせばいいんでない？
とか言うのはソフトを書くわけでもない素人の意見なのかな、やっぱり……

0514login:Penguin04/01/05 10:29ID:gmkRu+uW
>>513
はい。
0515login:Penguin04/01/12 16:06ID:Z4GWGJfa
　　　　　　 lヽ ﾉ l　　　　　　　　ｌ l　ｌ ヽ　　 ヽ
　 )'ｰーノ(　 |　|　 | ､　　　　　 / l｜ ｌ　ハヽ　　|ｰ‐''"ｌ
　/　Ｃ　　|　|　|／| ﾊ　　/ / ,/ /|ﾉ /l /　ｌ l ｌ|　ｌ　 Ｃ ヽ
　l 　 ･　　i´ |　ヽ､| |ｒ|| |　//--‐'" 　 ｀'メ､_ｌﾉ| /　 ・　 /
　|　 Ｓ　　l　 トー-トヽ| |ノ　''"´｀　　　ｒｰ-/// |　 Ｓ　｜
　|　 ･　　 |／　　 　 | l ||､　''"""　 j　""''/ | |ヽｌ 　・　｜
　|　 Ｉ 　 |　　 　 　 | l |　ヽ,　 　― 　 ／　| |　ｌ　 Ｉ　 |
　| 　 !!　 |　　 　 /　| | |　　 ` ｰ-‐ ' ´||　,ﾉ| |　|　　!!　｜
ノｰ‐---､,|　 　 /　│ｌ､l　　　　　　 　 |ﾚ' ,ﾉﾉ　ﾉハ､_ノヽ
　/ 　　 　 　 ／　ノ⌒ヾ､　 ヽ　　　 ノハ,　　　 　 |
,/ 　 　　　,イーｆ'´ /´　　＼　| ,／´ ｜ヽl　　　 　 |
　　　　 ／-ト、|　┼―- ､_ヽﾒr'　, -=ｌ''"ハ　　　　|　 ｌ
　　 ,／　 　|　ヽ 　＼　　_,ノｰｆ' ´　　ﾉノ　 ヽ　 　｜　|
､_　　　 _ ‐''ｌ　　`ー‐―''" ⌒'ｰ--‐'´｀ヽ､_ 　　_,ノ　ノ
　 ￣￣　　 |　　　　　　　　　　 ／　 　　　　￣
0516login:Penguin04/01/21 04:54ID:l6i+YvvA
Post
0517login:Penguin04/01/24 12:36ID:OGcyA9QE
GBやKSやCNSって文字名を規定するように改訂されてるんですか?
されてなかったら文字名による同定なんて絵に描いた餅だと思うんですが。
少なくともGB2312は廃止されてGB18030になったんだから
改訂版は存在しないですよね?
0518login:Penguin04/01/27 17:53ID:Vqw8VTxA
>>517
少なくともISO/IEC 8859シリーズやJIS X 0201/0208/0213は文字名を規定してる。
他の奴は調査のうえ報告きぼん。
0519login:Penguin04/01/27 18:02ID:CYFtYKQ6
>>518
それは知ってます。だからGB/KS/CNSについて聞いてみたわけです。
JIS X 0212の文字名は「参考」しか存在しないですね。
0520login:Penguin04/01/28 01:38ID:yXeHWwGb
GB18030の仕様書?
http://www.anycities.com/gb18030/standard.htm
0521login:Penguin04/01/28 09:30ID:zcjMBZrl
>>520
やっぱり絵に描いた餅っぽいな
JISの範囲に限定してもけっこう破綻してるし
0522login:Penguin04/01/31 00:53ID:0gxSoMh4
Unicode Normalization派には全ての文字集合が破綻して見える。
CSI派にはUnicodeが破綻して見える。
いじょ。
0523login:Penguin04/01/31 07:48ID:uM5oI3vd
CSI派は情報交換用符号化文字集合としては何を使うんでしょうか。
TRONコード?
0524login:Penguin04/01/31 15:12ID:A1rPcmld
> CSI派は情報交換用符号化文字集合としては何を使うんでしょうか。
CSIだから何でも有りなわけだが…
0525login:Penguin04/02/01 13:09ID:N4VOvKZ9
>>520
何がどう破綻してるのか意味不明。
文字名称による同定が破綻しているとすればUnicode/10646自体の失敗に近い。
Unicodeしか無い世界を想定すればそれでも良いのかもしれないけど、
そんな想定は頭の中のお花畑でしょ。
0526login:Penguin04/02/02 10:00ID:hq6ctxrf
>>524
内部が何でも有りでよくても外部と情報交換するときには
相手の知らないコードでは話にならないと思うんですが
0527login:Penguin04/02/02 10:06ID:hq6ctxrf
>>525
> 文字名称による同定が破綻
そもそも一対一の対応関係しか記述できないのが無理ありすぎ。
> Unicode/10646自体の失敗に近い。
でも国際規格との整合という名目で文字名を規定してしまった。
つーかCJKでUnicodeに一番反対しているはずの日本だけが
自国の文字集合で文字名を規定してる(らしい)ってほとんど
ギャクだな。
0528login:Penguin04/02/02 10:41ID:ZMPM1Vhd
>>526
何でもありと言ってもcharset repositoryに登録されてる奴だけでしょ。
0529login:Penguin04/02/02 22:12ID:rBgXmwm9
「相手の知らないもの」を「交換」すること事態ｱﾘｴﾅｲ、
お互いが情報を共有していれば既存の文字集合でなくても構わない。
0530login:Penguin04/02/12 11:08ID:KO5Q49AN
> 「相手の知らないもの」を「交換」すること事態ｱﾘｴﾅｲ、
> お互いが情報を共有していれば
どうやって共有するんですか?
そんなこと言い出したらネットワークプロトコルなんて
一切必要ないということになると思いますが。
0531login:Penguin04/02/13 07:42ID:AkWuZ3md
既存のコードのどれかに対する写像関数があれば
何も問題なさそうだけど。プロトコルと違って
文字コードは単純なので同じように考えることは
できないと思うけど。
0532login:Penguin04/02/13 10:16ID:9tJnggCR
関数が、ベンダーによって違ったり、
単射に出来なかったりで問題。
0533login:Penguin04/02/19 17:11ID:HogZ/lIc
とりあえずSJIS撲滅しろ
0534login:Penguin04/02/19 18:46ID:wXxKmQwW
　　　／⌒ヽ　　すいません、ちょっと撲殺しますよ・・・
　　/　´_ゝ`）　　　|　|　
　と　　　　）　 　 |　|　ｶﾞｯ
　　 Ｙ　/ノ　　　 人
　　　 /　）　 　 < 　>_∧∩
　 ＿/し'　／／. Ｖ｀Д´）/
　（＿フ彡　　　　　 　　/←>>533
0535login:Penguin04/02/20 15:15ID:MhppvPgK
「SJIS撲滅しろ」とSJISで読ませてる矛盾…
日本製品排斥運動のプラカードを日本製筆記用具で書いてる話を思い出したよ。
0536login:Penguin04/02/20 15:25ID:USABAkbG
ネット上を流れる日本語の何割ぐらいがEUCなのかな。
事情がどうであれ、SJISが既に多数派だってことは
受け入れないとダメだろね＜EUC派の人。
0537login:Penguin04/02/20 15:42ID:HZ88v8IJ
YahooはEUC-JPだよね。
0538login:Penguin04/02/20 15:59ID:DuOkNDXy
>>536
煽りか知らんが、それを受け入れてない香具師はいないだろ。
wwwにutf-8,16使ってるページが少ないからといってunicode推進は間違ってるという結論にはならん訳だし。
0539login:Penguin04/02/20 16:10ID:HZ88v8IJ
>>538
全然関係ない話だが、XHTMLがXMLの派生だと考えると、XHTMLでは
UTF-8・UTF-16を使うのが正道だと思うのだが、どう思う?
Unicode嫌いだがXHMLラブな俺。
0540login:Penguin04/02/20 18:02ID:DuOkNDXy
utf-16より16ビットクリーンのucs-2が乙。
0541login:Penguin04/02/20 18:13ID:OGx3SqOQ
> 16ビットクリーン
どういう意味? ぐぐっても0件だし。
「8ビットクリーン」の語義から類推すれば、
途中で16ビット目が壊れることはないって意味になるけど・・・
0542login:Penguin04/02/20 18:17ID:HZ88v8IJ
>>540
まぁUTF-16とUTF-8の二者択一で、UTF-16は選ばんな。
サロゲートペアが気持ち悪すぎる。
しかしUCS-2はどうかといわれると、それならUCS-4使いたいところ。
054354204/02/20 18:18ID:HZ88v8IJ
似たような理由でShift JISも気持ち悪い。
0544login:Penguin04/02/20 18:36ID:SE61JsUR
>>536
シフトJISって言っても何種類もあるしね。
0545login:Penguin04/02/20 18:47ID:HZ88v8IJ
>>544
たとえば?
まさか「Unicodeへのマッピングが〜」なんて言わないよね……。
0546login:Penguin04/02/20 19:39ID:YAuvVXfE
どうせなら、iso-2022 の枠の中に unicode の仕様も入れちゃえばよかったんじゃないの。
0547login:Penguin04/02/20 19:39ID:DuOkNDXy
>>541
16ビットオンリーと言うべきだったかもしれぬ。
EUC,JIS,SJIS,UTF-8 -> 8ビットと16ビットが混在
UTF-16 -> 16ビットだけと見せかけてサロゲートがある。
UCS-2 -> 16ビットのみ(n文字目に定数時間でアクセス可能)
0548login:Penguin04/02/20 20:26ID:HZ88v8IJ
>>546
>どうせなら、iso-2022 の枠の中に unicode の仕様も入れちゃえばよかったんじゃないの。

文字集合の話なら、ISO国際登録簿に登録されている。


符号化も含めてなら、一応ISO-2022には「他の符号化システムの指示(DOCS)」機能がある。
これを使えばUnicode(UTF-8・UTF-16)に切り替えられる。
# UTF-8・UTF-16のエスケープシーケンスもISO国際登録簿に登録されている。
0549login:Penguin04/02/20 20:35ID:YAuvVXfE
> # UTF-8・UTF-16のエスケープシーケンスもISO国際登録簿に登録されている。
本当だ。知らんかった。
0550login:Penguin04/02/20 20:37ID:SE61JsUR
>>545
Shift_JISとかMicrosoftのCP932とか
0551login:Penguin04/02/20 20:53ID:HZ88v8IJ
>>550
> Shift_JISとかMicrosoftのCP932とか

その二つはどこが違うの?
俺の理解では、まさに「Unicodeへのマッピング」の違いなんだが。
あと「何種類もあるしね」と書いているが、2つだけ?
0552login:Penguin04/02/21 10:55ID:8cIti7Dp
>>551
マッピングが違う時点で、別の文字コードになる。
種類も 2つではすまない。
http://www.opengroup.or.jp/jvc/cde/sjis.html
■ このスレッドは過去ログ倉庫に格納されています