03/09/10 18:55
定番のレスですまないが、まず「機種依存文字」という用語の、皆が納得できる定義から頼む。
17:デフォルトの名無しさん
03/09/10 18:56
じゃあたとえば、機種依存文字の場合
テーブル自作するとしよう
上の例だと
EUC_JPのファイルをバイト単位で読み込んだとき
AD A1っていうのがあれば、 UTF-8に変換する場合 E2 91 A0に書き換えればいいって事になる
こういう辞書を作ればいいのか？
こんな具合に
EUC_JP、ISO-2022-JP、MS932、Shift_JIS、UTF-8の辞書テーブル作れば解決だよな
18:デフォルトの名無しさん
03/09/10 18:59
>>16
たとえばi-mode文字とか
19:デフォルトの名無しさん
03/09/10 19:00
UNICODEへのマッピングが未定義の文字をUNICODEにマッピングしようという話か？
20:デフォルトの名無しさん
03/09/10 19:02
>>18
つまり標準規格化されてないベンダ独自定義の文字？
それだと「①」とかは当てはまらないし、他のコードに変換もできそうにないけど。
21:デフォルトの名無しさん
03/09/10 19:18
まあ詳しい話は俺は知らないんだが
たとえばJavaなんかでも簡単に文字コード指定してやれば
どんな文字コードのファイルも任意の文字コードのファイルとして変換できる。
ただ、普通に使う文字とかは漢字（一部例外）だろうと記号だろうと大体OKなんだけど
マッピングが割り当てられてない文字は？ってなるだろ。
そういうのを、正しく修正するようなテーブルをつくればいいのではないかと思ってな。
明らかにそのコードに存在しない文字はしょうがないけど
22:デフォルトの名無しさん
03/09/10 19:27
>21
ヴァカですか？
23:デフォルトの名無しさん
03/09/10 19:46
つーか、JIS系(ISO-20022-JP, Shift_JIS, EUC-JP, ...)とUnicode系（UTF-8, UCS-2, ...)
の変換は機種依存文字でなくても変換表使うしかないわけだが。
24:
03/09/10 19:57
>>13
UCS16 はかなり使われてるのにね。
25:●のテストカキコ中
03/09/10 19:59
URLﾘﾝｸ(ula2ch.muvc.net) (このカキコは削除しても良いです)
26:デフォルトの名無しさん
03/09/10 20:03
>>23
その変換表をプログラムから使えるようにしようって事でないの？
27:デフォルトの名無しさん
03/09/10 20:18
>>16
機種依存文字とは
『日本において技術者が喜んで実装し、
営業がユーザを囲い込むために喜んで利用する
ちょっとだけ見た目のいい文字集合セットの名称』
28:デフォルトの名無しさん
03/09/10 20:22
URLﾘﾝｸ(apex.wind.co.jp)
たとえば、Macintosh文字の機種依存文字として
丸付き数字や「cm」「↑↓」などがある。(「」内が一文字)
29:デフォルトの名無しさん
03/09/10 20:31
>>28 【機種依存文字】特定機種にのみ存在する文字のこと
この定義じゃ不充分だし。英語版のOSじゃ日本語全滅ですよ？
30:デフォルトの名無しさん
03/09/10 20:38
「機種依存文字」なんて存在しないことがわからないのはなんでだろう。
31:デフォルトの名無しさん
03/09/10 20:40
>>30
別にそんな細かいこといいじゃん ネタすれなのにマジになるなよ
32:デフォルトの名無しさん
03/09/10 22:12
来いよ
33:デフォルトの名無しさん
03/09/10 23:16
Unicode はクソ。
34:デフォルトの名無しさん
03/09/10 23:21
クソじゃない文字コードって何よ？
35:デフォルトの名無しさん
03/09/11 00:13
7bit ascii
36:デフォルトの名無しさん
03/09/11 10:35
Unicodeの功績:
文字コードを1つ増やしてプログラマの雇用を創出したこと
Unicodeの罪:
文字コードを1つ増やして右翼・左翼の声を大きくしたこと
37:デフォルトの名無しさん
03/09/11 12:34
7bit ascii はクソ、アラビア文字が表現できない。
38:デフォルトの名無しさん
03/09/11 14:30
UTF-16のメリットをひとつ述べよ
39:デフォルトの名無しさん
03/09/11 15:23
>>38
固定長
……あ、でもサロゲートペアが…………
40:デフォルトの名無しさん
03/09/11 15:39
>>38
中途半端で実用的
41:デフォルトの名無しさん
03/09/11 17:41
サロゲートを使わないと表現できない文字を使ってるのは人間じゃないから
サロゲートの事なんか考えなくてもいいんだって学校の先生がいってたよ
42:デフォルトの名無しさん
03/09/11 23:02
>>39
固定長なのはUCS2。
43:デフォルトの名無しさん
03/09/11 23:28
>>37
ま、7 bit ascii が今の文字コード問題の元凶だという意味では激しくクソだな。
- はハイフンなのかマイナスなのか
(いまは「ハイフンマイナス」だっつーことになった。何だよそれは)
~ はチルダなのかオーバーラインなのか
(規格に tilde or overline とか書くなよ…)
" の左右くらい区別しろ
...
44:デフォルトの名無しさん
03/09/12 00:14
>>43
昔はそんなもの厳密に区別しなくても困らなかったんだよ。
それよりリソースの制限のほうが深刻だった。
で、それらを「包摂分離」したことによって非互換が発生した
45:デフォルトの名無しさん
03/09/12 00:17
タイプライタなんて l と 1、 O と O を包摂していた。
46:デフォルトの名無しさん
03/09/12 00:24
>>41
クリンゴン人ですね
47:デフォルトの名無しさん
03/09/12 22:47
>>46
残念ながらクリンゴン語は却下されてUnicodeに含まれてないはずだよ
48:デフォルトの名無しさん
03/09/12 23:23
>47
>46のメール欄
49:47
03/09/12 23:57
ぐは。やられた。
50:デフォルトの名無しさん
03/09/13 14:04
ﾌﾟｯ
51:デフォルトの名無しさん
03/09/13 17:04
初心者ですがよろしいでしょうか？
Java上でSJIS→UNICODE→SJISと変換をかけると、
115区～119区は「?」になってしまうようなんですが、
仕方がないんでしょうか？
実際にUNICODEで割り当てられている文字もあります。
例えば人名の「高」のはしごタイプのやつです。これは
118区にあり、SJISではFBFC、Unicodeでは9AD9です。
IBM特殊文字なのはわかりますが、コードが存在するのに
エンコードしてくれないのは何故でしょうか？
52:デフォルトの名無しさん
03/09/13 17:15
>>51
Windows-31J エンコーディングを使用したか?
53:デフォルトの名無しさん
03/09/13 17:35
>>52
使ってるのはShift_JISです。
Windows-31JってMS932のことでしたっけ？ 試してみます。
54:デフォルトの名無しさん
03/09/13 17:55
必読ページ
URLﾘﾝｸ(www.ingrid.org)
55:デフォルトの名無しさん
03/09/13 19:16
>>53
Windows-31Jでやってみました。が、ダメでした。
しかしおかげさまで問題を切り分けることができました。
どうやら途中に使っているJDBCドライバの問題っぽいです。
そっち方面検証してみます。お騒がせしました。
56:デフォルトの名無しさん
03/09/13 20:27
データベースがEUCだったりするとたいがいうまくいかないね。
SJIS => UNICODE -> EUC -> UNICODE => SJIS
途中で、変換できないコードが混じっちゃう。
最近は、データベースの文字コードはできるだけUNICODEにしている。
それができないときは、SJIS。
JavaのWebアプリの場合だけど。
57:デフォルトの名無しさん
03/09/14 01:00
データーベースがUnicodeじゃないとIEのsize属性での長さチェックと
うまくかみ合わなかったり
どのみちサーバ側でチェックをする必要はあるんだけどなんか嫌
58:デフォルトの名無しさん
03/11/03 22:37
ICU使ってます？
59:デフォルトの名無しさん
03/11/03 22:42
使ってます
60:デフォルトの名無しさん
03/11/03 22:59
日本語でUnicodeならUTF-8よりUCS-2そのままのほうがかえって
メモリ消費少なくなったしせえへん？CJK共用漢字コード領域に
UTF-8の3バイト文字あったっけ？
61:デフォルトの名無しさん
03/11/03 23:50
>>60
たしかにUTF-8だと漢字や記号の一部、半角カナ類は全部3バイトだね。
でも、日本語だけならいいんだけど、ASCII文字も扱いたい場合は
UCS-2の16ビット表現はASCII部分の文字も2バイトになっちゃうからねぇ。
62:デフォルトの名無しさん
03/11/04 01:31
>>13
XMLの標準がUTF-8でさらに、
欧米人は本当はIS-8859-1しか使う気がなく
Unicode使ってもせいぜいUTF-8しか使わんのでしょう。
欧米系以外の外国人も英語を標準言語としており、
プログラミングなどの才には変数名などは英字のほうがわかりやすく
扱いやすくASCIIコードで事足りる記号が多いので、
無理してUTF-16を使う気を起こす人が少ないのでしょう。
まさに自分もこれに当てはまります。
63:デフォルトの名無しさん
03/11/04 02:46
>>62
> 欧米人は本当はIS-8859-1しか使う気がなく
そんだったら、WinもMacもUnicodeサポートしてないんじゃないの？
逆に、超漢字は、BMPしかサポートしてないというお粗末感がある。
ちなみに、Unicode Consortiumは、アメリカにあるよ。
ISO-8859-1はヨーロッパじゃあもう使いたくないでしょう。
Euroが入ってないと。
64:デフォルトの名無しさん
03/11/04 05:17
最近じゃ代わりに ISO-8859-15 を使うとかどうとか。＜euro
プログラム言語では内部コードが UTF-16 てのも珍しくないけど。
65:デフォルトの名無しさん
03/11/22 19:59
ICUのDLLがでかすぎるのだがUnicodeと日本語関係の文字コードに限定したサブセット版って誰かビルドして配布してくれてたりしないのかなあ
66:デフォルトの名無しさん
03/11/22 20:07
>>65
集中治療室？
67:デフォルトの名無しさん
03/11/22 20:34
>>63
非英語圏は英語圏産のソフトウェアの輸出先だからね。
日本が輸入最大手。
68:デフォルトの名無しさん
03/11/22 22:14
UTF-8って内部処理には最悪なんだって。
文字列の末尾から先頭に向かって文字を検索できないだろ。
UNIX系のgccでは標準ライブラリは一文字四バイト固定のwchar_tだし、
MSVCは二バイト固定のwchar_tなんだよね。
69:デフォルトの名無しさん
03/11/22 22:40
可変長なものが内部処理には向かないのはあたりまえ。
70:デフォルトの名無しさん
03/11/22 22:46
>>68
wchar_tはワイド文字なんだからutf-8でないのは当然なので、
wchar_tがutf-8でないことはutf-8を否定する理由にならない。
あと、末尾から先頭に向かって検索しづらい(できないわけじゃない)のは
utf-8に限った話ではない上、あるシステムが文字列を末尾から検索する
必要があるとも限らないし、それ以外のメリットとデメリットも色々ある。
もっと勉強して出直してきて。
71:デフォルトの名無しさん
03/11/23 23:19
コード順でソートすると一部言語が混ざるのが不味い
72:デフォルトの名無しさん
03/11/24 17:41
>>68
> 文字列の末尾から先頭に向かって文字を検索できないだろ。
ﾊｧ? そりゃシフトJISやEUCの話だ。
どこのバカにそんなデタラメ吹き込まれた?
>>70
UTF-8は単なるバイト列として末尾からでも検索できるはずだが。
73:デフォルトの名無しさん
03/11/24 17:56
>>72
>>70はできないとは書いてないけど？
可変長だから末尾から「文字として」検索するのはちょっとややこしめ、という程度の意味で書いた。
74:デフォルトの名無しさん
03/11/24 19:32
>>73
UTF-8のエンコード方式を理解してないだろ？
75:デフォルトの名無しさん
03/11/24 21:25
> 「文字として」検索する
必要がないのがUTF-8の特長なんだが。
どーでもいーけどこの程度の初歩的な知識もないくせに
知ったかぶってUnicode叩く奴大杉
76:デフォルトの名無しさん
03/11/24 21:30
まあUnicodeはクソだし。
77:デフォルトの名無しさん
03/11/24 21:52
で、そういう奴に限って何がどう糞なのか説明しない。
たまに説明したかと思ったら>>68みたいな単なる嘘だったりするし。
78:デフォルトの名無しさん
03/11/24 21:58
16ビットにおさめようと思って作っていた時点で糞です。
糞に何をかぶせようと糞にかわりはありません。
79:デフォルトの名無しさん
03/11/24 22:17
それじゃあたった8,836文字に収めようとしたJIS X 0208や
シフトJISの都合だけで11,280文字に詰め込もうとしたJIS X 0213なんて
話になりませんね。やはり時代はちょー漢字ですか?
80:デフォルトの名無しさん
03/11/24 22:17
Unicodeも糞だがJISも糞だ。
それを弁えて何とかするのがエンジニアだろ?
糞だ何だと言い訳する暇あったら調べるなり
なんなり、もっと悪足掻きしろよ。
81:デフォルトの名無しさん
03/11/24 22:18
で、悪あがきした結果がちょー感じ？
82:デフォルトの名無しさん
03/11/24 22:41
むしろ悪あがきした結果はExtension BやOpenTypeの字形切り換えや
language tagやvariation selectorではないかい
漏れが理解できないのは、いくらUnicodeが糞でもシフトJISよりは
マシだと思ってるんだが(理由は>>72や>>79)なんでシフトJISから
移行するだけでもあんなに拒否反応示す奴が多いの? ってあたり。
そいつが超漢字に移行しようっていうならまだ話も分かるんだが。
83:デフォルトの名無しさん
03/11/28 22:27
今まで使っていた物が使えないから。
84:デフォルトの名無しさん
03/12/01 00:30
捨てませう。
85:デフォルトの名無しさん
03/12/04 23:27
大昔のことで忘れたが、UTF-8って、
ビットテストすれば何バイト目が分かる仕様じゃなかったっけ？
86:デフォルトの名無しさん
03/12/05 11:18
・１オクテット文字か
・マルチオクテット文字の先頭オクテットか
・マルチオクテット文字の後続オクテットか
が分かる。
マルチオクテット文字の何オクテット目かは、先頭かどうか以外は分からない。
87:デフォルトの名無しさん
03/12/05 13:31
先頭オクテットに関しては
・何オクテット文字の先頭か
もわかるはず。
00-7F 1オクテット文字
80-BF 後続オクテット
C2-DF 2オクテット文字の先頭
E0-EF 3オクテット文字の先頭
F0-F7 4オクテット文字の先頭
※C0-C1とF5-FDはRFC3629で使用禁止になった
88:デフォルトの名無しさん
03/12/05 16:00
さんきぅ
単位はオクテットの方がよかったね(これまた大昔に指摘されたことだな)
ま、どっちにしてもシリアライズ向きか
Perlのutf8って、どのくらい使えるんだろう
89:デフォルトの名無しさん
03/12/05 18:31
>>88
URLﾘﾝｸ(hyam.dip.jp)
> foreach $name ( < * > )
> でファイル名やディレクトリ名の "機能"を拾えない。
が5.8.1でも直ってないのでまだJPerlの置き換えはできまへん
90:デフォルトの名無しさん
03/12/13 02:43
UNICODE 良く判らん・・・。UCS がキャラクタセットで、UTF がエンコーディング
なんだよね? UCS もキャラクタコードを持ってるという点ではエンコーディングと
考えてもいいの? 実際、Java や CLISP は内部的には UCS-2 で文字列を保持している
みたいだし。サロゲートペアとか考えなくてよくなるから、内部エンコーディングに
向いているのでしょうか?
UTF-8 が多いのは ASCII が使えれば十分な人が多いから?
各言語／ライブラリの内部エンコーディング／string のエンコーディング
Python: UTF-8?
Java: UCS-2/UTF-8
Tcl: UTF-8
Cocoa(Mac OS X): UTF-16
CLISP: UCS-2
Gauche: compile option dependent
Qt: UTF-8
Mule: has it's own encoding
XML: UTF-8 or UTF-16
自分で多言語対応文字列処理ライブラリを作る時は、UCS-2 を使うのが良いのでしょうか?
91:デフォルトの名無しさん
03/12/13 02:50
とりあえずPythonはUCS-2だとだけ言っておく。
92:デフォルトの名無しさん
03/12/13 02:52
thanx!
やっぱり固定長が便利って事だよね。
93:デフォルトの名無しさん
03/12/13 02:54
std::basic_string<wchar_t>
linux-gcc:glibc(UCS4)/mingw32-gcc:msvcrt(UCS2)
ワイドキャラクタは、テンプレートを使えば
ロジックはそのままで型の導出の定義を替えて再コンパイルのみ。
インターフェースが変わるだけで上流工程に影響しない。
マルチバイトはロジックにパッチを当てなきゃならんので
論理のチェックもやり直し。
94:デフォルトの名無しさん
03/12/13 03:38
URLﾘﾝｸ(homepage1.nifty.com)
95:デフォルトの名無しさん
03/12/13 06:14
>UTF-8 が多いのは ASCII が使えれば十分な人が多いから?
USC2は情報量が足りないからサロゲートせなあかん、面倒
UCS4は無駄が多い
なによりUCSはstrcmpレベルから書き直さんとあかんよ
96:デフォルトの名無しさん
03/12/13 06:21
JIS X 0213はUCSだと固定長ではすまないわけだが
(サロゲートを無視しても合成もある)
97:デフォルトの名無しさん
03/12/13 11:07
>なによりUCSはstrcmpレベルから書き直さんとあかんよ
そんな必要ない。
// char *m = itoa<char, int>(100)
// char *w = itoa<wchar_t, long>(1234L)
template <typename C, typename I>
std::basic_string<C> itoa(I v, int radix = 10, bool caps = false) {
std::basic_string<C> buff;
C ch;
C af = (caps ? 'A' : 'a');
do {
ch = C(v % I(radix));
ch = ((ch > 9) ? (ch - C(10) + af) : (ch + C('0')));
buff += ch;
v /= I(radix);
} while (v);
std::reverse(buff.begin(), buff.end());
return buff;
}
98:デフォルトの名無しさん
03/12/13 11:20
>97
型が混じってるぞ。
I r = v % I(radix);
C ch = (r >= I(10))? (af + (r - I(10)) : (C('0') + r);
ってところか。
99:デフォルトの名無しさん
03/12/13 11:31
>>97
その調子で今まで作られた文字列処理関数すべてを書き換えてみて。
100:デフォルトの名無しさん
03/12/13 11:42
>>99
つーか、作るまでも無く実はSTL+BOOSTなら大抵あるだろ。
boost::format(L"%5.3f:%3d") % 12.3 % 123
漏れも公開するかな。UCSはラクチンだよ。
101:デフォルトの名無しさん
03/12/13 13:35
ところで内部コードがUTF-8って何かまずいことあるん？
UCS-2でも(OSによっては)出力する時点で変換しないとならないし
大して利便性は変わらないと思うんだが。
表現方法がいくつもあるほうが逆にやりづらいというかサポートするのが面倒。
102:デフォルトの名無しさん
03/12/13 15:52
>>101
内部はUCSでいいじゃん。すでにJavaもVBもそうなってて不都合無いだろ。
C++も標準で困らないようになってる。
わざわざ検索処理とかCのランタイム書き直すの？
103:デフォルトの名無しさん
03/12/13 16:10
>>102
UTF-16だろ
104:デフォルトの名無しさん
03/12/13 19:39
jis x 0212 って「捨て」なんですか?
105:デフォルトの名無しさん
03/12/13 21:37
>>96
結局、固定長で多言語を扱うというのは現実的には難しいのか。。。
106:デフォルトの名無しさん
03/12/13 23:55
>104
Unicodeの中に生き残ってるでしょ。
107:デフォルトの名無しさん
03/12/14 00:11
超超超 超漢字！
超超超超 超漢字！
108:デフォルトの名無しさん
03/12/14 01:17
.NET Framework的には、文字列stringはUTF-16だから、
次世代Longhornもこれに統一されるんじゃないの？
てことは、数年後にはUTF-16が事実上の標準になると。
109:デフォルトの名無しさん
03/12/14 02:29
文字コート関連のスレが他に無いので、ここで質問しても宜しいでしょうか?
URLﾘﾝｸ(euc.jp)
上記 URL で、EUC-JP を ISO-2022 に割り当てる説明が書いてありますが、
G0 - G3 に各符合化文字集合を指示している部分は実際に何か行われている
のでしょうか。
EUC-JP はエスケープシーケンスを使わないという事ですので、エスケープ
シーケンスを使用した指示はしていないと思うのですが。
110:デフォルトの名無しさん
03/12/14 03:47
>>109
> 上記 URL で、EUC-JP を ISO-2022 に割り当てる説明が書いてありますが、
EUC は ISO 2022 に準拠してるとしか書いてないような…
> G0 - G3 に各符合化文字集合を指示している部分は実際に何か行われている
> のでしょうか。
定数なので普通は何もしない。
既存の ISO-2022-JP の処理系があるなら ** を指示ってのにしたがって
G0 ～ G3,GL,GR を設定すれば EUC の処理系が作れるってだけ。
(SS2 と SS3 の処理は追加しなきゃいかんかったっけ？)
111:デフォルトの名無しさん
03/12/14 08:52
>>109
EUC-JPは designate を省略しているが、invokeは省略しない。
ISO2022 designate invoke でググって見たら。
112:111
03/12/14 09:02
つうか、 URLﾘﾝｸ(euc.jp) にちゃんと書いてあるじゃん。
指示(designate)は省略する。(あらかじめ指示してあると約束する)
EUC-JPを使うと言う取り決めは、G0,G1,G2,G3に
それぞれJIS X0201ローマ字,JIS X0208, JIS X0201カタカナ, JIS X0212を指示するという
取り決めとなるわけ。
(ただし、GOがASCIIなのかJIS X0201ローマ字なのかにはゆれがある。)
当然、呼び出し(invoke)は行う。
113:デフォルトの名無しさん
03/12/14 15:37
G0にJIS X 0201ローマ字を指示するEUCってあったっけ?
(実装の解釈が変というのは除いて)
JIS X 0208本体のラテン文字・漢字用8ビット符号がいちおう該当するか。
これはG2もG3も使わないけど
114:デフォルトの名無しさん
03/12/14 16:30
>>113
URLﾘﾝｸ(www.opengroup.or.jp)
115:デフォルトの名無しさん
03/12/14 16:40
>>114
見事なまでにバラバラだな
116:デフォルトの名無しさん
03/12/14 17:19
>>110-112
レスどうもありがとうございます。
4.7 の所に省略すると書いてあるのに気付きませんでした。済みません。
エディタを作りたかったのですが、やっと ISO 2022 が理解出来ました。
どうもありがとうございました。
117:デフォルトの名無しさん
03/12/14 21:07
初歩的な質問ですが
EUC を SJIS に変換まではできたのですが、
この変換できた EUC のデータを
printf() 関数を使ってコンソールに出力したいので
CString szEUC;
szEUC = ....
printf( "%d\n", szEUC );
とやってみましたが うまくいきません。
EUCコードを 文字化けせずにコンソールに出力するには
何か設定が必要なのでしょうか？
118:デフォルトの名無しさん
03/12/14 21:21
エスパー募集ですか？
119:デフォルトの名無しさん
03/12/14 22:07
CString って MFCだよねぇ。
_MBCSと_UNICODEのどっちが定義されているかで入っているもの違うけど。
どっちにせよ、 CStringをそのままprintfで出力するのは反則だし。
_tprintf("%s\n", LPCTSTR(szEUC));
MFCスレで聞けば？
120:117
03/12/15 00:32
printf( "%d\n" szBuf ); → %s
また やってしもうたか・・・＿|￣|○
設定って、#define とかのことでした すんまそん
121:デフォルトの名無しさん
03/12/15 02:10
SJISしか受け付けないコンソールにEUC出力すれば、
そりゃ文字化けするわなぁ。
122:デフォルトの名無しさん
03/12/15 11:40
EUC-TWってSS2の後にA2～B0を付けてPlaneを識別している
みたいですけどこういうのってISO 2022的にアリなんですか?
123:122
03/12/15 11:58
94^3集合と考えればいちおうアリですね。
問題はISO-IRには別々の94^2集合しか登録されていないことですが。
124:デフォルトの名無しさん
03/12/15 12:58
内部コード UTF-8 は XML がらみのライブラリを使うときとかに多用するけど、
逆に OS 側やら他のライブラリは UTF-8 なんてこと殆どないんで、
かなりの場面でコード変換が必要になるなぁ。。
125:デフォルトの名無しさん
03/12/15 15:40
UCS-2って文字集合のことですよね。
UTF-16はUCS-2の符号化方式の一種ですよね。
ところで、GNUのlibiconvっていうライブラリに符号化方式としてUSC-2が使えるんだけど、
これって何か特別な使い方があるのかな。ダンプしてみたらUTF-16BEと全く同じなんですよね。
126:デフォルトの名無しさん
03/12/15 16:09
> UTF-16はUCS-2の符号化方式の一種ですよね。
違うと思う(前者は後者にない補助面の文字が存在してるから)
127:デフォルトの名無しさん
03/12/15 20:04
UCS-2の文字番号をそのまま使う符号化方式もUCS-2と呼んでるんだろう、きっと。
BMP外の文字を使わなきゃUTF-16BEと同じになるのは道理。
UTF-16類とは、サロゲートとBOM位しか違わないんでない？
128:デフォルトの名無しさん
03/12/15 22:57
UCS2は基本的に内部表現用なのでBE/LEどちらでもUCS2。
完全に実行環境に依存してる。
129:デフォルトの名無しさん
03/12/16 00:57
iconv使うと実行ファイル+数メガの.so/.dllをくっつけないといかんので困る。
130:デフォルトの名無しさん
03/12/16 10:06
SJIS←→UCSの変換なんてOSの変換表は
まるで信用できないからなあ
131:125
03/12/16 13:33
Thanks > 126-128
符号化方式としてのUCS-2ってのは使わない方がいいみたいですね。
さらに、UTF-16に関して質問なんですけど、私の認識では、UTF-16系の扱いは以下のようになってます。
・UTF-16 ＝ BOMを見てlittle endianかbig endianか判断せよ。
・UTF-16BE ＝ big endianに決まっている。
・UTF-16LE ＝ little endianに決まっている。
つまり、UTF-16はBOMがあるもので、BOMがない場合はUTF-16BEかUTF-16LEと明示的に
指定すべきものだと思っています。でもたまに「BOMなしUTF-16」とか「BOM付きUTF-16BE」
のような記述をWebサイトやアプリケーションに見受けます。
私の認識は間違ってます？
132:デフォルトの名無しさん
03/12/16 15:59
十数年前はチーズバーガーが１個２３０円だった。
それが、ついこの間まで１個８８円で売っていた。
これはつまり、その気になれば１個８８円で売れたモノを２３０円で売ってた訳だ。
その昔に１個２３０円で食ってたオレに言わせれば全く腹の立つ話だ。
133:デフォルトの名無しさん
03/12/16 16:53
じゃあたった10MBかそこらのメモリが億単位の値段だったなんて
もう詐欺みたいなものですね
とかコピペにマジレスしてみるテスト
134:デフォルトの名無しさん
03/12/19 19:24
>>131
好むと好まざるとに関らず、UTF-8 以外は使われなくなってくから
グズグズとそんなこと考えんで宜しい。
１０年後に UTF-16 なんて使ったら洟で笑われるぞ。
135:デフォルトの名無しさん
03/12/19 19:35
10年後には UTF-8 すらなくなっていますが。
136:デフォルトの名無しさん
03/12/19 20:13
Asciiコードは無くなるかなあ？
137:デフォルトの名無しさん
03/12/19 20:23
>>136
欧州市場はやっぱり無視できないから、新規の実装では使われなくなると思う。
138:デフォルトの名無しさん
03/12/19 21:05
UTF-8という名のASCII
139:デフォルトの名無しさん
03/12/20 00:09
UTF-8 って合成を考えると、一文字が最大 12 オクテットになるの??
140:デフォルトの名無しさん
03/12/20 05:14
>>139 21
141:デフォルトの名無しさん
03/12/20 21:50
どういう計算をして12オクテットになったのか謎ですが
3文字以上の合成だってあります。
142:デフォルトの名無しさん
03/12/22 17:19
合成で気になったんだが、合成の組み合わせと数に制限はあるのか？
例えば、U+306C U+0308 とか、U+0276 U+0328 U+0336 U+030F U+0360 とかは
Unicode文字として規格上正しいもんなのか……？
# 直感的には、明らかに正しくないことはわかってるのだが。
143:デフォルトの名無しさん
03/12/22 20:18
>>142
JIS X 0221の規格票をざっと眺めた感じでは、制限無しの模様。
144:デフォルトの名無しさん
03/12/22 22:38
>>142
残念ながらダイアクリティカルマークの
スタック(積み重ね)という概念は実在する
URLﾘﾝｸ(dl2.yukoncollege.yk.ca)
145:デフォルトの名無しさん
03/12/24 13:26
>>144
そこのページ雪だるまがいぱーいあって季節的にGood!
146:デフォルトの名無しさん
03/12/25 01:44
>好むと好まざるとに関らず、UTF-8 以外は使われなくなってくから
ISO C++ではワイドキャラクタはサポートされてますが、
マルチバイトがしっかり動く環境ではありません。
UCS-4マンセー。UCS-4でいいじゃん。
147:デフォルトの名無しさん
03/12/25 01:58
だったらこの文字ユニファイして領域節約してくれよ
U・C・S!! U・C・S!!
148:デフォルトの名無しさん
03/12/25 18:01
>>146
とりあえず、意味不明
149:デフォルトの名無しさん
03/12/25 18:55
正直utf-16でいい
150:デフォルトの名無しさん
03/12/25 20:03
正直utf-16のよさがわからない
151:デフォルトの名無しさん
03/12/25 22:56
WinXP用ならUTF-16もいいが
他の環境を考えると
152:デフォルトの名無しさん
03/12/26 00:58
UCS4だよ。一文字32ビット固定でいいやんけ。
153:デフォルトの名無しさん
03/12/26 12:55
合成があるってば
154:デフォルトの名無しさん
03/12/26 14:13
漢字圏の人間はついついUCS-4で全部解決と
思ってしまうんだよなあ。
155:デフォルトの名無しさん
03/12/26 15:06
その典型が昔のTRONですね
URLﾘﾝｸ(www.horagai.com)
最近のバージョンでは解決してるの?
156:デフォルトの名無しさん
04/01/06 02:05
うーん、実態はそんなに単純じゃないんだけどなあ。
TRONの関係者の中にも多言語処理の複雑さを理解している
人たちはちゃんといたよ。昔のweblogをみると多言語の問題と
取り組んで悪戦苦闘している様子がうかがえた。
合成の問題のことは頻繁に話題になっていたよ。
一応TRONでは80年代ごろから多言語処理には
4層構造(言語層、文字属、スクリプト、フォント)で対応する
ということになっていたんだけど、悲しいかな人手不足で
全然研究、ましてや実装は進まなかったんだよ。
今超漢字の販売元は組み込み向けの製品に注力していて、
超漢字にはあまり時間をかけていない様子。改善されているのも
相変わらず漢字処理が中心だよ。明るいニュースはごく最近
SUNがJavaのTRONコードへの対応を約束したことぐらいかな。
まだまだ先の道のりはながいよ。
157:デフォルトの名無しさん
04/01/06 20:27
> TRONの関係者の中にも多言語処理の複雑さを理解している
> 人たちはちゃんといたよ。
こんなのとか?
URLﾘﾝｸ(www.sumire.sakura.ne.jp)
漢字がどうしても中心になるのは分からなくもないけどね
使いもしない文字のサポートが強化されたって一般受けしないばかりか
「シリア語ブラクラ」なんて汚名まで被る始末だし
158:デフォルトの名無しさん
04/01/08 04:12
思ったんだけど、
わざわざ全ての文字を１つの文字コードに詰め込まなくても、
JIS コードみたいに文字コードの切り替えを行うマークを導入すれば
かなりすっきりするんじゃない？
159:デフォルトの名無しさん
04/01/08 04:22
その切り替えタグに当たるコードは
どうすれば必要十分で、どういうルールで割り当てていく？
160:デフォルトの名無しさん
04/01/08 04:30
仮に一文字２バイトで固定するなら、
文字として使える領域と
切り替えタグにしか使えない領域に分割すれば
いいんじゃない？
161:あぼーん
あぼーん
あぼーん
162:デフォルトの名無しさん
04/01/08 04:44
>>158
エスケープ・シーケンス unix で検索しる。
163:デフォルトの名無しさん
04/01/08 05:02
>>162
Compound Text ってやつ？
なるほど、既にその手のものはあるんですな。
これで問題になることって何があるのかな？
164:デフォルトの名無しさん
04/01/08 11:50
>>163
まともな処理をするのがめんどうくさい。
165:デフォルトの名無しさん
04/01/08 11:58
そもそも、プログラミングを容易にするために（＝国際化の容易さに直結）、
シフトを追放しランダムアクセス性を付与することが、
Unicodeの重要目標だったわけで。
166:デフォルトの名無しさん
04/01/08 18:45
URLﾘﾝｸ(www.d2.dion.ne.jp)
↑この看板のコウの字がJIS X0208その他の文字集合に見あたらないのですが、
「工」に包摂されているんでしょうか、それとも探し方が悪いのでしょうか……？
167:デフォルトの名無しさん
04/01/11 05:54
>>166
MacOSX 10.3のヒラギノProに異字体として入ってるから（Stdの方には入ってないし、他のUnicodeフォントにも存在してない）文字集合としてはAdobe-ほげほげ-1.5とか以上でないと
入ってなさそうな感じですね。
印刷物に使うのはかまわないけど、インターネットとかには使えないよという警告がでますな。
168:デフォルトの名無しさん
04/01/11 14:54
ほうちゃんと警告が出るのか。
つーかちゃんと異体字指定の方法を標準化して
インターネットでも使えるようにしてほしいんだが
169:デフォルトの名無しさん
04/01/12 00:05
>>168
その辺はまだこれからの課題なんじゃないかな？
AdobeとAppleだけだもんな。今んとこ。
XにContributeされてるAdobeのフォントに日本語のが入ってくれば状況は一気に変わるのかも
知れないけど。
WinはOTFのヒラギノ購入＆インストールで対応できるのかな？
Win持ってないんで判らんのでWinの方でヒラギノ入れてるような奇特な人は試してください。
あ、でもInDesignでドキュメントが完全にコンパチブルだとか売りにしてるようだから、ちゃんと
使えるのだろうな、きっと。
170:デフォルトの名無しさん
04/01/19 08:20
UTF-8 から JIS X 0208 への変換テーブルってどっかない？
171:デフォルトの名無しさん
04/01/19 08:28
>>170
Perlかなんかで作れ。
172:デフォルトの名無しさん
04/01/19 08:57
>>170
fURLﾘﾝｸ(unicode.org) のどっか。
173:170
04/01/19 09:24
UTF-8 って UNICODE を千切って可変長にねじ込んでるだけだったんだね。
URLﾘﾝｸ(ash.jp)
UNICODE <-> JIS X 0208 の変換テーブルは見つかったから、これを使ってやってみるよ。
>171 >172 ありがとう
174:デフォルトの名無しさん
04/01/19 14:44
合成なんて、あきらめちゃっていいんじゃないの? 韓国も逃げちゃったし。
既存のコード体系でもしばしば合成を仕様に含めてるけど、まともに利用されてないしさ。
175:デフォルトの名無しさん
04/01/19 15:25
漢字なんて、あきらめちゃっていいんじゃないの?
既存のコード体系でもしばしば10万字もの漢字を仕様に含めてるけど(ry
というのに賛成なら別に反対しないけど。
古ハングルは合成で表すことになってるし
実際にそれを実装したフォントも存在する
デヴァーナーガリーやアラビア語のスクリプトは
重ね打ちで処理できない合成が必須
176:174
04/01/19 15:31
>>175
> デヴァーナーガリーやアラビア語のスクリプトは
> 重ね打ちで処理できない合成が必須
あぁ、そうなのか。そりゃ俺が浅はかだった。
177:デフォルトの名無しさん
04/01/29 03:16
DB(ORACLE) + JRUN(JAVA + JSP)で
日本語と韓国語を同じページ（一枚のJSP)に混在させて表示させたいのですが
文字コードの設定はどのようにしたらよろしいのでしょうか。
できればＤＢの同じカラムに日本語と韓国語を突っ込んで
DBはORACLE9iだとUTF-16でしたがUTF-8にかえてJSP側でEUC-Krにしては
日本語がばけるしshift-Jisに設定したら韓国語が化ける。
178:デフォルトの名無しさん
04/01/29 08:33
JSP側でUNICODE…
179:デフォルトの名無しさん
04/01/29 12:40
JSP側で日本語と韓国語を同時に使える文字コードを選ぶのは
ものすごく当然だと思うが何に困ってるわけ?
つーか最後の3行日本語になってない
180:デフォルトの名無しさん
04/01/29 12:51
> つーか最後の3行日本語になってない
韓国語を直訳でもしたんじゃないか?
181:デフォルトの名無しさん
04/01/29 18:53
VB.NETを使ってるんですが、
日本語文字の自動判別が出来るライブラリってありませんか？
もしくはShiftJISとeucJPを見分ける賢いやり方誰か教えて～
182:デフォルトの名無しさん
04/01/29 18:56
Shift_JISとeuc_jpは完全には見分けられないなあ。
183:デフォルトの名無しさん
04/01/29 20:42
A0 以外の Shift-JIS の半角カナが偶数個あるものは
EUC-JP と区別がつきまそん。
184:181
04/01/29 21:01
ありがとうございます。
半角カナが奇数個なら判別可能という事なんでしょうか？
詳しい解説キボン
185:デフォルトの名無しさん
04/01/29 21:05
例えば MSB の立っているバイトが奇数個だけ連続している（前後はMSBがゼロ）
場合には EUC-JP ではなさそうだな、ということはいえると思う。
186:デフォルトの名無しさん
04/01/29 21:15
A1～DF が２つあるやつは、
Shift-JIS の半角カナ２文字と、
EUC-JP の２バイト文字１文字と、
両方の可能性がある。
でも、奇数個なら Shift-JIS にしかなりえない。
他にも E0～FC で始まり、A1～FC で終わる文字も
Shift-JIS か EUC-JP か区別できなかったりする。
187:デフォルトの名無しさん
04/01/29 21:41
>>185
EUC-JPは補助漢字も考慮に入れる必要があるので、奇数個続く可能性はある。
188:デフォルトの名無しさん
04/01/29 21:55
文字コードだけでは区別しにくい場合でも
日本語の文章の場合、「ひらがな」が多く含まれる事が判定の一助になる場合がある。
例えばSJISだと0x81-0x83(だったか忘れたけど)が多いとか。
189:デフォルトの名無しさん
04/01/29 22:51
ヒューリスティックな方法だけど、いくつかのプログラム
（例えばnkfとfile(file2)とiconv）にそれぞれ判定してもらって、
多数決をとるっていうのはどーだろ？
190:デフォルトの名無しさん
04/01/29 23:38
UHCもGBKもEUCの上位互換になるような拡張だから
判定ミスで文字化けに悩まされてるのは日本くらいだよなあ
191:デフォルトの名無しさん
04/01/30 13:26
半角カナ１文字だと分かってればstrlen()一発で判別できるんだがな。
…何の役にもたたん話だが。
192:デフォルトの名無しさん
04/01/30 18:09
ファイル入出力をユニコードに対応させたいのですが
_wfopen()使うとWindows95シリーズを切っちゃいますよねぇ。
いっそ切っちゃおうか…、悩ましい。
193:デフォルトの名無しさん
04/02/03 14:28
Windowsでは、UNICODEとSJISが使われてますね。
UNICODEが多国語Winでぶつからないのは分かりますが、
SJISは多国語Winで別の国のコードとぶつかっちゃうんでしょうか？
194:デフォルトの名無しさん
04/02/03 15:27
>>193
ぶつからないよ。非ユニコードのマルチバイト系のAPIを使うときは
暗に陽にキャラクターセットが指定されるから、ぶつかりようが無い。
195:193
04/02/03 16:01
>>194
そこが凄く知りたいところです。
もっと詳しく教えて下さい。
多国語対応してますが、
Delphi/標準VCLだとASCIIしか受け入れてくれないんですが、
キャラクターセットはどこで指定されるんでしょう。
DBの中身はUTF8で画面入出力時にUTF8ToAnsi/AnsiToUtf8してますが、
画面の入出力で文字化けしたら嫌だな、と思って。
196:デフォルトの名無しさん
04/02/03 17:42
Windows で ANSI コードページと言った場合、おそらくは GetACP で得られる
コードページ (日本語ロケールなら CP932 のシフトJIS）への変換だと思うのですが、
これはタダの ShiftJIS ですから、JIS にある文字以外は表現できません。
こんなので答えになってるんだろうか・・・
この辺見てみては？
URLﾘﾝｸ(www.microsoft.com)
197:デフォルトの名無しさん
04/02/04 00:49
javaではUCS-4はサポートされていないのでしょうか？
以下のソースでUnsupportedEncodingExceptionが出ました。
FileOutputStream fo = new FileOutputStream(args[0]);
String str = "A";
fo.write(str.getBytes("ISO-10646-UCS-4"));
198:デフォルトの名無しさん
04/02/04 09:57
java 1.4 は Unicode 3.0 だからなぁ・・・
BMP にない文字は扱えないぽ。
199:デフォルトの名無しさん
04/02/04 21:11
質問です。
fopenでファイルを開くときWindowsの場合、テキスト形式で開いてたら
0x1AをEOFと判断して、バイナリだと0x1AをEOFと判断しないと聞きました。
それでUnixの場合はバイナリでもテキストでも一緒とも聞いたんですが、それではUnix系はどうやってファイルの終端を確認しているんですか？
Unixのファイル終端の識別子はなんなんですか？
（なんか僕が勘違いなどしてるところがあったらズバット指摘してくれてけっこうです）
200:デフォルトの名無しさん
04/02/04 21:14
>>199
> （なんか僕が勘違いなどしてるところがあったらズバット指摘してくれてけっこうです）
その質問はスレ違い。
201:199
04/02/04 21:27
え、文字コードだからここじゃダメですか？
202:デフォルトの名無しさん
04/02/04 22:11
C言語の実装の詳細の話だな。
203:デフォルトの名無しさん
04/02/04 22:14
殆どの近代的なファイルシステムでは、「ファイルの長さ」というものがきちんと管理されているので、
適当なコードを使って終端を示す必要はありません。
一部の処理系の一部の関数において 0x1A をファイル終端としていることがあるのは、ファイル長が
128バイト単位でしか管理されていなかった CP/M という OS との互換性のためです。
204:デフォルトの名無しさん
04/02/04 23:14
>>203
ありがとうございます。
205:デフォルトの名無しさん
04/02/05 00:33
xmodemを思い出すな・・・
206:デフォルトの名無しさん
04/02/05 12:03
UTFとかUNICODEとか言われてもわっかんねーよ
大体おれソフト開発の際そんなこと気にしたことないしな（汗
やっぱりWeb開発者じゃないと気にしないのかな？
207:デフォルトの名無しさん
04/02/05 12:08
まぁアプリのジャンルや開発環境によって違うだろうね。
一生気にせずに済むのなら、それはそれで幸せだとは思う。
208:デフォルトの名無しさん
04/02/05 12:09
.NETとかJava開発者なら知らぬ間に使ってますよ
209:デフォルトの名無しさん
04/02/06 10:24
BCCで可能な限りwin32apiだけを使ってSJISをUTF8へ変換する関数がほしい…
ただしMultiByteToWideCharで直接UTF8へ変換するのはWin95では×らしいので…
210:デフォルトの名無しさん
04/02/06 10:27
まずUTF-16(95ならUCS-2か)に変換してからRFC3629を見てがんがる
機械的な計算だけでできるから大して難しくないよ
211:デフォルトの名無しさん
04/02/06 10:36
ちなみにWindows 2000でもMultiByteToWideCharでUTF-8→UTF-16は
セキュリティの問題があるので勧めない。
XPではセキュリティの問題を防ぐためにnon-shortest-formの文字を
削除するようになったとMSDNに書いてるが、削除だと別の問題が
発生するのでMB_ERR_INVALID_CHARSフラグが必要。
212:デフォルトの名無しさん
04/02/07 01:39
お忙しいところ失礼します。
やり方が分からないので立ち寄らせていただきました。
某板での記事からなのですが、
あるゲームのツールがヨーロッパ(たぶんITALY)で作られて、
日本語がもともと入っているデータがあって、
文字化けして表示されているんですが、
ゲーム中ではちゃんと表示されるんです。
でもそのEditorだとやはり文字化けしてしまうんです。
そこで他の方の質問からの解答で、
文字コードをS-JISからUTF-8へ変換。
とお答えになっていたのですが、
どのようにやればよいかわかりませんか？
本当にやりたいんで御願いします。
ちなみにCとか全く分かりません。
何かソフトありませんか？
OSはXPです。
213:デフォルトの名無しさん
04/02/07 01:41
メモ帳は UTF-8 で保存可能だ。
214:デフォルトの名無しさん
04/02/07 01:45
>>213
さっそくの回答ありがとうございます。
コードはどーやって変えるんでしょうか？
215:デフォルトの名無しさん
04/02/07 01:50
>>212
ここはそんなレベルの低い質問をするスレッドではない。
Windows XPなら、メモ帳がUTF-8に対応しているので
1, Shift JISで書かれたテキストファイルをメモ帳で開く
2, 「名前を付けて保存」のダイアログで、「文字コード」に「UTF-8」を指定
216:デフォルトの名無しさん
04/02/07 01:51
>>214
URLﾘﾝｸ(pc2.2ch.net)
217:デフォルトの名無しさん
04/02/07 01:57
>>214>>215
本当にありがとうございます。
後一個だけおねがいです。
Shift JISで書くのもメモ帳ですか？
それとも何かありますか？
218:デフォルトの名無しさん
04/02/07 02:01
メモ帳はデフォルトで ShiftJIS だ。
219:デフォルトの名無しさん
04/02/07 02:03
よごしてすんませんでした。
本当助かりました、ありがとう！
220:長いと言われたので分割
04/02/07 13:13
遅レスだけど
もし参考になれば
>>181
自分のHPからの抜粋今のところうまくは行ってるけど・・・(C#で作ってます)
最近文字コードの勉強しだしたんで間違えてたらｽﾏｿ
あとわかりづらいとおもうけどｽﾏｿ
■1 ISO-2022-JPの判別
各ESC(0x1B～)が出た場合はISO-2022-JP(確定)
■2 UTF-8の判別
0xC0<->0xFDが出た場合はUTF-8の強い可能性
第2バイト以降が全て0x80<->0xBF内であればUTF-8の強い可能性、そうでない場合は他コード
第1バイトで指定された長さ以下の場合は他コード
■3 EUC半角の判定
第1バイトが0x8Eで第2バイトが0xA1<->0xDFな場合はEUC半角カナの可能性
ただし既に他の文字コードの強い可能性ありと判断されてない場合に限る
第2バイトがEUC半角カナ範囲外で0x80<->0xA0であるならばSJIS(確定)
以上に当てはまらない場合は不明コード
221:長いと言われたので分割2
04/02/07 13:14
■4 EUC補助漢字の判定
第1バイトが0x8Fで第2・3バイトが0xA1<->0xFEな場合はEUC補助漢字の強い可能性
ただし既に他の文字コードの強い可能性ありと判断されてない場合に限る
第2・3バイトどちらかが0xFD・0xFEであるならばEUC補助漢字(確定)
第2・3バイトがEUC補助漢字範囲外で0x80<->0xA0であるならばSJIS(確定)
以上に当てはまらない場合は不明コード
■5 SJISの判定
0x80<->0xA0であるならばSJIS
■6 SJIS半角カナの判定
0xA1<->0xDFが出た場合はSJIS半角カナ・EUC全角かな・カナの強い可能性
ただし既に他の文字コードの強い可能性と判断されてない場合に限る
第1バイトが0xA4か0xA5で第2バイトが[かな]0xA1<->0xF3[カナ]0xA1<->0xF6であるならば
EUC全角ひらがな・カタカナの弱い可能性
第2バイトをチェックして0xE0<->0xFEであるならばEUCの強い可能性で0xFD・0xFEの場合はEUC(確定)
第2バイトが存在しない場合はSJISの強い可能性
以上に当てはまらない場合はSJIS半角カナの強い可能性
■7 EUCの判定
0xA1<->0xFEの場合はEUCの強い可能性で0xFD・0xFEの場合はEUC(確定)
当てはまらない場合は不明コード
222:長いと言われたので分割3
04/02/07 13:15
[１]→ ISO-2022-JP確定
↓
[２]→UTF-8強可能性→UTF-8強可能性→次ループ(ポインタ=+UTF8サイズ)
｜ ＋→他コードの強可能性→[３]へ
↓
[３]→EUC半角カナ強可能性→EUC半角カナ強可能性→次ループ(ポインタ=+1)
｜ ＋→EUC半角カナ確定
｜ ＋→SJIS確定
｜ ＋→不明コード→次ループ(ポインタ=+1)
↓
[４]→EUC補助漢字強可能性→EUC補助漢字強可能性→次ループ(ポインタ=+1)
｜ ＋→EUC補助漢字確定
｜ ＋→SJIS確定
｜ ＋→不明コード→次ループ(ポインタ=+1)
↓
[５]→SJIS確定
↓
[６]→SJIS半角カナ強可能性→SJIS半角カナ強可能性→次ループ(ポインタ=+1)
｜ ＋→EUC全角かなカナ弱可能性→次ループ(ポインタ=+2)
｜ ＋→EUC強可能性→次ループ(ポインタ=+1)
｜ ＋→EUC確定
↓
[７]→EUC強可能性→次ループ(ポインタ=+1)
＋→EUC確定
↓
不明コード→次ループ(ポインタ=+1)
223:デフォルトの名無しさん
04/02/07 13:31
BOMは無視？
224:デフォルトの名無しさん
04/02/07 13:37
utf-8 → Shift_JIS （Shift_JISに無い文字はTeXのutf package用に\UTF{xxxx}）
がほしい
225:220
04/02/07 14:13
>>223
BOMと言うものを知らなかったので・・・
今検索してみてわかりました
UTF-8に関しては
変換するときは消したほうがよさそうですが
判別の時は特に考えなくてもいいかと
判断された文字コードをスコア化して１番多いものをその文字コードと判断してるんですが
それに対して重みをつける(通常+1を+2ぐらい)でいいかなと
そのうちUTF-16とかにも対応したいので非常に勉強になりました
ありがとうございます
226:220
04/02/07 15:18
とおもったらUTF-8・UTF-8Nと区別するんですね＿|￣|○
.NETのEncodingクラスには無さそうだけどためしに変換してみたら
ゴミデータが付いてきたから標準でUTF-8Nなのかなぁ
227:デフォルトの名無しさん
04/02/07 15:43
>>220
> 0xC0<->0xFDが出た場合はUTF-8の強い可能性
0xC0, 0xC1 が出た場合はUTF-8ではない(確定)
Unicode(U+10FFFFまで)はサポートするけどISO10646の
UCS-4(U+7FFFFFFF)はサポートしないなら0xF5-FDも除外できる
RFC2279/3629参照
228:220
04/02/07 16:35
>>227
RFC読みました
C0、C1がセキュリティ上禁止されていることがわかりましたので
早速条件に入れたいとおもいます
UCS-4に関してはとりあえずサポートして置きたいので入れて起きます
ありがとうございます
奥が深い・・・
229:デフォルトの名無しさん
04/02/07 22:00
>> 220
どこかのHPにまとまっている？
230:220
04/02/07 22:25
>>229
はいまとまってるとおもいますが２ｃｈで晒すほど度胸無いので・・・
最近ページ追加したばっかりでgooglebotは数回きてるんですが反映はまだ見たいです
231:デフォルトの名無しさん
04/02/08 03:44
予言：
1 0 年 後 に は 、 U T F - 6 4 が 標 準 に な り ま す 。
＿|￣|○
232:デフォルトの名無しさん
04/02/10 10:27
>>211
どの場合も、事前に必要バッファ長を取得してから、
バッファ長指定して呼び出せば大丈夫じゃない？
233:デフォルトの名無しさん
04/02/10 17:20
>>232
セキュリティの問題というのは>>227-228でもちょっと触れてるけど
たとえばディレクトリトラバーサル対策で「2E 2E」という文字列を
フィルタリングしても、「C0 AE 2E」とか書くと貫通してしまうという問題。
URLﾘﾝｸ(altba.com)
あるいは「<」をnon-shortest formで送ることでXSSを発動させるとか。
URLﾘﾝｸ(www.cert.org)
対策としてXPではC0 AEのようなシーケンスを削除するようになった
わけだが、今度は「2E C0 AE 2E」とか書くと貫通する。
もう少しモノを考えて修正してくれMicrosoftと小一時間(ry
ただしMB_ERR_INVALID_CHARSを付けるとエラーになってくれる。
234:デフォルトの名無しさん
04/02/10 17:46
>>233
おお、なるほど。
勉強になります。
結局のところ、有効な対策の一つとしては、
「API側の対策をあてにせず、UTF-16 or UCS-2に変換した後に危険な文字をチェックしろ」
ってことですかね？
235:デフォルトの名無しさん
04/02/10 18:28
逆では?
UTF-16 or UCS-2 のままでのチェックだけではなく、
API に渡される実際の引数レベルでもチェックをするって感じ？
236:デフォルトの名無しさん
04/02/11 05:47
>>235
違う。
237:デフォルトの名無しさん
04/02/11 23:12
Shift_JISやEUC-JPやRFC1468に直接Unicode文字や補助漢字、JIS第3・第4水準の文字を
埋め込める規格を考案したけど、実用価値あるんだろうか？
Shift_JISで直接Unicode文字が使えたら機種依存文字の問題はなくなると思うんだけどね…
238:デフォルトの名無しさん
04/02/11 23:29
>>237
> Shift_JISやEUC-JPやRFC1468に直接Unicode文字や補助漢字、JIS第3・第4水準の文字を
> 埋め込める規格を考案したけど、実用価値あるんだろうか？
率直にいって無いだろう。でもせっかくだから言ってみたらどうだろう?
目新しいアイデアなら、ほかのところで生かせるかもしれない。
まさか制御文字の一部を使って符号化する、なんてアイデアじゃないだろうな……
それと、文字コードの話するなら
> Unicode文字
> ？
> 機種依存文字
この辺は直した方がいいよ。
239:デフォルトの名無しさん
04/02/11 23:36
>>237
イオさんという人が昔「拡張シフトJIS」「拡張EUC-JP」「拡張ISO-2022-JP」
とかいうの考案してましたね。サイト消えちゃったけどWayBack Machineから発掘
URLﾘﾝｸ(web.archive.org)
> Shift_JISで直接Unicode文字が使えたら機種依存文字の問題はなくなると思うんだけどね…
GBK/GB18030はGB2312と上位互換を保ったままUnicodeの文字を
全部使えますね。
Unicodeに移行しようと思ったら既存のデータを全部変換するか
捨てる必要があるシフトJISやBig5圏から見たらうらやましい限り。
240:デフォルトの名無しさん
04/02/12 12:14
>>238
端的にいうと、JIS X 0208の未定義領域を利用して、Unicodeのサロゲートペアみたいに、
面サロゲート、区サロゲート、点サロゲートの3文字(合計6バイト)を組み合わせて
(サロゲートトリオと呼ぶことにします)JIS X 0208にない文字を表現するんです。
たとえば面サロゲートは09区～12区、14区～15区、85区～88区のどこか、
区サロゲートは93区、点サロゲートは94区を使用することにします。
13区と89区～92区はWindowsの外字と衝突するので使用しません。
多分面サロゲートは940文字も要らない(*1)と思うので85区～88区だけでいい
(*2)とは思いますが。
(*1)使える総文字数は940*94*94-(940+94+94)=8304712文字
(*2)使える総文字数は376*94*94=(376+94+94)=3321772文字
>>238
すみません。「?」はJIS X 0201/ASCIIのほうを使用しろということでしょうか。
「機種依存文字」は「JIS X 0208未定義文字」、「Unicode文字」は
「Unicodeに含まれてJIS X 0208に含まれていない文字」のほうが正しい言い方ですね。
上のほうでも「Windowsの外字」なんて怪しげな言葉を使っていますが、ご勘弁を…
241:デフォルトの名無しさん
04/02/12 13:18
>>240の続きです。
85区01点はJIS X 0213第1面(第3水準)に収録されている文字のうち、
JIS X 0208に含まれない文字を区点番号はそのままで収録します。
JIS X 0208に含まれている文字の場所は空けておき、使用禁止にします。
同じように、85区02点はJIS X 0213第2面(第4水準)に収録されている
文字を収録します。
85区03点はJIS X 0212(補助漢字)を収録します。
Unicodeに収録されている文字は0x000000～0x10FFFFの1114112文字
(サロゲートペアは使用を禁止するが、文字数には含めておく)ですが、
これを94進法でサロゲートトリオの各サロゲートを求めます。
面サロゲートは全部で127個必要になりますので、85区04点～86区36点を
使用することにします。
86区37点～89区94点はとりあえず保留領域にしますが、将来の拡張として
大漢和辞典に収録されている漢字でJISやUnicodeにない文字や、
人名・地名用の異体字を収録する領域にしておきます。
同じ文字がJIS X 0201、JIS X 0208、JIS X 0213、JIS X 0212、Unicodeに
重複して収録されていることもありますが、この場合、
JIS X 0201 > JIS X 0208 > JIS X 0213 > JIS X 0212 > Unicode
の順番に優先して文字コードを使用することにします。
たとえばJIS X 0213、JIS X 0212、Unicodeに重複して収録されている文字は
JIS X 0213の文字コードを使用することになります。
242:デフォルトの名無しさん
04/02/12 13:24
・・・Unicode使うよ。。。
243:デフォルトの名無しさん
04/02/12 13:26
>>240-241の続きです。
これだけの文字(>>240参照)を使用することになると、すべての文字を
収録したフォントを製造することが難しくなります。
そこで、フォントに「収録基準」を設け、それをフォントのパッケージに
明示することによってフォントの収録文字数を明らかにします。
収録基準0 JIS X 0201(またはASCII) + JIS X 0208
収録基準1 JIS X 0201(またはASCII) + JIS X 0208 + JIS X 0213
収録基準2 JIS X 0201(またはASCII) + JIS X 0208 + JIS X 0213 + JIS X 0212
収録基準3 JIS X 0201(またはASCII) + JIS X 0208 + JIS X 0213 + JIS X 0212 + Unicodeの漢字(BMPのみ)(*3)
収録基準4 JIS X 0201(またはASCII) + JIS X 0208 + JIS X 0213 + JIS X 0212 + Unicodeの漢字(BMP以外を含む)(*3)
収録基準5 JIS X 0201(またはASCII) + JIS X 0208 + JIS X 0213 + JIS X 0212 + Unicodeのすべての文字
(*3)CJK統合漢字、CJK互換漢字、CJK互換文字のうちの漢字
説明は以上です。長文ご容赦ください。
244:デフォルトの名無しさん
04/02/12 14:13
1バイト部分がJIS X 0201かASCIIかによって使用禁止の区点が
変化しますがそこは曖昧なままですか?
245:デフォルトの名無しさん
04/02/12 16:14
>>240の総文字数が誤っていたので訂正します。
(*1)使える総文字数は94*94-(940+94+94)+940*94*94=8313548文字
(*2)使える総文字数は94*94-(376+94+94)+376*94*94=3330608文字
>>244
だよねぇ。
1バイト英数字をASCIIにするのをやめてJIS X 0201にするとはっきり宣言してしまったほうが
Shift_JISとの互換性を考えるといいのかも。
246:デフォルトの名無しさん
04/02/12 16:25
> 1バイト英数字をASCIIにするのをやめてJIS X 0201にするとはっきり宣言してしまったほうが
イラネ。
247:デフォルトの名無しさん
04/02/12 16:32
> JIS X 0201にするとはっきり宣言してしまったほうが
それはセキュリティの問題が発生するので
すくなくともWindowsのコードページとしては採用不可能
248:デフォルトの名無しさん
04/02/12 17:12
すなおにUTF32使おうよ・・・
249:デフォルトの名無しさん
04/02/12 18:05
ということは1バイトの英数字がASCIIで、1バイトのカタカナがJIS X 0201なのが
一番いいということなのかな。
1バイトのカタカナなんて廃止してしまえ!!という強硬な意見はあると思うけど、
互換性を考えるとどうしても廃止できないと思う。
250:デフォルトの名無しさん
04/02/12 18:13
シフトJISの上位互換こそが特長なんだから
1バイトカナを廃止したら話にならん
互換性がなくていいならそれこそ>>248だ
251:デフォルトの名無しさん
04/02/13 01:17
UTF32 って何が嬉しいのでしょうか。固定長ではないのですよね?
252:デフォルトの名無しさん
04/02/13 01:39
BOM...かな？
253:デフォルトの名無しさん
04/02/13 01:53
UTF32は固定長ですがなにか？
254:デフォルトの名無しさん
04/02/13 02:11
合成があんだろ
255:デフォルトの名無しさん
04/02/13 02:20
どうせ固定長じゃないならUTF-8のほうがいい
256:デフォルトの名無しさん
04/02/13 02:29
utf32が固定長じゃないとかUCS4もびっくりだな
何文字使う気なんだ
257:デフォルトの名無しさん
04/02/13 04:09
誰か>>256を翻訳してください
258:デフォルトの名無しさん
04/02/13 07:45
Even UCS4 looks conventional; utf32 dosn't have the fixed size etc.
How many characters does it plan to use?
259:デフォルトの名無しさん
04/02/13 11:07
>>257
He said,
"UNICODE -> UNI-WORD -> UNI-LANGUAGE -> UNI-PEOPLE -> UNI-NATIONAL
-> UNI-WORLD -> UNI-PLANET -> UNI-COSMOS -> UNI-SPACE-TIME -> UTF-32"
260:デフォルトの名無しさん
04/02/13 12:28
UNKO
261:デフォルトの名無しさん
04/02/13 12:51
CPU等が速くなってんのにアプリの体感速度が変わらないとう現象の
原因を作っている人たちはココにいたんですね。。
262:デフォルトの名無しさん
04/02/13 13:26
NTではUnicode化したほうが速くなるが
PC初心者にお帰り
263:デフォルトの名無しさん
04/02/13 13:58
つーか >>261 は何を言いたいのかよくわからん
264:デフォルトの名無しさん
04/02/13 14:05
>>263
IT産業を支えてくれてありがとうと言っているのですよ
265:デフォルトの名無しさん
04/02/13 16:40
┏┓┏┳┓
┏┛┗┻╋┛ ＼ i
┗┓┏┓┃ ─ ＋ ─>>1-1000
┃┃┃┃ ┏┳┳┓ ／/ | ＼
┗┛┗┛ ┗╋┛┃ ／ / |
┗━┛ ／ /
￣ 二─ ＿
￣ ､ - ､
-､＼ ＼
／ ＼＼ ＼
／／ ＼ヾ ヽ ヽ
／／／ ＼ ヾ、 | i
／__( |! `i |
<_,へ ＞- 、 ,.-､_ | |
＼ノ人＼ ／ ､ }! ＼ | |
＼へ〃＼／ヾ＼_ﾉ､ﾉ人 ,.-､ | |
＼|＼rj＼ヾ / ＼_ﾌ ,／ |! ﾘ |
rm＼ノ _ Y Lノ / | |
|ヽ-r＜￣`ヾr'￣ヽ / / / /
| └､ノ/￣`,-`┐ { _／ / ／ ／／
ﾚ⌒＼!_ ｰ -{ ﾉ ｝ ／ ／ ／
￣`ー一 'ﾞ _／／_ ／
＿二─ "
266:デフォルトの名無しさん
04/02/25 00:01
おい、お前ら字形が変わりましたよ。
URLﾘﾝｸ(www.forest.impress.co.jp)
コードは関係ないからスレ違いかもしれんが、改正前の字形で書いてると
ｵｻｰﾝ扱いになる悪寒。俺には改正後の文字が、なんか昔の字に
見えるんだけど。。。
267:デフォルトの名無しさん
04/02/25 00:30
経緯
１．旧字体のうち一部を新字体に「正式に」改正
２．改正されていない旧字体の一部を１．の改正からの「類推で勝手に」変更 (どこが主導でやったのかは知らないが)
３．今回２．で勝手に変更されていたのを「もともとの旧字体」に訂正
なので今回の改正で「改正後の文字が昔の字に見える」のは当たり前。
268:デフォルトの名無しさん
04/02/25 00:42
殆どが「書き文字としては間違いだけど、コンピュータ上では許されていた字形」を
正しい字形に戻したって感じを受けるな。
中には違いがさっぱり分からんのもあるんだが...。蟹とか灸とか粂とか。
個人的には進捗の捗の字が正しくなるのがうれしい。
269:デフォルトの名無しさん
04/02/25 00:58
>268
「正しさ」って何？
頻、賓、濱、捗
270:デフォルトの名無しさん
04/02/25 01:01
歩 渉 陟 捗 濱 瀕
271:デフォルトの名無しさん
04/02/25 01:12
歩 と
272:デフォルトの名無しさん
04/02/25 01:19
うぉ、『倶舎論』の本来の「倶」が入ってる！
産業省ﾏﾝｾｰ！
273:デフォルトの名無しさん
04/02/25 01:24
>>269
紙媒体の辞書に載せられるかどうか。
（載ってるかどうかとは言わないでおく）
274:デフォルトの名無しさん
04/02/25 01:52
DTP、フォント関連の連中は
忙しくなるな(w
275:デフォルトの名無しさん
04/02/25 02:58
DTP業界のフォントは78JIS字形をサポートし続けてきたから
実はほとんど影響なかったり。印刷物に使われ続けてきたん
だからまあ当然といえば当然だが。
276:デフォルトの名無しさん
04/02/25 03:14
何かスラドで激しくデジャヴを感じる投稿が多数あるような。
> 中には違いがさっぱり分からんのもあるんだが...。蟹とか灸とか粂とか。
そのへんは、例示字形にデザイン差を残しておくと規格がデザイン差に
関して何らかの価値判断を行ったと誤解されるおそれがあるから、
表外漢字字体表に一致させたもの(と解説に書かれてる)。
厳密にその通りのデザインで実装することを要求するものではないし、
そのような解釈はかえって表外漢字字体表の趣旨に沿わない。
何がデザイン差で何が包摂の範囲内での字体変更かも解説には
書かれてる。
277:デフォルトの名無しさん
04/02/25 10:49
蟹は「角」の右下と「虫」の上がくっついてるかどうかだな
微妙杉
278:デフォルトの名無しさん
04/02/25 13:05
鯖と鰯は良いね！
279:デフォルトの名無しさん
04/02/27 02:23
JIS X 0213が改正されても、JIS X 0208も一緒に改正されなければ無意味。
JIS X 0213なんて新JISキーボードと同じで、ほとんど使われていない規格なんだから。
ところで、法務省の人名用漢字追加はJIS漢字の字体をベースにするといっていたけど、
今回の改正でどう影響するんだろう？
今のところ、常用漢字・人名用漢字には2点しんにょうの字体はないけど（許容漢字を除く）、
場合によっては2点しんにょうに改正された文字が人名用漢字に追加される可能性がある。
280:デフォルトの名無しさん
04/02/27 04:15
後、気になったのは「辻」の字が2点しんにょうになっていること。
「表外漢字字体表」に従えば当然そうなるんだが、実際の人名（というか人の姓）で
使われているのは1点しんにょうの方が圧倒的多数。
2点しんにょうは文芸家（wが好んで使う（綾辻行人とか辻仁成など）けど、
表札とかに2点しんにょうの方が使われているのは見たことがない。
辻さんが「自分の名字の文字が『勝手に』正字に矯正されている」ことを知ったらどう思うだろうか。
人名にはまず使われていない迂とか迄とか謎とかは2点しんにょうのみにしてもいいけど、
辻は1点しんにょうと2点しんにょうの両方を規格に入れるべきだったと思う。
包摂規準に例外を作ってまでも。
281:デフォルトの名無しさん
04/02/27 04:23
正式には難しい字が使われてても
普段は簡単な字で書いてたりするので
（例：濱本を浜本と書いてたり）、
普段簡単な字で書いてるからといって、
その字で登録されているとは限んないけどね。
282:デフォルトの名無しさん
04/02/27 09:15
>>279
JIS X 0208を改正しなかった理由も解説に書かれてるね。
変更をほとんど使われていない規格だけにとどめたことで
混乱を最小限に抑えたとかいう角度の見方もある。
283:デフォルトの名無しさん
04/02/27 09:21
戸籍に登録されている「辻」が1点しんにょうということはありえない。
現時点で人名用漢字にも常用漢字にもないから戦後追加された
ことはないし、戦前の活字は当然すべて2点だし、
法務省は1点の「辻」は俗字扱いにしていて正字からの変更を
認めていないから既存の「辻」を持つ苗字が変えられた可能性もない。
したがって表札とかには戸籍にない略字を勝手に使っているだけだと
思われ
284:デフォルトの名無しさん
04/02/27 09:24
というか表札はふつう明朝体活字で書いたりしないから
1点しんにょうになるのはむしろ当然なような。
それとも点の下がグネグネした「辻」も追加すべきですかね。
285:デフォルトの名無しさん
04/02/27 09:28
> ところで、法務省の人名用漢字追加はJIS漢字の字体をベースにするといっていたけど、
読売の記事だとそれは去年の検討の話で
いったんご破算になったらしいんだが
今回も結局JIS漢字を元にしてるの?
286:デフォルトの名無しさん
04/02/27 09:52
imadoki kanji tukatteru yasi kimoi
287:デフォルトの名無しさん
04/02/27 10:15
>>283
電算化前の戸籍って和文タイプで打ったのもあるけど、手書きもあるよ。
たとえば漏れの本籍地は京都市だけど、戸籍謄本を取ってみたら手書きだった。
手書きの「辻」のすべてが2点しんにょうになっているとは思えない。
288:デフォルトの名無しさん
04/02/27 11:34
ああそうか、戸籍の電算化を阻んでるのは手書きの誤記を
これが自分の名前の字だと主張する連中だったな
> 手書きの「辻」のすべてが2点しんにょうになっているとは思えない。
むしろ手書きでは1点が普通だろ。それが活字では2点になるという
常識が戦前はあったわけだが
289:デフォルトの名無しさん
04/02/27 15:50
で、ののたんの名字は１点なの？２点なの？
場合によっちゃ幕の字書き換えなきゃならんのだけど
290:デフォルトの名無しさん
04/02/27 17:16
さすがプログラム版のスレだけあって、
漢字の話題になるといきなりレベルが低くなるな。
291:デフォルトの名無しさん
04/02/27 17:39
そもそも>>266が自分で言ってるがスレ違いっぽいし
292:デフォルトの名無しさん
04/02/27 22:10
>290
レベルの高い漢字の話題はどこでやってますか？
煽りじゃなく本当に知りたい。
293:デフォルトの名無しさん
04/02/27 22:16
格調高く感じを論ずるスレ四
ｽﾚﾘﾝｸ(kobun板)
294:デフォルトの名無しさん
04/02/27 22:17
>>293
感じって・・・
295:デフォルトの名無しさん
04/02/27 22:21
＿|￣|○ やられた。 古文・漢文板なんていったこと無かったから、無防備だった。
296:デフォルトの名無しさん
04/02/27 22:53
旧字体・別字体について
ｽﾚﾘﾝｸ(gengo板)
【朝日】文字を徹底的に略すスレ【JIS】
ｽﾚﾘﾝｸ(gengo板)
【ゐゑ】舊字、舊假名遣ひで話すスレッド 三箇目
ｽﾚﾘﾝｸ(gengo板)
【常用漢字表にない漢字の代わりの漢字について
ｽﾚﾘﾝｸ(gengo板)
◆◆漢字専用スレｐａｒｔ2◆◆
ｽﾚﾘﾝｸ(kobun板)
旧かな旧漢字は伝統的でしょうか
ｽﾚﾘﾝｸ(kobun板)
●教育漢字、常用漢字を有志で作り直すスレ●
ｽﾚﾘﾝｸ(kobun板)
JIS漢字
ｽﾚﾘﾝｸ(kobun板)
ちょっと集めてみたがレベルがそう違うとも思えんがね
297:デフォルトの名無しさん
04/02/27 23:09
ここも。
JISをもう1度、最初から作りなおせるとしたら
ｽﾚﾘﾝｸ(gengo板)
298:292
04/02/27 23:20
サンクスコ。
なるほど、レベルの違うスレもあれば、そうでないのもあって面白い。
結局、バカのせいなんだよな。
「かほる」なんて名前が昔から使われていると思うようなバカと一緒。
スレ違いなのでAC。
299:デフォルトの名無しさん
04/02/29 03:37
さ、
300:デフォルトの名無しさん
04/02/29 03:37
さんびゃくー！！
301:デフォルトの名無しさん
04/02/29 20:02
m17n-libがもうすぐ公開だな
使い物になるのだろうか
302:290
04/03/01 13:22
いや、どこのスレだって無責任なレスがほとんどなんだけどさ、
言語学版あたりの文字コード関連スレだと、
かなーり詳しい奴が張り付いてて、すぐに突っ込みが入る。
しょーがないから俺が突っ込んでおくと、
戸籍での「辻」は一点も二点もありだ。っつーか、
しんにょうはすべて一点でも二点でも認められているわけだが。
303:LightCone ◆sSJBc30S5w
04/03/03 21:26
UNICODEのUTF-8の日本語向けの符号を考えてみました:
URLﾘﾝｸ(www.nowsmartsoft.or.tv)
UTF-8と違って、JIS第一、第二までは、2BYTEで表せます。
まだ、仕様を考えている途中なので、この符号を用いたプログラムは一つ
もありません。
何か問題点や、嘘を書いてる点などが見つかりましたらご指摘頂ければ幸い
です（つまり添削お願いします）。
304:デフォルトの名無しさん
04/03/04 03:07
>>303
変換にテーブルが必要な時点でUTFと名乗るのは問題がある。
俺コードとかって名前なら別にどうでもいいんだけど。
305:デフォルトの名無しさん
04/03/04 07:40
>>303
>多バイト文字途中への検索ヒットを簡単に回避可能
正規表現で回避しているようだけど、回避のための
修正が必要な時点で、UTF-8と比べて汎用的とはいいがたいなぁ。
(strcmpを使っているなら細工をして再コンパイル等が必要だけど
UTF-8は修正の必要もない)
306:デフォルトの名無しさん
04/03/04 09:25
>>303
> 何か問題点や、
単にまた混乱の元を追加するだけってことかな。
307:デフォルトの名無しさん
04/03/04 11:16
みんなUTF-8で結構おなか一杯だからなぁ。
308:デフォルトの名無しさん
04/03/04 11:32
>>303
Unicodeを混ぜることができる,EUC-JP/シフトJISの一種と考えたら
そこそこ面白い。
309:デフォルトの名無しさん
04/03/04 12:43
>>308
その手の拡張は>>239にもあるし>>240-にもあるしおなかいっぱい
310:デフォルトの名無しさん
04/03/04 13:21
主にどういう局面で利用される事を想定してるんだろうか。
UTF-8でも少しサイズが大きい程度で、そんなに気にならないんだけど。
独自にやる苦労に見合うだけの結果が得られるかは微妙だ。
打算計算を抜きにすれば、自作のOSで自作の文字コード使って
色々実験するのは楽しそうとは思うけどね。(^^;
311:LightCone ◆sSJBc30S5w
04/03/04 16:31
>>308, >>309
「Unicodeを混ぜることの出来るEUC-JP/SJIS」に、「簡単に逆戻り可能」な
性質を取り入れたような感じなんです。
ちなみに、>>239の符号では、逆戻りは出来ないと思いますが、
さらに、「\」コードを含んでいるので、色々と問題があると思います。
というわけで、いかがでしょうか。
新しいコードは、みんなが使い始めるか、よっぽど良い性質がない限り、
抵抗感がある物かも知れませんが。
312:LightCone ◆sSJBc30S5w
04/03/04 16:42
>>310
>主にどういう局面で利用される事を想定してるんだろうか。
>UTF-8でも少しサイズが大きい程度で、そんなに気にならないんだけど。
そう思われる人が多いのであれば、せっかくでしたが、余り意味がないかも
知れません。
でも、今まで2BYTE表せていた文字に3BYTEを当てるのに抵抗がある人には、
需要があるのではないかと思うんです。
その点だけでは、>>239の符号もいいと思いますが、UTF-JAPANの方は、
逆戻り可能の性質を持っている点や、多バイト文字に\コード等を含んで
ない点で、解析やエディタ作りなどにおいて、真価を発揮する場面がある
のではないかと思います。
EUCも、2バイトの範囲では逆戻り可能ですけど。>>239に書かれている拡張EUC:
URLﾘﾝｸ(web.archive.org)
においては、UTF-16,UTF-32対応する3バイト以上のコードでは、逆戻りが
出来なくなっているようですし。
313:LightCone ◆sSJBc30S5w
04/03/04 16:46
>>304
この符号の場合、基本的に地域や言語ごとに違う変換テーブルを用意する
必要がありますね。それをOSがサポートして、欲しいフォーマットに
まで変換を世話してくれればアプリの負担は減るとは思うんですが。
全世界で全く同じコードを用いたいのであれば、漢字が３バイトになって
しまうのは、元々やむを得ないかも知れない。
314:LightCone ◆sSJBc30S5w
04/03/04 16:53
>>305
UTF-8の場合、strcmp()は、単純な昔ながらの1バイト単位の比較のまま
無修正で利用できてしまうんですよね。
それは凄い性質ではあると思いますが、結局、コードを無修正で済ました
いばっかりに、データサイズが大きくなる犠牲を払っているんだと思うん
です。
315:LightCone ◆sSJBc30S5w
04/03/04 16:54
なお、
UTF-JAPANを、「UTF-COMPACT-JAPAN」と改名して、
「UTF-COMPACT-ARABIA」
「UTF-COMPACT-CHINA」
なども定義すれば、strcmp()等の修正は、言語数分まで及ばずに
一回だけで済むかも知れませんね。
316:LightCone ◆sSJBc30S5w
04/03/04 16:57
>>237 から続く発言は、なんと先月のものなんですね！
うまく合併できないかな。
317:LightCone ◆sSJBc30S5w
04/03/04 17:02
>>261の
>CPU等が速くなってんのにアプリの体感速度が変わらないとう現象の
>原因を作っている人たちはココにいたんですね。。
これは、今まで2バイトで表現できていた物を3バイトにしようとすることとも
その一つかな。
全世界の文字を使えるのはいいことではあるけれど、日本人が、英語と
JIS第一,第二以外の言語を使用する頻度は低いし、文字集合はUNICODEを
使うにしても、地域ごとに違った符号があってもいいのではないかな。
318:LightCone ◆sSJBc30S5w
04/03/04 17:04
UTF-COMPACTの変換テーブルは、OSが提供するだろうから、
UTF-COMPACT-xxxxx用のアプリは、いずれのxxxxx言語にも
無修正で対応できるのではないだろうか?
319:LightCone ◆sSJBc30S5w
04/03/04 17:10
例えば、HTMLヘッダに、
<meta http-equiv="Content-Type" content="text/html;
charset=
utf-compact-japan">
~~~~~~~~~~~~~~~~~
を書いておけばいいんじゃないかな。
SJISや、EUC-JPでやってることと何ら変わりないと思うし。
320:デフォルトの名無しさん
04/03/04 17:25
アメ公がUTF-16嫌ってUTF-8に走るのとまったく同じ論法だよね
自分たちが使いもしない文字のことなんてどうでもいいと思うのは
世界共通というか
321:LightCone ◆sSJBc30S5w
04/03/04 17:34
>>320
でも、自分たちの地域で効率を上げることにも、一利はあると思うんです。
UNICODEを全否定しているわけではなく、符号長に地域ごとに偏りを
持たせるだけですし。
322:LightCone ◆sSJBc30S5w
04/03/04 17:36
SFみたいな世界になって、文字種が爆発的に増えた場合、やっぱり、
地球では地球語に短い符号を割り当てるんじゃないかな。
そういう意味で、偏りを持たせる発想は、古くさい考えではないと思う。
323:デフォルトの名無しさん
04/03/04 17:38
だったらローカルコードでいいし
地域の数だけ馬鹿でかい変換テーブル持つなんて馬鹿の極み
324:デフォルトの名無しさん
04/03/04 17:41
日本語が多くてサイズが増えるのが嫌なら、UTF-16を使えばいいのでは？
325:デフォルトの名無しさん
04/03/04 17:41
> 制御コード、特殊記号、\コードを含まず
C1文字は制御コードじゃありませんか
そうですか
326:デフォルトの名無しさん
04/03/04 17:43
> JIS X 0213 2000 JIS第三、第四 4344字
今さら2000年版かよ
327:デフォルトの名無しさん
04/03/04 17:43
> 情報交換用漢字符号系
つーかずいぶんと古い資料参照してるな
328:デフォルトの名無しさん
04/03/04 17:44
そもそもたった一つのインプリで他言語をカバーしようとしたのがUnicodeじゃないの？
それを地域ごとに独自テーブル作ったら意味ないじゃん
329:デフォルトの名無しさん
04/03/04 17:44
> /[^\x81-\xde]任意の文字列/
「任意の文字列」が先頭だったらヒットしなくなるね
330:328
04/03/04 17:45
失礼
X他言語
O多言語
331:328
04/03/04 17:47
そもそも
UTF-JAPAN
ってのがかっこわるいよね
せめて
UTF-JPとかUTF-jaとかにすればいいのに
332:デフォルトの名無しさん
04/03/04 17:48
せめてもう少し間隔おいて自演したら？
333:デフォルトの名無しさん
04/03/04 17:49
> SJISや、EUC-JPでやってることと何ら変わりないと思うし。
なんら変わりなく欠点を引き継いでどうするんだよ
334:デフォルトの名無しさん
04/03/04 17:51
>>332
誰に言ってるんですか?
335:デフォルトの名無しさん
04/03/04 18:41
ちょっと考えてはみたけど、UTF-8越えは難しいな。
使っててあまり不満ねーもの。（慣れたのもある）
その俺コードで外人と文書のやり取りする時はどうする気なんだ？
>>331
確かに微妙な名前だ。
>>333
文字集合がUnicodeでやろうと思えば多くの文字を表現出来る点が重要なんじゃね？
サイズを気にするなら圧縮で十分って気がするけど。
336:LightCone ◆sSJBc30S5w
04/03/05 00:09
中国には、JIS第一水準と同様に、「第一級漢字」が定まっていて:
URLﾘﾝｸ(www.kishugiken.co.jp)
このようになってます↑
ご覧の通り、JIS第一、第二水準と重複する部分も多く、興味深いのです。
これと、JIS第一水準を合わせた部分を2BYTEで表せるような、UNICODE符号を
作れば、中国人と日本人の両方にメリットがあるかも知れないと思うのですが、
いかがですか?
337:LightCone ◆sSJBc30S5w
04/03/05 00:17
ちなみに、UNICODEのCJK統合漢字部分は、頻度の低い漢字も何も考えずに
並べてあり、頻度毎に分類できないので、どうしても22000文字程度
をまとめて符号化する必要があります。ASCII符号と互換性を持たせ
つつ、これら全ての文字集合を2BYTEで表現しきることは、ほぼ不可能
です。
しかし、中国の第一級、第二級漢字と、日本のJIS第一、第二水準漢字
には重複する部分が多く、それらの「和集合」の文字なら、2BYTEで
表せる範囲の数ではないかと踏んでるんです。
338:デフォルトの名無しさん
04/03/05 00:19
各文字に割り振るコードの順番にも意味があるから、単に足し合わせれば良いという物でも
ないと思うけど。
339:LightCone ◆sSJBc30S5w
04/03/05 00:23
大体の目安としては、一万五千字程度の文字なら、ASCII符号と互換性
を持たせ、「逆戻り可能」で、しかも、後続バイトを付ければUCS-4全体
を表現しきれるような、2BYTEの符号を作る事が出来ると見ています。
340:LightCone ◆sSJBc30S5w
04/03/05 00:27
>>338
せっかく、JIS第一水準で五十音順、第二水準で部首順になってるのが、
中国の文字セットと合成した際に失われると言うこと?
341:デフォルトの名無しさん
04/03/05 00:28
GB18030は何文字格納できるんだっけか？
342:LightCone ◆sSJBc30S5w
04/03/05 00:29
UNICODEでは、部首順らしいので、統合する際にそれにならえばいい
のでは?
343:LightCone ◆sSJBc30S5w
04/03/05 00:30
>>341
わても知らんので、調べて。
344:デフォルトの名無しさん
04/03/05 00:30
>>342
コテハンには聞いていない。
345:デフォルトの名無しさん
04/03/05 02:12
150万文字ぐらい入るんだっけか＞GB18030
346:デフォルトの名無しさん
04/03/05 13:18
>>345
うん。約1,611,668文字かな。
347:デフォルトの名無しさん
04/03/05 13:49
ちなみに、GB18030は、逆戻り不可だし、検索も複数バイト文字の途中で
ヒットする。
348:LightCone ◆sSJBc30S5w
04/03/06 00:44
UNICODEの新符号「UTFCP」を発案しました:
URLﾘﾝｸ(nowsmartsoft.or.tv)
2バイトの符号で1万5千文字以上を表せて、なおかつ、文字列を文字単位で
正確に逆戻りできる、UNICODE符号です。UCS-4全体を表現できます。
また、多バイト符号にASCII符号を一切含まないので、英大文字小文字変換に
対しても安定です。
理論上、日本語のJIS第一、第二水準漢字、中国語の第一級、第二級漢字の両方
をコードページの切り替えなしに2BYTE符号で表せますので、
UTF8に比べ、頻度の高い日本語や中国語の文章が2/3に(50%減)コンパクトに
なります。
いかがでしょう？ (^_^;)
349:デフォルトの名無しさん
04/03/06 01:44
ハードディスクが何百GBになる時代に、テキストファイルの容量が数十%減ったくらいでは
あまり利点を感じないけどなぁ。
むしろ、>>240-243みたいに(書いたの漏れだけど)EUC-JPやShift_JISの完全上位互換規格を
考えたほうがまだ意味があると思う。
350:デフォルトの名無しさん
04/03/06 07:53
情報の冗長性を取り除いて小さくまとめようとすると
たいてい少し複雑な演算が必要になるよね。
UTF8と張り合うなら演算量も念頭にいれる必要があるかも。
UCS4とUTF8の変換では１～２個の条件分岐と
長さ*(シフト、OR、AND)演算＋入出力程度で変換してる。
351:デフォルトの名無しさん
04/03/06 08:13
>>348
各文字コードの主要な正規表現エンジン各々での探索コストの大まかな比較をやってみてほしい。
352:デフォルトの名無しさん
04/03/06 12:06
ただでさえ混乱している文字コード周りの処理をさらに混乱させないでくれ。
353:デフォルトの名無しさん
04/03/06 12:21
>>348
「俺コード」を作るな。
有用だと信じるなら、IETFとかUnicode.orgにでも提案しろ。
354:デフォルトの名無しさん
04/03/06 13:50
>>352-353
作るのは勝手なんじゃね？
気に入らないなら使わなけりゃ良いだけ。
案が未熟だというだけで作る事自体を否定するものではないかと。
因みに俺もUTF8で不満は無い。
文字コードみたいなもので冒険せずに他で頑張った方が良いんじゃないかと。
高いリスクを冒した結果、成功したところで見返りは小さい。
355:デフォルトの名無しさん
04/03/06 14:12
まあ、独自Unicode系CESなんて、普及するわけもないから、
悪影響も少ないわな。機種依存文字なんかはすぐに悪影響が出るけど。
356:デフォルトの名無しさん
04/03/06 19:34
俺アプリのベースエンコーディングに使う為の独自エンコーディングの開発ならオケですか？
357:デフォルトの名無しさん
04/03/06 20:49
俺OSのベースエンコーディングに使う為の独自エンコーディングの開発ならオケです。
358:デフォルトの名無しさん
04/03/06 21:35
>>350
1つの文字を複数の表現で符号化できる規則は可能なら避けたほうがいい
UTF-8で避けようとすると加減算が余分に入るけど
359:デフォルトの名無しさん
04/03/07 01:11
お前ら釣られるなよw
360:デフォルトの名無しさん
04/03/07 03:20
>>358
UTF-8は一つのコードに対して複数の表現は許していないはずだけど
文字とか字形の話…？
361:デフォルトの名無しさん
04/03/07 04:05
>>360
・・・・は？
362:LightCone ◆sSJBc30S5w
04/03/07 19:28
UTFCPについて、詳しく書いておきました。
符号の読み取りや、逆戻りの状態遷移図やソースプログラムもあります。
また、1バイト単位の正規表現ルーチンでも検索に利用できることも分かったので
書いておきました。
URLﾘﾝｸ(www.nowsmartsoft.or.tv)
363:デフォルトの名無しさん
04/03/07 19:34
2chで宣伝とは・・・
364:デフォルトの名無しさん
04/03/07 22:20
>>362
gobackUTFCP が動くとは思えないのだが。
365:LightCone ◆sSJBc30S5w
04/03/07 22:54
>>364
動くと私は思います。
動かないと思われる例を挙げてみて下さい。(^_^;)
366:デフォルトの名無しさん
04/03/07 23:02
>>362
だから○とか×じゃなくて探索コストで比較しろって。
あんたが主張する利点は対象データの処理がUTF8に比べて
速いということだろ。今の状態では説得力0だ。
367:デフォルトの名無しさん
04/03/07 23:05
>>366
いい加減放置しろって・・・
明らかな宣伝ということで削除依頼もしておいた。
368:LightCone ◆sSJBc30S5w
04/03/07 23:09
>>366
速いという事じゃなく、サイズがコンパクトと言うこと。
ディスクに保存するときは速いだろうけど。
369:デフォルトの名無しさん
04/03/07 23:19
>>368
んなんだから、院試に落ちるんだよ。
偉そうなお題目なんてのは後にしろ。時間の無駄だ。
370:LightCone ◆sSJBc30S5w
04/03/07 23:24
>>369
どの大学の、何学科の院試か知りませんが、工学部の院で良ければ、
東大でも受かります。
371:LightCone ◆sSJBc30S5w
04/03/07 23:25
第一、京大の理学部物理学科だって、研究室によれば簡単に受かるし。
372:デフォルトの名無しさん
04/03/08 00:13
>>365
動く動かないは別として、初期状態が符号列の最後のバイトに
なければならないというのがダメダメ。
そんな前提を置いた上でなら、EUCだってSJISだって
「複数バイト文字の最後のバイトから高々符号長分遡るだけで、
その符号の先頭バイトを発見可能」
って言えてしまうんだが。
373:LightCone ◆sSJBc30S5w
04/03/08 00:36
>>372
>そんな前提を置いた上でなら、EUCだってSJISだって
>「複数バイト文字の最後のバイトから高々符号長分遡るだけで、
>その符号の先頭バイトを発見可能」
>って言えてしまうんだが。
言えません。
例えば、SJISでは、
全角「キ」のコードは、0x83, 0x4c
全角「ャ」("キャ"などの小さい"ヤ")のコードは、0x83,0x83
半角「c」のコードは、0x63
全角「宴」のコードは、0x89, 0x83
全角「ツ」のコードは、0x83, 0x63
となり、
キャc ---> 0x83, 0x4c, 0x83, 0x83, 0x63
宴ツ ---> 0x89, 0x83, 0x83, 0x63
となるので、cにあるとき遡ると、0x63,0x83,0x83と
なり、ツの最後のバイトにあるとき遡ると、0x63,0x83,0x83となり、
全く同一になり、cなのか、ツなのか区別が付かない。
EUCでは、最後尾バイトからスタートする限りは大丈夫。
UTF8では、どこからスタートしても大丈夫。
UTFCPでは、最後尾バイトからスタートする限りは大丈夫。
374:LightCone ◆sSJBc30S5w
04/03/08 00:44
ちなみに、SJISでは、例えば、
ラャc ---> 0x83, 0x89, 0x83, 0x83, 0x63
宴ツ ---> 0x89, 0x83, 0x83, 0x63
のように、最悪のケース、1000バイトも遡っても、遡り始めた文字が、
半角なのか全角なのか判断付きかねる文字列を作れる。
つまり、「ツ」なら全角、「c」なら半角なのだが、その区別が長く遡っても
なかなか付かないような文字列が存在し得リますです。
375:デフォルトの名無しさん
04/03/08 00:50
>>374
UTF8より優れているにしろ使われなきゃどうしようもない。
こんなとこよりもっと有効なところで発表すれば？
376:デフォルトの名無しさん
04/03/08 01:02
>>374
自分のコードがまったくおんなじ問題を抱えているのに
気付いていないんだろうか？
＃こういうのリアルタイムで見たの久しぶりだな...
377:デフォルトの名無しさん
04/03/08 01:46
>>365
符号が DBA で、現在位置が A のとき。
378:デフォルトの名無しさん
04/03/08 01:57
> LightCone
まずは自分のOSで使用してみたら？
せっかく独自のOSを開発しているんだから。
379:デフォルトの名無しさん
04/03/08 02:14
結論: wchar_t使えやボケ
380:デフォルトの名無しさん
04/03/08 02:17
>>358
UTF-8では禁止されたはず。
確かそれ周りのセキュリティーホールもあったような。
（特定文字のチェックをすり抜けるようなやつ）
381:デフォルトの名無しさん
04/03/08 03:33
>>380
イチから作るなら「禁止」じゃなくて理論上重複符号化がありえない
設計にしたほうがいいって趣旨。UTF-8の場合は互換性の問題から
不可能だったわけだが。
セキュリティホールの話は>>232-あたりで出てるね
382:デフォルトの名無しさん
04/03/08 05:07
UTF-8はtransformation format of ISO 10646なんだから
UCSに戻して使うのが本来の使い方。
それを正しく把握していれば重複符号化が可能でも何ら問題無い。
383:デフォルトの名無しさん
04/03/08 07:02
>>363
宣伝ではなくて、突っ込み貰うのが目的なんだろ。
叩き台出してみてマシになるかどうかという。
置き換えるには既にUTF-8が広がり過ぎていると思うが。
384:LightCone ◆sSJBc30S5w
04/03/08 08:45
>>377
>符号が DBA で、現在位置が A のとき。
そんなのは全く問題ありませんよ。あなたが全く理解してないだけです。
URLﾘﾝｸ(www.nowsmartsoft.or.tv)
↑の図を見てもすぐ分かることだし、下の関数冒頭を見ても分かる通り、
*ptr <= 0x7f の判定が真になるので、すぐに、「A」に場合分けできて、
1バイト符号に分類されます。
unsigned char *gobackUTFCP( unsigned char *ptr )
{
if ( *ptr <= 0x7f ) {
//(1) A
ptr--;
}
...
385:デフォルトの名無しさん
04/03/08 10:20
>>382
> UTF-8はtransformation format of ISO 10646なんだから
> UCSに戻して使うのが本来の使い方。
まったくです。
情報交換用コードと情報処理用コードは分けて考えるべきなのに、
UTF-8をそのまま処理することを考えているのは愚かすぎます。
> それを正しく把握していれば重複符号化が可能でも何ら問題無い。
それはどうかと思いますが。
見識の低い人が実装することもあるわけですし。
386:LightCone ◆sSJBc30S5w
04/03/08 10:58
逆戻りがなぜ可能か分かりにくい人が多いようですので、
解説しておきます。ご覧アレ:
URLﾘﾝｸ(www.nowsmartsoft.or.tv)
これで。UTFCP符号が間違いなく逆戻りできることの証明になって
いると思います。
387:385
04/03/08 10:58
>>386
そもそも情報交換用コードで逆戻りする必要がありません。
388:LightCone ◆sSJBc30S5w
04/03/08 11:00
>>387
ASCIIもオンメモリで、32BITで保持するつもりなんでっしゃろか?
389:デフォルトの名無しさん
04/03/08 11:11
>>388
必要ならそうするんでは?
ASCIIだけでよい文脈なら1バイトで処理すればいいし、
そうでないなら4バイトで処理すればいいですし。
あと保持というのがよく分かりません。UTF-*とUCS*の
どちらで保持するかは文脈によるのでは。
390:デフォルトの名無しさん
04/03/08 11:14
ときどきいるよね。自称大発見とか大発明とか。
そろそろ春も近いしね。
391:LightCone ◆sSJBc30S5w
04/03/08 11:20
>>385
そもそも、情報交換用なら、BOCU圧縮を使えば、UTF8よりコンパクトに
なる:
URLﾘﾝｸ(www-6.ibm.com)
UTF8は、情報処理用としてもかなり考慮されていて、ASCII用に書かれ
た古い検索ルーチンや文字処理ルーチンを無修正でUnicodeに対応でき
る特徴をっている。こんな特性は、よく知られている他の可変長符号に
はない。
392:デフォルトの名無しさん
04/03/08 11:28
別に内部コードとしてUTF-8を採用することが
禁止されてるわけでもないのに愚か過ぎるだの見識が低いだの
とまで言われなければならない理由は何ですか
393:デフォルトの名無しさん
04/03/08 11:32
>>383
意見を求めているふりをして人の話などぜんぜん
聞くつもりがないところを見る限り違うような気がします。
では何が目的なのかと言われてもさっぱり分かりませんが
394:デフォルトの名無しさん
04/03/08 11:34
>>391
> UTF8は、情報処理用としてもかなり考慮されていて、ASCII用に書かれ
> た古い検索ルーチンや文字処理ルーチンを無修正でUnicodeに対応でき
> る特徴をっている。こんな特性は、よく知られている他の可変長符号に
> はない。
それはEUC-JPでも普通に行われてきたのでは?^^;
「問題が出ないようにしてある」のと「情報処理用に作ってある」のとは別です。
EUC-JPでもShift JISでもISO-2022-JPでも、内部処理用に使おうと思えば
可能です。実際そういうソフトウェアもあるわけですし。
ただ、その場合処理が複雑になるしその分エンバグする可能性も高いわけです。
> そもそも、情報交換用なら、BOCU圧縮を使えば、UTF8よりコンパクトに
> なる:
> URLﾘﾝｸ(www-6.ibm.com)
ここまでするなら、レイヤーを分けて普通にハフマン符号化した方が良いと思うんだけど。
395:LightCone ◆sSJBc30S5w
04/03/08 11:38
>>394
>それはEUC-JPでも普通に行われてきたのでは?^^;
多分、UTF8の特性をご存じない。
EUC-JPでは、全角文字をASCII用のstrstr()で探そうとすると、
別の全角文字の途中にヒットしてしまうことがあるが、UTF8では
ない。
396:デフォルトの名無しさん
04/03/08 11:43
>>395
> EUC-JPでは、全角文字をASCII用のstrstr()で探そうとすると、
> 別の全角文字の途中にヒットしてしまうことがあるが、UTF8では
> ない。
確かにそうですね。失念していました。
397:396
04/03/08 11:48
ですが情報処理コードとして適切でないのは明らかです。
strstr()して得た開始位置は、全体の何文字目なのでしょうか?
398:デフォルトの名無しさん
04/03/08 11:53
ところで疑問なのは
なんでUTFCPとUTF-JAPANと言う二つの符号化方式を用意したかだ。
399:デフォルトの名無しさん
04/03/08 11:56
それを言うならUCSの一単位は一文字とは限りませんが。
結合音節文字とかご存知ありませんか。
固定長によるインデックスアクセスですべて済まそうと
考えること自体が漢字文化圏の幻想です。
400:デフォルトの名無しさん
04/03/08 12:03
400get
盛り上がってきました
401:デフォルトの名無しさん
04/03/08 12:11
>>384
「if ( ptr[-1] <= 0x7f )」だろマヌケ。
それとも、DBA の B を指すのが正解なのか?
402:デフォルトの名無しさん
04/03/08 12:30
>>399
> 固定長によるインデックスアクセスですべて済まそうと
> 考えること自体が漢字文化圏の幻想です。
この考えは「どうせAという処理をしなければならないのだから
Bという処理が増えてもかまわない」と言っているようで奇妙
です。問題を分割することは基本なのに。
403:デフォルトの名無しさん
04/03/08 12:46
>>398
自分のOS作るのにどういう文字コードをメインに据えるかを考えているらしい。
UTF-8だと漢字のサイズが大きいから気に入らないそうだ。
OSとセットでもなけりゃ独自コードの生き残りは辛そうだから、
良い機会と言えば良い機会なんだろうが。
超漢字が無かったらTRONコードなんて……。