とか、
ls ~
ってやると、

ホームディレクトリになんかかんか出来るのだと思う。

 

まあ、linuxとOS Xしかお知り合いじゃないんだけど。

 

 

 

cocoaなことをしているときに

これを応用出来ないかと思った。

 

 

 

要するに

NSString* home = [@"~" stringByExpandingTildeInPath];

みたいな。

 

 

久しぶりに書いたと思えばなんと短い。

 

あるディレクトリの奥の奥の奥にある。

そんなファイルをロードしたい。

初夏の夜。

 

ファイルサイズを取得して、

そのぶんだけメモリを確保。

んで、そこにむいてファイルから、

リードリードリード。

 

 

オーバーフロー！！

 

ん？なんでだろ。

 

処理を極限まで減らす。

ファイルから読み込みを無くした時点で、

エラーは出なくなる。

 

 

読み込みがやっぱ悪い。

 

 

んー。ファイルサイズで取得した分しか、

ファイルのサイズはないわけなんで、

教えてもらったファイルサイズだけメモリを確保すればいいはず。

 

 

ちなみにファイルサイズを知る方法。

NSDictionary *result = [manager attributesOfItemAtPath:path error:&error];

で得たDictionaryにはfileSizeってイベントを送ってもいいらしいんですな。

unsigned long long resultSize = [result fileSize];

 

 

 

 

 

さて。エラーのおこるやつ。

ファイルサイズなんぼじゃ。

 

/Users/dev/Documents/backup/dmGet/build/Debug/dmGet.app/Contents/Plugins/ITunesCommunication.plugin/Contents/Resources/lib/python2.6/site.py

 

こんなおくのおくのおくにあるファイル。
枠からはみ出ているだろうが気にしない。

サイズは13。

 

そんなばかな。

site.py書いたの私だけど、13文字で書いた覚えは無い。

 

Finderで調べると、3042。

 

 

おっとー？

 

 

ファイルサイズの別の求め方として、

cの標準関数が使えるのならば。

前にlinuxでなんかを書いたとき、

statとかを使った気がする。

 

struct stat buf;    /* ファイル情報の格納領域 */

size_t debug = 0;

    if ((stat([path UTF8String], &buf)) == 0) {

debug = buf.st_size;

    }

 

まあ、ちょいとこんな感じで。

で、どうなったかというと、

 

 

 

＊attributesOfItemAtPath:error:の結果＊

2010-06-12 23:12:57.672 crepe[44602:903] image:14df5b30 size:13 pt+n:14df5c30 name:/Users/dev/Documents/backup/dmGet/build/Debug/dmGet.app/Contents/Plugins/ITunesCommunication.plugin/Contents/Resources/lib/python2.6/site.py

Current language:  auto; currently objective-c

 

“result”の説明を出力中：

{

    NSFileCreationDate = "2010-05-01 21:15:52 +0900";

    NSFileExtensionHidden = 0;

    NSFileGroupOwnerAccountID = 20;

    NSFileGroupOwnerAccountName = staff;

    NSFileHFSCreatorCode = 1919443312;

    NSFileHFSTypeCode = 1936485995;

    NSFileModificationDate = "2010-05-01 21:15:52 +0900";

    NSFileOwnerAccountID = 503;

    NSFileOwnerAccountName = dev;

    NSFilePosixPermissions = 493;

    NSFileReferenceCount = 1;

    NSFileSize = 13;←＊＊＊ここ＊＊＊

    NSFileSystemFileNumber = 2854447;

    NSFileSystemNumber = 234881026;

    NSFileType = NSFileTypeSymbolicLink;

}

 

うそつき。

 

 

 

＊statの結果＊

デバッガで見た。

debugの値は3042。

正解。そのとおり。

 

 

なんなんかなぁ。

わたし、なんかしたっけかなぁ。

 

 

 

とりあえず、statで問題をよけるぞ。

 

テキストファイルからテキストをメモリに読み取ってあるのなら、

stringWithCString:encodingを使えば、

そのメモリ領域にあるデータからNSStringを作成できると思った。

 

私の場合、encodingについては既に割れているので、

それを引数にstringWithCString:encodingを使う。

 

 

らくちんぽん。とおもいきや。

 

 

UTF-16でどうもうまくいかない。
 

ん？こいつどうやってUTF-16の終端を判断してるんだ？

とおもった。

長さを渡していないので、

終端を表す何かが必要なはず。

 

UTF-16でASCII文字を使うと、１バイト分データの空きが出る。

そう。そこはヌル文字。

なので、ほかの文字列と同じようには

UTF-16ではヌル文字で終端を表せない。

２バイト連続ヌル文字を使えばいいのだろうけど、

そんな話は聞いたこと無い。

ちなみにやってみたけど駄目。


 

unicharの配列だと可能だろうけど、

stringWithCStringはふつうにcharの配列を受け取るから。

 

もし、stringWithCString:encoding内部で、

ヌル文字を終端として扱っているなら、

このメソッドではUTF-16は扱えないように思えた。

 

 

そんななかにもかすかな光が。

 

 

stringWithCString:length:は長さが指定できる。

そして、試したところBOM無しのリトルエンディアンUTF-16も

同様にBOM無しのビッグエンディアンUTF-16もちゃんと読み込めた。

 

ん？Deprecated in Mac OS X v10.4？

あ。自分、英語読めませんのですいませんが。

 

 

なんか光が消えた。

 

 

そんななかにもかすかな光が。

 

 

stringWithCharacters:length:というメソッドがある。

引数にconst unichar *と長さが渡せる。

 

もう。いかにもいけそうな予感。

 

結論から言うといける。

ビッグエンディアンなら。

リトルエンディアンのときはBOMをつけてもだめ。

んもー。またぐちゃぐちゃ。

 

 

あー。なんならスワップしますけど、します？

 

 

またもや、そんななかにもかすかな光が。

 

 

initWithBytes:length:encoding:というメソッドがあった。

長さもエンコードも指定できる。

ええんよ、ええんよ。

どっちもわかってるから。

ちゃんと動いてくれれば。

 

．．．

動いた！

 

 

えっと。クラスメソッド版は無いんですね．．．

allocしなきゃだめですか。

 

 

そうですか。