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

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

1:デフォルトの名無しさん
03/09/10 16:04
文字コード変換について語りましょう♪

2:.NET Messenger Service
03/09/10 16:06
お使いの Messenger は、今すぐセキュリティアップデートが必要です。URLﾘﾝｸ(messenger.msn.co.jp) に移動して、アップグレードしてください。

3:デフォルトの名無しさん
03/09/10 16:07
MSゴシックからTerminalへの変換アツゴリズムを教えて下さい。

4:デフォルトの名無しさん
03/09/10 16:13
VC6環境でエディットボックス等から取得した文字列をUTF-8に変換するシンプルな方法教えて

5:デフォルトの名無しさん
03/09/10 16:15
単発質問の為にスレ立てるな

6:デフォルトの名無しさん
03/09/10 16:17
UTF-8からPOP3に変換する方法を教えて

7:デフォルトの名無しさん
03/09/10 16:20
かろやかに市ね

8:デフォルトの名無しさん
03/09/10 16:24
何語れって？
しかもUTF-8⇔SJIS限定かよ！

9:デフォルトの名無しさん
03/09/10 16:26
WideCharToMultiByte

10:デフォルトの名無しさん
03/09/10 16:28
MultiByteToWideChar

11:デフォルトの名無しさん
03/09/10 16:34
良スレのヨカン。

12:デフォルトの名無しさん
03/09/10 16:36
UTF-8⇔SJISに限定せんほうがいいな

13:デフォルトの名無しさん
03/09/10 16:50
そういえば、UTF-16は全然普及しないな。

14:デフォルトの名無しさん
03/09/10 17:21
UltraTinkoFlash
SuperJapneseIiSio

15:デフォルトの名無しさん
03/09/10 17:52
てか、普通の変換はもうすでにプログラミングしているので
どうせなら、機種依存文字とかやってみない？

例えば
①は、0Xad0xa1(euc_jp) 0xe20x910xa0(utf8)

16:デフォルトの名無しさん
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)

次ページ