| 追記です ( No.1 ) |
- 名前：かずお 日時：2011/03/14 15:54
情報が足りなかったと思います、追記します。
ＵＮＩＣＯＤＥ対応にしようとしているソフトは
クイズ形式のもので、外部のテキストファイルに記述されている
問題と答えを、ソフトの中に表示、出題するというものです。
これを北米、ヨーロッパなどのパソコンでも行えるよう、
ＵＮＩＣＯＤＥで保存されたテキストファイルの読み込みを
可能にするということを目的としています。
|
| Re: UNICODE対応 ( No.2 ) |
- 名前：かずお 日時：2011/03/16 20:48
Borland C++Compilerをやめて、visualC++に変えて、
それ用に修正してみると、問題なくコンパイルすることが出来ました。
（でも、それをBorland C++でコンパイルしてみると、やはり同じ症状です。）
そして、visualC++でＵＮＩＣＯＤＥのテキストファイルを読み込んだところ
基本的にはうまくいくのですが、FileRead_eof関数で空っぽのＵＮＩＣＯＤＥのテキストファイル
を読み込んだときに、具体的には下のプログラムで、ＡＮＳＩのテキストファイル
の場合にはＥＯＦを読み込んでwhile文に入らずにそれ以降に進むのですが、
ＵＮＩＣＯＤＥのテキストファイルの場合には、ＥＯＦを判別していないのかwhile文の中に進み、
MAXがインクリメントされてしまいます。
while(!FileRead_eof(FileHandle) && MAX<=30)
{
FileRead_gets(Str_d,12,FileHandle) ;
kyori[MAX] = _ttoi(Str_d) ;memset(Str_d,0,sizeof(Str_d));
FileRead_gets(String,256,FileHandle) ;
_stprintf(txt[MAX],_T("gra/%s"),String);memset(String,0,sizeof(String));
MAX++;
}
もしかするとFileRead_eof関数をＵＮＩＣＯＤＥで使用した場合に発生する
問題である可能性もあるのではないかとも思ったのですが、
なにぶんＣ言語もＤＸライブラリもまだまだ理解が足りないので
お分かりになる方がいらっしゃいましたら、教えていただけたらと思います。
よろしくお願いいたします。
|
| Re: UNICODE対応 ( No.3 ) |
- 名前：かずお 日時：2011/03/16 23:23
最後まで一人相撲でしたが、FileRead_eofはあきらめて
変数のkyoriが_ttoiで数字になるのを利用して、
if(!isdigit(kyori[MAX])){break;}
を４行目に加えてwhile文からエスケープすることにしました。
|
| Re: UNICODE対応 ( No.4 ) |
- 名前：いっち 日時：2011/03/17 00:22
FileRead_eof の動作がマルチバイトの場合とUNICODEの場合で異なるのは、
ＤＸライブラリのバグである可能性があるので管理人さんの見解をお待ちするのが良いと思います。
|
| Re: UNICODE対応 ( No.5 ) |
- 名前：かずお 日時：2011/03/17 07:33
No.3の方法は間違いでした。
修正してとりあえず個人的には解決しました。
マルチバイトの時はBorland C++Compilerをつかっていたので
あらためてＵＮＩＣＯＤＥと同じくvisualC++を使い、比較しました。
プログラムをマルチバイトにもどして、visualC++でコンパイルして、
読み込むテキストファイルを中身は変えずに（空のまま）ＡＮＳＩで保存すると
やはりちゃんとＥＯＦを認識しているようなので
ＵＮＩＣＯＤＥの時と動作が違うように思えます。
でも、自分がバカなだけかもしれません・・・
|
| Re: UNICODE対応 ( No.6 ) |
- 名前：いっち 日時：2011/03/17 20:24
FileRead_open 直後に FileRead_eof を行う実験をしてみました。
BOMのみのファイルの場合(2バイト) ... 戻り値は偽
BOMも無い完全な空ファイルの場合(0バイト) ... 戻り値は真
FileRead系関数は基本的にテキストファイルのみを扱う前提ではないので上記の結果はおそらく仕様だと思います。
(FileRead_gets、FileRead_getc、FileRead_scanf のみテキストファイル前提のはず)
ただ、EOFのもともとの出自がテキストファイル用のマーカーだったと思うので、
「FileRead_eof もテキストファイル前提で動作すべき」と言われると私には判断できません。
対策としてはかずおさんの場合、FileRead_eof を使わずに FileRead_gets の戻り値を監視して、
１文字以上読み込めた場合とそうでない場合で処理を分岐させてはどうでしょうか？
|
| Re: UNICODE対応 ( No.7 ) |
- 名前：かずお 日時：2011/03/17 21:44
いっちさん、本当にありがとうございます！
実はNO.5で個人的には解決と書きましたが、またそれも
不完全であるとわかり、悩んでいたところです。
if(FileRead_gets(String[i],42,FileHandle)<1){break;}
でエスケープする形にして今度こそ本当に解決しそうです。
FileRead_eofについては、やっぱり仕様なのでしょうか、
あのあと、FileRead_eofを使わずにＣ言語の
ファイル読み書きの関数を使って試した時に、
FileRead_eofを使った時と同じ症状が出たので
もしやとは思っていました。
ＢＯＭというやつがあるせいでＥＯＦがファイルの冒頭にあるときに
それ以前にＢＯＭがあるのを検知してwhile内に入ってしまう
ということなのですね。
すごく勉強になりました。ありがとうございました。
|
| Re: UNICODE対応 ( No.8 ) |
- 名前：管理人 日時：2011/03/21 17:26
> FileRead_eofについては、やっぱり仕様なのでしょうか、
はい、仕様となります
ご返答が遅くなり申し訳ありません
一応 UNICODEテキストファイルが前提でしたら、UNICODEテキストファイルを FileRead_open で開いた直後に
FileRead_seek( FileHandle, 2, SEEK_SET ) ;
として２バイト目に読み込み位置を移動すれば最初の FileRead_eof で TRUE が返ってくるようになります
|