文字コード総合スレ part2

プログラムにおける各種文字コードの処理について語りましょう♪

■前スレ
文字コード統一スレ 1文字目
http://pc8.2ch.net/test/read.cgi/tech/1109171258/

■関連スレ
文字コードの種類は何故複数あるのでしょうか？
http://pc8.2ch.net/test/read.cgi/tech/1093251312/l50

■参考サイト
Unicode Home Page
http://www.unicode.org/
Java Character Encodings
http://www.ingrid.org/java/i18n/encoding/
euc.JP: tech docs, BeOS tools
http://euc.jp/
ISO-IR - 2.8.1 Coding systems with Standard return
http://www.itscj.ipsj.or.jp/ISO-IR/2-8-1.htm
ISO-IR - 2.8.2 Coding Systems without Standard return
http://www.itscj.ipsj.or.jp/ISO-IR/2-8-2.htm

とりあえず>1乙と言っておくよ☆

ここまで読んだ！

■ライブラリ
IBM Globalization - ICU
http://www-306.ibm.com/software/globalization/icu/
NKF32.DLL
http://www.vector.co.jp/soft/win95/util/se020949.html
http://www1.ttcn.ne.jp/~kaneto/dll/nkf32dll.html

>>4
バベルも入れてくれよぅ。
http://tricklib.com/cxx/ex/babel/

IANA: Character Sets
http://www.iana.org/assignments/character-sets

UTF-16 で表現可能な符号化文字集合（UCS-4 の部分集合）って
何か特別な呼び方ありましたっけ？

Unicode では「Unicode scalar values」と呼んでいるようだけど、
わかりにくい用語だね。

Legacy Encoding Project
http://sourceforge.jp/projects/legacy-encoding/

>>9
[LE-talk-ja 15] で、森山氏がUTF-8で一度送ったあとISO-2022-JPで送りなおしているのが受けたｗ

さておき、風間氏はCESとCSSとcodesetの区別がいまいちついてない悪寒がするのは私だけか？

森山: 機種依存文字をEUCで扱うのはやめれ。でも一般的じゃない（みんな扱ってる）。
風間: 世界的には一般的
とか意味不明な返答もあるし。

これだからUCS厨はとか言うCSI厨は無しの方向で。

だれかCP50220の定義を教えてくれ。

http://webdav-jp.ml.nemui.org/msg00820.html
の参照先の
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/unicode_81rn.asp
を見ても「ISO 2022 Japanese with no halfwidth Katakana」と
（多分嘘が）書いてあるだけで、さっぱり判らん。

>>11
たぶん、「Microsoft による ISO-2022-JP の実装（の一つ）」 という以上の定義
（Unicodeとの変換表とか標準字体とか）は無いんじゃないかと思う。

CP50220 は Unicode からマルチバイト文字への変換で
いわゆる半角カタカナを全角カタカナに置き換える。
濁点の扱いが WideCharToMultiByte と ConvertINetUnicodeToMultiByte で違ったりする。
マルチバイト文字 から Unicode への変換のときは 50220 50221 50222 全部同じだと思った。

UnicodeをCP50220に変換する場合、
U+005C REVERSE SOLIDUS
U+00A5 YEN SIGN
あたりはどういう扱いになるの？

森山さんの説明
http://lists.sourceforge.jp/mailman/archives/legacy-encoding-talk-ja/2006-March/000002.html

■ CP50220

o Windows Codepage 50220
o Outlook Express, Internet Explorer での ISO-2022-JP
o JIS X 0201 片仮名を JIS X 0208 の片仮名に置換

使用するエスケープシーケンス

文字セット esc seq. 1バイト目 2バイト目
--------------------- --------- ------------------- --------- ------
US-ASCII ESC ( B 0x00-0x7F -- in/out
JIS X 0201 ラテン文字 ESC ( J 0x00-0x7F -- in
JIS X 0201 片仮名 ESC ( I 0x21-0x5F -- in
SO/SI 0x21-0x5F -- in
ESC ( B 0xA1-0xDF -- in
ESC ( J 0xA1-0xDF -- in
JIS X 0208:1978 ESC @ B 0x21-0x28,0x30-0x74 0x21-0x7E in
JIS X 0208:1997 ESC $ B 0x21-0x28,0x30-0x74 0x21-0x7E in/out
NEC特殊文字 ESC $ B 0x2D 0x21-0x7E in/out
NEC選定IBM拡張文字 ESC $ B 0x79-0x7C 0x21-0x7E in/out
ユーザ定義文字 ESC $ B 0x7F-0x92 0x21-0x7E in/out

※in = CP50220 から Unicode への変換
out= Unicode から CP50220 への変換

CP50221 や CP50222 についてもリンクにあります。

>>14
その説明を文字通りに理解すると、

Unicode -> CP50220
--------------------------------
U+005C REVERSE SOLIDUS -> 0x5C
U+00A5 YEN SIGN -> NA

のようになると思うんだけど、実際にそうなの？

>>15
Microsoft (R) Windows (R) 2005 Framework version 2.0.50727 の
System.Text.Encoding.GetEncoding(50220).GetBytes() で試したら、
Unicode -> CP50220
--------------------------------
U+005C REVERSE SOLIDUS -> 0x5C
U+00A5 YEN SIGN -> 0x5C
でした。
内部的には Unicode -> CP932 -> CP5022ｘ って変換な気もするね。
U+00A9 Copyright Sign ->0x63
とかもあったし。

ついでに、U+0000からU+FFFFまでをCP50220に変換してみた結果
http://www.vipper.net/vip27804.zip.html

>>16
多謝。どろどろですね。

>>14
> JIS X 0208:1978 ESC @ B 0x21-0x28,0x30-0x74 0x21-0x7E in
「ESC @ B」 って 「ESC $ @」 の typo なんじゃない？

俺が知らんだけで 「ESC @ B」 ってのがあるのかも知らんけど。

人名をソートかけたら期待する並びになる？

>>19 何を期待しているかにもよる。
少なくともバストサイズ順には並ばない。

じゃあ、意味ないじゃん！

人物クラスでも作ってバスト比較用関数を作らないとナ

ていうかね、俺はね、日本の文化を大切にするという意味で
文字コード以前に、言葉を重視すべきだと思うのよね。

つまりね、「バストサイズ」なんていう横文字は使うべきじゃないの。
「ちちのデカさ」って書いたほうが、意味がわかりやすいと思わない？

>>23
つ[胸の豊かさ]

s/胸/乳房/

貧乳順

>>23
そこまで言うなら、明治の文人に倣って新しい言葉を作るべきだ。
「乳厚」とか。

ちちあつヨーグルト

お前ら乳関数も知らんのか。

Nu function
http://mathworld.wolfram.com/NuFunction.html

see also .....
Mu function
http://mathworld.wolfram.com/MuFunction.html
Lamdba function
http://mathworld.wolfram.com/LambdaFunction.html

おっぱいが大きければソニーへ入社できてた時代は終わった
これからの時代は大きさより飛距離。

らめえええええええぇぇえぇぇぇぇぇ

C における wchar_t は、その表現系は特に定められていませんよね？
wchar_t が UTF-16 であっても UTF-32 であっても構わないわけです。

では Windows における WCHAR の表現系は定められているのでしょうか？
ちなみに typedef wchar_t WCHAR となっているようです。

UTF-16です

>>34 ありがとうございます。
Windows における WCHAR が UTF-16 であり、かつ
typedef wchar_t WCHAR されていると言うことは、
Visual C++ のランタイムライブラリにおける
ワイド文字 wchar_t も UTF-16 であるということですね。

C もしくは C++ の規格としては UTF-16 で統一
されていようが UTF-32 で統一されていようが
固定長であれば構わない、ということだったと
思うのですが、正しいでしょうか？

utf-16の文字列はwide character stringじゃなくて、
multi byte stringだけどな。サロゲートペアがあるから。

wcharならucs-2って言うべきだな。

しかし、WindowsのWCHARはUTF-16を使っているんだな。
C/C++の規格は共にwchar_tを固定長だと期待しているようだが。

GCCのwchar_tは32ビットでUCS-4らしいぞ。

>>36 なるほど、そういやサロゲートペアなんてものがありましたね。
Windows の WCHAR は UTF-16
Visual C++ の wchar_t は UCS-2
gcc の wchar_t は UTF-32 (UCS-4)

で、なぜか typedef wchar_t WCHAR ってことでしょうか。
ちなみに Java の JNI では typedef unsigned short jchar です。

Javaは仕様で各プリミティブ型のバイト長が完全に決まってるから。
C処理系の実装によってヘッダ定義変えるんじゃね？

>>38
wchar_tの内容を決めるのはライブラリであってコンパイラではない。

sizeof (L'A')
を決めるのはコンパイラ

L'A' の値を決めるのもコンパイラだね。

>>43 じゃ、wchar_t の表現形はコンパイラ依存じゃん。
って、char だってそうか。

>>42 >>43
ライブラリがまずwchar_tの中身を決めて、それに従うようコンパイラ
をビルドするの。

実際、gccでも
・UCS-4のwchar_tのプラットフォーム (glibc向けなど)
・そうでない32bitのwhcar_tのプラットフォーム
・16bitのwchar_tのプラットフォーム (MinGWなど)
がある。

なるほど

VC++とか使ってると「コンパイラをビルドする」
ってのは頭にないからなぁ。「コンパイラが決めてる」
ってなっちゃうな。

>>42
sizeof マンドクセに見えた

>>44
charは1バイトなんじゃないか？

厳密には「wchar_t も char もその時々で解釈が変わる」じゃないのか？
そりゃWin32APIや標準関数も含め各種ライブラリは、それぞれが想定した文字コードが前提だろうけど。

>>49
charは、integral typeであることと、
sizeof(char) == 1(つまり< sizeof(T))って事以外はライブラリの範疇だろ?

要するに、１バイトの表現形に環境依存性があるということやね？

>>51 sizeof char >=1 じゃなかったっけ？必定条件は

必要条件の間違いだった。
っていうか、その言葉も辺か。
使用上の要件ってことで。

【ISO/IEC 14882:1998】
《1.7 The C++ memory model -1》
The fundamental storage unit in the C++ memory model is the byte. A byte is at least
large enough to contain any member of the basic execution character set and is
composed of a contiguous sequence of bits, the number of which is implementation-defined.
(後略)
《5.3.3 Sizeof -1》
The sizeof operator yields the number of bytes in the object representation of its operand.
(中略)
sizeof(char), sizeof(signed char) and sizeof(unsigned char) are 1;
(中略)
[Note: in particular, sizeof(bool) and sizeof(wchar_t) are implementation-defined.69)]
[Note: See 1.7 for the definition of byte (後略)]

以上より、バイトはビット列、１バイトのビット数は実装定義、sizeofはバイト換算のサイズ、
sizeof(char)==1、sizeof(wchar_t)は実装定義。

そもそも43は型の大きさのことではなく、どんな文字コードを使うかという話だと思うのだが。

>>49
1バイトが8ビットとは限らない。

charが8bitとは限らなくても
sizeof(char)は常に1

>>58 そうだったのか。
でもそうすると sizeof でメモリ使用量を
見積もることができなくなるなぁ。

>>59
charは9ビットでもsizeof(int)が4ならばchar * 4に格納できると言うことなのだから問題ない。
つまり、仮令32ビットのintでもcharでアクセスするときに9ビット*4に格納されるということだな。

unicode<-->jis のマッピングは無いの？
ms 産の表しか見つからないんだけど、大丈夫？

ないわけないじゃん。

>>61
unicode.orgへ行け。

JIS X 0221 や JIS X 0213 にはマッピングが書いてあったような。
もっとも、そこに書いてあるマッピングを使って幸せになれるかはわからんけど。

T書体フォントマダー? (AAry

> unicode.org
> JIS X 0221
> JIS X 0213
書いてあるマッピングが微妙に違う罠
詳しくはXML日本語プロファイル見れと言っておけばいいのかな
(X0213のマッピングはないけど)

いきなりですけど、ＪＩＳ第３水準、第４水準は３バイトコードになりますか？

符号化方式による。

具体的には
Shift_JIS-JP-2004: すべて2バイト
EUC-JIS-JP-2004: 第三水準は2バイト、第四水準は3バイト
ISO-2022-JP-2004:
すべて2バイトだが、エスケープシーケンスが必要。
UTF-8:
BMPの1文字に割り当てられたものは3バイト、BMP外に割り当てられたものは4バイト
BMPの2文字の並びに割り当てられたもの(非漢字のみ)は6バイト

> EUC-JIS-JP-2004
なんだこれ
もちろんEUC-JIS-2004の間違い

>>39
UTF-32 で表現できる文字数は UTF-16 と大差ない。（同じだっけ？）
UCS4 で定義できる文字数をすべて表現することが出来るのは
現時点で UTF-8 しかないはず。

>>70
UTF-32ってのは、そもそもUTF-16とレンジを揃えるために制定されたもの。
その後UTF-8もこれらと同じレンジに制限されたから、どれでも文字数は同じ。

そのutf-8もrfc3629で、文字コードのrangeをutf-16でも表現可能な
0-0x10ffffに制限してしまったからね。

新utf-8や新utf-16みたいなものでも作らない限り、
0x110000以上は仮に定義されても使えないんじゃないかな。

ありゃ。書いてる間に重複してしまった。

ところで、素朴な疑問なんだが、
Shift JIS や EUC-JP や Big5 や GB なんかを
Unicode に変換してしまうと、元のコードで違う文字だったものが
Unicode では同じ文字になってしまうわけですよね？
つまりラウンドトリップは保証されていない？
全単射は不可能？

>>74
できることになってる。
ただし実装によってはできなかったりしなくもない。

ラウンドトリップは保証されているけど
(使っているマップによってはできないけど)、
結局のところCJKV統合しちゃってるので
言語判別は出現確率から統計的に
やらなくちゃだめになってるんですね？
どうせ16ビットにおさまらないんだったら
最初から統合なんてやらなけりゃよかったのに・・・

Basic LatinとかLatin 1で書かれているものが英語がドイツ語かフランス語かは不明
ですがそれはUnicodeの仕様です。
たとえば"SS"を小文字変換するのは言語情報がないとできません。

>>74
複数の文字コードのソース情報を混ぜた場合の話？
それとも単一情報をソースの文字コード(or 言語)情報なしに元に戻したい？

プレーンテキストで複数のソース混合ってISO-2022-JP-2以外にあるの?

ISO-2022-JP-2で一つでしょ。

>>78
>単一情報をソースの文字コード(or 言語)情報なしに元に戻したい

これがやりたい。統計的に文字の出現確率なんかを
調べればできるのだろうけど。たとえば Polyglot3000
なんかがやってるみたいに。
http://www.polyglot3000.com/

>>79-80
やっぱりISO-2022の枠組みって万能だなぁ。

>>81
うーんそれはラウンドトリップの問題じゃなくて、
あんさんの言うとおり統計とって言語を推定するしか。

しかし日本語だと判ったとしてもShift_JISだったかEUC-JPだったかは判らんよなぁ……

> やっぱりISO-2022の枠組みって万能だなぁ。
しかし万能なのは日本人の脳内ISO 2022に近い罠
> しかし日本語だと判ったとしてもShift_JISだったかEUC-JPだったかは判らんよなぁ……
エンコーディングスキームが分かる必要はないでしょ
ISO-2022-JP-2が複数ソースというのもそういう意味なんだから

ISO 2022系は、重複符号化があると、
Unicodeへのmapping fで、f・f^(-1)がidentity functionにならない。

ASCIIのaとJIS X 0201のaなど。

UTF-16がパンクする日は来るのだろうか?

16ビット程度でパンクしないようなら超漢字なんてない

UTF-64でもなんでも策定してバイト数固定のエンディアン意識不要コードを作ればいいんだ。

マッピングの問題は残るけどな。

>>86
UTF-16は16ビットじゃないですよ？

えーと、20bitとちょっと？

>>88 ん？どういうこと？
サロゲートペアの話？

UTF-16は16ビット単位にエンコードするけど、サロゲートペアがあるの
で表現できる文字空間はUTF-8と同じく(>>72)20ビットとちょっと
(>>89)。なので、>>86 の「(UTF-16の)16ビット程度で」というのは不
適切。

という話。

UTF-8ってなんで20ビット止まりなんだっけ？
原理的にはもっと表せるよね？

>>72じゃねの？

てかコード長とオクテット数があわない文字符号体系は好かないんだよな。
西洋人は１オクテットで事足りる事多いからいやがるけどUCS4とかでいいじゃねぇかと思うことって皆はないのかえ？

俺もUCS4でいいと思う。

UCS4にすればcode point処理は固定長で済むかもしれないが、grapheme単位の処理は
可変長だから手間はほとんど同じ。
文字表現を固定長にしたいならCompositionやJIS X 0213も禁止にしないといけませんな。

Normalization Form Dのデータとか…
ISO-8859-1の世界の人は、どう思っているのかな。
まああれば応用広がるのは確かなんだけど。

そのうち一般的なPCでのC言語の char が 32 ビットになって全部解決。

char c = '字';

中途半端なジョークはやめてくれ

http://std.dkuug.dk/jtc1/sc2/wg2/docs/N3104.doc

Resolution 48.14 において、１０万文字達成。

「翔」という字は最近ではよく見るがJISでは第2水準になってる。
JIS漢字制定当時(1978年)は人名漢字に無かったが(当時人名漢字にあった字は全て第1水準になってる)、
当時は「飛翔」等の言葉もあまり使われなかったのかな?

>>100
特に記念碑的意味しかないが、とりあえずおめ。

CJK ext. Cはいつ入るのかなぁ。絶対使いどころないけど。

>>101
翔泳社って、そういうとこ気にせず名前決めたのかな。

78年というとまだ当用漢字の時代だから、
「そんな難しい字は使うな」という意識があったんじゃないかな。

当時の新聞ひっくり返せば、「飛しょう」なんて表記も出てくるかも。

逆にその時代だと広告なんかは気兼ねなく「飛翔」って書いていたんじゃないかな。
電算写植もそれほど普及していない時代なんだし。

で「粍」「糎」「粁」なんてどう考えても全然使われない字が第1水準なわけだが、
当時は良く使ってたのかな?
「椴」とかは都道府県、市町村名に使われてる字は全て第1水準という事になってたから。
北海道の椴法華村の為に第1水準に入ってる。もし椴法華村が存在してなかったらこの字は第2水準だったか
JIS X0208には入ってなかっただろう。
しかし四條畷市や五條市の「條」は第2水準である。これらの市は78年にはこの市名で存在してた筈だが、
異体字は選考から除外されてたのかな?(「條」は「条」の旧字体)
第2水準が使えない環境では「四条畷」「五条」としろということだったのか?

くだらん事を言うな

「粍」「糎」「粁」は単位なんだから、それなりに使う場面もあったor考えられたんじゃないの。
少なくとも俺がいまパっと見て読めるってことはそれなりに見かけている筈だ。

でも普通は「mm」「cm」「km」か「ミリメートル」「センチメートル」「キロメートル」と書くよな。

だからその辺は明治以来の印刷屋の流儀があるわけで。
日本語タイプライタなんて､JIS制定以前からあったんだから
78年当時のみを考えても意味がないだろ。

粁が千チメートルでないとはこれいかに

何でジョ（禾予）がないのかが分からん。

>>109
推測でしかないが、法律の条文（正式には縦書きだよね）に使われてるからかもな。

ジョ（禾予）は第三水準だね。ちなみにU+25771。

粍 糎 粉 米 籵 粨 粁
竓 竰 竕 立 竍 竡 竏
瓱 甅 瓰 瓦 瓧 瓸 瓩 瓲

>>96
どうせ固定長厨は漢字が使いたいだけだから問題ない。
http://www.dkuug.dk/jtc1/sc2/wg2/docs/n3091.doc
のcollectionにも結合文字は含まれていないし。
まあそれはそもそも現状ではNamed sequenceをcollectionに含めることができない
という仕様の問題もあるんだが。
http://std.dkuug.dk/jtc1/sc2/wg2/docs/N3105.pdf

> どうせ固定長厨は漢字が使いたいだけだから問題ない。
ああでもIdeographic Variationが使われ出すと破綻するな。
つーかそんなに固定長が好きなら内部でgrapheme単位に固定長の独自コードに
好きなようにマップすればいいだろ。それを情報交換用の符号として標準化する
必然性はどこにもない。

__STDC_ISO_10646__が定義されていないwchar_tは本来そういう目的を想定して
作られたものだし(EUC-JP固定長とかを表すかもしれない)
そもそもUnicode自体固定長だった時代には内部コードで使うことを想定していた。
だからマッピングの違いがこんな大問題になるとは思われていなかったし
エンディアンも内部使用onlyなら計算機のエンディアンに決まっているだろと。

http://www.yui.ne.jp/np2/tool/index.html
ここのmakefont32を使って作られた画像ファイルを
ゲームで読み込んでフォントとして使いたいんだが、
どうやって文字の位置を取得したらいいか知恵を貸してくれ。

おそらくは何らかの文字コードの上位ビットと下位ビット
で位置が決められていると思うんだが。

補足。

http://www.co0.net/upload/src/0006521305.png
こんなかんじの画像が出力されるだが。

PC-9821って文字コードShift_JISだっけ？

Shift_JISの0xHHLLのコードの各HHに対し、
LLが0x40〜0x9E (0x7Fは除外)と
0x9F〜0xFCの二行に分け、
左から並んでるだけじゃ?

>>120
素直に句点コード表なんだが。あんたの説明は、ShiftJisのコード配置の説明そのものだ。

>>120,121
サンクス。
調べてみる。

>>119
PC-9821のMS-DOSはShift_JISだが漢字ROMはJIS
つまりMS-DOSがShift_JIS→JISの変換をやってる

>>123
いいえ。

>>124
いいえって何が?

MS-DOSは変換しませんな。BIOSは変換するかも知らんが。

98のVRAMはJIS。
で、DOSは(速度のために)BIOS使わずに
直接書いてた気がする。

>>127
×DOSは
○多くのDOSアプリが

DOSが画面出力をしないとでも？

もうちょっとわかりやすく書いておこうか？

DOS上のアプリ、例えば一太郎やMIFESがVRAMに直書きしていたのは常識で
そんなことは誰でも知ってる。

問題は、DOS(もっと言えばint29hのハンドラ)が
VRAMに書き込んでいたかどうか、だよ。

>>126 BIOSはそんなことやってくれません。
DOS/Vのコンソールドライバがやってくれる。

0xA0000 からだっけ？

PC-98x1シリーズの話じゃなかったのか

DOS/Vの仮想VRAMは確かにSJISだけど
ずっと98の話だった筈。

98 ができたときは SJIS を使うことを想定していなかったので
BIOS では SJIS からの変換はやっていないはず。

このスレにもよく出てくる番号付けたがり病の話
http://khdd.net/kanou/kangae/2006/Jun.html

ttp://legacy-encoding.sourceforge.jp/wiki/
ttp://legacy-encoding.sourceforge.jp/wiki/index.php?%B3%B5%CD%D7
>文字コード変換処理が Unicode 経由で行われるようになった事で次のような問題が発生するようになっています。
>
>・半角文字の '\' がシフトJISと日本語EUC との間で期待どおりに変換できない。
>・'〜' (波ダッシュ) などの JIS漢字で定義されている一部の記号が変換できない。
>・丸付数字などの Windows 機種依存文字が変換できない。
>
>これらの問題を解決するために、オープンソースソフトウェアで、次のキャラクタセットを使えるようにします。

いろんな意味でよくわからん。

なるほど、0x5cをUnicodeにするときにバックスラッシュに置き換えるか円マークに置き換えるかで、
逆変換時に結果が変わるのと同じ種類の問題か。
ShiftJis⇔EUCは機械的に変換できるから、Unicode経由じゃなければ発生しないからねぇ。

>丸付数字などの Windows 機種依存文字が変換できない

あり？Unicodeではこれは表現できなかったのか。

Unicodeで表現できるからと言って、変換表にそれがあるかというと・・・。

丸付き数字ってUnicode上にいくつか種類なかったっけ…

>>141
シフトJIS⇔Unicode や EUC⇔Unicode の変換表に丸付き数字がないんじゃない？

>>142
機種依存文字はシフトJISとかEUCの変換表に定義されていませんから…

丸付き数字は機種依存文字じゃないでしょ？

ちょっと前までは「機種依存文字」って呼ばれてたけど、今はもうそんなことないっていうこと？

JIS X 0213(第三、第四水準＋非漢字)の丸付き数字?

あれは「今更合成文字を規格に入れてんじゃねーよ、
もう互換文字は収録しないから」って拒否されたんじゃなかった?

>>145
Mac で普通に文字化けします。

MSIME2007ではCP932に収録されてない文字は「環境依存文字」って表示が出る。
だから、Microsoft曰く、丸付き数字は「環境依存文字」。
なお、Macではフォントによっては表示されないし、フォントによっては表示される、はず。

>>148
MSIME2007 では CP932 の定義が変わったの？

ここ見ると、丸付き数字がばっちり収録(?) されてるみたいだけど。
http://www.microsoft.com/globaldev/reference/dbcs/932/932_87.mspx

>>148
JIS X 0201/0208に収録されてないかな?

>>148
＞なお、Macではフォントによっては表示されないし、
＞フォントによっては表示される、はず。

それはMacJapanese時代の話。
今（内部Unicodeアプリ）は、フォント依存ではなくアプリ依存。
似非ISO-2022-JPや似非Shift_JISのドキュメント中の丸付き数字は、
素直にAppleのAPIを使ってるアプリならゲタ（U+FFFD）になる。

こういうのはシェアの大きいほうに合わせてCP932で統一してほしいなぁ。
一時的には混乱するかもしれないが、
結局は Mac ユーザでさえもその利益に預かれると思うんだけど。

というか、Mac OS XはUnicode中心で、
Shift_JISは捨てる傾向だから、今更CP932も糞もない。

実際、Mail.appもISO-2022-JPに収まらないとUTF-8になる。
CP932にある文字でもね。

今後CP932は不要。

>>151
そうか？
実際フォントを変えたら
○付き数字になったり ( ) 付き曜日になったりするんだが。

>>154
単にそのアプリが今どき珍しく内部SJISだって話だろ。

もうMac OS X純正アプリではほとんど皆無なんじゃないかな。

マカーｳｻﾞｽ

>>153
問題は、「Shift_JISと名乗っているCP932のウェブページ」やら
「ISO-2022-JPと名乗っているCP50220のメール」やらを
表示（Unicodeに変換）する際に
機種依存文字をサポートしてやるかどうかってことでしょ。

>>153
＞実際、Mail.appもISO-2022-JPに収まらないとUTF-8になる。
＞CP932にある文字でもね。

charset=CP932になるから試してみ。

>>155
ヒント：ブラウザ

>>160
ああ、Firefox for Mac OS Xか。
あれは非常に特殊なケース。つーか、バグと言ってもいい。

http://lists.sourceforge.jp/mailman/archives/legacy-encoding-talk-ja/2006-April/000059.html

Safariの〜問題も悩ましいな。Mac OS Xは。

もうちょい正確に言うと、
Mail.appではISO-2022-JPに収まらずCP932に収まるメールは、
含まれる字種によって
charset=CP932で送信される場合と
ISO-2022-JP（もどき）で送信される場合がある。

>>162
昔から問題になってるのに、どうして直そうとしないのかねえ。

>>153
>今後CP932は不要。

永遠に不滅でつ。

>>164
間違えたのはMSの方だから。

>>166
どちらも波ダッシュがらみだが、まったく別の問題。

MS:
U+007E TILDE <-> Shift_JIS 0x7E OVERLINE
U+301C WAVE DASH -> Shift_JIS NA 【MSの問題】
U+FF5E FULLWIDTH TILDE <-> Shift_JIS 0x8160 WAVE DASH 【MSの問題】

Safari:
U+007E TILDE -> Shift_JIS 0x8160 WAVE DASH 【Safariの問題】
U+301C WAVE DASH <-> Shift_JIS 0x8160 WAVE DASH
U+FF5E FULLWIDTH TILDE <-> Shift_JIS NA

>U+007E TILDE -> Shift_JIS 0x8160 WAVE DASH 【Safariの問題】
ちゃんとUnicodeConverterにU+007E TILDE -> Shift_JIS 0x7Eとするためのオプションが
用意されてるんだけど、Safariチームは知らないか、面倒いのでシカトしてる。

>>168
でも、SafariもShift_JIS to Unicodeは

Shift_JIS 0x7E OVERLINE -> U+007E TILDE

なんだよね。それでいてUnicode to Shift_JISが

U+007E TILDE -> Shift_JIS 0x8160 WAVE DASH

なのが意味不明。

>>169
> それでいてUnicode to Shift_JISが
> U+007E TILDE -> Shift_JIS 0x8160 WAVE DASH
> なのが意味不明。

これは入力フォームで~を入力した時を想定?

それはキーボードがJISでも、Shift-^が何故かASCII TILDEになっていて、
Shift_JISにはOVERLINEはあっても、ASCII TILDEはないから、
一番近いWAVE DASHを使うというルールなんだと思う。

> でも、SafariもShift_JIS to Unicodeは
> Shift_JIS 0x7E OVERLINE -> U+007E TILDE
> なんだよね。

これはどういうシチュエーション?
Shift_JISなHTMLで、データを入力フォームに自動的に引用とか?

>>170
> それはキーボードがJISでも、Shift-^が何故かASCII TILDEになっていて、
> Shift_JISにはOVERLINEはあっても、ASCII TILDEはないから、
> 一番近いWAVE DASHを使うというルールなんだと思う。

そりゃそうなんだけど。
http://d.hatena.ne.jp/NAOI/20060623

>>171
どうしてわざわざそのページの為だけにhatenaにアカウント作ってんだ？

はげしーくどうい

>>153
そんなこと言ったら、Windows だって 10 年以上前から内部の API は
Unicode (UTF16 or UCS2) ベースじゃまいか。

ucs2だったような希ガス

>>172
うｐろだだと流れるからじゃないの
>>175
Windows 2000からUTF-16になった

>>176
別に要点まとめるなり、小分けにカキコするなりしてここに書き込めば済むレベルの話だと思うんだが。
あ、てか、いま気づいたんがコイツ、有料オプションまで使ってるぞ。
ttp://d.hatena.ne.jp/NAOI/about
ますますなにがしたいんだか謎が深まるばかりだ。

直井靖氏?

Unicode ver 5.00 がリリース！
http://www.unicode.org/versions/Unicode5.0.0/

>>179
日本語にはあまり影響ないのばっかだなぁ今回は。

で、何バイト？

1. メモ帳を開く。
2. 「Bush hid the facts」と入力する。
3. ファイルを保存する。
4. 保存したファイルをメモ帳で開く。

解明してください。

>>180
日本からはNamedSequencesの追加要望すらしてないんですか
どれだけやる気ないんだ
>>182
http://blogs.msdn.com/michkap/archive/2006/06/14/631016.aspx

>>179
リリース？
βじゃねーの？

もうβは取れました
何ヶ月前からタイムスリップしてきたんですか

>>183
追加して欲しいのあるか？
国内規格の新設・改定もなかったし、
無理に増やす必要もなかったんじゃない？

>>186
JIS X 0213:2004のUSIで表される25文字のうち2文字しか登録されていない。
未登録のNamed Sequenceは勝手に使ってはいけないことになってるし
正式な文字名もない。

>>183
あれえ? なんでだ? Unicode と解釈しているようだが。

>>187
どうしてその2文字だけが登録されてるの？
UAX #34のTable 1で例として挙げたものについてだけ
（ドラフトの段階で）とりあえず登録してみた
ってふうにしか見えないんだけど。

>>189
> どうしてその2文字だけが登録されてるの？
いや漏れに聞かれても。
> UAX #34のTable 1で例として挙げたものについてだけ
> （ドラフトの段階で）とりあえず登録してみた
> ってふうにしか見えないんだけど。
たぶんそうなんだろうけど、どのみちやる気がないことに変わりはない。
http://std.dkuug.dk/jtc1/sc2/wg2/docs/N3105.pdf
でようやくNamed Sequenceを含むCollectionが定義可能になるわけだが、
肝心のNamed Sequenceが定義されていないのでは「JIS X 0213の文字を
全部含む日本語レパートリ」すら登録できない。
と思ったらUSI抜きで登録するつもりですか。もうね(ry
http://www.dkuug.dk/jtc1/sc2/wg2/docs/n3091.doc

って>>116で一度貼ってた。
やっぱり非漢字の合成文字なんてどうせ誰も使わないとか本音では考えてるとしか
思えないんだが。
AJ16相当グリフのIVD登録マダー? (AAry

>>190
> と思ったらUSI抜きで登録するつもりですか。もうね(ry

ん？　このJAPANESE NON IDEOGRAPHICS EXTENSIONって
どういう基準で選んでるんだろ？
N3091には「JIS X 0213:2004 non ideographic extension」とあるけど、
USIだけじゃなく、
たとえばU+31F0..U+31FF（アイヌ語表記用小書きカタカナ）も入ってないよね。

>>192
いったいどこ見てるの?
漏れの手元にあるJNIExt.txt(↓からダウンロード)には
http://www.dkuug.dk/jtc1/sc2/wg2/docs/n3091-A.zip
U+31F0〜U+31FFもしっかり入ってるけど? (もちろんUSIは入ってない)

http://mail.apps.ietf.org/ietf/charsets/msg01550.html
附属書5を恣意的に適用できるんだったら適用するのかどうか明示しておく
必要があると思う。

Unicodeを一から作り直すとしたらどうしたいですか?

unicodeじゃ無いものを作ります

過去のものばっさり切り捨てて1から作って欲しいね
明治維新レベルの革命を！

TRONコードにしろと？

1から厨も定期的に現れるよな

超…...

感じ悪い

國語元年からやり直しだな。

互換性をなくす事に重点をおいて
コード振りなおせばいいような気がするんだけど
どうだい？そんな甘かないですかね

だからさっさと銀河へ向けて地球開国
Galaxycodeへ移行しろと

ってなことを1000年後くらいにはどっかの星から言われるのだろうか

>>203
甘過ぎ

>>196
1文字64ビット

ほら64bit厨128bit厨もまた出てきた
>>199で一緒に書いとくべきだった

ちなみにフォント・トレーサビリティシステムで使われているucodeが128bit長
(さらに128bit単位で拡張も可能らしい)

64kbit文字にしてさ、文字テーブルを参照しなくても
256x256の２値画像で文字に変換できるようにするとかだめなのかね・・・

それもうんざりするほど既出
ベクタ画像という発想が出てこない時点で10年前のアイデア
頼むから現存するテクノロジ(PDFとか)くらい知っててくれ

>>209
ダメ。
字形に依存した符号化は、良く似た異なる文字の峻別で面倒な事になる。
それぞれに識別パターンを埋め込むような事をするなら、字形から導くメリットが例えあったとしても大幅に削がれることになる (字形対応ではビットパターンに大量の無駄が生じるため)。

アラビア語とかでは字母を組み合わせてgrapheme作ったり、前後の繋がりでglyphも
動的に変わるんですけど
固定長、文字コードとgrapheme１対１対応を提案する人に訊きたいんですが、こう
いうのはどうやって実現するんですか？

そういうこと聞いても忘れた頃にまた書き込んでくるの
せめて過去ログくらい見ろと言いたくなる

携帯業界はunicode化してかないの？

何が悲しくて非関税障壁を自分から埋めなきゃならないんですか
by ガラパゴス諸島に生息する携帯キャリア

UNICODEでフォーマットされたテキストファイルを、ReadFile関数で読み込んでいます。

TCHAR szBuffer[1024];

hFile = CreateFile(szFileName, GENERIC_READ, FILE_SHARE_READ, NULL,
OPEN_EXISTING, 0, NULL);
if(hFile == INVALID_HANDLE_VALUE) return FALSE; //ファイルを開けなかった場合

dwFileSize = GetFileSize(hFile, NULL);
if(dwFileSize > MAX_READ) return FALSE; //ファイルがおおきすぎる場合

bReturn = ReadFile(hFile, szBuffer, dwFileSize, &dwRcv, NULL);
if(bReturn == FALSE) return FALSE;//ファイルを読み込めなかった場合

szBufferにはUNICODE文字列を指すアドレス（ポインタ）が入っていると思うんですが、　lstrlen(szBuffer)の答えがいつも3になってしまいます。
どこがおかしいのかわかりません。

ﾌﾟﾘﾌﾟﾛｾｯｻの_UNICODEの定義や、TEXT(""),TCHAR　等はきちんと使用しているのですが・・・

>>216
よく分からないけど

> _UNICODEの定義
_UNICODE だけでなく、UNICODE の定義もしなくちゃいけないのでは？
（そのせいで lstrlen が lstrlenA になっているのではないかと）

あとは szBuffer の終端がNULL文字で終わってないように見えることと、
ファイル先頭に BOM があるんじゃないかということが気になる。

>>4のICU始めてドキュメントみたけど、
あまりに巨大なのでめまいがした…

>>216
たとえばテキストの最初が "AB" だったとすると UTF-16-LE では
FF FE 61 00 62 00
になる。ReadFile は先頭から TCHAR に入れていくので
UNICODE 使用時には
00FF 00FE 0061 0000 0062 0000
のようになる。その４バイト目の 0000 を lstrlen が文字列の
終端だとみなすために文字列の長さは３とみなされる。

>>219
あ、"AB"じゃなくて"ab"ね。

>>219
とおもって実際に実行してみたらちゃんと動いた。
（先頭の BOM は抜く必要があるが）
そもそも ReadFile はファイルの中身をそのまま取ってくる
だけだから WCHAR を引数にしちゃいかんような気がする。

>>219 >>221
ではどうしたらいいんでしょう
先頭のBOMって、ただのテキストファイルにもそういった識別子のようなものが埋め込まれているんでしょうか？
UNICODEファイルの操作ってそんなに特別なことなんでしょうか？

>>222
とりあえず、そのテキストファイルとやらにどんなデータが入ってるか調べろ

な？

>>222

>>222
いや、>>217だろ･･･
sizeof(TCHAR)の値いくつになるよ？

_UNICODEはtchar.h
UNICODEはwindows.h系で使ってる。

>>216
UNICODEが定義されていようとそうでなかろうと、テキストファイルの文字コードは変わりようがないはず。
だからReadFileやバイナリモードでのファイルの読み書きにはTCHARを使うべきではない。

>>219
> UTF-16-LE
UTF-16LE?
> FF FE 61 00 62 00
UTF-16LEにBOMはない。
面倒でもBOM付きリトルエンディアンのUTF-16とか言うしかない。
> 00FF 00FE 0061 0000 0062 0000
FFFE 0061 0062
だろ。実際にはUnicode使ってないけど。
> FF FE 61 00 62 00
の4バイト目の 00 を lstrlenA が文字列の終端とみなすから 3 になるんでしょ。

>>182を仕様だと言い張るなら
IsTextUnicode()でUnicodeかどうか判定できる

PHPでXMLを生成するプログラムを作っています。
PHPはeuc-jpで書き、XMLはUTF-8で書き出してるんですが、
生成したXMLをTerapadで読み込むと、Shift_JISで読み込まれるようなんです。
UTF-8で再読み込みすると文字化け等も解消され、正常に読み込まれます。
別のプログラムで同様に生成しているXMLではこんなことは起きないので
原因が知りたいのですが、わかる方いますか？
Terapadの設定では"文字/改行コードを自動認識"にしてあります。
またDreamweaverでの読み込みでは文字化けなどは起こりません。

BOM?

基本的なことを聞きたいんですが、
例えばウィンドウズ上で書かれているこのレスはSHIFT-JISなんですか？
macで書いた場合はunicodeで２ちゃん側で変換してるってこと？

原因わかりました。表示文字中に不正な文字が入っていました。
具体的には表示する文の中で、本来全角で書くべきカッコのひとつが
半角になっていたためでした。
これを訂正したところ改善しましたm(_ _)m

>>231
ブラウザが2chへ送り出す時点でUnicodeからShift_JISに変換してる。
Safariで ~ が化けたりするのはその変換テーブルがWindows PCと
一致していないため。

Windowsと一致する必要はない。

ブラウザが送るのはページの文字コードか送るためのボックスに書いてある属性依存。
また、ブラウザによって送る文字コードの種類も変わってくる。

受ける側は自動判別して、文字参照などを駆使して適当な文字コードで保存。

表示するときは、ページの文字コードと同じにする。

俺は表示・入力系はShift_JIS、内部DBはUTF-8が便利だとは思う。
今後ほとんどの環境がUnicodeに切り替わったときに、修正が楽だから。

>>234
Windows「に」歩み寄るべきだとは一言も言ってないんですが。
永遠に文字化けに悩まされたままでかまわない、解消する必要はないってことですか?

文字化けは起こっていないということです

>>236
Windows「に」歩み寄るべきでないとは一言も言ってないんですが。

Windowsと一致するかどうかという問題ではなくて、
テキストShift_JIS変換に、
利用者の意図と違うものがあることの問題。

利用者はTILDE、OVERLINEを同一視(%7E)している。
WAVE DASHではなくて。

>>237
現に文字化けしてるんですが

文字化けは起こっていないということです

あなたの脳内だけで起きてなくても意味がないので
mohtaと一緒にISO-2022-JP-3が登録されてるお花畑の世界にでも逝っててください

そういえば ISO-2022-JP-2004 が IETF に提出されてるね。
http://mail.apps.ietf.org/ietf/charsets/msg01550.html
反応ないけど・・・

>>241

>>237と>>240は、
「それは文字化けじゃなくて、変換の問題である」
ということを非常に稚拙な方法で訴えているのではないか?

って世に言う「文字化け」の大半は実質変換の不整合の結果なのでは?

単に間違った文字コードで表示しようとするから変になるんじゃないのか

ほとんどの「文字化け」は、
ドキュメントの文字コードと表示システムが想定する文字コードの
不一致が原因じゃないか?

次は機種依存文字。

変換の問題はかなり少ないような…

変換ミスこそ文字化けであって、
違った文字コードで表示するのはデータ自体に間違いはないわけで
文字化けとは言わない気がする。

その無理矢理な論理、恥ずかしいよ?

人生とは旅であって、

昔の文字化けと今の文字化けはあきらかに意味が変わってるね

人の一生は重き荷を背負いて長き

1200ボーのモデムで、文字化けに強いishフォーマットでエロ画像を交換していたオレがやってきましたよ。
ssより、s7のほうが化けにくいですよ。

一発簡単文字化けテクニック

nkf -Sj | nkf -We
後戻りは出来ない

>>247
>変換ミスこそ文字化けであって、
>違った文字コードで表示するのはデータ自体に間違いはないわけで
>文字化けとは言わない気がする。

「変換ミスは文字化けではない」でしょう？

変換ミスと呼ぼうと文字化けと呼ぼうと実際それに日々悩まされていて
対応を要求されたりする事実に何の変わりもないので、
そんな言葉遊びに興味はありません。
対応の仕方とかの建設的な話題だったらいくらでも話したいですが。

ぷ

建設的な質問があれば暇なヤツが応えるだろうさ

ところでこの文字化けの話はどこから始まっているの?

>>162

これはひどい
http://www.chokanji.com/webp/soft.html
今どきはしご高やたて崎を例に出すなんて、進歩してないのは
Windowsじゃなくて超漢字関係者の頭の中じゃねーの。
つーかT書体フォントマダー? (AAry
せめてExtension Cに提案されてる寿司屋のメニューに出てきそうな漢字とかを
例に出すくらいの芸は見せてほしいもんだ。
http://www.cse.cuhk.edu.hk/~irg/irg/irg26/IRG26.htm
つーか日本のEvidenceの力の入りようと他国の手抜きっぷりの違いがスゴス
日本は「片割れが入りそうにないからもう片方も削除を提案します」とか言ってるのに
中国はこの期に及んで千字以上追加しろとか言ってるし。
やっぱり(寿司屋のメニューとか人名地名以外では)一部の
古文書や仏典の研究者しか興味なさそうなレア漢字ばっかりになってきた
(そして実際の戸籍システムではJISともUnicodeとも関係ない外字システムの
再発明を続ける)日本と
現実に戸籍システムでGB18030を運用する必要に迫られてる中国の温度差
なんだろうな。

＞Extension Cに提案されてる寿司屋のメニューに出てきそうな漢字
これはひどい

他に少しでも一般人が興味持てそうな例あるか?

その内、人名、固有名詞の「高」は全部はしご高になる日が来そうな気がする。

どの高橋さんも、ちょっと捜せば自分の名前か家族の名前がはしご高で書かれた
手紙の一通や二通は見つかるだろうし。

なんで活字と手書き文字の区別がつけられなくなっちゃったんだろう。

教科書体至上主義の戦後の漢字教育のせいだと思う

フォントの切り替えが、
手書き文字の機能の一部を担ってきたように、
文字集合も手書き文字の機能の極一部を担ってくるようになったと考えては?
全部担うことになるとさすがに困るんだけど。

http://slashdot.jp/comments.pl?sid=333447&op=&threshold=1&commentsort=3&mode=thread&pid=1022939#1022963
なんかは「おもしろおかしい」が付いてるけどさ、
音声ファイルに関しては「テキストファイル」方式(MIDI)はすっかり廃れたよね。
文書ファイルに関しても同様なことが起きたりはしないのかな。
アウトライン化したPDFか何かばかりになって将来のGoogle先生はデジタルデータに
OCRみたいな処理をするのが当たり前、みたいな。

MIDIは、音楽再生形式としてはあまり使われてないだけで、
全然廃れてない。(デジタル化)ミュージシャンの間では現役。

そりゃWeb上のフルカラー画像はほとんど.jpgだけど編集段階で劣化する
フォーマットを使うわけないわな。圧縮音楽もしかり
で、将来のGoogle先生は最終出力を相手にしないわけにはいかないでしょ

＞音声ファイルに関しては「テキストファイル」方式(MIDI)はすっかり廃れたよね。
いいえ、MIDIはテキストファイルじゃありませんし、そもそも音声を表すためのデータでもありません。
「楽譜」と「音声」の区別ができない人にとっては、「文字」と「画像」の区別がつかないのかもしれませんが、
＞文書ファイルに関しても同様なことが起きたりはしないのかな。
なんてことは有り得ないから安心してください。

MIDIプレーヤーで使う音色データのことをサウンドフォントって言うでしょ?
> じゃありませんし、
> でもありません。
言葉尻をとらえられないように逃げるのがお上手ですね。
> 「楽譜」と「音声」の区別ができない人にとっては、
> 「文字」と「画像」の区別がつかないのかもしれませんが、
Web上で「楽譜」を配る習慣がなくなったように「文字」を配る習慣がなくなる
んじゃね? って言ってるだけですが何がそんなに気にくわないのですか?

たとえばMSXとか何かで、MMLで、音楽書いてた人じゃない？
「MML」はテキストデータ。それをコンパイルして、「標準MIDIファイル」。

MIDIのネットでのやり取り、昔に比べたら、確かに廃れたけどね…。
でも、DTM板やら作曲板やらでは、まだまだ現役。

>>270
だから、楽譜を配る習慣はなくなってないだろ。
尤も、楽譜は一般人は見る機会が少ないから目立たないわけで、
それを言うなら一般人が文字を見る機会が少なくなるとは思えんが。

MIDIが廃れたのはJASRACの影響が大きいかと　スレ違いsage

これからはoggの時代

MODてのもあったな
文字情報もベクトルフォント込みになって
文字列比較も類似性で行なうようになるのか?

>>270

MIDIデータをCDやmp3等のような音楽観賞用のデータだと
勘違いしているから、そういった誤解も生まれるんだよな。

MIDIデータは、楽器を鳴らすためのデータであって、音楽を
作成する人にとっては、いまでも現役。

昔はPCの能力（mp3エンコード時間）や回線の細さなどの問題
から、観賞用にもファイルサイズが小さくてすむMIDIデータ
形式での配布が多かっただけで、それが元に戻っただけ。

昔はGPLなソフトは、ほとんどソースでしか配布されてなかったけど
いまは普通にバイナリも配布されているのと似ている。

>>273
それは mp3とかも同じだと思うよ。

逆に他音源からのリッピングなどが多いmp3と比べて、自分で打ち込むMIDIのほうが
著作権処理は楽。

メールに使われている文字はJISコードでemacsというかUNIXで使われているのは
EUCなのに文字化けせずにコピペできるっていうのは内部で変換されているのでしょうか?
それかまったく違うことをしているのか

>>278
ケース1
メールソフトはEUCに変換してからGUIに表示してもらっている。
コピー要求に対しても、EUCに変換済みの文字を渡している。

ケース2
メールソフトは変換せずにGUIに変換して表示してもらっている。
コピー要求に対しても変換せずに渡し、後はGUI側に任せている。

たまに臍曲がりなGUIとアプリケーションの組み合わせで文字化けが発生するのは
例えばケース1で表示には変換済みを渡すのにコピーには未変換を渡すようなことをしているから。
その場合でも、GUI側が自動変換するなりペースト側アプリが自動変換するなりすれば化けずに済むが。

>>278
Emacsの内部は独自コード。

Emacs外とのやり取りでは外の事情に合わせた文字コードを使うことができる。
つまり変換する。

コピペはX11とのやりとりになるが、
X11はC-TEXT(compound text)を使う。

279>>
280>>
なるほど。GUIやアプリ両方でやってるんですね。。。
勉強してきます。ありがとうございました。

ISO/IEC 10646:2003の無償化キター
http://isotc.iso.org/livelink/livelink/fetch/2000/2489/Ittf_Home/PubliclyAvailableStandards.htm
U+29FCEの字形は古いままなのでAmendmentは含まれていない模様

libiconv がサポートしている文字コードの一覧を得るための
関数って、 libiconv 自体には用意されていますか？

iconv.h 眺めてると iconvlist() つー関数があるみたいですね。

プラットフォーム依存の話になりますが MS のコードページ一覧によると
http://windowssdk.msdn.microsoft.com/en-us/library/ms776446.aspx
20000 x-Chinese_CNS CNS Taiwan; Chinese Traditional (CNS)
20002 x_Chinese-Eten Eten Taiwan; Chinese Traditional (Eten)
となっています。しかし .NET Framework 2.0 で各コードページについて
EncodingInfo.Name を取得すると上記はそれぞれ x-Chinese-CNS,
x-Chinese-Eten となり "_" と "-" が一致しません。いずれも
x- ですから IANA には登録されていません。エンコード名として
何が正しいのでしょうか？何に依拠すべきでしょうか？

IANA未登録のエンコーディング名称に付けるのは"x-"ということになってる。
"x_"ではない。実際に取れるものも"x-"ならそれでいいんじゃないの。

一方はそれでいいとして、

MIMEなんかで使う時には、

X-x_Chinese-Eten

としなければ仕方ないだろ。

locale -m で表示される charset 一覧の文字コード名って、
何を元にして生成されているんですか？
特に Linux (Debian GNU/Linux, Fedora Core 5) を想定しています。

iconv や ICU で受付可能な文字コード一覧と照合したいんですが、
ポータブルに書くために特定のマシンの locale -m の出力を
ハードコーディングすると言うことは避けたいと思っています。

/usr/share/i18n/charmaps/*とか
詳しくはlocaleコマンドのソース読め。

IBMのICUについて語りたいんですが
どこのスレに行けばいいですか？

>>291
2chじゃなくてもいいならcppllにでも逝け。

>>291
遠慮なくここで語ってくれたまえ。

vine3.2 gcc 3.3.2
の環境で以下のソースをコンパイルして、ターミナルで実行しても
何も出力されません。

#include <iostream>
#include <locale>

using namespace std;

int main()
{
locale jp("japanese");
wstring str = L"漢字";
wcout.imbue(jp);
wcout << str << endl;

return 0;
}

eucjpに変換された"漢字"が出力されるのかと思ったのですけど。

windowsXPだと正しく動作するのですけどね。

Vine3.2のwchar_tってUnicodeなの? EUC fixed widthだったりしない?
Windowsばかり使ってるとwchar_t=Unicodeと思い込みがちだけど

>>296
確かに、Vine3.2は未だ内部コードにEUCJPを使っています。
それは私も知っていました。
しかし、wchar_tがUCS2(もしくはUTF16)でないとは。

今までASCIIしか使っていなかったので知りませんでした。
仕様ではwchar_tが2バイト文字だとしか言及されていないのですね。

扱いづらいような・・・・・。

sizeof(wchar_t)くらい実行してみろ。

>297
wchar_tが2バイトということすら規定されていない。
いずれかの整数型と等しいと規定されているだけ。

現実にはUTF-16かUTF-32（或いはUCS2/UCS4）の実装が多いと俺は思っているけど。

> 現実にはUTF-16かUTF-32（或いはUCS2/UCS4）の実装が多いと俺は思っているけど。
最近はLinuxもUTF-8ロケールが増えつつあるしおおむねそういう手抜きができるように
なってきたと思うけど一昔前の日本語UNIX環境ではまったく正しくなかった。
ちなみにUCSであることを保証したければ__STDC_ISO_10646__というマクロがある。

linuxだとwchar_tは4バイトなんですね。
そういえば以前にD言語をいじったときに知ったのでした。
それにしても、wstring::findの返り値も実装ごとに違うよ
うですし、ワイド文字の扱いって大変そうですね。
指針がないかちょっと調べてみます。

もし参考になるサイト等ございましたら教えて頂ければ幸
いです。

早速参考になるサイトを発見しました。
http://eside.homeip.net/columns/i18n.html

プラットフォームの違いを吸収するような方法は無いということですか。
古い記事ですが。

>>294
libstdc++はimbueに対応していないっぽい。
代わりに大域ロケールをセットすれば良い。
それから、"japanese"というロケールは普通ないので、
"ja_JP.eucJP"とか""とかを使う。

#include <iostream>
#include <locale>

using namespace std;

int main()
{
  locale::global(locale(""));
  wstring str = L"漢字";
  wcout << str << endl;

  return 0;
}

codecvtクラス使ってくれ。@libstdc++

そもそもワイドキャラの定義ってなんだったっけ？
ワイドキャラ=UCS2&UTF-16のBMPでいいんだっけ？

実装依存。
WindowsではUTF-16だしglibcではUTF-32(UCS-4だったか？)。

TRONコード入れてたり、JISコード入れてたり、なんでもありだね。

>>305
>>299
C/C++のwchar_tはいずれかの整数型と互換であるということが定められているだけ。

しかし、実装毎にワイドキャラの文字コードはなにかっていうのは
定められてないとまずいよね？じゃないとisalphaとかの実装は文字コードに
依存してるからまずそうだし。
つーと当面はWinのワイドキャラ=UTF-16、Linuxのワイドキャラ=UTF-32
で想定してればOK?
でも、Linux上でUTF-16のisalphaみたいなのは変換するか、実装するかしか
ないということか。。

>>309
wchar_tの中身のエンコーディングが何であるかは
処理系が知っていればいいことであって、
プログラマが関知すべきことではない。
wchar_tのエンコーディングに依存するコードは
書くべきではない。原則的にはな。

実用上はWindows:UTF-16、Linux:UTF-32と考えてまあよし。

みんな -fshort-wchar しちゃえばいいのに

>>310
うーん、そしたらさ、isalphaはAsciiコードに依存してるのと同じで
iswalphaはUTF-16というコードに依存してる(Winの場合)ということにならない？

>>312
iswalphaの実装は文字コードに依存していてもいいじゃん。
Ｃランタイムライブラリの一部なんだから。
プログラマが、wchar_tで使われている文字コードを仮定した
コードを書くべきでないということ。

>>313
Winでwchar_tが将来4バイトに拡張されたときにもプログラムは正しく
動くことが理想ってことだよね。
そうすると、UTF-16のファイルをwchar_tに収めるってのもまずいことになる？
あれ、なんかよくわかんなくなってきたな。

将来的にも、もしくはWin/LinuxのクロスでUTF-16を処理する方法って
何が正しいことになるんだ?wchar_tのサイズが未定義ってのが問題なのかな。
なんとなくchar*で持って、結局is系とかは自前で実装というはめになりそう
な気がするが。。

イムブエって
何の略で
あんな
名前？

>>310
FreeBSDは今でもCoding System Independentな実装になってるな
>>315
処理系依存の方法しかない。
>>316
略語じゃなくて染める、吹き込むという意味の英単語

wとか16とか32とか固定と勘違いしそうな名前付けるからいかんのだよ。
char_xp とかUTFVista とかつけとけばよかったんだ。

>>318
何だその無駄に重たそうな名前は(w

じゃあ char_podとか、char_DSとか

なにがおもしろいんだ
馬鹿

>>314
それが理想なんだけど、実際はそうなっていない。
whar_tの表現は内部エンコーディング(プログラムの実行中にその内部処理用と
してだけ使われるべきもの)であるべきだけど、コンパイラが生成する
オブジェクトファイルがwchar_tの表現に依存してしまっているので、
外部に露出してしまっている。
それはオブジェクトファイル内のワイド文字列リテラルのエンコーディングも
そうだし、プログラム内でwchar_tを直接触る部分もやはりwchar_tのサイズに
依存したコードにコンパイルされるというのもある。

これを防ぐにはワイド文字・ワイド文字列へのアクセスを全てAPI経由にし
文字列リテラルも、UTF-8等の外部エンコーディングで入れておいて
プログラムの初回参照時に変換するようにしていれば、
将来の拡張や変更にも耐えられたんだけど。
今から見ればどうってことない方式だけど、当時、しかもC言語の人間に
とってはコスト過多に思えて採用しがたかったかも。

せめてwchar_tが十分大きければwchar_tを直接触るのを許してもエンコーディング
の変更や拡張に耐えられたけど、2byteじゃやはり駄目だね。

>>317
しかしgccがFreeBSDやNetBSDのwchar_t表現に(たしか)対応していない罠……

もうchar*にUTF-8入れとけばいいよ。
ワイド文字は幻想だったのさ。

> それはオブジェクトファイル内のワイド文字列リテラルのエンコーディングも
> そうだし、
ソースファイルのエンコーディングと処理系が扱うエンコーディングは
別じゃなかったっけ? 少なくとも仕様上は。
> wchar_tのサイズに依存した
サイズに依存しちゃいけないのはwchar_tに限った話じゃないような。
C99ではサイズを明示した整数型が追加されたけど。
> もうchar*にUTF-8入れとけばいいよ。
しかしWindowsが対応してない罠

>>324
ソースコードじゃなくてコンパイラが作るオブジェクトファイルの話なんだけど。

> 処理系が扱うエンコーディングは

UCS2まんまぶち込んで置けばそれなりに使えるんじゃね？
API呼ぶ時に変換しなきゃいけないだろうけど

文字集合とエンコーディングってのは、ごっちゃになりやすいのかねぇ
内部表現は UCS-4、外部表現は UTF8 ってのが普及して欲しい
んで、適宜 SJIS や EUCJ への変換もサポートすると

JavaとかC#はその点いいよね。やっぱり、言語の設計段階から
文字列の扱いについて考慮しとかないといかんよな。
後追いだと、Pythonのようにunicodeオブジェクトを導入するくらいしか
ないのでは。

意味不明

Solarisが大昔から文字コードに何を指定してもisalpha()が働くような実装持ってるがな。

>>328
> 文字集合とエンコーディングってのは、ごっちゃになりやすいのかねぇ
そもそも使い分けで困ってるのは日本人だけですから

そんなわけないですねｗ

じゃあ日本が困ってることを国際の舞台で提案してもスルーされたり反対されたり
ひどいのになると「難しくて意味わからん」とか言われてつぶされるのはどうして?
海外でも切実に困ってるんだったら受理されるはずでしょ。
むしろ向こうから提案してくるか

>>334
おまえにとって「海外」は一つの文化圏なのか？
同じ問題に悩まされている人達も居れば
そうでない人達も居るってだけの事だろ。

いたとしても投票権を持つ程度に多いのは日本だけってこった

Windowsのワイドキャラの定義はUCS2の固定でいいんだよ

WIndows 2000からサロゲートに対応してます。
可変長のワイドキャラってC言語の定義的にはどうなんですか。

勿論だめ。
ランタイムライブラリのみならず、ATLのマクロレベルでも対応してないから
コンポーネント間での文字欠けとか起こるだろう。

じゃあ結局UTF-16のファイルから読み込んで文字列検索みたいなのは、
どうコーディングするのが完璧なんでしょう?

文字列検索の何が面倒なんだろう・・・・・

理想的にはUCS-4で読み込んで、そいつを比較というやり方だろうけど。
boost::regexとかなら可能だがchar_traitsの定義とかめんどくさそう。

>>337
でも実際にはUTF-16なんだなぁ

>>341
ちゃんとしたライブラリ使えば簡単だけど、自力でやり出すとNormalizeしたり
合成の切れ目探すのにステートマシン回したりと大変でしょ。

ワイドキャラの定義がUTF-16でないならば、UTF-16ファイルを
read(buf, 10)
wchar_t* w = (wchar_t*)buf;
wcsstr(buf, str);
みたいなコードで検索するのはすべてだめということになりそうな。。
ワイドキャラを固定文字コードとするのが違反なら、Utf16ToWideChar
みたいな関数が必要になるよね

>>345
まあそういうこと。
C/C++はワイド文字を直接読み書きすることを考えていない節がある。

C言語側は柔軟思想だからなぁ
ガチガチに決められたらそれこそ不自由かと

んー、C++とかが柔軟なのはいいとしてWindows上で可変とか未定義とか
にされてるとなあ。さらにマルチバイト≠SJISならprintf("%s", "SJIS文字列です");
だってだめってことでしょ。

環境を限定していいならもちろんwchar_tをUTF-16と仮定して書いても問題ない。

イチイチchar <=> wchar_t を変換することで解決。

文字コードの扱いに可搬性を求める場合、次の二つの方法がある。

・内部でcharまたはwchar_tで持つ。ロケールに依存しない特定のエンコードで入出力したいときは明示的に変換する。
・内部で用いるエンコードを決めておく。ロケール依存のエンコードで入出力したいときは明示的に変換する。

ロケール非依存のエンコーディングとロケール依存のエンコーディングの
両方で入出力する必要がある場合は、どちらを選んでも変換が必要になる。
この変換の機能は標準では用意されていないので、各プラットフォームごとに
自分で書くか、サードパーティーのライブラリを利用する必要がある。

という理解でおｋ？

入力 <=> locale <=> プログラムで自分の扱いやすい文字コード(Java,Unicode,UTF-8)
<=> wchar_t(Win,EUC) <=> char(ANSI C)
普通は作るの面倒だから、感謝しながらライブラリを使うことになる。

仮にマルチバイトが将来UTF-8になったとしもsetlocaleでShift_JISが
printf等で使えるはずだから、安心してShift_JISを使ってもいい。
でないと既存のプログラムがみな動かなくなるし、互換性を重視するMSはそう
いう切捨てはしないだろう。
64環境でintもlongも32bitに保留するような保守的な会社だからな。

ソースファイルはSJISで内部はUTF8とかその逆とかいろいろ大変そうですね

>>353
君はMSに恨みでもあるのか？もしくは学生無勢だろ。

>>353は、発言のないようから馬鹿もしくはコンピュータ歴(死語)が浅いのは確かだね。

COMのおかげでシステムの奥深くまでUCS2が入り込んでいるから
互換性を棄てる以外に抜けられないだろう。
UTF-16に関しても9x時代からの呪縛があるから、
サードパーティーのCOMがサロゲートを受け付けないと予想。

え？そんな狭い世界の話だったのか

新規で設計するならシステムの中は全部UCS-4でいいんじゃないのかと思う。
UTF-8で扱えるのは32ビット分だからコード変換しても欠落はないし。

>>353
そこにsetlocaleは関係しない。
おそらくSetConsoleCP/SetConsoleOutputCP。……という話でないことはわかっているけどさ。

前スレ443で書いた麻雀牌が採用されるようだが
http://std.dkuug.dk/jtc1/sc2/wg2/docs/N3176.pdf
何でドミノの駒は水平のパターンがあるのに麻雀牌にはありませんか?
リーチの表現なんかで必要だと思うんですが。

>>361
そこで合成文字のでb

これを表示できるフォントって作られるのかな？

>>356
馬鹿っていうやつが馬鹿の典型だな。お前は何が問題でどうすればいいかも
わかってないのだろう

>>363 こんな時間でも元気だな。もう眠くないか？

>>360
>setlocale 関数は、プログラムの現在のロケール情報の一部または全体を
>変更したり問い合わせたりするときに使用します。ロケール依存のルーチン
>atof、atoi、atol、printf・・
MSDNランタイム ライブラリ リファレンスより。なので関係します。

>>364
お前もつまんないやつだな。文字コードスレだから文字コードの議論する気の
ないやつはマ板にでもいけよ。

>>362
文字を横倒しにするフォーマット文字とか定義されてなかった気がするから
むしろここは組版機能の出番でしょう。それより問題なのは
> ドミノの駒は水平のパターンがあるのに
相変わらず欧米偏重ですか。と思ったけどドミノの起源って中国?

>>365
さらに_setmbcpの存在が話をややこしくする
>>366
いちいち相手にするな

結局 UCS2 しか安全に使えるコードはないのか。
UTF16 かもしれないとビクビクするくらいなら、
やっぱり UCS4 で統一した方がいいのかなぁ。
しかし wstring の中身は Visual C++ じゃ UCS2 だしなぁ。

もう、std::vector<unsigned long> でいいや（笑

>>357
互換性がどうとか言う以前に、COMで使ってるのはMS謹製Win32APIで
定義されたBSTR型 (文字列長さ＋WCHARの列 - Mac版を除く)だから、
C++のwchar_tがどうなろうが無関係。

>>370
いやその、ランタイムライブラリとシステムの文字コードの範囲がずれてしまうと
アレだ、cygwinみたいにfopenで指定できるのと実際のファイル名が違うとかそういう世界になっちまう。
VFATだと9x互換だからファイル名からUTF-8の範囲でははみ出してしまうし。

べつにいいじゃねえか

>>371
単にOSの問題のような気がする。

でも特定のキャラクタセットとエンコーディングしか処理できないアプリケーションでも
問題なく動かせるように、OS 側が環境変数などでたとえば CreateFile の引数の解釈
を変えてくれるなんていう機能はあれば便利だとは思う。

>>371
一応
FAT部はともかくとして、VFAT自体はUnicodeでファイル名を保存している。

もっともWindows 98のエクスプローラで名前の変更のとき、
CP932外の文字を貼り付けたらどうなるか試したら、?に変換されてしまったが。

ファイル名は大文字英数8.3と相場が決まってる

いつの間にかISO-2022-JP-2004の登録レビューがずいぶんと進んでるな

ちなみにUCS2は厳密には可変長ってほんと？んじゃ2倍してランダムアクセス
するとかって違法?

可変長なのはUTF16。
UCS2はランダムアクセス可能。
ただUCS2っていいながら
UTF16が入ってる事があるんだなぁ。
お行儀悪いプログラムだと。

WindowsのWCHAR、
Javaのchar/String、
ICUのUChar/UString、
ぜんぶUTF-16だった気がする。

形式論をいくら語り合っても無意味だよね。実質UTF16なんだから。

なんでUCS4にしないかなあ。
なんてぼやいてても不毛だよな。

なんでEUCにしないかなあ。
今も昔もこんなぼやきに意味はないよな。

ふーん、玄米ビスケットがあるのにね

玄米ビスケットって何ですか？

WindowsのWCHARはUTF-16より前に作られたんだから仕方がない。

>>212-213
予想通り、また固定長談義w

EUC-JPを文字の途中でぶった切るプログラムだっていくらでもあるんだから
UTF-16にだけそんな厳密な実装を要求することないじゃない。
みんな大げさだなあ

EUC-JPを文字の途中でぶった切るプログラムだっていくらでもあるんだから
僕のプログラムでもぶった切ってます、でクライアントが納得してくれれば良いのだが・・・・

マジレスだがその手のクライアントは今でもShift_JISと外字の世界に生きてませんか?

javaはUTF-8のサブセット
winはサロゲートがあるとMSDNで言っているがwcslenの実装は
while(++wc){}
みたいな実装だから2バイトでカウントしてる。。ひでー話だ

逆にwcslenにサロゲートペア使った1文字を渡して1が帰ってくるのも問題ありだと思う。
ようするにstrlen("あ") == 1と同じようなことだろ。

wcslenが返すのはあくまでwchar_tの数、code point数でもgrapheme数でもない。
文字数を得たり分解したい場合はgrapheme単位で処理するライブラリを別途使う。

Cの場合wchar_tを4バイトにするしかやりようが無い。
STLもあるしboostもあるから、マルチワードパッチなど焼け石に水。

>>390
> javaはUTF-8のサブセット
それはバイトコード内での文字列とかシリアライズした場合の話でしょ。

Java の char とか String は UTF-16 だよ。

>>392
string の文字数を返します。とMSDNには書いてあるがな。矛盾だらけだな。
いまだにUnicodeがUTF-16だとかUCS-2とかなんであるのかを明記してないMSは
後から言い訳しやすいようにあいまいにしてるように見えるな。

サロゲートが分離しても泣かない！

>>394
JDK 5.0からね。

http://java.sun.com/developer/technicalArticles/Intl/Supplementary/
> Most text-processing APIs, however, use character sequences, such as
> the String class or character arrays. These are now interpreted as
> UTF-16 sequences, and the implementations of these APIs is changed to
> correctly handle supplementary characters. The enhancements are part
> of version 5.0 of the Java 2 Platform, Standard Edition (J2SE).

昔はUCS-2と明記されていた。

それからcharはUCS-2でしょ? 16bitのままだから。
charの列はAPIでUTF-16として扱うようになった。

>>397
1.4 の nio.charset では既に UTF-16 って書いてあったりするけどね。
まぁ、どっちにしろ Java は UTF-8 ってのは、あんまし正確じゃないって事で。

>>397
http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2
> char, whose values are 16-bit unsigned integers representing UTF-16 code units (§3.1).

>>397
> 昔はUCS-2と明記されていた。
ざっと見た感じでは UCS-2 とは書いてなくて、
UTF-16 でもなく、Unicode って書いてあるのばっかりだったけど。

>>388
文字を途中でぶった切ってるのは僕のプログラムじゃなくてマイクロソフトです
と言いたくなってきた

この議論見てて不思議なんだけど、そもそもBMP外の文字使うことなんて
そんなにある？

日中韓台の言語処理のプログラマを長いことやってたけど、BMP外は
存在自体を無視。Extension-Aすら大陸絡みじゃなかったら無視してたよ。

GoogleだってExtension-Aも対応してな…と思ったら今は対応してるな。

だからEUC-JPよりもはるかにぶった切るケースに現実に出くわす可能性の低い
UTF-16でそんな神経質になるのはどうして? と思うわけだ

EUC-JPやShift_JISでさんざん懲りたからだろう。

そういえばサロゲートじゃないんだけどさぁ、Mac だと「株式会社」が
１文字扱いになってるヤツがあるじゃん、アレ、Unicode に変換すると
フツーのUnicode文字で５文字分相当になったりするけど、こーゆーのは論外？

>>404
正直羹に懲りて膾を吹くだと思う。
あるいは杞憂とか。
legacy-encoding MLでNEC選定IBM拡張文字とIBM拡張文字を区別できるように
すべきだなんて議論してるのを見てるとめまいがしてくる。
まあ百歩譲ってそれはいいとしてもその方法としてvariation selectorを不正使用する
とか言い出したときは死ねばいいのにと思った

>>405
AppleはPUAを使ってるからLE-talk JAの馬鹿どもよりは百倍マシ

>>402
それはtime_tが4バイトでも別にいーや的な感じが。後ですごい困ったことに
なるかもしれないという恐怖感がさあ。。
http://www.javainthebox.net/laboratory/J2SE1.5/MiscAPI/SupplementaryChar/SupplementaryChar.html
この辺とかみるとJavaも大変なことになっているみたいだね。
charを32bitに変更なんていまさらできないしねぇ。

time_tとかはわざとlong intにしてない事に意味があるんじゃないかな。
4バイトとか実装よりなこと言い出して、実は何も分かってないだろ？

>>407
PUAと言えば、Mac で Apple シフト JIS をUNICODE に変換した時に、
一部の記号になんか無駄に PUA が付加されちゃうんだけどその理由知らない？

4バイトとかが実装よりに感じる初心者さんには言ってないです

俺の定年後の2038年問題よりも、明日起きるUTF-16の文字化けの方が切実だよ

>>411
typedef struct {char val[12];} time_t;
こういうのもあるってことが、伝わらないかな？

いや、time_tがtypedefなんて誰でも知ってるって。しかもvs2003ならlongだし。
そこそんなつっこみどころじゃないし、BMP外を想定しないっていう、
決め打ち的なコーディングはどうかなあという例なだけだよ。
まあtime_tはvs2005でint64だし、ソース変えずにコンパイル環境だけで対応
できるから罪は軽いんだろうけどさ。

time_tは「<」とかが使えないと困る。
そのtypedefだとフリーソフトがコンパイルできない。

>>413

文字コードと関係ないけど、time_t は arithmetic type
だから、それは規格違反。

>>399
charは、一文字を表しているんじゃなくて、
UTF-16の16bit unitに過ぎないってことですね…

Javaのcharの扱いはこなれているような気がしたけど、
そうなってくるとC/C++みたいにwchar_tはAPIだけ決まっているやり方の方が、
UCS-4な実相を選択する余地もあって、うれしいこともあるかもね。

どうかなあという感覚はわかるんだけどね。BMPしか対応しないのは
それなりに理由がある。

そもそも、中国大陸や台湾では化学物質・元素名にどんどん漢字を作っているため、
どこまで行ってもカバー率が100%にならない。例えば、ダイオキシンの
中国大陸での名前は「二(口＋悪の簡体字)英」なんだけど、この
(口＋悪の簡体字)はUnicodeをどこまで見ても載っていない。
(探したらあるかも。見つけたら教えてください)

一方、そういう新漢字以外に関してはExtension-Aすら要らない場合がほとんど。

必死で頑張ってBMP以外まで対応しても、今のカバー率が仮に
99.999%だとして、それが99.9999%になるというわけでもなく、
せいぜい99.9991%にしかならない。残る部分が大して変わらないわけだ。

それぐらいなら、必死こいてBMP外までサポートするより、外字なり
画像なり、Unicodeの範疇外でなんとかする方向で頑張った方がまし。
いくら頑張っても100%にはならないんだし。

>>418
何を愚痴かいてるのか知らないけど、現状必要かどうかじゃなくて、用意してあるかどうかが大事じゃないのか？それ（BMP以外）を使うか使わないかは君が判断する事ではない。

>>418
「悪の簡体字」ってどんなの？
「惡」は悪の康煕字典体だし。。。

wikipedia中文では普通に「二呡英」で載ってるし・・・
http://zh.wikipedia.org/wiki/%E4%BA%8C%E5%99%81%E8%8B%B1

ちなみに「口＋惡」のコード番号はU+5641
JIS補助漢字に収録済みだね

ちなみにBMP外の文字ってWinで表示できるの?

>>421
Vistaではサロゲートペアの表示できたお

XP でも API レベルで対応してるし、
メモ帳とかでもふつうにあつかえる（グリフさえあれば）。

XANO明朝で2面の0213追加文字も表示できる

>>420
それは繁体字。

簡体字だと、本当は口偏に
http://www.unicode.org/cgi-bin/GetUnihanData.pl?codepoint=6076
この字。

>>425
U+6076（晋の上部に心）は「惡」の俗字で、いわゆる政府の決めた「簡体字」じゃないでしょ。
くちへんにこの字を使うのは慶應を广＋Ｋ 广＋Ｏ とか書くのと同レベルの字だから
コード化されてないのもしょうがない。

>>426
ちょっと待った、それはマジで言っているのか？
中国語を知らないなら黙っていた方がいい。

そもそも、上記リンクのVariants-Traditionalにちゃんと「惡」が出てるだろ。

>>427
たしかに中国語に関してはシロートだけど。
じゃU+6076が「正式な」簡体字だとして
くちへん＋U+6076 がコード化されてないのはなんで？
単体では正字扱いだけど構成要素としては俗字扱い？

日本で「曾→曽（常用）」になったから「甑」の旁まで略字にしちゃったのと
同レベルで、手書きでのみ通用する字じゃないのかなぁ。

漢語林付録の日中字体対照表によると
悪(惡)の簡体字はたしかにU+6076となっている。
で、くちへんにU+6076の文字（U+5641）は簡化字政策によればU+6076になるという。
つまりくちへんのあるなしを同一視したと。

上が土の吉とか表示できなくね?

JIS第3,4水準で303文字がBMP外だね。

>>430
メイリオでは表示できるよ。あとAcrobat7.0付属の小塚明朝とかでも
U+20BB7

>>428
中国語の簡体字では、へんやつくりが簡略化されるなら、その文字も自動的に簡略化して表記することが国家規格で決められている。俗字や手書き文字ではけっしてない。

>>428-429
この件の背後には多少複雑な経緯がある。

そもそも、中国語には「噁心」という表現で使われる「噁(U+5641)」という文字があった。
で、この「噁(U+5641)」は簡化政策によると「恶(U+6076)」に統一される。

ところで、中国には「複素環式化合物を音訳するときには必ず口偏をつける」という
規定がある。このため、「ダイオキシン」を er4-e4-xin1 と音訳したとき
(一文字目の「二」は意訳だが)、「口偏＋恶(U+6076)」という新字ができてしまった
わけだ。

こういったわけで、「口偏＋恶(U+6076)」は印刷物では普通に使われているが、
Unicodeにはどこにもない。
中国語が読めたら、
http://www.wanfangdata.com.cn/qikan/periodical.articles/zgspwszz/zgsp99/zgsp9906/990628.htm
この辺が参考になると思う。

>>434
すげー、よく知ってるねー。並みの漢字ヲタクじゃないな。
個人的にはWikipedia中文版で普通に「二噁英」で見出しになってるくらいだし
中国の知識層は繁体字を好んで使うとか聞くから、噁 (U+5641)があれば
それでいいんかなって気もするが。

じっさい俺らが高坊んときに普通に使ってたろ紙の「ろ」（さんずいに戸 U+6CAA）だって
JISに入るまでエラく時間かかったしね。今は第3水準に入ってるけど

事例は違うけど、その手の話を「日本の漢字」っちゅー本でこのまえ読んだ。
この本の著者もなんか筋金入りの漢字ヲタクだった。>>434と対決させてみたい。

>>435
あったあった、さんずいに戸。

http://forum.nifty.com/fchem/log/rika/1400_main.html
ここで詳しく議論されてるね。

まあ、こういったわけで、中国で新漢字がどんどん創られてる以上、
いたちごっこなんだよね。

だから経験上、
「普通はBMPでなんとかなる」
「BMPでなんとかならない場合はBMP外までサポートしてもどうにもならない」
というのがある。

そこで ideographic description sequence の登場ですよ。

俺は中国語に興味ないし、各言語ごとに把握したいわけじゃないから、
要は各コードのisLeadByteみたいなのさえわかればいい

そして思うんだが、プログラマレベルで気にすればいいのは切れないように
文字列を繋げるとか、イテレート時にサロゲートを気にするとかそれくらい
じゃね？表示できるかどうかはOSやらライブラリの話だし。

あのう、OSやライブラリを書くのもプログラマですよ。

そういうヤツらは自分で調べてもらわんと困る。

OSやライブラリのプログラマも、切れないように
文字列を繋げるとか、イテレート時にサロゲートを気にするとかそれくらいだから
最終的にはフォントの問題では？

Extension C以降は簡体字ってVSで表す方針じゃなかったっけ?
IRGの審議途中の文書見てると「これは(収録済みの字|収録を要求されえている
別の文字)の簡体字」という理由で登録を却下されたものがいくつもあるんだけど。

> 日本で「曾→曽（常用）」になったから「甑」の旁まで略字にしちゃったのと
> 同レベル
中国では「曾→曽」は簡体字と繁体字の違いとはみなされていない。
簡化字総表にも含まれてないし繁体字を含むとされてるGB12345でも「曽」。
字形の根拠は1965年発行の印刷通用漢字字形表。当然ながら(日本では
当然じゃないかもしれないが)部首にも自動的に適用される。
日本みたいに「�焉vの第一画がまっすぐかほんのちょっと斜めに傾いてるかさえ区別して
別字とみなすような異常な慣習は中国にはない。
UnicodeのCJK統合漢字部は漢字を知らない欧米人が勝手にでっち上げたと思ってる
人が多いみたいだけど実際には中国のHCCが元になってるわけで。まあそれでは
日本人のニーズが満たせないのも確かなので原規格分離とか言い出したわけだが

失礼、中国では「曽」のまんなかを「田」に簡略化はしてなかった。
>>445は上部のソ型とハ型の違いだと思って読んでくれ

>>445
そもそも曾(曽)は常用漢字じゃない。
最近になって判例を反映して人名用漢字になった。
で、この二つは異体字の扱い。

> そもそも曾(曽)は常用漢字じゃない。
そうだった。コメント元につられた
> で、この二つは異体字の扱い。
日本ではね。

>>439
ココで深い話をしている人たちは、そのOSやライブラリーを作る人たちだと思ってみてくれ。

昨日は超漢字Vの発売日だったのに見事なまでにスルーされてますね

>>450
それ食えんのか？

OS作る人にしたって、そもそも各言語ごとの違いを吸収するためのUnicodeな
わけだろうに。
各言語を詳細に把握しないとUnicodeを扱えないんじゃ本末転倒だろう

だいたいコンピュータで文字を扱おうなんて発想自体が
恐れ多いことなんだよ。言語ってのは計算機に扱える代物じゃないんだ。
計算機はひたすら２進数で加減剰除算と分岐処理と繰り返し処理をやってれば良かったんだ

>>432
OSが縁の下で各言語の違いをがんばって吸収してくれるから
OS使うだけのプログラマは各言語を詳細に把握しなくても扱えるようになってるんだよ

これも日本人に特徴的な気がするが
何もできなくなるまでむやみやたらと話を大きくしたがる人が多すぎ
優先順位をつけて物事に当たるという概念はないんだろうか

研究者になぜ研究をするんですかと問う人もいるんだよね

>何もできなくなるまでむやみやたらと話を大きくしたがる
どういうことだか分からないんだけど。

ごちゃごちゃ言ってねーでユニコード使えようんこども
俺様がcjk書ければ他はどーでもいーんだよ、の意

俺はSJIS,EUC,JIS,Unicodeに対応する文字列クラスみたいなの作ってるけど
確か、assign,append,isalpha,islower,ischarlen,isbomくらいがそろってれば
別に困ってないけどな。重要なのは可変長の扱いと、終端0が2バイトとか、
あとはbomの読み飛ばしくらいで、文字処理ができれば検索とかは後は同一だし、
なんかそんなに難しいことあるか？

はい次

俺は困ってないよ？
なんかそんなに難しいことあるか？

あなたは無理して話に入らなくてもいいんですよ

はい次

>>457
LE-talk-jaの過去ログの展開1つ取ってもそう
「現実を見ろ」という当初の志(?)すらどっかに吹っ飛んでる

http://pc8.2ch.net/test/read.cgi/win/1153828837/932-933
もうジャストは正しい日本語とか語るな。
日本語ですらこの始末なのにどうしてマトモな外国語処理ができようか(反語

なんか話が散漫としてるが、プログラマーの俺としても、459的な
コーディング上の具体的な問題とかの話の方が楽しいな。

>>459
そういう文字列処理の仕方は一般的なのでしょうか。

C/C++の話ですが、外部ではマルチバイト文字列でデータを作成して、
ソートや検索のような内部処理をするときはワイド文字列に変換して
使うのが正統派な気がします。変換規則はlocaleのfacetに任せます。

ところでstringとwstringの相互変換ってSTLにあるのでしょうか。

Windowsのワイド文字は破綻してるからWindowsではあまり一般的でない希ガス

>>467
std::codecvtというものがある。こういう風に使うらしい。
ttp://hw001.gate01.com/eggplant/tcf/cpp/strcnv.hpp

>>468
COMなどワイド文字が強制されることもあるわけで。

wide文字はひどい環境になるとISO646だったか、7bit文字以外のサポートは
全く考えていない実装が多くて使えない。
std::basic_stringにuint32_tなんかを入れて使うほうが無難なきがする。

>>467
いや、一般的かどうかはわからんがJavaみたいにいちいち入ってくるのを
統一の文字コードにして、また戻すみたいなのがめんどくて・・
Streamに文字コード設定したりとかさ。トラブルの元だし。
WindowsはSJIでUnixはEUCのままやりたかったから。それが正しいとも
思ってないし古いやり方かもね。上みたいに、ワイドにしてstlとか使う方
が今はいいのかもとかも思う。

てか今どきみなどうやって解決してるのかよくわかんねー。stlなのかboostなのか
MFCなのかATLなのか自前なのか。まあC/C++以外はお決まりのやり方がありそう
だけど。

>>469
ありがとうございます。

実は現在、国際化に関して勉強していたところでした。
以下のページもお勧めですよ。
http://www.scl.kyoto-u.ac.jp/scl/appli/appli_manual/SUNWspro/WS6U2/ja/manuals/stdlib/user_guide/loc_io/index.htm

>>472
プラットフォームの独自APIのみ使うのも有効だそうですよ。

しかし、ロケールが不備な環境に移植するなら、std::codecvtから
派生させてエンコーディング法変換用facetを新たに定義する方法が
王道なのでしょうね。
独自の変換APIを作るのと同等の作業量ですけど、locale周りのフレ
ームワークに従うので移植性は高いと思います。

>>474 こういういいかげんな奴の相手するなよ。

お前がどの程度いいかげんじゃないやり方してるんだかもよくわからんがな

もしかして考えすぎているのかもしれないが
文脈からすれば、>>472がいいかげんで、それを>>474に忠告してなんじゃないか？
まぎらわしいけど、たしかにどっちにもとれるな。

>だから経験上、
>「普通はBMPでなんとかなる」
>「BMPでなんとかならない場合はBMP外までサポートしてもどうにもならない」
>というのがある。
一理ある。
今まではUnicode、Unicodeうるさい人でも、BMPに対応していれば文句を言われることはなかった。
でも、そろそろBMP外にも対応しないと努力が足りないと怒られる時代が来ている気がする。
# 怒られてBMP外に対応したライブラリの中の人

ライブラリはちゃんとしてなきゃまずいだろ

>>475
いやだからいった通り別に自分のやり方がいいとなんて思ってないって。
しかし、外人の作ったstlで日本語文字コード関係が全部解決なんてする気も
あんまりしないなあと思う。今のところ文字コード関係は手作業とかOSの
APIをごちゃごちゃと泥臭いことしなきゃいけないのが現実という気がするって
だけだよ。

>>475
すみません。今473で貼ったサイトをみて勉強中ですのでfacetでの
変換は実用的ではないかもしれません。C++の規格上の理想です。

できれば475さんの採用されている方法を聞かせて頂けませんか。
少しでも良いものを吸収したいので。

効率度外視で一番まともな方法は
内部UCS4、外部UTF-8だと思う

winでUCS4に変換ってMultiByteToWideでできたっけ？

できない。
UTF-16と各種マルチバイト（UTF-8含）との相互変換のみ。

実際にcodecvtを使ってマルチバイト文字列<=>ワイド文字列
の変換やってみたけど変換に失敗。

環境は
vinelinux3.2
gcc3.3.2
libstdc++3.3.2
glibc2.3.3

std::codecvt::in,outの返り値がerrorになってしまうのです。
ttp://hw001.gate01.com/eggplant/tcf/cpp/strcnv.hpp
の関数を使用しても同様でした。

mbstowcsとかwcstombsは正常に動作するのですけどね。

libstdc++がふるすぎます。そのころのは駄目です。
最新はv.6です。

んじゃUCS4無理じゃん

それだけ環境を選ぶと使えませんね。
libstdc++3.3.2は新しくはないけど、そこまで古くもありませんから。

>>483
しかもそこで無理したってOSやCOMとのやり取りでUTF-16に変換せざるを得ないので
あまり意味がない。
Windowsだけの世界なら(内部なんだから当然そうなるはずだが)おとなしくOSの流儀に
したがって他方が無難だと思うよ

DOSプロンプトだとlocale::global(locale("C"))に設定しないと
ASCII以外がプロンプトのウィンドウに出力されませんね。
locale::global(locale(""))とすると使用中のロケールが取得さ
れるのですけど(自分の環境ではJapanese_Japan.932)、これだと
何故か駄目なんです。

付け加えるとcoutだけlocale("C")に組み入れても駄目で
locale::global(locale("C"))としないとcoutにASCII以外
を出力したときにDOS窓に文字が出力されないです。

リダイレクトを使うかofstreamでファイルに出力してやる
とASCII以外も正常なのになあ。
DOS窓の問題なんでしょうかね。

何の処理系の話なのかくらい書けよ

>>491
vc8。
プロンプトから
cl -EHsc ファイル名
でコンパイル。

>>489
内部ではコードポイント固定長で扱いたいこともあるだろ。
毎回変換するのも一つの選択肢で、意味は大いにあると思う。

内部で固定長で扱いたいだけなら別にUCS4である必要もないと思うが。
むしろ合成が事実上必須のコードなんて扱いづらくて仕方ないだろ

>>485
gcc3でC++って悪夢だ。
codecvt以外にも困ること多すぎ。

>>490
VC8のバグらしい。
ttp://forums.microsoft.com/msdn-ja/ShowPost.aspx?PostID=250724&SiteID=7

次期バージョンってまさかOrcasまで待てとか?

libstdc++のL""はダミーですか？
バージョン上げたら改善するの？

>>493,4
内部のコードポイントが外部より少ないんじゃ欠損する訳だし、
UCS4には変換できないし、どうやってやるんだ？という気がするが。

Windows で UTF-16 のサロゲートペアの扱いが面倒だなと
思ったので、UTF-8 とかを API で UTF-16 に変換後に
私が勝手に定義した 4 バイト固定版 UTF-16 にさらに変換して
std::basic_string に突っ込んでます。サロゲートペア以外を 0 付加して
4 バイト化するという、Shift JIS を 2 バイト固定化して使う方法と
同じような感覚です。通常の UTF-16 への逆変換なども当然必要です。

>>495
kwsk

なるほど。そうした場合以下のデメリットが出てくるだろうけど、その辺は
どう考えてるの？
・内部外部変換で２回の変換が入るのは速度面で不利
・４バイト長はメモリ消費が多い

内部をどうしようとプログラマの自由。
もっといえばWindowsに合わせる必要もない。
以上。

>>502
今時、しかもただでさえWindows自体が計算機資源をだだ漏れのように浪費するのに、
その程度のこと気にしたってしょうがないぞ。

>>500
お前の言う4バイト固定版UTF-16とUTF-32の違いを感じない。
自前でUTF-8とUTF-32を変換するルーチンを書いたらどうかと思う。

おまいらどうせ実質BMPしか使わないから
UCS2ぶっこんどけばいいんじゃね

>>504
いや、気にしようよ
>>505
差がないから手間のかからない方にしたんだろ。それもいいんじゃねーか。
>>506
んなことない。今どきいつサロゲート文字がくるかわからんよ。OSが表示
できねーとかは知ったこっちゃないが、文字が切れるのは困るって。

500 です。メモリや速度を気にするなら ASCII 限定でしょう。英語で勝負。
リッチな文字コードを使うのをやめるべきです。ちなみに
API で UTF-16 に一度変換するようにしているのは、UTF-8 以外も
楽して変換対象にしたいからです。手抜き工事ですね

>>505 ビット範囲が同様でも、サロゲートの部分が違うでしょ。
UTF-32 は、サロゲートないんで

UCS2 では UTF-16のサロゲート領域にどんな文字が定義されてるの？

>>508
UTF-32と違うのはわかるが、だからこそなぜUTF-32を使わないのかを聞きたい。

>>510 バイト数を揃えたいだけで、それ以上の品質を求めている
わけではないというのでは、回答になっていないですか？
UTF-32 は、Windows に食わせるのに都合が良いわけでもないという
思い込みもあります

>>509
未定義

500の人はUTF-32を知らないのではないだろうか

>>506
BMPしか使わなくてもUnicodeの文字表現は可変長だから、区切り位置判定は常に必要
Unicode文字列を任意のcode point位置で分割してはいけない。

>>507
気にした結果、何ら問題ない。終わり。

515の作ったソフトを使わせられる奴に乾杯

素人だろ、ほっとけよ

UTF-32の文字集合はUCS-4のサブセットであるは理解して発言せよ。
http://www.unicode.org/unicode/reports/tr19/tr19-9.html

>>513
500 です。UTF-32 のメリットを教えてください。一応、UTF-32 については
508 で書いたんですけど。UTF-16 が使いたいけど、バイト数を
揃えたいだけなんです

>>519
サロゲートペアだけバイト数を揃えて(?) メリットあるの？

合成とか考えると>>500のやり方でも 4バイト＝1文字は保証されないし。

すべてのOSレベルでTronコードが使えるようにすれば解決？

>>520 実際にプログラム上で文字を判定したいのは ASCII の範囲だけ
だったりするので、既存のイテレータやループ構造を修正しないで
サロゲートペアを意識しないままのコードにしたいという理由で
バイト数を揃えたいということですが、それだとバグが発生するだろうと
いう指摘なのでしょうか。文字の表示や印刷は OS に任せるので
自分では意識しません(UTF-16 に戻して OS に渡します)

>>522
ASCII とくっつく合成もあるからね。U+0041 + U+0308 => U+00C4 とか。

で、合成無視するなら、サロゲート回避だけのために 32bit にするのって
そんなにメリットがあるのか？ って話。

メリットはboostやSTLなどがそのまま動作保証できるってコトだろ。
マルチワードだと既存のものにパッチを当てる方向になってしまう。

>>524 そういうことです。指摘された合成の考慮は確かに必要でしょうけど

合成はサポートしないならそれでいいかも。
サポートするのであれば、UTF-8で全て扱うのと大差ないかも。

「UTF-32 の整数値」 = 「Unicode のコードポイント」
つー、最大のメリットを捨ててまで、独自コードにこだわる理由が分からない。

独自の32bit固定長コードにしても、文字情報の取得なんかを行う場合は結局
UTF-16 か、UTF-32 に変換する必要があるわけだから、結局は
UTF-32 に変換しちゃったほうがいいと思うけどな。

GCC で生活している人は sizeof(wchar_t) == 4 でいいんだが、
Visual C++ で生活する人は sizeof(wchar_t) == 2 だからね。
独自コードであっても、素性は UTF-16 のままだから
サロゲートのことを忘れて、独自コードのまま ASCII 範囲の判定を
してます。

ユニコードって糞だね

「Unicode + UTF-8 は優雅でないのでこれを認めない」なんてのもあったな。

優雅なものがあったとしても
普及してないから駄目でしょう

>>509
サロゲート文字が定義されてるが使用禁止。
そんなのを馬鹿丁寧に厳密に解釈してUTF-16と区別しなければならないなんて

UCS-2+(合成が必要なものやBMP外のものは)PUA マジオススメ。
JIS X 0213 NLSもそういう実装だったな。
Windowsのシステムコードページは1〜2バイトDBCS←→2バイトUnicode
の変換にしか対応できないという技術的な都合もあったと思われるが。

>>519
UTF-32もお前の独自コードも32ビット固定長だが合成文字には要注意などといった利点欠点は共通だと思う。
なぜなら両者はBMP外の文字（UTF-16でサロゲートペアになる文字）の扱い以外同じに見受けられるから。
だったらたとえ内部処理であっても広く世間で知られているものを使っておいた方が後々良いと思う。

>>534
> たとえ内部処理であっても
世の中にはNEC選定IBM拡張文字とIBM拡張文字を区別したくなるかもしれないなんて
あまりありそうにもないことは過剰に心配するわりに内部コードのつもりだったものが
外で使われだすなんて実際に起きてみんな困ってることは絶対にないとか意味不明な
確信を抱いてる人が存在するんですよ。

Normalization Form Cでいいやん

>>536
互換漢字がすべて統合漢字に統一されてしまうという人名処理では致命的な欠点が
ある。なぜか正規化について語るときはみんな見て見ぬふりをするんだけど。
かと言って正規化を完全に無視すると「ふ」 U+309Aが合成されなくて不便。
JIS X 0213のレパートリをフル実装するならU+309Aを無視するわけにもいかず、
にっちもさっちもいかない。

>>536
NFCにNormalizeしても全て１コードポイント＝１文字にはならない。
相変わらず可変長

そこでJIS2004 IDEOGRAPHICS EXTENSIONとJAPANESE NON IDEOGRAPHICS
EXTENSIONですよ。合成? 何それおいしいの?

漏れはUTF-8を使い続けると決めた。

>>540
どうせ可変長ならUTF-8でいいよねえ

合成文字機構は全ての文字にアクセントや発音区別符号を加えることができる。
合成文字は、タイ文字や数学植字のエンコード・国際音声字母を使うユーザーなどには必須である。

日本語すらまともに取り扱えてないくせに本当にタイ語のテキストなんか扱うつもりなのかと。
ものごとには順序ってものがあるんだってば。

　　　　 ∧＿∧
　　　　( ´･ω･`) 　　 　∧＿∧
　　　 ／ 　　　 ＼　 　（　　　　）何言ってんだこいつ　
.＿＿|　|　　　 .|　|＿　/ 　　 　 ヽ
||＼　￣￣￣￣　　 ／ .|　　　|　|
||＼..∧＿∧　 　　(⌒＼|_＿./ ./
||.　 （ 　　　）　　　　 ~＼___＿_ノ|　　 ∧＿∧
　　/　　　ヽ　死ねよ 　　 　 ＼| 　 （　　　　）　
　　|　　　　　ヽ　　　 　　　　　　　＼/ 　　　 ヽ. 早く病院に逝ってこいよ
　　|　　　　|ヽ、二⌒) 　　　　 　　／ .|　　　|　|
　　.|　　　　ヽ　＼∧＿∧　　　 (⌒＼|_＿./　/

合成をサポートしない実装のレベルは、規格で許容されていると
思うのだが

む、スレ住人を攻撃してるように見えるとアホが荒らすから確かにまずいな
訂正

日本語すらまともに取り扱えてないくせに本当にタイ語のテキストなんか扱わせるつもりなのかと。

>>545
サロゲートも同様だね。
すべての実装が附属書Cの実装を義務付けられているわけではない。
それどころか装置がさまざまなレベルでサロゲートをサポートしていない可能性を
考慮しろとまで書かれてる

Level1にしてもぶったぎったりしないようにはするひつようあんじゃねーの

>>548
とりあえずサロゲートに関してはぶったぎる装置が存在する可能性まで
附属書Cに書かれてる。

それはサロゲートをぶったぎられた入力が渡されてくる場合にも備えろってこと?

YES

SJISを扱うプログラムはSJIS１バイト目でぶったぎられることを
考慮しなければならなかったように、

UNICODEを扱うプログラムはサロゲートペア前半でぶったぎられることを
考慮しなければならない。

世の中進んだね。

>>546
MacOS XではJIS X 0213やNFDのファイル名や合成必須のcomplex scriptも扱えてるよ。

>>552
OS丸投げならできて当然だろ。
ちなみにMac OS XもModified NFDとか称して
> みんな見て見ぬふりをする
うちの一員だな。

Mac OS Xのhfsモジュールに組み込まれているNFD変換関数はしょぼいよ。

My内部コード+関数作るくらいなら、IBMのICU使った方がいいんじゃないの?

しかしModified NFDで変換するには当然OSの内部関数を使う必要がある。
ほらUnicodeもどき俺コードの弊害が早速出てる

NFDにNormalizeするのはVFSレイヤだから変換を意識する必要は無いよ。
適当なUnicode文字列を渡せば良い。ただし、使える文字は使うファイルシステム
の能力で制限されるから、Unicodeの問題を抜きにしても上位レイヤで使える全て
の文字がそのまま使えるとは限らない。

HFS+だとUnicodeが使えるけどHFSだとMacRomanになるとかか

>>556
お前、Darwinのソースコード読んだことないだろ?

与えられた2つのパスがVFSレベルで実は同一かどうか問い合わせる方法あるの?

i-node 値で見ればいいんじゃね？

もはや文字コード関係ないな

幸い俺は最近Xcode使ってるからちょっと興味がある

「サロゲートペアを含むパスを使用しないでください」
と運用で回避

「SJISで文字化けします」「EUCでおｋ」という運用すら許容されてるから
それで十分だなマジな話

SJISで十分だなマジな話

>>565
文字化けします

Windows-31Jでも無いんだな。

>>566
CP932 を使ってください。

Unicode 5.0：言語の分裂に挑み続けるUnicodeの新バージョン
http://opentechpress.jp/developer/article.pl?sid=06/11/06/011246

C++だけど
内部的にはどういう風に持つのがベターなのかな
プラットフォームを選ばないのなら
std::wstringにUCS2ベタで入れとくのが現実的？
あるいはstd::stringにUTF-8?

std::wstring に UTF-16 を入れて、
問題を見て見ぬふりというのはどうだろうか。

見てみぬフリじゃなくて、USC2に収まらない時には例外を投げれば良いじゃん。
どうせWindowsならサードパーティのソフトが対応していないんだし。

Windowsって、UTF-16のサロゲートペア対応してないの？

>>573 対応している。

>>568
「表示」が「侮ｦ」に文字化けします。

> あるいはstd::stringにUTF-8?
Windowsだと標準ライブラリやAPIの類が一切対応してないのが厳しいな

basic_string< WCHAR > に UTF-16 で入れておくのが Windows 的な感じ

なぁ、俺が心配しすぎなだけなのかもしれないが、
近々サロゲートペアで表現できない範囲まで
日常的に使われることになったりはしないのだろうか。
そうするとやっぱり wchar_t に UCS4 を突っ込みたい。

>>578
JIS X 0213 が常用されるようになればそういう日が来るけどそういう日って来るのかな？

>>579 え？ JIS X 0213 ってサロゲートペア使っても
表現できない範囲まで定義されてるの？？知らんかった。

>>578
Vista についてくるフォントとレンダラでは合成が大々的にサポートされるようだから、
ちゃんとやろうとすると結局は CharNextW とかで区切りを調べるよりなくなるわけで。

>>578
UTF-32 = Unicode のコードポイント値だから、
UCSで文字格納しても 0x10FFFF 以降は保障されないよ。

なんでプロセッサが64ビットの時代になってまで
内部処理でサロゲートみたいなことしてなやまにゃならんのだ・・・
内部 UCS4 外部 UTF8 でいいじゃん、って思うんだが、
OS やライブラリの設計する人はそうは思わないのかな。
結局は大部分のライブラリが ASCII だけ通ればいいじゃん、って
思想で作られているからしかたないのか。

実際面を考えるとサロゲートペアに入る文字より合成の方が
まだしも広く使われるように思う。んでUCS4厨は全滅。

>>581
CharNextWはサロゲートしか考慮しない。
>>584
JIS X 0213で追加された合成文字だけだとまだまだ広く使われそうなのはないね。
むしろ2面の漢字のほうが使いでがある。
個人的にはUCS4厨に引導渡すためにもとっととAJ1-6のグリフとかIVDに追加して
ほしいんだが。日本では需要が高いんだし

サロゲートにかかるような文字として、ぱっと思いつくのは吉野家の土吉(U+20BB7)くらい。

>>585 なんでそれが UCS4 厨に引導を渡すことになるの？

>>585
サロゲートよりは広く、と言ったときに念頭に置いていたのは、Windows が対応してくれば
Combining Diacritical Marks for Symbols あたりが使われ始めるんじゃないかってこと。

丸にAとか□にAとかの潜在需要はサロゲートに入ってる文字より上じゃないかな、と。

>>587
IVSは可変長だから

>>588
NCSは(IVSと同様)規格にないものを勝手に使ってはならないことになってるけど
JIS X 0213のやる気のなさを見る限りではなし崩しだろうな。
> 丸にAとか□にAとかの潜在需要はサロゲートに入ってる文字より上じゃないかな、と。
確かにそのへんもAJ1-6には入ってたな。

メーラのエディタ部分とMIME化部分が、
サロゲートペアに対応したら、普通にそんなテキストが送られてくると思う。

今でも、手書き入力＋候補文字パレット選択を使う人からは、
JISには定義されてない文字(主に記号)、中国の漢字が使われたUTF-8のメールが来る。
# 前者はともかく、後者は誤字なんだけどね…

マルチワードとなるとソーティングとか正規表現エンジンとか全部修正になるわけだが
手が回らないから結局内部UCS4でやる事になると思う。

高水準で設計している人は考えてなくて、たいしたことないと思ってるだろうけど。

内部にUnicodeと関係ない固定長コード使うのはナンセンスって声が意外と大きいけど
AJ1xはまさにそういう実装なんだよな。
ソースが今ちょっと出せないけど確かAdobeのインド語用フォントもすべての表現形に
番号を振って、外向けにはOpenTypeでUnicodeと結びつけるという実装だったはず

> JISには定義されてない文字(主に記号)、中国の漢字が使われたUTF-8のメールが来る。
UTF-8で来るだけマシでしょ。Outlook ExpressがCP50220に変換できる限りは
Windows-31Jの機種依存文字でも平然とISO-2022-JPのような何かとして飛んでくるし。

UCS4やUTF-32って1文字4byte使うから、なんとなくメモリなどの効率が悪そうなんだよなぁ。

英語圏の人からしたらUCS2/UTF-16でも(ry
逆に俺ら漢字圏の人からしたらUTF-8でも(ry

UTF-16でも効率が悪いからってさらに効率の悪いUCS-4を使う理由にはなるまい

>>580
ごめん間違えた、サロゲートペア必要な範囲 (U+10000-U+10FFFF) だと思った。
もちろんサロゲートペアで表せる。

せっかくだから書いておくと、JIS X 0213 で BMP 外は 302 文字。
http://charset.info/sjis-2004-std.txt

>>593
AJ1x は大文字セットだからUnicodeと関係ないことは意味がある。
Unicodeで足りるのに俺コード使うのはナンセンス。

合成文字まで考えたらソーティングとかどうするんだろマジで。
RDMSのインデクスとか、
正規表現も新しい技術投入になるんでないかな。

>>598 わざわざ調べなおしてくれて有難う。
俺もレス見て「ホントカヨッ？」と思ったんだが、
JIS X 0213:2004 より新しいものではそうなってるのかなと納得してた。

>>599
合成文字考えなくても、日本語のソートは音訳しないと出来ない。
ヨーロッパだけ考えても、国ごとに違い、コードポイント順では話にならない。

とUnicode以前から難しかった。英語が簡単なのはかなり特殊な部類。

>>593
AJ1xは内部コードとはちょっと違うんじゃね？
Adobeアプリだって内部AJ1xで動いてるわけじゃないし、
あくまで補助的な位置づけでしょ。

>>598
http://charset.info/
こんなページ、というか、サイトがあったんだな。
このサイトってどういう目的で作られているのかな。

>>601
日本語のソートって結局読みベースの順序だて辞書使わないとだめって事言ってると思うのだけど
これの標準的な手順とか規約みたいなものってあるの？

それとも文字コード順だとか言ってお茶濁すしかないのかな？

>>604
手持ちの漢和辞書でも参考にしたら？

読みは持っている、あるいは持ってないので読み順はあきらめると仮定して、

JISX4061
日本語文字列照合順番
http://www.jisc.go.jp/

>>604は、「読みの辞書順」にはどんな標準があるのか問うているような・・・
英語みたいに冠詞は後に回すとかの特殊な処理は無いよね。

>>607
はいそうです
>>606
JISX4061で言うところの代表読み辞書の標準はあるのかな？あればマシンリーダブルで存在するのかな〜と言う話です。

ぎゃー、404じゃなくて604の間違いです

std::stringでマルチバイトやってる人っている？

>>610
漏れはやってるよ。
Windows で MBCS のをそのまま入れて単なるコンテナとして使ってる。

struct UTF8char{
char* buf;
}
typedef std::basic_string<UTF8char> UTF8string;
ここまで考えて

どう考えても効率悪いですありがとうございました
の結論に

俺は以下のようにして、Cのように関数のオーバーロードは無いものとして変換関数を作って使っている。
typedef char utf8_char;
typedef std::basic_string<utf8_char> utf8_string;
WINの場合には大体UNICODEビルド使うのでUTF-16,UTF-8のみの変換で何とかなる。

マルチバイト用のiterator作らないと無理かな？
class mb_iterator{
char* cur;
int charLen;
operator++(){
cur += charLen;
calcNextCharLen();
}
operator*(){
cur;
}
}
的な

>>598
> せっかくだから書いておくと、JIS X 0213 で BMP 外は 302 文字。
JIS X 0213:2004で追加された10文字のうち1文字がBMP外にあるから現在は303文字。
.txtをgrepして数えても分かると思うけど
http://charset.info/surrogate.html
にも明記してある。
>>603
公開当時はびこってた内部コードSJISのJIS X 0213実装に合わせて作られた
JIS X 0213フォントを通常のWindows XP環境で使いたくて作った。

作者降臨すか。言語学板じゃお世話になりました。

VistaからJIS2004(unicode)になりますが、
APもunicode対応になるとのこと。

そこで質問です。
・フォーム等IEから送信される文字もunicodeになりますか？
→いままではSJISで送信
・今まではメールはJISで送信してましたが、今後もJISで送ればよい？
その場合JIS2004で拡張された文字はどう対応すればよいのですか？

だめです

>>618
何がだめですか？

ネタじゃねえのかよ・・・

>>617
> ・フォーム等IEから送信される文字もunicodeになりますか？
> →いままではSJISで送信

違うよ。ブラウザはページのコードに合わせて送ってた。

iconvって不正なマルチバイト文字列にでくわして変換が中断
した場合でも出力バッファをヌル終端するのかなあ。
ttp://www.linux.or.jp/JM/html/LDP_man-pages/man3/iconv.3.html
見ても書いてないのよね。一応本家iconv1.11の実装ではヌル終端す
るけどね。

どこまで出力されたかは*outbufの値で判断できるから
ヌル終端に頼る必要はないような。
そもそもiconvがヌル終端するなんて知らなかった。

ごめん。
ヌル終端しなかった。
単に自分で出力バッファをヌルクリアしてたorz。

でも変換が完了すればヌル終端する。

変換される方がヌル終端されていたので、そのヌル文字が
出力バッファに出力されただけだった。
ヌル終端されてない文字列を入力にしたら出力の方はヌル
終端されてなかった。

死にたいorz.......。

文部科学省に手紙出してからにしろよ
ちゃんと名前も住所も書くんだぞ

愛昆布

>>626

これ俺もやった。
文字列を渡すときに気をつけないとnull終端されてない出力になってるからね。

Windows板に32bitとか128bitとか512bitとか言ってる馬鹿が湧いてて頭が痛くなってきた

>>630
そのコードの数値を ASCII の文字列で表現するということを
提案して、さらに おかしな方向に持っていくとか。ASCII の数字列を
SI/SO でサンドイッチして数字列が可変でも大丈夫ですとかも
いいかもしれないですね(すべて冗談です)

> そのコードの数値を ASCII の文字列で表現するということを
> 提案して、さらに おかしな方向に持っていくとか。
それ何てJIS X 4166?

>>632
631 です。ネタとしては、以下参照ですか？
http://www.w3.org/TR/2002/NOTE-EGIX-20021220/
631 の冗談は、すべての文字を ASCII 数字列で表現というものです。
SI/SO じゃなくて XML で表現すれば確かにいいのかもしれませんね

base64にしてみるとか

それ何てUTF-7?

文字コードによる漢字の並び方の質問があります。
例えばShift-JISって基本的に訓読み順に並んでいると思うのですが、
UTF-16の場合の漢字はどのような規則性で並んでいるのか教えてもらえないでしょうか？

>>636
SJIS は訓読み順じゃない。
第一水準は音読み順で、第二水準は部首順。
UTF-16 も部首順。

あと、各部首内はもちろん画数順。

それは統合漢字の各ブロック（拡張AとかBとか無印とか）内での話だけどな。
他に互換漢字もあるし、互換漢字ブロックに入ってる統合漢字なんてのもあるし。

互換漢字ブロックもいちおう部首順に並べようとはしている。
通し番号がほしかったらSuperCJKでも見れ
つかISO/IEC 10646の場合文字コードの値の並びには何の意味もないから
ソートにはISO/IEC 14651を使えということになってる。

>>637
音訓のうち代表的な読みの順な。

部首順にするとどんなメリットがあるの？
50音順のほうが便利そうなのに

CJKそれぞれで違う読みの字はどうすればいいのか？

そういうこと。CJK統合なのでどの国からも文句が出ない並びということで
康煕部首順が採用された。
GB 2312の第2水準も部首順だけど簡体字に合わせて作られた新しい部首分類なので
康煕部首とはかなり違う。
ハングルは韓国の並び順そのままだけど1997年に北朝鮮が国連加盟するなんて
罠まではさすがに予測できなかったんだろう。
並べ替えを要求する北朝鮮にもISO/IEC 14651が持ち出されて、以後北朝鮮は
すねてWG2に出席しなくなった

jis2004対応大変だな。。

Vistaは内部どうなってるの？cp932,utf-8,utf-16LE,Shift_JIS2004？
JIS2004対応というのだけは見たのだが、JIS2004の文字のフォントが用意されて
全てUTF32ぐらいになっていると素人としては楽なのだが。

Windows NT系に関しては昔UCS2、今UTF-16だろ。
内部はともかく表向きのAPIはそうなっている。

>>646
JIS2004 対応のフォントがあって、Unicode使ってればそれらの文字が使える。
レガシーな cp932 とかの符号化方式は変更なし、だと思った。

UTF16LEだね

cp932はAPIにももう使われなくなるはずだが。

今後はメールもunicodeがデファクトスタンダードになるのか。。

２ちゃんの文字コードを変更してほしいな
いろいろ楽しそうなのに

今メールって8ビット通していいのかね。
今でもRFCは7ビット推奨なら、メールでunicodeっていうと
base64になってしまう。

utf-7があるじゃないか。

>>647-649
ありがとう。
cp932->Shift_JIS2004じゃなくてほんとに良かった。

>>651
文字を表示したいだけなら、大抵は実体参照が使えるぞ。

JIS X 0213:2004 対応と新日本語フォント「メイリオ」について
http://www.microsoft.com/japan/windowsvista/jp_font/default.mspx

ファイル名に日本語使わないでほしいが、U+0284 がようやく正しい形になってホッ。

jis2004 oracleもweblogicも最新版しか対応してないなんて…

こりゃたいへんだ〜

メイリオも途中の版までは0x5cがバックスラッシュだったのになぁ。

丸文字フォントに見えるが、角ゴシックフォントだけなの？
せめて明朝体と等幅のバリエーション程度は用意して欲しいな。
半角円マークのグリフはバックスラッシュのほうがいいなぁ。
日本の通貨記号をバックスラッシュに変えれば、みんな幸せじゃないのか。

>>659
> 半角円マークのグリフはバックスラッシュのほうがいいなぁ。

なに言ってんの?

波ダッシュ！

ゴシックでU+8212(舒)の右下が「了」になってるのはそのままか。
もっと早い時期に気づいてれば報告して直してもらえてたかも。

そういうのはまだ直してくれるんじゃないかな。

>>652
8bit使えるようにする拡張はあるが
どうせ経路の途中でBase64エンコードされる可能性があるから
最初からBase64使ったほうが振る舞いが予測しやすい
>>653
UTF-7は非推奨。UTF-8 + Base64使うことになってる
>>663
もうVistaの企業向けはリリースされたからどう考えても無理。
Microsoftが資料を公表したのも仕様が確定したからだろ。

>>664
TCP/IP+SMTPなら8bitクリーンでいけるんだろうけど
まだどこかにUUCPとかが残っているのかもしれないね。

想定してたのは8BITMIME拡張に対応していないメールサーバ。
ネットワーク層がTCP/IPに決まってるからってからって8bit通ると決め付けるのは
行儀が悪い。qmailは8BITMIMEを使わないで8bitのメールを送っちゃうらしいけど
http://ya.maya.st/mail/qmail-violations.html#8bitmime

>>666
> 8bit通ると決め付けるのは

ちゃんとEHLOしてくださいよ。
MAILコマンドにBODY=8BITMIME付けたり。

>>667
8BITMIMEについては1行目で触れてるが。
漏れじゃなくてqmailに言ってくれ

質問があります。
CP923に含まれている文字を教えてください。第一水準、第二水準の漢字は全部含まれていると
思うのですが(あと、機種依存文字)、補助漢字と呼ばれるものは収録されているのでしょうか？？
OSはWindows2000でお願いします。

Windows2000以降では、OS内部がUnicodeになり、MSの標準フォント(MS明朝、ゴシック)などにも
補助漢字(すべて？)が収録され、補助漢字が表示、入力できるようになったと思いますが、
Windowsアプリでは、Unicodeに対応していないものもあると思いますが、
Unicode非対応アプリでどの文字種が入力・表示できないか知りたいのです。

CP932？

> CP923に含まれている文字を教えてください。

see MSDN

CP923はISO-8859-15 (Latin-9)のサブセットで漢字は入ってないだろう。

スレ違いかもしれませんが、ここで聞くことにしました。制御記号ってどれも必要なんですか？？
とりあえず、アスキーのを引っ張ってきましたが、必要ないのばっかりという気がします。
でもなんでDELだけあんなに離れてるんだろう？
1/2

16進_略語______意味
00___NUL_______NU(null)_空白
01___TC1(SOH)__SH(start of heading)_ヘディング開始
02___TC2(STX)__SX(start of text)_テキスト開始
03___TC3(ETX)__EX(end of text)_テキスト終結
04___TC4(EOT)__ET(end of transmission)_転送終了
05___TC5(ENQ)__EQ(enquiry)_問い合わせ
06___TC6(ACK)__AK(acknowledgement)_肯定応答
07\a_(BEL)_____BL(bell)_ベル
08\b_FE0(BS)___BS(backspace)_後退
09\t_FE1(HT)___HT(character tabulation)_水平タブ
0a\n_FE2(LF)___LF(line feed)_改行
0b\v_FE3(VT)___VT(line tabulation)_垂直タブ
0c\f_FE4(FF)___FF(form feed書式送り
0d\r_FE5(CR)___CR(carriage return)_復帰
0e___SO________SO(shift-out)_シフトアウト
0f___SI________SI(shift-in)_シフトイン
10___TC7(DLE)__DL(data link escape)_伝送経路拡張
11___DC1_______D1(device control one)_装置制御１
12___DC2_______D2(device control two)_装置制御２
13___DC3_______D3(device control three)_装置制御３
14___DC4_______D4(device control four)_装置制御４
15___TC8(NAK)__NK(negative acknowledgement)_否定応答
16___TC9(SYN)__SY(synchronous idle)_同期信号

2/2

17___TC10(ETB) EB(end of transmission block)_伝送ブロック終結
18___CAN_______CN(cancel)_取り消し
19___EM________EM(end of medium)_媒体終端
1a___SUB_______SB(substitute)_置換キャラクタ
1b___ESC_______EC(escape)_拡張
1c___IS4(FS)___FS(file separator)_ファイル分離キャラクタ
1d___IS3(GS)___GS(group separator)_グループ分離キャラクタ
1e___IS2(RS)___RS(recode separator)_レコード分離キャラクタ
1f___IS1(US)___US(unit separator)_ユニット分離キャラクタ
20___SP________SP(space)_間隔
7f___DEL_______DT(delete)_抹消

>>672

> でもなんでDELだけあんなに離れてるんだろう？

紙テープ時代のなごり。
紙テープは穴が開いてるところを 1 として読み取るわけなんだけど、
そのデータを削除する場合全部のビット、穴を開けていた。

それで全ビットオンがDELとなった。

昔々テレタイプというものがあってだね。
そこに書いてあるコード通りの制御を行なうのに必要だったんだよ。

もう、ほっとんどいらないと思うんだけど。

テレタイプと書いて気づいたんだけど
�@は 1 に BS して ○ すればOK。文字コードいらね。
という流れで機種依存なのだろうか？

元々そのための「上書き用丸」でしょ。

669です。
CP932でした。

SOH〜ACK　NAK SYN DLE DC1〜DC4 なんかは通信制御の
世界では普通に使われてるぞ。

あとシリアル接続の機器（磁気カードリーダなど）もこのあたりの
制御コード使って制御されてる。

こうして見ると、制御コードのうちこの一年間に関わったプロジェクトのどれでも使わなかったものは殆どないな。

>>669
http://www.microsoft.com/globaldev/reference/dbcs/932.mspx

まぁ、RS232Cとか利用することがなけりゃフツーは無縁だわな。

>>682
ありがとう、ございます。でも、漢字がないですね。
意味がわからなくなってきましたので、あきらめます。

>>684
表の 81 とか 82 とかに貼ってあるリンク辿れば漢字でてくるけど。

>>685
おわ。この表、クリックできたのですね。気づきませんでした。
ありがとうございます。

もし、自分がｍｙＡｓｃｉｉなるコード表を作って
それに準じてブラウザ付きで配布したら、技術的にどこまで通用するんでしょう？？

通用する、の定義次第じゃね？
北朝鮮では金正日の３文字が別コードに割り当てられてるらしいし。

>>674
へー、勉強になった。
制御コードにはお世話になってるけど、
さすがに紙テープの時代は知らなかった。

ここに6bit版あるよ。
http://homepages.cwi.nl/~dik/english/codes/stand.html

TCP/IP利用の通信プログラムでも制御コードを含んだデータを
送受信する分野は存在します。テレタイプも海外では現役の
ところもあるので、考慮が必要な分野は存在します

>>691
制御コードと8bitクリーンはあんまり関係ない気が。
TCP通ってても8bit目は消される運命なのか…

>>692
ＴＣＰを通る、昔からの7ビットプロトコルもある罠。

>>692
7bitすら満たさない世界があるわけですよ

http://ja.wikipedia.org/wiki/Baudot_Code

>>694
これをRS-232C→USB変換機で使ったり、TCP上で流したりしてるの?
1バイトが8ビットじゃないぐらいの世代だろうか。

>>695
シリアル伝送の世界では、転送効率を上げるために5ビットコードが使われることがある。
例えばRS-232Cでは8ビット送るには最低限スタートビットとストップビットが必要なので10ビット必要になる。
つまり、9600bpsでも秒間960バイトしか送れない。
5ビットコードを使えば、パリティをつけても8ビットで済むから同じ9600bpsでも1200バイト送れる。
#実際には、未だに75bps回線なんてのもあるから結構切実。

75bpsですか。
おいらでも300ボーのモデムでパソコン通信していた程度だよ。

# MNPとか言われるとV.42bisとか連想してしまう世代ｗ

V.42bisなんてずいぶん最近w

>>695
シリアルポートだったり、イーサネットで TCP だったりしますけど、
過去との互換性の確保が最優先な分野では現役なのですよ

稼動しているマシンや OS は、現在普通に販売されているものです。
通信先の相手側の事情でプロトコルをリッチなものに変更できないのです

いまだったらエミュレータでも速度的に充分かもねぇ。
Z80とかMC68000くらいだったら余裕でしょ。

>>700
それだとデータベースとか使うの大変です。プロトコルは貧弱でも
他の部分は現代のシステムですから

こっちも相手も現代のOSで動いてたら、わざわざ古いプロトコル使うのって
悲しいよね。
レガシーシステムの保守はやっぱ大変そうだな。

ハングル文字を入力してその文字をデータベースから検索させるサイトを
作りたいんですが、入力された文字が内部でちゃんと認識されません。
同じ文字でも一文字入力した場合と二文字以上で入力した場合で
内部で認識するバイナリデータが変わったりします。
このへんのことに詳しい方いましたら、教えてください。

「ハングル」自体に文字の意味があるよ

unicode 正規化でググるとヒント見つかるかも。

>>704
あ、そうですね。知ってます。間違えました。
>>705
正規化ではググッたことがないですね。試してみます。

http://itpro.nikkeibp.co.jp/article/OPINION/20061211/256530/?ST=win&P=2

｜実際には，JIS2004で扱えるJIS第3/第4水準の文字についてもキャラクタ・コードを
｜割り振った「シフトJIS2004」や「EUC2004」などのエンコーディングがある。
｜ただしこれらは「標準（Standard）」ではない。

またnikkeibpが半可通で出鱈目書いてるよ。
前記事はyasuoka氏に突っ込まれまくったのに
こんどもまた総攻撃を食らうかもな（藁

せめてIANAに未登録とか書けばよかったのにねー。

>>707
おぉ。その記事ためになった。ありがとう。

>>707
>Unicodeでは，2つの文字を組み合わせて1つの文字として表示するものがある。
なぜ「Unicodeでは，2つ(以上)のcode pointを組み合わせて1つのgraphemeとして
表示するものがある。」と書かないの？
文中に出て来る「文字」や「キャラクタ」が各々何を意味するか教えて下さい。

>なぜ「Unicodeでは，2つ(以上)のcode pointを組み合わせて1つのgraphemeとして
>表示するものがある。」と書かないの？
一般向けの解説記事だから。

一般向けの記事だからとか、そういう問題じゃないような。

＞「JIS2004」で追加された新しい文字の形がデフォルトになっているフォント

「追加」じゃなくて「変更」な。それ以外にも日本語おかしいけど。

＞これらのフォントが利用しているコード体系のUnicodeでは，
＞日本語と台湾語，中国語，韓国語が1つの「スクリプト」として定義されており

1つのスクリプトとして扱われているのは、
日本「語」や台湾「語」じゃなく、各国の「漢字」な。

＞UTF-8やUTF-16といったUnicodeのエンコーディング（文字コード体系）

「エンコーディング」とか「コード体系」とかの用語がグダグダ。

＞Unicode（UTF-16）では，1文字当たり2バイトの
＞キャラクタ・コードが割り当てられているが

2バイトじゃなく16ビット（で1バイト）な。

＞2バイトじゃなく16ビット（で1バイト）な。

そうかあ？

1バイト=8ビットという定義が主流だけど昔はいろいろあったらしい。
最近でもキロバイトとかメガバイトみたいな 1キロ=1000? 1024? とか混乱する要素は多いな。
HDDみたく500ギガバイトあたりになると差が激しくなってくるねぇ。

そもそもUTF-8は16bit unsigned integerの列。
それを1byte = 8bitを単位とする世界で表現する時のためにbyte orderの考え方がある。

そして一文字辺り、一つか二つの16bit unsigned integerが必要。
サロゲートペアがあるので。

＞Unicode（UTF-16）では，1文字当たり2バイトの
＞キャラクタ・コードが割り当てられているが

ここまで短い文章で、突っ込みどころが満載なのも珍しい。

>>714
> そもそもUTF-8は16bit unsigned integerの列。

ｳｶﾞｯ!
UTF-8は→UTF-16は

>>707
安岡センセイも記事書いてるぞ
http://itpro.nikkeibp.co.jp/article/COLUMN/20061211/256519/

2オクテットでいいじゃない

規格の名称からして「Universal Multiple-Octet Coded Character Set」だしな

>>717
16ビットのものを2オクテットとして扱う場合にはバイトオーダーの問題がある。
16ビットのものは16ビットの単位で扱わないと面倒かも。
16ビットでいいかというとサロゲートペアという問題が残っている。
UCSで扱う場合でも、正規化と合成文字を考えないといけない。
さらに言語タグみたいなものまであるから、手抜きせずにUnicodeを
実装するのは重労働だな。

>>719
８ビットは常に１オクテットなんだからそれはいいんじゃないの？
バイトオーダはビット幅とはまた別の問題だよ。

でもさー、本当に全部必要なのかなー。TCP/IPを前提としてもさ。
BEL,VT(垂直タブ),FF(書式送り)なんて何に使うんだよー。
DC1-4だって使ってりゃちゃんとしたそれなりの名前付いてんじゃないの？
シフトイン、シフトアウトだってそれキーボードで既に制御済みじゃん。
BELって交換機でベルが鳴って誰かが駆けつけるとはとても思えないが。
CR,LFも片方しかいらないよ。どっちでもいい。どっちかにしてくれ。

>>720

DC1-4 は使ってる場合は、ちゃんと名前付いてるよ。
ここはそのコードを使用する機器特有の機能を割り当てるための
領域なんだから。

FFなんかはプリンターの改ページコードだし ESC/P系のプリンタでは
まだまだ使用されてるだろう。

>>720
その辺を節約してなんかメリットあるの?
#残すメリットなら色々あるわけだが。

ちなみにキーボードで ctrlキー押しながらアルファベットキーを押した場合
該当するアルファベットのASCIIコードの7ビット目が反転されたコードとなる。

^C = ETX　　^Q = DC1(XON)　^S = DC3(XOFF)　^D = EOT

>>720
> バイトオーダはビット幅とはまた別の問題だよ。

UTF-16は、>>714も書いているように、
16bit unsigned integerのsequenceなので、
ビット幅が16ビットでない時にバイトオーダーを考慮する必要があります。
だから別問題じゃなくて直結しています。

扱う最小単位が16bitのCPUであれば、
バイト(=8bit)オーダーは気にする必要がありません。

UTF-16はまず16bit unsigned integerのsequenceであると
抽象的に定義されていることを理解してください。

>>724
問題を混同していて、切り分けて考えることのできないひとだね。
16bitとして扱うことのできないCPUなら問題はあるかもしれないが、
それでも機種依存的な問題で、UTFの定義とは全く関係が無い。

>>722
自分だけのコード体系作って、ＯＳもコンパイラも全部自分で作って
自分だけ速くプログラムを動かしたい。その為ならもう日本語を捨てる。
新しいアルファベットベースの自然言語も自分で全部作って、それでものを考える。
記号も追加したいのたくさんあって。だから、だから割り当て可能なのが
７ビット幅か８ビット幅なのか、気になってしょうがない。
制御コードから数字から文字まで全部８ビットなんて夢のようじゃん。
Unicodeなんてどうせ一生待ったっていいもの出来ないよ。人生は一度きり。

>>725
UTF-16 Encoding Schemeは、
Section 3.10, Unicode Encoding Schemes.で定義されているぞ。

UTF-16 Encoding Schemeというのは、
UTF-16のcode unit(16bit)を、byte sequenceとして並べる時のやり方。

寝言言っている暇があったら、
http://www.unicode.org/versions/Unicode4.0.0/ch03.pdf
でも読んでくれ。(5じゃなくてあれだが)

>>725
あんたがEncoding formとEncoding schemeを理解できてないだけじゃんw

８ビットだろうが１６ビットだろうがバイトオーダの問題は
いつもある。文字コードの規定とビットの並びは別の問題だから。
だからデータの先頭にマジックナンバーとかサンプルの数字とか
書いてもらって自分側と逆だったら、全部一律に変換しちゃえばいい。
無駄なパワーとも思うが、どっちのエンディアンがいいのかは
賛否両論でそれぞれ言い分があるらしい。
ただ無条件に並びを規則的に交換するだけだから、別に大問題と
いうわけではないよ。今までだってそうやってきたんだから。
サロゲートペアはね、あれはね、大問題。
ＤＢの１カラムからもう何かの文字集合のサブセットなんだからさ。
明日の国際会議の出席者の一覧表作ってください、と言われたらもう困っちゃう。

Unicode標準は、バイドオーダーについてBEとLEを規定している。
規格も読んでない人間が、文字コードの規定と別問題というのはおかしい。

というよりバイドオーダは問題の内に入らない、くらいのことを言いたいな。
審議するほどの内容の深みがないんだから。解決済みなんだからさ。
エンディアンなんてどっちでもいいんだよ。
ずっと前からネットワーク越しに互いにやりとりしたきてるんだから。
両方を規定しているってことは、Unicode規格としてどうでもいいってことなんだから。

はいはい

Code PointとCode Unit。みんな使い分けてる？

違いすぎて混同しようがない。

どうでもいいならむしろ規定なんかしないだろ。
実際内部コードとして使うことを前提にしていた昔のUnicodeでは規定されてなかった
(で、その結果現状の混沌がもたらされた)。

>>733
＞Unicode（UTF-16）では，1文字当たり2バイトの
なんて迷文を書ける人以外は

>>729
マジックナンバーってBOMのこといってる?
どの文字コードでやり取りするか相手と意思の疎通が取れていないと
UTF-16前提で処理をするのは無謀。
ファイル名や拡張子みたいなデータ本体とは別の部分にメタデータとして
記録しておかないと、文字コードの自動判別みたいな不完全な処理を
しないといけなくなるぞ。

流れをぶったぎって質問です

UTF-8においてのBOMというのがあるそうですが、何のためにあるんでしょうか
UTF-8でByteOrderは関係ない気がするんですが・・・

>>738
> 文字コードの自動判別みたいな不完全な処理
のため。
> UTF-8でByteOrderは関係ない
だからISO/IEC 10646ではsignatureと呼んでる。

>>738
テキストエディタみたいな文字コードの自動判別をしなきゃいけないソフトの場合、
BOMが頭に入ってると判定の精度があがる。

BOM,が入っててもISO-8859-1としての解釈もできるので、本当に
ヒューリスティックな判定をしないといけないんだよねぇ。
IEとかMozillaで文字コードのところに日本語とか西欧とかユニコードとか
設定できるのは判定する文字コードの種類を押さえて精度を高めるため。

>>739
>>740
なるほど。ありがとうございます

Windowsのメモ帳もUTF-8で保存するとBOM付けるみたいですね

MIMEならcharset情報をヘッダで表現できるので、きちんと設定された
メーラであれば大丈夫。
しかし、SPAM送信プログラムみたいなMIMEに準拠する意思の
ないような実装の場合、Subjectもメール本文にもcharset指定なしで
CP932とかISO-8859-xとか8bitのまま送ってくる。
日本語のスパムでもメーラによっては文字化けして読めないのは
そのせい。

> SPAM送信プログラム
どうせならRFC 3514対応してくれ、とふと思った。

>>741
BOMなしのUTF-8は正式な名称ではないがUTF-8Nという風に呼ばれることがある。
単純にUTF-8といった場合にはBOMありもなしも含まれる。

悪意がなくてもバルクメーラーの実装は結構いいかげん。
Dateフィールドがなくて1970/01/01扱いされたり、2035年とか
未来からのメールとか平気で送ってくる。

>>738
標準では、「必須でもなければ、推奨もしてないが、標準に適合しないわけではない。」
という表現。あなたの言う通りbyte order signagureとしては意味ないが、>>739>>740のため。

>>744
BOM付きのUTF-8を指す略称が欲しいな。UTF-8Bとか。

今は分からないが、UnicodeとISO10646でBOMにあたるコードの扱いが
違ってなかったっけ?
UnicodeだとBOMでISO10646だとZERO-WIDTH NON-BREAKING SPACE。

UTF-8Y ってのがあるみたいだが、あんまりメジャーじゃないみたい。

スパムメールがへんてこなのはフィルタ対策だと思うがどうか。
メールチェッカ作ったときに業者の創意工夫が見れておもろかった。

>>748
U+FEFFをBOMと解釈すべきかzwnbspと解釈すべきかは細かく定められてる

先頭にきたときだけBOMとして扱って、途中にでたときはZWNBSP?
たまたま先頭に来たZWNBSPとの区別が出来ないのは欠陥だよな。
ZWNBSPを先頭(BOM)以外には使えないようにするしかないのか。

>>749
なんで Y なのかがさっぱりわからん。

Y/N

違う違う。先頭データって言っても１２３４Ｈって２バイト分書いてあるだけ。
そんなの見たって文字コードの種類なんてわかるわけない。
インテルのＣＰＵはこれが、３４，１２にバイト毎に反転される。
複数バイトの場合にはいつもこうなる。この順番がバイトオーダ。
インテルのＣＰＵが４ビットＣＰＵの頃からずっとこんな調子。
１２３４Ｈに見えたら変換の必要なしということ。
Ｓ−ＪＩＳ同士だろうがＥＵＣ同士だろうが、とにかくエンディアンが
違うとこうなっちゃう。１６ビットコードだからとか、Unicodeとか
全く関係ない。文字コードの話と全く関係ないことだからさ。

>>755
えーとオクテットで表現する形式としてのBOMではなくて、
UTF-7/8/16LE/16BE/32などのUnicodeとISO10646において
コードポイントとしてのU+FEFFをどう扱うかって話。

そりゃもう規格名とバージョンの番号を書くくらいしか思いつかない。
つーか、バイトオーダとかエンディアンとかの単語が出てくるあたり
から完全に変な感じだったよ。
多分、一言でうまく切り分けられる表現そのものが無いとみた。
だって規格自体ががあやふやで、だから何度も作り直してるんだから。
それがちゃんと決まってるなら、簡潔に今それを言えるはず。

>>757
Unicodeにバージョンがある時点でもう無理があるんだけど。
単にUTF-8と書いてもオクテットで表現する形式であって
Unicodeのどのバージョンですよ。みたいなことは分からんからね。
BOMとかXMLのバージョン表記みたいに先頭にバージョンを表現する
制御コードを書くぐらいしかないかもなぁ。

基本的に互換性を保っているものとして、処理するプログラムを開発した
時点における最新の規格に順ずる物とするのが現実的な回答か。

RFCでも後からでてきた拡張規格とかに対応してるかどうかは
問い合わせないとわからんことが多いしな。

TCPとかIPとかMIMEはversionがヘッダに書いてあるだろ。

>>759
MIMEヘッダでcharset=UTF-8って書いてあっても、どのUnicode規格に対応するかは
わからんよね。
区別する必要があるならUnicodeの中で制御コード割り振って対処するしかないんじゃない?

UTF-8にバージョン番号を付けていないのは意図的

えっと・・・
辻希美が「功名が辻+（'）」を見て、どう思ってるのかな？
神奈川県逗子市の人にも聞いてみたい。
そんなことより、佐藤琢+（'）磨についてYahooで検索しよっかなっと。
ついでに、辰良丈+(')一郎についても・・・これはやめておこう。

もう、みんないろいろいってるが、これですべて解決

��

えい

之繞がつく漢字は全て1点に統一して、
2点之繞にしたい時は後ろにU+300(COMBINING GRAVE ACCENT)を付ける事にしよう。
例:２点之繞の辻→U+8FBB U+300

1文字1コード
こんなにもシンプルな事が何故できない

>>764のようなアホなことを思いつく人がこれ上出ないように、
CJK用のVariation Selectorをさっさと何とかしてほしい・・・

パとﾊﾟとか1文字1コードじゃないものがソースだったり
変換先だったりするのでなかなか出来ない。
日本語以外の言語でどうなってるかは本当調べるのも大変

それ以前に「何を1文字とするか」で合意するのが困難。

`ま゛'

>>769
それが認められたら画面にレンダリングする際に合成文字として表示しないと
いけないんだよね……
それをさらに右から左に表示したり……

>>762
> 辻希美が「功名が辻+（'）」を見て、どう思ってるのかな？
Vistaなので脳内JIS90レンダリングしないと意味不明です。
> ついでに、辰良丈+(')一郎についても・・・これはやめておこう。
それは別区点
>>770
COMBINING KATAKANA-HIRAGANA VOICED SOUND MARKだったら
その通りだけど>>769のはCOMBININGじゃないほうだから合成「してはいけない」

>>766
もうレジストリはできてるから後はやる気の問題。
Adobeには期待してるんだけどねえ

Unicode5.0になって楔形文字は入ったがエジプト聖刻文字が入らなかったのはちょっと残念。
でもこの辺全部サロゲートごりごりの領域だからアプリのほーが面倒だ（死

もはやギャグの領域だな
そのうちナメック語とか
ニャントロ星人のドゴン語とか入りそうだ

>>774
スタートレックのクリンゴン語はISO639言語コードに正式登録されてるぞ。
Unicodeにはいまのところ入ったりはしないだろうが、TRONは
文字として識別されるものならなんでも取り込むみたいだからなぁｗ

ttp://www.rikai.com/perl/LangMediator.En.pl?a=2004080445

Klingon文字は正式に却下されとる。
ttp://www.unicode.org/consortium/utc-minutes/UTC-087-200105.html

まぁISOで正式登録されたものは好きだろうが嫌いだろうが
実装しないといけない人もいるだろうし、大変ですね。

アプリでサロゲートに対応するのそこまで大変じゃないでしょ。たいていの場合は。

ここにいる人の中には大変な場合があるんでしょう。
たいていは通じませんよ。

たいていは通じるだろ。上位サロゲートと下位サロゲートでちょんぎんなきゃいいだけ。
これだけのこと。

i18n関係まともにやっているともっともっと大変な処理はたんまりありますぜ。
サロゲートなんかで大変と言っとると・・・

テキスト入力ボックスなんて考えたくもない

ttp://www.unicode.org/charts/PDF/UF900.pdf
U+FA20(草冠に龝)がU+8612(草冠に穐)と等価なのは何でだろう?
亀と龜なんて全然字形違うのに。

字形と言われても困るんだが。
同じ系統に属する字だから等価と見做すcollationがあっても何の不思議もない。

右から左への表示って、通常通りキャレットの位置計算から表示まで　ほとんどを左から右に表示するよう実装して、
何気にOSか何かのAPIに用意されているだろう、座標系を設定する関数使って、反転させたら、
よかったりして。

語学の教科書なんかでは、
行の途中の単語だけ逆にしなければいけないケースがあるんですよ。

>>785
フォントも左右反転されてな

U+FA11(立崎)とU+FA14(欅の略字)は崎や欅と等価とされてなくて、
統合漢字ブロックに等価な字が無い為「互換漢字ブロックにあるけど統合漢字とみなす字」とされてるわけだが。
何でU+FA20は違うんだろ?

Unicodeに一貫性を求めちゃダメです

WindowsXP SP2 の話ですが、
IMultiLanguage2::DetectInputCodepage() に Shift_JIS な
http://www.google.co.jp/ を GET したものを与えたら、
Shift_JIS とは全然関係ない CodePage として判定されてしまいました

これでは使えないので、Shift_JIS 等の一部の CodePage の判定は自前で
実装して特別扱いして回避しました

>>788
いい同値関係を定義できたら、公表してください。
JISにある文字だけでもかなり有意義だと思います。

>>790
googleはUTF-8ですけど。。。

>>791
97JISの規格票はわりと気合が入ってる。
過去の規格との互換性のために妥協せざるを得なかったところもあるけど

>>792
それは思い込みかと。User-Agent に応じて動作が変化するという認識です

文字コードの自動認識は単純なロジックベースだとつらいかもな。
文字コード毎に出現する可能性があるか、ないかのビットマップでも
共通するコードしか出てこない場合は区別難しい。
ある程度長いソースで単語の辞書とか文字の出現頻度の統計とか
組み合わせればなんとかなるけど、短い文書はつらい。
テキストエディタで2文字だけ入力して保存して読み込んでみるとわかると思う。

DetectInputCodepageはIEの判定処理そのものなんだから何かトチってるんだろ

>>796
試しに Web 検索してみたら、これでコード判定出来ますと
サンプルを掲載しているサイトが結構ヒットしました

きっと試したファイル等が処理にやさしいものだったのでしょうね
(試したとは書いてなかったりしますが)

Webに落ちてるサンプルって明らかに試してないだろお前ってもの結構あるよ
たとえば
http://www.wac-jp.com/programmers/win32/Probe_IsUserAnAdmin.html
> // Win2000 Pro : 管理者, 制限ユーザー で正常に動作
> FUNC_ISUSERANADMIN func = (FUNC_ISUSERANADMIN)module.GetProcAddress(_T("IsUserAnAdmin"));
Win2kのIsUserAnAdminは名前でエクスポートされてねーよ

>>798
駄目サンプル晒しsageは基本的にウザイのだが、
せめて文字コード関連のサンプルを挙げてくれよん。

>>793
互換性妥協無し差分規則って公開している人いるのかね?
俺は一度マイルールを作りかけたことあるけど、量が多すぎて挫折した。
統一された基準を作り出すのは本当に大変。

>>787
それだよ。俺もフォントまで反転されそうな気がするけど、ひょっとして、フォントとかだけは、普通に
表示されるオプションとかあるのかもしれないと意味で、最後に「よかったりして」って付け加えた。

それだよw

どれだよ

>>799
6.3.3だけ見て残りの部分や適用除外(規定)は見なかったふりをする

>>803
それだと「王」と「壬」まで包摂しちゃうことになるぞ。

ああ〜もぅーややこしすぎ

口ロ□
。oOｏＯ○

適用除外のうち「王・壬」だけを残して他を無視すりゃOKじゃね？

「王・壬」以外は大丈夫っぽい。つーかこんな罠がのっけからあるとは思わなかったorz

>>808
他にも包摂規準 64 (且/旦)、70 (己/巳)、124 (犬/大) あたりが
「単独字では別字だけど、部分字体で入れ換わるのは当たり前」
な文字。他にも 69,77-78,83,91 のようなマニアックなのはあるけど
この3つは常用される。

特に注意を要するのが包摂規準100 (東/柬)。単独字では別字、
部分字体では基本的に包摂だけど、棟(むね)/楝(おうち)は別字、
鶇/鶫はうっかり両方とも入れてしまったので包摂分離。
X 0213 で新たに包摂分離になったのが錬と練(常用漢字表の
康煕別掲字体)だけど、金へんはU+932C/U+934AとUROで区別
できるのに対し、{糸柬} はU+7DF4/U+FA57と互換漢字を要し、
扱いに差がある。

>>809
> 他にも包摂規準 64 (且/旦)、70 (己/巳)、124 (犬/大) あたりが
なんでそれらの単独字は適用除外(規定)に入ってないんだ?
王/壬がなければ「単独字には適用できない」と解釈できたんだが…。
包摂規準 1 には3つ目の部分字体があることと関係してるのか?

>>810
> なんでそれらの単独字は適用除外(規定)に入ってないんだ?

むしろ王壬が載っているのがバグと考えるべきかも。

基本は
| 6.6.3 漢字の字体の包摂規準
| b) 包摂規準は，他のいずれかの漢字までを包摂するような適用を行ってはならない。
があるので、リストアップは無しでも問題ないはず。

でもそれだとあまりに不親切なので、JIS が一貫性無く収録してしまった
包摂字体に関してはきちんと情報提供しようという意図があるのでは?
棟諫鶇が載ってて楝諌鶇が載ってないのは載せなくても分かるからだろう
し、一方、初版に載っていなかった「仭」が正誤票で追加されているのは
必要があると判断されたからににちがいない。

少なくともリストで包摂除外を網羅的に規定していると判断してはならないのは
確か。単独字以外にも「任≠�j」とかあるわけで、こういうJIS 外字との
別字衝突は調べきれない。
だから 6.6.1 に「また，ここで規定する包摂規準を部分字体として演繹的に
適用することによって，新たな漢字字体を作り上げてはならない。」と書いて
済ませているわけで、実装者にある程度の文字の常識を要請している。

これを最初に読んだ時は「工業規格の規定がこれでいいのか」と思ったけど、
今は仕方ないと思っている。そこまで規定できるための情報を集めようと
思ったら、今になっても規格ができてないだろうから。

> 単独字以外にも「任≠�j」とかあるわけで、こういうJIS 外字との
> 別字衝突は調べきれない。
包摂規準はJIS外字との衝突はあまり考慮していないと思われ
JIS X 0212と比べてさえこれだけ類型異字の候補が出てくるし。
http://wakaba-web.hp.infoseek.co.jp/0212-0213/jisx0212-0213.ja.html

そもそもここでの最初のリクエストが
> JISにある文字だけでも
だったからそのへんは気にしてなかった。どうしても欲が出てくるんだろうけど

なんか、扱える文字増えたけどさ、合成文字だの左から右に読む文字だの、色々面倒なことの方がたくさん増えたな。
もう、なんたらJISの方が楽じゃねぇ？？まぁ、MicrosfotのMS932への文字の追加が止まってるのが痛いけど。

KISSの法則

あんまり（というかほとんど）文字コードについて詳しくないんですが、
>>804-あたりからの問題について意識ししないでシステムを作ったとすると
具体的にどのような問題が起こりえるのでしょうか？

>>815
フォントの実装でもしない限りプログラマにとってはあまり関係ない。
漢字ヲタクが気にするような問題

>>813
いまどきのプログラミング言語はふつー内部Unicodeなので変換の手間が増えるだけで
何もうれしくない

>>817
そうだけど、自前で、表示、入力しようと思ったら手間がかかる。合成だのなんだの。

ペイントソフトの文字の入力描画とかを作るのは大変ってことか

>>816
そうですか。ありがとうございました

文字コードのエンコーディングを自動判定するツール/ライブラリで
日本語以外も判定できるのって何がお勧め?
いま、とりあえずiconvでShift_JIS,WINDOWS-31J,EUC-JPからUTF-8への変換でエラーが
でるかどうかの情報とNKFでのguessとEncaでの判定とMozillaベースのCharGuessってライブラリ
での判定をまとめてみてるんだけど、まだ情報としてたりない気がするんだよね。
windows-1252のあたりが微妙な結果。
完璧な自動判定は無理だと思うのでなるべく多くのアルゴリズムで判定させたいんだけど
何かいいものあるかな?

>>821
MLang( IE で使われている文字コード処理エンジン )は、どう？
そういえば、テンプレに MLang が入っとらんね。

>>821
ありがとうございます。
MLang試してみます。
ファイルが置いてあるのはLinuxなのですが、Sambaで共有して
Windowsから判定させてみますね。

>>822
すいませんアンカー間違えました。

Windows-1252で0x81が未定義なのはやっぱりShift_JISとの判別精度を
上げるためなんだろうか

>>816
サーバサイドの場合、ブラウザからの入力文字がシステム内部で化ける可能性があるから関係してくる。

画面、DBを含めシステム全体で文字をUNICODEで扱っていれば問題ないが、一部でも文字変換をしていた場合、化けたり、文字チェックや文字数チェックで誤作動する可能性がでてくるでしょ。

だから、一概に関係無い話とは言い切れないのでは？

n-gramやるにはサンプルデータ用意するのが面倒なので
手軽にバイト単位のヒストグラムを作ってモデルとの差分を
積算するプログラムを書いてみた。

……なぜWindowsのシステムファイルとCygwinのバイナリを区別できる?
テキストでもそれなりに判別できそうな予感。

Unicode の文字列から「一文字ずつ」切り出す処理って、どうやったらいいんでしょう。
まあ素朴に、 "一文字ずつ" -> '一' '文' '字' 'ず' 'つ' みたいな。
Unicode の場合、例えば「ず」が「す+濁点」に分解されている場合があって、
面倒なようですが。

つきつめていくと「『一文字』って何?」ということにもなるのかな...
まとにかく、こういう目的に適したライブラリとかってありますか?

‏一文字‎ずつ‌?

‏ICUとかで正規化して自分が考える一文字で‎正規表現マッチさせればいいんじゃない?
制‌御‌文‌字‌と‌か‌は‌消さないと駄目かもねぇ。

>>830
こういうの対応するのめんどくせーよな。
単語で検索してもマッチしないし^^;
NGWordもうまく動いてくれない……

>>826
いや、>>804-の問題はそれとはぜんぜん関係ない。
まさに「複数の問題を混同しがちな〜」というやつだな

>>828
Unicodeでは一般的に文字と認識されている物をgraphemeと呼ぶ。
UAX #29: Text Boundaries
http://www.unicode.org/reports/tr29/
*まともな*Unicodeライブラリなら文字列を文字(grapheme cluster)に分割する
機能は必ずある。ICUで言うならBoundary Analysisがそれ
http://icu.sourceforge.net/userguide/boundaryAnalysis.html

830を「制御」で検索くらい試して欲しかったところ。
SETTING.TXTにBBS_UNICODE=passってなってると
ユニコード使えるんだねぇ。

文字を分割して、また結合したら別のものになる可能性があるから面倒だよなぁ。

ZERO WIDTHとかフィッシングに最適^^;

文字コードに関して誤った情報を掲載しているPDFファイルってインターネット上にありますか？

五万とあるだろ

よかったらURL教えてください？

なぜにPDF限定?

なぜに「誤った」情報？

【ネガティブ派遣根性チェック】

3つ以上、思い当たる点があればアナタの性格はひん曲がっており、ネガティブ負け組人生を歩んでいます。

□派遣先の人事権のある社員の意見はたとえ間違っていてもマンセーする
□派遣先から「いつまでもここで仕事してくださいね(安い金でｗ)」と言われている
□自社に仕事を持ち帰れるように言われるとムカつく
□自社で仕事なんてできるわけがない
□派遣労働の問題点の話題が出ると感情剥き出しにする
□派遣労働の問題を指摘する人は嫌いだ
□派遣先には仕事だけでなく自分のプライベートについても指示して欲しい
□自分の月額金額を知らない
□派遣先社員より自分の生涯収入が低いのは当然だ
□派遣先に尻尾を振り、いつまでも派遣を続けることが大切だ

森山さんとこの掲示板にも同じような質問が……

今WindowsMobile5.0で開発をしてるんですが、IMultiLanguage2
インターフェイスが作成できない(E_NOINTERFACE)んです。
IMultiLanguage2::DetectInputCodepageで読み取ったchar配列の
文字コードの判定をやりたいんですけど、
何かこれに代わる方法はありませんか？
無印の方は変換だけで、この関数は使えないんです。

IMLangConvertCharsetの初期化時にMLCONVCHARF_AUTODETECTを
つければ良さそうな気がしていろいろ試したんですがうまく動きません。
よろしくお願いします。

nkf

US-ASCIIかどうかの判定で0x20-0x7eという範囲指定じゃ駄目なんだな。
うぅISO646とか生まれる前からの呪いがまだ続いているよ……
ISO-8859系を前提にいれても無理やり入ってくるシフトJIS……
0x5cと0x7eは外しておいたほうが安全だな。

多言語の文字コードを調べようと思ったらStarDictというのを見つけた。
文字コードというか、辞書のソフトなんだがフリーで使える辞書の数がやたらと多い。
出現頻度とかの統計情報としては使えないが、Word-listの作成ソースとしては使える。

>>844
> US-ASCIIかどうかの判定で0x20-0x7eという範囲指定じゃ駄目なんだな。

どんだけずぼらなんだw

Unicode文字列の特定のキーワードの強調表示って本来どうあるべきかな？？
例えば、キーワードがaaaaとして、aaaaウムラウトの文字列を強調表示とか
で文字列を検索するときaaaaとウムラウトで分断すべきかな？？
つまり、表示上もaaaaとウムラウトで分断して表示すべきなかな？ややこしいな。

>>847
* あいまい検索とみなして、aaaaウムラウト、まで強調する
* 完全一致とみなして、全く強調しない
の二択だと思う。
「aaaaウムラウト」の「aaaa」だけ強調っていうのは、合成文字だって意識すると自然だけど、
ユーザ的には「aウムラウト」で「一文字」でしょ。

置換処理のような機械的なものと違って、強調表示の場合は
ユーザーが文字として認識する物を対象にするのが自然だと思う。
a+ウムラウトをaと見なすかどうかをオプションとしてユーザに選択させるのがいいんじゃないかな。
ただ、曖昧検索はどこまで曖昧かが難しいところもあるな。
「スーパーマン」が「ｽ-ﾊﾟ-ﾏﾝ」にマッチするかとか。
「ま゜」とか「み゛」とかやめてくれｗ

847です。
>>848,>>849ありがとうございます。いわいる前にもでてた、書記素(grapheme)のことですね。
今は単純な文字コードをマッチングしてるだけですが、完全一致するとなると、書記素を分割しないようにアルゴリズム
変えなきゃいけなさそうですね。うーん。あいまい検索にしてもいろいろ面倒そうですね。

Ideographic Variation Database submission (AdobeJapan1)キター!!
http://www.unicode.org/ivd/pri/pri98/index.html

これでAJ16の漢字グリフはK-JISからの3文字と電算写植用外字からの4文字を除いて
すべてUnicodeのプレーンテキストで表現できるようになる見込み

あれ？じゃあ包摂基準って結局どうなるわけ？

>>853
VSを付けない場合は従来通り字体は保証されない。
JIS90かJIS2004かわからないどころかGB18030の字体が出る可能性すらある。
もちろんフォントが対応してないとVSを付けても字体は保証されないんだけど
Unicodeの仕様として保証されないのとは問題のレイヤが違う。

あとJIS X 0208/0213にはIdeographic Variation Selectorなんて定義されてないし
半角カナの領域でもつぶさないと追加も不可能なのでJISの包摂規準には関係ない。
Unicodeに移行してかつサロゲートと結合文字に対応している場合にのみ
恩恵が受けられる。
もうMODIFIER LETTER EXTRA-HIGH EXTRA-LOW CONTOUR TONE BARなんか
誰も使ってねーよ、みたいな言い訳はできないぞ。

素晴らしいかも。
あとはAdobe-Japan1-6のフォントがもっと一般に出回れば・・・
ヒラギノはどうなるんだろ。MSのメイリオは絶望的？

>>856
ヒラギノはLeopardでAdobe Japan1-5NとかいうAdobe Japan1-5CMAPをJIS2004対応に
書き換えたものに対応するかも。
http://www.fontworks.com/new/news/2007/070205.html
http://www.tcp-net.ad.jp/danbo/page2007/index.html
VSにまで対応するかどうかは今のところ不明。

これ、たとえば「骨」(U+9AA8)に対しても、
U+9AA8 U+E0100 = CID+2062
という定義がされるわけね。

文書全体で確実に日本語の書体が選ばれるように
するには、やたらめったらU+E0100を挟みまくるように
なるのだろうか。

そういう目的なら言語タグのほうでしょう。こっちは実装される見込みがまったくなさそうだけど

小塚明朝と小塚ゴシックがAcrobatReaderには付いてくるけど・・・

>>860
ProじゃなくてStdじゃなかった?

Adobe Readerの日本語フォントパックには
AJ1-6フル実装の小塚明朝Pro VI-Rが付いてる。

それはさておき、公開レビューの締め切りが迫ってるので
万が一間違いとか見つけた人は速やかに報告すべし。
http://www.unicode.org/reporting.html
つーか去年の12月15日から公開レビューやってたらしいのに
ぐぐってもunicode.org内のサイトしかヒットしないわけだが、
何で日本人は決まるときには何も言わないくせに施行間近になってから急に
騒ぎ出しますか? JIS2004とかCJK統合漢字とかPSE法とか…

決めることはお上のやることだと思ってるからじゃない?

日本人のメンタリティの中ではMSも「お上」に含まれてる気がする

上といえば政財界のことだろ。当然MSも含まれる。

指定の仕方を教えてもらえないかな。
あるいはレファレンスのポインタでも。
（unicode "variation sector"だとgoogleで一つも当たらないんで）

>>851のpdfを見ると、9AA8 骨にはvariationの指定がない。
なくても、>>858で言ってるように
U+9AA8 U+E0100で、CID 2062（日本では普通の骨）が出るってこと？

utf16BEのbyte列だと
「9AA80E0100」となっているものを処理できればいいのかな？

見当違いなことを聞いていたら申し訳ないです。

ごめん。検索wordを間違えてた。

>>866
> >>851のpdfを見ると、9AA8 骨にはvariationの指定がない。
partial chartsのほう見てない? complete chartsにはvariationが1つしかなくても
ちゃんと載ってるはず(今確認した)。さらに念を押しておくと文字の下にあるVS17-2062は
VS17を付けるとCID+2062の字体になるという意味。他の字体が存在する必要はない。
sequences.txt見てもちゃんと
> 9AA8 E0100; Adobe-Japan1; CID+2062
って行があるし。
将来異体字が追加されるかもしれないし>>854で書いたようにvariationなしは
明確に意味が違うので現在字体が1つしかなくてもvariationの定義は必要。
> utf16BEのbyte列だと
> 「9AA80E0100」となっているものを処理できればいいのかな？
U+E0100はSSPの文字です。ちゃんとUTF-16のコードポイント計算してください。
ドラフト段階で叩かれまくって放棄されたUCS-2Eじゃあるまいし
http://slashdot.jp/~yasuoka/journal/387747

繝ッ繧コ縺輔ｓ莉穂コ九ｄ繧√ｋ繧薙〒縺吶°(>_<)

↑のような文字化けを直したいのですが、どうやって直したらいいのでしょうか？

>>869
エンコーディングを適切に設定する。
つーか、PC初心者板辺りで聞いたら?
もしあんたがプログラミングにおいて困っているのなら、何故そのような文字化けが発生したのか背景から説明しろ。
#あ、それでもやっぱりスレ違いか。

> K-JISからの3文字と電算写植用外字からの4文字
ちなみにこれらはExtension CかDに追加する予定らしい。
http://www.cse.cuhk.edu.hk/~irg/irg/irg27/IRGN1256.pdf

先生質問。
CJK Ideographのvariationには、なぜVS1〜VS16 (U+FE00?U+FE0F)
を使わず、SSPなんぞにあるVS17〜を使うことになっているの？

・BMPにあるVSの奪い合いになることをおそれて「みんな平等にSSP」にした。
・Mongolian専用のVSがあるように、VS17〜240はHan専用にしたかった。

うーむ。

> ・BMPにあるVSの奪い合いになることをおそれて「みんな平等にSSP」にした。
これってBMPのVSをCJKVで取り合って大ゲンカになるってことかな？
だったら少なくとも、CJKVそれぞれで何らかの代表的な字体1種は平等に
VS1〜最大でVS4までに格納、それ以降は早いもの順か抽選、ってのでも
良かったのでは・・・

だからそういうことはUTS#37のレビュー期間中に言えと。
つーか単なる想像なので本当にそういう理由なのかどうかも定かではない

【XBOX360】Grand Theft Auto�W総合スレ1【GTA】
名前： なまえをいれてください
E-mail： sage
内容：
2007年10月16日発売

XBOX360、PS3の両ハードで同時発売。

※尚、Xbox360版ではPS3にない追加シナリオがXbox Live経由で
独占供給されることが明らかになっている

開発：Rockstar Games

2007年3月1日より公式サイトにてトレーラーのカウントダウンが開始され、
米国時間の3月29日に公開予定


公式サイト
ttp://www.rockstargames.com/IV/

通販で予約受付中
ttp://item.rakuten.co.jp/gdex/119-10148/

ISO/IEC 10646 Amd.4からついに実装水準1と2が削除されるらしい。
Unicodeは最初から実装水準3のみを前提にしてたから今さらといえば今さらなんだが

> ISO/IEC 10646 Amd.4
ISO/IEC 10646:2003 Amd.4ね

>・BMPにあるVSの奪い合いになることをおそれて「みんな平等にSSP」にした。
どうせ字体気にしてVSが必要なのは日本くらいでしょう。

>>879
実はそう思うけどね
タテマエというものがあるし

ttp://www.unicode.org/ivd/pri/pri98/pri98-partialcharts.pdf
これ見たけど「囀」の拡張新字体の「口転」とか手書き等でよく使われる「曜」の略字「日玉」は
字形が大きく違うのに「囀」や「曜」と包摂扱いにして「囀」や「曜」+異体字セレクタで表す事にしちゃうんだね。

>>881
Extension Cに中国が提案した簡体字のいくつかは繁体字が収録済みという理由で
却下されてるからそういうものかも(BMPで簡体字が分離されてるのはあくまで
原規格分離のための例外扱いってことで)。

近年発見、命名された104番以降の元素を表す中国での漢字は
繁体字は既にある統合漢字の無印、拡張Aと衝突したり(「金盧」「金麥」)、
そうでない字(「金杜」など)は拡張Bに追加されて全て使えるようになった。
が、これらの簡体字は画像とかで良く見るがコードは定義されておらず拡張Cにも追加されないみたいだから
これらも>>882に書いてある通り繁体字と包摂として区別したい場合は異体字セレクタを使えという事なんだね。

他にVSで表す包摂扱いの字体差が大きい異体字には
何でよく見るのにJIS X 0213にも拡張Bにも無いんだろうと思ってた「撥」の拡張新字体なんかもあった。
「痙」の拡張新字体もあるがこれは中国簡体字のU+75C9に包摂するべきでは?「径」は中国の簡体字(旁がスの下にエ)と包摂されてるし。
「門」の手書きでよく使われる略字もあるが、これも「門」よりも中国簡体字のU+95E8のほうが近いからそっちの方が良いと思う。
U+9C75(魚箴)は強烈。いくら何でも違いすぎる。(魚針)
ひょっとしたら後で実は別字だったとか日本では異体字だが中国では別字とかになるかも知れんぞ。

Adobe-Japan1だから日本で異体字かどうかが基準なんだろ。
どう考えてもabstract shapeが違うものまでVSで表していいのかって気はするけど

ちなみにUnicode MLがAdobe-Japan1のsubmissionに関してプチ盛り上がってる

VSを省略されたとき日本のフォントで表示される可能性が高い方がたぶんありがたいし

UnicodeのMLで広大の人が主張していることは正しいんだけどさ、
JIS X 0213ソースの互換漢字のラウンドトリップが保証されないのは
UTS #37の問題っていうより、ああまた例の古傷がって感じだよな。

MLで言えよ

MLで言おうとしたら直メールで返信になってしまったorz
なんでUnicode MLのメールはReply-Toが付いてないんじゃー
>>888
UTS #37はむしろ問題解決の手がかりになると思う
IVSで表せば正規化しても消えないということだから。
レガシーな環境(現行の環境ほぼすべてがそうだけど)だと字体が反映されないとか
Unicodeのdefault ignorableやサロゲートをまじめに実装していないと
VSがゴミとして表示される可能性があるって問題はあるけど。

> なんでUnicode MLのメールはReply-Toが付いてないんじゃー

そんなもの付けているやつはばかです

>>890
せっかく公開するつもりで書いたんならMLにもポストし直せば？
「あなたは互換漢字をIVSに置き換えるのを禁止しろと主張しているが、
むしろ互換漢字のままのほうが危険だぜ」とでも書いたの？

# いらっしゃいませ実装依存の世界へようこそ！

>>891
MLがデフォルトで付けるReply-Toがないって話なんだが
>>892
いや全然別のポストに対する全然別の返信。
タイミング的に紛らわしかったけど。
しかも別の人からもっと詳細なReplyがすでに付いて言いたいこと全部言ってくれたので
今さらポストし直す必要なくなった

ちなみにレガシー実装との互換性に配慮するなら互換漢字はそのままで
(その互換幹事の字体を表す)VSも付ければいいと思われ
正規化されても字体の情報は消えないし正規化されなければ
レガシー実装は単にVSを無視するだけでおそらく期待した表示結果になる

> MLがデフォルトで付けるReply-Toがないって話なんだが

そんなもの付けているやつはばかです

いや、それ（0213ソースの互換漢字にVSを付ける）ができない仕様だから
問題になってるんだと思うが。こっち↓を見ると判りやすいかな。
http://www.unicode.org/ivd/pri/pri98/pri98-completecharts.pdf

>>895
あーvoidネタだったのか
マジレスしてほしいんだがRFC 2822には何のためにReply-To定義してるの?
>>896
MLで言ってるのは「仕様書に」互換漢字+VSの組み合わせを載せるのがおかしいから
修正したということだけ。
互換漢字+VSは統合漢字+VSと正規等価なのだから後者が有効な組み合わせなら
前者も全く同等に扱わなければならない。
仮に有効とみなされなければそれは正規化をちゃんとサポートしてない実装
(つまりレガシー実装)だからそれはそれで問題ない。

まぁ確かに、MLへの返事を発言者にしてしまうようなカスみたいなメイルクライアントを使うのなら
それ相応の注意を払うのが当然だがな。

>>897
マジレスしてやるよ。
http://www.unicom.com/pw/reply-to-harmful.html
http://www.metasystema.net/essays/reply-to.mhtml

誰か掻い摘んでくれ。

>>900
「そんなもの付けているやつはばかです」

>>897
参照してる発言はこれ？
Message-ID: <[email protected]>
Date: Tue, 20 Mar 2007 22:55:09 -0700
From: Eric Muller <[email protected]>

少なくともこれを読んだ限りでは、
互換漢字にVSを付けてもいいなんて解釈は
できない気がするが。
他にソースがあるならポインタ希望。

Eric Muller wrote:

> Start with the sequence of JIS code points <41-78, 1-14-24>.
> Turn that into a PDF using a AJ1 CID font, the PDF contains
> CIDs 3552 and 13382 (and no direct trace of the JIS code
> points). Use the registered sequences <4FAE, E0100> and
> <4FAE,E0101> in the ToUnicode map. If you want to go to JIS,
> turn <4FAE, E0100> into 41-78, and <4FAE, E0101> into 1-14-24.
>
> Compare with the current scenario: the ToUnicode map contains
> <4FAE> and <FA30>; any normalization on that reduces both to
> <4FAE>, and certainly you cannot recover your original JIS
> code points.

ていうかごく単純に、仕様書に載ってないシーケンスは
IVDに登録されない（つまり使えない）んじゃね？

登録されていないバリエーションシーケンスは使えない。
http://www.unicode.org/reports/tr37/

> IVSes are subject to the usual rules for variation sequences: unregistered
> IVSes (which are not in the database) should not be used in text
> interchange, and registered IVSes should be used only to restrict the
> rendering of their unified ideograph to the glyphic subset associated with
> the IVS in the database.

互換漢字のバリエーションシーケンスは登録されない。
http://www.unicode.org/ivd/pri/pri98/sequences.txt

>>902-905
http://www.unicode.org/versions/Unicode4.0.0/ch03.pdf
> C9 A process shall not assume that the interpretations of two canonical-equivalent character
> sequences are distinct.
統合漢字+VSで字形が変わるのに互換漢字+VSで字形が変わらなかったらC9に違反する。

うーむ。
http://www.unicode.org/versions/Unicode4.0.0/ch15.pdf#G19053
> The base character in a variation sequence is never a combining character or a decomposable
> character.
しかしこの通りに実装したらC9を満たせないんだからこりゃ規格のバグだな。
たぶんこれ書いた奴は欧米人だからcombining characterを含むsequenceに分解される
decomposable characterのことしか想定してなかったんだろう。

というわけで困る人は「統合漢字に分解される互換漢字+VS」は「分解後の統合漢字+VS」
と等価であることを明確化してくれ、と働きかけてみるのがいいと思われ

ちなみにISO/IEC 10646の定義だと
http://std.dkuug.dk/jtc1/sc2/wg2/docs/n3186.pdf
> 20.4 Variation selectors and variation sequences
> Variation selectors are a specific class of combining
> characters immediately following a non decomposable
> base character and which indicate a specific variant
> form of graphic symbol for that character. A decomposable
> character is a character for which there exists an
> equivalent composite sequence.
で、
> 4.14 Composite sequence
> A sequence of graphic characters consisting of a noncombining
> character followed by one or more combining
> characters (see also 4.12).
だから互換漢字はdecomposable characterではない。やっぱバグだな

> やっぱバグだな
やっぱUnicodeの定義のバグだな

>>906
C9は「区別されると想定するな」ってことであって、「区別するな」ではない。
たとえば統合漢字と互換漢字を区別してソートするプログラムは「C9違反」か？
そんなわけないだろ。

>>907
だからUnicodeのバグではないし、
そもそも互換漢字+VSを使うことが禁止されているのに
「互換漢字+VSというデータの解釈の話」をしても意味があるとは思えない。

>>908-909
「互換漢字はdecomposable characterではない」ってネタのつもり？
n3186の、分解や互換漢字自体がテーマになっているわけでもない箇所に
ちょっとしたミスがあるってだけの話じゃん。

> たとえば統合漢字と互換漢字を区別してソートするプログラムは「C9違反」か？
> そんなわけないだろ。
C9だけ見たら違反しないかもしれないがそんなわけある。
CollationのときはまずNFDにしろと言ってるぞ
http://unicode.org/reports/tr10/#Step_1
> 分解や互換漢字自体がテーマになっているわけでもない箇所に
ISO/IEC 10646ではdecomposable characterという用語はここにしか出てこないよ。
variation sequencesの定義で使うためだけにここで定義してる

> C10 When a process purports not to modify the interpretation of a valid coded character representation,
> it shall make no change to that coded character representation other than
> the possible replacement of character sequences by their canonical-equivalent sequences
> or the deletion of noncharacter code points.
つまり統合漢字+VSを互換漢字+VSに置き換えてもテキストの解釈は変化しない。

>>911
> C9だけ見たら違反しないかもしれないがそんなわけある。
> CollationのときはまずNFDにしろと言ってるぞ
Collationなら正規化するのは当然だろ。全然反証になってないぞ。

> ISO/IEC 10646ではdecomposable characterという用語はここにしか出てこないよ。
> variation sequencesの定義で使うためだけにここで定義してる
だからその用語が「ここにしか出てこない」ISO/IEC 10646が正しくて
みっちり定義しているほうのUnicodeが間違ってるって発想はどこから出てくるんだ
という意味のことを>>910で書いたつもりなんだが。

>>912
> つまり統合漢字+VSを互換漢字+VSに置き換えてもテキストの解釈は変化しない。
繰り返しになるが、その「置き換えても」という仮定が無意味。

>>913
> Collationなら正規化するのは当然だろ。全然反証になってないぞ。
Collationはソート(など)のために定義されてる規格だろ。日本の都合で統合漢字と
互換漢字を区別するためだけに俺様ソートアルゴリズムを使うのか?
北朝鮮から文句言われるぞ

日本のユーザーとして統合漢字と互換漢字を区別したい気持ちはよくわかるが
そもそもそれが許されるんだったら区別のためにコードを割り当てる必要自体がない。
Adobeの連中の考えの根底にあるのは「JIS X 0213(およびAdobe-Japan1)の立場で
は区別される2つの漢字を区別するために(正規等価でない)IVSの割り当てが必要」
なんだから、こっちはそれを逆手にとって「だったら統合漢字+VSと互換漢字+VSだって
正規等価だから区別できませんよね?」と言ってやればいい

> 繰り返しになるが、その「置き換えても」という仮定が無意味。
そもそも「禁止されてる」なんてどこに書いてる? 出現すること自体は禁止されてない。

46 72 E5 B0 86 E3 82 A2 64 E5 B0 86 E3 82 A2 72
69 63 20 43 68 6F 70 69 6E

これショパンの名前みたいなんだけど、デコード出来ないで困ってます。
なんていう文字コードでエンコードされてるんでしょう?

UTF-8

Frédéric Chopin

ブラウザに放り込んでUTF-8を選択しても
Fr将アd将アric Chopin
という風に出てしまうんですよね。

>>917のようなéにデコードするにはどうすればいいんでしょう？

iconv -f utf-8

世界のどっかの偉い人がとっとと、「はいパソコンで使える
文字コード体系はこれです！！」って決めろよ。
いつまでだらだらやってんだよ。
全世界の文字網羅するつもりか？
発展途上国の独自の文字コードも実装しても
その発展途上国の人間は民族争いと淘汰で
首ひきちぎられて、地雷ふんじまって
鉛筆すら手に入らない状況だろうよ

つGB18030
共産党の担当者が偉い人かどうかは知らんがw

しつもんです。
JISやSJISで0x80以上ってかなりの確率で半角かななのでしょうか?

>>922
いいえ。

確率て

SJIS で半角ｶﾅは 0xA1〜0xDF までだぜ。

80〜FFまでの128個中、A1〜DFの63個が半角かなだから
割合としては63/128≒49.2%だな。

>>926
頻度を考慮しろバカ

漏れのkakikomi.txtは0.156484%が一バイトかなだった。
このスレのログは0.0141597%だった。
この板の(漏れが取得した)ログは0.11844%だった。

確率を全て一様に等しいものと考えてしまうのは教科書脳のなせるわざだな

おまけ。
某ホムーランスレのログは1.12698%だった。
やはりAAには一バイトカナが多いらしい。
それでも、「かなりの確率」とは言い難いな。寧ろ、0x80以上は殆どが漢字だと言うことだ。
#実際にはOpenJaneのログだから純粋な書き込みだけではないが、まぁ誤差だろう。

参考までに...

つ http://tricklib.com/cxx/ex/babel/scoremap.csv

バベルの文字コード判定で使ってる日本語文書内での各文字の出現頻度データです。
出現頻度が100未満のものは切り捨てています。csv の各行は...

    出現頻度, SJISでのコード, EUCでのコード, UTF8でのコード, コメント

...こんな感じ。元にしたデータはブラウザがキャッシュしてたデータ(インターネット上のテキスト)です。

# このデータを使って文字コード判定を行えばわずか2,3バイト程度のテキストでも
# 非常に高い確率で正確に文字コード判定が行えます。

追記：
文字コード判定用のデータなんでUTF16で0xFF以下の表現になる文字は含まれとらんです。

>>931
頻度が100というのがよくわからないな。頻度じゃなくて出現回数ですね。
こういう場合、上位500件とか全体の95%の条件で切り捨てするのでは?
元にしたデータはもうちょっと再現性のあるものにしないと
偏りがありますね。逆にジャンル別統計データのような形で持っておくと
あとで合成するのにいいかも。

2,3バイトでの文字コード判定というのは危ないような。
4バイトあればbigramにしてもうちょっと精度上げられそうだけど。

日本語のでかいコーパスから出したbigram頻度、どっかに
落ちてないかな。

新聞社のCD-ROMとかが使えればいいんだけど
bigram頻度出すためには全文をテキストファイルで
アクセス出来ないと駄目だよね。
ttp://cl.naist.jp/nldata/corpus/
が参考になるかも知れないけど2006年時点で
95年度版CD-ROMを対象にしているあたり鮮度に問題がある。

青空文庫は文学に偏りすぎる。

Wikipediaのデータベースのダンプをダウンロードできるので
それを使う手もある。

言語処理学会入るというのは、ちょっと躊躇うなぁ^^;
ttp://www.nak.ics.keio.ac.jp/NLP/guide/admission.html

>>933
>頻度じゃなくて出現回数ですね。

そうです。

>こういう場合、上位500件とか全体の95%の条件で切り捨てするのでは?

データ量に対する判定精度への影響具合と元データの偏りやノイズを考えて
100未満のデータを切り捨てたですよ。

>2,3バイトでの文字コード判定というのは危ないような。
>4バイトあればbigramにしてもうちょっと精度上げられそうだけど。

そうですね。現在すでにバベルは実用上まず誤判定することがない
精度を達成できてると自負してますけど、より完璧な判定の為には
bigramの導入も考えるべきですね。

今思ったんだけどUnicodeの注音字母はU+3105から始まっててU+3100〜U+3104が空いてるのは何でだろ?

世界中で言語がバラバラになったのはバベルの塔のせいなのに

イザナギが振り向いたからじゃなかったっけ？

バベルの塔が崩れたのを察知して
イザナギが振り向いたとか。

バベルの塔は崩れてないだろ。

バベルの塔って新バビロニアの頃だからせいぜい紀元前6,7世紀だよな？

W3Cの勧告の数値文字参照の部分をどう解釈したものか迷っています。勧告の原文には
The syntax "&#xH;" or "&#XH;", where H is a hexadecimal number, refers to the ISO 10646 hexadecimal character number H.
とあります。では ISO 10646 character number とは何なのかと？

BMP面以外の文字を扱う場合、IEやFirefoxはサロゲートペアを解釈して1文字として表示するようになっているようです。
例えば、&#x20bb7;(𠮷) と書いても &#xd842;&#xdfb7;(��) と書いても、
上が「土」になってる「吉」が表示さます。環境によってはカッコ内に同じ文字が見えていると思います。

これはブラウザ側での勝手な拡張なのか、それとも、ISO 10646 にサロゲートペアの使用が含まれているということなのでしょうか。

ブラウザの勝手な拡張というかお節介なだけ。
実体参照の大文字小文字の区別だとか;の省略だとかそういった
いやーな実装の一つだな。

# n文字以上入力してくださいというところにサロゲートペアで
# ねじこむとか荒業出来そうだねぇ。>セキュリティ方面
# あ、あと別に16進じゃなくて10進で書いても同じ動作だろう。

>>943
サロゲートペアを1文字と解釈するのは「バグ」
Firefox3.0では表示されないようになってるね。

この場合サロゲートペアと呼ぶのも正しく無い感じがする。
なんだかんだあったけどISO10646=UCS-4で扱っていいんだよね?
UTF-16で表現するときにだけサロゲートペアが発生する。
ISO10646とかUCSが求められている場所ではサロゲートの領域のコードが
出たら駄目でしょ。

Unicode=UCS2だとおもって今まで実装してきたのに、
突然Unicode=UTF-16だと言われても、困ります。
サロゲートペアをフォントに紐付ければいいだけだろって
そんな単純な話じゃないんですよ、みたいな。