5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

文字コード総合スレ part2

1 :デフォルトの名無しさん:2006/03/26(日) 21:20:39
プログラムにおける各種文字コードの処理について語りましょう♪

■前スレ
文字コード統一スレ 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


2 :デフォルトの名無しさん:2006/03/26(日) 21:24:41
とりあえず>1乙と言っておくよ☆

3 :デフォルトの名無しさん:2006/03/26(日) 21:38:29
ここまで読んだ!

4 :デフォルトの名無しさん:2006/03/26(日) 21:51:56
■ライブラリ
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


5 :道化師:2006/03/27(月) 00:20:23
>>4
バベルも入れてくれよぅ。
http://tricklib.com/cxx/ex/babel/

6 :デフォルトの名無しさん:2006/03/27(月) 03:33:13
IANA: Character Sets
http://www.iana.org/assignments/character-sets

7 :デフォルトの名無しさん:2006/03/28(火) 00:51:48
UTF-16 で表現可能な符号化文字集合(UCS-4 の部分集合)って
何か特別な呼び方ありましたっけ?

8 :デフォルトの名無しさん:2006/03/28(火) 13:08:43
Unicode では「Unicode scalar values」と呼んでいるようだけど、
わかりにくい用語だね。


9 :デフォルトの名無しさん:2006/04/05(水) 01:27:49
Legacy Encoding Project
http://sourceforge.jp/projects/legacy-encoding/

10 :デフォルトの名無しさん:2006/04/06(木) 00:57:29
>>9
[LE-talk-ja 15] で、森山氏がUTF-8で一度送ったあとISO-2022-JPで送りなおしているのが受けたw

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

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

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

11 :デフォルトの名無しさん:2006/04/06(木) 15:54:03
だれか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」と
(多分嘘が)書いてあるだけで、さっぱり判らん。

12 :デフォルトの名無しさん:2006/04/06(木) 16:10:16
>>11
たぶん、「Microsoft による ISO-2022-JP の実装(の一つ)」 という以上の定義
(Unicodeとの変換表とか標準字体とか)は無いんじゃないかと思う。

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

13 :デフォルトの名無しさん:2006/04/06(木) 19:26:59
UnicodeをCP50220に変換する場合、
U+005C REVERSE SOLIDUS
U+00A5 YEN SIGN
あたりはどういう扱いになるの?

14 :デフォルトの名無しさん:2006/04/07(金) 00:24:47
森山さんの説明
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 についてもリンクにあります。

15 :デフォルトの名無しさん:2006/04/07(金) 14:07:28
>>14
その説明を文字通りに理解すると、

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

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

16 :デフォルトの名無しさん:2006/04/07(金) 16:02:01
>>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 -> CP5022x って変換な気もするね。
U+00A9 Copyright Sign ->0x63
とかもあったし。

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

17 :デフォルトの名無しさん:2006/04/07(金) 16:39:02
>>16
多謝。どろどろですね。

18 :デフォルトの名無しさん:2006/04/12(水) 15:36:44
>>14
> JIS X 0208:1978 ESC @ B 0x21-0x28,0x30-0x74 0x21-0x7E in
「ESC @ B」 って 「ESC $ @」 の typo なんじゃない?

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

19 :デフォルトの名無しさん:2006/04/12(水) 17:35:33
人名をソートかけたら期待する並びになる?

20 :デフォルトの名無しさん:2006/04/12(水) 17:38:27
>>19 何を期待しているかにもよる。
少なくともバストサイズ順には並ばない。

21 :デフォルトの名無しさん:2006/04/12(水) 22:02:34
じゃあ、意味ないじゃん!


22 :デフォルトの名無しさん:2006/04/13(木) 23:38:44
人物クラスでも作ってバスト比較用関数を作らないとナ

23 :デフォルトの名無しさん:2006/04/14(金) 10:34:45
ていうかね、俺はね、日本の文化を大切にするという意味で
文字コード以前に、言葉を重視すべきだと思うのよね。

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

24 :デフォルトの名無しさん:2006/04/14(金) 11:49:49
>>23
つ[胸の豊かさ]

25 :デフォルトの名無しさん:2006/04/14(金) 12:07:03
s/胸/乳房/

26 :デフォルトの名無しさん:2006/04/14(金) 13:46:49
貧乳順

27 :デフォルトの名無しさん:2006/04/14(金) 15:05:05 ?
>>23
そこまで言うなら、明治の文人に倣って新しい言葉を作るべきだ。
「乳厚」とか。

28 :デフォルトの名無しさん:2006/04/14(金) 17:43:01
ちちあつヨーグルト

29 :デフォルトの名無しさん:2006/04/14(金) 19:18:59
お前ら乳関数も知らんのか。

30 :乳関数:2006/04/15(土) 11:27:57
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

31 :デフォルトの名無しさん:2006/04/15(土) 20:56:00
おっぱいが大きければソニーへ入社できてた時代は終わった
これからの時代は大きさより飛距離。

32 :デフォルトの名無しさん:2006/04/15(土) 22:07:55
らめえええええええぇぇえぇぇぇぇぇ

33 :デフォルトの名無しさん:2006/04/16(日) 20:03:36
C における wchar_t は、その表現系は特に定められていませんよね?
wchar_t が UTF-16 であっても UTF-32 であっても構わないわけです。

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

34 :デフォルトの名無しさん:2006/04/16(日) 20:36:21
UTF-16です


35 :デフォルトの名無しさん:2006/04/16(日) 20:57:59
>>34 ありがとうございます。
Windows における WCHAR が UTF-16 であり、かつ
typedef wchar_t WCHAR されていると言うことは、
Visual C++ のランタイムライブラリにおける
ワイド文字 wchar_t も UTF-16 であるということですね。

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


36 :デフォルトの名無しさん:2006/04/16(日) 23:55:58
utf-16の文字列はwide character stringじゃなくて、
multi byte stringだけどな。サロゲートペアがあるから。

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

37 :デフォルトの名無しさん:2006/04/17(月) 00:03:26
しかし、WindowsのWCHARはUTF-16を使っているんだな。
C/C++の規格は共にwchar_tを固定長だと期待しているようだが。

38 :デフォルトの名無しさん:2006/04/17(月) 04:22:27
GCCのwchar_tは32ビットでUCS-4らしいぞ。

39 :デフォルトの名無しさん:2006/04/17(月) 06:54:22
>>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 です。

40 :デフォルトの名無しさん:2006/04/17(月) 11:01:33
Javaは仕様で各プリミティブ型のバイト長が完全に決まってるから。
C処理系の実装によってヘッダ定義変えるんじゃね?

41 :デフォルトの名無しさん:2006/04/17(月) 16:45:13
>>38
wchar_tの内容を決めるのはライブラリであってコンパイラではない。



42 :デフォルトの名無しさん:2006/04/17(月) 17:22:20
sizeof (L'A')
を決めるのはコンパイラ

43 :デフォルトの名無しさん:2006/04/17(月) 17:30:03
L'A' の値を決めるのもコンパイラだね。

44 :デフォルトの名無しさん:2006/04/17(月) 17:39:43
>>43 じゃ、wchar_t の表現形はコンパイラ依存じゃん。
って、char だってそうか。

45 :デフォルトの名無しさん:2006/04/17(月) 17:44:04
>>42 >>43
ライブラリがまずwchar_tの中身を決めて、それに従うようコンパイラ
をビルドするの。

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


46 :デフォルトの名無しさん:2006/04/17(月) 18:07:11
なるほど

47 :デフォルトの名無しさん:2006/04/17(月) 18:09:55
VC++とか使ってると「コンパイラをビルドする」
ってのは頭にないからなぁ。「コンパイラが決めてる」
ってなっちゃうな。

48 :デフォルトの名無しさん:2006/04/17(月) 22:55:35
>>42
sizeof マンドクセに見えた


49 :デフォルトの名無しさん:2006/04/18(火) 22:40:25
>>44
charは1バイトなんじゃないか?

50 :デフォルトの名無しさん:2006/04/18(火) 23:12:09
厳密には「wchar_t も char もその時々で解釈が変わる」じゃないのか?
そりゃWin32APIや標準関数も含め各種ライブラリは、それぞれが想定した文字コードが前提だろうけど。

51 :デフォルトの名無しさん:2006/04/18(火) 23:27:21
>>49
charは、integral typeであることと、
sizeof(char) == 1(つまり< sizeof(T))って事以外はライブラリの範疇だろ?

52 :デフォルトの名無しさん:2006/04/19(水) 03:47:12
要するに、1バイトの表現形に環境依存性があるということやね?

53 :デフォルトの名無しさん:2006/04/19(水) 12:08:09
>>51 sizeof char >=1 じゃなかったっけ?必定条件は

54 :デフォルトの名無しさん:2006/04/19(水) 12:15:59
必要条件の間違いだった。
っていうか、その言葉も辺か。
使用上の要件ってことで。

55 :デフォルトの名無しさん:2006/04/19(水) 13:56:02
【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 (後略)]

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

56 :デフォルトの名無しさん:2006/04/19(水) 17:20:49
そもそも43は型の大きさのことではなく、どんな文字コードを使うかという話だと思うのだが。

57 :デフォルトの名無しさん:2006/04/20(木) 03:56:45
>>49
1バイトが8ビットとは限らない。

58 :デフォルトの名無しさん:2006/04/20(木) 04:09:08
charが8bitとは限らなくても
sizeof(char)は常に1

59 :デフォルトの名無しさん:2006/04/20(木) 09:47:49
>>58 そうだったのか。
でもそうすると sizeof でメモリ使用量を
見積もることができなくなるなぁ。

60 :デフォルトの名無しさん:2006/04/20(木) 10:08:45
>>59
charは9ビットでもsizeof(int)が4ならばchar * 4に格納できると言うことなのだから問題ない。
つまり、仮令32ビットのintでもcharでアクセスするときに9ビット*4に格納されるということだな。

61 :デフォルトの名無しさん:2006/04/20(木) 17:17:53
unicode<-->jis のマッピングは無いの?
ms 産の表しか見つからないんだけど、大丈夫?

62 :デフォルトの名無しさん:2006/04/20(木) 18:01:43
ないわけないじゃん。

63 :デフォルトの名無しさん:2006/04/21(金) 01:09:16
>>61
unicode.orgへ行け。

64 :デフォルトの名無しさん:2006/04/21(金) 03:35:22
JIS X 0221 や JIS X 0213 にはマッピングが書いてあったような。
もっとも、そこに書いてあるマッピングを使って幸せになれるかはわからんけど。

65 :デフォルトの名無しさん:2006/04/27(木) 20:35:48
T書体フォントマダー? (AAry

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

66 :デフォルトの名無しさん:2006/05/10(水) 16:20:02
いきなりですけど、JIS第3水準、第4水準は3バイトコードになりますか?

67 :デフォルトの名無しさん:2006/05/10(水) 18:27:26
符号化方式による。

68 :デフォルトの名無しさん:2006/05/13(土) 17:26:24
具体的には
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バイト

69 :デフォルトの名無しさん:2006/05/13(土) 17:27:04
> EUC-JIS-JP-2004
なんだこれ
もちろんEUC-JIS-2004の間違い

70 :デフォルトの名無しさん:2006/05/16(火) 18:33:36
>>39
UTF-32 で表現できる文字数は UTF-16 と大差ない。(同じだっけ?)
UCS4 で定義できる文字数をすべて表現することが出来るのは
現時点で UTF-8 しかないはず。


71 :デフォルトの名無しさん:2006/05/16(火) 18:49:37
>>70
UTF-32ってのは、そもそもUTF-16とレンジを揃えるために制定されたもの。
その後UTF-8もこれらと同じレンジに制限されたから、どれでも文字数は同じ。

72 :デフォルトの名無しさん:2006/05/16(火) 18:57:49
そのutf-8もrfc3629で、文字コードのrangeをutf-16でも表現可能な
0-0x10ffffに制限してしまったからね。

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

73 :デフォルトの名無しさん:2006/05/16(火) 18:58:18
ありゃ。書いてる間に重複してしまった。

74 :デフォルトの名無しさん:2006/05/16(火) 20:02:40
ところで、素朴な疑問なんだが、
Shift JIS や EUC-JP や Big5 や GB なんかを
Unicode に変換してしまうと、元のコードで違う文字だったものが
Unicode では同じ文字になってしまうわけですよね?
つまりラウンドトリップは保証されていない?
全単射は不可能?

75 :デフォルトの名無しさん:2006/05/16(火) 21:27:34
>>74
できることになってる。
ただし実装によってはできなかったりしなくもない。

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

77 :デフォルトの名無しさん:2006/05/17(水) 04:37:51
Basic LatinとかLatin 1で書かれているものが英語がドイツ語かフランス語かは不明
ですがそれはUnicodeの仕様です。
たとえば"SS"を小文字変換するのは言語情報がないとできません。

78 :デフォルトの名無しさん:2006/05/17(水) 07:23:51
>>74
複数の文字コードのソース情報を混ぜた場合の話?
それとも単一情報をソースの文字コード(or 言語)情報なしに元に戻したい?

79 :デフォルトの名無しさん:2006/05/17(水) 07:34:20
プレーンテキストで複数のソース混合ってISO-2022-JP-2以外にあるの?

80 :デフォルトの名無しさん:2006/05/17(水) 07:49:52
ISO-2022-JP-2で一つでしょ。

81 :デフォルトの名無しさん:2006/05/17(水) 07:59:40
>>78
>単一情報をソースの文字コード(or 言語)情報なしに元に戻したい

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

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

82 :デフォルトの名無しさん:2006/05/17(水) 21:19:57
>>81
うーんそれはラウンドトリップの問題じゃなくて、
あんさんの言うとおり統計とって言語を推定するしか。

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

83 :デフォルトの名無しさん:2006/05/18(木) 05:52:43
> やっぱりISO-2022の枠組みって万能だなぁ。
しかし万能なのは日本人の脳内ISO 2022に近い罠
> しかし日本語だと判ったとしてもShift_JISだったかEUC-JPだったかは判らんよなぁ……
エンコーディングスキームが分かる必要はないでしょ
ISO-2022-JP-2が複数ソースというのもそういう意味なんだから

84 :デフォルトの名無しさん:2006/05/18(木) 08:07:20
ISO 2022系は、重複符号化があると、
Unicodeへのmapping fで、f・f^(-1)がidentity functionにならない。

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

85 :デフォルトの名無しさん:2006/05/18(木) 17:56:56
UTF-16がパンクする日は来るのだろうか?

86 :デフォルトの名無しさん:2006/05/18(木) 18:19:38
16ビット程度でパンクしないようなら超漢字なんてない

87 :デフォルトの名無しさん:2006/05/18(木) 18:22:39
UTF-64でもなんでも策定してバイト数固定のエンディアン意識不要コードを作ればいいんだ。

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

88 :デフォルトの名無しさん:2006/05/18(木) 19:32:12
>>86
UTF-16は16ビットじゃないですよ?


89 :デフォルトの名無しさん:2006/05/18(木) 19:54:55
えーと、20bitとちょっと?

90 :デフォルトの名無しさん:2006/05/19(金) 09:26:13
>>88 ん?どういうこと?
サロゲートペアの話?

91 :デフォルトの名無しさん:2006/05/19(金) 11:16:31
UTF-16は16ビット単位にエンコードするけど、サロゲートペアがあるの
で表現できる文字空間はUTF-8と同じく(>>72)20ビットとちょっと
(>>89)。なので、>>86 の「(UTF-16の)16ビット程度で」というのは不
適切。

という話。



92 :デフォルトの名無しさん:2006/05/19(金) 11:26:08
UTF-8ってなんで20ビット止まりなんだっけ?
原理的にはもっと表せるよね?

93 :デフォルトの名無しさん:2006/05/19(金) 11:39:30
>>72じゃねの?

94 :デフォルトの名無しさん:2006/05/19(金) 15:05:03
てかコード長とオクテット数があわない文字符号体系は好かないんだよな。
西洋人は1オクテットで事足りる事多いからいやがるけどUCS4とかでいいじゃねぇかと思うことって皆はないのかえ?


95 :デフォルトの名無しさん:2006/05/19(金) 23:27:46
俺もUCS4でいいと思う。

96 :デフォルトの名無しさん:2006/05/20(土) 06:08:59
UCS4にすればcode point処理は固定長で済むかもしれないが、grapheme単位の処理は
可変長だから手間はほとんど同じ。
文字表現を固定長にしたいならCompositionやJIS X 0213も禁止にしないといけませんな。

97 :デフォルトの名無しさん:2006/05/20(土) 09:52:18
Normalization Form Dのデータとか…
ISO-8859-1の世界の人は、どう思っているのかな。
まああれば応用広がるのは確かなんだけど。


98 :デフォルトの名無しさん:2006/05/23(火) 04:14:50
そのうち一般的なPCでのC言語の char が 32 ビットになって全部解決。

char c = '字';


99 :デフォルトの名無しさん:2006/05/23(火) 04:50:45
中途半端なジョークはやめてくれ

100 :デフォルトの名無しさん:2006/05/24(水) 00:22:53
http://std.dkuug.dk/jtc1/sc2/wg2/docs/N3104.doc

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


101 :デフォルトの名無しさん:2006/05/24(水) 11:39:49
「翔」という字は最近ではよく見るがJISでは第2水準になってる。
JIS漢字制定当時(1978年)は人名漢字に無かったが(当時人名漢字にあった字は全て第1水準になってる)、
当時は「飛翔」等の言葉もあまり使われなかったのかな?

102 :デフォルトの名無しさん:2006/05/24(水) 22:12:51
>>100
特に記念碑的意味しかないが、とりあえずおめ。

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

103 :デフォルトの名無しさん:2006/05/24(水) 23:27:14
>>101
翔泳社って、そういうとこ気にせず名前決めたのかな。

104 :デフォルトの名無しさん:2006/05/25(木) 00:35:04
78年というとまだ当用漢字の時代だから、
「そんな難しい字は使うな」という意識があったんじゃないかな。

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

105 :デフォルトの名無しさん:2006/05/25(木) 01:41:35
逆にその時代だと広告なんかは気兼ねなく「飛翔」って書いていたんじゃないかな。
電算写植もそれほど普及していない時代なんだし。

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

107 :デフォルトの名無しさん:2006/05/25(木) 23:23:25
くだらん事を言うな

108 :デフォルトの名無しさん:2006/05/25(木) 23:27:26
「粍」「糎」「粁」は単位なんだから、それなりに使う場面もあったor考えられたんじゃないの。
少なくとも俺がいまパっと見て読めるってことはそれなりに見かけている筈だ。



109 :デフォルトの名無しさん:2006/05/26(金) 00:15:14
でも普通は「mm」「cm」「km」か「ミリメートル」「センチメートル」「キロメートル」と書くよな。

110 :デフォルトの名無しさん:2006/05/26(金) 01:25:49
だからその辺は明治以来の印刷屋の流儀があるわけで。
日本語タイプライタなんて、JIS制定以前からあったんだから
78年当時のみを考えても意味がないだろ。

111 :デフォルトの名無しさん:2006/05/26(金) 02:06:52
粁が千チメートルでないとはこれいかに

112 :デフォルトの名無しさん:2006/05/26(金) 08:14:03
何でジョ(禾予)がないのかが分からん。

113 :デフォルトの名無しさん:2006/05/26(金) 13:03:55
>>109
推測でしかないが、法律の条文(正式には縦書きだよね)に使われてるからかもな。


114 :デフォルトの名無しさん:2006/05/27(土) 15:45:05
ジョ(禾予)は第三水準だね。ちなみにU+25771。

115 :デフォルトの名無しさん:2006/05/28(日) 13:48:40
粍 糎 粉 米 籵 粨 粁
竓 竰 竕 立 竍 竡 竏
瓱 甅 瓰 瓦 瓧 瓸 瓩 瓲



116 :デフォルトの名無しさん:2006/05/29(月) 01:26:17
>>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

117 :デフォルトの名無しさん:2006/05/29(月) 01:31:59
> どうせ固定長厨は漢字が使いたいだけだから問題ない。
ああでもIdeographic Variationが使われ出すと破綻するな。
つーかそんなに固定長が好きなら内部でgrapheme単位に固定長の独自コードに
好きなようにマップすればいいだろ。それを情報交換用の符号として標準化する
必然性はどこにもない。

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

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

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

119 :デフォルトの名無しさん:2006/05/29(月) 18:19:56
補足。

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

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

120 :デフォルトの名無しさん:2006/05/29(月) 18:35:22
Shift_JISの0xHHLLのコードの各HHに対し、
LLが0x40〜0x9E (0x7Fは除外)と
0x9F〜0xFCの二行に分け、
左から並んでるだけじゃ?

121 :デフォルトの名無しさん:2006/05/29(月) 18:47:37
>>120
素直に句点コード表なんだが。あんたの説明は、ShiftJisのコード配置の説明そのものだ。

122 :118:2006/05/29(月) 20:32:34
>>120,121
サンクス。
調べてみる。


123 :デフォルトの名無しさん:2006/06/03(土) 04:48:05
>>119
PC-9821のMS-DOSはShift_JISだが漢字ROMはJIS
つまりMS-DOSがShift_JIS→JISの変換をやってる

124 :デフォルトの名無しさん:2006/06/03(土) 09:38:01
>>123
いいえ。

125 :デフォルトの名無しさん:2006/06/03(土) 11:31:03
>>124
いいえって何が?

126 :デフォルトの名無しさん:2006/06/03(土) 14:08:30
MS-DOSは変換しませんな。BIOSは変換するかも知らんが。

127 :デフォルトの名無しさん:2006/06/03(土) 17:57:35
98のVRAMはJIS。
で、DOSは(速度のために)BIOS使わずに
直接書いてた気がする。

128 :デフォルトの名無しさん:2006/06/04(日) 05:04:37
>>127
×DOSは
○多くのDOSアプリが

129 :デフォルトの名無しさん:2006/06/04(日) 05:52:32
DOSが画面出力をしないとでも?

130 :デフォルトの名無しさん:2006/06/04(日) 06:03:27
もうちょっとわかりやすく書いておこうか?

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

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

131 :デフォルトの名無しさん:2006/06/08(木) 16:00:56
>>126 BIOSはそんなことやってくれません。
DOS/Vのコンソールドライバがやってくれる。

132 :デフォルトの名無しさん:2006/06/08(木) 16:31:43
0xA0000 からだっけ?

133 :デフォルトの名無しさん:2006/06/08(木) 22:07:26
PC-98x1シリーズの話じゃなかったのか

134 :デフォルトの名無しさん:2006/06/09(金) 00:59:17
DOS/Vの仮想VRAMは確かにSJISだけど
ずっと98の話だった筈。

135 :デフォルトの名無しさん:2006/06/09(金) 04:16:32
98 ができたときは SJIS を使うことを想定していなかったので
BIOS では SJIS からの変換はやっていないはず。


136 :デフォルトの名無しさん:2006/06/12(月) 23:03:13
このスレにもよく出てくる番号付けたがり病の話
http://khdd.net/kanou/kangae/2006/Jun.html

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

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

138 :デフォルトの名無しさん:2006/06/17(土) 08:31:02
なるほど、0x5cをUnicodeにするときにバックスラッシュに置き換えるか円マークに置き換えるかで、
逆変換時に結果が変わるのと同じ種類の問題か。
ShiftJis⇔EUCは機械的に変換できるから、Unicode経由じゃなければ発生しないからねぇ。

139 :デフォルトの名無しさん:2006/06/17(土) 10:23:50
>丸付数字などの Windows 機種依存文字が変換できない

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

140 :デフォルトの名無しさん:2006/06/17(土) 10:45:05
Unicodeで表現できるからと言って、変換表にそれがあるかというと・・・。

141 :デフォルトの名無しさん:2006/06/17(土) 22:32:25
丸付き数字ってUnicode上にいくつか種類なかったっけ…

142 :デフォルトの名無しさん:2006/06/18(日) 08:50:35
>>141
シフトJIS⇔Unicode や EUC⇔Unicode の変換表に丸付き数字がないんじゃない?

143 :デフォルトの名無しさん:2006/06/18(日) 13:38:19
>>142
機種依存文字はシフトJISとかEUCの変換表に定義されていませんから…

144 :デフォルトの名無しさん:2006/06/18(日) 13:47:11
丸付き数字は機種依存文字じゃないでしょ?


145 :デフォルトの名無しさん:2006/06/18(日) 13:50:18
ちょっと前までは「機種依存文字」って呼ばれてたけど、今はもうそんなことないっていうこと?

146 :デフォルトの名無しさん:2006/06/18(日) 13:54:45
JIS X 0213(第三、第四水準+非漢字)の丸付き数字?

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

147 :デフォルトの名無しさん:2006/06/18(日) 17:40:44
>>145
Mac で普通に文字化けします。

148 :デフォルトの名無しさん:2006/06/18(日) 21:53:36
MSIME2007ではCP932に収録されてない文字は「環境依存文字」って表示が出る。
だから、Microsoft曰く、丸付き数字は「環境依存文字」。
なお、Macではフォントによっては表示されないし、フォントによっては表示される、はず。

149 :デフォルトの名無しさん:2006/06/18(日) 22:39:34
>>148
MSIME2007 では CP932 の定義が変わったの?

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

150 :デフォルトの名無しさん:2006/06/18(日) 22:43:05
>>148
JIS X 0201/0208に収録されてないかな?

151 :デフォルトの名無しさん:2006/06/19(月) 15:33:23
>>148
>なお、Macではフォントによっては表示されないし、
>フォントによっては表示される、はず。

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


152 :デフォルトの名無しさん:2006/06/19(月) 23:07:37
こういうのはシェアの大きいほうに合わせてCP932で統一してほしいなぁ。
一時的には混乱するかもしれないが、
結局は Mac ユーザでさえもその利益に預かれると思うんだけど。

153 :デフォルトの名無しさん:2006/06/20(火) 12:28:19
というか、Mac OS XはUnicode中心で、
Shift_JISは捨てる傾向だから、今更CP932も糞もない。

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

今後CP932は不要。

154 :デフォルトの名無しさん:2006/06/20(火) 12:36:09
>>151
そうか?
実際フォントを変えたら
○付き数字になったり ( ) 付き曜日になったりするんだが。

155 :デフォルトの名無しさん:2006/06/20(火) 12:44:49
>>154
単にそのアプリが今どき珍しく内部SJISだって話だろ。

156 :デフォルトの名無しさん:2006/06/20(火) 12:46:57
もうMac OS X純正アプリではほとんど皆無なんじゃないかな。

157 :デフォルトの名無しさん:2006/06/20(火) 13:13:08
マカーウザス

158 :デフォルトの名無しさん:2006/06/20(火) 13:15:40
>>153
問題は、「Shift_JISと名乗っているCP932のウェブページ」やら
「ISO-2022-JPと名乗っているCP50220のメール」やらを
表示(Unicodeに変換)する際に
機種依存文字をサポートしてやるかどうかってことでしょ。

159 :デフォルトの名無しさん:2006/06/20(火) 13:17:59
>>153
>実際、Mail.appもISO-2022-JPに収まらないとUTF-8になる。
>CP932にある文字でもね。

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


160 :デフォルトの名無しさん:2006/06/20(火) 14:20:00
>>155
ヒント:ブラウザ

161 :デフォルトの名無しさん:2006/06/20(火) 14:56:40
>>160
ああ、Firefox for Mac OS Xか。
あれは非常に特殊なケース。つーか、バグと言ってもいい。

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

162 :デフォルトの名無しさん:2006/06/20(火) 19:10:23
Safariの〜問題も悩ましいな。Mac OS Xは。

163 :159:2006/06/20(火) 19:12:50
もうちょい正確に言うと、
Mail.appではISO-2022-JPに収まらずCP932に収まるメールは、
含まれる字種によって
charset=CP932で送信される場合と
ISO-2022-JP(もどき)で送信される場合がある。

164 :デフォルトの名無しさん:2006/06/20(火) 19:19:53
>>162
昔から問題になってるのに、どうして直そうとしないのかねえ。

165 :デフォルトの名無しさん:2006/06/21(水) 00:40:52
>>153
>今後CP932は不要。

永遠に不滅でつ。

166 :デフォルトの名無しさん:2006/06/21(水) 02:09:17
>>164
間違えたのはMSの方だから。

167 :デフォルトの名無しさん:2006/06/21(水) 12:26:04
>>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

168 :デフォルトの名無しさん:2006/06/21(水) 13:08:41
>U+007E TILDE -> Shift_JIS 0x8160 WAVE DASH 【Safariの問題】
ちゃんとUnicodeConverterにU+007E TILDE -> Shift_JIS 0x7Eとするためのオプションが
用意されてるんだけど、Safariチームは知らないか、面倒いのでシカトしてる。

169 :デフォルトの名無しさん:2006/06/22(木) 14:53:17
>>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

なのが意味不明。

170 :デフォルトの名無しさん:2006/06/23(金) 01:29:06
>>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で、データを入力フォームに自動的に引用とか?


171 :デフォルトの名無しさん:2006/06/23(金) 14:02:11
>>170
> それはキーボードがJISでも、Shift-^が何故かASCII TILDEになっていて、
> Shift_JISにはOVERLINEはあっても、ASCII TILDEはないから、
> 一番近いWAVE DASHを使うというルールなんだと思う。

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

172 :デフォルトの名無しさん:2006/06/24(土) 17:20:40
>>171
どうしてわざわざそのページの為だけにhatenaにアカウント作ってんだ?

173 :デフォルトの名無しさん:2006/06/24(土) 22:25:12
はげしーくどうい

174 :デフォルトの名無しさん:2006/06/25(日) 02:43:18
>>153
そんなこと言ったら、Windows だって 10 年以上前から内部の API は
Unicode (UTF16 or UCS2) ベースじゃまいか。

175 :デフォルトの名無しさん:2006/06/25(日) 03:01:51
ucs2だったような希ガス

176 :デフォルトの名無しさん:2006/06/26(月) 02:13:41
>>172
うpろだだと流れるからじゃないの
>>175
Windows 2000からUTF-16になった

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

178 :デフォルトの名無しさん:2006/06/26(月) 23:23:59
直井靖氏?

179 :デフォルトの名無しさん:2006/07/22(土) 00:25:19
Unicode ver 5.00 がリリース!
http://www.unicode.org/versions/Unicode5.0.0/

180 :デフォルトの名無しさん:2006/07/22(土) 02:44:57
>>179
日本語にはあまり影響ないのばっかだなぁ今回は。

181 :デフォルトの名無しさん:2006/07/22(土) 02:46:13
で、何バイト?

182 :デフォルトの名無しさん:2006/07/22(土) 17:27:34
1. メモ帳を開く。
2. 「Bush hid the facts」と入力する。
3. ファイルを保存する。
4. 保存したファイルをメモ帳で開く。

解明してください。

183 :デフォルトの名無しさん:2006/07/23(日) 02:08:39
>>180
日本からはNamedSequencesの追加要望すらしてないんですか
どれだけやる気ないんだ
>>182
http://blogs.msdn.com/michkap/archive/2006/06/14/631016.aspx

184 :デフォルトの名無しさん:2006/07/23(日) 02:14:05
>>179
リリース?
βじゃねーの?

185 :デフォルトの名無しさん:2006/07/23(日) 05:46:30
もうβは取れました
何ヶ月前からタイムスリップしてきたんですか

186 :デフォルトの名無しさん:2006/07/23(日) 08:29:16
>>183
追加して欲しいのあるか?
国内規格の新設・改定もなかったし、
無理に増やす必要もなかったんじゃない?

187 :デフォルトの名無しさん:2006/07/23(日) 18:16:32
>>186
JIS X 0213:2004のUSIで表される25文字のうち2文字しか登録されていない。
未登録のNamed Sequenceは勝手に使ってはいけないことになってるし
正式な文字名もない。

188 :デフォルトの名無しさん:2006/07/24(月) 09:49:32
>>183
あれえ? なんでだ? Unicode と解釈しているようだが。


189 :デフォルトの名無しさん:2006/07/25(火) 17:31:53
>>187
どうしてその2文字だけが登録されてるの?
UAX #34のTable 1で例として挙げたものについてだけ
(ドラフトの段階で)とりあえず登録してみた
ってふうにしか見えないんだけど。

190 :デフォルトの名無しさん:2006/07/25(火) 20:34:20
>>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

191 :デフォルトの名無しさん:2006/07/25(火) 20:50:05
って>>116で一度貼ってた。
やっぱり非漢字の合成文字なんてどうせ誰も使わないとか本音では考えてるとしか
思えないんだが。
AJ16相当グリフのIVD登録マダー? (AAry

192 :デフォルトの名無しさん:2006/07/26(水) 14:20:08
>>190
> と思ったらUSI抜きで登録するつもりですか。もうね(ry

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


193 :デフォルトの名無しさん:2006/07/26(水) 20:36:00
>>192
いったいどこ見てるの?
漏れの手元にあるJNIExt.txt(↓からダウンロード)には
http://www.dkuug.dk/jtc1/sc2/wg2/docs/n3091-A.zip
U+31F0〜U+31FFもしっかり入ってるけど? (もちろんUSIは入ってない)

194 :デフォルトの名無しさん:2006/07/26(水) 20:39:09
http://mail.apps.ietf.org/ietf/charsets/msg01550.html
附属書5を恣意的に適用できるんだったら適用するのかどうか明示しておく
必要があると思う。

195 :デフォルトの名無しさん:2006/08/12(土) 12:08:53
Unicodeを一から作り直すとしたらどうしたいですか?


196 :デフォルトの名無しさん:2006/08/12(土) 14:05:14
unicodeじゃ無いものを作ります

197 :デフォルトの名無しさん:2006/08/12(土) 16:21:04
過去のものばっさり切り捨てて1から作って欲しいね
明治維新レベルの革命を!

198 :デフォルトの名無しさん:2006/08/12(土) 16:54:41
TRONコードにしろと?

199 :デフォルトの名無しさん:2006/08/12(土) 22:28:32
1から厨も定期的に現れるよな

200 :デフォルトの名無しさん:2006/08/14(月) 23:33:17
超…...

201 :デフォルトの名無しさん:2006/08/15(火) 00:33:22
感じ悪い

202 :デフォルトの名無しさん:2006/08/15(火) 08:59:09
國語元年からやり直しだな。

203 :デフォルトの名無しさん:2006/08/16(水) 22:21:04
互換性をなくす事に重点をおいて
コード振りなおせばいいような気がするんだけど
どうだい?そんな甘かないですかね

204 :デフォルトの名無しさん:2006/08/16(水) 23:42:57
だからさっさと銀河へ向けて地球開国
Galaxycodeへ移行しろと

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

205 :デフォルトの名無しさん:2006/08/17(木) 03:11:30
>>203
甘過ぎ

206 :デフォルトの名無しさん:2006/08/17(木) 16:04:46
>>196
1文字64ビット


207 :デフォルトの名無しさん:2006/08/17(木) 20:24:59
ほら64bit厨128bit厨もまた出てきた
>>199で一緒に書いとくべきだった

208 :デフォルトの名無しさん:2006/08/17(木) 20:28:39
ちなみにフォント・トレーサビリティシステムで使われているucodeが128bit長
(さらに128bit単位で拡張も可能らしい)

209 :デフォルトの名無しさん:2006/08/18(金) 11:36:28
64kbit文字にしてさ、文字テーブルを参照しなくても
256x256の2値画像で文字に変換できるようにするとかだめなのかね・・・


210 :デフォルトの名無しさん:2006/08/18(金) 12:14:13
それもうんざりするほど既出
ベクタ画像という発想が出てこない時点で10年前のアイデア
頼むから現存するテクノロジ(PDFとか)くらい知っててくれ

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


212 :デフォルトの名無しさん:2006/08/18(金) 14:34:51
アラビア語とかでは字母を組み合わせてgrapheme作ったり、前後の繋がりでglyphも
動的に変わるんですけど
固定長、文字コードとgrapheme1対1対応を提案する人に訊きたいんですが、こう
いうのはどうやって実現するんですか?

213 :デフォルトの名無しさん:2006/08/18(金) 15:11:09
そういうこと聞いても忘れた頃にまた書き込んでくるの
せめて過去ログくらい見ろと言いたくなる

214 :デフォルトの名無しさん:2006/08/19(土) 00:26:27
携帯業界はunicode化してかないの?

215 :デフォルトの名無しさん:2006/08/19(土) 02:19:16
何が悲しくて非関税障壁を自分から埋めなきゃならないんですか
by ガラパゴス諸島に生息する携帯キャリア

216 :デフォルトの名無しさん:2006/08/23(水) 21:36:37
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 等はきちんと使用しているのですが・・・


217 :デフォルトの名無しさん:2006/08/23(水) 22:16:56
>>216
よく分からないけど

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

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

218 :デフォルトの名無しさん:2006/08/24(木) 00:08:13
>>4のICU始めてドキュメントみたけど、
あまりに巨大なのでめまいがした…

219 :デフォルトの名無しさん:2006/08/24(木) 09:22:40
>>216
たとえばテキストの最初が "AB" だったとすると UTF-16-LE では
FF FE 61 00 62 00
になる。ReadFile は先頭から TCHAR に入れていくので
UNICODE 使用時には
00FF 00FE 0061 0000 0062 0000
のようになる。その4バイト目の 0000 を lstrlen が文字列の
終端だとみなすために文字列の長さは3とみなされる。


220 :デフォルトの名無しさん:2006/08/24(木) 09:24:12
>>219
あ、"AB"じゃなくて"ab"ね。

221 :デフォルトの名無しさん:2006/08/24(木) 09:42:34
>>219
とおもって実際に実行してみたらちゃんと動いた。
(先頭の BOM は抜く必要があるが)
そもそも ReadFile はファイルの中身をそのまま取ってくる
だけだから WCHAR を引数にしちゃいかんような気がする。

222 :デフォルトの名無しさん:2006/08/24(木) 14:24:49
>>219 >>221
ではどうしたらいいんでしょう
先頭のBOMって、ただのテキストファイルにもそういった識別子のようなものが埋め込まれているんでしょうか?
UNICODEファイルの操作ってそんなに特別なことなんでしょうか?


223 :デフォルトの名無しさん:2006/08/24(木) 14:31:40
>>222
とりあえず、そのテキストファイルとやらにどんなデータが入ってるか調べろ

な?

224 :デフォルトの名無しさん:2006/08/24(木) 14:37:06
>>222

225 :デフォルトの名無しさん:2006/08/24(木) 14:42:12
>>222
いや、>>217だろ・・・
sizeof(TCHAR)の値いくつになるよ?

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

226 :デフォルトの名無しさん:2006/08/24(木) 15:32:56
>>216
UNICODEが定義されていようとそうでなかろうと、テキストファイルの文字コードは変わりようがないはず。
だからReadFileやバイナリモードでのファイルの読み書きにはTCHARを使うべきではない。

227 :デフォルトの名無しさん:2006/08/24(木) 22:10:50
>>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 になるんでしょ。

228 :デフォルトの名無しさん:2006/08/24(木) 22:14:57
>>182を仕様だと言い張るなら
IsTextUnicode()でUnicodeかどうか判定できる

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

230 :デフォルトの名無しさん:2006/09/09(土) 02:09:52
BOM?

231 :デフォルトの名無しさん:2006/09/09(土) 02:15:48
基本的なことを聞きたいんですが、
例えばウィンドウズ上で書かれているこのレスはSHIFT-JISなんですか?
macで書いた場合はunicodeで2ちゃん側で変換してるってこと?

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

233 :デフォルトの名無しさん:2006/09/09(土) 02:39:31
>>231
ブラウザが2chへ送り出す時点でUnicodeからShift_JISに変換してる。
Safariで ~ が化けたりするのはその変換テーブルがWindows PCと
一致していないため。

234 :デフォルトの名無しさん:2006/09/09(土) 05:36:16
Windowsと一致する必要はない。


235 :デフォルトの名無しさん:2006/09/09(土) 09:45:13
ブラウザが送るのはページの文字コードか送るためのボックスに書いてある属性依存。
また、ブラウザによって送る文字コードの種類も変わってくる。

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

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

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

236 :デフォルトの名無しさん:2006/09/09(土) 13:29:53
>>234
Windows「に」歩み寄るべきだとは一言も言ってないんですが。
永遠に文字化けに悩まされたままでかまわない、解消する必要はないってことですか?

237 :デフォルトの名無しさん:2006/09/09(土) 17:16:47
文字化けは起こっていないということです

238 :デフォルトの名無しさん:2006/09/09(土) 22:44:12
>>236
Windows「に」歩み寄るべきでないとは一言も言ってないんですが。

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

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

239 :デフォルトの名無しさん:2006/09/10(日) 03:12:21
>>237
現に文字化けしてるんですが

240 :デフォルトの名無しさん:2006/09/10(日) 14:11:11
文字化けは起こっていないということです

241 :デフォルトの名無しさん:2006/09/10(日) 16:15:19
あなたの脳内だけで起きてなくても意味がないので
mohtaと一緒にISO-2022-JP-3が登録されてるお花畑の世界にでも逝っててください

242 :デフォルトの名無しさん:2006/09/10(日) 19:29:18
そういえば ISO-2022-JP-2004 が IETF に提出されてるね。
http://mail.apps.ietf.org/ietf/charsets/msg01550.html
反応ないけど・・・

243 :>>234=>>238だが…:2006/09/11(月) 09:45:30
>>241

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


244 :デフォルトの名無しさん:2006/09/11(月) 23:07:09
って世に言う「文字化け」の大半は実質変換の不整合の結果なのでは?

245 :デフォルトの名無しさん:2006/09/11(月) 23:49:17
単に間違った文字コードで表示しようとするから変になるんじゃないのか

246 :デフォルトの名無しさん:2006/09/12(火) 00:54:08
ほとんどの「文字化け」は、
ドキュメントの文字コードと表示システムが想定する文字コードの
不一致が原因じゃないか?

次は機種依存文字。

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

247 :デフォルトの名無しさん:2006/09/12(火) 00:56:54
変換ミスこそ文字化けであって、
違った文字コードで表示するのはデータ自体に間違いはないわけで
文字化けとは言わない気がする。

248 :デフォルトの名無しさん:2006/09/12(火) 01:37:10
その無理矢理な論理、恥ずかしいよ?

249 :デフォルトの名無しさん:2006/09/12(火) 03:20:37
人生とは旅であって、

250 :デフォルトの名無しさん:2006/09/12(火) 06:56:16
昔の文字化けと今の文字化けはあきらかに意味が変わってるね

251 :デフォルトの名無しさん:2006/09/12(火) 13:26:17
人の一生は重き荷を背負いて長き


252 :デフォルトの名無しさん:2006/09/12(火) 14:38:20
1200ボーのモデムで、文字化けに強いishフォーマットでエロ画像を交換していたオレがやってきましたよ。
ssより、s7のほうが化けにくいですよ。


253 :デフォルトの名無しさん:2006/09/12(火) 15:22:46
一発簡単文字化けテクニック

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

254 :デフォルトの名無しさん:2006/09/12(火) 20:55:21
>>247
>変換ミスこそ文字化けであって、
>違った文字コードで表示するのはデータ自体に間違いはないわけで
>文字化けとは言わない気がする。

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


255 :デフォルトの名無しさん:2006/09/13(水) 05:18:57
変換ミスと呼ぼうと文字化けと呼ぼうと実際それに日々悩まされていて
対応を要求されたりする事実に何の変わりもないので、
そんな言葉遊びに興味はありません。
対応の仕方とかの建設的な話題だったらいくらでも話したいですが。

256 :デフォルトの名無しさん:2006/09/13(水) 05:25:51


257 :デフォルトの名無しさん:2006/09/13(水) 05:32:22
建設的な質問があれば暇なヤツが応えるだろうさ

258 :デフォルトの名無しさん:2006/09/13(水) 15:16:04
ところでこの文字化けの話はどこから始まっているの?

259 :デフォルトの名無しさん:2006/09/13(水) 20:51:25
>>162

260 :デフォルトの名無しさん:2006/09/20(水) 22:33:26
これはひどい
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を運用する必要に迫られてる中国の温度差
なんだろうな。

261 :デフォルトの名無しさん:2006/09/20(水) 23:54:25
>Extension Cに提案されてる寿司屋のメニューに出てきそうな漢字
これはひどい

262 :デフォルトの名無しさん:2006/09/22(金) 22:04:20
他に少しでも一般人が興味持てそうな例あるか?


263 :デフォルトの名無しさん:2006/09/22(金) 22:39:08
その内、人名、固有名詞の「高」は全部はしご高になる日が来そうな気がする。

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

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


264 :デフォルトの名無しさん:2006/09/22(金) 23:05:36
教科書体至上主義の戦後の漢字教育のせいだと思う

265 :デフォルトの名無しさん:2006/09/23(土) 09:57:42
フォントの切り替えが、
手書き文字の機能の一部を担ってきたように、
文字集合も手書き文字の機能の極一部を担ってくるようになったと考えては?
全部担うことになるとさすがに困るんだけど。

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

267 :デフォルトの名無しさん:2006/09/23(土) 22:17:14
MIDIは、音楽再生形式としてはあまり使われてないだけで、
全然廃れてない。(デジタル化)ミュージシャンの間では現役。

268 :デフォルトの名無しさん:2006/09/23(土) 22:21:43
そりゃWeb上のフルカラー画像はほとんど.jpgだけど編集段階で劣化する
フォーマットを使うわけないわな。圧縮音楽もしかり
で、将来のGoogle先生は最終出力を相手にしないわけにはいかないでしょ

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

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

271 :デフォルトの名無しさん:2006/09/23(土) 23:08:40
たとえばMSXとか何かで、MMLで、音楽書いてた人じゃない?
「MML」はテキストデータ。それをコンパイルして、「標準MIDIファイル」。

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


272 :デフォルトの名無しさん:2006/09/23(土) 23:32:56
>>270
だから、楽譜を配る習慣はなくなってないだろ。
尤も、楽譜は一般人は見る機会が少ないから目立たないわけで、
それを言うなら一般人が文字を見る機会が少なくなるとは思えんが。

273 :デフォルトの名無しさん:2006/09/24(日) 01:04:05
MIDIが廃れたのはJASRACの影響が大きいかと スレ違いsage

274 :デフォルトの名無しさん:2006/09/24(日) 17:10:58
これからはoggの時代

275 :デフォルトの名無しさん:2006/09/24(日) 22:24:57
MODてのもあったな
文字情報もベクトルフォント込みになって
文字列比較も類似性で行なうようになるのか?

276 :デフォルトの名無しさん:2006/09/25(月) 08:06:28
>>270

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

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

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

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


277 :デフォルトの名無しさん:2006/09/25(月) 08:10:34
>>273
それは mp3とかも同じだと思うよ。

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


278 :デフォルトの名無しさん:2006/09/27(水) 01:27:29
メールに使われている文字はJISコードでemacsというかUNIXで使われているのは
EUCなのに文字化けせずにコピペできるっていうのは内部で変換されているのでしょうか?
それかまったく違うことをしているのか

279 :デフォルトの名無しさん:2006/09/27(水) 01:38:33
>>278
ケース1
メールソフトはEUCに変換してからGUIに表示してもらっている。
コピー要求に対しても、EUCに変換済みの文字を渡している。

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

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

280 :デフォルトの名無しさん:2006/09/27(水) 02:00:43
>>278
Emacsの内部は独自コード。

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

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


281 :デフォルトの名無しさん:2006/09/27(水) 02:18:27
279>>
280>>
なるほど。GUIやアプリ両方でやってるんですね。。。
勉強してきます。ありがとうございました。

282 :デフォルトの名無しさん:2006/09/30(土) 07:44:48
ISO/IEC 10646:2003の無償化キター
http://isotc.iso.org/livelink/livelink/fetch/2000/2489/Ittf_Home/PubliclyAvailableStandards.htm
U+29FCEの字形は古いままなのでAmendmentは含まれていない模様

283 :デフォルトの名無しさん:2006/10/05(木) 11:31:53
libiconv がサポートしている文字コードの一覧を得るための
関数って、 libiconv 自体には用意されていますか?

284 :デフォルトの名無しさん:2006/10/05(木) 11:40:11
iconv.h 眺めてると iconvlist() つー関数があるみたいですね。

285 :デフォルトの名無しさん:2006/10/08(日) 07:33:00
プラットフォーム依存の話になりますが 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 には登録されていません。エンコード名として
何が正しいのでしょうか?何に依拠すべきでしょうか?

286 :デフォルトの名無しさん:2006/10/08(日) 09:26:16
IANA未登録のエンコーディング名称に付けるのは"x-"ということになってる。
"x_"ではない。実際に取れるものも"x-"ならそれでいいんじゃないの。

287 :デフォルトの名無しさん:2006/10/08(日) 10:21:04
一方はそれでいいとして、

288 :デフォルトの名無しさん:2006/10/08(日) 13:37:26
MIMEなんかで使う時には、

X-x_Chinese-Eten

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

289 :デフォルトの名無しさん:2006/10/12(木) 11:23:10
locale -m で表示される charset 一覧の文字コード名って、
何を元にして生成されているんですか?
特に Linux (Debian GNU/Linux, Fedora Core 5) を想定しています。

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

290 :デフォルトの名無しさん:2006/10/12(木) 11:59:18
/usr/share/i18n/charmaps/*とか
詳しくはlocaleコマンドのソース読め。

291 :デフォルトの名無しさん:2006/10/12(木) 20:44:29
IBMのICUについて語りたいんですが
どこのスレに行けばいいですか?

292 :デフォルトの名無しさん:2006/10/13(金) 02:37:33
>>291
2chじゃなくてもいいならcppllにでも逝け。

293 :デフォルトの名無しさん:2006/10/13(金) 12:24:40
>>291
遠慮なくここで語ってくれたまえ。

294 :デフォルトの名無しさん:2006/10/17(火) 03:56:06
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に変換された"漢字"が出力されるのかと思ったのですけど。

295 :294:2006/10/17(火) 05:04:44
windowsXPだと正しく動作するのですけどね。

296 :デフォルトの名無しさん:2006/10/17(火) 05:36:40
Vine3.2のwchar_tってUnicodeなの? EUC fixed widthだったりしない?
Windowsばかり使ってるとwchar_t=Unicodeと思い込みがちだけど

297 :デフォルトの名無しさん:2006/10/17(火) 14:41:14
>>296
確かに、Vine3.2は未だ内部コードにEUCJPを使っています。
それは私も知っていました。
しかし、wchar_tがUCS2(もしくはUTF16)でないとは。

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

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

298 :デフォルトの名無しさん:2006/10/17(火) 16:04:06
sizeof(wchar_t)くらい実行してみろ。

299 :デフォルトの名無しさん:2006/10/17(火) 18:31:44
>297
wchar_tが2バイトということすら規定されていない。
いずれかの整数型と等しいと規定されているだけ。

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

300 :デフォルトの名無しさん:2006/10/17(火) 20:22:48
> 現実にはUTF-16かUTF-32(或いはUCS2/UCS4)の実装が多いと俺は思っているけど。
最近はLinuxもUTF-8ロケールが増えつつあるしおおむねそういう手抜きができるように
なってきたと思うけど一昔前の日本語UNIX環境ではまったく正しくなかった。
ちなみにUCSであることを保証したければ__STDC_ISO_10646__というマクロがある。

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

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

302 :297:2006/10/17(火) 23:12:24
早速参考になるサイトを発見しました。
http://eside.homeip.net/columns/i18n.html

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

303 :デフォルトの名無しさん:2006/10/20(金) 12:06:10
>>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;
}

304 :デフォルトの名無しさん:2006/10/20(金) 12:40:56
codecvtクラス使ってくれ。@libstdc++

305 :デフォルトの名無しさん:2006/10/20(金) 20:16:14
そもそもワイドキャラの定義ってなんだったっけ?
ワイドキャラ=UCS2&UTF-16のBMPでいいんだっけ?

306 :デフォルトの名無しさん:2006/10/20(金) 20:25:53
実装依存。
WindowsではUTF-16だしglibcではUTF-32(UCS-4だったか?)。

307 :デフォルトの名無しさん:2006/10/20(金) 23:12:01
TRONコード入れてたり、JISコード入れてたり、なんでもありだね。

308 :デフォルトの名無しさん:2006/10/20(金) 23:16:36
>>305
>>299
C/C++のwchar_tはいずれかの整数型と互換であるということが定められているだけ。

309 :デフォルトの名無しさん:2006/10/20(金) 23:33:46
しかし、実装毎にワイドキャラの文字コードはなにかっていうのは
定められてないとまずいよね?じゃないとisalphaとかの実装は文字コードに
依存してるからまずそうだし。
つーと当面はWinのワイドキャラ=UTF-16、Linuxのワイドキャラ=UTF-32
で想定してればOK?
でも、Linux上でUTF-16のisalphaみたいなのは変換するか、実装するかしか
ないということか。。

310 :デフォルトの名無しさん:2006/10/20(金) 23:40:41
>>309
wchar_tの中身のエンコーディングが何であるかは
処理系が知っていればいいことであって、
プログラマが関知すべきことではない。
wchar_tのエンコーディングに依存するコードは
書くべきではない。原則的にはな。

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

311 :デフォルトの名無しさん:2006/10/20(金) 23:41:12
みんな -fshort-wchar しちゃえばいいのに


312 :デフォルトの名無しさん:2006/10/21(土) 00:36:58
>>310
うーん、そしたらさ、isalphaはAsciiコードに依存してるのと同じで
iswalphaはUTF-16というコードに依存してる(Winの場合)ということにならない?

313 :デフォルトの名無しさん:2006/10/21(土) 00:51:09
>>312
iswalphaの実装は文字コードに依存していてもいいじゃん。
Cランタイムライブラリの一部なんだから。
プログラマが、wchar_tで使われている文字コードを仮定した
コードを書くべきでないということ。

314 :デフォルトの名無しさん:2006/10/21(土) 01:25:02
>>313
Winでwchar_tが将来4バイトに拡張されたときにもプログラムは正しく
動くことが理想ってことだよね。
そうすると、UTF-16のファイルをwchar_tに収めるってのもまずいことになる?
あれ、なんかよくわかんなくなってきたな。

315 :デフォルトの名無しさん:2006/10/21(土) 01:30:16
将来的にも、もしくはWin/LinuxのクロスでUTF-16を処理する方法って
何が正しいことになるんだ?wchar_tのサイズが未定義ってのが問題なのかな。
なんとなくchar*で持って、結局is系とかは自前で実装というはめになりそう
な気がするが。。

316 :デフォルトの名無しさん:2006/10/21(土) 05:17:55
イムブエって
何の略で
あんな
名前?

317 :デフォルトの名無しさん:2006/10/21(土) 05:39:59
>>310
FreeBSDは今でもCoding System Independentな実装になってるな
>>315
処理系依存の方法しかない。
>>316
略語じゃなくて染める、吹き込むという意味の英単語

318 :デフォルトの名無しさん:2006/10/21(土) 09:15:44
wとか16とか32とか固定と勘違いしそうな名前付けるからいかんのだよ。
char_xp とかUTFVista とかつけとけばよかったんだ。

319 :デフォルトの名無しさん:2006/10/21(土) 10:17:34
>>318
何だその無駄に重たそうな名前は(w


320 :デフォルトの名無しさん:2006/10/21(土) 11:14:18
じゃあ char_podとか、char_DSとか

321 :デフォルトの名無しさん:2006/10/21(土) 11:31:00
なにがおもしろいんだ
馬鹿

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

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

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

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

323 :デフォルトの名無しさん:2006/10/21(土) 12:49:19
もうchar*にUTF-8入れとけばいいよ。
ワイド文字は幻想だったのさ。

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

325 :デフォルトの名無しさん:2006/10/21(土) 20:34:42
>>324
ソースコードじゃなくてコンパイラが作るオブジェクトファイルの話なんだけど。

326 :デフォルトの名無しさん:2006/10/21(土) 20:35:38
> 処理系が扱うエンコーディングは

327 :デフォルトの名無しさん:2006/10/21(土) 20:41:27
UCS2まんまぶち込んで置けばそれなりに使えるんじゃね?
API呼ぶ時に変換しなきゃいけないだろうけど

328 :デフォルトの名無しさん:2006/10/21(土) 21:47:30
文字集合とエンコーディングってのは、ごっちゃになりやすいのかねぇ
内部表現は UCS-4、外部表現は UTF8 ってのが普及して欲しい
んで、適宜 SJIS や EUCJ への変換もサポートすると

329 :デフォルトの名無しさん:2006/10/21(土) 21:55:02
JavaとかC#はその点いいよね。やっぱり、言語の設計段階から
文字列の扱いについて考慮しとかないといかんよな。
後追いだと、Pythonのようにunicodeオブジェクトを導入するくらいしか
ないのでは。

330 :デフォルトの名無しさん:2006/10/21(土) 22:23:05
意味不明

331 :デフォルトの名無しさん:2006/10/21(土) 23:06:02
Solarisが大昔から文字コードに何を指定してもisalpha()が働くような実装持ってるがな。


332 :デフォルトの名無しさん:2006/10/22(日) 12:46:17
>>328
> 文字集合とエンコーディングってのは、ごっちゃになりやすいのかねぇ
そもそも使い分けで困ってるのは日本人だけですから

333 :デフォルトの名無しさん:2006/10/22(日) 13:54:05
そんなわけないですねw

334 :デフォルトの名無しさん:2006/10/22(日) 14:12:55
じゃあ日本が困ってることを国際の舞台で提案してもスルーされたり反対されたり
ひどいのになると「難しくて意味わからん」とか言われてつぶされるのはどうして?
海外でも切実に困ってるんだったら受理されるはずでしょ。
むしろ向こうから提案してくるか

335 :デフォルトの名無しさん:2006/10/22(日) 14:28:39
>>334
おまえにとって「海外」は一つの文化圏なのか?
同じ問題に悩まされている人達も居れば
そうでない人達も居るってだけの事だろ。

336 :デフォルトの名無しさん:2006/10/22(日) 14:34:37
いたとしても投票権を持つ程度に多いのは日本だけってこった

337 :デフォルトの名無しさん:2006/10/22(日) 14:37:52
Windowsのワイドキャラの定義はUCS2の固定でいいんだよ

338 :デフォルトの名無しさん:2006/10/22(日) 14:55:37
WIndows 2000からサロゲートに対応してます。
可変長のワイドキャラってC言語の定義的にはどうなんですか。

339 :デフォルトの名無しさん:2006/10/22(日) 15:03:27
勿論だめ。
ランタイムライブラリのみならず、ATLのマクロレベルでも対応してないから
コンポーネント間での文字欠けとか起こるだろう。

340 :デフォルトの名無しさん:2006/10/22(日) 17:25:52
じゃあ結局UTF-16のファイルから読み込んで文字列検索みたいなのは、
どうコーディングするのが完璧なんでしょう?

341 :デフォルトの名無しさん:2006/10/22(日) 17:27:04
文字列検索の何が面倒なんだろう・・・・・

342 :デフォルトの名無しさん:2006/10/22(日) 17:45:47
理想的にはUCS-4で読み込んで、そいつを比較というやり方だろうけど。
boost::regexとかなら可能だがchar_traitsの定義とかめんどくさそう。

343 :デフォルトの名無しさん:2006/10/22(日) 18:28:49
>>337
でも実際にはUTF-16なんだなぁ

344 :デフォルトの名無しさん:2006/10/22(日) 20:36:05
>>341
ちゃんとしたライブラリ使えば簡単だけど、自力でやり出すとNormalizeしたり
合成の切れ目探すのにステートマシン回したりと大変でしょ。

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

346 :デフォルトの名無しさん:2006/10/22(日) 21:37:09
>>345
まあそういうこと。
C/C++はワイド文字を直接読み書きすることを考えていない節がある。

347 :デフォルトの名無しさん:2006/10/22(日) 21:48:26
C言語側は柔軟思想だからなぁ
ガチガチに決められたらそれこそ不自由かと

348 :デフォルトの名無しさん:2006/10/22(日) 21:54:41
んー、C++とかが柔軟なのはいいとしてWindows上で可変とか未定義とか
にされてるとなあ。さらにマルチバイト≠SJISならprintf("%s", "SJIS文字列です");
だってだめってことでしょ。

349 :デフォルトの名無しさん:2006/10/22(日) 21:58:34
環境を限定していいならもちろんwchar_tをUTF-16と仮定して書いても問題ない。

350 :デフォルトの名無しさん:2006/10/22(日) 22:02:26
イチイチchar <=> wchar_t を変換することで解決。

351 :デフォルトの名無しさん:2006/10/22(日) 22:13:24
文字コードの扱いに可搬性を求める場合、次の二つの方法がある。

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

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

という理解でおk?

352 :デフォルトの名無しさん:2006/10/22(日) 22:38:51
入力 <=> locale <=> プログラムで自分の扱いやすい文字コード(Java,Unicode,UTF-8)
<=> wchar_t(Win,EUC) <=> char(ANSI C)
普通は作るの面倒だから、感謝しながらライブラリを使うことになる。

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

354 :デフォルトの名無しさん:2006/10/22(日) 22:45:45
ソースファイルはSJISで内部はUTF8とかその逆とかいろいろ大変そうですね

355 :デフォルトの名無しさん:2006/10/22(日) 22:58:14
>>353
君はMSに恨みでもあるのか?もしくは学生無勢だろ。

356 :デフォルトの名無しさん:2006/10/22(日) 23:23:04
>>353は、発言のないようから馬鹿もしくはコンピュータ歴(死語)が浅いのは確かだね。

357 :デフォルトの名無しさん:2006/10/22(日) 23:39:43
COMのおかげでシステムの奥深くまでUCS2が入り込んでいるから
互換性を棄てる以外に抜けられないだろう。
UTF-16に関しても9x時代からの呪縛があるから、
サードパーティーのCOMがサロゲートを受け付けないと予想。

358 :デフォルトの名無しさん:2006/10/22(日) 23:48:42
え?そんな狭い世界の話だったのか

359 :デフォルトの名無しさん:2006/10/23(月) 00:21:59
新規で設計するならシステムの中は全部UCS-4でいいんじゃないのかと思う。
UTF-8で扱えるのは32ビット分だからコード変換しても欠落はないし。

360 :デフォルトの名無しさん:2006/10/23(月) 00:41:06
>>353
そこにsetlocaleは関係しない。
おそらくSetConsoleCP/SetConsoleOutputCP。……という話でないことはわかっているけどさ。

361 :デフォルトの名無しさん:2006/10/23(月) 00:50:32
前スレ443で書いた麻雀牌が採用されるようだが
http://std.dkuug.dk/jtc1/sc2/wg2/docs/N3176.pdf
何でドミノの駒は水平のパターンがあるのに麻雀牌にはありませんか?
リーチの表現なんかで必要だと思うんですが。

362 :デフォルトの名無しさん:2006/10/23(月) 01:02:41
>>361
そこで合成文字のでb

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

363 :デフォルトの名無しさん:2006/10/23(月) 01:09:48
>>356
馬鹿っていうやつが馬鹿の典型だな。お前は何が問題でどうすればいいかも
わかってないのだろう

364 :デフォルトの名無しさん:2006/10/23(月) 01:11:32
>>363 こんな時間でも元気だな。もう眠くないか?

365 :デフォルトの名無しさん:2006/10/23(月) 01:14:48
>>360
>setlocale 関数は、プログラムの現在のロケール情報の一部または全体を
>変更したり問い合わせたりするときに使用します。ロケール依存のルーチン
>atof、atoi、atol、printf・・
MSDNランタイム ライブラリ リファレンスより。なので関係します。

366 :デフォルトの名無しさん:2006/10/23(月) 01:16:39
>>364
お前もつまんないやつだな。文字コードスレだから文字コードの議論する気の
ないやつはマ板にでもいけよ。

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

368 :デフォルトの名無しさん:2006/10/23(月) 08:54:38
>>365
さらに_setmbcpの存在が話をややこしくする
>>366
いちいち相手にするな

369 :デフォルトの名無しさん:2006/10/23(月) 10:07:29
結局 UCS2 しか安全に使えるコードはないのか。
UTF16 かもしれないとビクビクするくらいなら、
やっぱり UCS4 で統一した方がいいのかなぁ。
しかし wstring の中身は Visual C++ じゃ UCS2 だしなぁ。

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

370 :デフォルトの名無しさん:2006/10/23(月) 11:54:52
>>357
互換性がどうとか言う以前に、COMで使ってるのはMS謹製Win32APIで
定義されたBSTR型 (文字列長さ+WCHARの列 - Mac版を除く)だから、
C++のwchar_tがどうなろうが無関係。

371 :デフォルトの名無しさん:2006/10/23(月) 12:58:40
>>370
いやその、ランタイムライブラリとシステムの文字コードの範囲がずれてしまうと
アレだ、cygwinみたいにfopenで指定できるのと実際のファイル名が違うとかそういう世界になっちまう。
VFATだと9x互換だからファイル名からUTF-8の範囲でははみ出してしまうし。

372 :デフォルトの名無しさん:2006/10/23(月) 13:07:54
べつにいいじゃねえか

373 :デフォルトの名無しさん:2006/10/23(月) 13:09:07
>>371
単にOSの問題のような気がする。

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

374 :デフォルトの名無しさん:2006/10/23(月) 16:36:26
>>371
一応
FAT部はともかくとして、VFAT自体はUnicodeでファイル名を保存している。

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

375 :デフォルトの名無しさん:2006/10/23(月) 16:46:02
ファイル名は大文字英数8.3と相場が決まってる

376 :デフォルトの名無しさん:2006/10/23(月) 22:45:38
いつの間にかISO-2022-JP-2004の登録レビューがずいぶんと進んでるな

377 :デフォルトの名無しさん:2006/10/24(火) 07:07:17
ちなみにUCS2は厳密には可変長ってほんと?んじゃ2倍してランダムアクセス
するとかって違法?

378 :デフォルトの名無しさん:2006/10/24(火) 11:01:26
可変長なのはUTF16。
UCS2はランダムアクセス可能。
ただUCS2っていいながら
UTF16が入ってる事があるんだなぁ。
お行儀悪いプログラムだと。

379 :デフォルトの名無しさん:2006/10/24(火) 11:07:42
WindowsのWCHAR、
Javaのchar/String、
ICUのUChar/UString、
ぜんぶUTF-16だった気がする。


380 :デフォルトの名無しさん:2006/10/24(火) 11:22:40
形式論をいくら語り合っても無意味だよね。実質UTF16なんだから。

381 :デフォルトの名無しさん:2006/10/24(火) 14:35:32
なんでUCS4にしないかなあ。
なんてぼやいてても不毛だよな。

382 :デフォルトの名無しさん:2006/10/24(火) 14:49:54
なんでEUCにしないかなあ。
今も昔もこんなぼやきに意味はないよな。

383 :デフォルトの名無しさん:2006/10/24(火) 16:49:48
ふーん、玄米ビスケットがあるのにね

384 :デフォルトの名無しさん:2006/10/24(火) 17:00:47
玄米ビスケットって何ですか?

385 :デフォルトの名無しさん:2006/10/24(火) 18:17:02
WindowsのWCHARはUTF-16より前に作られたんだから仕方がない。

386 :デフォルトの名無しさん:2006/10/24(火) 19:09:22
>>212-213
予想通り、また固定長談義w

387 :デフォルトの名無しさん:2006/10/24(火) 20:16:05
EUC-JPを文字の途中でぶった切るプログラムだっていくらでもあるんだから
UTF-16にだけそんな厳密な実装を要求することないじゃない。
みんな大げさだなあ

388 :デフォルトの名無しさん:2006/10/24(火) 21:01:42
EUC-JPを文字の途中でぶった切るプログラムだっていくらでもあるんだから
僕のプログラムでもぶった切ってます、でクライアントが納得してくれれば良いのだが・・・・

389 :デフォルトの名無しさん:2006/10/24(火) 21:07:27
マジレスだがその手のクライアントは今でもShift_JISと外字の世界に生きてませんか?

390 :デフォルトの名無しさん:2006/10/24(火) 23:30:37
javaはUTF-8のサブセット
winはサロゲートがあるとMSDNで言っているがwcslenの実装は
while(++wc){}
みたいな実装だから2バイトでカウントしてる。。ひでー話だ

391 :デフォルトの名無しさん:2006/10/24(火) 23:46:56
逆にwcslenにサロゲートペア使った1文字を渡して1が帰ってくるのも問題ありだと思う。
ようするにstrlen("あ") == 1と同じようなことだろ。

392 :デフォルトの名無しさん:2006/10/25(水) 00:22:00
wcslenが返すのはあくまでwchar_tの数、code point数でもgrapheme数でもない。
文字数を得たり分解したい場合はgrapheme単位で処理するライブラリを別途使う。

393 :デフォルトの名無しさん:2006/10/25(水) 00:39:42
Cの場合wchar_tを4バイトにするしかやりようが無い。
STLもあるしboostもあるから、マルチワードパッチなど焼け石に水。

394 :デフォルトの名無しさん:2006/10/25(水) 00:47:23
>>390
> javaはUTF-8のサブセット
それはバイトコード内での文字列とかシリアライズした場合の話でしょ。

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

395 :デフォルトの名無しさん:2006/10/25(水) 02:37:23
>>392
string の文字数を返します。とMSDNには書いてあるがな。矛盾だらけだな。
いまだにUnicodeがUTF-16だとかUCS-2とかなんであるのかを明記してないMSは
後から言い訳しやすいようにあいまいにしてるように見えるな。

396 :デフォルトの名無しさん:2006/10/25(水) 08:12:21
サロゲートが分離しても泣かない!

397 :デフォルトの名無しさん:2006/10/25(水) 17:20:04
>>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として扱うようになった。

398 :デフォルトの名無しさん:2006/10/25(水) 19:12:02
>>397
1.4 の nio.charset では既に UTF-16 って書いてあったりするけどね。
まぁ、どっちにしろ Java は UTF-8 ってのは、あんまし正確じゃないって事で。

399 :デフォルトの名無しさん:2006/10/25(水) 19:14:25
>>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).

400 :デフォルトの名無しさん:2006/10/25(水) 19:22:28
>>397
> 昔はUCS-2と明記されていた。
ざっと見た感じでは UCS-2 とは書いてなくて、
UTF-16 でもなく、Unicode って書いてあるのばっかりだったけど。

401 :デフォルトの名無しさん:2006/10/25(水) 21:03:33
>>388
文字を途中でぶった切ってるのは僕のプログラムじゃなくてマイクロソフトです
と言いたくなってきた

402 :デフォルトの名無しさん:2006/10/26(木) 00:33:47
この議論見てて不思議なんだけど、そもそもBMP外の文字使うことなんて
そんなにある?

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

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

403 :デフォルトの名無しさん:2006/10/26(木) 00:40:08
だからEUC-JPよりもはるかにぶった切るケースに現実に出くわす可能性の低い
UTF-16でそんな神経質になるのはどうして? と思うわけだ

404 :デフォルトの名無しさん:2006/10/26(木) 00:53:58
EUC-JPやShift_JISでさんざん懲りたからだろう。

405 :デフォルトの名無しさん:2006/10/26(木) 00:57:47
そういえばサロゲートじゃないんだけどさぁ、Mac だと「株式会社」が
1文字扱いになってるヤツがあるじゃん、アレ、Unicode に変換すると
フツーのUnicode文字で5文字分相当になったりするけど、こーゆーのは論外?

406 :デフォルトの名無しさん:2006/10/26(木) 01:06:30
>>404
正直羹に懲りて膾を吹くだと思う。
あるいは杞憂とか。
legacy-encoding MLでNEC選定IBM拡張文字とIBM拡張文字を区別できるように
すべきだなんて議論してるのを見てるとめまいがしてくる。
まあ百歩譲ってそれはいいとしてもその方法としてvariation selectorを不正使用する
とか言い出したときは死ねばいいのにと思った

407 :デフォルトの名無しさん:2006/10/26(木) 01:11:05
>>405
AppleはPUAを使ってるからLE-talk JAの馬鹿どもよりは百倍マシ

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

409 :デフォルトの名無しさん:2006/10/26(木) 01:33:39
time_tとかはわざとlong intにしてない事に意味があるんじゃないかな。
4バイトとか実装よりなこと言い出して、実は何も分かってないだろ?

410 :デフォルトの名無しさん:2006/10/26(木) 01:47:50
>>407
PUAと言えば、Mac で Apple シフト JIS をUNICODE に変換した時に、
一部の記号になんか無駄に PUA が付加されちゃうんだけどその理由知らない?

411 :デフォルトの名無しさん:2006/10/26(木) 01:55:35
4バイトとかが実装よりに感じる初心者さんには言ってないです

412 :デフォルトの名無しさん:2006/10/26(木) 02:29:57
俺の定年後の2038年問題よりも、明日起きるUTF-16の文字化けの方が切実だよ

413 :デフォルトの名無しさん:2006/10/26(木) 02:48:41
>>411
typedef struct {char val[12];} time_t;
こういうのもあるってことが、伝わらないかな?

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

415 :デフォルトの名無しさん:2006/10/26(木) 03:23:38
time_tは「<」とかが使えないと困る。
そのtypedefだとフリーソフトがコンパイルできない。

416 :デフォルトの名無しさん:2006/10/26(木) 03:47:29
>>413

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


417 :デフォルトの名無しさん:2006/10/26(木) 09:22:10
>>399
charは、一文字を表しているんじゃなくて、
UTF-16の16bit unitに過ぎないってことですね…

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

418 :デフォルトの名無しさん:2006/10/26(木) 22:07:16
どうかなあという感覚はわかるんだけどね。BMPしか対応しないのは
それなりに理由がある。

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

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

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

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

419 :デフォルトの名無しさん:2006/10/26(木) 22:58:50
>>418
何を愚痴かいてるのか知らないけど、現状必要かどうかじゃなくて、用意してあるかどうかが大事じゃないのか?それ(BMP以外)を使うか使わないかは君が判断する事ではない。

420 :デフォルトの名無しさん:2006/10/27(金) 01:43:47
>>418
「悪の簡体字」ってどんなの?
「惡」は悪の康煕字典体だし。。。

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

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

421 :デフォルトの名無しさん:2006/10/27(金) 04:33:58
ちなみにBMP外の文字ってWinで表示できるの?

422 :デフォルトの名無しさん:2006/10/27(金) 06:18:17
>>421
Vistaではサロゲートペアの表示できたお

423 :デフォルトの名無しさん:2006/10/27(金) 06:45:27
XP でも API レベルで対応してるし、
メモ帳とかでもふつうにあつかえる(グリフさえあれば)。



424 :デフォルトの名無しさん:2006/10/27(金) 09:52:42
XANO明朝で2面の0213追加文字も表示できる

425 :デフォルトの名無しさん:2006/10/27(金) 13:07:00
>>420
それは繁体字。

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

426 :デフォルトの名無しさん:2006/10/27(金) 14:55:38
>>425
U+6076(晋の上部に心)は「惡」の俗字で、いわゆる政府の決めた「簡体字」じゃないでしょ。
くちへんにこの字を使うのは慶應を广+K 广+O とか書くのと同レベルの字だから
コード化されてないのもしょうがない。

427 :デフォルトの名無しさん:2006/10/27(金) 15:46:39
>>426
ちょっと待った、それはマジで言っているのか?
中国語を知らないなら黙っていた方がいい。

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

428 :デフォルトの名無しさん:2006/10/27(金) 17:04:36
>>427
たしかに中国語に関してはシロートだけど。
じゃU+6076が「正式な」簡体字だとして
くちへん+U+6076 がコード化されてないのはなんで?
単体では正字扱いだけど構成要素としては俗字扱い?

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



429 :デフォルトの名無しさん:2006/10/27(金) 18:04:29
漢語林付録の日中字体対照表によると
悪(惡)の簡体字はたしかにU+6076となっている。
で、くちへんにU+6076の文字(U+5641)は簡化字政策によればU+6076になるという。
つまりくちへんのあるなしを同一視したと。

430 :デフォルトの名無しさん:2006/10/27(金) 19:07:44
上が土の吉とか表示できなくね?

431 :デフォルトの名無しさん:2006/10/27(金) 20:58:27
JIS第3,4水準で303文字がBMP外だね。

432 :デフォルトの名無しさん:2006/10/27(金) 21:48:12
>>430
メイリオでは表示できるよ。あとAcrobat7.0付属の小塚明朝とかでも
U+20BB7

433 :デフォルトの名無しさん:2006/10/27(金) 21:58:38
>>428
中国語の簡体字では、へんやつくりが簡略化されるなら、その文字も自動的に簡略化して表記することが国家規格で決められている。俗字や手書き文字ではけっしてない。

434 :デフォルトの名無しさん:2006/10/27(金) 22:21:00
>>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
この辺が参考になると思う。

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

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

436 :デフォルトの名無しさん:2006/10/27(金) 23:09:15
事例は違うけど、その手の話を「日本の漢字」っちゅー本でこのまえ読んだ。
この本の著者もなんか筋金入りの漢字ヲタクだった。>>434と対決させてみたい。

437 :デフォルトの名無しさん:2006/10/27(金) 23:13:01
>>435
あったあった、さんずいに戸。

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

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

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

438 :デフォルトの名無しさん:2006/10/28(土) 00:23:45
そこで ideographic description sequence の登場ですよ。


439 :デフォルトの名無しさん:2006/10/28(土) 04:25:53
俺は中国語に興味ないし、各言語ごとに把握したいわけじゃないから、
要は各コードのisLeadByteみたいなのさえわかればいい

440 :デフォルトの名無しさん:2006/10/28(土) 04:33:01
そして思うんだが、プログラマレベルで気にすればいいのは切れないように
文字列を繋げるとか、イテレート時にサロゲートを気にするとかそれくらい
じゃね?表示できるかどうかはOSやらライブラリの話だし。

441 :デフォルトの名無しさん:2006/10/28(土) 04:43:31
あのう、OSやライブラリを書くのもプログラマですよ。

442 :デフォルトの名無しさん:2006/10/28(土) 08:21:29
そういうヤツらは自分で調べてもらわんと困る。

443 :デフォルトの名無しさん:2006/10/28(土) 09:26:21
OSやライブラリのプログラマも、切れないように
文字列を繋げるとか、イテレート時にサロゲートを気にするとかそれくらいだから
最終的にはフォントの問題では?

444 :デフォルトの名無しさん:2006/10/28(土) 11:52:14
Extension C以降は簡体字ってVSで表す方針じゃなかったっけ?
IRGの審議途中の文書見てると「これは(収録済みの字|収録を要求されえている
別の文字)の簡体字」という理由で登録を却下されたものがいくつもあるんだけど。

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

446 :デフォルトの名無しさん:2006/10/28(土) 12:39:08
失礼、中国では「曽」のまんなかを「田」に簡略化はしてなかった。
>>445は上部のソ型とハ型の違いだと思って読んでくれ

447 :デフォルトの名無しさん:2006/10/28(土) 13:48:47
>>445
そもそも曾(曽)は常用漢字じゃない。
最近になって判例を反映して人名用漢字になった。
で、この二つは異体字の扱い。

448 :デフォルトの名無しさん:2006/10/28(土) 13:51:46
> そもそも曾(曽)は常用漢字じゃない。
そうだった。コメント元につられた
> で、この二つは異体字の扱い。
日本ではね。

449 :デフォルトの名無しさん:2006/10/28(土) 15:34:40
>>439
ココで深い話をしている人たちは、そのOSやライブラリーを作る人たちだと思ってみてくれ。

450 :デフォルトの名無しさん:2006/10/28(土) 18:49:47
昨日は超漢字Vの発売日だったのに見事なまでにスルーされてますね

451 :デフォルトの名無しさん:2006/10/28(土) 22:27:58
>>450
それ食えんのか?

452 :デフォルトの名無しさん:2006/10/29(日) 00:21:10
OS作る人にしたって、そもそも各言語ごとの違いを吸収するためのUnicodeな
わけだろうに。
各言語を詳細に把握しないとUnicodeを扱えないんじゃ本末転倒だろう

453 :デフォルトの名無しさん:2006/10/29(日) 00:43:21
だいたいコンピュータで文字を扱おうなんて発想自体が
恐れ多いことなんだよ。言語ってのは計算機に扱える代物じゃないんだ。
計算機はひたすら2進数で加減剰除算と分岐処理と繰り返し処理をやってれば良かったんだ

454 :デフォルトの名無しさん:2006/10/29(日) 02:23:08
>>432
OSが縁の下で各言語の違いをがんばって吸収してくれるから
OS使うだけのプログラマは各言語を詳細に把握しなくても扱えるようになってるんだよ

455 :デフォルトの名無しさん:2006/10/29(日) 02:25:16
これも日本人に特徴的な気がするが
何もできなくなるまでむやみやたらと話を大きくしたがる人が多すぎ
優先順位をつけて物事に当たるという概念はないんだろうか

456 :デフォルトの名無しさん:2006/10/29(日) 02:31:29
研究者になぜ研究をするんですかと問う人もいるんだよね

457 :デフォルトの名無しさん:2006/10/29(日) 02:33:31
>何もできなくなるまでむやみやたらと話を大きくしたがる
どういうことだか分からないんだけど。

458 :デフォルトの名無しさん:2006/10/29(日) 02:58:06
ごちゃごちゃ言ってねーでユニコード使えようんこども
俺様がcjk書ければ他はどーでもいーんだよ、の意

459 :デフォルトの名無しさん:2006/10/29(日) 03:15:57
俺はSJIS,EUC,JIS,Unicodeに対応する文字列クラスみたいなの作ってるけど
確か、assign,append,isalpha,islower,ischarlen,isbomくらいがそろってれば
別に困ってないけどな。重要なのは可変長の扱いと、終端0が2バイトとか、
あとはbomの読み飛ばしくらいで、文字処理ができれば検索とかは後は同一だし、
なんかそんなに難しいことあるか?

460 :デフォルトの名無しさん:2006/10/29(日) 08:41:09
はい次

461 :デフォルトの名無しさん:2006/10/29(日) 13:03:55
俺は困ってないよ?
なんかそんなに難しいことあるか?


462 :デフォルトの名無しさん:2006/10/29(日) 13:05:43
あなたは無理して話に入らなくてもいいんですよ

463 :デフォルトの名無しさん:2006/10/29(日) 13:49:07
はい次

464 :デフォルトの名無しさん:2006/10/29(日) 15:20:17
>>457
LE-talk-jaの過去ログの展開1つ取ってもそう
「現実を見ろ」という当初の志(?)すらどっかに吹っ飛んでる

465 :デフォルトの名無しさん:2006/10/29(日) 15:53:41
http://pc8.2ch.net/test/read.cgi/win/1153828837/932-933
もうジャストは正しい日本語とか語るな。
日本語ですらこの始末なのにどうしてマトモな外国語処理ができようか(反語

466 :デフォルトの名無しさん:2006/10/29(日) 16:06:37
なんか話が散漫としてるが、プログラマーの俺としても、459的な
コーディング上の具体的な問題とかの話の方が楽しいな。

467 :デフォルトの名無しさん:2006/10/29(日) 16:31:53
>>459
そういう文字列処理の仕方は一般的なのでしょうか。

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

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

468 :デフォルトの名無しさん:2006/10/29(日) 17:30:22
Windowsのワイド文字は破綻してるからWindowsではあまり一般的でない希ガス

469 :デフォルトの名無しさん:2006/10/29(日) 19:43:16
>>467
std::codecvtというものがある。こういう風に使うらしい。
ttp://hw001.gate01.com/eggplant/tcf/cpp/strcnv.hpp

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

470 :デフォルトの名無しさん:2006/10/29(日) 20:44:16
wide文字はひどい環境になるとISO646だったか、7bit文字以外のサポートは
全く考えていない実装が多くて使えない。
std::basic_stringにuint32_tなんかを入れて使うほうが無難なきがする。

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

472 :デフォルトの名無しさん:2006/10/30(月) 00:38:04
てか今どきみなどうやって解決してるのかよくわかんねー。stlなのかboostなのか
MFCなのかATLなのか自前なのか。まあC/C++以外はお決まりのやり方がありそう
だけど。

473 :デフォルトの名無しさん:2006/10/30(月) 01:47:31
>>469
ありがとうございます。

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

474 :デフォルトの名無しさん:2006/10/30(月) 01:57:49
>>472
プラットフォームの独自APIのみ使うのも有効だそうですよ。

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

475 :デフォルトの名無しさん:2006/10/30(月) 02:52:49
>>474 こういういいかげんな奴の相手するなよ。

476 :デフォルトの名無しさん:2006/10/30(月) 05:08:13
お前がどの程度いいかげんじゃないやり方してるんだかもよくわからんがな

477 :デフォルトの名無しさん:2006/10/30(月) 05:22:51
もしかして考えすぎているのかもしれないが
文脈からすれば、>>472がいいかげんで、それを>>474に忠告してなんじゃないか?
まぎらわしいけど、たしかにどっちにもとれるな。

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

479 :デフォルトの名無しさん:2006/10/30(月) 06:12:37
ライブラリはちゃんとしてなきゃまずいだろ

480 :デフォルトの名無しさん:2006/10/30(月) 09:07:22
>>475
いやだからいった通り別に自分のやり方がいいとなんて思ってないって。
しかし、外人の作ったstlで日本語文字コード関係が全部解決なんてする気も
あんまりしないなあと思う。今のところ文字コード関係は手作業とかOSの
APIをごちゃごちゃと泥臭いことしなきゃいけないのが現実という気がするって
だけだよ。

481 :473 474:2006/10/30(月) 12:47:13
>>475
すみません。今473で貼ったサイトをみて勉強中ですのでfacetでの
変換は実用的ではないかもしれません。C++の規格上の理想です。

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

482 :デフォルトの名無しさん:2006/10/30(月) 13:39:56
効率度外視で一番まともな方法は
内部UCS4、外部UTF-8だと思う

483 :デフォルトの名無しさん:2006/10/30(月) 16:53:01
winでUCS4に変換ってMultiByteToWideでできたっけ?

484 :デフォルトの名無しさん:2006/10/30(月) 17:07:04
できない。
UTF-16と各種マルチバイト(UTF-8含)との相互変換のみ。

485 :デフォルトの名無しさん:2006/10/30(月) 19:47:17
実際に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は正常に動作するのですけどね。

486 :デフォルトの名無しさん:2006/10/30(月) 20:32:55
libstdc++がふるすぎます。そのころのは駄目です。
最新はv.6です。

487 :デフォルトの名無しさん:2006/10/30(月) 22:45:34
んじゃUCS4無理じゃん

488 :デフォルトの名無しさん:2006/10/30(月) 23:01:04
それだけ環境を選ぶと使えませんね。
libstdc++3.3.2は新しくはないけど、そこまで古くもありませんから。

489 :デフォルトの名無しさん:2006/10/30(月) 23:59:36
>>483
しかもそこで無理したってOSやCOMとのやり取りでUTF-16に変換せざるを得ないので
あまり意味がない。
Windowsだけの世界なら(内部なんだから当然そうなるはずだが)おとなしくOSの流儀に
したがって他方が無難だと思うよ

490 :デフォルトの名無しさん:2006/10/31(火) 00:08:15
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 :デフォルトの名無しさん:2006/10/31(火) 00:13:12
何の処理系の話なのかくらい書けよ

492 :デフォルトの名無しさん:2006/10/31(火) 00:27:37
>>491
vc8。
プロンプトから
cl -EHsc ファイル名
でコンパイル。

493 :デフォルトの名無しさん:2006/10/31(火) 00:29:14
>>489
内部ではコードポイント固定長で扱いたいこともあるだろ。
毎回変換するのも一つの選択肢で、意味は大いにあると思う。

494 :デフォルトの名無しさん:2006/10/31(火) 00:34:05
内部で固定長で扱いたいだけなら別にUCS4である必要もないと思うが。
むしろ合成が事実上必須のコードなんて扱いづらくて仕方ないだろ

495 :デフォルトの名無しさん:2006/10/31(火) 00:34:41
>>485
gcc3でC++って悪夢だ。
codecvt以外にも困ること多すぎ。

496 :デフォルトの名無しさん:2006/10/31(火) 01:06:36
>>490
VC8のバグらしい。
ttp://forums.microsoft.com/msdn-ja/ShowPost.aspx?PostID=250724&SiteID=7

497 :デフォルトの名無しさん:2006/10/31(火) 01:13:14
次期バージョンってまさかOrcasまで待てとか?

498 :デフォルトの名無しさん:2006/10/31(火) 02:07:56
libstdc++のL""はダミーですか?
バージョン上げたら改善するの?

499 :デフォルトの名無しさん:2006/10/31(火) 03:10:00
>>493,4
内部のコードポイントが外部より少ないんじゃ欠損する訳だし、
UCS4には変換できないし、どうやってやるんだ?という気がするが。

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

501 :デフォルトの名無しさん:2006/10/31(火) 05:28:59
>>495
kwsk

502 :デフォルトの名無しさん:2006/10/31(火) 05:32:25
なるほど。そうした場合以下のデメリットが出てくるだろうけど、その辺は
どう考えてるの?
・内部外部変換で2回の変換が入るのは速度面で不利
・4バイト長はメモリ消費が多い

503 :デフォルトの名無しさん:2006/10/31(火) 08:17:04
内部をどうしようとプログラマの自由。
もっといえばWindowsに合わせる必要もない。
以上。

504 :デフォルトの名無しさん:2006/10/31(火) 11:36:55
>>502
今時、しかもただでさえWindows自体が計算機資源をだだ漏れのように浪費するのに、
その程度のこと気にしたってしょうがないぞ。

505 :デフォルトの名無しさん:2006/10/31(火) 18:48:07
>>500
お前の言う4バイト固定版UTF-16とUTF-32の違いを感じない。
自前でUTF-8とUTF-32を変換するルーチンを書いたらどうかと思う。

506 :デフォルトの名無しさん:2006/10/31(火) 20:00:47
おまいらどうせ実質BMPしか使わないから
UCS2ぶっこんどけばいいんじゃね

507 :デフォルトの名無しさん:2006/10/31(火) 21:26:20
>>504
いや、気にしようよ
>>505
差がないから手間のかからない方にしたんだろ。それもいいんじゃねーか。
>>506
んなことない。今どきいつサロゲート文字がくるかわからんよ。OSが表示
できねーとかは知ったこっちゃないが、文字が切れるのは困るって。

508 :デフォルトの名無しさん:2006/10/31(火) 23:05:52
500 です。メモリや速度を気にするなら ASCII 限定でしょう。英語で勝負。
リッチな文字コードを使うのをやめるべきです。ちなみに
API で UTF-16 に一度変換するようにしているのは、UTF-8 以外も
楽して変換対象にしたいからです。手抜き工事ですね

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

509 :デフォルトの名無しさん:2006/10/31(火) 23:15:44
UCS2 では UTF-16のサロゲート領域にどんな文字が定義されてるの?

510 :505:2006/10/31(火) 23:37:25
>>508
UTF-32と違うのはわかるが、だからこそなぜUTF-32を使わないのかを聞きたい。

511 :デフォルトの名無しさん:2006/10/31(火) 23:50:35
>>510 バイト数を揃えたいだけで、それ以上の品質を求めている
わけではないというのでは、回答になっていないですか?
UTF-32 は、Windows に食わせるのに都合が良いわけでもないという
思い込みもあります

512 :デフォルトの名無しさん:2006/11/01(水) 03:25:30
>>509
未定義

513 :デフォルトの名無しさん:2006/11/01(水) 05:42:58
500の人はUTF-32を知らないのではないだろうか

514 :デフォルトの名無しさん:2006/11/01(水) 08:00:31
>>506
BMPしか使わなくてもUnicodeの文字表現は可変長だから、区切り位置判定は常に必要
Unicode文字列を任意のcode point位置で分割してはいけない。

515 :デフォルトの名無しさん:2006/11/01(水) 08:18:51
>>507
気にした結果、何ら問題ない。終わり。

516 :デフォルトの名無しさん:2006/11/01(水) 08:41:06
515の作ったソフトを使わせられる奴に乾杯

517 :デフォルトの名無しさん:2006/11/01(水) 08:45:25
素人だろ、ほっとけよ

518 :デフォルトの名無しさん:2006/11/01(水) 09:36:40
UTF-32の文字集合はUCS-4のサブセットであるは理解して発言せよ。
http://www.unicode.org/unicode/reports/tr19/tr19-9.html

519 :デフォルトの名無しさん:2006/11/01(水) 13:13:11
>>513
500 です。UTF-32 のメリットを教えてください。一応、UTF-32 については
508 で書いたんですけど。UTF-16 が使いたいけど、バイト数を
揃えたいだけなんです

520 :デフォルトの名無しさん:2006/11/01(水) 13:34:11
>>519
サロゲートペアだけバイト数を揃えて(?) メリットあるの?

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

521 :デフォルトの名無しさん:2006/11/01(水) 14:39:28
すべてのOSレベルでTronコードが使えるようにすれば解決?

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

523 :デフォルトの名無しさん:2006/11/01(水) 15:22:58
>>522
ASCII とくっつく合成もあるからね。U+0041 + U+0308 => U+00C4 とか。

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

524 :デフォルトの名無しさん:2006/11/01(水) 15:45:51
メリットはboostやSTLなどがそのまま動作保証できるってコトだろ。
マルチワードだと既存のものにパッチを当てる方向になってしまう。

525 :デフォルトの名無しさん:2006/11/01(水) 15:51:11
>>524 そういうことです。指摘された合成の考慮は確かに必要でしょうけど

526 :デフォルトの名無しさん:2006/11/01(水) 15:51:18
合成はサポートしないならそれでいいかも。
サポートするのであれば、UTF-8で全て扱うのと大差ないかも。

527 :デフォルトの名無しさん:2006/11/01(水) 15:52:27
「UTF-32 の整数値」 = 「Unicode のコードポイント」
つー、最大のメリットを捨ててまで、独自コードにこだわる理由が分からない。

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

528 :デフォルトの名無しさん:2006/11/01(水) 16:08:54
GCC で生活している人は sizeof(wchar_t) == 4 でいいんだが、
Visual C++ で生活する人は sizeof(wchar_t) == 2 だからね。
独自コードであっても、素性は UTF-16 のままだから
サロゲートのことを忘れて、独自コードのまま ASCII 範囲の判定を
してます。

529 :デフォルトの名無しさん:2006/11/01(水) 18:22:30
ユニコードって糞だね

530 :デフォルトの名無しさん:2006/11/01(水) 20:51:43
「Unicode + UTF-8 は優雅でないのでこれを認めない」なんてのもあったな。

531 :デフォルトの名無しさん:2006/11/01(水) 21:00:41
優雅なものがあったとしても
普及してないから駄目でしょう

532 :デフォルトの名無しさん:2006/11/01(水) 21:16:22
>>509
サロゲート文字が定義されてるが使用禁止。
そんなのを馬鹿丁寧に厳密に解釈してUTF-16と区別しなければならないなんて

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

534 :デフォルトの名無しさん:2006/11/01(水) 22:14:32
>>519
UTF-32もお前の独自コードも32ビット固定長だが合成文字には要注意などといった利点欠点は共通だと思う。
なぜなら両者はBMP外の文字(UTF-16でサロゲートペアになる文字)の扱い以外同じに見受けられるから。
だったらたとえ内部処理であっても広く世間で知られているものを使っておいた方が後々良いと思う。

535 :デフォルトの名無しさん:2006/11/01(水) 22:21:34
>>534
> たとえ内部処理であっても
世の中にはNEC選定IBM拡張文字とIBM拡張文字を区別したくなるかもしれないなんて
あまりありそうにもないことは過剰に心配するわりに内部コードのつもりだったものが
外で使われだすなんて実際に起きてみんな困ってることは絶対にないとか意味不明な
確信を抱いてる人が存在するんですよ。

536 :デフォルトの名無しさん:2006/11/01(水) 22:26:09
Normalization Form Cでいいやん

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

538 :デフォルトの名無しさん:2006/11/01(水) 22:39:48
>>536
NFCにNormalizeしても全て1コードポイント=1文字にはならない。
相変わらず可変長

539 :デフォルトの名無しさん:2006/11/01(水) 22:43:51
そこでJIS2004 IDEOGRAPHICS EXTENSIONとJAPANESE NON IDEOGRAPHICS
EXTENSIONですよ。合成? 何それおいしいの?

540 :デフォルトの名無しさん:2006/11/01(水) 22:45:45
漏れはUTF-8を使い続けると決めた。

541 :デフォルトの名無しさん:2006/11/01(水) 22:53:00
>>540
どうせ可変長ならUTF-8でいいよねえ

542 :デフォルトの名無しさん:2006/11/01(水) 22:59:58
合成文字機構は全ての文字にアクセントや発音区別符号を加えることができる。
合成文字は、タイ文字や数学植字のエンコード・国際音声字母を使うユーザーなどには必須である。



543 :デフォルトの名無しさん:2006/11/01(水) 23:03:51
日本語すらまともに取り扱えてないくせに本当にタイ語のテキストなんか扱うつもりなのかと。
ものごとには順序ってものがあるんだってば。

544 : ̄∨ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄:2006/11/01(水) 23:05:59
     ∧_∧
    ( ´・ω・`)     ∧_∧
    /     \   (    )何言ってんだこいつ 
.__| |    .| |_ /      ヽ
||\  ̄ ̄ ̄ ̄   / .|   | |
||\..∧_∧    (⌒\|__./ ./
||.  (    )     ~\_____ノ|   ∧_∧
  /   ヽ 死ねよ      \|   (    ) 
  |     ヽ           \/     ヽ. 早く病院に逝ってこいよ
  |    |ヽ、二⌒)        / .|   | |
  .|    ヽ \∧_∧    (⌒\|__./ /


545 :デフォルトの名無しさん:2006/11/01(水) 23:07:04
合成をサポートしない実装のレベルは、規格で許容されていると
思うのだが

546 :デフォルトの名無しさん:2006/11/01(水) 23:07:42
む、スレ住人を攻撃してるように見えるとアホが荒らすから確かにまずいな
訂正

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

547 :デフォルトの名無しさん:2006/11/01(水) 23:12:52
>>545
サロゲートも同様だね。
すべての実装が附属書Cの実装を義務付けられているわけではない。
それどころか装置がさまざまなレベルでサロゲートをサポートしていない可能性を
考慮しろとまで書かれてる

548 :デフォルトの名無しさん:2006/11/01(水) 23:13:05
Level1にしてもぶったぎったりしないようにはするひつようあんじゃねーの

549 :デフォルトの名無しさん:2006/11/01(水) 23:17:35
>>548
とりあえずサロゲートに関してはぶったぎる装置が存在する可能性まで
附属書Cに書かれてる。

550 :デフォルトの名無しさん:2006/11/02(木) 00:20:55
それはサロゲートをぶったぎられた入力が渡されてくる場合にも備えろってこと?

551 :デフォルトの名無しさん:2006/11/02(木) 00:25:03
YES

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

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

世の中進んだね。

552 :デフォルトの名無しさん:2006/11/02(木) 00:39:56
>>546
MacOS XではJIS X 0213やNFDのファイル名や合成必須のcomplex scriptも扱えてるよ。

553 :デフォルトの名無しさん:2006/11/02(木) 00:46:36
>>552
OS丸投げならできて当然だろ。
ちなみにMac OS XもModified NFDとか称して
> みんな見て見ぬふりをする
うちの一員だな。

554 :デフォルトの名無しさん:2006/11/02(木) 01:27:12
Mac OS Xのhfsモジュールに組み込まれているNFD変換関数はしょぼいよ。

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

555 :デフォルトの名無しさん:2006/11/02(木) 01:36:27
しかしModified NFDで変換するには当然OSの内部関数を使う必要がある。
ほらUnicodeもどき俺コードの弊害が早速出てる

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

557 :デフォルトの名無しさん:2006/11/02(木) 02:02:24
HFS+だとUnicodeが使えるけどHFSだとMacRomanになるとかか

558 :デフォルトの名無しさん:2006/11/02(木) 02:27:44
>>556
お前、Darwinのソースコード読んだことないだろ?

559 :デフォルトの名無しさん:2006/11/02(木) 21:56:10
与えられた2つのパスがVFSレベルで実は同一かどうか問い合わせる方法あるの?

560 :デフォルトの名無しさん:2006/11/03(金) 06:40:22
i-node 値で見ればいいんじゃね?

561 :デフォルトの名無しさん:2006/11/03(金) 11:50:49
もはや文字コード関係ないな

562 :デフォルトの名無しさん:2006/11/03(金) 12:19:08
幸い俺は最近Xcode使ってるからちょっと興味がある

563 :デフォルトの名無しさん:2006/11/04(土) 19:10:30
「サロゲートペアを含むパスを使用しないでください」
と運用で回避

564 :デフォルトの名無しさん:2006/11/04(土) 20:20:32
「SJISで文字化けします」「EUCでおk」という運用すら許容されてるから
それで十分だなマジな話

565 :デフォルトの名無しさん:2006/11/04(土) 21:41:40
SJISで十分だなマジな話

566 :デフォルトの名無しさん:2006/11/04(土) 21:46:55
>>565
文字化けします

567 :デフォルトの名無しさん:2006/11/04(土) 22:25:16
Windows-31Jでも無いんだな。

568 :デフォルトの名無しさん:2006/11/06(月) 13:12:27
>>566
CP932 を使ってください。

569 :デフォルトの名無しさん:2006/11/06(月) 20:01:42
Unicode 5.0:言語の分裂に挑み続けるUnicodeの新バージョン
http://opentechpress.jp/developer/article.pl?sid=06/11/06/011246

570 :デフォルトの名無しさん:2006/11/06(月) 21:04:36
C++だけど
内部的にはどういう風に持つのがベターなのかな
プラットフォームを選ばないのなら
std::wstringにUCS2ベタで入れとくのが現実的?
あるいはstd::stringにUTF-8?



571 :デフォルトの名無しさん:2006/11/06(月) 22:11:02
std::wstring に UTF-16 を入れて、
問題を見て見ぬふりというのはどうだろうか。

572 :デフォルトの名無しさん:2006/11/06(月) 22:14:55
見てみぬフリじゃなくて、USC2に収まらない時には例外を投げれば良いじゃん。
どうせWindowsならサードパーティのソフトが対応していないんだし。

573 :デフォルトの名無しさん:2006/11/06(月) 22:16:23
Windowsって、UTF-16のサロゲートペア対応してないの?

574 :デフォルトの名無しさん:2006/11/06(月) 22:29:16
>>573 対応している。

575 :デフォルトの名無しさん:2006/11/06(月) 23:36:07
>>568
「表示」が「侮ヲ」に文字化けします。

576 :デフォルトの名無しさん:2006/11/07(火) 01:35:07
> あるいはstd::stringにUTF-8?
Windowsだと標準ライブラリやAPIの類が一切対応してないのが厳しいな

577 :デフォルトの名無しさん:2006/11/07(火) 13:05:43
basic_string< WCHAR > に UTF-16 で入れておくのが Windows 的な感じ

578 :デフォルトの名無しさん:2006/11/07(火) 13:54:03
なぁ、俺が心配しすぎなだけなのかもしれないが、
近々サロゲートペアで表現できない範囲まで
日常的に使われることになったりはしないのだろうか。
そうするとやっぱり wchar_t に UCS4 を突っ込みたい。

579 :デフォルトの名無しさん:2006/11/07(火) 15:45:26
>>578
JIS X 0213 が常用されるようになればそういう日が来るけどそういう日って来るのかな?

580 :デフォルトの名無しさん:2006/11/07(火) 16:57:33
>>579 え? JIS X 0213 ってサロゲートペア使っても
表現できない範囲まで定義されてるの??知らんかった。

581 :デフォルトの名無しさん:2006/11/07(火) 17:15:43
>>578
Vista についてくるフォントとレンダラでは合成が大々的にサポートされるようだから、
ちゃんとやろうとすると結局は CharNextW とかで区切りを調べるよりなくなるわけで。

582 :デフォルトの名無しさん:2006/11/07(火) 17:29:05
>>578
UTF-32 = Unicode のコードポイント値だから、
UCSで文字格納しても 0x10FFFF 以降は保障されないよ。


583 :デフォルトの名無しさん:2006/11/07(火) 17:39:37
なんでプロセッサが64ビットの時代になってまで
内部処理でサロゲートみたいなことしてなやまにゃならんのだ・・・
内部 UCS4 外部 UTF8 でいいじゃん、って思うんだが、
OS やライブラリの設計する人はそうは思わないのかな。
結局は大部分のライブラリが ASCII だけ通ればいいじゃん、って
思想で作られているからしかたないのか。

584 :デフォルトの名無しさん:2006/11/07(火) 17:47:10
実際面を考えるとサロゲートペアに入る文字より合成の方が
まだしも広く使われるように思う。んでUCS4厨は全滅。

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

586 :デフォルトの名無しさん:2006/11/07(火) 21:33:59
サロゲートにかかるような文字として、ぱっと思いつくのは吉野家の土吉(U+20BB7)くらい。

587 :デフォルトの名無しさん:2006/11/07(火) 21:42:58
>>585 なんでそれが UCS4 厨に引導を渡すことになるの?

588 :デフォルトの名無しさん:2006/11/07(火) 21:43:28
>>585
サロゲートよりは広く、と言ったときに念頭に置いていたのは、Windows が対応してくれば
Combining Diacritical Marks for Symbols あたりが使われ始めるんじゃないかってこと。

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

589 :デフォルトの名無しさん:2006/11/08(水) 00:38:14
>>587
IVSは可変長だから

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

591 :デフォルトの名無しさん:2006/11/08(水) 08:41:36
メーラのエディタ部分とMIME化部分が、
サロゲートペアに対応したら、普通にそんなテキストが送られてくると思う。

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

592 :デフォルトの名無しさん:2006/11/08(水) 11:11:03
マルチワードとなるとソーティングとか正規表現エンジンとか全部修正になるわけだが
手が回らないから結局内部UCS4でやる事になると思う。

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

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

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

595 :デフォルトの名無しさん:2006/11/08(水) 22:23:33
UCS4やUTF-32って1文字4byte使うから、なんとなくメモリなどの効率が悪そうなんだよなぁ。

596 :デフォルトの名無しさん:2006/11/08(水) 22:50:35
英語圏の人からしたらUCS2/UTF-16でも(ry
逆に俺ら漢字圏の人からしたらUTF-8でも(ry

597 :デフォルトの名無しさん:2006/11/09(木) 01:26:46
UTF-16でも効率が悪いからってさらに効率の悪いUCS-4を使う理由にはなるまい

598 :デフォルトの名無しさん:2006/11/09(木) 01:26:49
>>580
ごめん間違えた、サロゲートペア必要な範囲 (U+10000-U+10FFFF) だと思った。
もちろんサロゲートペアで表せる。

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

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

599 :デフォルトの名無しさん:2006/11/09(木) 01:31:50
合成文字まで考えたらソーティングとかどうするんだろマジで。
RDMSのインデクスとか、
正規表現も新しい技術投入になるんでないかな。

600 :デフォルトの名無しさん:2006/11/09(木) 10:02:45
>>598 わざわざ調べなおしてくれて有難う。
俺もレス見て「ホントカヨッ?」と思ったんだが、
JIS X 0213:2004 より新しいものではそうなってるのかなと納得してた。


601 :デフォルトの名無しさん:2006/11/09(木) 10:20:31
>>599
合成文字考えなくても、日本語のソートは音訳しないと出来ない。
ヨーロッパだけ考えても、国ごとに違い、コードポイント順では話にならない。

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

602 :デフォルトの名無しさん:2006/11/09(木) 11:54:23
>>593
AJ1xは内部コードとはちょっと違うんじゃね?
Adobeアプリだって内部AJ1xで動いてるわけじゃないし、
あくまで補助的な位置づけでしょ。

603 :デフォルトの名無しさん:2006/11/09(木) 11:59:22
>>598
http://charset.info/
こんなページ、というか、サイトがあったんだな。
このサイトってどういう目的で作られているのかな。

604 :デフォルトの名無しさん:2006/11/09(木) 13:21:06
>>601
日本語のソートって結局読みベースの順序だて辞書使わないとだめって事言ってると思うのだけど
これの標準的な手順とか規約みたいなものってあるの?

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


605 :デフォルトの名無しさん:2006/11/09(木) 14:10:36
>>604
手持ちの漢和辞書でも参考にしたら?

606 :デフォルトの名無しさん:2006/11/09(木) 15:34:06
読みは持っている、あるいは持ってないので読み順はあきらめると仮定して、

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

607 :デフォルトの名無しさん:2006/11/09(木) 15:40:02
>>604は、「読みの辞書順」にはどんな標準があるのか問うているような・・・
英語みたいに冠詞は後に回すとかの特殊な処理は無いよね。

608 :404:2006/11/09(木) 16:12:21
>>607
はいそうです
>>606
JISX4061で言うところの代表読み辞書の標準はあるのかな?あればマシンリーダブルで存在するのかな〜と言う話です。


609 :デフォルトの名無しさん:2006/11/09(木) 16:14:41
ぎゃー、404じゃなくて604の間違いです


610 :デフォルトの名無しさん:2006/11/10(金) 21:39:26
std::stringでマルチバイトやってる人っている?

611 :デフォルトの名無しさん:2006/11/10(金) 22:07:32
>>610
漏れはやってるよ。
Windows で MBCS のをそのまま入れて単なるコンテナとして使ってる。

612 :デフォルトの名無しさん:2006/11/10(金) 22:23:45
struct UTF8char{
char* buf;
}
typedef std::basic_string<UTF8char> UTF8string;
ここまで考えて

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

613 :デフォルトの名無しさん:2006/11/10(金) 22:32:06
俺は以下のようにして、Cのように関数のオーバーロードは無いものとして変換関数を作って使っている。
typedef char utf8_char;
typedef std::basic_string<utf8_char> utf8_string;
WINの場合には大体UNICODEビルド使うのでUTF-16,UTF-8のみの変換で何とかなる。

614 :デフォルトの名無しさん:2006/11/10(金) 22:54:31
マルチバイト用のiterator作らないと無理かな?
class mb_iterator{
char* cur;
int charLen;
operator++(){
cur += charLen;
calcNextCharLen();
}
operator*(){
cur;
}
}
的な

615 :デフォルトの名無しさん:2006/11/11(土) 00:10:02
>>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環境で使いたくて作った。

616 :デフォルトの名無しさん:2006/11/11(土) 00:47:05
作者降臨すか。言語学板じゃお世話になりました。

617 :デフォルトの名無しさん:2006/11/14(火) 23:46:25
VistaからJIS2004(unicode)になりますが、
APもunicode対応になるとのこと。

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


618 :デフォルトの名無しさん:2006/11/14(火) 23:51:26
だめです

619 :617:2006/11/15(水) 00:13:28
>>618
何がだめですか?

620 :デフォルトの名無しさん:2006/11/15(水) 00:34:08
ネタじゃねえのかよ・・・

621 :デフォルトの名無しさん:2006/11/15(水) 08:19:21
>>617
> ・フォーム等IEから送信される文字もunicodeになりますか?
> →いままではSJISで送信

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

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

623 :デフォルトの名無しさん:2006/11/17(金) 01:39:57
どこまで出力されたかは*outbufの値で判断できるから
ヌル終端に頼る必要はないような。
そもそもiconvがヌル終端するなんて知らなかった。

624 :デフォルトの名無しさん:2006/11/17(金) 01:43:02
ごめん。
ヌル終端しなかった。
単に自分で出力バッファをヌルクリアしてたorz。

625 :624:2006/11/17(金) 02:04:20
でも変換が完了すればヌル終端する。

626 :624:2006/11/17(金) 02:24:26
変換される方がヌル終端されていたので、そのヌル文字が
出力バッファに出力されただけだった。
ヌル終端されてない文字列を入力にしたら出力の方はヌル
終端されてなかった。

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

627 :デフォルトの名無しさん:2006/11/17(金) 02:43:56
文部科学省に手紙出してからにしろよ
ちゃんと名前も住所も書くんだぞ

628 :デフォルトの名無しさん:2006/11/17(金) 05:53:01
愛昆布

629 :デフォルトの名無しさん:2006/11/17(金) 11:37:55
>>626

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

630 :デフォルトの名無しさん:2006/11/19(日) 18:33:08
Windows板に32bitとか128bitとか512bitとか言ってる馬鹿が湧いてて頭が痛くなってきた

631 :デフォルトの名無しさん:2006/11/19(日) 22:49:19
>>630
そのコードの数値を ASCII の文字列で表現するということを
提案して、さらに おかしな方向に持っていくとか。ASCII の数字列を
SI/SO でサンドイッチして数字列が可変でも大丈夫ですとかも
いいかもしれないですね(すべて冗談です)

632 :デフォルトの名無しさん:2006/11/19(日) 23:09:36
> そのコードの数値を ASCII の文字列で表現するということを
> 提案して、さらに おかしな方向に持っていくとか。
それ何てJIS X 4166?

633 :デフォルトの名無しさん:2006/11/19(日) 23:51:22
>>632
631 です。ネタとしては、以下参照ですか?
http://www.w3.org/TR/2002/NOTE-EGIX-20021220/
631 の冗談は、すべての文字を ASCII 数字列で表現というものです。
SI/SO じゃなくて XML で表現すれば確かにいいのかもしれませんね

634 :デフォルトの名無しさん:2006/11/22(水) 21:10:35
base64にしてみるとか

635 :デフォルトの名無しさん:2006/11/22(水) 22:20:07
それ何てUTF-7?

636 :デフォルトの名無しさん:2006/11/28(火) 11:05:43
文字コードによる漢字の並び方の質問があります。
例えばShift-JISって基本的に訓読み順に並んでいると思うのですが、
UTF-16の場合の漢字はどのような規則性で並んでいるのか教えてもらえないでしょうか?

637 :デフォルトの名無しさん:2006/11/28(火) 11:10:07
>>636
SJIS は訓読み順じゃない。
第一水準は音読み順で、第二水準は部首順。
UTF-16 も部首順。

638 :デフォルトの名無しさん:2006/11/28(火) 11:10:59
あと、各部首内はもちろん画数順。

639 :デフォルトの名無しさん:2006/11/28(火) 12:15:48
それは統合漢字の各ブロック(拡張AとかBとか無印とか)内での話だけどな。
他に互換漢字もあるし、互換漢字ブロックに入ってる統合漢字なんてのもあるし。

640 :デフォルトの名無しさん:2006/11/28(火) 23:42:57
互換漢字ブロックもいちおう部首順に並べようとはしている。
通し番号がほしかったらSuperCJKでも見れ
つかISO/IEC 10646の場合文字コードの値の並びには何の意味もないから
ソートにはISO/IEC 14651を使えということになってる。

641 :デフォルトの名無しさん:2006/11/29(水) 00:38:54
>>637
音訓のうち代表的な読みの順な。

642 :デフォルトの名無しさん:2006/12/02(土) 18:24:49
部首順にするとどんなメリットがあるの?
50音順のほうが便利そうなのに

643 :デフォルトの名無しさん:2006/12/02(土) 20:16:08
CJKそれぞれで違う読みの字はどうすればいいのか?

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

645 :デフォルトの名無しさん:2006/12/06(水) 00:03:50
jis2004対応大変だな。。

646 :デフォルトの名無しさん:2006/12/06(水) 00:21:49
Vistaは内部どうなってるの?cp932,utf-8,utf-16LE,Shift_JIS2004?
JIS2004対応というのだけは見たのだが、JIS2004の文字のフォントが用意されて
全てUTF32ぐらいになっていると素人としては楽なのだが。

647 :デフォルトの名無しさん:2006/12/06(水) 00:33:00
Windows NT系に関しては昔UCS2、今UTF-16だろ。
内部はともかく表向きのAPIはそうなっている。

648 :デフォルトの名無しさん:2006/12/06(水) 00:35:20
>>646
JIS2004 対応のフォントがあって、Unicode使ってればそれらの文字が使える。
レガシーな cp932 とかの符号化方式は変更なし、だと思った。

649 :デフォルトの名無しさん:2006/12/06(水) 00:50:04
UTF16LEだね

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

650 :デフォルトの名無しさん:2006/12/06(水) 00:55:34
今後はメールもunicodeがデファクトスタンダードになるのか。。

651 :デフォルトの名無しさん:2006/12/06(水) 01:50:09
2ちゃんの文字コードを変更してほしいな
いろいろ楽しそうなのに


652 :デフォルトの名無しさん:2006/12/06(水) 02:48:06
今メールって8ビット通していいのかね。
今でもRFCは7ビット推奨なら、メールでunicodeっていうと
base64になってしまう。

653 :デフォルトの名無しさん:2006/12/06(水) 02:52:41
utf-7があるじゃないか。

654 :646:2006/12/06(水) 07:20:13
>>647-649
ありがとう。
cp932->Shift_JIS2004じゃなくてほんとに良かった。

655 :デフォルトの名無しさん:2006/12/06(水) 12:47:55
>>651
文字を表示したいだけなら、大抵は実体参照が使えるぞ。

656 :デフォルトの名無しさん:2006/12/07(木) 00:42:55
JIS X 0213:2004 対応と新日本語フォント「メイリオ」について
http://www.microsoft.com/japan/windowsvista/jp_font/default.mspx

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


657 :デフォルトの名無しさん:2006/12/07(木) 01:06:00
jis2004 oracleもweblogicも最新版しか対応してないなんて…

こりゃたいへんだ〜

658 :デフォルトの名無しさん:2006/12/07(木) 01:21:34
メイリオも途中の版までは0x5cがバックスラッシュだったのになぁ。

659 :デフォルトの名無しさん:2006/12/07(木) 08:01:05
丸文字フォントに見えるが、角ゴシックフォントだけなの?
せめて明朝体と等幅のバリエーション程度は用意して欲しいな。
半角円マークのグリフはバックスラッシュのほうがいいなぁ。
日本の通貨記号をバックスラッシュに変えれば、みんな幸せじゃないのか。

660 :デフォルトの名無しさん:2006/12/07(木) 10:13:55
>>659
> 半角円マークのグリフはバックスラッシュのほうがいいなぁ。

なに言ってんの?


661 :デフォルトの名無しさん:2006/12/07(木) 20:01:42
波ダッシュ!

662 :デフォルトの名無しさん:2006/12/07(木) 20:24:05
ゴシックでU+8212(舒)の右下が「了」になってるのはそのままか。
もっと早い時期に気づいてれば報告して直してもらえてたかも。


663 :デフォルトの名無しさん:2006/12/08(金) 01:28:34
そういうのはまだ直してくれるんじゃないかな。

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

665 :デフォルトの名無しさん:2006/12/08(金) 20:11:01
>>664
TCP/IP+SMTPなら8bitクリーンでいけるんだろうけど
まだどこかにUUCPとかが残っているのかもしれないね。


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

667 :デフォルトの名無しさん:2006/12/09(土) 01:07:02
>>666
> 8bit通ると決め付けるのは

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

668 :デフォルトの名無しさん:2006/12/09(土) 06:31:28
>>667
8BITMIMEについては1行目で触れてるが。
漏れじゃなくてqmailに言ってくれ

669 :デフォルトの名無しさん:2006/12/10(日) 14:02:05
質問があります。
CP923に含まれている文字を教えてください。第一水準、第二水準の漢字は全部含まれていると
思うのですが(あと、機種依存文字)、補助漢字と呼ばれるものは収録されているのでしょうか??
OSはWindows2000でお願いします。

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



670 :デフォルトの名無しさん:2006/12/10(日) 14:10:15
CP932?

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

see MSDN

671 :デフォルトの名無しさん:2006/12/10(日) 14:25:32
CP923はISO-8859-15 (Latin-9)のサブセットで漢字は入ってないだろう。

672 :デフォルトの名無しさん:2006/12/10(日) 14:34:06
スレ違いかもしれませんが、ここで聞くことにしました。制御記号ってどれも必要なんですか??
とりあえず、アスキーのを引っ張ってきましたが、必要ないのばっかりという気がします。
でもなんで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)_装置制御1
12___DC2_______D2(device control two)_装置制御2
13___DC3_______D3(device control three)_装置制御3
14___DC4_______D4(device control four)_装置制御4
15___TC8(NAK)__NK(negative acknowledgement)_否定応答
16___TC9(SYN)__SY(synchronous idle)_同期信号


673 :デフォルトの名無しさん:2006/12/10(日) 14:35:26
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)_抹消


674 :デフォルトの名無しさん:2006/12/10(日) 14:41:27
>>672

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

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

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


675 :デフォルトの名無しさん:2006/12/10(日) 14:43:27
昔々テレタイプというものがあってだね。
そこに書いてあるコード通りの制御を行なうのに必要だったんだよ。


676 :デフォルトの名無しさん:2006/12/10(日) 14:52:48
もう、ほっとんどいらないと思うんだけど。

677 :デフォルトの名無しさん:2006/12/10(日) 14:59:17
テレタイプと書いて気づいたんだけど
@は 1 に BS して ○ すればOK。文字コードいらね。
という流れで機種依存なのだろうか?


678 :デフォルトの名無しさん:2006/12/10(日) 15:12:54
元々そのための「上書き用丸」でしょ。

679 :デフォルトの名無しさん:2006/12/10(日) 15:12:59
669です。
CP932でした。

680 :デフォルトの名無しさん:2006/12/10(日) 15:13:11
SOH〜ACK NAK SYN DLE DC1〜DC4 なんかは通信制御の
世界では普通に使われてるぞ。

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


681 :デフォルトの名無しさん:2006/12/10(日) 15:27:22
こうして見ると、制御コードのうちこの一年間に関わったプロジェクトのどれでも使わなかったものは殆どないな。

682 :デフォルトの名無しさん:2006/12/10(日) 15:39:38
>>669
http://www.microsoft.com/globaldev/reference/dbcs/932.mspx

683 :デフォルトの名無しさん:2006/12/10(日) 16:01:54
まぁ、RS232Cとか利用することがなけりゃフツーは無縁だわな。

684 :デフォルトの名無しさん:2006/12/10(日) 16:08:24
>>682
ありがとう、ございます。でも、漢字がないですね。
意味がわからなくなってきましたので、あきらめます。



685 :デフォルトの名無しさん:2006/12/10(日) 16:13:38
>>684
表の 81 とか 82 とかに貼ってあるリンク辿れば漢字でてくるけど。

686 :デフォルトの名無しさん:2006/12/10(日) 17:01:16
>>685
おわ。この表、クリックできたのですね。気づきませんでした。
ありがとうございます。


687 :デフォルトの名無しさん:2006/12/10(日) 18:21:11
もし、自分がmyAsciiなるコード表を作って
それに準じてブラウザ付きで配布したら、技術的にどこまで通用するんでしょう??



688 :デフォルトの名無しさん:2006/12/10(日) 18:28:48
通用する、の定義次第じゃね?
北朝鮮では金正日の3文字が別コードに割り当てられてるらしいし。

689 :デフォルトの名無しさん:2006/12/11(月) 10:52:19
>>674
へー、勉強になった。
制御コードにはお世話になってるけど、
さすがに紙テープの時代は知らなかった。

690 :デフォルトの名無しさん:2006/12/11(月) 22:13:51
ここに6bit版あるよ。
http://homepages.cwi.nl/~dik/english/codes/stand.html

691 :デフォルトの名無しさん:2006/12/12(火) 01:32:26
TCP/IP利用の通信プログラムでも制御コードを含んだデータを
送受信する分野は存在します。テレタイプも海外では現役の
ところもあるので、考慮が必要な分野は存在します

692 :デフォルトの名無しさん:2006/12/12(火) 20:10:08
>>691
制御コードと8bitクリーンはあんまり関係ない気が。
TCP通ってても8bit目は消される運命なのか…


693 :デフォルトの名無しさん:2006/12/12(火) 20:24:28
>>692
TCPを通る、昔からの7ビットプロトコルもある罠。

694 :デフォルトの名無しさん:2006/12/14(木) 00:01:43
>>692
7bitすら満たさない世界があるわけですよ

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

695 :692:2006/12/14(木) 00:19:18
>>694
これをRS-232C→USB変換機で使ったり、TCP上で流したりしてるの?
1バイトが8ビットじゃないぐらいの世代だろうか。


696 :デフォルトの名無しさん:2006/12/14(木) 00:49:38
>>695
シリアル伝送の世界では、転送効率を上げるために5ビットコードが使われることがある。
例えばRS-232Cでは8ビット送るには最低限スタートビットとストップビットが必要なので10ビット必要になる。
つまり、9600bpsでも秒間960バイトしか送れない。
5ビットコードを使えば、パリティをつけても8ビットで済むから同じ9600bpsでも1200バイト送れる。
#実際には、未だに75bps回線なんてのもあるから結構切実。

697 :デフォルトの名無しさん:2006/12/14(木) 01:09:50
75bpsですか。
おいらでも300ボーのモデムでパソコン通信していた程度だよ。

# MNPとか言われるとV.42bisとか連想してしまう世代w


698 :デフォルトの名無しさん:2006/12/14(木) 05:39:59
V.42bisなんてずいぶん最近w

699 :デフォルトの名無しさん:2006/12/14(木) 21:46:36
>>695
シリアルポートだったり、イーサネットで TCP だったりしますけど、
過去との互換性の確保が最優先な分野では現役なのですよ

稼動しているマシンや OS は、現在普通に販売されているものです。
通信先の相手側の事情でプロトコルをリッチなものに変更できないのです

700 :デフォルトの名無しさん:2006/12/14(木) 21:59:11
いまだったらエミュレータでも速度的に充分かもねぇ。
Z80とかMC68000くらいだったら余裕でしょ。


701 :デフォルトの名無しさん:2006/12/14(木) 22:12:49
>>700
それだとデータベースとか使うの大変です。プロトコルは貧弱でも
他の部分は現代のシステムですから

702 :デフォルトの名無しさん:2006/12/14(木) 22:57:52
こっちも相手も現代のOSで動いてたら、わざわざ古いプロトコル使うのって
悲しいよね。
レガシーシステムの保守はやっぱ大変そうだな。


703 :QQQ:2006/12/15(金) 03:14:06
ハングル文字を入力してその文字をデータベースから検索させるサイトを
作りたいんですが、入力された文字が内部でちゃんと認識されません。
同じ文字でも一文字入力した場合と二文字以上で入力した場合で
内部で認識するバイナリデータが変わったりします。
このへんのことに詳しい方いましたら、教えてください。

704 :デフォルトの名無しさん:2006/12/15(金) 03:16:43
「ハングル」自体に文字の意味があるよ

705 :デフォルトの名無しさん:2006/12/15(金) 03:47:24
unicode 正規化でググるとヒント見つかるかも。

706 :QQQ:2006/12/15(金) 04:31:07
>>704
あ、そうですね。知ってます。間違えました。
>>705
正規化ではググッたことがないですね。試してみます。

707 :デフォルトの名無しさん:2006/12/15(金) 08:55:02
http://itpro.nikkeibp.co.jp/article/OPINION/20061211/256530/?ST=win&P=2

|実際には,JIS2004で扱えるJIS第3/第4水準の文字についてもキャラクタ・コードを
|割り振った「シフトJIS2004」や「EUC2004」などのエンコーディングがある。
|ただしこれらは「標準(Standard)」ではない。

またnikkeibpが半可通で出鱈目書いてるよ。
前記事はyasuoka氏に突っ込まれまくったのに
こんどもまた総攻撃を食らうかもな(藁

せめてIANAに未登録とか書けばよかったのにねー。


708 :デフォルトの名無しさん:2006/12/15(金) 14:07:15
>>707
おぉ。その記事ためになった。ありがとう。

709 :デフォルトの名無しさん:2006/12/15(金) 15:03:00
>>707
>Unicodeでは,2つの文字を組み合わせて1つの文字として表示するものがある。
なぜ「Unicodeでは,2つ(以上)のcode pointを組み合わせて1つのgraphemeとして
表示するものがある。」と書かないの?
文中に出て来る「文字」や「キャラクタ」が各々何を意味するか教えて下さい。

710 :デフォルトの名無しさん:2006/12/15(金) 15:14:14
>なぜ「Unicodeでは,2つ(以上)のcode pointを組み合わせて1つのgraphemeとして
>表示するものがある。」と書かないの?
一般向けの解説記事だから。

711 :デフォルトの名無しさん:2006/12/15(金) 19:54:07
一般向けの記事だからとか、そういう問題じゃないような。

>「JIS2004」で追加された新しい文字の形がデフォルトになっているフォント

「追加」じゃなくて「変更」な。それ以外にも日本語おかしいけど。

>これらのフォントが利用しているコード体系のUnicodeでは,
>日本語と台湾語,中国語,韓国語が1つの「スクリプト」として定義されており

1つのスクリプトとして扱われているのは、
日本「語」や台湾「語」じゃなく、各国の「漢字」な。

>UTF-8やUTF-16といったUnicodeのエンコーディング(文字コード体系)

「エンコーディング」とか「コード体系」とかの用語がグダグダ。

>Unicode(UTF-16)では,1文字当たり2バイトの
>キャラクタ・コードが割り当てられているが

2バイトじゃなく16ビット(で1バイト)な。

712 :デフォルトの名無しさん:2006/12/15(金) 23:19:10
>2バイトじゃなく16ビット(で1バイト)な。

そうかあ?

713 :デフォルトの名無しさん:2006/12/16(土) 00:03:04
1バイト=8ビットという定義が主流だけど昔はいろいろあったらしい。
最近でもキロバイトとかメガバイトみたいな 1キロ=1000? 1024? とか混乱する要素は多いな。
HDDみたく500ギガバイトあたりになると差が激しくなってくるねぇ。


714 :デフォルトの名無しさん:2006/12/16(土) 01:54:54
そもそもUTF-8は16bit unsigned integerの列。
それを1byte = 8bitを単位とする世界で表現する時のためにbyte orderの考え方がある。

そして一文字辺り、一つか二つの16bit unsigned integerが必要。
サロゲートペアがあるので。

>Unicode(UTF-16)では,1文字当たり2バイトの
>キャラクタ・コードが割り当てられているが

ここまで短い文章で、突っ込みどころが満載なのも珍しい。



715 :714:2006/12/16(土) 01:55:34
>>714
> そもそもUTF-8は16bit unsigned integerの列。

ウガッ!
UTF-8は→UTF-16は

716 :デフォルトの名無しさん:2006/12/16(土) 09:18:09
>>707
安岡センセイも記事書いてるぞ
http://itpro.nikkeibp.co.jp/article/COLUMN/20061211/256519/

717 :デフォルトの名無しさん:2006/12/16(土) 12:10:28
2オクテットでいいじゃない

718 :デフォルトの名無しさん:2006/12/16(土) 12:18:08
規格の名称からして「Universal Multiple-Octet Coded Character Set」だしな

719 :デフォルトの名無しさん:2006/12/17(日) 02:06:22
>>717
16ビットのものを2オクテットとして扱う場合にはバイトオーダーの問題がある。
16ビットのものは16ビットの単位で扱わないと面倒かも。
16ビットでいいかというとサロゲートペアという問題が残っている。
UCSで扱う場合でも、正規化と合成文字を考えないといけない。
さらに言語タグみたいなものまであるから、手抜きせずにUnicodeを
実装するのは重労働だな。


720 :デフォルトの名無しさん:2006/12/17(日) 06:12:27
>>719
8ビットは常に1オクテットなんだからそれはいいんじゃないの?
バイトオーダはビット幅とはまた別の問題だよ。

でもさー、本当に全部必要なのかなー。TCP/IPを前提としてもさ。
BEL,VT(垂直タブ),FF(書式送り)なんて何に使うんだよー。
DC1-4だって使ってりゃちゃんとしたそれなりの名前付いてんじゃないの?
シフトイン、シフトアウトだってそれキーボードで既に制御済みじゃん。
BELって交換機でベルが鳴って誰かが駆けつけるとはとても思えないが。
CR,LFも片方しかいらないよ。どっちでもいい。どっちかにしてくれ。

721 :デフォルトの名無しさん:2006/12/17(日) 08:26:08
>>720

DC1-4 は使ってる場合は、ちゃんと名前付いてるよ。
ここはそのコードを使用する機器特有の機能を割り当てるための
領域なんだから。

FFなんかはプリンターの改ページコードだし ESC/P系のプリンタでは
まだまだ使用されてるだろう。


722 :デフォルトの名無しさん:2006/12/17(日) 08:27:11
>>720
その辺を節約してなんかメリットあるの?
#残すメリットなら色々あるわけだが。

723 :デフォルトの名無しさん:2006/12/17(日) 09:03:08
ちなみにキーボードで ctrlキー押しながらアルファベットキーを押した場合
該当するアルファベットのASCIIコードの7ビット目が反転されたコードとなる。

^C = ETX  ^Q = DC1(XON) ^S = DC3(XOFF) ^D = EOT


724 :デフォルトの名無しさん:2006/12/17(日) 10:39:09
>>720
> バイトオーダはビット幅とはまた別の問題だよ。

UTF-16は、>>714も書いているように、
16bit unsigned integerのsequenceなので、
ビット幅が16ビットでない時にバイトオーダーを考慮する必要があります。
だから別問題じゃなくて直結しています。

扱う最小単位が16bitのCPUであれば、
バイト(=8bit)オーダーは気にする必要がありません。

UTF-16はまず16bit unsigned integerのsequenceであると
抽象的に定義されていることを理解してください。

725 :デフォルトの名無しさん:2006/12/17(日) 11:26:47
>>724
問題を混同していて、切り分けて考えることのできないひとだね。
16bitとして扱うことのできないCPUなら問題はあるかもしれないが、
それでも機種依存的な問題で、UTFの定義とは全く関係が無い。


726 :デフォルトの名無しさん:2006/12/17(日) 11:43:40
>>722
自分だけのコード体系作って、OSもコンパイラも全部自分で作って
自分だけ速くプログラムを動かしたい。その為ならもう日本語を捨てる。
新しいアルファベットベースの自然言語も自分で全部作って、それでものを考える。
記号も追加したいのたくさんあって。だから、だから割り当て可能なのが
7ビット幅か8ビット幅なのか、気になってしょうがない。
制御コードから数字から文字まで全部8ビットなんて夢のようじゃん。
Unicodeなんてどうせ一生待ったっていいもの出来ないよ。人生は一度きり。


727 :デフォルトの名無しさん:2006/12/17(日) 11:46:11
>>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じゃなくてあれだが)

728 :デフォルトの名無しさん:2006/12/17(日) 11:50:24
>>725
あんたがEncoding formとEncoding schemeを理解できてないだけじゃんw

729 :デフォルトの名無しさん:2006/12/17(日) 12:24:52
8ビットだろうが16ビットだろうがバイトオーダの問題は
いつもある。文字コードの規定とビットの並びは別の問題だから。
だからデータの先頭にマジックナンバーとかサンプルの数字とか
書いてもらって自分側と逆だったら、全部一律に変換しちゃえばいい。
無駄なパワーとも思うが、どっちのエンディアンがいいのかは
賛否両論でそれぞれ言い分があるらしい。
ただ無条件に並びを規則的に交換するだけだから、別に大問題と
いうわけではないよ。今までだってそうやってきたんだから。
サロゲートペアはね、あれはね、大問題。
DBの1カラムからもう何かの文字集合のサブセットなんだからさ。
明日の国際会議の出席者の一覧表作ってください、と言われたらもう困っちゃう。

730 :デフォルトの名無しさん:2006/12/17(日) 12:43:54
Unicode標準は、バイドオーダーについてBEとLEを規定している。
規格も読んでない人間が、文字コードの規定と別問題というのはおかしい。

731 :デフォルトの名無しさん:2006/12/17(日) 13:05:40
というよりバイドオーダは問題の内に入らない、くらいのことを言いたいな。
審議するほどの内容の深みがないんだから。解決済みなんだからさ。
エンディアンなんてどっちでもいいんだよ。
ずっと前からネットワーク越しに互いにやりとりしたきてるんだから。
両方を規定しているってことは、Unicode規格としてどうでもいいってことなんだから。

732 :デフォルトの名無しさん:2006/12/17(日) 13:38:14
はいはい

733 :デフォルトの名無しさん:2006/12/17(日) 15:33:21
Code PointとCode Unit。みんな使い分けてる?


734 :デフォルトの名無しさん:2006/12/17(日) 17:49:28
違いすぎて混同しようがない。

735 :デフォルトの名無しさん:2006/12/17(日) 18:23:53
どうでもいいならむしろ規定なんかしないだろ。
実際内部コードとして使うことを前提にしていた昔のUnicodeでは規定されてなかった
(で、その結果現状の混沌がもたらされた)。

736 :デフォルトの名無しさん:2006/12/17(日) 18:25:33
>>733
>Unicode(UTF-16)では,1文字当たり2バイトの
なんて迷文を書ける人以外は

737 :デフォルトの名無しさん:2006/12/17(日) 18:38:27
>>729
マジックナンバーってBOMのこといってる?
どの文字コードでやり取りするか相手と意思の疎通が取れていないと
UTF-16前提で処理をするのは無謀。
ファイル名や拡張子みたいなデータ本体とは別の部分にメタデータとして
記録しておかないと、文字コードの自動判別みたいな不完全な処理を
しないといけなくなるぞ。


738 :デフォルトの名無しさん:2006/12/17(日) 18:41:31
流れをぶったぎって質問です

UTF-8においてのBOMというのがあるそうですが、何のためにあるんでしょうか
UTF-8でByteOrderは関係ない気がするんですが・・・


739 :デフォルトの名無しさん:2006/12/17(日) 19:41:53
>>738
> 文字コードの自動判別みたいな不完全な処理
のため。
> UTF-8でByteOrderは関係ない
だからISO/IEC 10646ではsignatureと呼んでる。

740 :デフォルトの名無しさん:2006/12/17(日) 19:55:30
>>738
テキストエディタみたいな文字コードの自動判別をしなきゃいけないソフトの場合、
BOMが頭に入ってると判定の精度があがる。

BOM,が入っててもISO-8859-1としての解釈もできるので、本当に
ヒューリスティックな判定をしないといけないんだよねぇ。
IEとかMozillaで文字コードのところに日本語とか西欧とかユニコードとか
設定できるのは判定する文字コードの種類を押さえて精度を高めるため。


741 :デフォルトの名無しさん:2006/12/17(日) 20:58:58
>>739
>>740
なるほど。ありがとうございます

Windowsのメモ帳もUTF-8で保存するとBOM付けるみたいですね


742 :デフォルトの名無しさん:2006/12/17(日) 20:59:18
MIMEならcharset情報をヘッダで表現できるので、きちんと設定された
メーラであれば大丈夫。
しかし、SPAM送信プログラムみたいなMIMEに準拠する意思の
ないような実装の場合、Subjectもメール本文にもcharset指定なしで
CP932とかISO-8859-xとか8bitのまま送ってくる。
日本語のスパムでもメーラによっては文字化けして読めないのは
そのせい。


743 :デフォルトの名無しさん:2006/12/17(日) 21:04:55
> SPAM送信プログラム
どうせならRFC 3514対応してくれ、とふと思った。

744 :デフォルトの名無しさん:2006/12/17(日) 21:05:43
>>741
BOMなしのUTF-8は正式な名称ではないがUTF-8Nという風に呼ばれることがある。
単純にUTF-8といった場合にはBOMありもなしも含まれる。


745 :デフォルトの名無しさん:2006/12/17(日) 21:11:30
悪意がなくてもバルクメーラーの実装は結構いいかげん。
Dateフィールドがなくて1970/01/01扱いされたり、2035年とか
未来からのメールとか平気で送ってくる。


746 :デフォルトの名無しさん:2006/12/17(日) 21:21:58
>>738
標準では、「必須でもなければ、推奨もしてないが、標準に適合しないわけではない。」
という表現。あなたの言う通りbyte order signagureとしては意味ないが、>>739>>740のため。

747 :デフォルトの名無しさん:2006/12/17(日) 21:42:14
>>744
BOM付きのUTF-8を指す略称が欲しいな。UTF-8Bとか。

748 :デフォルトの名無しさん:2006/12/17(日) 21:59:24
今は分からないが、UnicodeとISO10646でBOMにあたるコードの扱いが
違ってなかったっけ?
UnicodeだとBOMでISO10646だとZERO-WIDTH NON-BREAKING SPACE。


749 :デフォルトの名無しさん:2006/12/17(日) 22:07:30
UTF-8Y ってのがあるみたいだが、あんまりメジャーじゃないみたい。

750 :デフォルトの名無しさん:2006/12/17(日) 22:25:37
スパムメールがへんてこなのはフィルタ対策だと思うがどうか。
メールチェッカ作ったときに業者の創意工夫が見れておもろかった。

751 :デフォルトの名無しさん:2006/12/17(日) 22:28:43
>>748
U+FEFFをBOMと解釈すべきかzwnbspと解釈すべきかは細かく定められてる

752 :デフォルトの名無しさん:2006/12/17(日) 22:44:17
先頭にきたときだけBOMとして扱って、途中にでたときはZWNBSP?
たまたま先頭に来たZWNBSPとの区別が出来ないのは欠陥だよな。
ZWNBSPを先頭(BOM)以外には使えないようにするしかないのか。


753 :デフォルトの名無しさん:2006/12/17(日) 23:18:30
>>749
なんで Y なのかがさっぱりわからん。

754 :デフォルトの名無しさん:2006/12/17(日) 23:32:56
Y/N

755 :デフォルトの名無しさん:2006/12/17(日) 23:45:00
違う違う。先頭データって言っても1234Hって2バイト分書いてあるだけ。
そんなの見たって文字コードの種類なんてわかるわけない。
インテルのCPUはこれが、34,12にバイト毎に反転される。
複数バイトの場合にはいつもこうなる。この順番がバイトオーダ。
インテルのCPUが4ビットCPUの頃からずっとこんな調子。
1234Hに見えたら変換の必要なしということ。
S−JIS同士だろうがEUC同士だろうが、とにかくエンディアンが
違うとこうなっちゃう。16ビットコードだからとか、Unicodeとか
全く関係ない。文字コードの話と全く関係ないことだからさ。


756 :752:2006/12/18(月) 00:15:06
>>755
えーとオクテットで表現する形式としてのBOMではなくて、
UTF-7/8/16LE/16BE/32などのUnicodeとISO10646において
コードポイントとしてのU+FEFFをどう扱うかって話。


757 :デフォルトの名無しさん:2006/12/18(月) 01:41:36
そりゃもう規格名とバージョンの番号を書くくらいしか思いつかない。
つーか、バイトオーダとかエンディアンとかの単語が出てくるあたり
から完全に変な感じだったよ。
多分、一言でうまく切り分けられる表現そのものが無いとみた。
だって規格自体ががあやふやで、だから何度も作り直してるんだから。
それがちゃんと決まってるなら、簡潔に今それを言えるはず。

758 :デフォルトの名無しさん:2006/12/18(月) 01:55:46
>>757
Unicodeにバージョンがある時点でもう無理があるんだけど。
単にUTF-8と書いてもオクテットで表現する形式であって
Unicodeのどのバージョンですよ。みたいなことは分からんからね。
BOMとかXMLのバージョン表記みたいに先頭にバージョンを表現する
制御コードを書くぐらいしかないかもなぁ。

基本的に互換性を保っているものとして、処理するプログラムを開発した
時点における最新の規格に順ずる物とするのが現実的な回答か。

RFCでも後からでてきた拡張規格とかに対応してるかどうかは
問い合わせないとわからんことが多いしな。


759 :デフォルトの名無しさん:2006/12/18(月) 02:13:06
TCPとかIPとかMIMEはversionがヘッダに書いてあるだろ。

760 :デフォルトの名無しさん:2006/12/18(月) 02:24:04
>>759
MIMEヘッダでcharset=UTF-8って書いてあっても、どのUnicode規格に対応するかは
わからんよね。
区別する必要があるならUnicodeの中で制御コード割り振って対処するしかないんじゃない?


761 :デフォルトの名無しさん:2006/12/18(月) 20:54:01
UTF-8にバージョン番号を付けていないのは意図的

762 :デフォルトの名無しさん:2006/12/19(火) 00:58:39
えっと・・・
辻希美が「功名が辻+(')」を見て、どう思ってるのかな?
神奈川県逗子市の人にも聞いてみたい。
そんなことより、佐藤琢+(')磨についてYahooで検索しよっかなっと。
ついでに、辰良丈+(')一郎についても・・・これはやめておこう。


763 :デフォルトの名無しさん:2006/12/19(火) 01:02:35
もう、みんないろいろいってるが、これですべて解決



えい

764 :デフォルトの名無しさん:2006/12/20(水) 16:30:10
之繞がつく漢字は全て1点に統一して、
2点之繞にしたい時は後ろにU+300(COMBINING GRAVE ACCENT)を付ける事にしよう。
例:2点之繞の辻→U+8FBB U+300

765 :デフォルトの名無しさん:2006/12/20(水) 17:24:44
1文字1コード
こんなにもシンプルな事が何故できない

766 :デフォルトの名無しさん:2006/12/20(水) 17:48:03
>>764のようなアホなことを思いつく人がこれ上出ないように、
CJK用のVariation Selectorをさっさと何とかしてほしい・・・

767 :デフォルトの名無しさん:2006/12/20(水) 19:02:45
パとパとか1文字1コードじゃないものがソースだったり
変換先だったりするのでなかなか出来ない。
日本語以外の言語でどうなってるかは本当調べるのも大変


768 :デフォルトの名無しさん:2006/12/20(水) 19:30:08
それ以前に「何を1文字とするか」で合意するのが困難。

769 :デフォルトの名無しさん:2006/12/20(水) 19:50:34
`ま゛'


770 :デフォルトの名無しさん:2006/12/21(木) 07:28:15
>>769
それが認められたら画面にレンダリングする際に合成文字として表示しないと
いけないんだよね……
それをさらに右から左に表示したり……


771 :デフォルトの名無しさん:2006/12/21(木) 22:18:33
>>762
> 辻希美が「功名が辻+(')」を見て、どう思ってるのかな?
Vistaなので脳内JIS90レンダリングしないと意味不明です。
> ついでに、辰良丈+(')一郎についても・・・これはやめておこう。
それは別区点
>>770
COMBINING KATAKANA-HIRAGANA VOICED SOUND MARKだったら
その通りだけど>>769のはCOMBININGじゃないほうだから合成「してはいけない」

772 :デフォルトの名無しさん:2006/12/21(木) 22:20:16
>>766
もうレジストリはできてるから後はやる気の問題。
Adobeには期待してるんだけどねえ

773 :デフォルトの名無しさん:2006/12/21(木) 22:35:43
Unicode5.0になって楔形文字は入ったがエジプト聖刻文字が入らなかったのはちょっと残念。
でもこの辺全部サロゲートごりごりの領域だからアプリのほーが面倒だ(死

774 :デフォルトの名無しさん:2006/12/21(木) 23:04:30
もはやギャグの領域だな
そのうちナメック語とか
ニャントロ星人のドゴン語とか入りそうだ

775 :デフォルトの名無しさん:2006/12/22(金) 00:16:55
>>774
スタートレックのクリンゴン語はISO639言語コードに正式登録されてるぞ。
Unicodeにはいまのところ入ったりはしないだろうが、TRONは
文字として識別されるものならなんでも取り込むみたいだからなぁw

ttp://www.rikai.com/perl/LangMediator.En.pl?a=2004080445


776 :デフォルトの名無しさん:2006/12/22(金) 00:23:45
Klingon文字は正式に却下されとる。
ttp://www.unicode.org/consortium/utc-minutes/UTC-087-200105.html


777 :デフォルトの名無しさん:2006/12/22(金) 02:13:42
まぁISOで正式登録されたものは好きだろうが嫌いだろうが
実装しないといけない人もいるだろうし、大変ですね。


778 :デフォルトの名無しさん:2006/12/22(金) 03:13:39
アプリでサロゲートに対応するのそこまで大変じゃないでしょ。たいていの場合は。



779 :デフォルトの名無しさん:2006/12/22(金) 03:45:24
ここにいる人の中には大変な場合があるんでしょう。
たいていは通じませんよ。

780 :デフォルトの名無しさん:2006/12/22(金) 06:34:14
たいていは通じるだろ。上位サロゲートと下位サロゲートでちょんぎんなきゃいいだけ。
これだけのこと。


781 :デフォルトの名無しさん:2006/12/22(金) 13:58:25
i18n関係まともにやっているともっともっと大変な処理はたんまりありますぜ。
サロゲートなんかで大変と言っとると・・・


782 :デフォルトの名無しさん:2006/12/22(金) 14:53:09
テキスト入力ボックスなんて考えたくもない

783 :デフォルトの名無しさん:2006/12/23(土) 11:30:35
ttp://www.unicode.org/charts/PDF/UF900.pdf
U+FA20(草冠に龝)がU+8612(草冠に穐)と等価なのは何でだろう?
亀と龜なんて全然字形違うのに。


784 :デフォルトの名無しさん:2006/12/23(土) 11:39:39
字形と言われても困るんだが。
同じ系統に属する字だから等価と見做すcollationがあっても何の不思議もない。

785 :デフォルトの名無しさん:2006/12/23(土) 12:24:47
右から左への表示って、通常通りキャレットの位置計算から表示まで ほとんどを左から右に表示するよう実装して、
何気にOSか何かのAPIに用意されているだろう、座標系を設定する関数使って、反転させたら、
よかったりして。

786 :デフォルトの名無しさん:2006/12/23(土) 12:30:47
語学の教科書なんかでは、
行の途中の単語だけ逆にしなければいけないケースがあるんですよ。

787 :デフォルトの名無しさん:2006/12/23(土) 12:47:46
>>785
フォントも左右反転されてな

788 :デフォルトの名無しさん:2006/12/23(土) 17:07:32
U+FA11(立崎)とU+FA14(欅の略字)は崎や欅と等価とされてなくて、
統合漢字ブロックに等価な字が無い為「互換漢字ブロックにあるけど統合漢字とみなす字」とされてるわけだが。
何でU+FA20は違うんだろ?

789 :デフォルトの名無しさん:2006/12/23(土) 19:16:03
Unicodeに一貫性を求めちゃダメです

790 :デフォルトの名無しさん:2006/12/23(土) 22:58:44
WindowsXP SP2 の話ですが、
IMultiLanguage2::DetectInputCodepage() に Shift_JIS な
http://www.google.co.jp/ を GET したものを与えたら、
Shift_JIS とは全然関係ない CodePage として判定されてしまいました

これでは使えないので、Shift_JIS 等の一部の CodePage の判定は自前で
実装して特別扱いして回避しました

791 :デフォルトの名無しさん:2006/12/23(土) 23:47:13
>>788
いい同値関係を定義できたら、公表してください。
JISにある文字だけでもかなり有意義だと思います。

792 :デフォルトの名無しさん:2006/12/23(土) 23:55:52
>>790
googleはUTF-8ですけど。。。

793 :デフォルトの名無しさん:2006/12/24(日) 00:13:11
>>791
97JISの規格票はわりと気合が入ってる。
過去の規格との互換性のために妥協せざるを得なかったところもあるけど

794 :デフォルトの名無しさん:2006/12/24(日) 00:49:30
>>792
それは思い込みかと。User-Agent に応じて動作が変化するという認識です

795 :デフォルトの名無しさん:2006/12/24(日) 00:57:02
文字コードの自動認識は単純なロジックベースだとつらいかもな。
文字コード毎に出現する可能性があるか、ないかのビットマップでも
共通するコードしか出てこない場合は区別難しい。
ある程度長いソースで単語の辞書とか文字の出現頻度の統計とか
組み合わせればなんとかなるけど、短い文書はつらい。
テキストエディタで2文字だけ入力して保存して読み込んでみるとわかると思う。


796 :デフォルトの名無しさん:2006/12/24(日) 07:15:06
DetectInputCodepageはIEの判定処理そのものなんだから何かトチってるんだろ

797 :デフォルトの名無しさん:2006/12/24(日) 11:44:52
>>796
試しに Web 検索してみたら、これでコード判定出来ますと
サンプルを掲載しているサイトが結構ヒットしました

きっと試したファイル等が処理にやさしいものだったのでしょうね
(試したとは書いてなかったりしますが)

798 :デフォルトの名無しさん:2006/12/24(日) 12:06:04
Webに落ちてるサンプルって明らかに試してないだろお前ってもの結構あるよ
たとえば
http://www.wac-jp.com/programmers/win32/Probe_IsUserAnAdmin.html
> // Win2000 Pro : 管理者, 制限ユーザー で正常に動作
> FUNC_ISUSERANADMIN func = (FUNC_ISUSERANADMIN)module.GetProcAddress(_T("IsUserAnAdmin"));
Win2kのIsUserAnAdminは名前でエクスポートされてねーよ

799 :デフォルトの名無しさん:2006/12/24(日) 13:14:01
>>798
駄目サンプル晒しsageは基本的にウザイのだが、
せめて文字コード関連のサンプルを挙げてくれよん。

>>793
互換性妥協無し差分規則って公開している人いるのかね?
俺は一度マイルールを作りかけたことあるけど、量が多すぎて挫折した。
統一された基準を作り出すのは本当に大変。

800 :デフォルトの名無しさん:2006/12/24(日) 15:42:58
>>787
それだよ。俺もフォントまで反転されそうな気がするけど、ひょっとして、フォントとかだけは、普通に
表示されるオプションとかあるのかもしれないと意味で、最後に「よかったりして」って付け加えた。


801 :デフォルトの名無しさん:2006/12/24(日) 16:32:33
それだよw

802 :デフォルトの名無しさん:2006/12/24(日) 16:34:54
どれだよ

803 :デフォルトの名無しさん:2006/12/24(日) 21:03:54
>>799
6.3.3だけ見て残りの部分や適用除外(規定)は見なかったふりをする

804 :デフォルトの名無しさん:2006/12/25(月) 13:17:35
>>803
それだと「王」と「壬」まで包摂しちゃうことになるぞ。

805 :デフォルトの名無しさん:2006/12/26(火) 10:19:37
ああ〜もぅーややこしすぎ

806 :デフォルトの名無しさん:2006/12/26(火) 14:26:47
口ロ□
。oOoO○


807 :デフォルトの名無しさん:2006/12/26(火) 15:12:29
適用除外のうち「王・壬」だけを残して他を無視すりゃOKじゃね?

808 :デフォルトの名無しさん:2006/12/27(水) 22:15:01
「王・壬」以外は大丈夫っぽい。つーかこんな罠がのっけからあるとは思わなかったorz

809 :デフォルトの名無しさん:2006/12/30(土) 16:25:19
>>808
他にも包摂規準 64 (且/旦)、70 (己/巳)、124 (犬/大) あたりが
「単独字では別字だけど、部分字体で入れ換わるのは当たり前」
な文字。他にも 69,77-78,83,91 のようなマニアックなのはあるけど
この3つは常用される。

特に注意を要するのが包摂規準100 (東/柬)。単独字では別字、
部分字体では基本的に包摂だけど、棟(むね)/楝(おうち)は別字、
鶇/鶫はうっかり両方とも入れてしまったので包摂分離。
X 0213 で新たに包摂分離になったのが錬と練(常用漢字表の
康煕別掲字体)だけど、金へんはU+932C/U+934AとUROで区別
できるのに対し、{糸柬} はU+7DF4/U+FA57と互換漢字を要し、
扱いに差がある。



810 :デフォルトの名無しさん:2006/12/31(日) 00:40:39
>>809
> 他にも包摂規準 64 (且/旦)、70 (己/巳)、124 (犬/大) あたりが
なんでそれらの単独字は適用除外(規定)に入ってないんだ?
王/壬がなければ「単独字には適用できない」と解釈できたんだが…。
包摂規準 1 には3つ目の部分字体があることと関係してるのか?

811 :デフォルトの名無しさん:2006/12/31(日) 04:22:42
>>810
> なんでそれらの単独字は適用除外(規定)に入ってないんだ?

むしろ王壬が載っているのがバグと考えるべきかも。

基本は
| 6.6.3 漢字の字体の包摂規準
| b) 包摂規準は,他のいずれかの漢字までを包摂するような適用を行ってはならない。
があるので、リストアップは無しでも問題ないはず。

でもそれだとあまりに不親切なので、JIS が一貫性無く収録してしまった
包摂字体に関してはきちんと情報提供しようという意図があるのでは?
棟諫鶇が載ってて楝諌鶇が載ってないのは載せなくても分かるからだろう
し、一方、初版に載っていなかった「仭」が正誤票で追加されているのは
必要があると判断されたからににちがいない。

少なくともリストで包摂除外を網羅的に規定していると判断してはならないのは
確か。単独字以外にも「任≠j」とかあるわけで、こういうJIS 外字との
別字衝突は調べきれない。
だから 6.6.1 に「また,ここで規定する包摂規準を部分字体として演繹的に
適用することによって,新たな漢字字体を作り上げてはならない。」と書いて
済ませているわけで、実装者にある程度の文字の常識を要請している。

これを最初に読んだ時は「工業規格の規定がこれでいいのか」と思ったけど、
今は仕方ないと思っている。そこまで規定できるための情報を集めようと
思ったら、今になっても規格ができてないだろうから。

812 :デフォルトの名無しさん:2006/12/31(日) 11:12:13
> 単独字以外にも「任≠j」とかあるわけで、こういうJIS 外字との
> 別字衝突は調べきれない。
包摂規準はJIS外字との衝突はあまり考慮していないと思われ
JIS X 0212と比べてさえこれだけ類型異字の候補が出てくるし。
http://wakaba-web.hp.infoseek.co.jp/0212-0213/jisx0212-0213.ja.html

そもそもここでの最初のリクエストが
> JISにある文字だけでも
だったからそのへんは気にしてなかった。どうしても欲が出てくるんだろうけど

813 :デフォルトの名無しさん:2006/12/31(日) 15:52:43
なんか、扱える文字増えたけどさ、合成文字だの左から右に読む文字だの、色々面倒なことの方がたくさん増えたな。
もう、なんたらJISの方が楽じゃねぇ??まぁ、MicrosfotのMS932への文字の追加が止まってるのが痛いけど。


814 :デフォルトの名無しさん:2006/12/31(日) 16:28:34
KISSの法則

815 :デフォルトの名無しさん:2006/12/31(日) 17:48:32
あんまり(というかほとんど)文字コードについて詳しくないんですが、
>>804-あたりからの問題について意識ししないでシステムを作ったとすると
具体的にどのような問題が起こりえるのでしょうか?


816 :デフォルトの名無しさん:2007/01/01(月) 15:34:43
>>815
フォントの実装でもしない限りプログラマにとってはあまり関係ない。
漢字ヲタクが気にするような問題

817 :デフォルトの名無しさん:2007/01/01(月) 15:35:48
>>813
いまどきのプログラミング言語はふつー内部Unicodeなので変換の手間が増えるだけで
何もうれしくない

818 :デフォルトの名無しさん:2007/01/01(月) 16:42:57
>>817
そうだけど、自前で、表示、入力しようと思ったら手間がかかる。合成だのなんだの。


819 :デフォルトの名無しさん:2007/01/01(月) 16:51:02
ペイントソフトの文字の入力描画とかを作るのは大変ってことか

820 :デフォルトの名無しさん:2007/01/01(月) 21:59:12
>>816
そうですか。ありがとうございました

821 :デフォルトの名無しさん:2007/01/04(木) 19:44:49
文字コードのエンコーディングを自動判定するツール/ライブラリで
日本語以外も判定できるのって何がお勧め?
いま、とりあえずiconvでShift_JIS,WINDOWS-31J,EUC-JPからUTF-8への変換でエラーが
でるかどうかの情報とNKFでのguessとEncaでの判定とMozillaベースのCharGuessってライブラリ
での判定をまとめてみてるんだけど、まだ情報としてたりない気がするんだよね。
windows-1252のあたりが微妙な結果。
完璧な自動判定は無理だと思うのでなるべく多くのアルゴリズムで判定させたいんだけど
何かいいものあるかな?


822 :デフォルトの名無しさん:2007/01/04(木) 20:14:05
>>821
MLang( IE で使われている文字コード処理エンジン )は、どう?
そういえば、テンプレに MLang が入っとらんね。

823 :デフォルトの名無しさん:2007/01/04(木) 22:01:26
>>821
ありがとうございます。
MLang試してみます。
ファイルが置いてあるのはLinuxなのですが、Sambaで共有して
Windowsから判定させてみますね。


824 :821=823:2007/01/04(木) 22:02:00
>>822
すいませんアンカー間違えました。



825 :デフォルトの名無しさん:2007/01/06(土) 17:22:46
Windows-1252で0x81が未定義なのはやっぱりShift_JISとの判別精度を
上げるためなんだろうか

826 :デフォルトの名無しさん:2007/01/17(水) 15:37:31
>>816
サーバサイドの場合、ブラウザからの入力文字がシステム内部で化ける可能性があるから関係してくる。

画面、DBを含めシステム全体で文字をUNICODEで扱っていれば問題ないが、一部でも文字変換をしていた場合、化けたり、文字チェックや文字数チェックで誤作動する可能性がでてくるでしょ。

だから、一概に関係無い話とは言い切れないのでは?

827 :デフォルトの名無しさん:2007/01/17(水) 20:37:56
n-gramやるにはサンプルデータ用意するのが面倒なので
手軽にバイト単位のヒストグラムを作ってモデルとの差分を
積算するプログラムを書いてみた。

……なぜWindowsのシステムファイルとCygwinのバイナリを区別できる?
テキストでもそれなりに判別できそうな予感。


828 :デフォルトの名無しさん:2007/01/17(水) 21:47:22
Unicode の文字列から「一文字ずつ」切り出す処理って、どうやったらいいんでしょう。
まあ素朴に、 "一文字ずつ" -> '一' '文' '字' 'ず' 'つ' みたいな。
Unicode の場合、例えば「ず」が「す+濁点」に分解されている場合があって、
面倒なようですが。

つきつめていくと「『一文字』って何?」ということにもなるのかな...
まとにかく、こういう目的に適したライブラリとかってありますか?

829 :デフォルトの名無しさん:2007/01/17(水) 22:30:03
‏一文字‎ずつ‌?


830 :デフォルトの名無しさん:2007/01/17(水) 22:34:18
‏ICUとかで正規化して自分が考える一文字で‎正規表現マッチさせればいいんじゃない?
制‌御‌文‌字‌と‌か‌は‌消さないと駄目かもねぇ。


831 :830:2007/01/17(水) 22:41:40
>>830
こういうの対応するのめんどくせーよな。
単語で検索してもマッチしないし^^;
NGWordもうまく動いてくれない……


832 :デフォルトの名無しさん:2007/01/17(水) 23:03:08
>>826
いや、>>804-の問題はそれとはぜんぜん関係ない。
まさに「複数の問題を混同しがちな〜」というやつだな

833 :デフォルトの名無しさん:2007/01/19(金) 10:34:54
>>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

834 :830:2007/01/19(金) 20:20:53
830を「制御」で検索くらい試して欲しかったところ。
SETTING.TXTにBBS_UNICODE=passってなってると
ユニコード使えるんだねぇ。

文字を分割して、また結合したら別のものになる可能性があるから面倒だよなぁ。

ZERO WIDTHとかフィッシングに最適^^;


835 :056:2007/01/19(金) 21:08:48
文字コードに関して誤った情報を掲載しているPDFファイルってインターネット上にありますか?

836 :デフォルトの名無しさん:2007/01/19(金) 21:40:45
五万とあるだろ

837 :056:2007/01/19(金) 23:10:44
よかったらURL教えてください?

838 :デフォルトの名無しさん:2007/01/20(土) 01:06:43
なぜにPDF限定?

839 :デフォルトの名無しさん:2007/01/20(土) 10:57:57
なぜに「誤った」情報?

840 :デフォルトの名無しさん:2007/01/20(土) 13:22:41
【ネガティブ派遣根性チェック】

3つ以上、思い当たる点があればアナタの性格はひん曲がっており、ネガティブ負け組人生を歩んでいます。

□派遣先の人事権のある社員の意見はたとえ間違っていてもマンセーする
□派遣先から「いつまでもここで仕事してくださいね(安い金でw)」と言われている
□自社に仕事を持ち帰れるように言われるとムカつく
□自社で仕事なんてできるわけがない
□派遣労働の問題点の話題が出ると感情剥き出しにする
□派遣労働の問題を指摘する人は嫌いだ
□派遣先には仕事だけでなく自分のプライベートについても指示して欲しい
□自分の月額金額を知らない
□派遣先社員より自分の生涯収入が低いのは当然だ
□派遣先に尻尾を振り、いつまでも派遣を続けることが大切だ


841 :デフォルトの名無しさん:2007/01/20(土) 16:32:29
森山さんとこの掲示板にも同じような質問が……

842 :デフォルトの名無しさん:2007/01/23(火) 02:17:09
今WindowsMobile5.0で開発をしてるんですが、IMultiLanguage2
インターフェイスが作成できない(E_NOINTERFACE)んです。
IMultiLanguage2::DetectInputCodepageで読み取ったchar配列の
文字コードの判定をやりたいんですけど、
何かこれに代わる方法はありませんか?
無印の方は変換だけで、この関数は使えないんです。

IMLangConvertCharsetの初期化時にMLCONVCHARF_AUTODETECTを
つければ良さそうな気がしていろいろ試したんですがうまく動きません。
よろしくお願いします。

843 :デフォルトの名無しさん:2007/01/23(火) 22:16:01
nkf

844 :デフォルトの名無しさん:2007/01/26(金) 02:05:13
US-ASCIIかどうかの判定で0x20-0x7eという範囲指定じゃ駄目なんだな。
うぅISO646とか生まれる前からの呪いがまだ続いているよ……
ISO-8859系を前提にいれても無理やり入ってくるシフトJIS……
0x5cと0x7eは外しておいたほうが安全だな。


845 :デフォルトの名無しさん:2007/01/29(月) 04:10:02
多言語の文字コードを調べようと思ったらStarDictというのを見つけた。
文字コードというか、辞書のソフトなんだがフリーで使える辞書の数がやたらと多い。
出現頻度とかの統計情報としては使えないが、Word-listの作成ソースとしては使える。


846 :デフォルトの名無しさん:2007/01/29(月) 10:15:06
>>844
> US-ASCIIかどうかの判定で0x20-0x7eという範囲指定じゃ駄目なんだな。

どんだけずぼらなんだw

847 :デフォルトの名無しさん:2007/02/04(日) 05:06:46
Unicode文字列の特定のキーワードの強調表示って本来どうあるべきかな??
例えば、キーワードがaaaaとして、aaaaウムラウトの文字列を強調表示とか
で文字列を検索するときaaaaとウムラウトで分断すべきかな??
つまり、表示上もaaaaとウムラウトで分断して表示すべきなかな?ややこしいな。

848 :デフォルトの名無しさん:2007/02/04(日) 12:51:30
>>847
* あいまい検索とみなして、aaaaウムラウト、まで強調する
* 完全一致とみなして、全く強調しない
の二択だと思う。
「aaaaウムラウト」の「aaaa」だけ強調っていうのは、合成文字だって意識すると自然だけど、
ユーザ的には「aウムラウト」で「一文字」でしょ。

849 :デフォルトの名無しさん:2007/02/06(火) 01:44:55
置換処理のような機械的なものと違って、強調表示の場合は
ユーザーが文字として認識する物を対象にするのが自然だと思う。
a+ウムラウトをaと見なすかどうかをオプションとしてユーザに選択させるのがいいんじゃないかな。
ただ、曖昧検索はどこまで曖昧かが難しいところもあるな。
「スーパーマン」が「ス-パ-マン」にマッチするかとか。
「ま゜」とか「み゛」とかやめてくれw


850 :デフォルトの名無しさん:2007/02/06(火) 02:01:43
847です。
>>848,>>849ありがとうございます。いわいる前にもでてた、書記素(grapheme)のことですね。
今は単純な文字コードをマッチングしてるだけですが、完全一致するとなると、書記素を分割しないようにアルゴリズム
変えなきゃいけなさそうですね。うーん。あいまい検索にしてもいろいろ面倒そうですね。


210 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)