アカウント名:
パスワード:
詳しい理由はわかりませんが、こうしてまた漢字が一文字増えるのですね。(本当に増えたのか既存の漢字に該当する字があったのかすら、わからない門外漢ですが。)
http://mojikiban.ipa.go.jp/1287.html [ipa.go.jp]
Q1. 文字情報基盤とは何ですか?A1. 人名等を正確に表記する必要のある行政業務で用いられる漢字約6万文字を整備して国際標準化を行う事業です。詳しくはこちらをご覧ください。成果物としての文字フォントと文字情報一覧表を無償で提供しています。
Q5. 6万文字を使う必要があるのでしょうか?A5. (略)氏名など、個人のアイデンティティに関わる文字を厳密に指定すべき用途(略)逆に、氏名の表記等、個人のアイデンティティに関わる文字においては、意味や読みが同じだからといって、複数の
文字が増えたかどうかはともかく、文字コードは増えたよな。
サロゲートペアってのは、UTF-16に特有の現象で、要するに「本物のユニコード」は65535文字に納まりきらないから、論理的に考えて16bitでは表現できず、「ユニコードの1文字」に対して「16bitのコード」を複数使って表現する話。つまり、エンコーディングが16bit単位だからややこしくなっているだけで、最初からユニコードは32bitなんだ、と思えばこんな問題は発生しない。
一方、IVS(表意文字異体字セレクタ)は、ユニコードに番号が振られていない字体を特殊なユニコードで指定する試み。つまり、異体字がある文字は[ユニコード上の文字情報]に1文字、[異体字情報]に1文字のユニコードを使うので、単純に合計すると64bitを一つの字形で使うことになる。実際にUTF-8の「葛」は3バイトだが、異体字セレクタはUTF-8で4バイト必要なので、合計7バイトになる。
ここで最も問題なのは、同じ字形でもフォント製作者によって異なる「異体字情報」が割り当てられていること。例えば、丸い方の「葛」はAdobeによって、「17」という異体字番号が振られている(1〜17は漢字以外のためのオフセットなので、実質0番目)ので、「葛」の後に「U+E0100」を置けばAdobe系のフォントでは丸い「葛」となる。一方、文字情報基盤は丸い方の「葛」に「20」という異体字番号を振っているので、文字情報基盤系のフォントでは「葛」の後に「U+E0103」を置けば丸い「葛」になる。
「葛」に異体字があるのは確かなんだから、それを表現するためにコードが増えるのは仕方がない。許容範囲。しかし、「葛」の異体字は2つなのに、「葛」に振られた異体字番号は合計で4つある。これはいかんでしょ。異体字セレクタなんて、10年ちょいしか歴史がないのに、既に国内事情だけですらもうバベルの塔状態なんだから。もちろん、フォント実装の最先端にいる人たちは後方互換の破棄で失われる利益やプライドを鑑みた上で、真面目に頑張ったんだろうとは思うが、まとめて傍から眺めると、愚行としか言いようがない。実用上、これらも「包摂」するしかないんでしょ。この包摂情報を各ユーザーのビューアがデータベースで持っておいて、レンダリング時に照合するとか、まさに誰得。
外資系独占企業と政府系組織の仁義なき戦いだよ、ほんと。
もうちょっと詳しく言うと、文字情報基盤が主張する(つまり、戸籍で使ってる)「葛」の異体字は8種類(U+E0102〜U+E0109)あって、Adobeは2種類(U+E0100とU+E0101)しかなく、形だけで言えばその2種類は8種類にサブセットとして含まれている。ただし、Adobeの方が古い。http://www.unicode.org/ivd/data/2014-05-16/ [unicode.org]
UTFとUCSをごっちゃにしてませんか?
こうなったからには一緒ですよ。
自分の無知をごまかすのは良くないよ。
UTFって何ですか?聞いたことないんだけど。
なんでそんな人がこのツリーの末端にわざわざレス付けるのか…
# 開き直りかたが小学生レベル
UCS Transform FormatUCSとUTFが一緒となると、スタックがオーバーフローしそうな予感がします
GNU's Not UnixとかPHP: HyperText ProcessorとかWine Is Not an Emulatorとかが生きているようなのでなんとかなるのではないでしょうか。
> 実際のところ日本ローカルな問題だから割とどうでもいいような。
日本語向けのコレクションしか登録されていないあたりが何より雄弁に物語っていますよね。標準規格にするから形式的には地域依存しない体裁を整えたけど、事実上もっぱら日本のためだけに用意された仕様。UCSの統合規則は中国の印刷通用漢字字形表とおおむね一致しているので中国はそもそもUCSでそれほど困っていない(UROは中国主導で定められたのだから当然かも知れないが)。実際G Sourceの互換漢字は存在しない(CJKC_SR.txtにG欄は存在しない)。
> Cは簡体字にユニファイするだけあ、一つ誤解を訂正しておくと、中国は確かに印刷通用漢字字形表(現在は通用漢字規範表)に基づいて 新字形 [wikipedia.org]を標準と定めているので旧字形との違いには頓着しないようだけど、簡体字と繁体字は全部分離して収録している。CJKC_SR.txtにG欄がないのは、中国は必要なら何としてでも(たとえば架空の国内規格をでっち上げてでも)統合漢字にねじ込んでいるからでもある。あと中国は昔から合成で一文字を表すのが嫌いなようで、たとえばTaboo var [unicode.org]
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー
互換性維持 (スコア:1)
詳しい理由はわかりませんが、こうしてまた漢字が一文字増えるのですね。
(本当に増えたのか既存の漢字に該当する字があったのかすら、わからない門外漢ですが。)
Re: (スコア:1)
http://mojikiban.ipa.go.jp/1287.html [ipa.go.jp]
Q1. 文字情報基盤とは何ですか?
A1. 人名等を正確に表記する必要のある行政業務で用いられる漢字約6万文字を整備して国際標準化を行う事業です。詳しくはこちらをご覧ください。成果物としての文字フォントと文字情報一覧表を無償で提供しています。
Q5. 6万文字を使う必要があるのでしょうか?
A5. (略)氏名など、個人のアイデンティティに関わる文字を厳密に指定すべき用途(略)逆に、氏名の表記等、個人のアイデンティティに関わる文字においては、意味や読みが同じだからといって、複数の
Re:互換性維持 (スコア:0)
文字が増えたかどうかはともかく、文字コードは増えたよな。
サロゲートペアってのは、UTF-16に特有の現象で、要するに「本物のユニコード」は65535文字に納まりきらないから、論理的に考えて16bitでは表現できず、「ユニコードの1文字」に対して「16bitのコード」を複数使って表現する話。つまり、エンコーディングが16bit単位だからややこしくなっているだけで、最初からユニコードは32bitなんだ、と思えばこんな問題は発生しない。
一方、IVS(表意文字異体字セレクタ)は、ユニコードに番号が振られていない字体を特殊なユニコードで指定する試み。つまり、異体字がある文字は[ユニコード上の文字情報]に1文字、[異体字情報]に1文字のユニコードを使うので、単純に合計すると64bitを一つの字形で使うことになる。実際にUTF-8の「葛」は3バイトだが、異体字セレクタはUTF-8で4バイト必要なので、合計7バイトになる。
ここで最も問題なのは、同じ字形でもフォント製作者によって異なる「異体字情報」が割り当てられていること。例えば、丸い方の「葛」はAdobeによって、「17」という異体字番号が振られている(1〜17は漢字以外のためのオフセットなので、実質0番目)ので、「葛」の後に「U+E0100」を置けばAdobe系のフォントでは丸い「葛」となる。一方、文字情報基盤は丸い方の「葛」に「20」という異体字番号を振っているので、文字情報基盤系のフォントでは「葛」の後に「U+E0103」を置けば丸い「葛」になる。
「葛」に異体字があるのは確かなんだから、それを表現するためにコードが増えるのは仕方がない。許容範囲。しかし、「葛」の異体字は2つなのに、「葛」に振られた異体字番号は合計で4つある。これはいかんでしょ。異体字セレクタなんて、10年ちょいしか歴史がないのに、既に国内事情だけですらもうバベルの塔状態なんだから。もちろん、フォント実装の最先端にいる人たちは後方互換の破棄で失われる利益やプライドを鑑みた上で、真面目に頑張ったんだろうとは思うが、まとめて傍から眺めると、愚行としか言いようがない。実用上、これらも「包摂」するしかないんでしょ。この包摂情報を各ユーザーのビューアがデータベースで持っておいて、レンダリング時に照合するとか、まさに誰得。
外資系独占企業と政府系組織の仁義なき戦いだよ、ほんと。
もうちょっと詳しく言うと、文字情報基盤が主張する(つまり、戸籍で使ってる)「葛」の異体字は8種類(U+E0102〜U+E0109)あって、Adobeは2種類(U+E0100とU+E0101)しかなく、形だけで言えばその2種類は8種類にサブセットとして含まれている。ただし、Adobeの方が古い。
http://www.unicode.org/ivd/data/2014-05-16/ [unicode.org]
Re: (スコア:0)
UTFとUCSをごっちゃにしてませんか?
Re: (スコア:0)
こうなったからには一緒ですよ。
Re: (スコア:0)
自分の無知をごまかすのは良くないよ。
Re: (スコア:0)
UTFって何ですか?聞いたことないんだけど。
Re:互換性維持 (スコア:1)
なんでそんな人がこのツリーの末端にわざわざレス付けるのか…
# 開き直りかたが小学生レベル
Re: (スコア:0)
UCS Transform Format
UCSとUTFが一緒となると、スタックがオーバーフローしそうな予感がします
UTF is not a Transform Format (スコア:0)
GNU's Not UnixとかPHP: HyperText ProcessorとかWine Is Not an Emulatorとかが生きているようなのでなんとかなるのではないでしょうか。
Re: (スコア:0)
実際のところ日本ローカルな問題だから割とどうでもいいような。
CJKVのうちCは簡体字にユニファイするだけ、というか標準字形に包摂を決めるのは歴代王朝の重要な業務だからね。そこで俺の名字は代々これとか言っても、それは皇帝の名前と被るからお前が改名しろと言われる社会だし。台湾の事情は知らんがどうせそのうち中国に吸収されるし、KとVは日常ではもう漢字使ってないし。
Re: (スコア:0)
> 実際のところ日本ローカルな問題だから割とどうでもいいような。
日本語向けのコレクションしか登録されていないあたりが何より雄弁に物語っていますよね。標準規格にするから形式的には地域依存しない体裁を整えたけど、事実上もっぱら日本のためだけに用意された仕様。
UCSの統合規則は中国の印刷通用漢字字形表とおおむね一致しているので中国はそもそもUCSでそれほど困っていない(UROは中国主導で定められたのだから当然かも知れないが)。実際G Sourceの互換漢字は存在しない(CJKC_SR.txtにG欄は存在しない)。
Re: (スコア:0)
> Cは簡体字にユニファイするだけ
あ、一つ誤解を訂正しておくと、中国は確かに印刷通用漢字字形表(現在は通用漢字規範表)に基づいて 新字形 [wikipedia.org]を標準と定めているので旧字形との違いには頓着しないようだけど、簡体字と繁体字は全部分離して収録している。CJKC_SR.txtにG欄がないのは、中国は必要なら何としてでも(たとえば架空の国内規格をでっち上げてでも)統合漢字にねじ込んでいるからでもある。
あと中国は昔から合成で一文字を表すのが嫌いなようで、たとえばTaboo var [unicode.org]