982コメント325KB

文字コード総合スレ part2

レス数が950を超えています。1000を超えると書き込みができなくなります。

0001デフォルトの名無しさん

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

0002デフォルトの名無しさん

2006/03/26(日) 21:24:41

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

0003デフォルトの名無しさん

2006/03/26(日) 21:38:29

ここまで読んだ！

0004デフォルトの名無しさん

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

0005道化師

2006/03/27(月) 00:20:23

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

0006デフォルトの名無しさん

2006/03/27(月) 03:33:13

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

0007デフォルトの名無しさん

2006/03/28(火) 00:51:48

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

0008デフォルトの名無しさん

2006/03/28(火) 13:08:43

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

0009デフォルトの名無しさん

2006/04/05(水) 01:27:49

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

0010デフォルトの名無しさん

2006/04/06(木) 00:57:29

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

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

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

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

0011デフォルトの名無しさん

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」と
（多分嘘が）書いてあるだけで、さっぱり判らん。

0012デフォルトの名無しさん

2006/04/06(木) 16:10:16

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

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

0013デフォルトの名無しさん

2006/04/06(木) 19:26:59

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

0014デフォルトの名無しさん

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 についてもリンクにあります。

0015デフォルトの名無しさん

2006/04/07(金) 14:07:28

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

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

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

0016デフォルトの名無しさん

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 -> CP5022ｘって変換な気もするね。
U+00A9 Copyright Sign ->0x63
とかもあったし。

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

0017デフォルトの名無しさん

2006/04/07(金) 16:39:02

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

0018デフォルトの名無しさん

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」ってのがあるのかも知らんけど。

0019デフォルトの名無しさん

2006/04/12(水) 17:35:33

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

0020デフォルトの名無しさん

2006/04/12(水) 17:38:27

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

0021デフォルトの名無しさん

2006/04/12(水) 22:02:34

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

0022デフォルトの名無しさん

2006/04/13(木) 23:38:44

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

0023デフォルトの名無しさん

2006/04/14(金) 10:34:45

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

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

0024デフォルトの名無しさん

2006/04/14(金) 11:49:49

>>23
つ[胸の豊かさ]

0025デフォルトの名無しさん

2006/04/14(金) 12:07:03

s/胸/乳房/

0026デフォルトの名無しさん

2006/04/14(金) 13:46:49

貧乳順

0027デフォルトの名無しさん

NGNG

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

0028デフォルトの名無しさん

2006/04/14(金) 17:43:01

ちちあつヨーグルト

0029デフォルトの名無しさん

2006/04/14(金) 19:18:59

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

0030乳関数

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

0031デフォルトの名無しさん

2006/04/15(土) 20:56:00

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

0032デフォルトの名無しさん

2006/04/15(土) 22:07:55

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

0033デフォルトの名無しさん

2006/04/16(日) 20:03:36

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

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

0034デフォルトの名無しさん

2006/04/16(日) 20:36:21

UTF-16です

0035デフォルトの名無しさん

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 で統一されていようが
固定長であれば構わない、ということだったと
思うのですが、正しいでしょうか？

0036デフォルトの名無しさん

2006/04/16(日) 23:55:58

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

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

0037デフォルトの名無しさん

2006/04/17(月) 00:03:26

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

0038デフォルトの名無しさん

2006/04/17(月) 04:22:27

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

0039デフォルトの名無しさん

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 です。

0040デフォルトの名無しさん

2006/04/17(月) 11:01:33

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

0041デフォルトの名無しさん

2006/04/17(月) 16:45:13

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

0042デフォルトの名無しさん

2006/04/17(月) 17:22:20

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

0043デフォルトの名無しさん

2006/04/17(月) 17:30:03

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

0044デフォルトの名無しさん

2006/04/17(月) 17:39:43

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

0045デフォルトの名無しさん

2006/04/17(月) 17:44:04

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

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

0046デフォルトの名無しさん

2006/04/17(月) 18:07:11

なるほど

0047デフォルトの名無しさん

2006/04/17(月) 18:09:55

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

0048デフォルトの名無しさん

2006/04/17(月) 22:55:35

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

0049デフォルトの名無しさん

2006/04/18(火) 22:40:25

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

0050デフォルトの名無しさん

2006/04/18(火) 23:12:09

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

0051デフォルトの名無しさん

2006/04/18(火) 23:27:21

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

0052デフォルトの名無しさん

2006/04/19(水) 03:47:12

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

0053デフォルトの名無しさん

2006/04/19(水) 12:08:09

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

0054デフォルトの名無しさん

2006/04/19(水) 12:15:59

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

0055デフォルトの名無しさん

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 (後略)]

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

0056デフォルトの名無しさん

2006/04/19(水) 17:20:49

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

0057デフォルトの名無しさん

2006/04/20(木) 03:56:45

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

0058デフォルトの名無しさん

2006/04/20(木) 04:09:08

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

0059デフォルトの名無しさん

2006/04/20(木) 09:47:49

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

0060デフォルトの名無しさん

2006/04/20(木) 10:08:45

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

0061デフォルトの名無しさん

2006/04/20(木) 17:17:53

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

0062デフォルトの名無しさん

2006/04/20(木) 18:01:43

ないわけないじゃん。

0063デフォルトの名無しさん

2006/04/21(金) 01:09:16

>>61
unicode.orgへ行け。

0064デフォルトの名無しさん

2006/04/21(金) 03:35:22

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

0065デフォルトの名無しさん

2006/04/27(木) 20:35:48

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

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

0066デフォルトの名無しさん

2006/05/10(水) 16:20:02

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

0067デフォルトの名無しさん

2006/05/10(水) 18:27:26

符号化方式による。

0068デフォルトの名無しさん

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バイト

0069デフォルトの名無しさん

2006/05/13(土) 17:27:04

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

0070デフォルトの名無しさん

2006/05/16(火) 18:33:36

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

0071デフォルトの名無しさん

2006/05/16(火) 18:49:37

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

0072デフォルトの名無しさん

2006/05/16(火) 18:57:49

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

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

0073デフォルトの名無しさん

2006/05/16(火) 18:58:18

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

0074デフォルトの名無しさん

2006/05/16(火) 20:02:40

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

0075デフォルトの名無しさん

2006/05/16(火) 21:27:34

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

0076デフォルトの名無しさん

2006/05/16(火) 21:33:53

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

0077デフォルトの名無しさん

2006/05/17(水) 04:37:51

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

0078デフォルトの名無しさん

2006/05/17(水) 07:23:51

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

0079デフォルトの名無しさん

2006/05/17(水) 07:34:20

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

0080デフォルトの名無しさん

2006/05/17(水) 07:49:52

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

0081デフォルトの名無しさん

2006/05/17(水) 07:59:40

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

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

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

0082デフォルトの名無しさん

2006/05/17(水) 21:19:57

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

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

0083デフォルトの名無しさん

2006/05/18(木) 05:52:43

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

0084デフォルトの名無しさん

2006/05/18(木) 08:07:20

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

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

0085デフォルトの名無しさん

2006/05/18(木) 17:56:56

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

0086デフォルトの名無しさん

2006/05/18(木) 18:19:38

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

0087デフォルトの名無しさん

2006/05/18(木) 18:22:39

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

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

0088デフォルトの名無しさん

2006/05/18(木) 19:32:12

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

0089デフォルトの名無しさん

2006/05/18(木) 19:54:55

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

0090デフォルトの名無しさん

2006/05/19(金) 09:26:13

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

0091デフォルトの名無しさん

2006/05/19(金) 11:16:31

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

という話。

0092デフォルトの名無しさん

2006/05/19(金) 11:26:08

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

0093デフォルトの名無しさん

2006/05/19(金) 11:39:30

>>72じゃねの？

0094デフォルトの名無しさん

2006/05/19(金) 15:05:03

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

0095デフォルトの名無しさん

2006/05/19(金) 23:27:46

俺もUCS4でいいと思う。

0096デフォルトの名無しさん

2006/05/20(土) 06:08:59

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

0097デフォルトの名無しさん

2006/05/20(土) 09:52:18

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

0098デフォルトの名無しさん

2006/05/23(火) 04:14:50

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

char c = '字';

0099デフォルトの名無しさん

2006/05/23(火) 04:50:45

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

0100デフォルトの名無しさん

2006/05/24(水) 00:22:53

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

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

0101デフォルトの名無しさん

2006/05/24(水) 11:39:49

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

0102デフォルトの名無しさん

2006/05/24(水) 22:12:51

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

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

0103デフォルトの名無しさん

2006/05/24(水) 23:27:14

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

0104デフォルトの名無しさん

2006/05/25(木) 00:35:04

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

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

0105デフォルトの名無しさん

2006/05/25(木) 01:41:35

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

0106デフォルトの名無しさん

2006/05/25(木) 16:14:44

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

0107デフォルトの名無しさん

2006/05/25(木) 23:23:25

くだらん事を言うな

0108デフォルトの名無しさん

2006/05/25(木) 23:27:26

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

0109デフォルトの名無しさん

2006/05/26(金) 00:15:14

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

0110デフォルトの名無しさん

2006/05/26(金) 01:25:49

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

0111デフォルトの名無しさん

2006/05/26(金) 02:06:52

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

0112デフォルトの名無しさん

2006/05/26(金) 08:14:03

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

0113デフォルトの名無しさん

2006/05/26(金) 13:03:55

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

0114デフォルトの名無しさん

2006/05/27(土) 15:45:05

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

0115デフォルトの名無しさん

2006/05/28(日) 13:48:40

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

0116デフォルトの名無しさん

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

0117デフォルトの名無しさん

2006/05/29(月) 01:31:59

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

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

0118デフォルトの名無しさん

2006/05/29(月) 16:44:39

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

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

0119デフォルトの名無しさん

2006/05/29(月) 18:19:56

補足。

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

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

0120デフォルトの名無しさん

2006/05/29(月) 18:35:22

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

0121デフォルトの名無しさん

2006/05/29(月) 18:47:37

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

0122118

2006/05/29(月) 20:32:34

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

0123デフォルトの名無しさん

2006/06/03(土) 04:48:05

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

0124デフォルトの名無しさん

2006/06/03(土) 09:38:01

>>123
いいえ。

0125デフォルトの名無しさん

2006/06/03(土) 11:31:03

>>124
いいえって何が?

0126デフォルトの名無しさん

2006/06/03(土) 14:08:30

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

0127デフォルトの名無しさん

2006/06/03(土) 17:57:35

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

0128デフォルトの名無しさん

2006/06/04(日) 05:04:37

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

0129デフォルトの名無しさん

2006/06/04(日) 05:52:32

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

0130デフォルトの名無しさん

2006/06/04(日) 06:03:27

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

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

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

0131デフォルトの名無しさん

2006/06/08(木) 16:00:56

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

0132デフォルトの名無しさん

2006/06/08(木) 16:31:43

0xA0000 からだっけ？

0133デフォルトの名無しさん

2006/06/08(木) 22:07:26

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

0134デフォルトの名無しさん

2006/06/09(金) 00:59:17

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

0135デフォルトの名無しさん

2006/06/09(金) 04:16:32

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

0136デフォルトの名無しさん

2006/06/12(月) 23:03:13

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

0137デフォルトの名無しさん

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 機種依存文字が変換できない。
>
>これらの問題を解決するために、オープンソースソフトウェアで、次のキャラクタセットを使えるようにします。

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

0138デフォルトの名無しさん

2006/06/17(土) 08:31:02

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

0139デフォルトの名無しさん

2006/06/17(土) 10:23:50

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

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

0140デフォルトの名無しさん

2006/06/17(土) 10:45:05

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

0141デフォルトの名無しさん

2006/06/17(土) 22:32:25

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

0142デフォルトの名無しさん

2006/06/18(日) 08:50:35

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

0143デフォルトの名無しさん

2006/06/18(日) 13:38:19

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

0144デフォルトの名無しさん

2006/06/18(日) 13:47:11

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

0145デフォルトの名無しさん

2006/06/18(日) 13:50:18

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

0146デフォルトの名無しさん

2006/06/18(日) 13:54:45

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

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

0147デフォルトの名無しさん

2006/06/18(日) 17:40:44

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

0148デフォルトの名無しさん

2006/06/18(日) 21:53:36

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

0149デフォルトの名無しさん

2006/06/18(日) 22:39:34

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

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

0150デフォルトの名無しさん

2006/06/18(日) 22:43:05

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

0151デフォルトの名無しさん

2006/06/19(月) 15:33:23

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

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

0152デフォルトの名無しさん

2006/06/19(月) 23:07:37

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

0153デフォルトの名無しさん

2006/06/20(火) 12:28:19

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

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

今後CP932は不要。

0154デフォルトの名無しさん

2006/06/20(火) 12:36:09

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

0155デフォルトの名無しさん

2006/06/20(火) 12:44:49

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

0156デフォルトの名無しさん

2006/06/20(火) 12:46:57

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

0157デフォルトの名無しさん

2006/06/20(火) 13:13:08

マカーｳｻﾞｽ

0158デフォルトの名無しさん

2006/06/20(火) 13:15:40

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

0159デフォルトの名無しさん

2006/06/20(火) 13:17:59

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

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

0160デフォルトの名無しさん

2006/06/20(火) 14:20:00

>>155
ヒント：ブラウザ

0161デフォルトの名無しさん

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

0162デフォルトの名無しさん

2006/06/20(火) 19:10:23

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

0163159

2006/06/20(火) 19:12:50

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

0164デフォルトの名無しさん

2006/06/20(火) 19:19:53

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

0165デフォルトの名無しさん

2006/06/21(水) 00:40:52

>>153
>今後CP932は不要。

永遠に不滅でつ。

0166デフォルトの名無しさん

2006/06/21(水) 02:09:17

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

0167デフォルトの名無しさん

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

0168デフォルトの名無しさん

2006/06/21(水) 13:08:41

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

0169デフォルトの名無しさん

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

なのが意味不明。

0170デフォルトの名無しさん

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で、データを入力フォームに自動的に引用とか?

0171デフォルトの名無しさん

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

0172デフォルトの名無しさん

2006/06/24(土) 17:20:40

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

0173デフォルトの名無しさん

2006/06/24(土) 22:25:12

はげしーくどうい

0174デフォルトの名無しさん

2006/06/25(日) 02:43:18

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

0175デフォルトの名無しさん

2006/06/25(日) 03:01:51

ucs2だったような希ガス

0176デフォルトの名無しさん

2006/06/26(月) 02:13:41

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

0177デフォルトの名無しさん

2006/06/26(月) 02:44:38

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

0178デフォルトの名無しさん

2006/06/26(月) 23:23:59

直井靖氏?

0179デフォルトの名無しさん

2006/07/22(土) 00:25:19

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

0180デフォルトの名無しさん

2006/07/22(土) 02:44:57

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

0181デフォルトの名無しさん

2006/07/22(土) 02:46:13

で、何バイト？

0182デフォルトの名無しさん

2006/07/22(土) 17:27:34

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

解明してください。

0183デフォルトの名無しさん

2006/07/23(日) 02:08:39

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

0184デフォルトの名無しさん

2006/07/23(日) 02:14:05

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

0185デフォルトの名無しさん

2006/07/23(日) 05:46:30

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

0186デフォルトの名無しさん

2006/07/23(日) 08:29:16

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

0187デフォルトの名無しさん

2006/07/23(日) 18:16:32

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

0188デフォルトの名無しさん

2006/07/24(月) 09:49:32

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

0189デフォルトの名無しさん

2006/07/25(火) 17:31:53

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

0190デフォルトの名無しさん

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

0191デフォルトの名無しさん

2006/07/25(火) 20:50:05

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

0192デフォルトの名無しさん

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（アイヌ語表記用小書きカタカナ）も入ってないよね。

0193デフォルトの名無しさん

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は入ってない)

0194デフォルトの名無しさん

2006/07/26(水) 20:39:09

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

0195デフォルトの名無しさん

2006/08/12(土) 12:08:53

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

0196デフォルトの名無しさん

2006/08/12(土) 14:05:14

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

0197デフォルトの名無しさん

2006/08/12(土) 16:21:04

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

0198デフォルトの名無しさん

2006/08/12(土) 16:54:41

TRONコードにしろと？

0199デフォルトの名無しさん

2006/08/12(土) 22:28:32

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

0200デフォルトの名無しさん

2006/08/14(月) 23:33:17

超…...

0201デフォルトの名無しさん

2006/08/15(火) 00:33:22

感じ悪い

0202デフォルトの名無しさん

2006/08/15(火) 08:59:09

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

0203デフォルトの名無しさん

2006/08/16(水) 22:21:04

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

0204デフォルトの名無しさん

2006/08/16(水) 23:42:57

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

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

0205デフォルトの名無しさん

2006/08/17(木) 03:11:30

>>203
甘過ぎ

0206デフォルトの名無しさん

2006/08/17(木) 16:04:46

>>196
1文字64ビット

0207デフォルトの名無しさん

2006/08/17(木) 20:24:59

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

0208デフォルトの名無しさん

2006/08/17(木) 20:28:39

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

0209デフォルトの名無しさん

2006/08/18(金) 11:36:28

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

0210デフォルトの名無しさん

2006/08/18(金) 12:14:13

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

0211デフォルトの名無しさん

2006/08/18(金) 12:15:49

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

0212デフォルトの名無しさん

2006/08/18(金) 14:34:51

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

0213デフォルトの名無しさん

2006/08/18(金) 15:11:09

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

0214デフォルトの名無しさん

2006/08/19(土) 00:26:27

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

0215デフォルトの名無しさん

2006/08/19(土) 02:19:16

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

0216デフォルトの名無しさん

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　等はきちんと使用しているのですが・・・

0217デフォルトの名無しさん

2006/08/23(水) 22:16:56

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

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

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

0218デフォルトの名無しさん

2006/08/24(木) 00:08:13

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

0219デフォルトの名無しさん

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
のようになる。その４バイト目の 0000 を lstrlen が文字列の
終端だとみなすために文字列の長さは３とみなされる。

0220デフォルトの名無しさん

2006/08/24(木) 09:24:12

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

0221デフォルトの名無しさん

2006/08/24(木) 09:42:34

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

0222デフォルトの名無しさん

2006/08/24(木) 14:24:49

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

0223デフォルトの名無しさん

2006/08/24(木) 14:31:40

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

な？

0224デフォルトの名無しさん

2006/08/24(木) 14:37:06

>>222

0225デフォルトの名無しさん

2006/08/24(木) 14:42:12

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

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

0226デフォルトの名無しさん

2006/08/24(木) 15:32:56

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

0227デフォルトの名無しさん

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 になるんでしょ。

0228デフォルトの名無しさん

2006/08/24(木) 22:14:57

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

0229デフォルトの名無しさん

2006/09/09(土) 02:00:07

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

0230デフォルトの名無しさん

2006/09/09(土) 02:09:52

BOM?

0231デフォルトの名無しさん

2006/09/09(土) 02:15:48

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

0232229

2006/09/09(土) 02:22:41

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

0233デフォルトの名無しさん

2006/09/09(土) 02:39:31

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

0234デフォルトの名無しさん

2006/09/09(土) 05:36:16

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

0235デフォルトの名無しさん

2006/09/09(土) 09:45:13

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

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

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

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

0236デフォルトの名無しさん

2006/09/09(土) 13:29:53

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

0237デフォルトの名無しさん

2006/09/09(土) 17:16:47

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

0238デフォルトの名無しさん

2006/09/09(土) 22:44:12

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

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

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

0239デフォルトの名無しさん

2006/09/10(日) 03:12:21

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

0240デフォルトの名無しさん

2006/09/10(日) 14:11:11

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

0241デフォルトの名無しさん

2006/09/10(日) 16:15:19

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

0242デフォルトの名無しさん

2006/09/10(日) 19:29:18

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

0243>>234=>>238だが…

2006/09/11(月) 09:45:30

>>241

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

0244デフォルトの名無しさん

2006/09/11(月) 23:07:09

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

0245デフォルトの名無しさん

2006/09/11(月) 23:49:17

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

0246デフォルトの名無しさん

2006/09/12(火) 00:54:08

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

次は機種依存文字。

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

0247デフォルトの名無しさん

2006/09/12(火) 00:56:54

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

0248デフォルトの名無しさん

2006/09/12(火) 01:37:10

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

0249デフォルトの名無しさん

2006/09/12(火) 03:20:37

人生とは旅であって、

0250デフォルトの名無しさん

2006/09/12(火) 06:56:16

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

0251デフォルトの名無しさん

2006/09/12(火) 13:26:17

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

0252デフォルトの名無しさん

2006/09/12(火) 14:38:20

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

0253デフォルトの名無しさん

2006/09/12(火) 15:22:46

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

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

0254デフォルトの名無しさん

2006/09/12(火) 20:55:21

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

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

0255デフォルトの名無しさん

2006/09/13(水) 05:18:57

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

0256デフォルトの名無しさん

2006/09/13(水) 05:25:51

ぷ

0257デフォルトの名無しさん

2006/09/13(水) 05:32:22

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

0258デフォルトの名無しさん

2006/09/13(水) 15:16:04

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

0259デフォルトの名無しさん

2006/09/13(水) 20:51:25

>>162

0260デフォルトの名無しさん

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を運用する必要に迫られてる中国の温度差
なんだろうな。

0261デフォルトの名無しさん

2006/09/20(水) 23:54:25

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

0262デフォルトの名無しさん

2006/09/22(金) 22:04:20

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

0263デフォルトの名無しさん

2006/09/22(金) 22:39:08

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

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

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

0264デフォルトの名無しさん

2006/09/22(金) 23:05:36

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

0265デフォルトの名無しさん

2006/09/23(土) 09:57:42

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

0266デフォルトの名無しさん

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みたいな処理をするのが当たり前、みたいな。

0267デフォルトの名無しさん

2006/09/23(土) 22:17:14

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

0268デフォルトの名無しさん

2006/09/23(土) 22:21:43

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

0269デフォルトの名無しさん

2006/09/23(土) 22:25:34

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

0270デフォルトの名無しさん

2006/09/23(土) 22:43:07

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

0271デフォルトの名無しさん

2006/09/23(土) 23:08:40

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

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

0272デフォルトの名無しさん

2006/09/23(土) 23:32:56

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

0273デフォルトの名無しさん

2006/09/24(日) 01:04:05

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

0274デフォルトの名無しさん

2006/09/24(日) 17:10:58

これからはoggの時代

0275デフォルトの名無しさん

2006/09/24(日) 22:24:57

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

0276デフォルトの名無しさん

2006/09/25(月) 08:06:28

>>270

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

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

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

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

0277デフォルトの名無しさん

2006/09/25(月) 08:10:34

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

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

0278デフォルトの名無しさん

2006/09/27(水) 01:27:29

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

0279デフォルトの名無しさん

2006/09/27(水) 01:38:33

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

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

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

0280デフォルトの名無しさん

2006/09/27(水) 02:00:43

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

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

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

0281デフォルトの名無しさん

2006/09/27(水) 02:18:27

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

0282デフォルトの名無しさん

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は含まれていない模様

0283デフォルトの名無しさん

2006/10/05(木) 11:31:53

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

0284デフォルトの名無しさん

2006/10/05(木) 11:40:11

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

0285デフォルトの名無しさん

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 には登録されていません。エンコード名として
何が正しいのでしょうか？何に依拠すべきでしょうか？

0286デフォルトの名無しさん

2006/10/08(日) 09:26:16

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

0287デフォルトの名無しさん

2006/10/08(日) 10:21:04

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

0288デフォルトの名無しさん

2006/10/08(日) 13:37:26

MIMEなんかで使う時には、

X-x_Chinese-Eten

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

0289デフォルトの名無しさん

2006/10/12(木) 11:23:10

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

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

0290デフォルトの名無しさん

2006/10/12(木) 11:59:18

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

0291デフォルトの名無しさん

2006/10/12(木) 20:44:29

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

0292デフォルトの名無しさん

2006/10/13(金) 02:37:33

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

0293デフォルトの名無しさん

2006/10/13(金) 12:24:40

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

0294デフォルトの名無しさん

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に変換された"漢字"が出力されるのかと思ったのですけど。

0295294

2006/10/17(火) 05:04:44

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

0296デフォルトの名無しさん

2006/10/17(火) 05:36:40

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

0297デフォルトの名無しさん

2006/10/17(火) 14:41:14

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

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

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

0298デフォルトの名無しさん

2006/10/17(火) 16:04:06

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

0299デフォルトの名無しさん

2006/10/17(火) 18:31:44

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

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

0300デフォルトの名無しさん

2006/10/17(火) 20:22:48

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

0301297

2006/10/17(火) 22:53:36

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

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

0302297

2006/10/17(火) 23:12:24

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

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

0303デフォルトの名無しさん

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;
}

0304デフォルトの名無しさん

2006/10/20(金) 12:40:56

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

0305デフォルトの名無しさん

2006/10/20(金) 20:16:14

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

0306デフォルトの名無しさん

2006/10/20(金) 20:25:53

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

0307デフォルトの名無しさん

2006/10/20(金) 23:12:01

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

0308デフォルトの名無しさん

2006/10/20(金) 23:16:36

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

0309デフォルトの名無しさん

2006/10/20(金) 23:33:46

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

0310デフォルトの名無しさん

2006/10/20(金) 23:40:41

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

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

0311デフォルトの名無しさん

2006/10/20(金) 23:41:12

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

0312デフォルトの名無しさん

2006/10/21(土) 00:36:58

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

0313デフォルトの名無しさん

2006/10/21(土) 00:51:09

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

0314デフォルトの名無しさん

2006/10/21(土) 01:25:02

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

0315デフォルトの名無しさん

2006/10/21(土) 01:30:16

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

0316デフォルトの名無しさん

2006/10/21(土) 05:17:55

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

0317デフォルトの名無しさん

2006/10/21(土) 05:39:59

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

0318デフォルトの名無しさん

2006/10/21(土) 09:15:44

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

0319デフォルトの名無しさん

2006/10/21(土) 10:17:34

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

0320デフォルトの名無しさん

2006/10/21(土) 11:14:18

じゃあ char_podとか、char_DSとか

0321デフォルトの名無しさん

2006/10/21(土) 11:31:00

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

0322デフォルトの名無しさん

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表現に(たしか)対応していない罠……

0323デフォルトの名無しさん

2006/10/21(土) 12:49:19

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

0324デフォルトの名無しさん

2006/10/21(土) 13:36:37

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

0325デフォルトの名無しさん

2006/10/21(土) 20:34:42

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

0326デフォルトの名無しさん

2006/10/21(土) 20:35:38

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

0327デフォルトの名無しさん

2006/10/21(土) 20:41:27

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

0328デフォルトの名無しさん

2006/10/21(土) 21:47:30

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

0329デフォルトの名無しさん

2006/10/21(土) 21:55:02

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

0330デフォルトの名無しさん

2006/10/21(土) 22:23:05

意味不明

0331デフォルトの名無しさん

2006/10/21(土) 23:06:02

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

0332デフォルトの名無しさん

2006/10/22(日) 12:46:17

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

0333デフォルトの名無しさん

2006/10/22(日) 13:54:05

そんなわけないですねｗ

0334デフォルトの名無しさん

2006/10/22(日) 14:12:55

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

0335デフォルトの名無しさん

2006/10/22(日) 14:28:39

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

0336デフォルトの名無しさん

2006/10/22(日) 14:34:37

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

0337デフォルトの名無しさん

2006/10/22(日) 14:37:52

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

0338デフォルトの名無しさん

2006/10/22(日) 14:55:37

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

0339デフォルトの名無しさん

2006/10/22(日) 15:03:27

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

0340デフォルトの名無しさん

2006/10/22(日) 17:25:52

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

0341デフォルトの名無しさん

2006/10/22(日) 17:27:04

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

0342デフォルトの名無しさん

2006/10/22(日) 17:45:47

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

0343デフォルトの名無しさん

2006/10/22(日) 18:28:49

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

0344デフォルトの名無しさん

2006/10/22(日) 20:36:05

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

0345デフォルトの名無しさん

2006/10/22(日) 21:27:51

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

0346デフォルトの名無しさん

2006/10/22(日) 21:37:09

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

0347デフォルトの名無しさん

2006/10/22(日) 21:48:26

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

0348デフォルトの名無しさん

2006/10/22(日) 21:54:41

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

0349デフォルトの名無しさん

2006/10/22(日) 21:58:34

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

0350デフォルトの名無しさん

2006/10/22(日) 22:02:26

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

0351デフォルトの名無しさん

2006/10/22(日) 22:13:24

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

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

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

という理解でおｋ？

0352デフォルトの名無しさん

2006/10/22(日) 22:38:51

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

0353デフォルトの名無しさん

2006/10/22(日) 22:39:55

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

0354デフォルトの名無しさん

2006/10/22(日) 22:45:45

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

0355デフォルトの名無しさん

2006/10/22(日) 22:58:14

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

0356デフォルトの名無しさん

2006/10/22(日) 23:23:04

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

0357デフォルトの名無しさん

2006/10/22(日) 23:39:43

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

0358デフォルトの名無しさん

2006/10/22(日) 23:48:42

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

0359デフォルトの名無しさん

2006/10/23(月) 00:21:59

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

0360デフォルトの名無しさん

2006/10/23(月) 00:41:06

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

0361デフォルトの名無しさん

2006/10/23(月) 00:50:32

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

0362デフォルトの名無しさん

2006/10/23(月) 01:02:41

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

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

0363デフォルトの名無しさん

2006/10/23(月) 01:09:48

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

0364デフォルトの名無しさん

2006/10/23(月) 01:11:32

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

0365デフォルトの名無しさん

2006/10/23(月) 01:14:48

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

0366デフォルトの名無しさん

2006/10/23(月) 01:16:39

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

0367デフォルトの名無しさん

2006/10/23(月) 06:58:59

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

0368デフォルトの名無しさん

2006/10/23(月) 08:54:38

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

0369デフォルトの名無しさん

2006/10/23(月) 10:07:29

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

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

0370デフォルトの名無しさん

2006/10/23(月) 11:54:52

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

0371デフォルトの名無しさん

2006/10/23(月) 12:58:40

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

0372デフォルトの名無しさん

2006/10/23(月) 13:07:54

べつにいいじゃねえか

0373デフォルトの名無しさん

2006/10/23(月) 13:09:07

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

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

0374デフォルトの名無しさん

2006/10/23(月) 16:36:26

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

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

0375デフォルトの名無しさん

2006/10/23(月) 16:46:02

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

0376デフォルトの名無しさん

2006/10/23(月) 22:45:38

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

0377デフォルトの名無しさん

2006/10/24(火) 07:07:17

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

0378デフォルトの名無しさん

2006/10/24(火) 11:01:26

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

0379デフォルトの名無しさん

2006/10/24(火) 11:07:42

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

0380デフォルトの名無しさん

2006/10/24(火) 11:22:40

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

0381デフォルトの名無しさん

2006/10/24(火) 14:35:32

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

0382デフォルトの名無しさん

2006/10/24(火) 14:49:54

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

0383デフォルトの名無しさん

2006/10/24(火) 16:49:48

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

0384デフォルトの名無しさん

2006/10/24(火) 17:00:47

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

0385デフォルトの名無しさん

2006/10/24(火) 18:17:02

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

0386デフォルトの名無しさん

2006/10/24(火) 19:09:22

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

0387デフォルトの名無しさん

2006/10/24(火) 20:16:05

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

0388デフォルトの名無しさん

2006/10/24(火) 21:01:42

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

0389デフォルトの名無しさん

2006/10/24(火) 21:07:27

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

0390デフォルトの名無しさん

2006/10/24(火) 23:30:37

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

0391デフォルトの名無しさん

2006/10/24(火) 23:46:56

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

0392デフォルトの名無しさん

2006/10/25(水) 00:22:00

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

0393デフォルトの名無しさん

2006/10/25(水) 00:39:42

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

0394デフォルトの名無しさん

2006/10/25(水) 00:47:23

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

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

0395デフォルトの名無しさん

2006/10/25(水) 02:37:23

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

0396デフォルトの名無しさん

2006/10/25(水) 08:12:21

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

0397デフォルトの名無しさん

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として扱うようになった。

0398デフォルトの名無しさん

2006/10/25(水) 19:12:02

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

0399デフォルトの名無しさん

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).

0400デフォルトの名無しさん

2006/10/25(水) 19:22:28

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

0401デフォルトの名無しさん

2006/10/25(水) 21:03:33

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

0402デフォルトの名無しさん

2006/10/26(木) 00:33:47

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

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

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

0403デフォルトの名無しさん

2006/10/26(木) 00:40:08

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

0404デフォルトの名無しさん

2006/10/26(木) 00:53:58

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

0405デフォルトの名無しさん

2006/10/26(木) 00:57:47

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

0406デフォルトの名無しさん

2006/10/26(木) 01:06:30

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

0407デフォルトの名無しさん

2006/10/26(木) 01:11:05

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

0408デフォルトの名無しさん

2006/10/26(木) 01:11:25

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

0409デフォルトの名無しさん

2006/10/26(木) 01:33:39

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

0410デフォルトの名無しさん

2006/10/26(木) 01:47:50

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

0411デフォルトの名無しさん

2006/10/26(木) 01:55:35

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

0412デフォルトの名無しさん

2006/10/26(木) 02:29:57

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

0413デフォルトの名無しさん

2006/10/26(木) 02:48:41

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

0414デフォルトの名無しさん

2006/10/26(木) 03:09:46

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

0415デフォルトの名無しさん

2006/10/26(木) 03:23:38

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

0416デフォルトの名無しさん

2006/10/26(木) 03:47:29

>>413

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

0417デフォルトの名無しさん

2006/10/26(木) 09:22:10

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

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

0418デフォルトの名無しさん

2006/10/26(木) 22:07:16

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

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

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

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

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

0419デフォルトの名無しさん

2006/10/26(木) 22:58:50

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

0420デフォルトの名無しさん

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補助漢字に収録済みだね

0421デフォルトの名無しさん

2006/10/27(金) 04:33:58

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

0422デフォルトの名無しさん

2006/10/27(金) 06:18:17

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

0423デフォルトの名無しさん

2006/10/27(金) 06:45:27

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

0424デフォルトの名無しさん

2006/10/27(金) 09:52:42

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

0425デフォルトの名無しさん

2006/10/27(金) 13:07:00

>>420
それは繁体字。

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

0426デフォルトの名無しさん

2006/10/27(金) 14:55:38

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

0427デフォルトの名無しさん

2006/10/27(金) 15:46:39

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

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

0428デフォルトの名無しさん

2006/10/27(金) 17:04:36

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

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

0429デフォルトの名無しさん

2006/10/27(金) 18:04:29

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

0430デフォルトの名無しさん

2006/10/27(金) 19:07:44

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

0431デフォルトの名無しさん

2006/10/27(金) 20:58:27

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

0432デフォルトの名無しさん

2006/10/27(金) 21:48:12

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

0433デフォルトの名無しさん

2006/10/27(金) 21:58:38

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

0434デフォルトの名無しさん

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
この辺が参考になると思う。

0435デフォルトの名無しさん

2006/10/27(金) 22:43:39

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

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

0436デフォルトの名無しさん

2006/10/27(金) 23:09:15

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

0437デフォルトの名無しさん

2006/10/27(金) 23:13:01

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

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

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

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

0438デフォルトの名無しさん

2006/10/28(土) 00:23:45

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

0439デフォルトの名無しさん

2006/10/28(土) 04:25:53

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

0440デフォルトの名無しさん

2006/10/28(土) 04:33:01

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

0441デフォルトの名無しさん

2006/10/28(土) 04:43:31

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

0442デフォルトの名無しさん

2006/10/28(土) 08:21:29

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

0443デフォルトの名無しさん

2006/10/28(土) 09:26:21

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

0444デフォルトの名無しさん

2006/10/28(土) 11:52:14

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

0445デフォルトの名無しさん

2006/10/28(土) 12:27:54

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

0446デフォルトの名無しさん

2006/10/28(土) 12:39:08

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

0447デフォルトの名無しさん

2006/10/28(土) 13:48:47

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

0448デフォルトの名無しさん

2006/10/28(土) 13:51:46

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

0449デフォルトの名無しさん

2006/10/28(土) 15:34:40

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

0450デフォルトの名無しさん

2006/10/28(土) 18:49:47

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

0451デフォルトの名無しさん

2006/10/28(土) 22:27:58

>>450
それ食えんのか？

0452デフォルトの名無しさん

2006/10/29(日) 00:21:10

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

0453デフォルトの名無しさん

2006/10/29(日) 00:43:21

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

0454デフォルトの名無しさん

2006/10/29(日) 02:23:08

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

0455デフォルトの名無しさん

2006/10/29(日) 02:25:16

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

0456デフォルトの名無しさん

2006/10/29(日) 02:31:29

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

0457デフォルトの名無しさん

2006/10/29(日) 02:33:31

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

0458デフォルトの名無しさん

2006/10/29(日) 02:58:06

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

0459デフォルトの名無しさん

2006/10/29(日) 03:15:57

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

0460デフォルトの名無しさん

2006/10/29(日) 08:41:09

はい次

0461デフォルトの名無しさん

2006/10/29(日) 13:03:55

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

0462デフォルトの名無しさん

2006/10/29(日) 13:05:43

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

0463デフォルトの名無しさん

2006/10/29(日) 13:49:07

はい次

0464デフォルトの名無しさん

2006/10/29(日) 15:20:17

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

0465デフォルトの名無しさん

2006/10/29(日) 15:53:41

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

0466デフォルトの名無しさん

2006/10/29(日) 16:06:37

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

0467デフォルトの名無しさん

2006/10/29(日) 16:31:53

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

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

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

0468デフォルトの名無しさん

2006/10/29(日) 17:30:22

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

0469デフォルトの名無しさん

2006/10/29(日) 19:43:16

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

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

0470デフォルトの名無しさん

2006/10/29(日) 20:44:16

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

0471デフォルトの名無しさん

2006/10/30(月) 00:29:58

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

0472デフォルトの名無しさん

2006/10/30(月) 00:38:04

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

0473デフォルトの名無しさん

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

0474デフォルトの名無しさん

2006/10/30(月) 01:57:49

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

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

0475デフォルトの名無しさん

2006/10/30(月) 02:52:49

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

0476デフォルトの名無しさん

2006/10/30(月) 05:08:13

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

0477デフォルトの名無しさん

2006/10/30(月) 05:22:51

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

0478デフォルトの名無しさん

2006/10/30(月) 05:54:10

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

0479デフォルトの名無しさん

2006/10/30(月) 06:12:37

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

0480デフォルトの名無しさん

2006/10/30(月) 09:07:22

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

0481473 474

2006/10/30(月) 12:47:13

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

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

0482デフォルトの名無しさん

2006/10/30(月) 13:39:56

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

0483デフォルトの名無しさん

2006/10/30(月) 16:53:01

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

0484デフォルトの名無しさん

2006/10/30(月) 17:07:04

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

0485デフォルトの名無しさん

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は正常に動作するのですけどね。

0486デフォルトの名無しさん

2006/10/30(月) 20:32:55

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

0487デフォルトの名無しさん

2006/10/30(月) 22:45:34

んじゃUCS4無理じゃん

0488デフォルトの名無しさん

2006/10/30(月) 23:01:04

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

0489デフォルトの名無しさん

2006/10/30(月) 23:59:36

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

0490デフォルトの名無しさん

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窓の問題なんでしょうかね。

0491デフォルトの名無しさん

2006/10/31(火) 00:13:12

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

0492デフォルトの名無しさん

2006/10/31(火) 00:27:37

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

0493デフォルトの名無しさん

2006/10/31(火) 00:29:14

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

0494デフォルトの名無しさん

2006/10/31(火) 00:34:05

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

0495デフォルトの名無しさん

2006/10/31(火) 00:34:41

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

0496デフォルトの名無しさん

2006/10/31(火) 01:06:36

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

0497デフォルトの名無しさん

2006/10/31(火) 01:13:14

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

0498デフォルトの名無しさん

2006/10/31(火) 02:07:56

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

0499デフォルトの名無しさん

2006/10/31(火) 03:10:00

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

0500デフォルトの名無しさん

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 への逆変換なども当然必要です。

0501デフォルトの名無しさん

2006/10/31(火) 05:28:59

>>495
kwsk

0502デフォルトの名無しさん

2006/10/31(火) 05:32:25

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

0503デフォルトの名無しさん

2006/10/31(火) 08:17:04

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

0504デフォルトの名無しさん

2006/10/31(火) 11:36:55

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

0505デフォルトの名無しさん

2006/10/31(火) 18:48:07

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

0506デフォルトの名無しさん

2006/10/31(火) 20:00:47

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

0507デフォルトの名無しさん

2006/10/31(火) 21:26:20

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

0508デフォルトの名無しさん

2006/10/31(火) 23:05:52

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

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

0509デフォルトの名無しさん

2006/10/31(火) 23:15:44

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

0510505

2006/10/31(火) 23:37:25

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

0511デフォルトの名無しさん

2006/10/31(火) 23:50:35

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

0512デフォルトの名無しさん

2006/11/01(水) 03:25:30

>>509
未定義

0513デフォルトの名無しさん

2006/11/01(水) 05:42:58

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

0514デフォルトの名無しさん

2006/11/01(水) 08:00:31

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

0515デフォルトの名無しさん

2006/11/01(水) 08:18:51

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

0516デフォルトの名無しさん

2006/11/01(水) 08:41:06

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

0517デフォルトの名無しさん

2006/11/01(水) 08:45:25

素人だろ、ほっとけよ

0518デフォルトの名無しさん

2006/11/01(水) 09:36:40

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

0519デフォルトの名無しさん

2006/11/01(水) 13:13:11

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

0520デフォルトの名無しさん

2006/11/01(水) 13:34:11

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

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

0521デフォルトの名無しさん

2006/11/01(水) 14:39:28

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

0522デフォルトの名無しさん

2006/11/01(水) 15:12:01

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

0523デフォルトの名無しさん

2006/11/01(水) 15:22:58

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

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

0524デフォルトの名無しさん

2006/11/01(水) 15:45:51

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

0525デフォルトの名無しさん

2006/11/01(水) 15:51:11

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

0526デフォルトの名無しさん

2006/11/01(水) 15:51:18

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

0527デフォルトの名無しさん

2006/11/01(水) 15:52:27

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

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

0528デフォルトの名無しさん

2006/11/01(水) 16:08:54

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

0529デフォルトの名無しさん

2006/11/01(水) 18:22:30

ユニコードって糞だね

0530デフォルトの名無しさん

2006/11/01(水) 20:51:43

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

0531デフォルトの名無しさん

2006/11/01(水) 21:00:41

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

0532デフォルトの名無しさん

2006/11/01(水) 21:16:22

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

0533デフォルトの名無しさん

2006/11/01(水) 21:19:00

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

0534デフォルトの名無しさん

2006/11/01(水) 22:14:32

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

0535デフォルトの名無しさん

2006/11/01(水) 22:21:34

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

0536デフォルトの名無しさん

2006/11/01(水) 22:26:09

Normalization Form Cでいいやん

0537デフォルトの名無しさん

2006/11/01(水) 22:29:39

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

0538デフォルトの名無しさん

2006/11/01(水) 22:39:48

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

0539デフォルトの名無しさん

2006/11/01(水) 22:43:51

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

0540デフォルトの名無しさん

2006/11/01(水) 22:45:45

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

0541デフォルトの名無しさん

2006/11/01(水) 22:53:00

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

0542デフォルトの名無しさん

2006/11/01(水) 22:59:58

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

0543デフォルトの名無しさん

2006/11/01(水) 23:03:51

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

0544￣∨￣￣￣￣￣￣￣￣￣￣￣

2006/11/01(水) 23:05:59

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

0545デフォルトの名無しさん

2006/11/01(水) 23:07:04

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

0546デフォルトの名無しさん

2006/11/01(水) 23:07:42

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

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

0547デフォルトの名無しさん

2006/11/01(水) 23:12:52

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

0548デフォルトの名無しさん

2006/11/01(水) 23:13:05

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

0549デフォルトの名無しさん

2006/11/01(水) 23:17:35

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

0550デフォルトの名無しさん

2006/11/02(木) 00:20:55

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

0551デフォルトの名無しさん

2006/11/02(木) 00:25:03

YES

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

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

世の中進んだね。

0552デフォルトの名無しさん

2006/11/02(木) 00:39:56

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

0553デフォルトの名無しさん

2006/11/02(木) 00:46:36

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

0554デフォルトの名無しさん

2006/11/02(木) 01:27:12

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

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

0555デフォルトの名無しさん

2006/11/02(木) 01:36:27

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

0556デフォルトの名無しさん

2006/11/02(木) 01:49:32

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

0557デフォルトの名無しさん

2006/11/02(木) 02:02:24

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

0558デフォルトの名無しさん

2006/11/02(木) 02:27:44

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

0559デフォルトの名無しさん

2006/11/02(木) 21:56:10

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

0560デフォルトの名無しさん

2006/11/03(金) 06:40:22

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

0561デフォルトの名無しさん

2006/11/03(金) 11:50:49

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

0562デフォルトの名無しさん

2006/11/03(金) 12:19:08

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

0563デフォルトの名無しさん

2006/11/04(土) 19:10:30

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

0564デフォルトの名無しさん

2006/11/04(土) 20:20:32

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

0565デフォルトの名無しさん

2006/11/04(土) 21:41:40

SJISで十分だなマジな話

0566デフォルトの名無しさん

2006/11/04(土) 21:46:55

>>565
文字化けします

0567デフォルトの名無しさん

2006/11/04(土) 22:25:16

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

0568デフォルトの名無しさん

2006/11/06(月) 13:12:27

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

0569デフォルトの名無しさん

2006/11/06(月) 20:01:42

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

0570デフォルトの名無しさん

2006/11/06(月) 21:04:36

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

0571デフォルトの名無しさん

2006/11/06(月) 22:11:02

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

0572デフォルトの名無しさん

2006/11/06(月) 22:14:55

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

0573デフォルトの名無しさん

2006/11/06(月) 22:16:23

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

0574デフォルトの名無しさん

2006/11/06(月) 22:29:16

>>573 対応している。

0575デフォルトの名無しさん

2006/11/06(月) 23:36:07

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

0576デフォルトの名無しさん

2006/11/07(火) 01:35:07

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

0577デフォルトの名無しさん

2006/11/07(火) 13:05:43

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

0578デフォルトの名無しさん

2006/11/07(火) 13:54:03

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

0579デフォルトの名無しさん

2006/11/07(火) 15:45:26

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

0580デフォルトの名無しさん

2006/11/07(火) 16:57:33

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

0581デフォルトの名無しさん

2006/11/07(火) 17:15:43

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

0582デフォルトの名無しさん

2006/11/07(火) 17:29:05

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

0583デフォルトの名無しさん

2006/11/07(火) 17:39:37

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

0584デフォルトの名無しさん

2006/11/07(火) 17:47:10

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

0585デフォルトの名無しさん

2006/11/07(火) 21:25:05

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

0586デフォルトの名無しさん

2006/11/07(火) 21:33:59

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

0587デフォルトの名無しさん

2006/11/07(火) 21:42:58

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

0588デフォルトの名無しさん

2006/11/07(火) 21:43:28

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

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

0589デフォルトの名無しさん

2006/11/08(水) 00:38:14

>>587
IVSは可変長だから

0590デフォルトの名無しさん

2006/11/08(水) 00:41:41

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

0591デフォルトの名無しさん

2006/11/08(水) 08:41:36

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

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

0592デフォルトの名無しさん

2006/11/08(水) 11:11:03

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

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

0593デフォルトの名無しさん

2006/11/08(水) 22:08:26

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

0594デフォルトの名無しさん

2006/11/08(水) 22:12:11

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

0595デフォルトの名無しさん

2006/11/08(水) 22:23:33

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

0596デフォルトの名無しさん

2006/11/08(水) 22:50:35

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

0597デフォルトの名無しさん

2006/11/09(木) 01:26:46

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

0598デフォルトの名無しさん

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で足りるのに俺コード使うのはナンセンス。

0599デフォルトの名無しさん

2006/11/09(木) 01:31:50

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

0600デフォルトの名無しさん

2006/11/09(木) 10:02:45

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

0601デフォルトの名無しさん

2006/11/09(木) 10:20:31

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

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

0602デフォルトの名無しさん

2006/11/09(木) 11:54:23

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

0603デフォルトの名無しさん

2006/11/09(木) 11:59:22

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

0604デフォルトの名無しさん

2006/11/09(木) 13:21:06

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

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

0605デフォルトの名無しさん

2006/11/09(木) 14:10:36

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

0606デフォルトの名無しさん

2006/11/09(木) 15:34:06

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

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

0607デフォルトの名無しさん

2006/11/09(木) 15:40:02

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

0608404

2006/11/09(木) 16:12:21

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

0609デフォルトの名無しさん

2006/11/09(木) 16:14:41

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

0610デフォルトの名無しさん

2006/11/10(金) 21:39:26

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

0611デフォルトの名無しさん

2006/11/10(金) 22:07:32

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

0612デフォルトの名無しさん

2006/11/10(金) 22:23:45

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

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

0613デフォルトの名無しさん

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のみの変換で何とかなる。

0614デフォルトの名無しさん

2006/11/10(金) 22:54:31

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

0615デフォルトの名無しさん

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環境で使いたくて作った。

0616デフォルトの名無しさん

2006/11/11(土) 00:47:05

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

0617デフォルトの名無しさん

2006/11/14(火) 23:46:25

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

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

0618デフォルトの名無しさん

2006/11/14(火) 23:51:26

だめです

0619617

2006/11/15(水) 00:13:28

>>618
何がだめですか？

0620デフォルトの名無しさん

2006/11/15(水) 00:34:08

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

0621デフォルトの名無しさん

2006/11/15(水) 08:19:21

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

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

0622デフォルトの名無しさん

2006/11/17(金) 01:29:53

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

0623デフォルトの名無しさん

2006/11/17(金) 01:39:57

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

0624デフォルトの名無しさん

2006/11/17(金) 01:43:02

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

0625624

2006/11/17(金) 02:04:20

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

0626624

2006/11/17(金) 02:24:26

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

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

0627デフォルトの名無しさん

2006/11/17(金) 02:43:56

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

0628デフォルトの名無しさん

2006/11/17(金) 05:53:01

愛昆布

0629デフォルトの名無しさん

2006/11/17(金) 11:37:55

>>626

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

0630デフォルトの名無しさん

2006/11/19(日) 18:33:08

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

0631デフォルトの名無しさん

2006/11/19(日) 22:49:19

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

0632デフォルトの名無しさん

2006/11/19(日) 23:09:36

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

0633デフォルトの名無しさん

2006/11/19(日) 23:51:22

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

0634デフォルトの名無しさん

2006/11/22(水) 21:10:35

base64にしてみるとか

0635デフォルトの名無しさん

2006/11/22(水) 22:20:07

それ何てUTF-7?

0636デフォルトの名無しさん

2006/11/28(火) 11:05:43

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

0637デフォルトの名無しさん

2006/11/28(火) 11:10:07

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

0638デフォルトの名無しさん

2006/11/28(火) 11:10:59

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

0639デフォルトの名無しさん

2006/11/28(火) 12:15:48

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

0640デフォルトの名無しさん

2006/11/28(火) 23:42:57

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

0641デフォルトの名無しさん

2006/11/29(水) 00:38:54

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

0642デフォルトの名無しさん

2006/12/02(土) 18:24:49

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

0643デフォルトの名無しさん

2006/12/02(土) 20:16:08

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

0644デフォルトの名無しさん

2006/12/05(火) 05:52:57

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

0645デフォルトの名無しさん

2006/12/06(水) 00:03:50

jis2004対応大変だな。。

0646デフォルトの名無しさん

2006/12/06(水) 00:21:49

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

0647デフォルトの名無しさん

2006/12/06(水) 00:33:00

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

0648デフォルトの名無しさん

2006/12/06(水) 00:35:20

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

0649デフォルトの名無しさん

2006/12/06(水) 00:50:04

UTF16LEだね

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

0650デフォルトの名無しさん

2006/12/06(水) 00:55:34

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

0651デフォルトの名無しさん

2006/12/06(水) 01:50:09

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

0652デフォルトの名無しさん

2006/12/06(水) 02:48:06

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

0653デフォルトの名無しさん

2006/12/06(水) 02:52:41

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

0654646

2006/12/06(水) 07:20:13

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

0655デフォルトの名無しさん

2006/12/06(水) 12:47:55

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

0656デフォルトの名無しさん

2006/12/07(木) 00:42:55

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

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

0657デフォルトの名無しさん

2006/12/07(木) 01:06:00

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

こりゃたいへんだ～

0658デフォルトの名無しさん

2006/12/07(木) 01:21:34

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

0659デフォルトの名無しさん

2006/12/07(木) 08:01:05

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

0660デフォルトの名無しさん

2006/12/07(木) 10:13:55

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

なに言ってんの?

0661デフォルトの名無しさん

2006/12/07(木) 20:01:42

波ダッシュ！

0662デフォルトの名無しさん

2006/12/07(木) 20:24:05

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

0663デフォルトの名無しさん

2006/12/08(金) 01:28:34

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

0664デフォルトの名無しさん

2006/12/08(金) 03:30:34

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

0665デフォルトの名無しさん

2006/12/08(金) 20:11:01

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

0666デフォルトの名無しさん

2006/12/08(金) 21:44:35

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

0667デフォルトの名無しさん

2006/12/09(土) 01:07:02

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

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

0668デフォルトの名無しさん

2006/12/09(土) 06:31:28

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

0669デフォルトの名無しさん

2006/12/10(日) 14:02:05

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

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

0670デフォルトの名無しさん

2006/12/10(日) 14:10:15

CP932？

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

see MSDN

0671デフォルトの名無しさん

2006/12/10(日) 14:25:32

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

0672デフォルトの名無しさん

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)_装置制御１
12___DC2_______D2(device control two)_装置制御２
13___DC3_______D3(device control three)_装置制御３
14___DC4_______D4(device control four)_装置制御４
15___TC8(NAK)__NK(negative acknowledgement)_否定応答
16___TC9(SYN)__SY(synchronous idle)_同期信号

0673デフォルトの名無しさん

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)_抹消

0674デフォルトの名無しさん

2006/12/10(日) 14:41:27

>>672

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

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

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

0675デフォルトの名無しさん

2006/12/10(日) 14:43:27

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

0676デフォルトの名無しさん

2006/12/10(日) 14:52:48

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

0677デフォルトの名無しさん

2006/12/10(日) 14:59:17

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

0678デフォルトの名無しさん

2006/12/10(日) 15:12:54

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

0679デフォルトの名無しさん

2006/12/10(日) 15:12:59

669です。
CP932でした。

0680デフォルトの名無しさん

2006/12/10(日) 15:13:11

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

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

0681デフォルトの名無しさん

2006/12/10(日) 15:27:22

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

0682デフォルトの名無しさん

2006/12/10(日) 15:39:38

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

0683デフォルトの名無しさん

2006/12/10(日) 16:01:54

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

0684デフォルトの名無しさん

2006/12/10(日) 16:08:24

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

0685デフォルトの名無しさん

2006/12/10(日) 16:13:38

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

0686デフォルトの名無しさん

2006/12/10(日) 17:01:16

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

0687デフォルトの名無しさん

2006/12/10(日) 18:21:11

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

0688デフォルトの名無しさん

2006/12/10(日) 18:28:48

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

0689デフォルトの名無しさん

2006/12/11(月) 10:52:19

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

0690デフォルトの名無しさん

2006/12/11(月) 22:13:51

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

0691デフォルトの名無しさん

2006/12/12(火) 01:32:26

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

0692デフォルトの名無しさん

2006/12/12(火) 20:10:08

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

0693デフォルトの名無しさん

2006/12/12(火) 20:24:28

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

0694デフォルトの名無しさん

2006/12/14(木) 00:01:43

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

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

0695692

2006/12/14(木) 00:19:18

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

0696デフォルトの名無しさん

2006/12/14(木) 00:49:38

>>695
シリアル伝送の世界では、転送効率を上げるために5ビットコードが使われることがある。
例えばRS-232Cでは8ビット送るには最低限スタートビットとストップビットが必要なので10ビット必要になる。
つまり、9600bpsでも秒間960バイトしか送れない。
5ビットコードを使えば、パリティをつけても8ビットで済むから同じ9600bpsでも1200バイト送れる。
#実際には、未だに75bps回線なんてのもあるから結構切実。

0697デフォルトの名無しさん

2006/12/14(木) 01:09:50

75bpsですか。
おいらでも300ボーのモデムでパソコン通信していた程度だよ。

# MNPとか言われるとV.42bisとか連想してしまう世代ｗ

0698デフォルトの名無しさん

2006/12/14(木) 05:39:59

V.42bisなんてずいぶん最近w

0699デフォルトの名無しさん

2006/12/14(木) 21:46:36

>>695
シリアルポートだったり、イーサネットで TCP だったりしますけど、
過去との互換性の確保が最優先な分野では現役なのですよ

稼動しているマシンや OS は、現在普通に販売されているものです。
通信先の相手側の事情でプロトコルをリッチなものに変更できないのです

0700デフォルトの名無しさん

2006/12/14(木) 21:59:11

いまだったらエミュレータでも速度的に充分かもねぇ。
Z80とかMC68000くらいだったら余裕でしょ。

0701デフォルトの名無しさん

2006/12/14(木) 22:12:49

>>700
それだとデータベースとか使うの大変です。プロトコルは貧弱でも
他の部分は現代のシステムですから

0702デフォルトの名無しさん

2006/12/14(木) 22:57:52

こっちも相手も現代のOSで動いてたら、わざわざ古いプロトコル使うのって
悲しいよね。
レガシーシステムの保守はやっぱ大変そうだな。

0703QQQ

2006/12/15(金) 03:14:06

ハングル文字を入力してその文字をデータベースから検索させるサイトを
作りたいんですが、入力された文字が内部でちゃんと認識されません。
同じ文字でも一文字入力した場合と二文字以上で入力した場合で
内部で認識するバイナリデータが変わったりします。
このへんのことに詳しい方いましたら、教えてください。

0704デフォルトの名無しさん

2006/12/15(金) 03:16:43

「ハングル」自体に文字の意味があるよ

0705デフォルトの名無しさん

2006/12/15(金) 03:47:24

unicode 正規化でググるとヒント見つかるかも。

0706QQQ

2006/12/15(金) 04:31:07

>>704
あ、そうですね。知ってます。間違えました。
>>705
正規化ではググッたことがないですね。試してみます。

0707デフォルトの名無しさん

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に未登録とか書けばよかったのにねー。

0708デフォルトの名無しさん

2006/12/15(金) 14:07:15

>>707
おぉ。その記事ためになった。ありがとう。

0709デフォルトの名無しさん

2006/12/15(金) 15:03:00

>>707
>Unicodeでは，2つの文字を組み合わせて1つの文字として表示するものがある。
なぜ「Unicodeでは，2つ(以上)のcode pointを組み合わせて1つのgraphemeとして
表示するものがある。」と書かないの？
文中に出て来る「文字」や「キャラクタ」が各々何を意味するか教えて下さい。

0710デフォルトの名無しさん

2006/12/15(金) 15:14:14

>なぜ「Unicodeでは，2つ(以上)のcode pointを組み合わせて1つのgraphemeとして
>表示するものがある。」と書かないの？
一般向けの解説記事だから。

0711デフォルトの名無しさん

2006/12/15(金) 19:54:07

一般向けの記事だからとか、そういう問題じゃないような。

＞「JIS2004」で追加された新しい文字の形がデフォルトになっているフォント

「追加」じゃなくて「変更」な。それ以外にも日本語おかしいけど。

＞これらのフォントが利用しているコード体系のUnicodeでは，
＞日本語と台湾語，中国語，韓国語が1つの「スクリプト」として定義されており

1つのスクリプトとして扱われているのは、
日本「語」や台湾「語」じゃなく、各国の「漢字」な。

＞UTF-8やUTF-16といったUnicodeのエンコーディング（文字コード体系）

「エンコーディング」とか「コード体系」とかの用語がグダグダ。

＞Unicode（UTF-16）では，1文字当たり2バイトの
＞キャラクタ・コードが割り当てられているが

2バイトじゃなく16ビット（で1バイト）な。

0712デフォルトの名無しさん

2006/12/15(金) 23:19:10

＞2バイトじゃなく16ビット（で1バイト）な。

そうかあ？

0713デフォルトの名無しさん

2006/12/16(土) 00:03:04

1バイト=8ビットという定義が主流だけど昔はいろいろあったらしい。
最近でもキロバイトとかメガバイトみたいな 1キロ=1000? 1024? とか混乱する要素は多いな。
HDDみたく500ギガバイトあたりになると差が激しくなってくるねぇ。

0714デフォルトの名無しさん

2006/12/16(土) 01:54:54

そもそもUTF-8は16bit unsigned integerの列。
それを1byte = 8bitを単位とする世界で表現する時のためにbyte orderの考え方がある。

そして一文字辺り、一つか二つの16bit unsigned integerが必要。
サロゲートペアがあるので。

＞Unicode（UTF-16）では，1文字当たり2バイトの
＞キャラクタ・コードが割り当てられているが

ここまで短い文章で、突っ込みどころが満載なのも珍しい。

0715714

2006/12/16(土) 01:55:34

>>714
> そもそもUTF-8は16bit unsigned integerの列。

ｳｶﾞｯ!
UTF-8は→UTF-16は

0716デフォルトの名無しさん

2006/12/16(土) 09:18:09

>>707
安岡センセイも記事書いてるぞ
http://itpro.nikkeibp.co.jp/article/COLUMN/20061211/256519/

0717デフォルトの名無しさん

2006/12/16(土) 12:10:28

2オクテットでいいじゃない

0718デフォルトの名無しさん

2006/12/16(土) 12:18:08

規格の名称からして「Universal Multiple-Octet Coded Character Set」だしな

0719デフォルトの名無しさん

2006/12/17(日) 02:06:22

>>717
16ビットのものを2オクテットとして扱う場合にはバイトオーダーの問題がある。
16ビットのものは16ビットの単位で扱わないと面倒かも。
16ビットでいいかというとサロゲートペアという問題が残っている。
UCSで扱う場合でも、正規化と合成文字を考えないといけない。
さらに言語タグみたいなものまであるから、手抜きせずにUnicodeを
実装するのは重労働だな。

0720デフォルトの名無しさん

2006/12/17(日) 06:12:27

>>719
８ビットは常に１オクテットなんだからそれはいいんじゃないの？
バイトオーダはビット幅とはまた別の問題だよ。

でもさー、本当に全部必要なのかなー。TCP/IPを前提としてもさ。
BEL,VT(垂直タブ),FF(書式送り)なんて何に使うんだよー。
DC1-4だって使ってりゃちゃんとしたそれなりの名前付いてんじゃないの？
シフトイン、シフトアウトだってそれキーボードで既に制御済みじゃん。
BELって交換機でベルが鳴って誰かが駆けつけるとはとても思えないが。
CR,LFも片方しかいらないよ。どっちでもいい。どっちかにしてくれ。

0721デフォルトの名無しさん

2006/12/17(日) 08:26:08

>>720

DC1-4 は使ってる場合は、ちゃんと名前付いてるよ。
ここはそのコードを使用する機器特有の機能を割り当てるための
領域なんだから。

FFなんかはプリンターの改ページコードだし ESC/P系のプリンタでは
まだまだ使用されてるだろう。

0722デフォルトの名無しさん

2006/12/17(日) 08:27:11

>>720
その辺を節約してなんかメリットあるの?
#残すメリットなら色々あるわけだが。

0723デフォルトの名無しさん

2006/12/17(日) 09:03:08

ちなみにキーボードで ctrlキー押しながらアルファベットキーを押した場合
該当するアルファベットのASCIIコードの7ビット目が反転されたコードとなる。

^C = ETX　　^Q = DC1(XON)　^S = DC3(XOFF)　^D = EOT

0724デフォルトの名無しさん

2006/12/17(日) 10:39:09

>>720
> バイトオーダはビット幅とはまた別の問題だよ。

UTF-16は、>>714も書いているように、
16bit unsigned integerのsequenceなので、
ビット幅が16ビットでない時にバイトオーダーを考慮する必要があります。
だから別問題じゃなくて直結しています。

扱う最小単位が16bitのCPUであれば、
バイト(=8bit)オーダーは気にする必要がありません。

UTF-16はまず16bit unsigned integerのsequenceであると
抽象的に定義されていることを理解してください。

0725デフォルトの名無しさん

2006/12/17(日) 11:26:47

>>724
問題を混同していて、切り分けて考えることのできないひとだね。
16bitとして扱うことのできないCPUなら問題はあるかもしれないが、
それでも機種依存的な問題で、UTFの定義とは全く関係が無い。

0726デフォルトの名無しさん

2006/12/17(日) 11:43:40

>>722
自分だけのコード体系作って、ＯＳもコンパイラも全部自分で作って
自分だけ速くプログラムを動かしたい。その為ならもう日本語を捨てる。
新しいアルファベットベースの自然言語も自分で全部作って、それでものを考える。
記号も追加したいのたくさんあって。だから、だから割り当て可能なのが
７ビット幅か８ビット幅なのか、気になってしょうがない。
制御コードから数字から文字まで全部８ビットなんて夢のようじゃん。
Unicodeなんてどうせ一生待ったっていいもの出来ないよ。人生は一度きり。

0727デフォルトの名無しさん

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じゃなくてあれだが)

0728デフォルトの名無しさん

2006/12/17(日) 11:50:24

>>725
あんたがEncoding formとEncoding schemeを理解できてないだけじゃんw

0729デフォルトの名無しさん

2006/12/17(日) 12:24:52

８ビットだろうが１６ビットだろうがバイトオーダの問題は
いつもある。文字コードの規定とビットの並びは別の問題だから。
だからデータの先頭にマジックナンバーとかサンプルの数字とか
書いてもらって自分側と逆だったら、全部一律に変換しちゃえばいい。
無駄なパワーとも思うが、どっちのエンディアンがいいのかは
賛否両論でそれぞれ言い分があるらしい。
ただ無条件に並びを規則的に交換するだけだから、別に大問題と
いうわけではないよ。今までだってそうやってきたんだから。
サロゲートペアはね、あれはね、大問題。
ＤＢの１カラムからもう何かの文字集合のサブセットなんだからさ。
明日の国際会議の出席者の一覧表作ってください、と言われたらもう困っちゃう。

0730デフォルトの名無しさん

2006/12/17(日) 12:43:54

Unicode標準は、バイドオーダーについてBEとLEを規定している。
規格も読んでない人間が、文字コードの規定と別問題というのはおかしい。

0731デフォルトの名無しさん

2006/12/17(日) 13:05:40

というよりバイドオーダは問題の内に入らない、くらいのことを言いたいな。
審議するほどの内容の深みがないんだから。解決済みなんだからさ。
エンディアンなんてどっちでもいいんだよ。
ずっと前からネットワーク越しに互いにやりとりしたきてるんだから。
両方を規定しているってことは、Unicode規格としてどうでもいいってことなんだから。

0732デフォルトの名無しさん

2006/12/17(日) 13:38:14

はいはい

0733デフォルトの名無しさん

2006/12/17(日) 15:33:21

Code PointとCode Unit。みんな使い分けてる？

0734デフォルトの名無しさん

2006/12/17(日) 17:49:28

違いすぎて混同しようがない。

0735デフォルトの名無しさん

2006/12/17(日) 18:23:53

どうでもいいならむしろ規定なんかしないだろ。
実際内部コードとして使うことを前提にしていた昔のUnicodeでは規定されてなかった
(で、その結果現状の混沌がもたらされた)。

0736デフォルトの名無しさん

2006/12/17(日) 18:25:33

>>733
＞Unicode（UTF-16）では，1文字当たり2バイトの
なんて迷文を書ける人以外は

0737デフォルトの名無しさん

2006/12/17(日) 18:38:27

>>729
マジックナンバーってBOMのこといってる?
どの文字コードでやり取りするか相手と意思の疎通が取れていないと
UTF-16前提で処理をするのは無謀。
ファイル名や拡張子みたいなデータ本体とは別の部分にメタデータとして
記録しておかないと、文字コードの自動判別みたいな不完全な処理を
しないといけなくなるぞ。

0738デフォルトの名無しさん

2006/12/17(日) 18:41:31

流れをぶったぎって質問です

UTF-8においてのBOMというのがあるそうですが、何のためにあるんでしょうか
UTF-8でByteOrderは関係ない気がするんですが・・・

0739デフォルトの名無しさん

2006/12/17(日) 19:41:53

>>738
> 文字コードの自動判別みたいな不完全な処理
のため。
> UTF-8でByteOrderは関係ない
だからISO/IEC 10646ではsignatureと呼んでる。

0740デフォルトの名無しさん

2006/12/17(日) 19:55:30

>>738
テキストエディタみたいな文字コードの自動判別をしなきゃいけないソフトの場合、
BOMが頭に入ってると判定の精度があがる。

BOM,が入っててもISO-8859-1としての解釈もできるので、本当に
ヒューリスティックな判定をしないといけないんだよねぇ。
IEとかMozillaで文字コードのところに日本語とか西欧とかユニコードとか
設定できるのは判定する文字コードの種類を押さえて精度を高めるため。

0741デフォルトの名無しさん

2006/12/17(日) 20:58:58

>>739
>>740
なるほど。ありがとうございます

Windowsのメモ帳もUTF-8で保存するとBOM付けるみたいですね

0742デフォルトの名無しさん

2006/12/17(日) 20:59:18

MIMEならcharset情報をヘッダで表現できるので、きちんと設定された
メーラであれば大丈夫。
しかし、SPAM送信プログラムみたいなMIMEに準拠する意思の
ないような実装の場合、Subjectもメール本文にもcharset指定なしで
CP932とかISO-8859-xとか8bitのまま送ってくる。
日本語のスパムでもメーラによっては文字化けして読めないのは
そのせい。

0743デフォルトの名無しさん

2006/12/17(日) 21:04:55

> SPAM送信プログラム
どうせならRFC 3514対応してくれ、とふと思った。

0744デフォルトの名無しさん

2006/12/17(日) 21:05:43

>>741
BOMなしのUTF-8は正式な名称ではないがUTF-8Nという風に呼ばれることがある。
単純にUTF-8といった場合にはBOMありもなしも含まれる。

0745デフォルトの名無しさん

2006/12/17(日) 21:11:30

悪意がなくてもバルクメーラーの実装は結構いいかげん。
Dateフィールドがなくて1970/01/01扱いされたり、2035年とか
未来からのメールとか平気で送ってくる。

0746デフォルトの名無しさん

2006/12/17(日) 21:21:58

>>738
標準では、「必須でもなければ、推奨もしてないが、標準に適合しないわけではない。」
という表現。あなたの言う通りbyte order signagureとしては意味ないが、>>739 >>740のため。

0747デフォルトの名無しさん

2006/12/17(日) 21:42:14

>>744
BOM付きのUTF-8を指す略称が欲しいな。UTF-8Bとか。

0748デフォルトの名無しさん

2006/12/17(日) 21:59:24

今は分からないが、UnicodeとISO10646でBOMにあたるコードの扱いが
違ってなかったっけ?
UnicodeだとBOMでISO10646だとZERO-WIDTH NON-BREAKING SPACE。

0749デフォルトの名無しさん

2006/12/17(日) 22:07:30

UTF-8Y ってのがあるみたいだが、あんまりメジャーじゃないみたい。

0750デフォルトの名無しさん

2006/12/17(日) 22:25:37

スパムメールがへんてこなのはフィルタ対策だと思うがどうか。
メールチェッカ作ったときに業者の創意工夫が見れておもろかった。

0751デフォルトの名無しさん

2006/12/17(日) 22:28:43

>>748
U+FEFFをBOMと解釈すべきかzwnbspと解釈すべきかは細かく定められてる

0752デフォルトの名無しさん

2006/12/17(日) 22:44:17

先頭にきたときだけBOMとして扱って、途中にでたときはZWNBSP?
たまたま先頭に来たZWNBSPとの区別が出来ないのは欠陥だよな。
ZWNBSPを先頭(BOM)以外には使えないようにするしかないのか。

0753デフォルトの名無しさん

2006/12/17(日) 23:18:30

>>749
なんで Y なのかがさっぱりわからん。

0754デフォルトの名無しさん

2006/12/17(日) 23:32:56

Y/N

0755デフォルトの名無しさん

2006/12/17(日) 23:45:00

違う違う。先頭データって言っても１２３４Ｈって２バイト分書いてあるだけ。
そんなの見たって文字コードの種類なんてわかるわけない。
インテルのＣＰＵはこれが、３４，１２にバイト毎に反転される。
複数バイトの場合にはいつもこうなる。この順番がバイトオーダ。
インテルのＣＰＵが４ビットＣＰＵの頃からずっとこんな調子。
１２３４Ｈに見えたら変換の必要なしということ。
Ｓ－ＪＩＳ同士だろうがＥＵＣ同士だろうが、とにかくエンディアンが
違うとこうなっちゃう。１６ビットコードだからとか、Unicodeとか
全く関係ない。文字コードの話と全く関係ないことだからさ。

0756752

2006/12/18(月) 00:15:06

>>755
えーとオクテットで表現する形式としてのBOMではなくて、
UTF-7/8/16LE/16BE/32などのUnicodeとISO10646において
コードポイントとしてのU+FEFFをどう扱うかって話。

0757デフォルトの名無しさん

2006/12/18(月) 01:41:36

そりゃもう規格名とバージョンの番号を書くくらいしか思いつかない。
つーか、バイトオーダとかエンディアンとかの単語が出てくるあたり
から完全に変な感じだったよ。
多分、一言でうまく切り分けられる表現そのものが無いとみた。
だって規格自体ががあやふやで、だから何度も作り直してるんだから。
それがちゃんと決まってるなら、簡潔に今それを言えるはず。

0758デフォルトの名無しさん

2006/12/18(月) 01:55:46

>>757
Unicodeにバージョンがある時点でもう無理があるんだけど。
単にUTF-8と書いてもオクテットで表現する形式であって
Unicodeのどのバージョンですよ。みたいなことは分からんからね。
BOMとかXMLのバージョン表記みたいに先頭にバージョンを表現する
制御コードを書くぐらいしかないかもなぁ。

基本的に互換性を保っているものとして、処理するプログラムを開発した
時点における最新の規格に順ずる物とするのが現実的な回答か。

RFCでも後からでてきた拡張規格とかに対応してるかどうかは
問い合わせないとわからんことが多いしな。

0759デフォルトの名無しさん

2006/12/18(月) 02:13:06

TCPとかIPとかMIMEはversionがヘッダに書いてあるだろ。

0760デフォルトの名無しさん

2006/12/18(月) 02:24:04

>>759
MIMEヘッダでcharset=UTF-8って書いてあっても、どのUnicode規格に対応するかは
わからんよね。
区別する必要があるならUnicodeの中で制御コード割り振って対処するしかないんじゃない?

0761デフォルトの名無しさん

2006/12/18(月) 20:54:01

UTF-8にバージョン番号を付けていないのは意図的

0762デフォルトの名無しさん

2006/12/19(火) 00:58:39

えっと・・・
辻希美が「功名が辻+（'）」を見て、どう思ってるのかな？
神奈川県逗子市の人にも聞いてみたい。
そんなことより、佐藤琢+（'）磨についてYahooで検索しよっかなっと。
ついでに、辰良丈+(')一郎についても・・・これはやめておこう。

0763デフォルトの名無しさん

2006/12/19(火) 01:02:35

もう、みんないろいろいってるが、これですべて解決

㈱

えい

0764デフォルトの名無しさん

2006/12/20(水) 16:30:10

之繞がつく漢字は全て1点に統一して、
2点之繞にしたい時は後ろにU+300(COMBINING GRAVE ACCENT)を付ける事にしよう。
例:２点之繞の辻→U+8FBB U+300

0765デフォルトの名無しさん

2006/12/20(水) 17:24:44

1文字1コード
こんなにもシンプルな事が何故できない

0766デフォルトの名無しさん

2006/12/20(水) 17:48:03

>>764のようなアホなことを思いつく人がこれ上出ないように、
CJK用のVariation Selectorをさっさと何とかしてほしい・・・

0767デフォルトの名無しさん

2006/12/20(水) 19:02:45

パとﾊﾟとか1文字1コードじゃないものがソースだったり
変換先だったりするのでなかなか出来ない。
日本語以外の言語でどうなってるかは本当調べるのも大変

0768デフォルトの名無しさん

2006/12/20(水) 19:30:08

それ以前に「何を1文字とするか」で合意するのが困難。

0769デフォルトの名無しさん

2006/12/20(水) 19:50:34

`ま゛'

0770デフォルトの名無しさん

2006/12/21(木) 07:28:15

>>769
それが認められたら画面にレンダリングする際に合成文字として表示しないと
いけないんだよね……
それをさらに右から左に表示したり……

0771デフォルトの名無しさん

2006/12/21(木) 22:18:33

>>762
> 辻希美が「功名が辻+（'）」を見て、どう思ってるのかな？
Vistaなので脳内JIS90レンダリングしないと意味不明です。
> ついでに、辰良丈+(')一郎についても・・・これはやめておこう。
それは別区点
>>770
COMBINING KATAKANA-HIRAGANA VOICED SOUND MARKだったら
その通りだけど>>769のはCOMBININGじゃないほうだから合成「してはいけない」

0772デフォルトの名無しさん

2006/12/21(木) 22:20:16

>>766
もうレジストリはできてるから後はやる気の問題。
Adobeには期待してるんだけどねえ

0773デフォルトの名無しさん

2006/12/21(木) 22:35:43

Unicode5.0になって楔形文字は入ったがエジプト聖刻文字が入らなかったのはちょっと残念。
でもこの辺全部サロゲートごりごりの領域だからアプリのほーが面倒だ（死

0774デフォルトの名無しさん

2006/12/21(木) 23:04:30

もはやギャグの領域だな
そのうちナメック語とか
ニャントロ星人のドゴン語とか入りそうだ

0775デフォルトの名無しさん

2006/12/22(金) 00:16:55

>>774
スタートレックのクリンゴン語はISO639言語コードに正式登録されてるぞ。
Unicodeにはいまのところ入ったりはしないだろうが、TRONは
文字として識別されるものならなんでも取り込むみたいだからなぁｗ

ttp://www.rikai.com/perl/LangMediator.En.pl?a=2004080445

0776デフォルトの名無しさん

2006/12/22(金) 00:23:45

Klingon文字は正式に却下されとる。
ttp://www.unicode.org/consortium/utc-minutes/UTC-087-200105.html

0777デフォルトの名無しさん

2006/12/22(金) 02:13:42

まぁISOで正式登録されたものは好きだろうが嫌いだろうが
実装しないといけない人もいるだろうし、大変ですね。

0778デフォルトの名無しさん

2006/12/22(金) 03:13:39

アプリでサロゲートに対応するのそこまで大変じゃないでしょ。たいていの場合は。

0779デフォルトの名無しさん

2006/12/22(金) 03:45:24

ここにいる人の中には大変な場合があるんでしょう。
たいていは通じませんよ。

0780デフォルトの名無しさん

2006/12/22(金) 06:34:14

たいていは通じるだろ。上位サロゲートと下位サロゲートでちょんぎんなきゃいいだけ。
これだけのこと。

0781デフォルトの名無しさん

2006/12/22(金) 13:58:25

i18n関係まともにやっているともっともっと大変な処理はたんまりありますぜ。
サロゲートなんかで大変と言っとると・・・

0782デフォルトの名無しさん

2006/12/22(金) 14:53:09

テキスト入力ボックスなんて考えたくもない

0783デフォルトの名無しさん

2006/12/23(土) 11:30:35

ttp://www.unicode.org/charts/PDF/UF900.pdf
U+FA20(草冠に龝)がU+8612(草冠に穐)と等価なのは何でだろう?
亀と龜なんて全然字形違うのに。

0784デフォルトの名無しさん

2006/12/23(土) 11:39:39

字形と言われても困るんだが。
同じ系統に属する字だから等価と見做すcollationがあっても何の不思議もない。

0785デフォルトの名無しさん

2006/12/23(土) 12:24:47

右から左への表示って、通常通りキャレットの位置計算から表示まで　ほとんどを左から右に表示するよう実装して、
何気にOSか何かのAPIに用意されているだろう、座標系を設定する関数使って、反転させたら、
よかったりして。

0786デフォルトの名無しさん

2006/12/23(土) 12:30:47

語学の教科書なんかでは、
行の途中の単語だけ逆にしなければいけないケースがあるんですよ。

0787デフォルトの名無しさん

2006/12/23(土) 12:47:46

>>785
フォントも左右反転されてな

0788デフォルトの名無しさん

2006/12/23(土) 17:07:32

U+FA11(立崎)とU+FA14(欅の略字)は崎や欅と等価とされてなくて、
統合漢字ブロックに等価な字が無い為「互換漢字ブロックにあるけど統合漢字とみなす字」とされてるわけだが。
何でU+FA20は違うんだろ?

0789デフォルトの名無しさん

2006/12/23(土) 19:16:03

Unicodeに一貫性を求めちゃダメです

0790デフォルトの名無しさん

2006/12/23(土) 22:58:44

WindowsXP SP2 の話ですが、
IMultiLanguage2::DetectInputCodepage() に Shift_JIS な
http://www.google.co.jp/ を GET したものを与えたら、
Shift_JIS とは全然関係ない CodePage として判定されてしまいました

これでは使えないので、Shift_JIS 等の一部の CodePage の判定は自前で
実装して特別扱いして回避しました

0791デフォルトの名無しさん

2006/12/23(土) 23:47:13

>>788
いい同値関係を定義できたら、公表してください。
JISにある文字だけでもかなり有意義だと思います。

0792デフォルトの名無しさん

2006/12/23(土) 23:55:52

>>790
googleはUTF-8ですけど。。。

0793デフォルトの名無しさん

2006/12/24(日) 00:13:11

>>791
97JISの規格票はわりと気合が入ってる。
過去の規格との互換性のために妥協せざるを得なかったところもあるけど

0794デフォルトの名無しさん

2006/12/24(日) 00:49:30

>>792
それは思い込みかと。User-Agent に応じて動作が変化するという認識です

0795デフォルトの名無しさん

2006/12/24(日) 00:57:02

文字コードの自動認識は単純なロジックベースだとつらいかもな。
文字コード毎に出現する可能性があるか、ないかのビットマップでも
共通するコードしか出てこない場合は区別難しい。
ある程度長いソースで単語の辞書とか文字の出現頻度の統計とか
組み合わせればなんとかなるけど、短い文書はつらい。
テキストエディタで2文字だけ入力して保存して読み込んでみるとわかると思う。

0796デフォルトの名無しさん

2006/12/24(日) 07:15:06

DetectInputCodepageはIEの判定処理そのものなんだから何かトチってるんだろ

0797デフォルトの名無しさん

2006/12/24(日) 11:44:52

>>796
試しに Web 検索してみたら、これでコード判定出来ますと
サンプルを掲載しているサイトが結構ヒットしました

きっと試したファイル等が処理にやさしいものだったのでしょうね
(試したとは書いてなかったりしますが)

0798デフォルトの名無しさん

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は名前でエクスポートされてねーよ

0799デフォルトの名無しさん

2006/12/24(日) 13:14:01

>>798
駄目サンプル晒しsageは基本的にウザイのだが、
せめて文字コード関連のサンプルを挙げてくれよん。

>>793
互換性妥協無し差分規則って公開している人いるのかね?
俺は一度マイルールを作りかけたことあるけど、量が多すぎて挫折した。
統一された基準を作り出すのは本当に大変。

0800デフォルトの名無しさん

2006/12/24(日) 15:42:58

>>787
それだよ。俺もフォントまで反転されそうな気がするけど、ひょっとして、フォントとかだけは、普通に
表示されるオプションとかあるのかもしれないと意味で、最後に「よかったりして」って付け加えた。

0801デフォルトの名無しさん

2006/12/24(日) 16:32:33

それだよw

0802デフォルトの名無しさん

2006/12/24(日) 16:34:54

どれだよ

0803デフォルトの名無しさん

2006/12/24(日) 21:03:54

>>799
6.3.3だけ見て残りの部分や適用除外(規定)は見なかったふりをする

0804デフォルトの名無しさん

2006/12/25(月) 13:17:35

>>803
それだと「王」と「壬」まで包摂しちゃうことになるぞ。

0805デフォルトの名無しさん

2006/12/26(火) 10:19:37

ああ～もぅーややこしすぎ

0806デフォルトの名無しさん

2006/12/26(火) 14:26:47

口ロ□
。oOｏＯ○

0807デフォルトの名無しさん

2006/12/26(火) 15:12:29

適用除外のうち「王・壬」だけを残して他を無視すりゃOKじゃね？

0808デフォルトの名無しさん

2006/12/27(水) 22:15:01

「王・壬」以外は大丈夫っぽい。つーかこんな罠がのっけからあるとは思わなかったorz

0809デフォルトの名無しさん

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と互換漢字を要し、
扱いに差がある。

0810デフォルトの名無しさん

2006/12/31(日) 00:40:39

>>809
> 他にも包摂規準 64 (且/旦)、70 (己/巳)、124 (犬/大) あたりが
なんでそれらの単独字は適用除外(規定)に入ってないんだ?
王/壬がなければ「単独字には適用できない」と解釈できたんだが…。
包摂規準 1 には3つ目の部分字体があることと関係してるのか?

0811デフォルトの名無しさん

2006/12/31(日) 04:22:42

>>810
> なんでそれらの単独字は適用除外(規定)に入ってないんだ?

むしろ王壬が載っているのがバグと考えるべきかも。

基本は
| 6.6.3 漢字の字体の包摂規準
| b) 包摂規準は，他のいずれかの漢字までを包摂するような適用を行ってはならない。
があるので、リストアップは無しでも問題ないはず。

でもそれだとあまりに不親切なので、JIS が一貫性無く収録してしまった
包摂字体に関してはきちんと情報提供しようという意図があるのでは?
棟諫鶇が載ってて楝諌鶇が載ってないのは載せなくても分かるからだろう
し、一方、初版に載っていなかった「仭」が正誤票で追加されているのは
必要があると判断されたからににちがいない。

少なくともリストで包摂除外を網羅的に規定していると判断してはならないのは
確か。単独字以外にも「任≠仼」とかあるわけで、こういうJIS 外字との
別字衝突は調べきれない。
だから 6.6.1 に「また，ここで規定する包摂規準を部分字体として演繹的に
適用することによって，新たな漢字字体を作り上げてはならない。」と書いて
済ませているわけで、実装者にある程度の文字の常識を要請している。

これを最初に読んだ時は「工業規格の規定がこれでいいのか」と思ったけど、
今は仕方ないと思っている。そこまで規定できるための情報を集めようと
思ったら、今になっても規格ができてないだろうから。

0812デフォルトの名無しさん

2006/12/31(日) 11:12:13

> 単独字以外にも「任≠仼」とかあるわけで、こういうJIS 外字との
> 別字衝突は調べきれない。
包摂規準はJIS外字との衝突はあまり考慮していないと思われ
JIS X 0212と比べてさえこれだけ類型異字の候補が出てくるし。
http://wakaba-web.hp.infoseek.co.jp/0212-0213/jisx0212-0213.ja.html

そもそもここでの最初のリクエストが
> JISにある文字だけでも
だったからそのへんは気にしてなかった。どうしても欲が出てくるんだろうけど

0813デフォルトの名無しさん

2006/12/31(日) 15:52:43

なんか、扱える文字増えたけどさ、合成文字だの左から右に読む文字だの、色々面倒なことの方がたくさん増えたな。
もう、なんたらJISの方が楽じゃねぇ？？まぁ、MicrosfotのMS932への文字の追加が止まってるのが痛いけど。

0814デフォルトの名無しさん

2006/12/31(日) 16:28:34

KISSの法則

0815デフォルトの名無しさん

2006/12/31(日) 17:48:32

あんまり（というかほとんど）文字コードについて詳しくないんですが、
>>804-あたりからの問題について意識ししないでシステムを作ったとすると
具体的にどのような問題が起こりえるのでしょうか？

0816デフォルトの名無しさん

2007/01/01(月) 15:34:43

>>815
フォントの実装でもしない限りプログラマにとってはあまり関係ない。
漢字ヲタクが気にするような問題

0817デフォルトの名無しさん

2007/01/01(月) 15:35:48

>>813
いまどきのプログラミング言語はふつー内部Unicodeなので変換の手間が増えるだけで
何もうれしくない

0818デフォルトの名無しさん

2007/01/01(月) 16:42:57

>>817
そうだけど、自前で、表示、入力しようと思ったら手間がかかる。合成だのなんだの。

0819デフォルトの名無しさん

2007/01/01(月) 16:51:02

ペイントソフトの文字の入力描画とかを作るのは大変ってことか

0820デフォルトの名無しさん

2007/01/01(月) 21:59:12

>>816
そうですか。ありがとうございました

0821デフォルトの名無しさん

2007/01/04(木) 19:44:49

文字コードのエンコーディングを自動判定するツール/ライブラリで
日本語以外も判定できるのって何がお勧め?
いま、とりあえずiconvでShift_JIS,WINDOWS-31J,EUC-JPからUTF-8への変換でエラーが
でるかどうかの情報とNKFでのguessとEncaでの判定とMozillaベースのCharGuessってライブラリ
での判定をまとめてみてるんだけど、まだ情報としてたりない気がするんだよね。
windows-1252のあたりが微妙な結果。
完璧な自動判定は無理だと思うのでなるべく多くのアルゴリズムで判定させたいんだけど
何かいいものあるかな?

0822デフォルトの名無しさん

2007/01/04(木) 20:14:05

>>821
MLang( IE で使われている文字コード処理エンジン )は、どう？
そういえば、テンプレに MLang が入っとらんね。

0823デフォルトの名無しさん

2007/01/04(木) 22:01:26

>>821
ありがとうございます。
MLang試してみます。
ファイルが置いてあるのはLinuxなのですが、Sambaで共有して
Windowsから判定させてみますね。

0824821=823

2007/01/04(木) 22:02:00

>>822
すいませんアンカー間違えました。

0825デフォルトの名無しさん

2007/01/06(土) 17:22:46

Windows-1252で0x81が未定義なのはやっぱりShift_JISとの判別精度を
上げるためなんだろうか

0826デフォルトの名無しさん

2007/01/17(水) 15:37:31

>>816
サーバサイドの場合、ブラウザからの入力文字がシステム内部で化ける可能性があるから関係してくる。

画面、DBを含めシステム全体で文字をUNICODEで扱っていれば問題ないが、一部でも文字変換をしていた場合、化けたり、文字チェックや文字数チェックで誤作動する可能性がでてくるでしょ。

だから、一概に関係無い話とは言い切れないのでは？

0827デフォルトの名無しさん

2007/01/17(水) 20:37:56

n-gramやるにはサンプルデータ用意するのが面倒なので
手軽にバイト単位のヒストグラムを作ってモデルとの差分を
積算するプログラムを書いてみた。

……なぜWindowsのシステムファイルとCygwinのバイナリを区別できる?
テキストでもそれなりに判別できそうな予感。

0828デフォルトの名無しさん

2007/01/17(水) 21:47:22

Unicode の文字列から「一文字ずつ」切り出す処理って、どうやったらいいんでしょう。
まあ素朴に、 "一文字ずつ" -> '一' '文' '字' 'ず' 'つ' みたいな。
Unicode の場合、例えば「ず」が「す+濁点」に分解されている場合があって、
面倒なようですが。

つきつめていくと「『一文字』って何?」ということにもなるのかな...
まとにかく、こういう目的に適したライブラリとかってありますか?

0829デフォルトの名無しさん

2007/01/17(水) 22:30:03

‏一文字‎ずつ‌?

0830デフォルトの名無しさん

2007/01/17(水) 22:34:18

‏ICUとかで正規化して自分が考える一文字で‎正規表現マッチさせればいいんじゃない?
制‌御‌文‌字‌と‌か‌は‌消さないと駄目かもねぇ。

0831830

2007/01/17(水) 22:41:40

>>830
こういうの対応するのめんどくせーよな。
単語で検索してもマッチしないし^^;
NGWordもうまく動いてくれない……

0832デフォルトの名無しさん

2007/01/17(水) 23:03:08

>>826
いや、>>804-の問題はそれとはぜんぜん関係ない。
まさに「複数の問題を混同しがちな～」というやつだな

0833デフォルトの名無しさん

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

0834830

2007/01/19(金) 20:20:53

830を「制御」で検索くらい試して欲しかったところ。
SETTING.TXTにBBS_UNICODE=passってなってると
ユニコード使えるんだねぇ。

文字を分割して、また結合したら別のものになる可能性があるから面倒だよなぁ。

ZERO WIDTHとかフィッシングに最適^^;

0835056

2007/01/19(金) 21:08:48

文字コードに関して誤った情報を掲載しているPDFファイルってインターネット上にありますか？

0836デフォルトの名無しさん

2007/01/19(金) 21:40:45

五万とあるだろ

0837056

2007/01/19(金) 23:10:44

よかったらURL教えてください？

0838デフォルトの名無しさん

2007/01/20(土) 01:06:43

なぜにPDF限定?

0839デフォルトの名無しさん

2007/01/20(土) 10:57:57

なぜに「誤った」情報？

0840デフォルトの名無しさん

2007/01/20(土) 13:22:41

【ネガティブ派遣根性チェック】

3つ以上、思い当たる点があればアナタの性格はひん曲がっており、ネガティブ負け組人生を歩んでいます。

□派遣先の人事権のある社員の意見はたとえ間違っていてもマンセーする
□派遣先から「いつまでもここで仕事してくださいね(安い金でｗ)」と言われている
□自社に仕事を持ち帰れるように言われるとムカつく
□自社で仕事なんてできるわけがない
□派遣労働の問題点の話題が出ると感情剥き出しにする
□派遣労働の問題を指摘する人は嫌いだ
□派遣先には仕事だけでなく自分のプライベートについても指示して欲しい
□自分の月額金額を知らない
□派遣先社員より自分の生涯収入が低いのは当然だ
□派遣先に尻尾を振り、いつまでも派遣を続けることが大切だ

0841デフォルトの名無しさん

2007/01/20(土) 16:32:29

森山さんとこの掲示板にも同じような質問が……

0842デフォルトの名無しさん

2007/01/23(火) 02:17:09

今WindowsMobile5.0で開発をしてるんですが、IMultiLanguage2
インターフェイスが作成できない(E_NOINTERFACE)んです。
IMultiLanguage2::DetectInputCodepageで読み取ったchar配列の
文字コードの判定をやりたいんですけど、
何かこれに代わる方法はありませんか？
無印の方は変換だけで、この関数は使えないんです。

IMLangConvertCharsetの初期化時にMLCONVCHARF_AUTODETECTを
つければ良さそうな気がしていろいろ試したんですがうまく動きません。
よろしくお願いします。

0843デフォルトの名無しさん

2007/01/23(火) 22:16:01

nkf

0844デフォルトの名無しさん

2007/01/26(金) 02:05:13

US-ASCIIかどうかの判定で0x20-0x7eという範囲指定じゃ駄目なんだな。
うぅISO646とか生まれる前からの呪いがまだ続いているよ……
ISO-8859系を前提にいれても無理やり入ってくるシフトJIS……
0x5cと0x7eは外しておいたほうが安全だな。

0845デフォルトの名無しさん

2007/01/29(月) 04:10:02

多言語の文字コードを調べようと思ったらStarDictというのを見つけた。
文字コードというか、辞書のソフトなんだがフリーで使える辞書の数がやたらと多い。
出現頻度とかの統計情報としては使えないが、Word-listの作成ソースとしては使える。

0846デフォルトの名無しさん

2007/01/29(月) 10:15:06

>>844
> US-ASCIIかどうかの判定で0x20-0x7eという範囲指定じゃ駄目なんだな。

どんだけずぼらなんだw

0847デフォルトの名無しさん

2007/02/04(日) 05:06:46

Unicode文字列の特定のキーワードの強調表示って本来どうあるべきかな？？
例えば、キーワードがaaaaとして、aaaaウムラウトの文字列を強調表示とか
で文字列を検索するときaaaaとウムラウトで分断すべきかな？？
つまり、表示上もaaaaとウムラウトで分断して表示すべきなかな？ややこしいな。

0848デフォルトの名無しさん

2007/02/04(日) 12:51:30

>>847
* あいまい検索とみなして、aaaaウムラウト、まで強調する
* 完全一致とみなして、全く強調しない
の二択だと思う。
「aaaaウムラウト」の「aaaa」だけ強調っていうのは、合成文字だって意識すると自然だけど、
ユーザ的には「aウムラウト」で「一文字」でしょ。

0849デフォルトの名無しさん

2007/02/06(火) 01:44:55

置換処理のような機械的なものと違って、強調表示の場合は
ユーザーが文字として認識する物を対象にするのが自然だと思う。
a+ウムラウトをaと見なすかどうかをオプションとしてユーザに選択させるのがいいんじゃないかな。
ただ、曖昧検索はどこまで曖昧かが難しいところもあるな。
「スーパーマン」が「ｽ-ﾊﾟ-ﾏﾝ」にマッチするかとか。
「ま゜」とか「み゛」とかやめてくれｗ

0850デフォルトの名無しさん

2007/02/06(火) 02:01:43

847です。
>>848,>>849ありがとうございます。いわいる前にもでてた、書記素(grapheme)のことですね。
今は単純な文字コードをマッチングしてるだけですが、完全一致するとなると、書記素を分割しないようにアルゴリズム
変えなきゃいけなさそうですね。うーん。あいまい検索にしてもいろいろ面倒そうですね。

0851デフォルトの名無しさん

2007/03/05(月) 21:28:43

Ideographic Variation Database submission (AdobeJapan1)キター!!
http://www.unicode.org/ivd/pri/pri98/index.html

0852デフォルトの名無しさん

2007/03/05(月) 21:30:40

これでAJ16の漢字グリフはK-JISからの3文字と電算写植用外字からの4文字を除いて
すべてUnicodeのプレーンテキストで表現できるようになる見込み

0853デフォルトの名無しさん

2007/03/05(月) 22:44:08

あれ？じゃあ包摂基準って結局どうなるわけ？

0854デフォルトの名無しさん

2007/03/05(月) 23:18:09

>>853
VSを付けない場合は従来通り字体は保証されない。
JIS90かJIS2004かわからないどころかGB18030の字体が出る可能性すらある。
もちろんフォントが対応してないとVSを付けても字体は保証されないんだけど
Unicodeの仕様として保証されないのとは問題のレイヤが違う。

0855デフォルトの名無しさん

2007/03/05(月) 23:32:08

あとJIS X 0208/0213にはIdeographic Variation Selectorなんて定義されてないし
半角カナの領域でもつぶさないと追加も不可能なのでJISの包摂規準には関係ない。
Unicodeに移行してかつサロゲートと結合文字に対応している場合にのみ
恩恵が受けられる。
もうMODIFIER LETTER EXTRA-HIGH EXTRA-LOW CONTOUR TONE BARなんか
誰も使ってねーよ、みたいな言い訳はできないぞ。

0856デフォルトの名無しさん

2007/03/06(火) 01:08:36

素晴らしいかも。
あとはAdobe-Japan1-6のフォントがもっと一般に出回れば・・・
ヒラギノはどうなるんだろ。MSのメイリオは絶望的？

0857デフォルトの名無しさん

2007/03/06(火) 01:18:49

>>856
ヒラギノはLeopardでAdobe Japan1-5NとかいうAdobe Japan1-5CMAPをJIS2004対応に
書き換えたものに対応するかも。
http://www.fontworks.com/new/news/2007/070205.html
http://www.tcp-net.ad.jp/danbo/page2007/index.html
VSにまで対応するかどうかは今のところ不明。

0858デフォルトの名無しさん

2007/03/06(火) 01:37:23

これ、たとえば「骨」(U+9AA8)に対しても、
U+9AA8 U+E0100 = CID+2062
という定義がされるわけね。

文書全体で確実に日本語の書体が選ばれるように
するには、やたらめったらU+E0100を挟みまくるように
なるのだろうか。

0859デフォルトの名無しさん

2007/03/06(火) 07:23:39

そういう目的なら言語タグのほうでしょう。こっちは実装される見込みがまったくなさそうだけど

0860デフォルトの名無しさん

2007/03/06(火) 07:24:44

小塚明朝と小塚ゴシックがAcrobatReaderには付いてくるけど・・・

0861デフォルトの名無しさん

2007/03/06(火) 12:49:52

>>860
ProじゃなくてStdじゃなかった?

0862デフォルトの名無しさん

2007/03/06(火) 19:30:18

Adobe Readerの日本語フォントパックには
AJ1-6フル実装の小塚明朝Pro VI-Rが付いてる。

それはさておき、公開レビューの締め切りが迫ってるので
万が一間違いとか見つけた人は速やかに報告すべし。
http://www.unicode.org/reporting.html
つーか去年の12月15日から公開レビューやってたらしいのに
ぐぐってもunicode.org内のサイトしかヒットしないわけだが、
何で日本人は決まるときには何も言わないくせに施行間近になってから急に
騒ぎ出しますか? JIS2004とかCJK統合漢字とかPSE法とか…

0863デフォルトの名無しさん

2007/03/06(火) 19:51:53

決めることはお上のやることだと思ってるからじゃない?

0864デフォルトの名無しさん

2007/03/07(水) 04:30:50

日本人のメンタリティの中ではMSも「お上」に含まれてる気がする

0865デフォルトの名無しさん

2007/03/07(水) 11:06:26

上といえば政財界のことだろ。当然MSも含まれる。

0866デフォルトの名無しさん

2007/03/07(水) 12:59:52

指定の仕方を教えてもらえないかな。
あるいはレファレンスのポインタでも。
（unicode "variation sector"だとgoogleで一つも当たらないんで）

>>851のpdfを見ると、9AA8 骨にはvariationの指定がない。
なくても、>>858で言ってるように
U+9AA8 U+E0100で、CID 2062（日本では普通の骨）が出るってこと？

utf16BEのbyte列だと
「9AA80E0100」となっているものを処理できればいいのかな？

見当違いなことを聞いていたら申し訳ないです。

0867866

2007/03/07(水) 13:00:58

ごめん。検索wordを間違えてた。

0868デフォルトの名無しさん

2007/03/07(水) 21:50:41

>>866
> >>851のpdfを見ると、9AA8 骨にはvariationの指定がない。
partial chartsのほう見てない? complete chartsにはvariationが1つしかなくても
ちゃんと載ってるはず(今確認した)。さらに念を押しておくと文字の下にあるVS17-2062は
VS17を付けるとCID+2062の字体になるという意味。他の字体が存在する必要はない。
sequences.txt見てもちゃんと
> 9AA8 E0100; Adobe-Japan1; CID+2062
って行があるし。
将来異体字が追加されるかもしれないし>>854で書いたようにvariationなしは
明確に意味が違うので現在字体が1つしかなくてもvariationの定義は必要。
> utf16BEのbyte列だと
> 「9AA80E0100」となっているものを処理できればいいのかな？
U+E0100はSSPの文字です。ちゃんとUTF-16のコードポイント計算してください。
ドラフト段階で叩かれまくって放棄されたUCS-2Eじゃあるまいし
http://slashdot.jp/~yasuoka/journal/387747

0869デフォルトの名無しさん

2007/03/08(木) 14:36:42

繝ッ繧コ縺輔ｓ莉穂コ九ｄ繧√ｋ繧薙〒縺吶°(>_<)

↑のような文字化けを直したいのですが、どうやって直したらいいのでしょうか？

0870ッbゃRさん仕ﾒめるんですか(>_<)

2007/03/08(木) 15:14:09

>>869
エンコーディングを適切に設定する。
つーか、PC初心者板辺りで聞いたら?
もしあんたがプログラミングにおいて困っているのなら、何故そのような文字化けが発生したのか背景から説明しろ。
#あ、それでもやっぱりスレ違いか。

0871デフォルトの名無しさん

2007/03/09(金) 01:33:09

> K-JISからの3文字と電算写植用外字からの4文字
ちなみにこれらはExtension CかDに追加する予定らしい。
http://www.cse.cuhk.edu.hk/~irg/irg/irg27/IRGN1256.pdf

0872デフォルトの名無しさん

2007/03/09(金) 02:13:29

先生質問。
CJK Ideographのvariationには、なぜVS1～VS16 (U+FE00?U+FE0F)
を使わず、SSPなんぞにあるVS17～を使うことになっているの？

0873デフォルトの名無しさん

2007/03/09(金) 02:23:09

・BMPにあるVSの奪い合いになることをおそれて「みんな平等にSSP」にした。
・Mongolian専用のVSがあるように、VS17～240はHan専用にしたかった。

0874デフォルトの名無しさん

2007/03/09(金) 02:33:43

うーむ。

> ・BMPにあるVSの奪い合いになることをおそれて「みんな平等にSSP」にした。
これってBMPのVSをCJKVで取り合って大ゲンカになるってことかな？
だったら少なくとも、CJKVそれぞれで何らかの代表的な字体1種は平等に
VS1～最大でVS4までに格納、それ以降は早いもの順か抽選、ってのでも
良かったのでは・・・

0875デフォルトの名無しさん

2007/03/09(金) 02:45:49

だからそういうことはUTS#37のレビュー期間中に言えと。
つーか単なる想像なので本当にそういう理由なのかどうかも定かではない

0876デフォルトの名無しさん

2007/03/12(月) 17:32:56

【XBOX360】Grand Theft AutoⅣ総合スレ1【GTA】
名前：なまえをいれてください
E-mail： sage
内容：
2007年10月16日発売

XBOX360、PS3の両ハードで同時発売。

※尚、Xbox360版ではPS3にない追加シナリオがXbox Live経由で
独占供給されることが明らかになっている

開発：Rockstar Games

2007年3月1日より公式サイトにてトレーラーのカウントダウンが開始され、
米国時間の3月29日に公開予定

公式サイト
ttp://www.rockstargames.com/IV/

通販で予約受付中
ttp://item.rakuten.co.jp/gdex/119-10148/

0877デフォルトの名無しさん

2007/03/15(木) 04:03:46

ISO/IEC 10646 Amd.4からついに実装水準1と2が削除されるらしい。
Unicodeは最初から実装水準3のみを前提にしてたから今さらといえば今さらなんだが

0878デフォルトの名無しさん

2007/03/15(木) 04:04:19

> ISO/IEC 10646 Amd.4
ISO/IEC 10646:2003 Amd.4ね

0879デフォルトの名無しさん

2007/03/17(土) 19:08:10

>・BMPにあるVSの奪い合いになることをおそれて「みんな平等にSSP」にした。
どうせ字体気にしてVSが必要なのは日本くらいでしょう。

0880デフォルトの名無しさん

2007/03/18(日) 00:02:56

>>879
実はそう思うけどね
タテマエというものがあるし

0881デフォルトの名無しさん

2007/03/19(月) 00:59:39

ttp://www.unicode.org/ivd/pri/pri98/pri98-partialcharts.pdf
これ見たけど「囀」の拡張新字体の「口転」とか手書き等でよく使われる「曜」の略字「日玉」は
字形が大きく違うのに「囀」や「曜」と包摂扱いにして「囀」や「曜」+異体字セレクタで表す事にしちゃうんだね。

0882デフォルトの名無しさん

2007/03/19(月) 01:29:24

>>881
Extension Cに中国が提案した簡体字のいくつかは繁体字が収録済みという理由で
却下されてるからそういうものかも(BMPで簡体字が分離されてるのはあくまで
原規格分離のための例外扱いってことで)。

0883デフォルトの名無しさん

2007/03/19(月) 11:08:08

近年発見、命名された104番以降の元素を表す中国での漢字は
繁体字は既にある統合漢字の無印、拡張Aと衝突したり(「金盧」「金麥」)、
そうでない字(「金杜」など)は拡張Bに追加されて全て使えるようになった。
が、これらの簡体字は画像とかで良く見るがコードは定義されておらず拡張Cにも追加されないみたいだから
これらも>>882に書いてある通り繁体字と包摂として区別したい場合は異体字セレクタを使えという事なんだね。

0884デフォルトの名無しさん

2007/03/23(金) 20:48:30

他にVSで表す包摂扱いの字体差が大きい異体字には
何でよく見るのにJIS X 0213にも拡張Bにも無いんだろうと思ってた「撥」の拡張新字体なんかもあった。
「痙」の拡張新字体もあるがこれは中国簡体字のU+75C9に包摂するべきでは?「径」は中国の簡体字(旁がスの下にエ)と包摂されてるし。
「門」の手書きでよく使われる略字もあるが、これも「門」よりも中国簡体字のU+95E8のほうが近いからそっちの方が良いと思う。
U+9C75(魚箴)は強烈。いくら何でも違いすぎる。(魚針)
ひょっとしたら後で実は別字だったとか日本では異体字だが中国では別字とかになるかも知れんぞ。

0885デフォルトの名無しさん

2007/03/23(金) 21:11:31

Adobe-Japan1だから日本で異体字かどうかが基準なんだろ。
どう考えてもabstract shapeが違うものまでVSで表していいのかって気はするけど

0886デフォルトの名無しさん

2007/03/23(金) 21:13:47

ちなみにUnicode MLがAdobe-Japan1のsubmissionに関してプチ盛り上がってる

0887デフォルトの名無しさん

2007/03/23(金) 21:17:57

VSを省略されたとき日本のフォントで表示される可能性が高い方がたぶんありがたいし

0888デフォルトの名無しさん

2007/03/27(火) 20:36:27

UnicodeのMLで広大の人が主張していることは正しいんだけどさ、
JIS X 0213ソースの互換漢字のラウンドトリップが保証されないのは
UTS #37の問題っていうより、ああまた例の古傷がって感じだよな。

0889デフォルトの名無しさん

2007/03/27(火) 20:54:57

MLで言えよ

0890デフォルトの名無しさん

2007/03/28(水) 05:01:31

MLで言おうとしたら直メールで返信になってしまったorz
なんでUnicode MLのメールはReply-Toが付いてないんじゃー
>>888
UTS #37はむしろ問題解決の手がかりになると思う
IVSで表せば正規化しても消えないということだから。
レガシーな環境(現行の環境ほぼすべてがそうだけど)だと字体が反映されないとか
Unicodeのdefault ignorableやサロゲートをまじめに実装していないと
VSがゴミとして表示される可能性があるって問題はあるけど。

0891デフォルトの名無しさん

2007/03/28(水) 10:16:53

> なんでUnicode MLのメールはReply-Toが付いてないんじゃー

そんなもの付けているやつはばかです

0892デフォルトの名無しさん

2007/03/28(水) 12:27:18

>>890
せっかく公開するつもりで書いたんならMLにもポストし直せば？
「あなたは互換漢字をIVSに置き換えるのを禁止しろと主張しているが、
むしろ互換漢字のままのほうが危険だぜ」とでも書いたの？

# いらっしゃいませ実装依存の世界へようこそ！

0893デフォルトの名無しさん

2007/03/28(水) 20:56:31

>>891
MLがデフォルトで付けるReply-Toがないって話なんだが
>>892
いや全然別のポストに対する全然別の返信。
タイミング的に紛らわしかったけど。
しかも別の人からもっと詳細なReplyがすでに付いて言いたいこと全部言ってくれたので
今さらポストし直す必要なくなった

0894デフォルトの名無しさん

2007/03/28(水) 21:12:59

ちなみにレガシー実装との互換性に配慮するなら互換漢字はそのままで
(その互換幹事の字体を表す)VSも付ければいいと思われ
正規化されても字体の情報は消えないし正規化されなければ
レガシー実装は単にVSを無視するだけでおそらく期待した表示結果になる

0895デフォルトの名無しさん

2007/03/28(水) 22:02:07

> MLがデフォルトで付けるReply-Toがないって話なんだが

そんなもの付けているやつはばかです

0896デフォルトの名無しさん

2007/03/29(木) 01:15:58

いや、それ（0213ソースの互換漢字にVSを付ける）ができない仕様だから
問題になってるんだと思うが。こっち↓を見ると判りやすいかな。
http://www.unicode.org/ivd/pri/pri98/pri98-completecharts.pdf

0897デフォルトの名無しさん

2007/03/29(木) 04:29:45

>>895
あーvoidネタだったのか
マジレスしてほしいんだがRFC 2822には何のためにReply-To定義してるの?
>>896
MLで言ってるのは「仕様書に」互換漢字+VSの組み合わせを載せるのがおかしいから
修正したということだけ。
互換漢字+VSは統合漢字+VSと正規等価なのだから後者が有効な組み合わせなら
前者も全く同等に扱わなければならない。
仮に有効とみなされなければそれは正規化をちゃんとサポートしてない実装
(つまりレガシー実装)だからそれはそれで問題ない。

0898デフォルトの名無しさん

2007/03/29(木) 07:42:33

まぁ確かに、MLへの返事を発言者にしてしまうようなカスみたいなメイルクライアントを使うのなら
それ相応の注意を払うのが当然だがな。

0899デフォルトの名無しさん

2007/03/29(木) 10:24:47

>>897
マジレスしてやるよ。
http://www.unicom.com/pw/reply-to-harmful.html
http://www.metasystema.net/essays/reply-to.mhtml

0900デフォルトの名無しさん

2007/03/29(木) 10:58:29

誰か掻い摘んでくれ。

0901デフォルトの名無しさん

2007/03/29(木) 11:44:18

>>900
「そんなもの付けているやつはばかです」

0902デフォルトの名無しさん

2007/03/29(木) 13:20:20

>>897
参照してる発言はこれ？
Message-ID: <[email protected]>
Date: Tue, 20 Mar 2007 22:55:09 -0700
From: Eric Muller <[email protected]>

少なくともこれを読んだ限りでは、
互換漢字にVSを付けてもいいなんて解釈は
できない気がするが。
他にソースがあるならポインタ希望。

0903902

2007/03/29(木) 14:55:09

Eric Muller wrote:

> Start with the sequence of JIS code points <41-78, 1-14-24>.
> Turn that into a PDF using a AJ1 CID font, the PDF contains
> CIDs 3552 and 13382 (and no direct trace of the JIS code
> points). Use the registered sequences <4FAE, E0100> and
> <4FAE,E0101> in the ToUnicode map. If you want to go to JIS,
> turn <4FAE, E0100> into 41-78, and <4FAE, E0101> into 1-14-24.
>
> Compare with the current scenario: the ToUnicode map contains
> <4FAE> and <FA30>; any normalization on that reduces both to
> <4FAE>, and certainly you cannot recover your original JIS
> code points.

0904デフォルトの名無しさん

2007/03/29(木) 17:22:45

ていうかごく単純に、仕様書に載ってないシーケンスは
IVDに登録されない（つまり使えない）んじゃね？

0905デフォルトの名無しさん

2007/03/29(木) 18:59:18

登録されていないバリエーションシーケンスは使えない。
http://www.unicode.org/reports/tr37/

> IVSes are subject to the usual rules for variation sequences: unregistered
> IVSes (which are not in the database) should not be used in text
> interchange, and registered IVSes should be used only to restrict the
> rendering of their unified ideograph to the glyphic subset associated with
> the IVS in the database.

互換漢字のバリエーションシーケンスは登録されない。
http://www.unicode.org/ivd/pri/pri98/sequences.txt

0906デフォルトの名無しさん

2007/03/30(金) 02:34:40

>>902-905
http://www.unicode.org/versions/Unicode4.0.0/ch03.pdf
> C9 A process shall not assume that the interpretations of two canonical-equivalent character
> sequences are distinct.
統合漢字+VSで字形が変わるのに互換漢字+VSで字形が変わらなかったらC9に違反する。

0907デフォルトの名無しさん

2007/03/30(金) 03:14:55

うーむ。
http://www.unicode.org/versions/Unicode4.0.0/ch15.pdf#G19053
> The base character in a variation sequence is never a combining character or a decomposable
> character.
しかしこの通りに実装したらC9を満たせないんだからこりゃ規格のバグだな。
たぶんこれ書いた奴は欧米人だからcombining characterを含むsequenceに分解される
decomposable characterのことしか想定してなかったんだろう。

というわけで困る人は「統合漢字に分解される互換漢字+VS」は「分解後の統合漢字+VS」
と等価であることを明確化してくれ、と働きかけてみるのがいいと思われ

0908デフォルトの名無しさん

2007/03/30(金) 03:37:54

ちなみにISO/IEC 10646の定義だと
http://std.dkuug.dk/jtc1/sc2/wg2/docs/n3186.pdf
> 20.4 Variation selectors and variation sequences
> Variation selectors are a specific class of combining
> characters immediately following a non decomposable
> base character and which indicate a specific variant
> form of graphic symbol for that character. A decomposable
> character is a character for which there exists an
> equivalent composite sequence.
で、
> 4.14 Composite sequence
> A sequence of graphic characters consisting of a noncombining
> character followed by one or more combining
> characters (see also 4.12).
だから互換漢字はdecomposable characterではない。やっぱバグだな

0909デフォルトの名無しさん

2007/03/30(金) 03:40:07

> やっぱバグだな
やっぱUnicodeの定義のバグだな

0910デフォルトの名無しさん

2007/03/30(金) 13:58:17

>>906
C9は「区別されると想定するな」ってことであって、「区別するな」ではない。
たとえば統合漢字と互換漢字を区別してソートするプログラムは「C9違反」か？
そんなわけないだろ。

>>907
だからUnicodeのバグではないし、
そもそも互換漢字+VSを使うことが禁止されているのに
「互換漢字+VSというデータの解釈の話」をしても意味があるとは思えない。

>>908-909
「互換漢字はdecomposable characterではない」ってネタのつもり？
n3186の、分解や互換漢字自体がテーマになっているわけでもない箇所に
ちょっとしたミスがあるってだけの話じゃん。

0911デフォルトの名無しさん

2007/03/30(金) 22:17:02

> たとえば統合漢字と互換漢字を区別してソートするプログラムは「C9違反」か？
> そんなわけないだろ。
C9だけ見たら違反しないかもしれないがそんなわけある。
CollationのときはまずNFDにしろと言ってるぞ
http://unicode.org/reports/tr10/#Step_1
> 分解や互換漢字自体がテーマになっているわけでもない箇所に
ISO/IEC 10646ではdecomposable characterという用語はここにしか出てこないよ。
variation sequencesの定義で使うためだけにここで定義してる

0912デフォルトの名無しさん

2007/03/30(金) 22:47:17

> C10 When a process purports not to modify the interpretation of a valid coded character representation,
> it shall make no change to that coded character representation other than
> the possible replacement of character sequences by their canonical-equivalent sequences
> or the deletion of noncharacter code points.
つまり統合漢字+VSを互換漢字+VSに置き換えてもテキストの解釈は変化しない。

0913デフォルトの名無しさん

2007/03/30(金) 23:57:33

>>911
> C9だけ見たら違反しないかもしれないがそんなわけある。
> CollationのときはまずNFDにしろと言ってるぞ
Collationなら正規化するのは当然だろ。全然反証になってないぞ。

> ISO/IEC 10646ではdecomposable characterという用語はここにしか出てこないよ。
> variation sequencesの定義で使うためだけにここで定義してる
だからその用語が「ここにしか出てこない」ISO/IEC 10646が正しくて
みっちり定義しているほうのUnicodeが間違ってるって発想はどこから出てくるんだ
という意味のことを>>910で書いたつもりなんだが。

>>912
> つまり統合漢字+VSを互換漢字+VSに置き換えてもテキストの解釈は変化しない。
繰り返しになるが、その「置き換えても」という仮定が無意味。

0914デフォルトの名無しさん

2007/03/31(土) 05:51:27

>>913
> Collationなら正規化するのは当然だろ。全然反証になってないぞ。
Collationはソート(など)のために定義されてる規格だろ。日本の都合で統合漢字と
互換漢字を区別するためだけに俺様ソートアルゴリズムを使うのか?
北朝鮮から文句言われるぞ

日本のユーザーとして統合漢字と互換漢字を区別したい気持ちはよくわかるが
そもそもそれが許されるんだったら区別のためにコードを割り当てる必要自体がない。
Adobeの連中の考えの根底にあるのは「JIS X 0213(およびAdobe-Japan1)の立場で
は区別される2つの漢字を区別するために(正規等価でない)IVSの割り当てが必要」
なんだから、こっちはそれを逆手にとって「だったら統合漢字+VSと互換漢字+VSだって
正規等価だから区別できませんよね?」と言ってやればいい

> 繰り返しになるが、その「置き換えても」という仮定が無意味。
そもそも「禁止されてる」なんてどこに書いてる? 出現すること自体は禁止されてない。

0915デフォルトの名無しさん

2007/04/02(月) 04:56:04

46 72 E5 B0 86 E3 82 A2 64 E5 B0 86 E3 82 A2 72
69 63 20 43 68 6F 70 69 6E

これショパンの名前みたいなんだけど、デコード出来ないで困ってます。
なんていう文字コードでエンコードされてるんでしょう?

0916デフォルトの名無しさん

2007/04/02(月) 05:04:45

UTF-8

0917デフォルトの名無しさん

2007/04/02(月) 05:45:44

Frédéric Chopin

0918デフォルトの名無しさん

2007/04/02(月) 07:11:27

ブラウザに放り込んでUTF-8を選択しても
Fr将アd将アric Chopin
という風に出てしまうんですよね。

>>917のようなéにデコードするにはどうすればいいんでしょう？

0919デフォルトの名無しさん

2007/04/02(月) 08:07:18

iconv -f utf-8

0920デフォルトの名無しさん

2007/04/03(火) 01:42:25

世界のどっかの偉い人がとっとと、「はいパソコンで使える
文字コード体系はこれです！！」って決めろよ。
いつまでだらだらやってんだよ。
全世界の文字網羅するつもりか？
発展途上国の独自の文字コードも実装しても
その発展途上国の人間は民族争いと淘汰で
首ひきちぎられて、地雷ふんじまって
鉛筆すら手に入らない状況だろうよ

0921デフォルトの名無しさん

2007/04/03(火) 06:24:54

つGB18030
共産党の担当者が偉い人かどうかは知らんがw

0922デフォルトの名無しさん

2007/04/11(水) 10:04:01

しつもんです。
JISやSJISで0x80以上ってかなりの確率で半角かななのでしょうか?

0923デフォルトの名無しさん

2007/04/11(水) 12:51:53

>>922
いいえ。

0924デフォルトの名無しさん

2007/04/11(水) 19:32:03

確率て

0925デフォルトの名無しさん

2007/04/11(水) 20:21:51

SJIS で半角ｶﾅは 0xA1～0xDF までだぜ。

0926デフォルトの名無しさん

2007/04/12(木) 14:09:26

80～FFまでの128個中、A1～DFの63個が半角かなだから
割合としては63/128≒49.2%だな。

0927デフォルトの名無しさん

2007/04/12(木) 14:43:52

>>926
頻度を考慮しろバカ

0928デフォルトの名無しさん

2007/04/12(木) 15:21:05

漏れのkakikomi.txtは0.156484%が一バイトかなだった。
このスレのログは0.0141597%だった。
この板の(漏れが取得した)ログは0.11844%だった。

0929デフォルトの名無しさん

2007/04/12(木) 15:24:13

確率を全て一様に等しいものと考えてしまうのは教科書脳のなせるわざだな

0930928

2007/04/12(木) 15:50:14

おまけ。
某ホムーランスレのログは1.12698%だった。
やはりAAには一バイトカナが多いらしい。
それでも、「かなりの確率」とは言い難いな。寧ろ、0x80以上は殆どが漢字だと言うことだ。
#実際にはOpenJaneのログだから純粋な書き込みだけではないが、まぁ誤差だろう。

0931デフォルトの名無しさん

2007/04/12(木) 23:41:55

参考までに...

つ http://tricklib.com/cxx/ex/babel/scoremap.csv

バベルの文字コード判定で使ってる日本語文書内での各文字の出現頻度データです。
出現頻度が100未満のものは切り捨てています。csv の各行は...

出現頻度, SJISでのコード, EUCでのコード, UTF8でのコード, コメント

...こんな感じ。元にしたデータはブラウザがキャッシュしてたデータ(インターネット上のテキスト)です。

# このデータを使って文字コード判定を行えばわずか2,3バイト程度のテキストでも
# 非常に高い確率で正確に文字コード判定が行えます。

0932931

2007/04/13(金) 00:45:15

追記：
文字コード判定用のデータなんでUTF16で0xFF以下の表現になる文字は含まれとらんです。

0933デフォルトの名無しさん

2007/04/13(金) 06:37:58

>>931
頻度が100というのがよくわからないな。頻度じゃなくて出現回数ですね。
こういう場合、上位500件とか全体の95%の条件で切り捨てするのでは?
元にしたデータはもうちょっと再現性のあるものにしないと
偏りがありますね。逆にジャンル別統計データのような形で持っておくと
あとで合成するのにいいかも。

2,3バイトでの文字コード判定というのは危ないような。
4バイトあればbigramにしてもうちょっと精度上げられそうだけど。

0934デフォルトの名無しさん

2007/04/13(金) 11:53:43

日本語のでかいコーパスから出したbigram頻度、どっかに
落ちてないかな。

0935デフォルトの名無しさん

2007/04/13(金) 12:26:49

新聞社のCD-ROMとかが使えればいいんだけど
bigram頻度出すためには全文をテキストファイルで
アクセス出来ないと駄目だよね。
ttp://cl.naist.jp/nldata/corpus/
が参考になるかも知れないけど2006年時点で
95年度版CD-ROMを対象にしているあたり鮮度に問題がある。

青空文庫は文学に偏りすぎる。

Wikipediaのデータベースのダンプをダウンロードできるので
それを使う手もある。

言語処理学会入るというのは、ちょっと躊躇うなぁ^^;
ttp://www.nak.ics.keio.ac.jp/NLP/guide/admission.html

0936931

2007/04/13(金) 23:11:58

>>933
>頻度じゃなくて出現回数ですね。

そうです。

>こういう場合、上位500件とか全体の95%の条件で切り捨てするのでは?

データ量に対する判定精度への影響具合と元データの偏りやノイズを考えて
100未満のデータを切り捨てたですよ。

>2,3バイトでの文字コード判定というのは危ないような。
>4バイトあればbigramにしてもうちょっと精度上げられそうだけど。

そうですね。現在すでにバベルは実用上まず誤判定することがない
精度を達成できてると自負してますけど、より完璧な判定の為には
bigramの導入も考えるべきですね。

0937デフォルトの名無しさん

2007/04/19(木) 00:20:12

今思ったんだけどUnicodeの注音字母はU+3105から始まっててU+3100～U+3104が空いてるのは何でだろ?

0938デフォルトの名無しさん

2007/04/19(木) 13:50:34

世界中で言語がバラバラになったのはバベルの塔のせいなのに

0939デフォルトの名無しさん

2007/04/19(木) 18:04:05

イザナギが振り向いたからじゃなかったっけ？

0940デフォルトの名無しさん

2007/04/19(木) 19:37:55

バベルの塔が崩れたのを察知して
イザナギが振り向いたとか。

0941デフォルトの名無しさん

2007/04/19(木) 19:59:37

バベルの塔は崩れてないだろ。

0942デフォルトの名無しさん

2007/04/19(木) 20:03:28

バベルの塔って新バビロニアの頃だからせいぜい紀元前6,7世紀だよな？

0943デフォルトの名無しさん

2007/04/20(金) 00:17:50

W3Cの勧告の数値文字参照の部分をどう解釈したものか迷っています。勧告の原文には
The syntax "&#xH;" or "&#XH;", where H is a hexadecimal number, refers to the ISO 10646 hexadecimal character number H.
とあります。では ISO 10646 character number とは何なのかと？

BMP面以外の文字を扱う場合、IEやFirefoxはサロゲートペアを解釈して1文字として表示するようになっているようです。
例えば、𠮷(𠮷) と書いても &#xd842;&#xdfb7;(��) と書いても、
上が「土」になってる「吉」が表示さます。環境によってはカッコ内に同じ文字が見えていると思います。

これはブラウザ側での勝手な拡張なのか、それとも、ISO 10646 にサロゲートペアの使用が含まれているということなのでしょうか。

0944デフォルトの名無しさん

2007/04/20(金) 01:13:21

ブラウザの勝手な拡張というかお節介なだけ。
実体参照の大文字小文字の区別だとか;の省略だとかそういった
いやーな実装の一つだな。

# n文字以上入力してくださいというところにサロゲートペアで
# ねじこむとか荒業出来そうだねぇ。>セキュリティ方面
# あ、あと別に16進じゃなくて10進で書いても同じ動作だろう。

0945デフォルトの名無しさん

2007/04/20(金) 20:19:54

>>943
サロゲートペアを1文字と解釈するのは「バグ」
Firefox3.0では表示されないようになってるね。

0946デフォルトの名無しさん

2007/04/20(金) 20:59:48

この場合サロゲートペアと呼ぶのも正しく無い感じがする。
なんだかんだあったけどISO10646=UCS-4で扱っていいんだよね?
UTF-16で表現するときにだけサロゲートペアが発生する。
ISO10646とかUCSが求められている場所ではサロゲートの領域のコードが
出たら駄目でしょ。

0947デフォルトの名無しさん

2007/04/21(土) 00:37:32

Unicode=UCS2だとおもって今まで実装してきたのに、
突然Unicode=UTF-16だと言われても、困ります。
サロゲートペアをフォントに紐付ければいいだけだろって
そんな単純な話じゃないんですよ、みたいな。

0948943

2007/04/21(土) 04:38:14

遅くなりましたが、皆さんありがとうございます。
やはり素直に解釈すれば、ISO 10646 character number とは UCS-4 におけるコードポイント、
ということになりますね。

実は、テキスト文書に含まれる文字のうち、ある文字コードで扱えない文字を数値文字参照に
置き換える、というソフトを作成していまして、その実装をどうするかで迷っていたのです。
サロゲートペアは一切扱わない方向で行くことにします。

0949デフォルトの名無しさん

2007/04/21(土) 04:50:22

今気づいたけど、>>943をOpenJaneのポップアップで見ると、𠮷が土吉じゃなくて
TAMIL LETTER SSA になってる。
どうも下位16ビットしか見てないようですね。

(´-`).｡oO(Janeスレで報告してくるか……)

0950デフォルトの名無しさん

2007/04/26(木) 05:38:13

結局、「異体字タグ」ってこれのことなんでしょうか↓
http://www.unicode.org/Public/UNIDATA/StandardizedVariants.html

個人的な名簿の整理をしていてふと気になって調べてみたのだが...
日本語で恩恵を受けられるようになる日はいつのことやら。

0951デフォルトの名無しさん

2007/04/26(木) 15:25:01

MacでAJ15使ってれば
そのうちIVSの読み込み／書き出しがサポートされるんじゃね？

0952デフォルトの名無しさん

2007/04/27(金) 19:02:53

>>948
ユニコード(UCS-4)に変換して数値文字参照にするなら、サロゲートペアなんて
出て来ないから普通に組んで問題ないと思うよ。
数値文字参照からUCS-4にしたときに0xd800～0xdfffが出てきたらおかしいから
弾かないと駄目。

0953デフォルトの名無しさん

2007/05/02(水) 01:40:33

ISO/IEC2022の表記方法で0/0とか7/15とかいう記述があるのですが、
どういう意味なのでしょうか？
どなたか教えて

0954デフォルトの名無しさん

2007/05/02(水) 02:15:57

書いた人の定義による、出典だせ

0955デフォルトの名無しさん

2007/05/02(水) 04:15:00

出典というほどのものではないですが
ここのサイトで見ました。
ttp://www.wdic.org/w/WDIC/ISO/IEC%202022

どうやら0/0は0x00, 7/15は0x7Fのように自分には見えました。
でも敢えて0/0のように記述しているのはそれなりの理由があるのでしょうね。

0956デフォルトの名無しさん

2007/05/02(水) 04:34:03

規格票がそういう流儀だから。

0957デフォルトの名無しさん

2007/05/02(水) 04:51:08

ありがと。

0958デフォルトの名無しさん

2007/05/02(水) 05:28:58

>>606のサイトで規格票を読める。

0959デフォルトの名無しさん

2007/05/02(水) 14:58:20

>>951
少し試してみました。TextEdit.appのRTFってCID埋め込めるんですね。

で、異体字を Excel とかでも使いたいんですが、
タイプセットと関係ない一般のアプリでCIDを使う訳にはいかないんでしょうねえ。

0960デフォルトの名無しさん

2007/05/03(木) 15:00:35

日本では公的な標準があまりに非力だから仕方なく一部で使われてるけど
CIDってそもそもそういうこと(一般的な情報交換)に使うためのものじゃないからねえ
まさにそのためにIVSが定義されようとしているわけだし

0961デフォルトの名無しさん

2007/05/03(木) 15:15:13

>>944
;の省略はブラウザのお節介ではなく仕様で認められてる場合がある。

0962デフォルトの名無しさん

2007/05/03(木) 15:18:54

>>937
昔は原規格の並びをそれなりに反映してるっぽい並びで収録されることがあったからだと
思われ(Big5のbopomofoは0xA375～)。
BMPに余裕がなくなってきた最近ではとにかく空いてるところに詰め込む感じになってるけど

0963デフォルトの名無しさん

2007/05/03(木) 15:26:42

> Big5のbopomofoは0xA375～
すまん嘘だった。0xA374～じゃんorz

0964デフォルトの名無しさん

2007/05/11(金) 23:44:52

Extension Cに投票でツッコミが入りまくってAmd.5に回された。
まあレビューが正常に機能してる証拠だとも言えそうだが。
Adobe-Japan1がAmd.3に入りそうなのはいいけど早すぎて品質が心配

0965デフォルトの名無しさん

2007/05/16(水) 09:38:38

Wikipedia に

UCS-4
　31ビットを使うコード。4バイトを基本とするUCS。Unicodeの符号化方式であるUTF-32と似ている。
　Unicode以外のコード（0x10FFFF以降）も使用できるという点が異なっていたが、
　2006年の改訂によりUnicodeで使用できない領域には永久に文字が定義されないこととなった。
　~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
って書いてあるんですけど、
ISO/IEC 10646 自体が 22～31 ビット目を使わなくなった、ということではなくて、
ISO/IEC 10646 のサブセットである UCS-4 は 22～31 ビット目を使わないけど、
ISO/IEC 10646 自体はまだ 22～31 ビット目を持つ文字も使えるようになってる、
ということなのでしょうか？

0966デフォルトの名無しさん

2007/05/16(水) 10:46:40

ISO10646=Unicodeなので22～31ビット目は使われない。

0967デフォルトの名無しさん

2007/05/16(水) 11:56:19

ISO/IEC 10646 ⊃ Unicode ではなくて？

0968デフォルトの名無しさん

2007/05/16(水) 12:30:44

>>967
その認識は古い。

0969デフォルトの名無しさん

2007/05/16(水) 12:43:08

うーん。
http://www.unicode.org/faq/unicode_iso.html
にある
＞文字コードと符号化方式は同期を取っていますが、Unicodeは実装上の適合性を重視しています。
＞このため、ISO/IEC 10646で規定していない、拡張した機能文字、文字データ、アルゴリスム、背景資料などを提供しています。
というのが微妙に分からないんですけど、
要するに ISO/IEC 10646 は文字コードや符号化方式のみを規定していて、
Unicode はそれを実際に実装する際の話も規定しているという話であってますか？

0970デフォルトの名無しさん

2007/05/16(水) 13:21:27

UCS は Unicode にはないよね？

0971デフォルトの名無しさん

2007/05/16(水) 13:24:24

Unicode は UCS にはないよね？

0972デフォルトの名無しさん

2007/05/16(水) 13:30:51

あいや、UCS-2 や UCS-4 という用語は Unicode にはないよね、と。

0973デフォルトの名無しさん

2007/05/16(水) 13:56:42

ナイアルヨ

0974デフォルトの名無しさん

2007/05/16(水) 14:33:10

結局 UCS の群(group)って意味なかったのかね。

0975デフォルトの名無しさん

2007/05/16(水) 15:16:48

UCS-3が開発されたりしてｗ

0976デフォルトの名無しさん

2007/05/16(水) 15:39:10

The most significant octet of this sequence shall be the group-octet.

とまで書かれていたのに・・・。

0977デフォルトの名無しさん

2007/05/17(木) 02:50:46

>>976
それは「BEだぞおめーら」って意味じゃ?

0978デフォルトの名無しさん

2007/05/17(木) 04:03:12

そういう場合に significant って使うの？

0979デフォルトの名無しさん

2007/05/17(木) 10:35:51

「最上位ビット」という意味の "MSB" の S は Significant だよ。

0980デフォルトの名無しさん

2007/05/17(木) 10:55:02

なるほど。そうなんだ。

0981デフォルトの名無しさん

2007/05/17(木) 21:22:01

>>969
> 文字コードと符号化方式は同期を取っていますが、

文字コードも符号化方式も
UnicodeとISO/IEC 10646の間で同期していますが、

> Unicodeは実装上の適合性を重視しています。

Unicode標準は、プラットフォームやアプリケーションが違っても、
統一的に文字を扱う事を確実にする実装上の制約も課しています。

「要するに～？」についてはYES。
実装を規程している訳じゃなくて、
(実装するなら当然必要になるような)その他のことも規定してる。
「実装」に特にこだわってその文を解釈する必要はない。

0982デフォルトの名無しさん

2007/05/18(金) 06:13:56

なるほど。よくわかりました。

レス数が950を超えています。1000を超えると書き込みができなくなります。