!![[Re: ISO-2022-JP-2004 vs Unicode mapping table|BBS-相談所/3]] - えむけい (2006年06月06日 06時01分35秒) ISO-2022-JP-2004の対応表ですが、ISO/IEC 646 IRVと重複する文字も漢字7ビット符号の対応表と同様に割り当てるのではないですか? 重複符号化になりますが、ISO-2022-JP-2004に関しては(EUC-JIS-2004やShift_JIS-2004と異なり)使用禁止も「慣用的な利用との互換」もJIS X 0213の附属書に規定されていません。 つまりFULLWIDTHに割り当てる根拠がありません(参考として「Fullwidth:」を付けるのはかまわないと思いますが)。 *おや。どうもそのように読めますね。JIS X 0208の附属書2 (RFC1468符号化表現) も同様のように見えます。これはどう解釈すれば良いのでしょう。規格の誤り? - やの (2006年06月07日 23時42分45秒) *私は誤りではなく、ISO-2022-JP的に文字集合を切り替えて使う場合に重複符号化が発生する可能性があるのは仕様なのだと解釈しています。実際、たとえば1b 24 42と1b 24 28 51ではほとんどの文字が重複していますが、それを理由にどちらかの使用を禁止されたりはしていません(1b 24 42の一部の文字は使用禁止ですが、重複符号化を理由としているわけではありません)。SuikaWikiの[図形文字の一意な符号化|http://suika.fam.cx/~wakaba/-temp/wiki/wiki?%BF%DE%B7%C1%CA%B8%BB%FA%A4%CE%B0%EC%B0%D5%A4%CA%C9%E4%B9%E6%B2%BD]が参考になると思います。 - えむけい (2006年06月08日 12時47分09秒) *うーん、するとUnicodeに変換したときに「全角・半角」の区別が保存されなくなりますよね。それに、ISO-2022-JP{-3|-2004}で「全角英数」を"FULLWIDTH"の方に変換している実装は全部間違いということになってしまいますけど、それで良いのでしょうか? - やの (2006年06月08日 22時44分50秒) *そもそもJIS X 0213の英数字は「全角」ではないので、区別が保存されないのはそういうものでは? というしか。EUC-JIS-2004とShift_JIS-2004ですら同じJIS X 0213の文字が「半角」になったり「全角」になったりしてますし。規格を字義どおりに解釈するなら、ISO-2022-JP{-3|-2004}でFULLWIDTHに割り当てる実装は「全部間違い」としかいいようがないです。[XML MOJI 00655|http://www2.xml.gr.jp/log.html?MLID=xmlmoji&N=655]は私のお気に入りの言葉です。川俣氏がWindowsの変換表の誤りに関してダブルスタンダードなのは残念というほかありませんが。 - えむけい (2006年06月09日 09時03分54秒) *JIS X 0213:2000の本体の9.符号拡張法、9.2には、「JIS X 0201又はISO/IEC646と漢字集合とを同時に指示する場合、これまでの慣用的な利用との互換を目的としてだけ、附属書5表2に規定される文字をJIS X 0201又はISO/IEC 646とで規定される文字とは異なった図形文字として用いてもよい。」とあります。しかし附属書2から本体9.を参照できるのかどうかは、よく分かりません。 - さだひろ (2006年06月10日 10時09分43秒) *もう少し考えてみましたが、本体9.2も附属書2も漢字集合として本体6.5.1で規定するものを用いる点では共通しています。すると、附属書2が、本体9.2における「JIS X 0202の符号拡張法を主とする環境で」に該当するのかどうかなのでしょうが、どうなのでしょう... - さだひろ (2006年06月10日 10時28分00秒) *上で「全角・半角」という言葉を使ったのは便宜のためです。本質的には、同じ文字に異なる符号化表現を重複して割り当てている場合に、コード変換で重複が失われないようにするようUnicodeでは配慮されており、それがfullwidth/halfwidth formの意義である筈です(「互換漢字」の存在もその目的)。とすれば、ISO-2022-JPでfullwidth formを使わない理由は存在しないはずだと言うのが私の意見です。規格は字義通り解釈しなければならないと言うのは当然のことですが、規格の誤りを発見し改められるようにすることも大事なことだと思います。 - やの (2006年06月14日 23時21分36秒) *えっと、JIS X 0213:2000において、EUC-JISX0213が附属書5を参照しているのに、ISO-2022-JP-3が附属書5を参照していなかった理由ですけど、これ、ISO/IEC 2022を厳密に解釈したら、こうなったというだけのことです。EUC-JISX0213の場合は、G0とG1に「同じ名前」の文字(たとえばLATIN CAPITAL LETTER A)が収録されてるので、そのままだとG1の1-3-33とかが使えなくなっちゃいますよね。で、それが困る人は代替名称にするわけです。でも、ISO-2022-JP-3はG0を変えながら使うので、「同じ名前」の文字が同時にG0には現れない。ですので、ISO/IEC 646 IRVの4/1もJIS X 0213の1-3-33もどちらも使えるので、ISO/IEC 2022上はあえて代替名称を使う理由がないわけです。じゃあ、ISO-2022-JP-3では代替名称を使っちゃいけないか、っていうと、それはもちろん「慣用的な利用との互換」のためには使ってもかまわないわけで、それがわざわざ附属書5を独立させている理由でもあるわけです。 - 安岡孝一 (2006年06月25日 22時07分36秒) *あ、そうか、やのさんは、JIS X 0213での「名前」を、JIS X 0221-1の「名前」と同一視してらっしゃるんですね。それ、厳密には違いますよ。JIS X 0213での「名前」は、JIS X 0202の5.3でいう「名前」でもあるんです。その意味で、JIS X 0213:2000附属書5には、あえてUCSを示さなかったんです。ただ、1-1-17の代替名称をドタンバで「FULLWIDTH OVERLINE」にできなかった(理由はJIS X 0221-1:2001附属書P参照)のは、いまだもってクヤシかったりしますけど。 - 安岡孝一 (2006年06月26日 00時10分27秒) *なるほど、附属書5は独立しているから附属書2から参照しても構わないと。考えてみれば附属書4や6も参照するわけだから、附属書5だけ参照してはいけない理由はないですよね。言われてみれば単純なことでした。 - やの (2006年06月29日 22時17分41秒) {{comment}}