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

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

2:デフォルトの名無しさん
05/02/24 00:08:53
文字コードを統一するのか？
アホか？

3:デフォルトの名無しさん
05/02/24 00:37:16
アホw

4:デフォルトの名無しさん
05/02/24 00:55:22
「文字コード乱立スレ」ってわけにもいかんし…

5:デフォルトの名無しさん
05/02/24 01:03:38
新スレ発見！乙 >>1
リンク貼る前に埋めんな＞前スレ999-1000

6:テンプレ作った人
05/02/24 01:17:13
>>1 乙

7:デフォルトの名無しさん
05/02/24 01:26:49
Win32 API で UTF16 を EUC-JP(-ms) にするときは、
　UTF16 →(WideCharToMultiByte)→ CP932 →(自分でがんがる)→ EUC-JP
が普通なのかなあ・・・。

ドキュメントでは WideCharToMultiByte の CodePage に 51932 を指定すれば一発でできそうに
書いてあるのに、実際やるとなんでﾀﾞﾒなんだよ（ｗ
CP20932 は微妙に変換ルールが違うみたいだしなあ(´･ω･`)

8:デフォルトの名無しさん
05/02/24 01:41:13
IMultiLanguage Interface
URLﾘﾝｸ(msdn.microsoft.com)
これは対応している予感。使ったことないから知らないけど。

9:デフォルトの名無しさん
05/02/24 01:44:01
文字コードを統一？
TRONコードの出番か！

10:デフォルトの名無しさん
05/02/24 03:22:46
>>7
俺は変換テーブルを実行ファイルに組み込んでいる。
200KBぐらいだけど、これで特に問題はない。

11:デフォルトの名無しさん
05/02/24 03:26:24
ところでUTF16なんてあるの？

12:デフォルトの名無しさん
05/02/24 03:31:23
アホなスレタイだなｗ
「統一」いらんじゃんｗ

13:デフォルトの名無しさん
05/02/24 03:41:04
とういつ【統一】
まとまりのないばらばらな物事を１つのものにまとめること。

新しい文字コードでも作るつもりなのか？このスレ

14:デフォルトの名無しさん
05/02/24 03:43:22
1も読めないのか。読んで言っているのなら白痴だな。

15:デフォルトの名無しさん
05/02/24 03:44:03
>>7
うるさいことを言わなければコードページ20932がなんとなくEUC-JPに近い。
JIS X 0208 にない文字は変になるけど。

16:デフォルトの名無しさん
05/02/24 03:48:20
スレタイも読めないのか。読んで言っているのなら白痴だな。

17:デフォルトの名無しさん
05/02/24 04:05:24
>>13 辞書を引用し、都合のいい解釈をする
>>16 人の言葉をモジって言い返す
アホの典型

18:デフォルトの名無しさん
05/02/24 04:26:06
ではスレタイはどんな意味で統一と入れたのか

19:デフォルトの名無しさん
05/02/24 04:45:00
早く各種ローカルコードからUnicodeへのマッピングを統一してくれ．
あと，サロゲートペアってもうなくならんのだろうな…
結局固定ビット長で処理できねーじゃんか．

20:デフォルトの名無しさん
05/02/24 07:08:44
まずスレタイの意味を統一すべきだな。

21:デフォルトの名無しさん
05/02/24 10:18:07
>>19
32bitで固定

22:テンプレ作者
05/02/24 10:57:35
他に文字コード関連のスレを立てる人がいないように「統一」の
文字を入れました。もう立っているみたいですが。

23:デフォルトの名無しさん
05/02/24 11:01:09
普通「総合」じゃないのかな？

24:テンプレ作者
05/02/24 11:06:15
ま、洒落と言うことにしといてくださいな。

25:デフォルトの名無しさん
05/02/24 11:46:41
統一だろうが総合だろうがどうでもいいんだが・・・

26:デフォルトの名無しさん
05/02/24 12:01:35
>>7,15
URLﾘﾝｸ(msdn.microsoft.com)
によるとCP20932はJIS X 0208-1990 & 0121-1990だな。

27:デフォルトの名無しさん
05/02/24 12:42:27
>>21 そりゃなんでもあまりにもスカスカ過ぎないか？
まぁメモリ潤沢な昨今のパソコンならそれでもいいと思うけど、
やっぱり2バイトくらいにとどめておいて欲しかった。
つーか、4バイトで固定するならそもそもサロゲートペアいらねーじゃん。
次の面に素直にもってくりゃよかったんだ。

28:デフォルトの名無しさん
05/02/24 12:53:11
> つーか、4バイトで固定するならそもそもサロゲートペアいらねーじゃん。

その通り。サロゲートペアは2バイトという幻想にとらわれた故の特殊事情であって、
もはやUnicodeとしてはサロゲートペアなんぞ使わないのが正しい。

29:デフォルトの名無しさん
05/02/24 13:01:21
さすがに第1群以降は使わないよな？
せめて最上位バイトを内部処理用フラグとして使いたい。
まぁ外に出すときにはクリアするが。

30:デフォルトの名無しさん
05/02/24 13:17:13
確かに文字コードは頭が痛くなる問題ですね。
早く標準が固まって欲しいです。

ただ、右から左にテキストを書くやつ(アラビア辺り?)とかは
絶望的じゃなかろうかと思ってみたりみなかったり。

31:デフォルトの名無しさん
05/02/24 13:50:09
>>30
標準ならあるぞ。たくさん(笑)

right-to-leftの何が絶望的なんだろう? ふつうにWindowsでも扱えるは
ずだけど。

32:デフォルトの名無しさん
05/02/24 14:08:58
ストリームの出現順の問題のことを言ってるのかな？

33:デフォルトの名無しさん
05/02/24 14:10:04
>>30
日本語は縦書きなんだが

34:デフォルトの名無しさん
05/02/24 14:48:10
>>30
描画方向が違うだけだと思うYO

35:デフォルトの名無しさん
05/02/24 15:53:10
日本でも昔の看板とかは右から左

36:デフォルトの名無しさん
05/02/24 16:03:14
笑止！それは一行一文字の縦書きにすぎぬわ！

37:デフォルトの名無しさん
05/02/24 16:13:22
そんなわけで本文なんかを横書きにする場合では、
相当古くから(もちろん明治維新よりは後だが)
今と同じく左から右へ書いていたそうな。

38:デフォルトの名無しさん
05/02/24 18:00:17
左←右圏でも縦書きされる場合があるらしい。看板とか。

39:デフォルトの名無しさん
05/02/24 18:24:23
まさにアホなスレタイ
文字表示雑談スレ

40:デフォルトの名無しさん
05/02/24 18:30:54
右から左に書く場合でも、数値だけは逆だったりするよね。
日本語にたとえれば、「。すで年2005は年今」みたいな感じ。

41:デフォルトの名無しさん
05/02/24 18:47:29
アホなスレタイだとアホしかよってこない。
スレタイってやっぱり大事なんだね。

42:7
05/02/24 21:50:15
>>8 動作要件に IE4 以上というのが気に掛かる・・・。
>>10 その方法を考えたけど、実行ファイルが肥大化するのと、他の Windows アプリとの
　　データ互換性が保証できなくなるのがネック・・・。
>>15 >>26 一見よさげだけど、たとえば「～」なんか化けてしまうのが致命的・・・。

みなさんどうもでつ。もう少しいろいろ検討してみまつ。

43:デフォルトの名無しさん
05/02/24 22:52:42
>>27
ISO 10646 dis v.1

44:デフォルトの名無しさん
05/02/25 10:20:01
>>41　意外とまともな事言ってる人もいると思うが。

45:デフォルトの名無しさん
05/02/25 10:22:38
URLﾘﾝｸ(suika.fam.cx)
>>43 それって、この表だとどの規格のこと？

46:デフォルトの名無しさん
05/02/25 11:03:27
>>45
DIS 10646:19911990-12-061st DIS

47:デフォルトの名無しさん
05/02/25 12:02:10
>>43
寝言言ってねえで素直にUTF-32でも使っとけ。

48:デフォルトの名無しさん
05/02/25 12:26:02
>>44
Unicodeは複数コードポイントを組合わせる可変長表現なのに、
相変わらず２バイト４バイト固定とか言ってますが。

49:デフォルトの名無しさん
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:デフォルトの名無しさん
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かよ!?
05/02/26 01:44:50
>>55
unsigned _int64って何だよ…

いまや#include <stdint.h>で、uint64_tじゃないのか?

57:デフォルトの名無しさん
05/02/26 02:04:17
>>51
wchar_tはUnicodeが入るとは限らないんだけど、そのままUTF-16やUTF-32
を突っ込んでる実装が多いから良しと仮定しましょう。
wchar_tにUTF-32が並んでいても、そこから文字（grapheme）単位に処理
するにはステートマシンで区切りを探さないといけない。
　URLﾘﾝｸ(www.unicode.org)
こういったことを理解しての発言には見えない。
加えて、ICUもそうだけどUTF-16が処理対象の場合はサロゲート込みで処
理されるからサロゲートの有無で手間は全く変わらない。

58:デフォルトの名無しさん
05/02/26 02:04:28
>55
さすがに地球外知性とデータ送受信するようにでもならないとそこまでは……
いや、そうなったらそうなったで、向こうのコード体系を強引に押しつけられる悪寒orz

59:デフォルトの名無しさん
05/02/26 11:29:58
>>57
> そこから文字（grapheme）単位に処理
> するには
誰もそんなこと書いてないと思うが。

60:デフォルトの名無しさん
05/02/26 12:57:35
文字単位に処理することはあり得るだろう？

61:デフォルトの名無しさん
05/02/26 14:23:12
あり得るけど、それこそ Shift JIS や EUC-JP でAPI/システムコールレベルでは
バイト列として扱い、それを文字に組み上げるのは各アプリケーションの責任という
考え方もあった罠。
この考え方を Unicode にあてはめてみたり、とか。char を wchar_t に変えて。

62:デフォルトの名無しさん
05/02/26 14:42:33
>>61
> あり得るけど、それこそ Shift JIS や EUC-JP でAPI/システムコールレベルでは
> バイト列として扱い、それを文字に組み上げるのは各アプリケーションの責任という
> 考え方もあった罠。

それほど変ってないような…

そしてその「アプリケーションの責任」の技術的な部分の研究を、
一番行っているのはUnicodeの世界なのでは?

63:デフォルトの名無しさん
05/02/26 17:38:26
結局「一文字」単位に扱おうとすると,
ステートマシンは必要になるのか…
なんかあんまり変わってないな，昔と.

64:デフォルトの名無しさん
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:デフォルトの名無しさん
05/02/27 00:27:02
URLﾘﾝｸ(www.hatena.ne.jp)

67:57
05/02/27 00:45:01
>>59
UAX #29でも触れられているけど、文字（grapheme）単位に
処理できないと文字列の文字数を得たり、分解したりできな
いのはもちろん、比較や検索も正しく行なえない。

68:デフォルトの名無しさん
05/02/27 01:24:33
normalize してもコードポイント一つであらわせない文字は正しく扱えません
としても、それほど困らないんだよなあ。
実装コストに見合うメリット無いし。

69:デフォルトの名無しさん
05/02/27 02:13:31
>>67-68
内部文字コードが Unicode 化された Visual Basic 4.0 以降や Java なんかでは、
「文字列をバイト単位で切り出すにはどうすればよいですか？」という質問が
必ず FAQ になってるよな（ｗ

70:デフォルトの名無しさん
05/02/27 02:34:30
U+F92FとU+F98DのkIRG_KSourceが間違ってる件について
これどうやったら修正させることができるんですか
韓国のNational Bodyが言い出さない限り何人たりとも修正できないんでしょうか
とりあえずUnicode 4.1.0βのレビューで指摘してみたけどシカトされますた
ほかの指摘事項はちゃんと反映されてたから指摘そのものは届いてるはず

71:デフォルトの名無しさん
05/02/27 13:12:20
ほかの指摘事項はたまたまほかの人が同じ指摘をしたんだろう

72:デフォルトの名無しさん
05/02/28 07:13:00
5件あって5件ともたまたま別の人が同時に指摘したってあんまりありそうにないような
「報告ありがとう。Unihanの専門家に転送しとくよ彼が今日中に反映してくれるだろう」
みたいな返信もちゃんと返ってきたし。
正規表現が間違いだらけだったから正しいの書いて送ったけど他の誰かが一字一句
ピッタリ一致するような正規表現をたまたま同時に送ってたとかありえなーい。
つーかスクリプトに通して検査するだけで見つかるような誤りがなんでボロボロ
出てきますか? なんのために機械可読な形式で提供してますか?

73:デフォルトの名無しさん
05/02/28 08:42:52
もう一回聞いてみればいいじゃん

74:デフォルトの名無しさん
05/03/01 01:46:45
戸籍やってる身からすれば
康煕字典体はきっちり入っていないと

75:デフォルトの名無しさん
05/03/02 08:36:34
ところで，Unicode って既存のコードとのラウンドトリップは考慮されてるの？
つまり Unicode に変換されたとたん，元のコードでは区別されていた文字が
同じ文字にマップされたりはしないの？
それはいわゆる機種依存文字も含めて？

76:デフォルトの名無しさん
05/03/02 08:53:12
文字コードを作る人は馬鹿ですか？
なんで固定バイト数にしないんだよ。
先頭数ビットを国コードにして残りを文字コードに割り当てる。

似ている文字でも国ごとに別の文字コードにするべきだ。
そして検索の機能として文字コード検索と、文字形検索の二つに分ける。

77:デフォルトの名無しさん
05/03/02 09:06:12
>>76
UNICODE棄てれば実現可能かもね

78:デフォルトの名無しさん
05/03/02 10:18:45
>>76
そしてPhishingが横行

79:デフォルトの名無しさん
05/03/02 10:38:34
多言語ドメインなんてくだらないものは捨てちまえ。

80:デフォルトの名無しさん
05/03/02 14:57:31
>>76
Emacsの内部コードがそんな感じよ。文字列表現はマルチバイトだけど。
国ごとじゃなくて文字集合ごとだけど実質あまり変わらん。

81:デフォルトの名無しさん
05/03/02 15:50:16
マジな話、文字形検索（文字コードではなく文字の形で
検索すると言う意味）って考え方ないの？

同じ形の字でも国が違えば検索に引っかからない方がいいだろうし、
同じ国でちょっと違う形の字でも同じとして検索した方がいいこともあるだろうし、
国は分からないけど、すべての国対象で似ている字を検索したいこともあると
思うんだけどなぁ。

82:デフォルトの名無しさん
05/03/02 15:55:33
1 I l | ! i │ ⅰ Ⅰ (以下略)をどこまで一緒にするのやら

83:デフォルトの名無しさん
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:デフォルトの名無しさん
05/03/02 23:31:01
へとヘは？

86:デフォルトの名無しさん
05/03/03 02:37:43
タと夕とか
トと卜とか

87:デフォルトの名無しさん
05/03/03 04:42:46
ロとか口とか

88:デフォルトの名無しさん
05/03/03 11:42:20
(以下略

89:デフォルトの名無しさん
05/03/03 16:02:46
C++ で文字コード変換したいと思った場合、
Windows + IE5.5 ならば、IMultiLanguage3 を通して変換すればいいが、
UCS-4 のコードから、文字種別などの文字情報を取得するライブラリが
OS標準にないというのが悲しい。

90:デフォルトの名無しさん
05/03/03 16:09:52
Windowsの事しか考えられないバカは去ってくれ。

91:デフォルトの名無しさん
05/03/03 18:27:33
>>90
そりゃ言いすぎ(w

けど、
> Windows + IE5.5 ならば、IMultiLanguage3 を通して変換すればいいが、
つーのが、もうスレの主旨には全く合わないな。
それが良いかどうか語りたいようなヲタの住むスレなんだから。

92:デフォルトの名無しさん
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:デフォルトの名無しさん
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:デフォルトの名無しさん
05/03/10 11:13:14
>>94
SUS的にはchar**が定義らしいが、現実的にはconst char**じゃないと
面倒なんだよな。

96:デフォルトの名無しさん
05/03/10 13:04:58
>>83 に関連した疑問なんだが，各種日本語文字コード，Unicode間で
縦横無尽にマッピングしまくッっても安全な集合って
どこかで定義されてない？？

97:デフォルトの名無しさん
05/03/10 15:21:23
サロゲートうんこ

98:デフォルトの名無しさん
05/03/10 21:21:44
内部はgrapheme clusterを単位にした固定長コードにでもしないと
面倒でやってられんぞ

99:デフォルトの名無しさん
05/03/11 00:57:47
>>95
URLﾘﾝｸ(www.opengroup.org)
では const 付きだけど

URLﾘﾝｸ(www.opengroup.org)
には const 付いてない(つД`)

100:デフォルトの名無しさん
05/03/11 02:55:46
>>96
\~￣―＼～∥…－￥￠￡￢とか
CP932におけるNEC選定IBM拡張文字とか
古えの半角ｶﾅとかの話?

101:デフォルトの名無しさん
05/03/11 05:35:24
①②③④⑤⑥⑦⑧⑨

102:デフォルトの名無しさん
05/03/11 05:55:24
>>100 そう．そういう微妙な文字以外の
「安全な」文字の集合ってどこかでまとめてくれてないかな，と．
自鯖の掲示板で，サニタイジングのついでに警告を出したい．

103:デフォルトの名無しさん
05/03/11 06:33:51
>>98
コードポイント３つ４つの組合せもあるから、余裕も見て内部は
1 cluster=20byte位の固定長？素晴らしい富豪設計です。

104:デフォルトの名無しさん
05/03/11 07:00:57
>>103
任意のスカラ値の組み合わせが可能な訳じゃないからそんなに必要ない

105:デフォルトの名無しさん
05/03/11 07:08:52
よくある実装が必要な組み合わせだけ適当にPUAに割り当てて
知らない/対応する気のないスクリプトはそのまんま素通し
どうせ未定義の符号位置に関しては素通しにせざるを得ないんだし

つーかなんでこうも過度に汎用化したがるんだろうか
シフトJISのアプリケーションがISO 2022完全実装に対応できないから駄目なんて
文句言う奴はいないのになんでUnicodeになったとたん単なる地域化じゃ許されなく
なりますか? 単に漢字をたくさん使いたいだけというささやかな望みも叶いませんか?

106:デフォルトの名無しさん
05/03/11 18:57:03
>>102
(jisx0201左半面 or ASCII) + (jisx0208) - (\~￣―＼～∥…－￥￠￡￢)
前提がひどく厳しいのでこんなものじゃないかしら。
ISO-2022-JPの…なんてことは言わないで頂戴。

いわゆる機種依存文字や半角カナが非互換なのは、unicode以前からの通り。
\~￣―＼～∥…－￥￠￡￢は、unicodeの普及によって新たに生じた非互換。
(余談だけど、後者は終止unicodeのみで処理するときでさえいやらしい。)

「自鯖の掲示板」で「縦横無尽にマッピングしまく」る必要はないようにも思うが。

107:デフォルトの名無しさん
05/03/12 19:44:53
人間はなぜ同じ過ちを繰り返すのでしょうか？

108:デフォルトの名無しさん
05/03/13 00:39:53
>>107
過去の失敗から学ぼうとしないからだ、と何回言ったら分かるんだ

109:デフォルトの名無しさん
05/03/13 08:59:59
>>104
HangulやDevanagariは３つ４つ平気で使うよ。

110:デフォルトの名無しさん
05/03/13 09:14:00
>109 タイ語もたくさん使うよ。

111:デフォルトの名無しさん
05/03/16 01:50:18
>>109-110
だから3つ4つの任意の組み合わせがすべて必要なわけじゃないだろ。
Windowsのフォントフォルダ見てもインド語のフォントは500KBもないし
実際にPUA使ってリガチャを実装してるタイ語やインド語のフォントだって
BMPの6400文字で十分に足りてる。理論上可能なすべての組み合わせを
サポートするニダ150万コードポイント必要ニダUTCは謝罪と賠償しる!
とはさすがの韓国も言ってないみたいだし。
そもそもそんなこと言い出したらIdeographic Description Sequenceなんか
最大16コードポイントの並びだし。

112:デフォルトの名無しさん
05/03/16 06:11:24
>>111
要約すると「Windowsでは使わない、使えないから不要」ということ？
でしたら特定の実装上と限定して話しをして下さい。

ちなみにAppleのATSUIだと、PUA使ってリガチャを実装なんて変なこと
はやってないから、長いdecompositionで表現したcomplex scriptでも
glyph metamorphosis tableを使って適切なglyphを拾って来る。
この実装上では、complex scriptが扱えなかったり、ヒラギノOpenType
の豊富なglyphを使えないと粗悪品とみなされます。

113:デフォルトの名無しさん
05/04/27 20:33:59
Windowsが扱うコードをすべてutf-8に統一したいんですけど、できますか?
たとえば、コマンドプロンプトとかでutf-8で書いたコンソールに文字列を出力するjavaのコードをコンパイルしたものを実行したいんです。
現状では、コマンドプロンプトはMS932(Shift_JIS)と勝手に解釈してへんちくりんな文字列を出力します。

114:デフォルトの名無しさん
05/04/27 21:23:00
>>113
毎回MultiByteToWideChar(CP_UTF8, で変換するしかない。

115:デフォルトの名無しさん
05/04/27 23:05:28
>>113
CygwinのLC_ALLにutf-8って指定できなけったった？

116:デフォルトの名無しさん
05/04/28 10:40:23
OutputStreamWriter(system.out, "MS932")

117:デフォルトの名無しさん
05/04/30 13:39:58
>115
Cygwin のロケール周りはきちんと実装されていないはず。

118:デフォルトの名無しさん
05/05/02 09:12:23
経済産業省が、こんなこと発表してた。
URLﾘﾝｸ(www.jisc.go.jp)

現在、最新のＪＩＳ漢字コード表を採用した情報機器は多くありません。
しかしながら、人名用漢字の改正を契機に最新のＪＩＳ漢字コード表が普及することが期待されます。
人名用漢字（９８３字）の水準ごとの字数は、次のとおりです。
第１水準：６８５字第２水準：１９１字第３水準：１０７字第４水準：０字合計：９８３字
（注）第１水準漢字及び第２水準漢字しか実装していない情報機器では、
１０７字の人名用漢字について情報交換が行えないことになります。

これは、Unicode導入をどんどん進めろと言いたいわけか ?

119:デフォルトの名無しさん
05/05/03 00:43:07
>>118
AppleもMicrosoftも、UnicodeのレパートリとしてしかJIS X 0213はサポートしないと
ずっと前から言っている。それをようやく追認しただけ。
その発表書いた中の人のコメント↓
URLﾘﾝｸ(slashdot.jp)

120:デフォルトの名無しさん
05/05/03 00:53:27
リンク先にはもうコメント付けられないからここに書いとこう
> ＃戸籍統一コードのページができているのにも気がついた。これはいわゆる
> 住基コードなんだろうか。
違うもの(なんつー税金の無駄遣い…)。
URLﾘﾝｸ(www.itscj.ipsj.or.jp)

> 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:デフォルトの名無しさん
05/05/03 00:55:28
> 変えたのをお忘れですか
これは本気で忘れてる可能性もあるんだよな
あれだけあれこれ言い訳してるJIS X 0213:2004の解説でもこの件には
なぜか一切触れてないし

122:デフォルトの名無しさん
05/05/04 15:54:55
JIS X 0213 で例示字形が大幅に変えられたことの影響はどうでるか。

以前、小形克宏氏は「文字の海、ビットの舟」で
「ほとんどのフォントベンダーの対応は、... 世間が新しいMS書体を
どう受け入れるかを見極めた後になるはず。」としていた。
URLﾘﾝｸ(internet.watch.impress.co.jp)
しかし、Windows でまず登場したのは、ジャストシステムからで、
一太郎2005ユーザー登録特典の「JIS X 0213:2004」対応フォント
が登場した。URLﾘﾝｸ(www.ichitaro.com)

日本工業標準調査会のサイトが「最近、JIS X 0213:2004について問合せが
多いため」と、JIS X0213 関連の情報をまとめたページを作ったのは、
ここからリンクがあるためだろう。URLﾘﾝｸ(www.ichitaro.com)

このフォントは一太郎で標準ではなく、無償であってもオプションのフォントだ。
そうなっている一番の理由は、JIS2004 での大幅な例示字形の変更に対応して
表外漢字字体表の印刷標準字体を使ったフォントだからに違いない。
既存の文書までフォントが変わったことで、意識しないのに字体が
大きく変わってしまっては困るから。
標準のフォントを変えたり、それしか使えなくなっては 83JIS の時の二の舞。

今後マイクロソフトが JIS2004 にどう対応するのかは、はっきりしないとしても
似たような対応になるだろう。
マイクロソフトは表外漢字字体表が制定された時に、JIS漢字の例示字形について
「今回仮に例示字体・字形を差し替えたとしても、差し替えられた面区点位置に
包摂されている字体・字形をもとに実装することは依然として規格に反しない」
「こうした利用者が意識しない変更を生産者が押しつけるわけにはいかないので、
利用者が意識して表外漢字字体表の字体を選択できるよう生産者は考えざるをえない」
との見解を表明していた。もっともな見解だ。
MS の方こそ、当面は今の MS明朝・MSゴシックでやっていって、どんな利用者の要求
があるか様子みましょう、となって急がないかもしれない。

123:デフォルトの名無しさん
05/05/04 17:33:54
人名用漢字は印刷標準字体の方で規定されている。
もともと第1・第2水準漢字を規定した JIS X 0208 の例示字形は変更されていないと
いうから、第1・第2水準の漢字の字形は、JIS としても実装としても、
2種類あることになって、必要に応じて使い分けることになっていくのか。

124:デフォルトの名無しさん
05/05/04 18:44:59
>>119 があげていた安岡先生のコメントに
> でもJIS X 0213の「エンコーデング」の主流が「Adobe-Japan1」
> になるのだけは、個人的に勘弁してほしい。
とあった。Adobe が「エンコーデング」というのは笑えるが、けっこう強そう。

125:デフォルトの名無しさん
05/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:デフォルトの名無しさん
05/05/04 19:41:07
>>124
> Adobe が「エンコーデング」というのは笑えるが、
Adobe-Japan1-0～Adobe-Japan1-6はCIDをビッグエンディアンでそのまんま並べた
エンコーディングの名称でもある

127:デフォルトの名無しさん
05/05/06 09:15:37
> Longhornではこういうことができるらしい
> <Inline Typography.EastAsianLanguage="NLCKanji">葛</Inline>飾区
そういえば、Longhorn ではインターフェースを XML 使って構築する話、
どこかで聞いたな。そこでフォントも指定できるか。

128:デフォルトの名無しさん
05/05/06 10:43:31
印刷標準字体を採用となれば、葛飾区は喜ぶ方の口だったっけね。
茨城県や芦屋市もいいのかな。小樽市や灘区はどうなん ? どっちでもいい ?

129:デフォルトの名無しさん
05/05/06 13:18:54
奈良県に葛城市ができたのは知らなかったぞ。
こっちは、JIS X 0213:2004 改正で消滅した字体の方を使ってるじゃないか。
なんなら、JIS X 0208 字体を使い続ければいいけど、たいていは、いちいちフォント切り換えないぞ。

130:デフォルトの名無しさん
05/05/07 12:45:46
JIS漢字コードとその実装の字形が2種類になるのは、表外漢字字体表からの当然の帰結。

131:デフォルトの名無しさん
05/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:デフォルトの名無しさん
05/05/07 16:46:41
なお、なぜ第3位が浮上したかというと、新市名称候補選定小委員会が
「人」と書いても「ヒ」と書いても同じ「葛城市」だから同一と考え、
そこからパソコン等で使われている方との理由で「ヒ」と書く「葛城市」を
候補として選び、住民アンケートの結果、第1位を獲得したからである。
このとき、すでに表外漢字字体表はもちろん、JIS X 0213:2004 も公示されていたが、
候補選定小委員会で検討された様子はない。届いていなかったと思われる。

133:デフォルトの名無しさん
05/05/08 01:08:31
>>132
「パソコン等で使われている方」でちょっと思い出した事が。
こないだ、青森県西津軽郡車力村が他と合併して「つがる市」に
なったんだけど、その時にある字名の表記が変更になった。
旧：青森県西津軽郡車力村大字下牛潟字靎舞岬（つるまいみさき/靎は雨冠の下に金+鳥（U+974E））
新：青森県つがる市下牛潟町靏舞岬（つるまいみさき/靏は雨冠の下に鶴（U+974F））
URLﾘﾝｸ(www.city.tsugaru.aomori.jp)

鶴にするならともかく、どっちも第3水準だし最初は疑問に思ったんだけど、
これって靏がWindowsの外字部分に含まれてたから表記しやすい
方に、って事だったのかもしれない。

134:デフォルトの名無しさん
05/05/08 03:15:01
統一するってことは、世界中の文字を表現できるようにするってことだよな？
しかし、それぞれが持ち寄った文字数をみると漢字圏が大きすぎる
普段は使わない人々からすれば対応するだけ無駄が多すぎとしか思えない

言語統一を推進するほうが将来的にいいじゃんてことになる。だから無理

135:デフォルトの名無しさん
05/05/08 12:15:56
あのね、Apple, IBM, Microsoft, Sunの様な会社は、
漢字文化圏も重要なマーケットと考えているんですよ。
君のいる三流ソフトハウスは違うだろうけど。

136:デフォルトの名無しさん
05/05/09 00:29:37
漢字文化圏でも今や重心はあっちの国だがな。

137:デフォルトの名無しさん
05/05/09 10:03:40
sunの禿、ギコが見れてうれしいって言ってた気がするなぁ。

138:デフォルトの名無しさん
05/05/09 10:54:58
>>134
いいから黙ってUTF-8使っとけ

139:デフォルトの名無しさん
05/05/09 10:56:38
なるほどねえ。Longhorn での WinFX のクラスライブラリ予定を見たら、
"FontEastAsianLanguage 列挙体" なんてのがあって、
フォントによって字形(glyphs) が異なるバージョンを並べて、選択できるようになってる。
JIS78, JIS83, JIS90, JIS04, HojoKanji と、ここまで日本向けか。
確かに、これが簡単でないと、この先は困るよ。よくわかっていらっしゃる。
日本もまだ、Microsoft の重要なマーケットですって。

140:デフォルトの名無しさん
05/05/09 22:30:04
ちなみに Mac OS X の対応してそうな機能
URLﾘﾝｸ(developer.apple.com)

141:デフォルトの名無しさん
05/05/10 00:22:53
>>140
これは最新の情報ではないよ。実際に使えるのはもっと多い。
フォントパネルからTypographyパレットを出せば、フォント毎に
使用可能なFont Featureが列挙される。
>>131
で出ている「葛」もヒラギノを使っていればどちらの字体も選べる。
これはOSXのAAT+ATSUIで「今」できる機能

142:デフォルトの名無しさん
05/05/10 05:31:04
「Updated 2/5/98」だから最新の情報なわけはないと思ってたけどやっぱりそうか。

143:デフォルトの名無しさん
05/05/10 05:38:41
あとはAdobe Japan1-6をJIS X 4165(ISO/IEC 10036)に登録してくれれば
インターネットでの情報交換も問題ないんだけどねえ
誰かやってくれないかなあ

144:デフォルトの名無しさん
05/05/10 09:36:35
第3水準漢字を含む人名用漢字表のテキストを作る実験してみました。報告します。

人名用漢字表テキストを作る簡単な方法は、経済産業省から
「人名用漢字の文字符号に関する規格検討会報告」（PDFファイル）
をダウンロードし、この中の人名用漢字表をエディタ等にコピー&ペーストして
Unicode のエンコーディングで保存する方法です。これなら入力手段も不要です。
すべて BMP 内ですから、サロゲートペア対応までは必要ありません。
URLﾘﾝｸ(www.jisc.go.jp)

最初は、総務省の法令データ提供システムから「戸籍法施行規則」を見て、
そこの漢字表を調べたのですが、正式の表の形を知るにはこちらが必要でも、
内容はとんでもないものでした。一度、見比べて下さい。
URLﾘﾝｸ(law.e-gov.go.jp)

水準別の一覧表としては、こちらを参照できます。
URLﾘﾝｸ(www.eonet.ne.jp)

145:デフォルトの名無しさん
05/05/10 09:38:26
人名用漢字を表示するには、やはり JIS X 0213:2004 対応フォントが必要なようです。
たとえば、一太郎2005 で入手できる JS平成明朝W3[JISX0213:2004] を使えば、
第3水準漢字も含めすべて表示されますし、戸籍に認める正しい字形です。
Windows では、他のフォントを使うと第3水準の分の半分ほどが表示できませんでした。
表示される字も、字形が人名用漢字としては正しくないものが多く出ます。
たとえば、「人」と書く「葛」が正しい所が、「ヒ」と書く「葛」になるわけです。
JISの包摂基準では同じ字であっても、戸籍上の名では字形が限定される点が、
この先、人名データの扱いが難しくなる所です。
「葛城市の山田広葛くん」が誕生したら、２つの「葛」の字形は異なるのが正しい、
なんてケース、どう処理しますか。
まあ、表外漢字字体表を楯に、人名優先で有無を言わせず印刷標準字体を使うのが、
簡単だとは思ってますが。ごめんなさい、葛城市。

漢字表のコピペ先のエディタとしては、Windows XP の場合はメモ帳が適当でした。
このテキストを表示させようとして、予想以上の壊滅的打撃を受けたのがエディタでした。
第3水準漢字をきちんと表示できないものが多そうです。
Unicode のエンコーディングを読み書きできるということと Unicode 対応ということが、
まったく違うことだ、という当たり前のことが現実のものとなります。

146:デフォルトの名無しさん
05/05/10 19:54:41
> なんてケース、どう処理しますか。
Longhornまで待つかMacを買うかだな。

147:デフォルトの名無しさん
05/05/11 10:51:54
> Longhornまで待つかMacを買うかだな。
その限りならそうとして、MacはJIS X 0213:2004対応済? 待ち?

148:デフォルトの名無しさん
05/05/11 11:24:31
Mac OS Xは、JIS X 0213:2000に対応すると一時言ったけど、
結局Unicodeに含まれる限りにおいて、と修正。
2004も同様。いわゆる対応はやらない。

149:デフォルトの名無しさん
05/05/11 12:31:56
>>148 なるほど。
Shift_JIS-2004 はサポートしないと言っているということかな。

150:デフォルトの名無しさん
05/05/11 21:27:53
レパートリが揃っているか、という意味なら現時点で対応済み。

151:デフォルトの名無しさん
05/05/11 22:58:00
>>149
Shift_JISX0213には対応してるみたいよ。
2004は知らん。

>>150
内部がUnicodeだと、合成に対応しているかどうかが問題になる。
半濁点つきのカキクケコ(鼻濁音用)とか、半濁点つきのトツセ(アイヌ語用)とか。
そこまで注意しないと、がっかりする人が出るはめになる。

152:デフォルトの名無しさん
05/05/11 22:59:31
セミナー：　CJKV 日中韓越情報処理
URLﾘﾝｸ(www.jtpa.org)

講演は英語だってさ。

153:デフォルトの名無しさん
05/05/11 23:16:08
最近（でもないか?）CJKV って聞く様になったけど、何で越南だけ追加されたんだろう

154:デフォルトの名無しさん
05/05/12 00:42:46
>>151
OSXは現状で合成に対応してます。
ATSUIは正しくレンダリングするし、区切り判定も合成文字を１文字と
認識します。
このスレでも散見されるけど、合成対応は意味がないから無視という姿
勢のアプリケーションではだめですね。

155:デフォルトの名無しさん
05/05/12 00:52:27
>154
おお。なかなか。
ところでデーヴァナーガリーなんかのリガチャはどうなるんだっけ?
あれを一律「一文字」にされると古典を扱うときヽ(`Д´)ﾉｳﾜｧｧﾝなことになるんでちと気になって。

156:デフォルトの名無しさん
05/05/12 05:16:53
>>151
青空文庫の中の人によればShift_JIS-2004には未対応
URLﾘﾝｸ(www.siesta.co.jp)
これは去年の話だからもしかしたらTigerは対応したのかもしれないが
そこまでは知らん

157:デフォルトの名無しさん
05/05/12 07:51:51
包摂に対する考え方が、JISとUnicodeは違うけど、
2004なら追加文字で問題がなくなる→JIS X 0213対応ってわけ?

158:デフォルトの名無しさん
05/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:デフォルトの名無しさん
05/05/12 12:45:04
蛇足だけど、Unicode マンセーって言ってるわけじゃない。
Unicode導入とは非関税障壁撤廃が進んでいるというだけのこと。
ただ、それで便利にできる所は利用する。
中国の方が日本より上手に対応してきた。

160:デフォルトの名無しさん
05/05/12 19:35:44
>>159
> 中国の方が日本より上手に対応してきた。

これマジレス?

161:デフォルトの名無しさん
05/05/13 04:48:38
つまり中国を見習って、Unicodeの全文字を含み1文字最大4バイトで表現する
新しい文字集合とエンコーディングをJISで定義して、全ての市販ソフトに
その採用を義務付けろと主張するわけだな? >159

162:デフォルトの名無しさん
05/05/13 17:44:09
超漢字マンセー

163:デフォルトの名無しさん
05/05/13 20:15:32
GB18030の影響でMeは発禁

164:デフォルトの名無しさん
05/05/13 20:21:36
>>157
2004で追加された以外の文字ではまだ問題が残ってる。
JISとUnicodeで包摂規準が明らかに矛盾してる文字の一覧とか
調べてみたいんだが面倒で挫折中。

165:デフォルトの名無しさん
05/05/13 20:24:14
>>160
波ダッシュはチルダではないとか意地を張ったりしないで
GBKをそのまんま追認した点とか。

166:デフォルトの名無しさん
05/05/13 23:40:13
>>165
> 意地を張ったりしないで

これってマジレス?

167:デフォルトの名無しさん
05/05/14 10:14:12
>>155
複雑なリガチャ付き文字はマウス操作やカーソルキー移動では１文字扱いですが、
デリート時は適度に分割されて扱われます。
Devanagariは理解できないので実装の正確さは判断できません。
OSX標準の状態でもDevanagariを扱うためのリソースは揃っていますので、実物で
確かめてみて下さい。

168:デフォルトの名無しさん
05/05/16 20:57:28
>>166
94x94の表の空き領域にも全部PUAへの写像を定義した点とか

169:デフォルトの名無しさん
05/05/16 21:41:37
Unicode 4.1でU+2B00とU+2B01、U+2B08とU+2B09のグリフが入れ替わった件について
URLﾘﾝｸ(www.unicode.org)

170:デフォルトの名無しさん
05/05/17 15:31:46
>>169を見て気づいた。
Code2001のU+1D301～U+1D303の実装がおかしい。

171:デフォルトの名無しさん
05/05/18 06:35:24
実はU+1D300～U+1D305の文字名で地と人が入れ替わってる件について

172:デフォルトの名無しさん
05/05/18 11:17:35
>>171
ｽﾚﾘﾝｸ(gengo板:170番)

173:デフォルトの名無しさん
05/05/18 20:23:41
>>172
つーかそれ書いたの漏れ。

U+3020のナンバー君がMeiryoでポストン君に変わってる件について
URLﾘﾝｸ(www.post.japanpost.jp)
これは包摂の範囲なんですか? U+3004のJISマークもそのうち変わりますか?
URLﾘﾝｸ(www.jisc.go.jp)
ちなみにユーロ記号はデザインが変わったとき新たにコードを割り当てられた。
まあUnicodeの欧米偏重は今に始まったことじゃないけど

174:デフォルトの名無しさん
05/05/18 21:12:03
この際だから>>169も解説しちゃおう
U+2B00～U+2B0Dの矢印類はKPS 9566をソースに北朝鮮が追加提案した(N2056)。
URLﾘﾝｸ(std.dkuug.dk)
このときの並び順は右上→左上の順だった。
すくなくともPDAM2まではその順だったのだが(N2395)、
URLﾘﾝｸ(std.dkuug.dk)
FPDAM2になってなぜか突然グリフの順番が左上→右上に入れ替わった。
URLﾘﾝｸ(std.dkuug.dk)
後から説明しているところによると(N2926 T.7とか)、Unicodeの他の矢印では
左上→右上だったからそれに合わせたかったのだろうとか。
でもFPDAM2で入れ替えたのはグリフだけで、名前を入れ替え忘れて(証拠は
N2491のチャートに残ってる)、そのままAmendment 2=Unicode 4.0 BMPに
なってしまった。
正式にAmendmentになってしまった以上もう名前は変えられないので
グリフを入れ替えることにした(N2926)。
URLﾘﾝｸ(std.dkuug.dk)
もうアホかと。

175:デフォルトの名無しさん
05/05/20 11:49:25
ユニコードHPが見られなくなっているんですが、
自分だけでしょうか･･･。

Unicode Home Page
URLﾘﾝｸ(www.unicode.org)

176:デフォルトの名無しさん
05/05/20 12:52:42
>>175
世界中であなただけです。

177:デフォルトの名無しさん
05/05/25 22:49:03
Ideographic Variation Sequencesキター
URLﾘﾝｸ(www.unicode.org)
# 例によって日本はシカトして事実上中国のSimplified Variant専用になる予感

178:デフォルトの名無しさん
05/05/28 20:45:42
>>175
一週間以上たってるが、俺も見れねぇ。

179:デフォルトの名無しさん
05/05/28 23:26:48
今見られるよ
ちなみに Announcements のトップは UCB の記事で 2005.05.06 の日付け

180:デフォルトの名無しさん
05/05/28 23:27:12
2005.05.09 だったorz

181:デフォルトの名無しさん
05/05/31 09:50:40
サロゲートペア、動作テスト中
呼吸深く𠹭囉仿謨(コロロホルム)や吸ひ入るる―北原白秋
呼吸深く��囉仿謨(コロロホルム)や吸ひ入るる―北原白秋

182:デフォルトの名無しさん
05/06/02 15:10:19
サロゲートペア対応
Netscape ○
Firefox ○
MS IE6 ×

183:デフォルトの名無しさん
05/06/02 17:54:59
>>182
IEはレジストリ弄る必要がある　ウチはIEで表示出来てるぞ

184:デフォルトの名無しさん
05/06/03 12:05:48
>>183
そうだったのか、知らなかった。と、調べてみたものの、よくわからなかった。
レジストリの弄り方、教えて下さいませ。

185:184
05/06/03 12:50:10
おっと、「non BMP対応」を説明した
URLﾘﾝｸ(charset.info) を発見。
ここの「レジストリを修正してフォントを指定する」をやったら
IEで無事に表示できました。

186:デフォルトの名無しさん
05/06/26 13:21:15
>>157 >>164
Unicode での JIS X 0213対応で問題として残っているのは、包摂規準以外にもありそう。
JIS X 0213 の文字の中には、完成形での収録が認められず、
「文字合成」で表現することになった文字が25文字ある。
URLﾘﾝｸ(charset.info) ここにある。
１文字だけでは表現することができない文字があるわけで、
表現するには合成可能な「結合文字」を使わなければならないんだが、
これを全部正しく処理できるシステムとフォントという条件は、かなり敷居が高い。
表示できても、「正規化」に対応していないと問題が起こるし。
今は厳しすぎかも。とりあえず Y.OzFont4 がベストなのかな。
Macならうまくいくか?

187:デフォルトの名無しさん
05/06/26 13:37:37
>>186
それは規格に適合してない処理系だから、
>>157 >>164の話とはレベルが全然違うでしょ

188:デフォルトの名無しさん
05/06/26 14:14:45
そう。「規格に適合してない」という実装の問題が一つあって、
これは、きちんと実装されれば解決の話。確かにレベル違うな。

一方、U+309Aの合成可能な半濁点を使わなければ、鼻濁音等が表現できないんだが、
これは JIS X 0213にはなかったりするズレは、
やはり Unicodeと JIS X 0213の関係の問題でもあるんじゃないかと
思ったりするが、どんなもんなんでしょう。
JIS X 0213:2004対応を言うジャストシステムの平成書体で、
U+309A が合成可能になっていないのはバグだろうか。

次ページ