文字コード統一スレ 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 44 名前：デフォルトの名無しさん mailto:sage [05/02/25 10:20:01 ] >>41　意外とまともな事言ってる人もいると思うが。 45 名前：デフォルトの名無しさん [05/02/25 10:22:38 ] suika.fam.cx/~wakaba/-temp/wiki/wiki?ISO%2FIEC%2010646 >>43 それって、この表だとどの規格のこと？ 46 名前：デフォルトの名無しさん mailto:sage [05/02/25 11:03:27 ] >>45 DIS 10646:19911990-12-061st DIS 47 名前：デフォルトの名無しさん mailto:sage [05/02/25 12:02:10 ] >>43 寝言言ってねえで素直にUTF-32でも使っとけ。 48 名前：デフォルトの名無しさん mailto:sage [05/02/25 12:26:02 ] >>44 Unicodeは複数コードポイントを組合わせる可変長表現なのに、 相変わらず２バイト４バイト固定とか言ってますが。 49 名前：デフォルトの名無しさん mailto:sage [05/02/25 12:54:57 ] 結局シフトJISに統一されるんだよな 50 名前：デフォルトの名無しさん [05/02/25 13:29:46 ] （・∀・）ｳﾝｺｰ 51 名前：デフォルトの名無しさん [05/02/25 13:56:16 ] >>48 その「固定」ってのは sizeof wchar_t の話だと思う 52 名前：デフォルトの名無しさん [05/02/25 14:01:52 ] 総合といいたかったのか。なるほど。 53 名前：デフォルトの名無しさん [05/02/26 00:51:25 ] >>51 Linux の gcc だと sizeof(wchar_t) == 4 で、 Windows の VC++ だと sizeof(wchar_t) == 2 だったり。 54 名前：デフォルトの名無しさん mailto:sage [05/02/26 01:06:18 ] 将来の主流は、__wchar64_t になると予言しておく。 55 名前：デフォルトの名無しさん [05/02/26 01:41:31 ] typedef unsigned int wchar_t; が typedef unsigned _int64 swchar_t; になって typedef unsigned _int128 xwchar_t; になって typedef unsigned _int256 uwchar_t; になって（ｒｙ 56 名前：Winかよ!? mailto:sage [05/02/26 01:44:50 ] >>55 unsigned _int64って何だよ… いまや#include <stdint.h>で、uint64_tじゃないのか? 57 名前：デフォルトの名無しさん mailto:sage [05/02/26 02:04:17 ] >>51 wchar_tはUnicodeが入るとは限らないんだけど、そのままUTF-16やUTF-32 を突っ込んでる実装が多いから良しと仮定しましょう。 wchar_tにUTF-32が並んでいても、そこから文字（grapheme）単位に処理 するにはステートマシンで区切りを探さないといけない。 　www.unicode.org/reports/tr29/ こういったことを理解しての発言には見えない。 加えて、ICUもそうだけどUTF-16が処理対象の場合はサロゲート込みで処 理されるからサロゲートの有無で手間は全く変わらない。 58 名前：デフォルトの名無しさん mailto:sage [05/02/26 02:04:28 ] >55 さすがに地球外知性とデータ送受信するようにでもならないとそこまでは…… いや、そうなったらそうなったで、向こうのコード体系を強引に押しつけられる悪寒orz 59 名前：デフォルトの名無しさん mailto:sage [05/02/26 11:29:58 ] >>57 > そこから文字（grapheme）単位に処理 > するには 誰もそんなこと書いてないと思うが。 60 名前：デフォルトの名無しさん mailto:sage [05/02/26 12:57:35 ] 文字単位に処理することはあり得るだろう？ 61 名前：デフォルトの名無しさん [05/02/26 14:23:12 ] あり得るけど、それこそ Shift JIS や EUC-JP でAPI/システムコールレベルでは バイト列として扱い、それを文字に組み上げるのは各アプリケーションの責任という 考え方もあった罠。 この考え方を Unicode にあてはめてみたり、とか。char を wchar_t に変えて。 62 名前：デフォルトの名無しさん mailto:sage [05/02/26 14:42:33 ] >>61 > あり得るけど、それこそ Shift JIS や EUC-JP でAPI/システムコールレベルでは > バイト列として扱い、それを文字に組み上げるのは各アプリケーションの責任という > 考え方もあった罠。 それほど変ってないような… そしてその「アプリケーションの責任」の技術的な部分の研究を、 一番行っているのはUnicodeの世界なのでは? 63 名前：デフォルトの名無しさん [05/02/26 17:38:26 ] 結局「一文字」単位に扱おうとすると, ステートマシンは必要になるのか… なんかあんまり変わってないな，昔と. 64 名前：デフォルトの名無しさん mailto:sage [05/02/26 20:24:52 ] >>63 そういう領域はUnicodが解決しようとした問題領域に含まれていないものと思われ。 65 名前：デフォルトの名無しさん [05/02/26 20:48:58 ] 結局は、ASCII 系のコードしかなかった頃は基本単位（char） 1 つに 英数字程度しか入らなかったけど、Unicode では基本単位（wchar_t） 1 つに 漢字とかも入れられるようになりますたよ。 でも、国際化を考えるときは 1 基本単位＝ 1 文字と仮定するのはやめようね。 というのは変わってないということか。 66 名前：デフォルトの名無しさん mailto:sage [05/02/27 00:27:02 ] www.hatena.ne.jp/1105667960 67 名前：57 mailto:sage [05/02/27 00:45:01 ] >>59 UAX #29でも触れられているけど、文字（grapheme）単位に 処理できないと文字列の文字数を得たり、分解したりできな いのはもちろん、比較や検索も正しく行なえない。 68 名前：デフォルトの名無しさん mailto:sage [05/02/27 01:24:33 ] normalize してもコードポイント一つであらわせない文字は正しく扱えません としても、それほど困らないんだよなあ。 実装コストに見合うメリット無いし。 69 名前：デフォルトの名無しさん [05/02/27 02:13:31 ] >>67-68 内部文字コードが Unicode 化された Visual Basic 4.0 以降や Java なんかでは、 「文字列をバイト単位で切り出すにはどうすればよいですか？」という質問が 必ず FAQ になってるよな（ｗ 70 名前：デフォルトの名無しさん mailto:sage [05/02/27 02:34:30 ] U+F92FとU+F98DのkIRG_KSourceが間違ってる件について これどうやったら修正させることができるんですか 韓国のNational Bodyが言い出さない限り何人たりとも修正できないんでしょうか とりあえずUnicode 4.1.0βのレビューで指摘してみたけどシカトされますた ほかの指摘事項はちゃんと反映されてたから指摘そのものは届いてるはず 71 名前：デフォルトの名無しさん mailto:sage [05/02/27 13:12:20 ] ほかの指摘事項はたまたまほかの人が同じ指摘をしたんだろう 72 名前：デフォルトの名無しさん mailto:sage [05/02/28 07:13:00 ] 5件あって5件ともたまたま別の人が同時に指摘したってあんまりありそうにないような 「報告ありがとう。Unihanの専門家に転送しとくよ彼が今日中に反映してくれるだろう」 みたいな返信もちゃんと返ってきたし。 正規表現が間違いだらけだったから正しいの書いて送ったけど他の誰かが一字一句 ピッタリ一致するような正規表現をたまたま同時に送ってたとかありえなーい。 つーかスクリプトに通して検査するだけで見つかるような誤りがなんでボロボロ 出てきますか? なんのために機械可読な形式で提供してますか? 73 名前：デフォルトの名無しさん mailto:sage [05/02/28 08:42:52 ] もう一回聞いてみればいいじゃん 74 名前：デフォルトの名無しさん mailto:sage [05/03/01 01:46:45 ] 戸籍やってる身からすれば 康煕字典体はきっちり入っていないと 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

---

---

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

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