文字コード統一スレ 1文字目

1 名前：とりあえず立ててみた [05/02/24 00:07:38 ] プログラムにおける文字コードの取り扱いについて議論する統一スレッド です。 ほぼ前スレ 【UTF8】文字コード変換【SJIS】 pc5.2ch.net/test/read.cgi/tech/1063177450/ 参考ホームページ Unicode Home Page www.unicode.org/ Java Character Encodings www.ingrid.org/java/i18n/encoding/ euc.JP: tech docs, BeOS tools euc.jp/ ISO-IR - 2.8.1 Coding systems with Standard return www.itscj.ipsj.or.jp/ISO-IR/2-8-1.htm ISO-IR - 2.8.2 Coding Systems without Standard return www.itscj.ipsj.or.jp/ISO-IR/2-8-2.htm 75 名前：デフォルトの名無しさん [05/03/02 08:36:34 ] ところで，Unicode って既存のコードとのラウンドトリップは考慮されてるの？ つまり Unicode に変換されたとたん，元のコードでは区別されていた文字が 同じ文字にマップされたりはしないの？ それはいわゆる機種依存文字も含めて？ 76 名前：デフォルトの名無しさん mailto:sage [05/03/02 08:53:12 ] 文字コードを作る人は馬鹿ですか？ なんで固定バイト数にしないんだよ。 先頭数ビットを国コードにして残りを文字コードに割り当てる。 似ている文字でも国ごとに別の文字コードにするべきだ。 そして検索の機能として文字コード検索と、文字形検索の二つに分ける。 77 名前：デフォルトの名無しさん mailto:sage [05/03/02 09:06:12 ] >>76 UNICODE棄てれば実現可能かもね 78 名前：デフォルトの名無しさん mailto:sage [05/03/02 10:18:45 ] >>76 そしてPhishingが横行 79 名前：デフォルトの名無しさん mailto:sage [05/03/02 10:38:34 ] 多言語ドメインなんてくだらないものは捨てちまえ。 80 名前：デフォルトの名無しさん mailto:sage [05/03/02 14:57:31 ] >>76 Emacsの内部コードがそんな感じよ。文字列表現はマルチバイトだけど。 国ごとじゃなくて文字集合ごとだけど実質あまり変わらん。 81 名前：デフォルトの名無しさん mailto:sage [05/03/02 15:50:16 ] マジな話、文字形検索（文字コードではなく文字の形で 検索すると言う意味）って考え方ないの？ 同じ形の字でも国が違えば検索に引っかからない方がいいだろうし、 同じ国でちょっと違う形の字でも同じとして検索した方がいいこともあるだろうし、 国は分からないけど、すべての国対象で似ている字を検索したいこともあると 思うんだけどなぁ。 82 名前：デフォルトの名無しさん mailto:sage [05/03/02 15:55:33 ] 1 I l | ! i │ �@ �T (以下略)をどこまで一緒にするのやら 83 名前：デフォルトの名無しさん mailto:sage [05/03/02 16:54:58 ] >>75 文字コードA →Uniocde→文字コードA と、元に戻せることは配慮されてる。 そのために互換用文字とか元規格分離の原則とかがあるわけで。 機種依存文字は、例えばJIS X 0208のShift_JISとMicrosoftのCP932と Appleの拡張Shift_JISは「別の文字コード」なので、Unicodeを介した それぞれの変換で情報が失われないことは配慮されない、という扱い。 84 名前：デフォルトの名無しさん [05/03/02 19:56:53 ] <とくを一緒にされなかっただけでも不幸中の幸い 85 名前：デフォルトの名無しさん mailto:sage [05/03/02 23:31:01 ] へとヘは？ 86 名前：デフォルトの名無しさん mailto:sage [05/03/03 02:37:43 ] タと夕とか トと卜とか 87 名前：デフォルトの名無しさん mailto:sage [05/03/03 04:42:46 ] ロとか口とか 88 名前：デフォルトの名無しさん mailto:sae [05/03/03 11:42:20 ] (以下略 89 名前：デフォルトの名無しさん mailto:sage [05/03/03 16:02:46 ] C++ で文字コード変換したいと思った場合、 Windows + IE5.5 ならば、IMultiLanguage3 を通して変換すればいいが、 UCS-4 のコードから、文字種別などの文字情報を取得するライブラリが OS標準にないというのが悲しい。 90 名前：デフォルトの名無しさん mailto:sage [05/03/03 16:09:52 ] Windowsの事しか考えられないバカは去ってくれ。 91 名前：デフォルトの名無しさん mailto:sage [05/03/03 18:27:33 ] >>90 そりゃ言いすぎ(w けど、 > Windows + IE5.5 ならば、IMultiLanguage3 を通して変換すればいいが、 つーのが、もうスレの主旨には全く合わないな。 それが良いかどうか語りたいようなヲタの住むスレなんだから。 92 名前：デフォルトの名無しさん mailto:sage [05/03/07 22:10:55 ] >>73 Unihan-4.0.1d4で修正されてますた。 つーかよく見たらUnihan-4.0.1d3のヘッダにも > Similarly, U+F92F should map to kIRG_KSource 0-523E, not 0-523F, and U+F98D should > map to kIRG_KSource 0-663C, not 0-663D. って追加されてた。正直スマンカッタ＞unicode.orgの中の人 93 名前：デフォルトの名無しさん mailto:sage [05/03/07 22:13:29 ] Unihan-4.1.0d4とUnihan-4.1.0d3の間違い 94 名前：デフォルトの名無しさん [05/03/08 01:19:00 ] iconv(3) の引数 inbuf の型が、glibc 版だと char** になってて libiconv 版だと const char** なのがイヤン 95 名前：デフォルトの名無しさん mailto:sage [05/03/10 11:13:14 ] >>94 SUS的にはchar**が定義らしいが、現実的にはconst char**じゃないと 面倒なんだよな。 96 名前：デフォルトの名無しさん [05/03/10 13:04:58 ] >>83 に関連した疑問なんだが，各種日本語文字コード，Unicode間で 縦横無尽にマッピングしまくッっても安全な集合って どこかで定義されてない？？ 97 名前：デフォルトの名無しさん mailto:sage [05/03/10 15:21:23 ] サロゲートうんこ 98 名前：デフォルトの名無しさん mailto:sage [05/03/10 21:21:44 ] 内部はgrapheme clusterを単位にした固定長コードにでもしないと 面倒でやってられんぞ 99 名前：デフォルトの名無しさん [05/03/11 00:57:47 ] >>95 www.opengroup.org/onlinepubs/007908799/xsh/iconv.html では const 付きだけど www.opengroup.org/onlinepubs/007908799/xsh/iconv.h.html には const 付いてない(つД`) 100 名前：デフォルトの名無しさん mailto:sage [05/03/11 02:55:46 ] >>96 \~￣―＼〜‖…−￥¢£¬とか CP932におけるNEC選定IBM拡張文字 とか 古えの半角ｶﾅ とかの話? 101 名前：デフォルトの名無しさん mailto:sage [05/03/11 05:35:24 ] �@�A�B�C�D�E�F�G�H 102 名前：デフォルトの名無しさん [05/03/11 05:55:24 ] >>100 そう．そういう微妙な文字以外の 「安全な」文字の集合ってどこかでまとめてくれてないかな，と． 自鯖の掲示板で，サニタイジングのついでに警告を出したい． 103 名前：デフォルトの名無しさん mailto:sage [05/03/11 06:33:51 ] >>98 コードポイント３つ４つの組合せもあるから、余裕も見て内部は 1 cluster=20byte位の固定長？素晴らしい富豪設計です。 104 名前：デフォルトの名無しさん mailto:sage [05/03/11 07:00:57 ] >>103 任意のスカラ値の組み合わせが可能な訳じゃないからそんなに必要ない 105 名前：デフォルトの名無しさん mailto:sage [05/03/11 07:08:52 ] よくある実装が必要な組み合わせだけ適当にPUAに割り当てて 知らない/対応する気のないスクリプトはそのまんま素通し どうせ未定義の符号位置に関しては素通しにせざるを得ないんだし つーかなんでこうも過度に汎用化したがるんだろうか シフトJISのアプリケーションがISO 2022完全実装に対応できないから駄目なんて 文句言う奴はいないのになんでUnicodeになったとたん単なる地域化じゃ許されなく なりますか? 単に漢字をたくさん使いたいだけというささやかな望みも叶いませんか? 106 名前：デフォルトの名無しさん mailto:sage [05/03/11 18:57:03 ] >>102 (jisx0201左半面 or ASCII) + (jisx0208) - (\~￣―＼〜‖…−￥¢£¬) 前提がひどく厳しいのでこんなものじゃないかしら。 ISO-2022-JPの…なんてことは言わないで頂戴。 いわゆる機種依存文字や半角カナが非互換なのは、unicode以前からの通り。 \~￣―＼〜‖…−￥¢£¬は、unicodeの普及によって新たに生じた非互換。 (余談だけど、後者は終止unicodeのみで処理するときでさえいやらしい。) 「自鯖の掲示板」で「縦横無尽にマッピングしまく」る必要はないようにも思うが。 107 名前：デフォルトの名無しさん mailto:sage [05/03/12 19:44:53 ] 人間はなぜ同じ過ちを繰り返すのでしょうか？ 108 名前：デフォルトの名無しさん mailto:sage [05/03/13 00:39:53 ] >>107 過去の失敗から学ぼうとしないからだ、と何回言ったら分かるんだ 109 名前：デフォルトの名無しさん mailto:sage [05/03/13 08:59:59 ] >>104 HangulやDevanagariは３つ４つ平気で使うよ。 110 名前：デフォルトの名無しさん [05/03/13 09:14:00 ] >109 タイ語もたくさん使うよ。 111 名前：デフォルトの名無しさん mailto:sage [05/03/16 01:50:18 ] >>109-110 だから3つ4つの任意の組み合わせがすべて必要なわけじゃないだろ。 Windowsのフォントフォルダ見てもインド語のフォントは500KBもないし 実際にPUA使ってリガチャを実装してるタイ語やインド語のフォントだって BMPの6400文字で十分に足りてる。理論上可能なすべての組み合わせを サポートするニダ150万コードポイント必要ニダUTCは謝罪と賠償しる! とはさすがの韓国も言ってないみたいだし。 そもそもそんなこと言い出したらIdeographic Description Sequenceなんか 最大16コードポイントの並びだし。 112 名前：デフォルトの名無しさん mailto:sage [05/03/16 06:11:24 ] >>111 要約すると「Windowsでは使わない、使えないから不要」ということ？ でしたら特定の実装上と限定して話しをして下さい。 ちなみにAppleのATSUIだと、PUA使ってリガチャを実装なんて変なこと はやってないから、長いdecompositionで表現したcomplex scriptでも glyph metamorphosis tableを使って適切なglyphを拾って来る。 この実装上では、complex scriptが扱えなかったり、ヒラギノOpenType の豊富なglyphを使えないと粗悪品とみなされます。 113 名前：デフォルトの名無しさん [2005/04/27(水) 20:33:59 ] Windowsが扱うコードをすべてutf-8に統一したいんですけど、できますか? たとえば、コマンドプロンプトとかでutf-8で書いたコンソールに文字列を出力するjavaのコードをコンパイルしたものを実行したいんです。 現状では、コマンドプロンプトはMS932(Shift_JIS)と勝手に解釈してへんちくりんな文字列を出力します。 114 名前：デフォルトの名無しさん mailto:sage [2005/04/27(水) 21:23:00 ] >>113 毎回MultiByteToWideChar(CP_UTF8, で変換するしかない。 115 名前：デフォルトの名無しさん mailto:sage [2005/04/27(水) 23:05:28 ] >>113 CygwinのLC_ALLにutf-8って指定できなけったった？ 116 名前：デフォルトの名無しさん mailto:sage [2005/04/28(木) 10:40:23 ] OutputStreamWriter(system.out, "MS932") 117 名前：デフォルトの名無しさん mailto:sage [2005/04/30(土) 13:39:58 ] >115 Cygwin のロケール周りはきちんと実装されていないはず。 118 名前：デフォルトの名無しさん mailto:sage [2005/05/02(月) 09:12:23 ] 経済産業省が、こんなこと発表してた。 www.jisc.go.jp/newstopics/2004/041221kanjicode.htm 現在、最新のＪＩＳ漢字コード表を採用した情報機器は多くありません。 しかしながら、人名用漢字の改正を契機に最新のＪＩＳ漢字コード表が普及することが期待されます。 人名用漢字（９８３字）の水準ごとの字数は、次のとおりです。 第１水準：６８５字 第２水準：１９１字 第３水準：１０７字 第４水準：０字 合計：９８３字 （注）第１水準漢字及び第２水準漢字しか実装していない情報機器では、 １０７字の人名用漢字について情報交換が行えないことになります。 これは、Unicode導入をどんどん進めろと言いたいわけか ? 119 名前：デフォルトの名無しさん mailto:sage [2005/05/03(火) 00:43:07 ] >>118 AppleもMicrosoftも、UnicodeのレパートリとしてしかJIS X 0213はサポートしないと ずっと前から言っている。それをようやく追認しただけ。 その発表書いた中の人のコメント↓ slashdot.jp/comments.pl?sid=230343&op=&threshold=1&commentsort=0&mode=nested&startat=&pid=0 120 名前：デフォルトの名無しさん mailto:sage [2005/05/03(火) 00:53:27 ] リンク先にはもうコメント付けられないからここに書いとこう > ＃戸籍統一コード のページができているのにも気がついた。これはいわゆる > 住基コードなんだろうか。 違うもの(なんつー税金の無駄遣い…)。 www.itscj.ipsj.or.jp/senmon/03sen/moji.html > JIS X 0213の2000年版と2004年版でUCSが違う(正確には2000年版では「参考」 > として載せられていた363個のUCSが、2004年版では「規定」になったうえにUCSでの > 符号位置も変わった) それは(Unicode 3.0以前に)対応するUCSがないと「規定」されていたものに (Unicode 3.1以降への)対応を追加しただけだからまあ許せるけど 2面93区27点をU+9B1D(規定)からU+9B1C(規定)に変えたのをお忘れですかセンセイ そもそも「変わった」とか他人事のように言ってるけどあんたが変えたんでしょうに 121 名前：デフォルトの名無しさん mailto:sage [2005/05/03(火) 00:55:28 ] > 変えたのをお忘れですか これは本気で忘れてる可能性もあるんだよな あれだけあれこれ言い訳してるJIS X 0213:2004の解説でもこの件には なぜか一切触れてないし 122 名前：デフォルトの名無しさん mailto:sage [2005/05/04(水) 15:54:55 ] JIS X 0213 で例示字形が大幅に変えられたことの影響はどうでるか。 以前、小形克宏氏は「文字の海、ビットの舟」で 「ほとんどのフォントベンダーの対応は、... 世間が新しいMS書体を どう受け入れるかを見極めた後になるはず。」としていた。 internet.watch.impress.co.jp/www/column/ogata/sp18.htm しかし、Windows でまず登場したのは、ジャストシステムからで、 一太郎2005ユーザー登録特典の「JIS X 0213:2004」対応フォント が登場した。www.ichitaro.com/2005/taro/toku07.html 日本工業標準調査会のサイトが「最近、JIS X 0213:2004について問合せが 多いため」と、JIS X0213 関連の情報をまとめたページを作ったのは、 ここからリンクがあるためだろう。www.ichitaro.com/value/jis.html このフォントは一太郎で標準ではなく、無償であってもオプションのフォントだ。 そうなっている一番の理由は、JIS2004 での大幅な例示字形の変更に対応して 表外漢字字体表の印刷標準字体を使ったフォントだからに違いない。 既存の文書までフォントが変わったことで、意識しないのに字体が 大きく変わってしまっては困るから。 標準のフォントを変えたり、それしか使えなくなっては 83JIS の時の二の舞。 今後マイクロソフトが JIS2004 にどう対応するのかは、はっきりしないとしても 似たような対応になるだろう。 マイクロソフトは表外漢字字体表が制定された時に、JIS漢字の例示字形について 「今回仮に例示字体・字形を差し替えたとしても、差し替えられた面区点位置に 包摂されている字体・字形をもとに実装することは依然として規格に反しない」 「こうした利用者が意識しない変更を生産者が押しつけるわけにはいかないので、 利用者が意識して表外漢字字体表の字体を選択できるよう生産者は考えざるをえない」 との見解を表明していた。もっともな見解だ。 MS の方こそ、当面は今の MS明朝・MSゴシックでやっていって、どんな利用者の要求 があるか様子みましょう、となって急がないかもしれない。 123 名前：デフォルトの名無しさん mailto:sage [2005/05/04(水) 17:33:54 ] 人名用漢字は印刷標準字体の方で規定されている。 もともと第1・第2水準漢字を規定した JIS X 0208 の例示字形は変更されていないと いうから、第1・第2水準の漢字の字形は、JIS としても実装としても、 2種類あることになって、必要に応じて使い分けることになっていくのか。 124 名前：デフォルトの名無しさん mailto:sage [2005/05/04(水) 18:44:59 ] >>119 があげていた安岡先生のコメントに > でもJIS X 0213の「エンコーデング」の主流が「Adobe-Japan1」 > になるのだけは、個人的に勘弁してほしい。 とあった。Adobe が「エンコーデング」というのは笑えるが、けっこう強そう。 125 名前：デフォルトの名無しさん mailto:sage [2005/05/04(水) 19:30:32 ] >>122 某フォントスレからの情報 213 ：名無し~3.EXE ：2005/05/01(日) 04:40:02 ID:++Vj6Nxl Meiryoは印刷標準字体になるって噂もあったが変わってないな 218 ：213 ：2005/05/01(日) 18:45:08 ID:++Vj6Nxl 違った Adobe Japan1-5相当になってるっぽい でもデフォルトで印刷標準字体になるって言ってた気がするんだが…。 Longhornの環境だとデフォルトで'nlck' featureが適用されるんだろうか 231 ：名無し~3.EXE ：2005/05/02(月) 19:39:51 ID:BAiJXOjJ Longhornではこういうことができるらしい <Inline Typography.EastAsianLanguage="NLCKanji">葛</Inline>飾区 <Inline Typography.EastAsianLanguage="JIS90">葛</Inline>城市 第64代横綱<Inline Typography.EastAsianExpertForms="True">曙</Inline> Avalonマンセー 126 名前：デフォルトの名無しさん mailto:sage [2005/05/04(水) 19:41:07 ] >>124 > Adobe が「エンコーデング」というのは笑えるが、 Adobe-Japan1-0〜Adobe-Japan1-6はCIDをビッグエンディアンでそのまんま並べた エンコーディングの名称でもある 127 名前：デフォルトの名無しさん mailto:sage [2005/05/06(金) 09:15:37 ] > Longhornではこういうことができるらしい > <Inline Typography.EastAsianLanguage="NLCKanji">葛</Inline>飾区 そういえば、Longhorn ではインターフェースを XML 使って構築する話、 どこかで聞いたな。そこでフォントも指定できるか。 128 名前：デフォルトの名無しさん mailto:sage [2005/05/06(金) 10:43:31 ] 印刷標準字体を採用となれば、葛飾区は喜ぶ方の口だったっけね。 茨城県や芦屋市もいいのかな。小樽市や灘区はどうなん ? どっちでもいい ? 129 名前：デフォルトの名無しさん mailto:sage [2005/05/06(金) 13:18:54 ] 奈良県に葛城市ができたのは知らなかったぞ。 こっちは、JIS X 0213:2004 改正で消滅した字体の方を使ってるじゃないか。 なんなら、JIS X 0208 字体を使い続ければいいけど、たいていは、いちいちフォント切り換えないぞ。 130 名前：デフォルトの名無しさん mailto:sage [2005/05/07(土) 12:45:46 ] JIS漢字コードとその実装の字形が2種類になるのは、表外漢字字体表からの当然の帰結。 131 名前：デフォルトの名無しさん mailto:sage [2005/05/07(土) 14:28:03 ] 将来、文字コードのトピックにちょうどよくなりそうなので、書いておこう。 2004年10月1日、奈良県に葛城市が誕生した。奈良県北葛城郡新庄町と同郡當麻町の合併である。 なお「葛」の字形は、「北葛城郡」は漢字の『人』を書く方(JIS X 0213:2004字形)だったが、 新市名「葛城市」はカタカナのヒを書くの方(JIS X 0208字形)に変わった。 新市名称公募は、2004年1月6日から1月31日までの受付期間で行われ、以下が結果報告のサイトからの引用。 応募点数で最も多かったのは『白鳳市』で205点、次いで漢字の『人』を書く『葛城市』143点、 カタカナのヒを書く『葛城市』89点、ひらがなの『かつらぎ市』85点の順になりました。 その後、新市名称候補選定小委員会を経て、合併協議会において協議・決定された名称が、 第3位だったカタカナのヒを書く『葛城市』である。 132 名前：デフォルトの名無しさん mailto:sage [2005/05/07(土) 16:46:41 ] なお、なぜ第3位が浮上したかというと、新市名称候補選定小委員会が 「人」と書いても「ヒ」と書いても同じ「葛城市」だから同一と考え、 そこからパソコン等で使われている方との理由で「ヒ」と書く「葛城市」を 候補として選び、住民アンケートの結果、第1位を獲得したからである。 このとき、すでに表外漢字字体表はもちろん、JIS X 0213:2004 も公示されていたが、 候補選定小委員会で検討された様子はない。届いていなかったと思われる。 133 名前：デフォルトの名無しさん [2005/05/08(日) 01:08:31 ] >>132 「パソコン等で使われている方」でちょっと思い出した事が。 こないだ、青森県西津軽郡車力村が他と合併して「つがる市」に なったんだけど、その時にある字名の表記が変更になった。 旧：青森県西津軽郡車力村大字下牛潟字靎舞岬（つるまいみさき/靎は雨冠の下に金+鳥（U+974E）） 新：青森県つがる市下牛潟町靏舞岬（つるまいみさき/靏は雨冠の下に鶴（U+974F）） www.city.tsugaru.aomori.jp/tugaru/pdf/add_shariki.pdf 鶴にするならともかく、どっちも第3水準だし最初は疑問に思ったんだけど、 これって靏がWindowsの外字部分に含まれてたから表記しやすい 方に、って事だったのかもしれない。 134 名前：デフォルトの名無しさん mailto:sage [2005/05/08(日) 03:15:01 ] 統一するってことは、世界中の文字を表現できるようにするってことだよな？ しかし、それぞれが持ち寄った文字数をみると漢字圏が大きすぎる 普段は使わない人々からすれば対応するだけ無駄が多すぎとしか思えない 言語統一を推進するほうが将来的にいいじゃんてことになる。だから無理 135 名前：デフォルトの名無しさん mailto:sage [2005/05/08(日) 12:15:56 ] あのね、Apple, IBM, Microsoft, Sunの様な会社は、 漢字文化圏も重要なマーケットと考えているんですよ。 君のいる三流ソフトハウスは違うだろうけど。 136 名前：デフォルトの名無しさん mailto:sage [2005/05/09(月) 00:29:37 ] 漢字文化圏でも今や重心はあっちの国だがな。 137 名前：デフォルトの名無しさん mailto:sage [2005/05/09(月) 10:03:40 ] sunの禿、ギコが見れてうれしいって言ってた気がするなぁ。 138 名前：デフォルトの名無しさん mailto:sage [2005/05/09(月) 10:54:58 ] >>134 いいから黙ってUTF-8使っとけ 139 名前：デフォルトの名無しさん mailto:sage [2005/05/09(月) 10:56:38 ] なるほどねえ。Longhorn での WinFX のクラスライブラリ予定を見たら、 "FontEastAsianLanguage 列挙体" なんてのがあって、 フォントによって字形(glyphs) が異なるバージョンを並べて、選択できるようになってる。 JIS78, JIS83, JIS90, JIS04, HojoKanji と、ここまで日本向けか。 確かに、これが簡単でないと、この先は困るよ。よくわかっていらっしゃる。 日本もまだ、Microsoft の重要なマーケットですって。 140 名前：デフォルトの名無しさん mailto:sage [2005/05/09(月) 22:30:04 ] ちなみに Mac OS X の対応してそうな機能 developer.apple.com/fonts/Registry/ 141 名前：デフォルトの名無しさん mailto:sage [2005/05/10(火) 00:22:53 ] >>140 これは最新の情報ではないよ。実際に使えるのはもっと多い。 フォントパネルからTypographyパレットを出せば、フォント毎に 使用可能なFont Featureが列挙される。 >>131 で出ている「葛」もヒラギノを使っていればどちらの字体も選べる。 これはOSXのAAT+ATSUIで「今」できる機能 142 名前：デフォルトの名無しさん mailto:sage [2005/05/10(火) 05:31:04 ] 「Updated 2/5/98」だから最新の情報なわけはないと思ってたけどやっぱりそうか。 143 名前：デフォルトの名無しさん mailto:sage [2005/05/10(火) 05:38:41 ] あとはAdobe Japan1-6をJIS X 4165(ISO/IEC 10036)に登録してくれれば インターネットでの情報交換も問題ないんだけどねえ 誰かやってくれないかなあ 144 名前：デフォルトの名無しさん mailto:sage [2005/05/10(火) 09:36:35 ] 第3水準漢字を含む人名用漢字表のテキストを作る実験してみました。報告します。 人名用漢字表テキストを作る簡単な方法は、経済産業省から 「人名用漢字の文字符号に関する規格検討会報告」（PDFファイル） をダウンロードし、この中の人名用漢字表をエディタ等にコピー&ペーストして Unicode のエンコーディングで保存する方法です。これなら入力手段も不要です。 すべて BMP 内ですから、サロゲートペア対応までは必要ありません。 www.jisc.go.jp/newstopics/2004/041221kanjicode.htm 最初は、総務省の法令データ提供システムから「戸籍法施行規則」を見て、 そこの漢字表を調べたのですが、正式の表の形を知るにはこちらが必要でも、 内容はとんでもないものでした。一度、見比べて下さい。 law.e-gov.go.jp/htmldata/S22/S22F00501000094.html 水準別の一覧表としては、こちらを参照できます。 www.eonet.ne.jp/~kotobukispace/ddt/itaizy/jinm0409.html 145 名前：デフォルトの名無しさん mailto:sage [2005/05/10(火) 09:38:26 ] 人名用漢字を表示するには、やはり JIS X 0213:2004 対応フォントが必要なようです。 たとえば、一太郎2005 で入手できる JS平成明朝W3[JISX0213:2004] を使えば、 第3水準漢字も含めすべて表示されますし、戸籍に認める正しい字形です。 Windows では、他のフォントを使うと第3水準の分の半分ほどが表示できませんでした。 表示される字も、字形が人名用漢字としては正しくないものが多く出ます。 たとえば、「人」と書く「葛」が正しい所が、「ヒ」と書く「葛」になるわけです。 JISの包摂基準では同じ字であっても、戸籍上の名では字形が限定される点が、 この先、人名データの扱いが難しくなる所です。 「葛城市の山田広葛くん」が誕生したら、２つの「葛」の字形は異なるのが正しい、 なんてケース、どう処理しますか。 まあ、表外漢字字体表を楯に、人名優先で有無を言わせず印刷標準字体を使うのが、 簡単だとは思ってますが。ごめんなさい、葛城市。 漢字表のコピペ先のエディタとしては、Windows XP の場合はメモ帳が適当でした。 このテキストを表示させようとして、予想以上の壊滅的打撃を受けたのがエディタでした。 第3水準漢字をきちんと表示できないものが多そうです。 Unicode のエンコーディングを読み書きできるということと Unicode 対応ということが、 まったく違うことだ、という当たり前のことが現実のものとなります。 146 名前：デフォルトの名無しさん mailto:sage [2005/05/10(火) 19:54:41 ] > なんてケース、どう処理しますか。 Longhornまで待つかMacを買うかだな。 147 名前：デフォルトの名無しさん mailto:sage [2005/05/11(水) 10:51:54 ] > Longhornまで待つかMacを買うかだな。 その限りならそうとして、MacはJIS X 0213:2004対応済? 待ち? 148 名前：デフォルトの名無しさん mailto:sage [2005/05/11(水) 11:24:31 ] Mac OS Xは、JIS X 0213:2000に対応すると一時言ったけど、 結局Unicodeに含まれる限りにおいて、と修正。 2004も同様。いわゆる対応はやらない。 149 名前：デフォルトの名無しさん mailto:sage [2005/05/11(水) 12:31:56 ] >>148 なるほど。 Shift_JIS-2004 はサポートしないと言っているということかな。 150 名前：デフォルトの名無しさん mailto:sage [2005/05/11(水) 21:27:53 ] レパートリが揃っているか、という意味なら現時点で対応済み。 151 名前：デフォルトの名無しさん mailto:sage [2005/05/11(水) 22:58:00 ] >>149 Shift_JISX0213には対応してるみたいよ。 2004は知らん。 >>150 内部がUnicodeだと、合成に対応しているかどうかが問題になる。 半濁点つきのカキクケコ(鼻濁音用)とか、半濁点つきのトツセ(アイヌ語用)とか。 そこまで注意しないと、がっかりする人が出るはめになる。 152 名前：デフォルトの名無しさん mailto:sage [2005/05/11(水) 22:59:31 ] セミナー：　CJKV 日中韓越情報処理 ttp://www.jtpa.org/event_in_silicon_valley/000285.html 講演は英語だってさ。 153 名前：デフォルトの名無しさん mailto:sage [2005/05/11(水) 23:16:08 ] 最近（でもないか?）CJKV って聞く様になったけど、何で越南だけ追加されたんだろう 154 名前：デフォルトの名無しさん mailto:sage [2005/05/12(木) 00:42:46 ] >>151 OSXは現状で合成に対応してます。 ATSUIは正しくレンダリングするし、区切り判定も合成文字を１文字と 認識します。 このスレでも散見されるけど、合成対応は意味がないから無視という姿 勢のアプリケーションではだめですね。 155 名前：デフォルトの名無しさん mailto:sage [2005/05/12(木) 00:52:27 ] >154 おお。なかなか。 ところでデーヴァナーガリーなんかのリガチャはどうなるんだっけ? あれを一律「一文字」にされると古典を扱うときヽ(`Д´)ﾉｳﾜｧｧﾝなことになるんでちと気になって。 156 名前：デフォルトの名無しさん mailto:sage [2005/05/12(木) 05:16:53 ] >>151 青空文庫の中の人によればShift_JIS-2004には未対応 www.siesta.co.jp/aozora/archives/001145.html これは去年の話だからもしかしたらTigerは対応したのかもしれないが そこまでは知らん 157 名前：デフォルトの名無しさん mailto:sage [2005/05/12(木) 07:51:51 ] 包摂に対する考え方が、JISとUnicodeは違うけど、 2004なら追加文字で問題がなくなる→JIS X 0213対応ってわけ? 158 名前：デフォルトの名無しさん mailto:sage [2005/05/12(木) 11:10:39 ] >>150 いまはまだ過渡期とはいえ、Unicode でレパートリが揃い、使えれば 「JIS X 0213:2004 対応」と言う段階に入ってきていると思う。 少なくとも、ジャストシステムが「JIS X 0213:2004 対応フォント」 と言うときには、その意味で使っている。 このフォントで、Shift_JIS-2004 のテキストが表示できるわけじゃない。 ATOK2005も「Unicodeを使うJIS X 0213:2004 対応」での入力手段。 >>119 にあるように、規格作成当事者からも > JIS X 0213の「エンコーディング」を捨ててしまう は追認されてる。 159 名前：デフォルトの名無しさん mailto:sage [2005/05/12(木) 12:45:04 ] 蛇足だけど、Unicode マンセーって言ってるわけじゃない。 Unicode導入とは非関税障壁撤廃が進んでいるというだけのこと。 ただ、それで便利にできる所は利用する。 中国の方が日本より上手に対応してきた。 160 名前：デフォルトの名無しさん mailto:sage [2005/05/12(木) 19:35:44 ] >>159 > 中国の方が日本より上手に対応してきた。 これマジレス? 161 名前：デフォルトの名無しさん mailto:sage [2005/05/13(金) 04:48:38 ] つまり中国を見習って、Unicodeの全文字を含み1文字最大4バイトで表現する 新しい文字集合とエンコーディングをJISで定義して、全ての市販ソフトに その採用を義務付けろと主張するわけだな? >159 162 名前：デフォルトの名無しさん mailto:sage [2005/05/13(金) 17:44:09 ] 超漢字マンセー 163 名前：デフォルトの名無しさん mailto:sage [2005/05/13(金) 20:15:32 ] GB18030の影響でMeは発禁 164 名前：デフォルトの名無しさん mailto:sage [2005/05/13(金) 20:21:36 ] >>157 2004で追加された以外の文字ではまだ問題が残ってる。 JISとUnicodeで包摂規準が明らかに矛盾してる文字の一覧とか 調べてみたいんだが面倒で挫折中。 165 名前：デフォルトの名無しさん mailto:sage [2005/05/13(金) 20:24:14 ] >>160 波ダッシュはチルダではないとか意地を張ったりしないで GBKをそのまんま追認した点とか。 166 名前：デフォルトの名無しさん mailto:sage [2005/05/13(金) 23:40:13 ] >>165 > 意地を張ったりしないで これってマジレス? 167 名前：デフォルトの名無しさん mailto:sage [2005/05/14(土) 10:14:12 ] >>155 複雑なリガチャ付き文字はマウス操作やカーソルキー移動では１文字扱いですが、 デリート時は適度に分割されて扱われます。 Devanagariは理解できないので実装の正確さは判断できません。 OSX標準の状態でもDevanagariを扱うためのリソースは揃っていますので、実物で 確かめてみて下さい。 168 名前：デフォルトの名無しさん mailto:sage [2005/05/16(月) 20:57:28 ] >>166 94x94の表の空き領域にも全部PUAへの写像を定義した点とか 169 名前：デフォルトの名無しさん mailto:sage [2005/05/16(月) 21:41:37 ] Unicode 4.1でU+2B00とU+2B01、U+2B08とU+2B09のグリフが入れ替わった件について www.unicode.org/versions/Unicode4.1.0/erratafixed.html 170 名前：デフォルトの名無しさん mailto:sage [2005/05/17(火) 15:31:46 ] >>169を見て気づいた。 Code2001のU+1D301〜U+1D303の実装がおかしい。 171 名前：デフォルトの名無しさん mailto:sage [2005/05/18(水) 06:35:24 ] 実はU+1D300〜U+1D305の文字名で地と人が入れ替わってる件について 172 名前：デフォルトの名無しさん mailto:sage [2005/05/18(水) 11:17:35 ] >>171 academy3.2ch.net/test/read.cgi/gengo/1040929046/170 173 名前：デフォルトの名無しさん mailto:sage [2005/05/18(水) 20:23:41 ] >>172 つーかそれ書いたの漏れ。 U+3020のナンバー君がMeiryoでポストン君に変わってる件について www.post.japanpost.jp/zipcode/zipmanual/image/052-1.jpg これは包摂の範囲なんですか? U+3004のJISマークもそのうち変わりますか? www.jisc.go.jp/newjis/newjismknews.htm ちなみにユーロ記号はデザインが変わったとき新たにコードを割り当てられた。 まあUnicodeの欧米偏重は今に始まったことじゃないけど 174 名前：デフォルトの名無しさん mailto:sage [2005/05/18(水) 21:12:03 ] この際だから>>169も解説しちゃおう U+2B00〜U+2B0Dの矢印類はKPS 9566をソースに北朝鮮が追加提案した(N2056)。 std.dkuug.dk/jtc1/sc2/wg2/docs/n2056/J1n599903.pdf このときの並び順は右上→左上の順だった。 すくなくともPDAM2まではその順だったのだが(N2395)、 std.dkuug.dk/jtc1/sc2/wg2/docs/n2395.pdf FPDAM2になってなぜか突然グリフの順番が左上→右上に入れ替わった。 std.dkuug.dk/jtc1/sc2/wg2/docs/n2491.pdf 後から説明しているところによると(N2926 T.7とか)、Unicodeの他の矢印では 左上→右上だったからそれに合わせたかったのだろうとか。 でもFPDAM2で入れ替えたのはグリフだけで、名前を入れ替え忘れて(証拠は N2491のチャートに残ってる)、そのままAmendment 2=Unicode 4.0 BMPに なってしまった。 正式にAmendmentになってしまった以上もう名前は変えられないので グリフを入れ替えることにした(N2926)。 std.dkuug.dk/jtc1/sc2/wg2/docs/N2926.pdf もうアホかと。 175 名前：デフォルトの名無しさん mailto:age [2005/05/20(金) 11:49:25 ] ユニコードHPが見られなくなっているんですが、 自分だけでしょうか･･･。 Unicode Home Page www.unicode.org/

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef