【UTF8】文字コード変換【SJIS】

【UTF8】文字コード変 ..

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の完全上位互換規格を
考えたほうがまだ意味があると思う。

次ページ