Obj.C

obj.C:トホホ @”\n”

改行@”\n”は1文字だったのですね!!

アプリが定めたデフォルトのファイルパスをユーザーがあとから変更できるように設定値を.txtファイルにしてsaveし、これを読み込む仕様にしました。

ファイルパスの区切りを改行にして、.txtファイルを開けたときに見た目にもわかりやすくしました。言うまでもないことですが、リストアするには、saveしたファイルを読み込み、改行までの文字列をファイルパスとして取り出す必要があります。

しかし、ここが問題のはじまりでした。@”\n”を2文字だと決めつけてファイルパスの文字列を取り出していたのですが、改行@”\n”は1文字の文字コードなのですね?だったら、1文字に見えるようにしてほしかった・・・。

何回やっても、1文字ずつ取り出しているのに、いっぺんに2文字が入って来ます。そもそも、if文で改行@”\n”かとif ([[mcWriteBuffer substringWithRange:NSMakeRange(R0,2)] isEqual:[[NSMutableString alloc]initWithFormat:@”\n”]])聞いているのに、全くYESになりません。おかしいでしょう。

それで、ログを取ったら、1文字として入って来ました。

言い訳。頭の中がバイナリが基本になっていると、英数特殊文字は1バイト、制御コードは別のコード体系と分かれてしまいますが、そもそも文字コード表がどうなっているのかから理解しないと、こうしたまちがいは再発しそうな気がします。

大昔、はじめてCobolで某百貨店のシステムを開発したとき、整数の計算にバイナリを使わないで、パックや1バイトコードの文字列を使うのがCobolの基本構造のひとつだと知ったとき、本当にびっくりしたのですが、この改行@”\n”にもたいへん驚きました。いや、本当にびっくりしました。

こんなところで引っかかるのは、全く想定外でした。

先のisEqual:と合わせて、このイッシューについての再確認が取れたら、追記でupdateするようにします。もう、まちがっていないことを願います。

追記1:はい。その通り改行@”\n”は1文字でした。文字列は、NSMutableStirngでハンドリングしています。

追記2: 右辺が常数のとき、==でもいいような気がしますが、isEqual:に変えたので真偽の確認はしていません。いつか、必ず再確認が必要です。

追記3: ファイルの読み込みバッファを使い回ししているのですが、[self ExecReadTextFile:readBuffer filepath:txtFilepath];のような形式では、呼び出し元でうまく参照できない現象がでた(ような気がした)ので、readBuffer = [self ExecReadTextFile:readBuffer filepath:txtFilepath];と返り値でも設定することにしました。これも、いずれ必ず再確認が必要です。これは先の==の問題と違い、BOOLでチェックしたいとき、返り値を複数設定する方法をわかっていないからです。

追記4: XCode 5.1にupdateしました。特に問題はありません。

ここまでで、NSTableView (NSMutableTable)に設定した情報をファイルにsaveし、アプリ終了後、アプリを再起動、関連ファイルをrestoreして以前のアプリの状態を引き継いで表示するところまで作り込みが完了しました。デバッグが完全に終わっていませんので、今後、不具合を直すことになります。アプリは暴走しないのですが、restoreの復元が不完全か、restore後の手順に不具合があるようです。

Categories: Obj.C, 技術

Tagged as: