私はそれに気づき、OS X 10.8 で非推奨になりましたFSPathMakeRef()
。FSRefMakePath()
それらを使用してパスの正規のケースを見つけるコードがあります。たとえば、「/USeRs」を渡すと「/Users」が返されます。
これらの関数やその他の関連する関数が非推奨になったのはなぜですか? また、同等の機能を提供するために、非推奨でない API を代わりに使用する必要があるのはなぜですか?
私はそれに気づき、OS X 10.8 で非推奨になりましたFSPathMakeRef()
。FSRefMakePath()
それらを使用してパスの正規のケースを見つけるコードがあります。たとえば、「/USeRs」を渡すと「/Users」が返されます。
これらの関数やその他の関連する関数が非推奨になったのはなぜですか? また、同等の機能を提供するために、非推奨でない API を代わりに使用する必要があるのはなぜですか?
NSURL
通常のパスとファイル参照パスの両方を格納するために使用します。
ファイル マネージャーのドキュメント(付録 A: 非推奨のファイル マネージャー関数) から:
FSMakeFSRefUnicode
親ディレクトリと Unicode 名を指定して、ファイルまたはディレクトリの FSRef を構築します。(OS X v10.8 では廃止されました。代わりに NSURL または CFURL API を使用してください。ファイル システム アイテムの動作を ID で追跡するには、fileReferenceURL または CFURLCreateFileReferenceURL を使用してファイル参照 URL を作成します。)
私が知る限り、Apple はこのFSRef
タイプを完全に廃止することを選択し、代わりにファイル参照 URL (のように見えるfile:///.file/id=6571367.39068/
) を優先しました。
文字列パスを正規化する場合は、廃止されていない API を使用して次のことを行うことができます。
NSString *canonicalPath = [[[NSURL fileURLWithPath:@"/USeRs"] fileReferenceURL] path];