- 1 名前：デフォルトの名無しさん [03/09/10 16:04]
- 文字コード変換について語りましょう♪
- 101 名前：デフォルトの名無しさん mailto:sage [03/12/13 13:35]
- ところで内部コードがUTF-8って何かまずいことあるん？
UCS-2でも(OSによっては)出力する時点で変換しないとならないし
大して利便性は変わらないと思うんだが。
表現方法がいくつもあるほうが逆にやりづらいというかサポートするのが面倒。
- 102 名前：デフォルトの名無しさん mailto:sage [03/12/13 15:52]
- >>101
内部はUCSでいいじゃん。すでにJavaもVBもそうなってて不都合無いだろ。
C++も標準で困らないようになってる。
わざわざ検索処理とかCのランタイム書き直すの？
- 103 名前：デフォルトの名無しさん mailto:sage [03/12/13 16:10]
- >>102
UTF-16だろ
- 104 名前：デフォルトの名無しさん mailto:sage [03/12/13 19:39]
- jis x 0212 って「捨て」なんですか?
- 105 名前：デフォルトの名無しさん mailto:sage [03/12/13 21:37]
- >>96
結局、固定長で多言語を扱うというのは現実的には難しいのか。。。
- 106 名前：デフォルトの名無しさん mailto:sage [03/12/13 23:55]
- >104
Unicodeの中に生き残ってるでしょ。
- 107 名前：デフォルトの名無しさん mailto:sage [03/12/14 00:11]
- 超超超 超漢字！
超超超超 超漢字！
- 108 名前：デフォルトの名無しさん [03/12/14 01:17]
- .NET Framework的には、文字列stringはUTF-16だから、
次世代Longhornもこれに統一されるんじゃないの？
てことは、数年後にはUTF-16が事実上の標準になると。
- 109 名前：デフォルトの名無しさん mailto:sage [03/12/14 02:29]
- 文字コート関連のスレが他に無いので、ここで質問しても宜しいでしょうか?
euc.jp/i18n/charcode.ja.html#chap5
上記 URL で、EUC-JP を ISO-2022 に割り当てる説明が書いてありますが、
G0 - G3 に各符合化文字集合を指示している部分は実際に何か行われている
のでしょうか。
EUC-JP はエスケープシーケンスを使わないという事ですので、エスケープ
シーケンスを使用した指示はしていないと思うのですが。
- 110 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [03/12/14 08:52]
- >>109
EUC-JPは designate を省略しているが、invokeは省略しない。
ISO2022 designate invoke でググって見たら。
- 112 名前：111 mailto:sage [03/12/14 09:02]
- つうか、 ttp://euc.jp/i18n/charcode.ja.html#chap5 にちゃんと書いてあるじゃん。
指示(designate)は省略する。(あらかじめ指示してあると約束する)
EUC-JPを使うと言う取り決めは、G0,G1,G2,G3に
それぞれJIS X0201ローマ字,JIS X0208, JIS X0201カタカナ, JIS X0212を指示するという
取り決めとなるわけ。
(ただし、GOがASCIIなのかJIS X0201ローマ字なのかにはゆれがある。)
当然、呼び出し(invoke)は行う。
- 113 名前：デフォルトの名無しさん mailto:sage [03/12/14 15:37]
- G0にJIS X 0201ローマ字を指示するEUCってあったっけ?
(実装の解釈が変というのは除いて)
JIS X 0208本体のラテン文字・漢字用8ビット符号がいちおう該当するか。
これはG2もG3も使わないけど
- 114 名前：デフォルトの名無しさん mailto:sage [03/12/14 16:30]
- >>113
ttp://www.opengroup.or.jp/jvc/cde/euc.html
- 115 名前：デフォルトの名無しさん mailto:sage [03/12/14 16:40]
- >>114
見事なまでにバラバラだな
- 116 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [03/12/14 21:21]
- エスパー募集ですか？
- 119 名前：デフォルトの名無しさん mailto:sage [03/12/14 22:07]
- CString って MFCだよねぇ。
_MBCSと_UNICODEのどっちが定義されているかで入っているもの違うけど。
どっちにせよ、 CStringをそのままprintfで出力するのは反則だし。
_tprintf("%s\n", LPCTSTR(szEUC));
MFCスレで聞けば？
- 120 名前：117 mailto:sage [03/12/15 00:32]
- printf( "%d\n" szBuf ); → %s
また やってしもうたか・・・＿|￣|○
設定って、#define とかのことでした すんまそん
- 121 名前：デフォルトの名無しさん mailto:sage [03/12/15 02:10]
- SJISしか受け付けないコンソールにEUC出力すれば、
そりゃ文字化けするわなぁ。
- 122 名前：デフォルトの名無しさん [03/12/15 11:40]
- EUC-TWってSS2の後にA2〜B0を付けてPlaneを識別している
みたいですけどこういうのってISO 2022的にアリなんですか?
- 123 名前：122 mailto:sage [03/12/15 11:58]
- 94^3集合と考えればいちおうアリですね。
問題はISO-IRには別々の94^2集合しか登録されていないことですが。
- 124 名前：デフォルトの名無しさん [03/12/15 12:58]
- 内部コード UTF-8 は XML がらみのライブラリを使うときとかに多用するけど、
逆に OS 側やら他のライブラリは UTF-8 なんてこと殆どないんで、
かなりの場面でコード変換が必要になるなぁ。。
- 125 名前：デフォルトの名無しさん mailto:sage [03/12/15 15:40]
- UCS-2って文字集合のことですよね。
UTF-16はUCS-2の符号化方式の一種ですよね。
ところで、GNUのlibiconvっていうライブラリに符号化方式としてUSC-2が使えるんだけど、
これって何か特別な使い方があるのかな。ダンプしてみたらUTF-16BEと全く同じなんですよね。
- 126 名前：デフォルトの名無しさん mailto:sage [03/12/15 16:09]
- > UTF-16はUCS-2の符号化方式の一種ですよね。
違うと思う(前者は後者にない補助面の文字が存在してるから)
- 127 名前：デフォルトの名無しさん mailto:sage [03/12/15 20:04]
- UCS-2の文字番号をそのまま使う符号化方式もUCS-2と呼んでるんだろう、きっと。
BMP外の文字を使わなきゃUTF-16BEと同じになるのは道理。
UTF-16類とは、サロゲートとBOM位しか違わないんでない？
- 128 名前：デフォルトの名無しさん mailto:sage [03/12/15 22:57]
- UCS2は基本的に内部表現用なのでBE/LEどちらでもUCS2。
完全に実行環境に依存してる。
- 129 名前：デフォルトの名無しさん mailto:sage [03/12/16 00:57]
- iconv使うと実行ファイル+数メガの.so/.dllをくっつけないといかんので困る。
- 130 名前：デフォルトの名無しさん mailto:sage [03/12/16 10:06]
- SJIS←→UCSの変換なんてOSの変換表は
まるで信用できないからなあ
- 131 名前：125 mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [03/12/16 15:59]
- 十数年前はチーズバーガーが１個２３０円だった。
それが、ついこの間まで１個８８円で売っていた。
これはつまり、その気になれば１個８８円で売れたモノを２３０円で売ってた訳だ。
その昔に１個２３０円で食ってたオレに言わせれば全く腹の立つ話だ。
- 133 名前：デフォルトの名無しさん mailto:sage [03/12/16 16:53]
- じゃあたった10MBかそこらのメモリが億単位の値段だったなんて
もう詐欺みたいなものですね
とかコピペにマジレスしてみるテスト
- 134 名前：デフォルトの名無しさん mailto:sage [03/12/19 19:24]
- >>131
好むと好まざるとに関らず、UTF-8 以外は使われなくなってくから
グズグズとそんなこと考えんで宜しい。
１０年後に UTF-16 なんて使ったら洟で笑われるぞ。
- 135 名前：デフォルトの名無しさん mailto:sage [03/12/19 19:35]
- 10年後には UTF-8 すらなくなっていますが。
- 136 名前：デフォルトの名無しさん mailto:sage [03/12/19 20:13]
- Asciiコードは無くなるかなあ？
- 137 名前：デフォルトの名無しさん mailto:sage [03/12/19 20:23]
- >>136
欧州市場はやっぱり無視できないから、新規の実装では使われなくなると思う。
- 138 名前：デフォルトの名無しさん mailto:sage [03/12/19 21:05]
- UTF-8という名のASCII
- 139 名前：デフォルトの名無しさん mailto:sage [03/12/20 00:09]
- UTF-8 って合成を考えると、一文字が最大 12 オクテットになるの??
- 140 名前：デフォルトの名無しさん mailto:sage [03/12/20 05:14]
- >>139 21
- 141 名前：デフォルトの名無しさん mailto:sage [03/12/20 21:50]
- どういう計算をして12オクテットになったのか謎ですが
3文字以上の合成だってあります。
- 142 名前：デフォルトの名無しさん mailto:sage [03/12/22 17:19]
- 合成で気になったんだが、合成の組み合わせと数に制限はあるのか？
例えば、U+306C U+0308 とか、U+0276 U+0328 U+0336 U+030F U+0360 とかは
Unicode文字として規格上正しいもんなのか……？
# 直感的には、明らかに正しくないことはわかってるのだが。
- 143 名前：デフォルトの名無しさん mailto:sage [03/12/22 20:18]
- >>142
JIS X 0221の規格票をざっと眺めた感じでは、制限無しの模様。
- 144 名前：デフォルトの名無しさん mailto:sage [03/12/22 22:38]
- >>142
残念ながらダイアクリティカルマークの
スタック(積み重ね)という概念は実在する
dl2.yukoncollege.yk.ca/ynlc/ynlcfonts/stacking/stacking.html
- 145 名前：デフォルトの名無しさん mailto:sage [03/12/24 13:26]
- >>144
そこのページ雪だるまがいぱーいあって季節的にGood!
- 146 名前：デフォルトの名無しさん mailto:sage [03/12/25 01:44]
- >好むと好まざるとに関らず、UTF-8 以外は使われなくなってくから
ISO C++ではワイドキャラクタはサポートされてますが、
マルチバイトがしっかり動く環境ではありません。
UCS-4マンセー。UCS-4でいいじゃん。
- 147 名前：デフォルトの名無しさん mailto:sage [03/12/25 01:58]
- だったらこの文字ユニファイして領域節約してくれよ
U・C・S!! U・C・S!!
- 148 名前：デフォルトの名無しさん mailto:sage [03/12/25 18:01]
- >>146
とりあえず、意味不明
- 149 名前：デフォルトの名無しさん mailto:sage [03/12/25 18:55]
- 正直utf-16でいい
- 150 名前：デフォルトの名無しさん mailto:sage [03/12/25 20:03]
- 正直utf-16のよさがわからない
- 151 名前：デフォルトの名無しさん mailto:sage [03/12/25 22:56]
- WinXP用ならUTF-16もいいが
他の環境を考えると
- 152 名前：デフォルトの名無しさん mailto:sage [03/12/26 00:58]
- UCS4だよ。一文字32ビット固定でいいやんけ。
- 153 名前：デフォルトの名無しさん mailto:sage [03/12/26 12:55]
- 合成があるってば
- 154 名前：デフォルトの名無しさん mailto:sage [03/12/26 14:13]
- 漢字圏の人間はついついUCS-4で全部解決と
思ってしまうんだよなあ。
- 155 名前：デフォルトの名無しさん mailto:sage [03/12/26 15:06]
- その典型が昔のTRONですね
www.horagai.com/www/den/kanken.htm#04
最近のバージョンでは解決してるの?
- 156 名前：デフォルトの名無しさん [04/01/06 02:05]
- うーん、実態はそんなに単純じゃないんだけどなあ。
TRONの関係者の中にも多言語処理の複雑さを理解している
人たちはちゃんといたよ。昔のweblogをみると多言語の問題と
取り組んで悪戦苦闘している様子がうかがえた。
合成の問題のことは頻繁に話題になっていたよ。
一応TRONでは80年代ごろから多言語処理には
4層構造(言語層、文字属、スクリプト、フォント)で対応する
ということになっていたんだけど、悲しいかな人手不足で
全然研究、ましてや実装は進まなかったんだよ。
今超漢字の販売元は組み込み向けの製品に注力していて、
超漢字にはあまり時間をかけていない様子。改善されているのも
相変わらず漢字処理が中心だよ。明るいニュースはごく最近
SUNがJavaのTRONコードへの対応を約束したことぐらいかな。
まだまだ先の道のりはながいよ。
- 157 名前：デフォルトの名無しさん mailto:sage [04/01/06 20:27]
- > TRONの関係者の中にも多言語処理の複雑さを理解している
> 人たちはちゃんといたよ。
こんなのとか?
www.sumire.sakura.ne.jp/~oguma/tron/btm1999z.html#19991203
漢字がどうしても中心になるのは分からなくもないけどね
使いもしない文字のサポートが強化されたって一般受けしないばかりか
「シリア語ブラクラ」なんて汚名まで被る始末だし
- 158 名前：デフォルトの名無しさん [04/01/08 04:12]
- 思ったんだけど、
わざわざ全ての文字を１つの文字コードに詰め込まなくても、
JIS コードみたいに文字コードの切り替えを行うマークを導入すれば
かなりすっきりするんじゃない？
- 159 名前：デフォルトの名無しさん mailto:sage [04/01/08 04:22]
- その切り替えタグに当たるコードは
どうすれば必要十分で、どういうルールで割り当てていく？
- 160 名前：デフォルトの名無しさん mailto:sage [04/01/08 04:30]
- 仮に一文字２バイトで固定するなら、
文字として使える領域と
切り替えタグにしか使えない領域に分割すれば
いいんじゃない？
- 161 名前：あぼーん mailto:あぼーん [あぼーん]
- あぼーん
- 162 名前：デフォルトの名無しさん mailto:sage [04/01/08 04:44]
- >>158
エスケープ・シーケンス unix で検索しる。
- 163 名前：デフォルトの名無しさん mailto:sage [04/01/08 05:02]
- >>162
Compound Text ってやつ？
なるほど、既にその手のものはあるんですな。
これで問題になることって何があるのかな？
- 164 名前：デフォルトの名無しさん mailto:sage [04/01/08 11:50]
- >>163
まともな処理をするのがめんどうくさい。
- 165 名前：デフォルトの名無しさん mailto:sage [04/01/08 11:58]
- そもそも、プログラミングを容易にするために（＝国際化の容易さに直結）、
シフトを追放しランダムアクセス性を付与することが、
Unicodeの重要目標だったわけで。
- 166 名前：デフォルトの名無しさん mailto:sage [04/01/08 18:45]
- ttp://www.d2.dion.ne.jp/~kuropoo/kanban/shimbun/iwateken.jpg
↑この看板のコウの字がJIS X0208その他の文字集合に見あたらないのですが、
「工」に包摂されているんでしょうか、それとも探し方が悪いのでしょうか……？
- 167 名前：デフォルトの名無しさん mailto:sage [04/01/11 05:54]
- >>166
MacOSX 10.3のヒラギノProに異字体として入ってるから（Stdの方には入ってないし、他のUnicodeフォントにも存在してない）文字集合としてはAdobe-ほげほげ-1.5とか以上でないと
入ってなさそうな感じですね。
印刷物に使うのはかまわないけど、インターネットとかには使えないよという警告がでますな。
- 168 名前：デフォルトの名無しさん mailto:sage [04/01/11 14:54]
- ほうちゃんと警告が出るのか。
つーかちゃんと異体字指定の方法を標準化して
インターネットでも使えるようにしてほしいんだが
- 169 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [04/01/19 08:28]
- >>170
Perlかなんかで作れ。
- 172 名前：デフォルトの名無しさん mailto:sage [04/01/19 08:57]
- >>170
ftp://unicode.org/Public/ のどっか。
- 173 名前：170 mailto:sage [04/01/19 09:24]
- UTF-8 って UNICODE を千切って可変長にねじ込んでるだけだったんだね。
ash.jp/ash/src/codetbl/jis0208.txt
UNICODE <-> JIS X 0208 の変換テーブルは見つかったから、これを使ってやってみるよ。
>171 >172 ありがとう
- 174 名前：デフォルトの名無しさん mailto:sage [04/01/19 14:44]
- 合成なんて、あきらめちゃっていいんじゃないの? 韓国も逃げちゃったし。
既存のコード体系でもしばしば合成を仕様に含めてるけど、まともに利用されてないしさ。
- 175 名前：デフォルトの名無しさん mailto:sage [04/01/19 15:25]
- 漢字なんて、あきらめちゃっていいんじゃないの?
既存のコード体系でもしばしば10万字もの漢字を仕様に含めてるけど(ry
というのに賛成なら別に反対しないけど。
古ハングルは合成で表すことになってるし
実際にそれを実装したフォントも存在する
デヴァーナーガリーやアラビア語のスクリプトは
重ね打ちで処理できない合成が必須
- 176 名前：174 mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [04/01/29 12:40]
- JSP側で日本語と韓国語を同時に使える文字コードを選ぶのは
ものすごく当然だと思うが何に困ってるわけ?
つーか最後の3行日本語になってない
- 180 名前：デフォルトの名無しさん mailto:sage [04/01/29 12:51]
- > つーか最後の3行日本語になってない
韓国語を直訳でもしたんじゃないか?
- 181 名前：デフォルトの名無しさん [04/01/29 18:53]
- VB.NETを使ってるんですが、
日本語文字の自動判別が出来るライブラリってありませんか？
もしくはShiftJISとeucJPを見分ける賢いやり方誰か教えて〜
- 182 名前：デフォルトの名無しさん mailto:sage [04/01/29 18:56]
- Shift_JISとeuc_jpは完全には見分けられないなあ。
- 183 名前：デフォルトの名無しさん mailto:sage [04/01/29 20:42]
- A0 以外の Shift-JIS の半角カナが偶数個あるものは
EUC-JP と区別がつきまそん。
- 184 名前：181 [04/01/29 21:01]
- ありがとうございます。
半角カナが奇数個なら判別可能という事なんでしょうか？
詳しい解説キボン
- 185 名前：デフォルトの名無しさん mailto:sage [04/01/29 21:05]
- 例えば MSB の立っているバイトが奇数個だけ連続している（前後はMSBがゼロ）
場合には EUC-JP ではなさそうだな、ということはいえると思う。
- 186 名前：デフォルトの名無しさん mailto:sage [04/01/29 21:15]
- A1〜DF が２つあるやつは、
Shift-JIS の半角カナ２文字と、
EUC-JP の２バイト文字１文字と、
両方の可能性がある。
でも、奇数個なら Shift-JIS にしかなりえない。
他にも E0〜FC で始まり、A1〜FC で終わる文字も
Shift-JIS か EUC-JP か区別できなかったりする。
- 187 名前：デフォルトの名無しさん mailto:sage [04/01/29 21:41]
- >>185
EUC-JPは補助漢字も考慮に入れる必要があるので、奇数個続く可能性はある。
- 188 名前：デフォルトの名無しさん mailto:sage [04/01/29 21:55]
- 文字コードだけでは区別しにくい場合でも
日本語の文章の場合、「ひらがな」が多く含まれる事が判定の一助になる場合がある。
例えばSJISだと0x81-0x83(だったか忘れたけど)が多いとか。
- 189 名前：デフォルトの名無しさん mailto:sage [04/01/29 22:51]
- ヒューリスティックな方法だけど、いくつかのプログラム
（例えばnkfとfile(file2)とiconv）にそれぞれ判定してもらって、
多数決をとるっていうのはどーだろ？
- 190 名前：デフォルトの名無しさん mailto:sage [04/01/29 23:38]
- UHCもGBKもEUCの上位互換になるような拡張だから
判定ミスで文字化けに悩まされてるのは日本くらいだよなあ
- 191 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [04/02/03 15:27]
- >>193
ぶつからないよ。非ユニコードのマルチバイト系のAPIを使うときは
暗に陽にキャラクターセットが指定されるから、ぶつかりようが無い。
- 195 名前：193 mailto:sage [04/02/03 16:01]
- >>194
そこが凄く知りたいところです。
もっと詳しく教えて下さい。
多国語対応してますが、
Delphi/標準VCLだとASCIIしか受け入れてくれないんですが、
キャラクターセットはどこで指定されるんでしょう。
DBの中身はUTF8で画面入出力時にUTF8ToAnsi/AnsiToUtf8してますが、
画面の入出力で文字化けしたら嫌だな、と思って。
- 196 名前：デフォルトの名無しさん mailto:sage [04/02/03 17:42]
- Windows で ANSI コードページと言った場合、おそらくは GetACP で得られる
コードページ (日本語ロケールなら CP932 のシフトJIS）への変換だと思うのですが、
これはタダの ShiftJIS ですから、JIS にある文字以外は表現できません。
こんなので答えになってるんだろうか・・・
この辺見てみては？
ttp://www.microsoft.com/globaldev/handson/dev/muiapp.mspx
- 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 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [04/02/04 21:14]
- >>199
> （なんか僕が勘違いなどしてるところがあったらズバット指摘してくれてけっこうです）
その質問はスレ違い。
- 201 名前：199 mailto:sage [04/02/04 21:27]
- え、文字コードだからここじゃダメですか？
|
 |
