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 が合成可能になっていないのはバグだろうか。
189:デフォルトの名無しさん
05/06/26 14:25:37
ジャストシステムの書体使ってるけどU+309Aはちゃんと合成できるよ
(ただしJIS X 0213に規定されてる組み合わせだけ)
そんなことよりこの書体の問題はU+02EFとU+02F0に規格違反の文字が
入ってること
190:デフォルトの名無しさん
05/06/26 14:37:07
U+02EFとU+02F0 にこれがあるのは知らなかった。
Y.OzFont4 もここに同じグリフがあるんだけど、どうしてなんでしょう?
事情おしえて。
191:デフォルトの名無しさん
05/06/26 14:48:24
あれ。
U+02EF MODIFIER LETTER LOW DOWN ARROWHEAD
U+02F0 MODIFIER LETTER LOW UP ARROWHEAD
となってて、どちらも Introduced in Version: 4.0 とある。
規格になったんじゃないでしょか。
192:デフォルトの名無しさん
05/06/26 14:59:41
規格になっているのなら、
これとJIS X 0213の声調記号 1-11-69 (U+02E9 U+02E5) と 1-11-70 (U+02E5 U+02E9) が
文字合成でできたりすることとの関係は、どうなってんだろう。
同じなら、どっちが正規化形式なのか調べておこう。
193:デフォルトの名無しさん
05/06/26 15:10:33
>>190-192
U+02EF MODIFIER LETTER LOW DOWN ARROWHEAD
U+02F0 MODIFIER LETTER LOW UP ARROWHEAD
はUnicodeのチャート見れば分かるけど
URLﾘﾝｸ(www.unicode.org)
JIS X 0213の1-11-69、1-11-70とはまったく違う文字。
じゃあ何でY.OzFont4やジャストシステムの平成書体がそこにグリフ入れてるかというと
たぶんJIS X 0213:2000のカッコ付きUCSがその値だったからだと思うけど
Unicode的には完璧に違反。
194:デフォルトの名無しさん
05/06/26 15:12:07
ちなみにカッコ付きUCSは単なる「参考」であって、
JIS X 0213:2000では1-11-69、1-11-70には対応するUCSは存在しないと
「規定」されていたので、いちおう違反はしていないという建前
195:デフォルトの名無しさん
05/06/26 15:30:57
なるほど。
合成の方の 1-11-69 (U+02E9 U+02E5) と 1-11-70 (U+02E5 U+02E9) とは
Unicode 的には無関係ということか。
こういうケースも、包摂範囲とは認められない違反となるのか。
でもって、これらのフォントでは、無関係だけどグリフ置換でこれを使うために、
あえてこの形で置いてあるわけかな。
196:デフォルトの名無しさん
05/06/26 15:42:34
いやこの場合まったく包摂の余地ないし。なんでもかんでも多重にグリフを付与できる
魔法の言葉じゃないですよ?
グリフ置換するためにコードを与える必要はない。
Y.OzFont4は独自仕様であえて与えている(技術的問題ではない)と作者が明言している。
ジャストシステムのほうは知らないけど。
197:デフォルトの名無しさん
05/06/26 15:47:45
そうなんだ、いろいろ教えてもらいました。ありがとう。
198:デフォルトの名無しさん
05/06/29 09:18:53
"こんにちは"とだけ書いたUTF-8なテキストファイルを作成するコンソールプログラムを作りたいのです。
環境はMSVC6.0でして、プリプロセッサ定義の_MBCSを消去して_UNICODEとUNICODEを追加し、リンクオプション・エントリポイントには「wmainCRTStartup」を設定しました。
結果は文字化けしたものが出力されてしまいます。何がいけないのかご教授願えますでしょうか。
#define tstring wstring
#define tofstream wofstream
// IMBUE_NULL_CODECVTマクロについては URLﾘﾝｸ(www.codeproject.com)）
// からコピーしました。長いので略します。
void _tmain(int argc, TCHAR* argv[], TCHAR* envp[])
{
USES_CONVERSION;
tofstream zFileOut ;
IMBUE_NULL_CODECVT( zFileOut )
zFileOut.open( "C:\\temp\\test.txt", ios::out|ios::binary ) ;
zFileOut << _T("こんにちは");
}
199:デフォルトの名無しさん
05/06/29 18:34:44
>>198
そもそもそこのURLの中にUTF-8という言葉も出てこなし、UTF-16から8への変換をしているコードも見当たらない。
肝心のクラスもNullCodecvtっていかにも何もしなさそうな名前だ。（実際そうだし）
つまりそこのはASCII限定だろ。
200:198
05/06/30 11:09:52
>>199
すみません、UTF-8とUTF-16の違いもわかっていませんでした。
少し調べたのですが、UNICODEは文字セットの呼称、そのためのエンコード方式にUTF-8（可変マルチバイト）,
UTF-16（固定マルチバイト）などがある、ということでよいでしょうか。
また、リンク先の記事では、メモリ中のUNICODE（16ビット固定？）の文字をwfstreamでファイル出力すると
ASCII文字のコードが8ビットにされてしまうことが問題にされているのですね。
質問を変えさせてください。
(1) "<?xml version="1.0" encoding="UTF-8"?>"といったようにUTF-8が指定されているXMLファイル
がありますが、これはそのファイル自体の文字コードがUTF-8でなければならないことを意味するのでしょうか。
(2) STLのfstreamでUTF-8形式のファイルを作成したいのですが以下のコードでは
うまく行きません。解決方法をご教授願えませんでしょうか。
（環境はMSVC6です。プリプロセッサで"_UNICODE"を定義したうえエントリポイントも
先の投稿の通り変更しています。）
void _tmain(int argc, TCHAR* argv[], TCHAR* envp[])
{
wofstream zFileOut ;
zFileOut.open( "C:\\temp\\test.txt", ios::out) ;
zFileOut << _T("こんにちは");}
}
201:デフォルトの名無しさん
05/06/30 11:47:11
(1) ファイルは別のエンコーディングでも構わない。
ただ、そのXMLデータの場合、処理系が解釈する場合はUTF-8と想定する。
処理系に渡す際、UTF-8エンコーディングに変換するのは、
XML処理系を含むシステムの責任。
例えば、JIS X 0208に含まれる文字しか使われていないとして、
ファイルはShift_JIS, EUC-JP, ISO-2022-JPエンコーディングで、
処理系に渡す際に(encoding="UTF-8"と宣言されているので)UTF-8に変換して
渡すシステムも一向に問題がない。
これは例えばhttpによるContent-Type: text/xml; charset=XXXも場合も同様。
URLﾘﾝｸ(www.w3.org)
ドキュメントエンティティと外部表現の違い。
ドキュメントエンティティがどのような外部表現をもつかXMLの仕様が関与するところではない。
202:デフォルトの名無しさん
05/06/30 13:19:15
>>200
(1)XMLパーザにそのファイルをそのまま渡すのなら、UTF-8でなければ
ならない。201さんも書いているようにUTF-8でなくてもいい場合も
あるけど、ややこしいのでUTF-8にしときなさい。
(2)Windowsだったら
WideCharToMultiByte(CP_UTF8, 0, L"こんにちは", -1, dest, destlen, NULL, NULL);
てな感じでUTF-8にしてからofstream(wofstreamではない)に出せばいい
んじゃないかな。C++標準の範囲でUTF-8化できるかどうかは知らない。
203:デフォルトの名無しさん
05/06/30 14:33:53
上のURL本文のプログラムは、確かにUTF-8化ができる様子ないな。UTF-16だけでしょ。
あとのスレッド URLﾘﾝｸ(www.codeproject.com)
の codecvt_UTF16_to_CESU8 あたりがUTF-8化のものなのか、試したら。
ここのCESU-8とか"UTF-8 light"って、どんなものかは知らないが。
204:デフォルトの名無しさん
05/06/30 15:11:37
CESU-8 で検索するといろいろ出るな。
UTF-8 ならsarrogate対応を4バイトでするところを、
3バイト×2 = 6バイトにしておく方法か。
205:デフォルトの名無しさん
05/06/30 20:53:59
CP_UTF8にはセキュリティホールがある罠
206:デフォルトの名無しさん
05/06/30 21:11:09
KPS9566を拡張すれば結構いい感じの文字コードになるかも。
207:デフォルトの名無しさん
05/06/30 21:25:28
KPS9566ってどっちかというと最悪に近いと思うけど
(将軍様専用ハングルの件は置いたとしても)
208:デフォルトの名無しさん
05/06/30 21:39:54
そうかもしれんな…
209:デフォルトの名無しさん
05/06/30 22:15:25
>>205
マジ？
210:デフォルトの名無しさん
05/06/30 22:34:43
詳しくはほぼ前スレに書いた
211:デフォルトの名無しさん
05/06/30 22:43:07
>>210
読んだ。なるほどと思った気がする。
212:198
05/07/01 08:51:51
アドバイスありがとうございます。
(1)については了解いたしました。ファイルはUTF-8のエンコーディングで行きたいと思います。
>>202
以下のようなコードを試して見ましたがやはり文字化けしたものが出力されます。
（結果のファイルをWinのノードパッドでUTF-8形式でオープンして確認しました。）
void _tmain(int argc, TCHAR* argv[], TCHAR* envp[])
{
ofstream zFileOut;
char dest[1024];
WideCharToMultiByte(CP_UTF8, 0, L"こんにちは", -1, dest, 1000, NULL, NULL);
zFileOut.open( "C:\\temp\\test.txt", ios::out ) ;
zFileOut << dest << endl;
}
デバッガではdestのアドレスに以下のようなコードが書き込まれていました。
E2 80 9A C2 B1 E2 80 9A C3 B1 E2 80 9A C3 89 E2 80 9A C2 BF E2 80 9A C3 8D 00
ちなみにC形式でのFILEを用いて出力してみましたが、まったく同じ結果が得られました。
>>203
こちらも試しましたがやはり文字化けしてしまいます。
なにかさらにヒントがあればご教授ください、、、。
213:デフォルトの名無しさん
05/07/01 09:22:44
そのソースは何エンコーディングでファイルに保存されているの?
WideCharToMultiByte()のWideCharっていうのは、そのエンコーディングのことなの?
# なおそのAPIのことは全然知りません。
214:デフォルトの名無しさん
05/07/01 10:32:39
>>212
こぴぺして試したらきちんとUTF-8で保存されていた。
ソースはSHIFT-JISで保存。
215:デフォルトの名無しさん
05/07/01 11:06:51
いろいろやって出来ればいいんだけど、
その場合、UTF-8にしたくて標準C++の範囲でよいなら、簡単な話としては、
ソースファイルをUTF-8で保存してコンパイルが通るか、という問題なんじゃないの。
MSVC Toolkit 2003(フリーのやつ)でやる限り、
入門的な標準C++プログラムをUTF-8(ただしBOM付き)で保存すれば、
> "こんにちは"とだけ書いたUTF-8なテキストファイルを作成するコンソールプログラム
は出来てしまうんだけどね。MSVC6.0は知らないけど。
gcc だと、BOMなしのUTF-8にすればコンパイルできるようだな。
216:デフォルトの名無しさん
05/07/01 12:54:33
>>214
そのコンパイラはShift_JISを理解して、
wchar_tなL"こんにちわ"の文字列リテラルを構成するんだね。
wchar_tはUCS-2なのかな?
217:デフォルトの名無しさん
05/07/01 13:34:10
>>212
たしかに、おかしいね。
L"こんにちは" が期待通りの値になってないのかな?
218:デフォルトの名無しさん
05/07/01 13:50:23
WideCharToMultiByte() というのは、名前は変だけど、
エンコーディング変換をするWin32APIを使っているんでなかったっけ。
219:デフォルトの名無しさん
05/07/01 17:04:02
>>212
俺はそのコードでうまくできたけど。
220:デフォルトの名無しさん
05/07/01 21:24:42
VC6とBCC5.5ではうまくいくことを確認した。
どちらもソースはSHIFT-JISで保存。
221:198
05/07/01 22:21:50
アメリカに在住しておりまして、返事が遅くなりすみません。
コードを試していただいた方々ありがとうございました。
大切なことを言い忘れていましたが、私の環境は英語版XP上の英語版MSVC6なんです。
XPのシステムロケールはJapaneseにしています。
（コントロールパネル->Regional and Language Options->Advancedタブ->Language for non-Unicode programsにJapaneseを指定）
ソースファイル自体はSHIFT_JISで保存されているように思われます。
（Meadowのモード行でSと表示されています。）
222:デフォルトの名無しさん
05/07/01 22:31:56
いっそのこと、自前で書いてしまうのはどうか？
UTF16とCESU-8の相互なら大した手間ではないと思う。
223:デフォルトの名無しさん
05/07/01 23:57:27
>>221
L"申し上げます"がメモリ内でどうなっているか、hex dumpするとどうなってる?
$ printf 申し上げます | iconv -f euc-jp -t shift_jis | hexdump -C
00000000 90 5c 82 b5 8f e3 82 b0 82 dc 82 b7 |.\..........|
つーわけで2byte目がbackslashなんだけど処理できている?
出来てないならコンパイラがShift_JISを扱えないね。
224:デフォルトの名無しさん
05/07/02 00:30:55
echo "こ"(cp932で"82 B1") | iconv -f cp1250 -t utf-8 | hex
E2 80 9A C2 B1
cp1251でもcp1252でも同じだからそういったヨーロッパ言語を使うようになってんじゃないの。
vcがosの言語の設定を見てないのか、設定方法が間違ってるか...。
225:198
05/07/02 07:25:45
>>222
私の技量ではちょっと遠慮したい感じです。
>>223,224
確かに224さんの"こ"のメモリダンプ結果が私がデバッガで見たものと同じですね。
> vcがosの言語の設定を見てないのか、設定方法が間違ってるか...。
みたいですね。XPのシステムロケール以外に設定する項目を知らないのですが、
いずれにしてもプログラム的には問題なさそうなので（みなさんの環境では動いているようですし）、
設定あたりの線で調べてみたいと思います。ありがとうございました。
226:デフォルトの名無しさん
05/07/02 08:18:33
日本版のVC++が特別版(Shift_JIS対応)ってことはないかな?
wchar_t *p = L"申し上げます";
for (char *q = (char *)p; *q != '\0'; q++) {
printf("%02x ", *q);
}
printf("\n");
するとどうなるの?
227:198
05/07/02 10:35:50
英語版MSVCのソースエディタ内で「申し上げます」とタイプすると変換を確定した時点で
「\し繧ｰます」などと表示されてしまいます。Meadowで編集した上でセーブし（この際には一応
SHIFT_JISでセーブされているように見えます）、コンパイルすると
warning C4129: '�' : unrecognized character escape sequence
というwarningが出ます。warningをコピペしましたが'\202'は画面上では'・'のように見えます。
一応ビルドは終了するので実行するとコンソールには
ffffff90
と表示されました。何かおわかりになりますでしょうか。
228:198
05/07/02 10:38:11
>「\し繧ｰます」などと表示されてしまいます。Meadowで編集した上でセーブし（この際には一応
MSVCのエディタでは「申し上げます」が入力できないので、代わりにMeadowで編集した、という意味です。
229:223=226
05/07/02 12:28:48
>>227
そのコンパイラ/統合環境はShift_JIS対応じゃないです。
「申」の2byte目にあるbackslashを処理できてない。
m18nされてないのでしょう。
一応、L"文字列"を解釈しようとしているようですが。
とりあえずヘルプを読んだ方が良さそう。
実はwchar_t文字列リテラルに対応してないか、UTF-8辺りに固定なのか。
230:デフォルトの名無しさん
05/07/02 22:16:29
VCのコンパイラは日本語版でもShift_JISにL10Nされてるだけで、UTF-8すら使えない。
英語版だとどんなMBCSも使えないんでは。
231:223=226
05/07/03 01:13:29
日本版は過去の経緯という事情でShift_JISオンリーになっていても、
米版はUTF-8利用可能という可能性がないでもないが…さて
232:デフォルトの名無しさん
05/07/03 03:04:22
どのバージョンか忘れたけどutf-8なソースをコンパイルしようとすると
「utf-8には対応してません」的なメッセージを出してたときがあったな。
.NET Framework SDK v2.0のcl.exeを試してみたら
cp932のソースは問題なくコンパイルできた。
utf-8のソースはBOMなしだとcp932として扱うみたい(つまり文字コードの判定はしない)。
BOM付きだとutf-8として認識した。ただし、
char str[] = "こんにちは";
みたいな普通の文字列はcp932に変換された状態でstrに入る。
ワイド文字リテラル(L"こんにちは")は正しく変換された。
233:デフォルトの名無しさん
05/07/03 07:12:37
WindowsはそもそもUTF-8なMBCSはサポートしてないからな
234:デフォルトの名無しさん
05/07/03 09:15:51
cp65001とかあるし脈はあると思うけどね。実際にちょっとだけ機能するし。
sjis依存なコードがたくさんあるから実用できないだろうけど。
235:デフォルトの名無しさん
05/07/04 05:25:45
残念ながらシステムのコードページとしては利用できない。APIの仕様上不可能。
たとえばWM_IME_CHARは1文字が3バイト以上になることをまるっきり考慮してない。
(64ビットWindowsならWin16を捨てたから実装可能かも)
*.nlsは1文字2バイト以下のDBCS←→UCS-2の変換しかサポートできない構造だし。
GB18030も同様にシステムのコードページには設定できない。
236:デフォルトの名無しさん
05/07/04 09:32:17
今のVC++2003のサブセットにあたる VC++ Toolkit 2003はフリーダウンロードだから、
試す価値ある。英語版しかないから、日本でもこれ使ってるよ。
URLﾘﾝｸ(msdn.microsoft.com)
これはUnicodeのソースファイルを解釈できる。
UTF-8 でも UTF-16 でもいい。ただし、BOMがないと判定に失敗して
コンパイルエラーになることが多い。
この場合、C++でやる限り、文字列リテラルやstringは、
実行ファイル内ではUTF-8になっている。
だから、ofstream のファイル出力もUTF-8になる。
cout出力からファイル名・パス名までUTF-8になってしまうので、注意いるが、
リダイレクトでUTF-8を得るには好都合な時もある。
ソースがUTF-16でも結果はUTF-8。ソースがShift_JISなら結果もShiff_JIS。
237:デフォルトの名無しさん
05/07/04 10:18:14
> 実行ファイル内ではUTF-8になっている。
"UTF-8の文字列リテラル"
L"UTF-8の文字列リテラル"
のどっちが?
238:デフォルトの名無しさん
05/07/04 10:54:25
これは標準C++と.NET Frameworkだけがサポートされるバージョンだから、それが前提で
"UTF-8の文字列リテラル"
の方
239:238
05/07/04 12:27:54
簡単なサンプルさらしちゃえば、これをUTF-8(BOM付き)かUTF-16で保存して実行すれば、
UTF-8(BOM付き)のテキストができる、ということで。
標準C++だけの VC++ Toolkit 2003では、文字列に L つけたらエラーになっちゃう。
#include <iostream>
#include <fstream>
#include <string>
using namespace std;
int main() {
char bom[] = {0xEF, 0xBB, 0xBF}; // UTF-8のBOM
string s = "こんにちは。𠹭囉仿謨はnon-BMPテスト";
ofstream out("test.txt");
out.write(bom, 3);
out << s << endl;
}
240:デフォルトの名無しさん
05/07/04 14:14:43
>>238
要するに「何もしてない」って事だと思うが、
BOMがないとどうしてコンパイルエラーになるんだろう…
一応コードポイントの有効範囲くらいは調べているのだろうか。
241:デフォルトの名無しさん
05/07/04 21:29:12
シグニチャが無いと、Shift_JISだとしてリテラル解釈するから
文字列が不完全になってコンパイルエラーになるのよ。
シグニチャありだと一応そこら辺を処理しているように見えるけど、
実はLatinとして扱っているだけという可能性もある。
242:デフォルトの名無しさん
05/07/05 08:44:25
>>241
えーと、では、>>236にあるように英語版しかないけど、
そのコンパイラはソースのエンコーディングをShift_JISとして解釈するって事ですか?
OSのロケールにしたがって、l10n処理しているんでしょうか。
"申"とか大丈夫なのかな? (2byte目がbackslashだけど)
243:デフォルトの名無しさん
05/07/05 09:09:02
BOMがないとシステム設定のコードページを優先して、
Unicodeエンコーディングの判定はBOM付けてくれれば可能だから、
BOMなしのときは、Unicodeだとの判定は絶対確実でないとされないのかな、
とか推測してみたりする。
244:デフォルトの名無しさん
05/07/05 09:21:52
>>243
Windowsはメモ帳なんかもBOM付けるから、その仕様だと自然な感じですね。
245:デフォルトの名無しさん
05/07/05 11:02:30
VisualStudio 2003付属のCL.exeは、シグネチャ付きUTF-8のソースなら
MBCS文字列もワイド指定付き文字列も、ちゃんと処理しているみたいよん。
246:デフォルトの名無しさん
05/07/05 13:08:36
>>239 のサンプルコードは、Cygwin版のgcc や MinGW でも、
BOM無しUTF-8で保存してコンパイルできた。結果は同じ。
こちらは、どうエンコーディング判定してるのかな。
247:デフォルトの名無しさん
05/07/05 13:20:00
gccのmbchar拡張がなければ、{
gccはBOMさえ外してあればスルーでしょ。要するに判定なし。
これはどの環境でも同じ。
}
248:デフォルトの名無しさん
05/07/05 13:37:26
そうでしたか。判定しなくていい仕様なのか。
249:デフォルトの名無しさん
05/07/30 15:58:16
マイクロソフトは「Windows Vista」で日本語フォント環境を一新。
JIS X 0213:2004規格に対応するとともに、
画面上での可読性を大幅に向上させるまったく新しいデザインのフォント（フォント名：メイリオ）
開発を開発中と発表。
URLﾘﾝｸ(www.microsoft.com)
URLﾘﾝｸ(pc.watch.impress.co.jp)
URLﾘﾝｸ(www.itmedia.co.jp)
【社会】"混乱大丈夫？" 次期OSウィンドウズ・ビスタで漢字１５０字形を変更
URLﾘﾝｸ(www.yomiuri.co.jp)
ｽﾚﾘﾝｸ(newsplus板)l50
Windows Vista 日本語フォント環境を一新
ｽﾚﾘﾝｸ(pcnews板)l50
250:デフォルトの名無しさん
05/07/30 16:07:47
>>249
Visa、 XP以前の混在企業システム環境だと、オワットル。
251:デフォルトの名無しさん
05/07/30 16:17:04
＞開発を開発中
＞Visa
252:デフォルトの名無しさん
05/07/30 19:29:27
よろこんでコピペする前に>>122-あたりから嫁
さんざん既出だし前の字体が使えなくなるなんてこともない
253:デフォルトの名無しさん
05/07/30 20:37:53
MACが無視されているのはなぜ？
254:デフォルトの名無しさん
05/07/31 00:40:20
>>253
合成対応やcomplex script対応やJIS X 0213対応や字形の沢山入ったフォント
やらOSXでは何年も前に実装済みなのであまり話題がありません。
255:デフォルトの名無しさん
05/08/01 23:10:12
Vista beta1を調べてみた結果
・Meiryoは>>125とか>>139な感じ
・新ＭＳ ゴシック/ＭＳ 明朝はグリフ自体が入れ替えられてて
OpenType Featureはccmpとvertしかない
(ほぼ一太郎の2004JISフォントと同等)
・Uniscribeに
ScriptGetFontAlternateGlyphs
ScriptGetFontFeatureTags
ScriptGetFontLanguageTags
ScriptGetFontScriptTags
ScriptItemizeOpenType
ScriptPlaceOpenType
ScriptPositionSingleGlyph
ScriptShapeOpenType
ScriptSubstituteSingleGlyph
みたいなAPIが追加されていて、Win32からでも字形は制御できるらしい
256:デフォルトの名無しさん
05/08/02 20:49:48
Vistaのメモ帳で「葛飾区」と打って、フォントをMeiryoに切り替えるだけで
文字化けするわけだがいいのかこれで?
257:デフォルトの名無しさん
05/08/03 00:28:25
>>256
同じ文字コードに、フォントによって違う字形が割り当てられているのはいやだ。
特に、住所管理とか人名管理とかそういうシステムではどうすんだ。
葛飾区役所のシステム担当とか終わりそうだ。
258:デフォルトの名無しさん
05/08/03 00:58:34
葛飾区の役人は今やってる方法のまま暮らしていれば問題ない。
259:デフォルトの名無しさん
05/08/03 01:07:11
>>258
中途半端にえらい役所のやつが、VistaのＰＣを勝手に導入して
「こらー、これで俺のところの区の字がでねーぞ、なんとかしろー」
とかいいそうだ。
260:デフォルトの名無しさん
05/08/03 01:35:07
>同じ文字コードに、フォントによって違う字形が割り当てられている
それは当たり前なのでは?
261:デフォルトの名無しさん
05/08/03 01:41:31
717：login:Penguin：2005/07/30(土) 10:41:03 ID:Hd+4jW+B
>>716
CP932の定義が変わって、
CP932とUnicodeのマッピングが変わるわけでしょ?
とりあえず>>711のPDFくらい読めよ。
URLﾘﾝｸ(internet.watch.impress.co.jp)
でも概略は理解できるよ。
JIS X 0208の1978, 1983, 1997が同じ文字集合を規定している
というセンスだと理解不可能。
262:デフォルトの名無しさん
05/08/03 04:38:15
> 特に、住所管理とか人名管理とかそういうシステムではどうすんだ。
そんなシステムでフォントすら規定してないほうがどうかと思うが…
263:デフォルトの名無しさん
05/08/03 04:48:06
>>261
リンク元くらい書いてほしいなあ。login:Penguinで分かったけど
ｽﾚﾘﾝｸ(linux板:717番)
> CP932とUnicodeのマッピングが変わるわけでしょ?
変わんねーよ(Shift_JISではJIS X 0213の2面の漢字とか使えない)
PDFのどこを読んだらそういう結論に到達するのやら
つーか「考え方」の5-(7)ってどれだよ
264:デフォルトの名無しさん
05/08/03 04:54:08
>>259
逆だろ? 葛飾区は今まで出せなかった字がVistaでは出るようになる。
困るのは葛城市。しかもJIS字体にした理由が「PCで出しやすいように」。
合併したのは2004年。もうアホかと。
265:デフォルトの名無しさん
05/08/03 05:16:53
文字集合が違うんだから同じコードで字形が違っても全然不思議じゃない。
REVERSE SOLIDUSに円記号が割り当たってる方がよほど奇妙なんだけど
>>257はそっちは問題にせんの?
266:デフォルトの名無しさん
05/08/03 05:27:43
MeiryoのU+005CはちゃんとREVERSE SOLIDUSの字形になってるけど
システムの言語を日本語にするとU+005Cでわざわざ円記号が表示されるように
何か特別な細工をしてる模様。
円記号以外の英数字はClearTypeが掛かってるのでMS UI Gothicじゃないのは確実。
そこまでやりますか
267:デフォルトの名無しさん
05/08/03 05:31:13
なぜか文字集合の違いにしたがってる奴がいるようだが
同じJIS X 0208:1997やJIS X 0213:2004で字形が違ってたってぜんぜん不思議
じゃないのだが。喪前らこそ規格票読んでるのか?
参考:
URLﾘﾝｸ(toyohira.asablo.jp)
268:256
05/08/03 05:55:02
いちおう漏れの疑問の意図を説明しとくと、
規格に適合してるか否かを聞きたかったんじゃなくて(適合するのは分かってる)
新ＭＳ ゴシックとMeiryoはどちらも同じシステム上に標準で存在する
2004JIS対応を主張するフォントなのに、切り替えただけで文字化けが発生する
仕様なわけだが(規格上はもちろん問題ないが)、
MicrosoftはVistaに標準で存在する日本語フォントだけでもなんとかする気は
なかったのか? ってことなんだが。
文字化けが発生する「仕様」であることを世間に思い知らせるためあえてこう
したのかもしれんが、互換性を無視してそこまでdrasticな考えができるなら
IEはとっくの昔にCSS完全準拠になってるはずだし。
269:デフォルトの名無しさん
05/08/03 06:59:16
>>268
まだVistaがβだからであって、正式版までには解消されている、って期待はないの？
270:デフォルトの名無しさん
05/08/03 07:04:13
>>269
マジでそう期待したい。
ちなみに正式版ではどう解消されてる(する余地がある)と思う?
271:デフォルトの名無しさん
05/08/03 10:21:48
表外漢字字体表の字体に変更すると、
JIS X 0213と矛盾が生じる文字についてはどうなっているの?
272:デフォルトの名無しさん
05/08/03 11:39:59
>>271
その28文字については、表外漢字字体表の字体変更しないんじゃない?
当たり前だけど。
URLﾘﾝｸ(www.yomiuri.co.jp)
にもある168文字の内訳ってどこかに書いてある?
273:デフォルトの名無しさん
05/08/03 12:25:41
補助漢字を無視したいところだけど、
補助漢字はUnicodeに入っているしねー。
274:デフォルトの名無しさん
05/08/03 16:34:57
>>263
> つーか「考え方」の5-(7)ってどれだよ
URLﾘﾝｸ(www.jsa.or.jp)
じゃないかな。(読んだことがある人ならすぐピンと来るはず)
URLﾘﾝｸ(internet.watch.impress.co.jp)
URLﾘﾝｸ(internet.watch.impress.co.jp)
に、その要約があるけど、(調査報告には例示字体の表もある)
その9つのケースについて、現状のVista&Meiryoでどうなっているか、
誰かまとめてくれる人いませんかね? (僕は残念ながら持ってないです…)
275:デフォルトの名無しさん
05/08/03 17:13:03
>>274
＞現状のVista&Meiryo
要はOpenTypeの'jp04'グリフってことじゃねえの？
そうであれば、基本はJIS04が変更したとおり。
ただし「微細な字形差」に関しては無視しているものもある。
276:デフォルトの名無しさん
05/08/03 21:57:21
>>272
> 168文字の内訳
JIS X 0213:2004に関する経済産業省の報道発表
URLﾘﾝｸ(www.jisc.go.jp)
277:デフォルトの名無しさん
05/08/04 03:36:56
>>275
なんとMeiryoには'jp04' featureがない('nlck'はある)。AJ1-5相当だから
当然かもしれんが。
正式版までにサポートされるのかサードパーティー製のAJ1-6フォントを
インストールしたときに備えてAPIの口のみ用意してるのかは知らん
278:デフォルトの名無しさん
05/08/04 03:41:12
>>271
別区点に追加されたほうの面区点を使えってこと
279:デフォルトの名無しさん
05/08/04 03:47:56
> じゃないかな。(読んだことがある人ならすぐピンと来るはず)
5-(7)って数字の根拠が分からない。そんな章番号とかはないみたいだし
> その9つのケースについて、現状のVista&Meiryoでどうなっているか、
Meiryoは単なるAJ1-5相当のOpenTypeフォント(要するにデフォルト字形は90JIS)。
だから>>256のような「文字化け」が起きる
280:デフォルトの名無しさん
05/08/04 04:12:15
> 5-(7)
ようやく分かった。2.1.5 (7)のUCS互換漢字10文字のことか。
当然2004JIS・ISO/IEC 10646:2003がやったとおりのことをやって対応
(字形変更ではなく対応するUCS符号位置のグリフを追加実装)。ヒラギノなんかと一緒。
281:デフォルトの名無しさん
05/08/04 04:28:20
Shift_JISのtext/plainやtext/htmlはどう扱うの? > Vista
(CSVなど全般的に)
>>280でいうと、追加した文字の方になったわけ?
282:デフォルトの名無しさん
05/08/04 04:42:51
>>281
CP932のマッピングに一切変更はない。
UCSのレパートリとしてしかサポートしないとずっと言い続けてた通り
283:デフォルトの名無しさん
05/08/04 04:46:28
もちろん「葛」みたいに字形が変わった字は結果的にShift_JISでも変わるけど、
それはたまたまで印刷標準字体をShift_JISで完全にサポートする気ははじめから
ないということ。
284:デフォルトの名無しさん
05/08/04 23:33:35
メーラーを作っているのですが、受信したメールが正しく表示されません。
JIS→Shift_JISの変換を勉強のためにも自力で変換したいのですが、
どう変換していいのか分かりません。
JISの文字コードをShift_JISに変換するときのアルゴリズムのヒントを教えていただけませんでしょうか。
1byteずつ読み込んでいって変換していかなきゃいけないというところまでは分かります。
285:デフォルトの名無しさん
05/08/04 23:47:59
勉強のために自力で変換したいという人が
検索もせずに質問するとはこれいかに
286:デフォルトの名無しさん
05/08/04 23:50:32
そのくらい調べられない奴には絶対にメーラーなんぞ作って欲しくは無い罠。
287:デフォルトの名無しさん
05/08/04 23:52:21
>>284
マジでやめてくれ。
288:デフォルトの名無しさん
05/08/04 23:55:26
言語は何よ?
>>8でどうなのよ。
perlならEncode.pmな。
289:デフォルトの名無しさん
05/08/04 23:58:24
Shift_JISのままBase64でエンコードしたほうが被害は少なそうだ。
290:デフォルトの名無しさん
05/08/05 00:06:50
iso-2022-jpと書けない時点で終どうしようもない。
291:284
05/08/05 00:31:17
＞勉強のために自力で変換したいという人が
＞検索もせずに質問するとはこれいかに
ここ一週間調べたのですが、今ひとつ理解できるものが見つからないんです。
かなり運が悪いようです。
＞そのくらい調べられない奴には絶対にメーラーなんぞ作って欲しくは無い罠。
メーラーが初めてなだけでネットワーク関係のプログラミング経験は豊富です。
バイトですが十数件のCGIも手がけました。
フリーで配布しているものもあり、結構多くの方に利用していただいています。
CGIはPerlで組んでいて、jcode.plを使っていました。
今回はC++で作っています。
292:デフォルトの名無しさん
05/08/05 00:34:11
とりあえず
つ libiconv
293:デフォルトの名無しさん
05/08/05 00:35:00
……てゆーか、jcode.pl読めばわかるんジャマイカ?
294:デフォルトの名無しさん
05/08/05 00:35:17
CGIってネットワークプログラミングに含まれていたのか。
この板の「ネットワークプログラミング」スレでCGIなんて書き込んだら
鼻で笑われるだけだけどな。
295:デフォルトの名無しさん
05/08/05 00:42:33
>>284
バベルじゃダメ？
296:デフォルトの名無しさん
05/08/05 00:57:11
> フリーで配布しているものもあり、結構多くの方に利用していただいています。
フリーCGIで日本語(もちろん文字コードでんでんで)の扱いがクソレベルな物ばかり掴まされている漏れなので、
よろしければお前のCGIの配布サイトを教えてくだちい。
297:デフォルトの名無しさん
05/08/05 01:12:38
> かなり運が悪いようです。
悪いのは運ではなくて頭
298:デフォルトの名無しさん
05/08/05 01:44:02
>>284
inがJIS文字列で処理結果がshiftjis文字列のはず。バグあるはず。
そもそもcharがunsignedではない環境ではあぼーんする恐れあり。
std::string jis2sjis(const std::string& in) {
bool is_ascii = true;
std::string::const_iterator begin = in.begin(), end = in.end();
std::string out;
while (begin != end) {
if (*begin == 0x1B) {
if (*(begin + 1) == 0x24 && *(begin + 2) == 0x42) is_ascii = false;
else if (*(begin + 1) == 0x28 && *(begin + 2) == 0x42) is_ascii = true;
begin += 3;
continue;
}
if (is_ascii) out.push_back(char(*begin));
else {
unsigned char hib = unsigned char(*begin), lob = unsigned char(*++begin);
lob += (hib & 1) ? 0x1f : 0x7d;
if (lob >= 0x7f) ++lob;
hib = unsigned char(((hib - 0x21) >> 1) + 0x81);
if (hib > 0x9f) hib += 0x40;
out.push_back(char(hib));
out.push_back(char(lob));
}
++begin;
}
return out;
}
299:デフォルトの名無しさん
05/08/05 01:47:50
馬鹿は出てくるなよ…
300:デフォルトの名無しさん
05/08/05 01:49:28
>>291
完全に経験不足(ﾜﾗ
301:デフォルトの名無しさん
05/08/05 01:54:45
CJKV日中韓越情報処理
URLﾘﾝｸ(www.amazon.co.jp)
Unicode標準入門
URLﾘﾝｸ(www.amazon.co.jp)
国際化と日本語処理
URLﾘﾝｸ(www.amazon.co.jp)
最後はJavaだけど、Unicode経由する場合のマッピング問題の理解にはよいでしょう。
302:デフォルトの名無しさん
05/08/05 06:36:52
Vista beta1の文字コード表がExtBに未対応なのを見ると確かにかなり暫定的なもの
である可能性は高そうだ
XPからそのまま移植しただけみたいな
303:デフォルトの名無しさん
05/08/10 18:42:06
>>284
もし環境が Windows ならば、
MultiByteToWideChar -> WideCharToMultiByte と呼び出す。
IE5以上が入っていれば、
IMultiLanguage2 を取得して、ConvertString メソッドを呼び出す。
Windows 以外なら、
iconv とか、ICU とか、バベルとかその辺を使う。
304:デフォルトの名無しさん
05/08/10 18:52:06
> 勉強のためにも自力で変換したい
305:デフォルトの名無しさん
05/08/11 03:13:50
MultiByteToWideChar がISO-2022-JPを変換できるのはWin2k以降で
IE5より条件厳しいし。
306:デフォルトの名無しさん
05/08/13 04:25:56
文字コード支離滅裂なのって日本だけなの？
307:デフォルトの名無しさん
05/08/13 07:06:58
日本の文字コード体系を真似た中台韓も同様の状況じゃなかったっけ？
308:デフォルトの名無しさん
05/08/13 07:45:36
ベトナムも。
それからEU内はISO-8859-*で扱おうとするとやっかい。
隣国間のやりとりで結構問題になった。
島国日本に比べるとずっと近くて交流が多いから。
309:デフォルトの名無しさん
05/08/15 14:04:21
まあ日本語は他の2byte圏より多少歴史がある分、面倒なしがらみも多いわけだが
310:デフォルトの名無しさん
05/08/15 15:07:27
>>309
他の2byte文字を知っての言葉か？
311:デフォルトの名無しさん
05/08/15 15:36:10
>>310
他の2byte文字とやらの説明よろ
中国は国家権力でGB18030を強制できるので楽と言えば楽だよね。
312:デフォルトの名無しさん
05/08/15 16:34:39
>>311
質問を質問で返すなよ
313:デフォルトの名無しさん
05/08/15 18:18:36
>>312
311!=310なんで別に返してるわけじゃないよ。説明よろ。
314:デフォルトの名無しさん
05/08/15 23:46:02
何が聞きたいんだ
315:デフォルトの名無しさん
05/08/15 23:48:45
他の2byte文字圏が日本語に負けず劣らず面倒であることの証明だろ
316:デフォルトの名無しさん
05/08/16 00:38:40
他の2byte文字って何？
317:デフォルトの名無しさん
05/08/16 00:52:27
だからそれを説明しろといってるんだろ
318:デフォルトの名無しさん
05/08/16 00:55:44
スネークマンショーのつもりかよ
319:デフォルトの名無しさん
05/08/16 01:36:30
だ～れ～？
320:デフォルトの名無しさん
05/08/16 03:14:03
CJKVだろ
URLﾘﾝｸ(www.amazon.co.jp)
でも読め
321:デフォルトの名無しさん
05/08/18 09:58:24
ここでいいのかなぁ…Windowsで文字コードの判定に
IMultiLanguage2::DetectInputCodepageを使ってみました。Googleのページ
(UTF-8)すらまともに判定できていませんが、精度はこんなものでしょうか？
322:デフォルトの名無しさん
05/08/18 10:01:59
質問なので上げときます。
323:デフォルトの名無しさん
05/08/18 11:35:39
試さずに言うけど、googleのトップページなんて
文字量が少ないんだから判定しにくいのも当然なのでは？
324:デフォルトの名無しさん
05/08/18 12:51:53
文字コードの範囲限定してないし…
325:321
05/08/18 14:28:28
トルコ語(Windows)と判定されました。
>>324
指定方法ってあるんでしょうか？
326:デフォルトの名無しさん
05/08/18 14:49:00
せっかくメタタグあるんだから、MLDETECTCP_HTML指定してやれば
まともに判断してくれまいか。
つうか、Win32Apiスレの話だよな、こんなの。
327:デフォルトの名無しさん
05/08/18 17:13:11
どうするよ「表」
文字コードが何種できてもいいけどさ
5c入るコードに文字振るのやめない？
どんどん増えてく
328:デフォルトの名無しさん
05/08/18 18:19:13
>>326
読み込むのがHTMLとは限らないんですよ。次のページのコードも
参考にしましたが…
DOBON.NET .NET Tips - 文字コードを判別する
URLﾘﾝｸ(dobon.net)
329:デフォルトの名無しさん
05/08/18 18:29:38
あきらめの悪い奴だな
330:>>321
05/08/18 18:32:19
>>329
>>328のサイトので我慢します。
331:デフォルトの名無しさん
05/08/18 18:42:33
>>330
C++でもいいんならバベルはどうだ？
サンプリングしたデータを下にスコアリングを行うからかなりの精度で判別するぞ。
332:321
05/08/18 18:56:46
>>331
ありがとうございます、Babelの存在を忘れていました。一応C♯とC++を
考えているので、考慮に入れたいと思います。
333:デフォルトの名無しさん
05/08/20 00:41:24
>>327
意味不明
334:デフォルトの名無しさん
05/08/20 02:53:04
>>333
もちろん意味わかっててそう言ってるんだよな。
335:デフォルトの名無しさん
05/08/20 08:31:29
0x22, 0x27, 0x2Fとかきりがないけどな。
いまやUTF-8の時代だし。
336:デフォルトの名無しさん
05/08/20 13:34:04 BE:39938742-
>>328
このページの判定ルーチンは、一バイト目に0のあるバイナリファイルを食わせると、
配列の外にアクセスして例外が起きそうな気が。
337:デフォルトの名無しさん
05/08/20 14:48:40
まあ.NETならそれを足がかりにバッファオーバーフロー起こして攻略とかできないから
338:デフォルトの名無しさん
05/08/20 14:52:07
>>335
だいたいそれならISO-2022-JPを真っ先に滅ぼさなきゃならない
(実際日本語を想定してないメールゲートウェイでトラブルの元になってる)
ことには気付いてるんだろうかね
339:デフォルトの名無しさん
05/08/20 23:16:21
>>338
> (実際日本語を想定してないメールゲートウェイでトラブルの元になってる)
( ﾟдﾟ)
(つд⊂)ｺﾞｼｺﾞｼ
(；ﾟдﾟ)
(つд⊂)ｺﾞｼｺﾞｼ
_, ._
（；ﾟ Дﾟ）
340:デフォルトの名無しさん
05/08/21 02:55:12
ESCを捨てるゲートウェイの話とか聞いたことない?
341:デフォルトの名無しさん
05/08/21 06:57:30
ISO-2022-JP の問題なら今は ESC よりも瘢雹だろう。
342:デフォルトの名無しさん
05/08/21 10:38:35
amp;(瘢雹)は挟まるだけだからまだマシ
<→<や>→>はその後が全部化ける
343:デフォルトの名無しさん
05/08/21 17:22:03
utf-8の日本語
すでに複数存在するって本当？
344:デフォルトの名無しさん
05/08/22 00:42:02
>>338
いつの話だよ。
MIMEエンコードもしてないメールなの?
Structual fieldなら問題外だし。
345:デフォルトの名無しさん
05/08/22 04:15:44
瘢雹でぐぐればそういうメールアーカイブがバリバリ現役なのは分かると思いますが。
いくら綺麗事を並べたところでascii圏の認識なんてそんなもん。
346:デフォルトの名無しさん
05/08/22 19:39:20
メールアーカイブなんぞメールのトラブルとは何の関係もないやんけ
347:デフォルトの名無しさん
05/08/22 22:19:43
>>343
MicrosoftとAppleとLinux(つーかglibc?)とJavaとJISで全部ちょこっとづつ違うんじゃなかったっけ。
「～」等の記号のコードポイントが違ったり正規化表現が違ったり。(正規化はUnicodeの範疇だけど)
348:デフォルトの名無しさん
05/08/23 05:22:31
>>346
メールのトラブルじゃなきゃ何が起きてもいいわけじゃないし
349:デフォルトの名無しさん
05/08/23 07:05:13
>>347
それはUTF-8ではなくShift_JISの方
そして違うのはコードポイントというかUCSへのマッピング
350:デフォルトの名無しさん
05/08/24 02:10:00
>>349
でも全部UTF-8で処理するCGI作ってWinとMacからそれぞれ「スケジュール2005年4月～9月」などと入力してPOSTしたら、「～」が異なるコードポイントでやってきますですよ?
351:デフォルトの名無しさん
05/08/24 02:17:29
そもそもWinとMacでは同じに見えても違う波線だから当然と言えば当然。
352:デフォルトの名無しさん
05/08/24 06:44:13
>>350
だからUTF-8の方は一種類なんだって。
1. あるUTF-8にはＸＸＸという文字があるけど違うUTF-8にはない、みたいなことはない。
2. あるUTF-8のYYYというコードポイントの文字はZZZだけど違うUTF-8では別の文字、みたいなこともない。
でもShift_JISでは、1. も2. も現実に起こってるの。
で、そのいろいろ微妙に違うShift_JIS達をユニコードに変換するときに、それぞれがいろいろ微妙に違う変換テーブルを使ってるのが原因。
UTF-8側の問題じゃないの。OK?
353:デフォルトの名無しさん
05/08/24 07:54:01
原規格との変換テーブルを規定しないUnicode側の問題だろ。
354:デフォルトの名無しさん
05/08/24 08:26:17
むかしは規定してたけどな。
きっと管理しきれなくなってやめたんだろうなぁ……。
ちゃんとやろうとするなら、SJISだけでいくつの方言を面倒みないといけないやら。
355:デフォルトの名無しさん
05/08/24 08:32:03
> でも全部UTF-8で処理するCGI作って
356:デフォルトの名無しさん
05/08/24 08:39:26
ていうかユニコード側が規定してもベンダが従うとは限らないし、
ベンダはマッピングを変更したり増やしたりもするだろうし、
ユニコード側にそれの管理をさせるのは無茶だろ。
混乱の元だってのは確かにその通りかもしれないけど、他にどうしろと？
357:デフォルトの名無しさん
05/08/24 08:52:17
よしUTF-128ぐらいで手を打とうじゃないか
言語問わず、今現在使われてる部分は意地でも文字振りません
358:デフォルトの名無しさん
05/08/24 16:22:59
Unicodeがマッピング・テーブルを公開していた頃も
ベンダはそれに従ってなかったし。
359:デフォルトの名無しさん
05/08/24 18:55:15
>>357
UTF-8でも、36bitコードまでリニアな拡張で扱えるが。
360:デフォルトの名無しさん
05/08/24 19:11:20
それはUTF-8ではない。
361:デフォルトの名無しさん
05/08/24 19:31:36
＞36bitコード
( ´д)ﾋｿ(´д｀)ﾋｿ(д｀ )
362:デフォルトの名無しさん
05/08/24 20:05:55
>>360
だから、「UTF-8の *リニアな拡張* 」だって言ってんだろ？
先頭バイトの上位ビットに7個1が並んでいたら、↓ 36bitになるだろうが。
11111110 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
363:デフォルトの名無しさん
05/08/24 21:23:35
UTF-8 符号化では 0xfe と 0xff のバイトは絶対に使用しない。
364:デフォルトの名無しさん
05/08/24 21:35:56
拡張って言葉の意味が分からないの?
365:デフォルトの名無しさん
05/08/24 21:36:49
ちなみに0xfeと0xffを使わない理由はUTF-16のBOMが100%判別できるようにするためだな
366:347=350
05/08/24 22:50:04
>>351 >>352
ええと、理屈はわかるんですが、現実として、WinとMacとLinuxの混在環境
で全部UTF-8に統一しても、人間から見たら「同じ」と認識されるはずの
ものが異なるバイトパターンを構成するために、システム的には「同じ」
にならないと言う問題があって、これを解決するためには、どこかで
UTF-8 to UTF-8変換をする必要があるのではないでしょうか。
この状況を称して「UTF-8の日本語はすでに複数存在する」と言っても
過言ではない、と思うんですけれども。
367:デフォルトの名無しさん
05/08/24 22:59:33
> UTF-8 to UTF-8
お前が言わんとすることに似たようなことは既に存在する。
URLﾘﾝｸ(www.google.co.jp)
368:デフォルトの名無しさん
05/08/24 23:02:00
>>366
UTF-8は文字エンコードの規格。
見た目は同じで違う文字、というのは文字セットの問題。
だから、UTF-8云々の議論はかみ合わない。
それに、バイトパターンが一致しないのは、BOM有無とか改行の問題じゃないの？
あるいは、UTF-8なら本来2バイトで表せる文字を3バイトで記録するような誤った実装の
アプリを使っているとか、サロゲートペアをそのまま2文字で扱うエラーとか…
369:366
05/08/25 00:49:19
>>367
ぅぃ。問題自体が今さらなのは承知しております。
が、その対策が、この関数／メソッドを呼べばOK!にはなってなくて、
未だにアプリケーション毎の個別対応に依存しているようにしか
見えないのはどうしたものかと。
Javaの世界ですら、10年前から既知の問題なのにどこにも(ベンダ依存
マッピング問題を含む)統一されたフレームワークが見あたりません……。
私が知らないだけだったら、是非教えてください。