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

EUCボクメツ委員会

■ このスレッドは過去ログ倉庫に格納されています
0001ﾓ･ｸ･ﾍ･ｹ菽ｦｯ01/10/16 00:18ID:ZujZqkcr
Javaとかのマルチプラットフォームなアプリでも文字コードをいじらないと化けるし。
ICQクローンで Shift_JIS<=>EUC の相互変換をするように加工とか小細工して使ってるのには泣けたＹＯ
せっかく多言語対応の環境で作られたソフトでも日本ローカルのパッチ作んなきゃいけないんじゃ
意味ないじゃん！
Winに比べて少ないアプリがさらに選択肢が狭まっちゃってどうしようもないYO
Linuxにおける日本語の標準コードはWinに倣いShift-JISをメインにすべきである。
0581login:Penguin04/03/06 16:57ID:RIYFz2Z8
UTF-8の作成に日本はお金だしたの？
ちょっとしかお金ださないから3バイトに追いやられたの？
最近は「金は力なり」ってことはないのかな…
0582login:Penguin04/03/06 17:37ID:FTiwHY/0
>>581
なんか外人からみた日本人のイメージの典型みたいな人だなぁ
0583login:Penguin04/03/06 20:57ID:NtiYGtdX
>>581
とりあえず、UNICODE コンソーシアムのメンバーで日本の会社は
ジャストシステムしか見あたらない。
http://www.unicode.org/consortium/memblogo.html
0584login:Penguin04/03/06 21:52ID:k9F50u4V
>>581
どっかで聞いた気がするのだが結構お金だしてたような………
UNICODEの方だったかなぁ………
0585login:Penguin04/03/07 01:10ID:1mpDS4RM
>>578
http://www.itscj.ipsj.or.jp/ipsj-ts/02-07/coreset/toc.htm
というのがあるけど。
0586login:Penguin04/03/07 10:03ID:JJs7467H
特定のロケールのみ使う場合に短縮できるというアイデアは
DIS 10646そのものじゃん。それを葬り去って(ry
0587LightCone ◆sSJBc30S5w 04/03/07 19:36ID:Q1hO8bzI
>>578, >>580
日本語のJIS第一、第二水準、中国語の第一級、第二級漢字までを2BYTEで
符号化できる新しいUnicode符号化方式:UTFCPを開発したのでご覧下さい。
2バイトで一万五千文字ものコード・ポイントがあります。

http://www.nowsmartsoft.or.tv/nws/Japanese/nwsos_utf.htm

また、この符号は、ロケールやコードページの必要のない世界共通の符号
になり得る可能性があります。

符号の逆戻りも可能なので、文字列を後ろから検索する際の効率も
高いですし、複数バイト文字にASCII符号を一切含まないので、
無配慮に大文字小文字変換をしてしまう様な欧米のアプリケーションに
対しても問題ありません。
0588login:Penguin04/03/08 00:10ID:Jjoer6mt
basic planeマンセー！(やや曇り勝ちな声で)
0589login:Penguin04/03/08 00:16ID:xPUur27x
>>587
> 今まで2バイトで余裕を持って扱えていたものを、突然3バイトで
> 扱わなければならないと言われれば、誰でも納得しがたいもので
> しょう。
いや別に……。
でかい文字集合突っ込んでる立場としては、3バイトくらいが妥当と
いう感覚がある。
0590login:Penguin04/03/08 00:45ID:8nTBrLvd
>>589
それでも、やっぱり2バイトがいい。
文化の違いを考慮するべきでしょう（私は日本語だけ2バイトにでいいですがｗ
飛躍しすぎですが、メールとかの通信量が1.5倍＝料金1.5倍と思えば…
2chのログも1.5倍になったら………

FedoraがUTF-8になったので危機感を感じてるのですが
日本か中国で差別用語(?)とか言ってUTF-8禁止令とかでないかなぁ～
日本政府ヨワッチイからなぁ、中国やってくれないかなｗ

で、英数字1バイト、日本語2バイトが良い我々は、SiftJISかEUC-JP使えばいいの？
0591login:Penguin04/03/08 01:38ID:CDAnHB+K
もっと先を見越した発想しないと駄目だよ。
0592login:Penguin04/03/08 01:58ID:BCltEIyA
>>591
先を見越すとどうなるの？
あとホームページが全部UTF-8になったらインターネットは混むかな？
メールがなったら携帯電話は大変だな。ドコモセンター落ちるかな(笑
0593login:Penguin04/03/08 02:28ID:nJKGONH1
中華人民共和国にはGB2312やGBKと完全な互換性を保ちつつ
UCS4の上位互換でもあるGB18030が既にありますが。
0594login:Penguin04/03/08 03:06ID:BCltEIyA
>>593
さすが中国。で、日本は？
0595login:Penguin04/03/08 03:56ID:y/RuiKoY
>>594
日本はUnicodeアレルギーが強すぎるのでUnicodeへの上位互換なんか
屁の突っ張りほどにも思ってない俺コードばかりです。
たいてい大漢和への上位互換は売り文句にしてますね
0596LightCone ◆sSJBc30S5w 04/03/08 08:53ID:JfYQzP4X
>>595
拡張シフトJIS案、拡張EUC-JP案は提唱されています:
http://web.archive.org/web/20030605094425/www.ksky.ne.jp/~smile4me/charcode/index.htm

それと、>>587のUTFCP。
059758904/03/08 10:11ID:xPUur27x
>>590
> 文化の違いを考慮するべきでしょう（私は日本語だけ2バイトにでいいですがｗ

文化の違いっていうのがよく分かりませんが。
「それぞれの言語でもっとも効率のよいエンコーディングを使うのが良い」と
いう意見ならEUC-JPを使えばいいし、他の言語の文字集合も使いたい
のならISO-2022を使えばいいでしょう。

> FedoraがUTF-8になったので危機感を感じてるのですが

なぜ?
0598login:Penguin04/03/08 10:42ID:Bwi62gzy
>>597
なんかいろいろと意味不明な文章ですが
> EUC-JP
→EUC
> ISO-2022
→文字集合指示のエスケープシーケンス
ですか?
それはともかく簡体字中国語はGB2312しか登録されてないから
ISO 2022じゃ話にならないです
0599login:Penguin04/03/08 10:53ID:xPUur27x
>>598
> なんかいろいろと意味不明な文章ですが

私もあなたの書いている文章の意味が分かりません。

> > EUC-JP
> →EUC

EUC-JPであってます。
590の人は「日本語を2バイトで扱いたい」ようでしたので。

> > ISO-2022
> →文字集合指示のエスケープシーケンス

ISO-2022を誤解しているのでは?

> それはともかく簡体字中国語はGB2312しか登録されてないから
> ISO 2022じゃ話にならないです

使えます。「ESC 2/4 4/1」でG0にdesignate。
0600login:Penguin04/03/08 10:54ID:Bwi62gzy
> GB2312しか登録されてない
訂正。CCITT Extended GBもありましたね。
0601login:Penguin04/03/08 10:55ID:xPUur27x
>>600
あぁ、そういう意味ですか。了解。
0602login:Penguin04/03/08 10:58ID:Bwi62gzy
>>598
> 590の人は「日本語を2バイトで扱いたい」ようでしたので。
ならそれに
> 「それぞれの言語でもっとも効率のよいエンコーディングを使うのが良い」と
> いう意見なら
という前提の答えをすること自体が変というだけです。
> ISO-2022を誤解しているのでは?
そのままお返しします。EUCもISO 2022の一種でしょう。
> 使えます。「ESC 2/4 4/1」でG0にdesignate。
でも結論は変わりませんね。
0603login:Penguin04/03/08 11:05ID:xPUur27x
>>602
> > 590の人は「日本語を2バイトで扱いたい」ようでしたので。
> ならそれに
> > 「それぞれの言語でもっとも効率のよいエンコーディングを使うのが良い」と
> > いう意見なら
> という前提の答えをすること自体が変というだけです。

いいえ。ちっとも変じゃないですね。

> > ISO-2022を誤解しているのでは?
> そのままお返しします。EUCもISO 2022の一種でしょう。

サブセットという方が適切ですね。

> > 使えます。「ESC 2/4 4/1」でG0にdesignate。
> でも結論は変わりませんね。

で、結論は?
0604login:Penguin04/03/08 14:41ID:CDAnHB+K
このスレに定期的に出ますね。
内容は高度なのに
精神年齢が低い人たちの争い。
0605login:Penguin04/03/08 15:43ID:W+OHYtj/
>>604
宗教戦争みたいなものですから。
0606login:Penguin04/03/08 18:49ID:ERahI9hZ
> 文化の違いを考慮するべきでしょう（私は日本語だけ2バイトにでいいですがｗ
文化の違いってのは各国の言語事情とかかな。
それ無視したら、言語統制して英語使えって事になりかねないから。
そしたらASCIIで足りるようになるけど。

> FedoraがUTF-8になったので危機感を感じてるのですが
なぜかと言うとUTF-8がメインになりそうだからでしょう。
実際には自分で他のコード選べませんから（今だってEUC前提のとこにSiftJISじゃあ…


難しいことは分からないけど
英数字1byteで日本語2byteで他の文字も2byteのコードが欲しい。
で、それを世界標準にしたい。メールもホームページも、それにする。

でも65536文字以上の文字が有るのはどしたらよかろ？
使わなそうな古代ＸＸ文字とか非常用漢字は4byte(6?)にでもすればいいのかな。
（3byteだと分かりにくそうだし、あとで足りないのはイヤだし…）
中国怒るかな？あと日本中国韓国の常用漢字いれても2byteでいけるのかな？
0607LightCone ◆sSJBc30S5w 04/03/08 21:12ID:JfYQzP4X
>>606
>あと日本中国韓国の常用漢字いれても2byteでいけるのかな？
これくらいだとなんとかなりそうな符号がUTFCP(UTFCP2も出た(笑))です。
0608LightCone ◆sSJBc30S5w 04/03/08 21:13ID:JfYQzP4X
UTFCP2のスペック(だけ):
http://www.nowsmartsoft.or.tv/nws/Japanese/chara_code_compare.htm
0609login:Penguin04/03/08 22:02ID:Jjoer6mt
>>590
その前にお前のレスの長さを半分にしてくれ。
0610login:Penguin04/03/08 22:36ID:kN4paUAc
長い行は黙って切り詰めるスレはここですか？
0611login:Penguin04/03/09 12:01ID:fWu0tHS8
>>606
そうやって考えられたのがTRONコード。
たとえ、明日宇宙人と交流が始まったとしても、
とっととフォントと割り当て作り配れば、そのままどのクライアントでも宇宙人の文字が読める。

運用や仕様に問題がないとは思わないし手放しで褒められるものじゃないみたいだけど、
その考え方自体は賛成。

0612login:Penguin04/03/09 13:14ID:yT9facPe
>>611
TRONコードは、ISO2022と同様の状態指定が必要なんでしたよね。

状態指定がある文字コード体系ではプログラミングし辛いので、EUCや、SJISが
登場したんだけど。
0613login:Penguin04/03/09 17:30ID:QwDvTJcd
状態指定していいのなら色々やれるようになるが……
現時点ではUTF-8の勝利っぽいな。日本語は3byteで我慢する。
通信量だってプロバイダからすればnyから見れば微々たるもの。
通信料固定の携帯会社は少し痛いかな。

でも日本と中国だけ自分の国の2byteコード使いそう…
UTFCP頑張って欲しいが国際的には全然ダメそう；；

あと最近電子政府とか言ってるけど文字コード何使うの？
かなり昔だが市役所行ったら漢字が出ないとか言われて
名前の漢字変えられたわな(いいのかな？まずい気がしたんだが…)
ちなみにWindowsでは変えられた方の漢字もでないんだが……
略字で登録してるとこと、正規で登録してるところがあるのが不便でつ。
戸籍略字に出来ないかなぁ………
0614login:Penguin04/03/09 20:21ID:2DDflbAy
役所はJEF相当の字が使えるんじゃないかな。
0615login:Penguin04/03/09 20:27ID:uH50TqIT
>>612
TRONコードは内部処理用にstatelessな表現もあったような気が。
以前何かの資料でちらっと見ただけで不確実すまんぬ。
0616LightCone ◆sSJBc30S5w 04/03/10 12:25ID:FD2GRc4Q
JIS第1水準、中国第1級の混合テーブル:
http://www.nowsmartsoft.or.tv/nws/Japanese/jpcn1.htm

2997文字+3749文字--->5025文字になった。
0617login:Penguin04/03/10 14:00ID:7wD2ks5p
解決策：日本語は使用せず、ネイティヴでそのまま使用する。
0618login:Penguin04/03/10 20:43ID:0cmjmGF/
はい、私はネイティヴな日本語を利用しております。
0619login:Penguin04/03/11 00:17ID:qo0Fn/uZ
UTF-8使ってれば問題ないぞ！
世界的にはUTF-8が標準だ！FedoraだってUTF-8だぞ！
1よUTF-8で決定して良かったな。WindowsもUTF-8使えるから大丈夫だぞ。
0620login:Penguin04/03/11 01:16ID:MFIoWDtG
詳しいことは知らないし、どうせ時代に流されるだけだけど
UTF-8になったら文字化けとかしなくなるの？
2バイト文字より3バイト文字の処理が遅くなったりしない？
0621login:Penguin04/03/11 02:42ID:J+pKjlDB
CPUの計算速度は秒間10億回、メモリーは秒百メガ以上転送します。
2バイトと3ﾊﾞｲﾄの差なんぞ。
0622login:Penguin04/03/11 04:34ID:3Et/51wn
とりあえずJISは死滅してるってことでいいんだよね？
少なくともEUCより先に使われなくなると思うけど
0623login:Penguin04/03/11 04:38ID:kmGNgh8j
iso-2022-jp のことなら、mail に使われてるよ。
0624login:Penguin04/03/11 12:15ID:5SXwbIF3
ふと思ったけど、7bit ISO 2022なcodesetが使われているのって実は日本だけ？

* USAや西欧はISO-8859-1
* 韓国はEUC-KR
* 台湾はBig 5
* 中国はGB2312→GB18030？
0625login:Penguin04/03/11 12:16ID:5SXwbIF3
>>624
ぐは、「mailに」使われていると書き忘れた。
0626login:Penguin04/03/11 12:55ID:Kb5yLeCK
中国はISO2022より前からHZ(7bit、stateful)が使われてたし、いらんのよ。
0627login:Penguin04/03/11 13:54ID:/yDh0VN8
>>624
韓国は、ISO-2022-KRを使っていた頃がありませんでしたか?
少なくとも俺の知っている留学生はそうだった。15年くらい前の話。
nemacs+sj3+sendmailって環境。(留学生の間だけだったのかも…)

今はEUC-KR固定なんですか?
0628login:Penguin04/03/11 14:11ID:5SXwbIF3
>>627
現在ではEUC-KRが使われているというか、ISO-2022-KRはほとんど使われて
いないそうな。グッデイに移る前のSylpheedのMLでそういう話が出てた。
どっかの日記にも引用されてたような。
062962804/03/11 14:47ID:5SXwbIF3
>>628
見つけた。
ttp://gotom.jp/~gotom/diary/?200010b#200010161S3
0630login:Penguin04/03/11 20:04ID:7rWfBDb3
>>620
JISX0208 <-> UNICODE 間での変換表はすでに混乱しているわけだが。
このへんでも見とけ -> http://www.denpa.org/~go/denpa/200402/from01.html#01_2

>>619
はい、Fedoraはどの変換表を使ってるのかくらい知ってるよね？
で、Java方式？ Windows方式? それとも Mac方式？ それとも Fedora 独自ですか(w
0631login:Penguin04/03/11 20:42ID:ud4fgRTq
変換しなければいいんだろ？UNICODE外のエンコードは捨て。時代遅れ。
0632login:Penguin04/03/11 20:57ID:O42OfURm
と、Shift_JISっぽいエンコードで書き込む、自称時代遅れの631。
0633login:Penguin04/03/11 21:18ID:n7h4RRup
Unicode（って何？）で書き込むスレとかあったら面白いかも。
0634login:Penguin04/03/12 00:11ID:80GSSPnR
634get
0635login:Penguin04/03/12 00:26ID:zv+9d8+B
？x3053;？x3093;？x306a;？x611f;？x3058;？x003f;
0636login:Penguin04/03/12 00:29ID:zv+9d8+B
BBS_UNICODE=changeだった…。
0637login:Penguin04/03/12 21:05ID:8N+xdVQn
>>627
ISO-2022-KR じゃなくて、ks_c_5601-1987 かな。
その名に反して、事実上 EUC-KR。
(あと、SJIS的な空き領域にたっぷり詰め込まれてるらしいけど。

ttp://www.mew.org/ml/mew-dist-1.94/msg07160.html

あたり参照。
0638login:Penguin04/03/14 06:05ID:p3IFOeaA
TRON code使えばいいじゃん
0639login:Penguin04/03/15 00:07ID:FjBdRajh
>>637
えーと、7bit ISO 2022だったけど、ISO-2022-KRじゃなかった。
muleの古いdocument, ISO2022.jaより、

*korean-mail* -- 韓国のネットワークで使用される符号系
1. G0 <- ASCII, G1 <- KSC5601, G2,3 <- 使用せず
2. No.
3. Yes.
4. Yes.
5. 7ビット環境
6. Yes.
7. No.
8. No.

G1使っているから、ISO-2022-JP風文字集合違いではない。

0640login:Penguin04/04/19 18:35ID:TRVyblqf
m17n-libに対するネガティブな評価
http://tabesugi.net/memo/cur/cur.html#172331
0641login:Penguin04/04/19 19:37ID:TxiUU5Sx
その人、かなりアポなような気がする。
0642login:Penguin04/04/19 20:43ID:WBHL9VYt
気がしても言っちゃいけないこともある。見ないふりをしてあげるのが礼義
0643login:Penguin04/04/19 20:58ID:TRVyblqf
でも実際のところ、これって流行るのか？
0644login:Penguin04/04/20 01:16ID:vUH5wJkn
m17n.orgに置いた位じゃ無理だろう。
freshmeatあたりで宣伝するとか。
0645login:Penguin04/04/20 06:55ID:rTQHYqpZ
>>644
> m17n.orgに置いた位じゃ無理だろう。
なんで?
0646login:Penguin04/04/20 07:20ID:/Sip6aJR
そもそもm17n.orgなんて知らないし。
0647login:Penguin04/07/01 15:11ID:dfbyP3DL
良スレが埋もれてしまうのは惜しいのでage

文字コード問題って複雑でわからんので、「加護ちゃんはウンコするよ派
/しないよ派/加護ちゃんの肛門から出るのはウンコじゃないよ派」
みたいにわかりやすく図示してくれんもんかねぇ＞識者様
0648login:Penguin04/07/01 23:44ID:gL6c8Bme
>>647
巣に帰れ。
0649login:Penguin04/07/02 04:21ID:ijjyl7Oa
文字コード・ストーカー事件
http://anthill.hp.infoseek.co.jp/misc/memorandum/stalker.html
0650login:Penguin04/07/26 20:35ID:9+dUBwXS
IBMのEUCコード表に、日本語EUCでは文字型表示装置における表示幅が
定義されてるって書いてたんだけどホント?
0651login:Penguin04/07/31 06:35ID:mohvMq6x
EUCjpなんて駄目駄目よ

鄧小平とかマップできてないだろう。
まだMSKANJIの方がよいな
0652login:Penguin04/07/31 08:09ID:euiPIjU0
>>651
鄧 8F E2 C7
小 BE AE
平 CA BF
0653login:Penguin04/08/04 12:27ID:Tzmg5Mgq
EUCなんかよりISO 10646
0654login:Penguin04/08/21 13:06ID:sZauC9ye
各ディス鳥のSJIS化の情報を収集に来たのだが、
文字コードのスレになってて期待ハズレ。

と、保守下記子。
0655login:Penguin04/08/21 23:47ID:WhdMMhrh
ディス鳥のSJIS化???
0656login:Penguin04/08/21 23:58ID:fky5S1QK
単純にlocaledefでつくってしまえばよいと思われ
EUCやUTF-8のメッセージカタログが入っていれば
コード変換も行ってくれるし

まぁテキストファイルなんかの文字コード変換は自前でやるアプリもあるから
ロケールが直接影響するのは
コード変換を自前でやらないアプリと、ファイル名くらいの気もするが
0657login:Penguin04/08/25 21:00ID:jObGm5N7
ファイルやデータのやり取りが決め打ちな組み込みに近いミニディストリでもない限り
現行のソフトを使う限りにおいては「SJIS化」には意味がないな。
0658login:Penguin04/08/31 13:53ID:VTbpM5cz
こんなスレが立ってしまいましたよ
http://pc5.2ch.net/test/read.cgi/unix/1093879892/
0659login:Penguin04/08/31 14:03ID:Z/eOEk8J
､筅ﾞ､､､鬢筍｢ｵｭﾇｰ･ﾞ･ｭ･ｳｽﾁ! >>658
0660login:Penguin04/10/05 20:31:01ID:Bv1T0iZx
記念カキコ
0661login:Penguin04/10/07 05:42:33ID:KhLYeD11
>>658
スレタイもEUCにしろ
0662login:Penguin04/10/17 23:49:26ID:DOTd84Rc
Unicodeのいろんな問題見てたら、俺としては一つの結論にたどり着いたわけだ。

Unicodeを日本語、英語含めて全言語に適用できる文字コードにしようとするのは間違ってる。
UTF8はあくまで、他の言語もある程度満足に扱える、拡張ASCIIコードと考えよう。

今のコンピュータ業界では世界共通文字コードであるASCIIが拡張されて、
各国の言語がとりあえず使えるようになったんだ。

ASCIIだけでは不満だった人達がSJISやEUCなどを使っていたように、
Unicodeだけでは不満な人達はTRONコードでも超漢字でも、独自規格でも自由にしなよ。
でも、みんなに配るときは、UTF8で書かれた文章も付けて。
だいたいはそれで事足りるだろうし、それで不満ならそのコードが読める環境を用意するから。

＃そうして歴史は繰り返す
0663login:Penguin04/10/17 23:54:44ID:DOTd84Rc
↑Unicodeって書いたり、UTF8って書いたりしててわけ分からんorz

UnicodeをUCS-2と読みかえてくれ。
UTF8はUCS-2のエンコード方式の中で、ASCIIと互換性があり、
その中で一番一般的なように思えるもの、というような意味合い。
0664login:Penguin04/10/18 23:17:47ID:g1D5JuB1
>>662-663
はぁ？？でなおしてこい。
0665login:Penguin04/10/19 23:23:04ID:Al9qBxAQ
unicodeでいいよ。
m17n楽だから。
0666login:Penguin04/12/01 22:05:16ID:c7RgDl8N
ISO-2022-JPがISO/IEC 2022に適合しないのってどのへん?
0667login:Penguin04/12/01 22:27:58ID:w/F2PYLo
改行でASCIIに戻るとこ。
066866704/12/01 22:37:58ID:w/F2PYLo
おおっと、ちょっと嘘書いちゃった。RFC 1468のこのへんかな。

> オンラインにJIS X 0208 文字がある場合、行の終（すなわちCRLFの前）
> ASCIIもしくはJIS X 0201の"Roman"セットに切り替えなければなりません。
> これは、次の行が直前の行の終の前で切り替えられた文字セットではじます
> ことを意味します。
> また、テキストはASCIIで終わらなければなりません。

http://www.asahi-net.or.jp/~bd9y-ktu/dtd_f/rfc_f/rfc1468j.html
0669login:Penguin04/12/02 00:01:17ID:/R16VbWh
>>668
別にそれは更なる制約だから問題ないでしょ。

同一文字の二重符号化禁止でしょ。
半角のAと全角のA。Unicodeではあれだけど、
ASCII, JIS X 0201, JIS X 0208では同じ文字。
だから「AはASCIIのAのみを利用する」という約束がないと駄目なんじゃない?
067066704/12/02 01:37:50ID:+PbXBE2p
>>669
> 同一文字の二重符号化禁止でしょ。
なんのこっちゃ。
「図形文字の一意な符号化」が何の関係があるの?
ISO-2022では「要求される場合がある。その場合は...」と書いてあるだけだろう。

> 別にそれは更なる制約だから問題ないでしょ。

制約じゃないだろ。明らかにISO-2022の範囲外。
067166704/12/02 01:44:22ID:+PbXBE2p
>>669
ちょっと厳しく書きすぎたかも知れない。
どう誤解してるのかに興味があるから、もう少し詳しく書いてみて。
669の文章から推測すると、
「ISO-2022では一意な符号化が要求されているが、ISO-2022-JPでは
そのへんが定められていないから違反だ」というところか?
0672login:Penguin04/12/02 06:15:35ID:CCz/AXQj
> 別にそれは更なる制約だから問題ないでしょ。
http://web.archive.org/web/20040105042210/www.xinada.ne.jp/~handa/tech/Scribbles/RFC1468-and-ISO2022
とか
http://suika.fam.cx/~wakaba/-temp/wiki/wiki?ISO-2022-JP%A4%CEISO%2FIEC%202022%C5%AC%B9%E7%C0%AD
の受け売り?
こんな明らかな間違いに今まで誰も突っ込んでないのが不思議なんだが
受信装置の適合性は無視ですか? でもSuikaWikiのすぐ下読むと
> 文字を実装しなくて良い、はデータの適合性には影響しないでしょうが、受信装置の
> 適合性で問題がある可能性があります。
とか
> (受信装置?の適合性は疑わしい可能性がありますが) データの適合性には影響しない
> でしょう。
とか書いてるしマジわけわかんねぇ
問題: 上記2つの文書にはもう1つ共通する間違いがあります。それはなんでしょう?

> 同一文字の二重符号化禁止でしょ。
それが関係するのはG0～G3の複数のバッファから呼び出す場合で、
ISO-2022-JPみたいに指示のみで切り替える場合には関係ない。

少しは規格票読んだら?
067366704/12/02 16:50:35ID:+PbXBE2p
>>670
>> 別にそれは更なる制約だから問題ないでしょ。
> 制約じゃないだろ。明らかにISO-2022の範囲外。

ごめん、俺が間違ってた。これは制約にすぎないな。
# ASCIIやJIS X 0201 Romanにもどす話は、JIS X 0208:1997 附属書2に書いてあるだけか。

>> 同一文字の二重符号化禁止でしょ。

670 の追記だが、ISO/IEC 2022やJIS X 0202の
「7.5 Unique coding of graphic characters(図形文字の一意な符号化)」
では、一意な符号化はmustではないし、shouldでもない。

そもそも 672 の言うように、ISO-2022-JPのようなG0のみの使い方なら関係ないとも
考えられる。
067467204/12/03 03:59:08ID:9rXlF8ug
解答例:
改訂番号の識別機能を使うとき、それがエスケープシーケンスとしてCCデータ要素
に埋め込まれている必要はない。
したがって、改訂番号識別シーケンスを使わないことをもってただちに不適合である
とは結論できない。
0675login:Penguin05/01/23 19:59:57ID:pIU32Ad7
明けましておめでとう
0676login:Penguin05/01/23 23:18:08ID:5luBPpp6
ことよろ
0677login:Penguin05/02/12 22:41:24ID:q+2/aCG1
CSIって具体的にどういう実装？
0678login:Penguin2005/07/13(水) 03:16:01ID:GiU0rXXK
　　
0679login:Penguin2005/07/20(水) 09:02:03ID:6Oqfp2xg
ユニコードで多国籍言語が混在できるわけだから、もうユニコードしかないだろ。
0680login:Penguin2005/07/21(木) 03:14:07ID:OTpKdDbb
最初っからワイドキャラクター4バイト扱いになってればよかったのにね
■ このスレッドは過去ログ倉庫に格納されています