StandardPaths 1.6.7

StandardPaths 1.6.7

×

测试已测试✗
lang语言 Obj-CObjective C
许可 NOASSERTION
发布最新发布2019年10月

由Nick Lockwood维护。

StandardPaths 1.6.7

  • 由
  • Nick Lockwood

目的

iOS 和 Mac App Store 对文件存储位置有非常严格的要求，但有时候并不清楚正确的位置在哪里。自 iOS 5.0 以来，情况变得更加复杂，因为需要确保某些文件不会被备份到 iCloud，或者设备空间不足时不会被清除。

此外，由于 Retina 显示和混合应用的出现，通常很难确定图像或 nib 等资源的正确文件路径，因为这些文件在不同的设备上可能有不同的后缀，如 @2x 或 ~ipad，尽管许多 iOS 和 Mac OS API 可以自动管理这些后缀，但方法并不一致且不透明。

对 -568h 文件后缀的支持也很有限，只能针对 iPhone 5 的启动图像，通常不支持加载图像、nib 文件等。

StandardPaths 提供了一系列 NSFileManager 扩展方法，可用于跨平台以清晰和一致的方式访问文件，并抽象了在 iOS 5 及以上版本应用移动备份属性以禁用 iCloud 备份的复杂性。

此外，StandardPaths 还提供了一些 NSString 扩展方法来操作 Retina 图像、iPhone 5 以及设备固有（手机/平板/桌面）的后缀，以简化特定设备资源的加载。

最后，StandardPaths 通过重写 UIKit 和 AppKit 的一些方法，使得它们在加载特定设备资源时具有额外的智能。这使得您可以根据文件后缀而不是丑陋的运行时代码检查显示大小来加载正确的图像和 nib 文件。如果愿意，可以禁用这种重写（详情见下文）。

支持的操作系统 & SDK 版本

  • 支持的构建目标 - iOS 11.2 / Mac OS 10.12（Xcode 9.2）
  • 最早支持的部署目标 - iOS 8.0 / Mac OS 10.11
  • 最早兼容的部署目标 - iOS 7.0 / Mac OS 10.7

注意：“支持”意味着库与该版本进行了测试。“兼容”意味着库应在该操作系统版本下工作（即它不依赖于任何不可用的 SDK 功能），但不再进行兼容性测试，可能需要调整或错误修复以正确运行。

ARC 兼容性

StandardPaths 与 ARC 和非 ARC 项目都兼容。无需从 ARC 验证过程中排除 StandardPaths 文件，也不需使用 ARC 转换工具转换 StandardPaths。

线程安全

您可以从任何线程安全地调用 StandardPaths 方法。

安装

要在项目中使用 StandardPaths，只需将 StandardPaths.h 和 .m 文件拖入项目中。没有依赖项。

NSFileManager 扩展方法

StandardPaths 扩展 NSFileManager，提供一系列有用的标准目录。大多数方法提供两种版本，一种是只返回目录路径的版本，另一种是返回目录中特定文件名或路径片段的路径的版本。为了简洁，以下文档中这些方法被配对在一起。

- (NSString *)publicDataPath;
- (NSString *)pathForPublicFile:(NSString *)file;

返回用户《文档》文件夹的路径。在iOS上，这是存储用户创建的文档的好地方。您可以通过将应用程序的Info.plist中的UIFileSharingEnabled设置为YES，使这些文档可通过iTunes供用户访问。因此，将私人应用程序数据文件存储在《文档》文件夹中并不是一个好主意，因为这样会失去灵活性。您应该将这些文件存储在Library/Application Support中。注意，Mac App Store的沙箱规则禁止在没有请求用户明确许可的情况下访问《文档》文件夹中的文件。

- (NSString *)privateDataPath;
- (NSString *)pathForPrivateFile:(NSString *)file;

返回iOS上Library/Application Support的路径，或在Mac OS上返回Library/Application Support/<AppName>的路径，并在不存在时创建它。这是一个存储应用程序数据文件的好地方，这些数据文件不是用户可编辑的，因此不应存储在《文档》文件夹中。

- (NSString *)cacheDataPath;
- (NSString *)pathForCacheFile:(NSString *)file;

返回应用程序《库/缓存》文件夹的路径。在Mac OS上，该路径将包括一个以应用程序的捆绑ID命名的子文件夹，以防止命名空间冲突。如果您的应用程序从互联网下载数据或缓存昂贵的计算结果，请在此处存储结果。在iOS 5及以上版本中，当设备空间不足时，这些文件将被自动删除，因此如果数据很重要，您应该使用offlineDataPath来存储它。

- (NSString *)offlineDataPath;
- (NSString *)pathForOfflineFile:(NSString *)file;

返回iOS上Library/Application Support/Offline Data的路径，或Mac OS上Library/Application Support/<AppName>/Offline Data的路径，并在不存在时创建它。这不是一个标准定义的路径，但它是存储不希望自动删除的缓存文件的安全地方。在iOS 5.0.1中，此文件夹设置了com.apple.MobileBackup属性，以防止它自动备份到iCloud。此标志在iOS 5.1中已被弃用，因此当为5.1及以上版本编译时，使用新的API。这些机制在iOS 5.0.1之前不可用，因此iOS 5.0的用户会发现这些文件已同步到他们的云端空间。StandardPaths库的先前版本将离线数据文件存储在《库/缓存》中，但这对从iOS 4/5升级到5.0.1的用户来说可能是不必要的麻烦，因此从版本1.1开始，offlineDataPath不再这样做。

- (NSString *)temporaryDataPath;
- (NSString *)pathForTemporaryFile:(NSString *)file;

返回临时数据文件夹的路径。这是一个存储临时文件的好地方，例如在某个复杂过程中，数据无法全部适合内存的情况下。存储在此处的文件可能会在应用程序关闭时或当设备内存不足时自动删除，但在您完成时自行删除它们是个好主意。

- (NSString *)resourcePath;
- (NSString *)pathForResource:(NSString *)file;

返回应用程序资源文件夹中文件的路径。这基本上会将[[NSBundle mainBundle] resourcePath]映射。此文件夹中的文件是只读的。请注意，与[[NSBundle mainBundle] pathForResource:ofType:]方法不同，如果文件不存在，则pathForResource:不会返回nil。

- (NSString *)normalizedPathForFile:(NSString *)fileOrPath;
- (NSString *)normalizedPathForFile:(NSString *)fileOrPath ofType:(NSString *)ext;

此方法接受一个文件名或路径，并通过执行以下操作进行规范化

  1. 它可以将一个路径片段或文件名转换为完整路径，通过前缀应用程序捆绑资源路径。其次，它复制Mac OS和iOS查找不同版本的资源文件的行为，例如@2x图像文件或以~ipad或~iphone结尾的文件（并添加一个~mac扩展选项以实现跨平台一致性）。

  2. 它支持iPhone 5 "-568h"后缀，用于专为更高分辨率屏幕设计的文件。除了默认的.png启动图像外，苹果并没有提供其他内置对该后缀的支持，但是normalizedFilePathForFile:方法可以检测并使用带有此扩展名（带或不带@2x）的任何文件，在iPhone 5上运行时，会优先使用这些文件，而不是不带后缀的同名文件。这对于自动加载iPhone 5特定的图像和nib文件非常有用，而且不需要编写难看的运行时代码检查。

  3. 它实现了Cocos2D -hd后缀伪标准，用于表示适用于Retina iPhone和标清iPad/Mac的图像文件。这允许你使用相同的代码库支持2个或3个平台，而不必在应用中使用重复的图像。

  4. 它正确地将.png图像路径映射到在Mac OS 10.7+上用于将标准分辨率和Retina分辨率图像合并到单个文件中的多页HiDPI TIFF文件。

这些行为适用于任何文件，而不仅仅是图像或nib文件，因此如果你想加载特定于设备的nib文件、3D模型或OpenGL应用程序的着色器而无需编写大量分支代码时，它非常有用。与其他NSFileManager扩展方法不同，此方法如果文件不存在，则返回nil。此方法调用多个文件系统调用，因此第一次调用每个路径时可能相对较慢。但是它会对给定的输入缓存结果，所以下次调用会更快。有关更多信息，请参见下面的“图像文件后缀”部分。

该方法的ofType:形式可以接受一个可选文件扩展名，如果文件已经包含扩展名，则将忽略它。与内置的[[NSBundle mainBundle] pathForResource:ofType:]方法不同，如果文件已经有类型，则忽略扩展名。

NSString扩展方法

StandardPaths扩展了NSString，并添加了一些额外的用于通过添加、删除和检索标准或伪标准路径扩展名来操作文件路径的方法，这些扩展名用于Retina分辨率图像和特定于设备的资源。有关更多信息，请参见下面的“图像文件后缀”部分。

- (NSString *)stringByReplacingPathExtensionWithExtension:(NSString *)extension;

此方法将字符串路径扩展名替换为指定的值。

- (BOOL)hasPathExtension;

此方法返回YES，如果字符串有路径扩展名。

- (NSString *)stringByAppendingPathSuffix:(NSString *)suffix;

此方法用于将后缀追加到文件路径上。它与stringByAppendingString:方法类似，但它会自动确保如果字符串有文件扩展名，则后缀插入在扩展名之前。

- (NSString *)stringByDeletingPathSuffix:(NSString *)suffix;

此方法从字符串中删除指定的后缀（如果存在），而不会干扰文件扩展名。

- (BOOL)hasPathSuffix:(NSString *)suffix;

此方法返回YES，如果字符串有指定的后缀。这与hasSuffix:方法不同，因为它在执行检查之前会从文件路径中移除文件扩展名。

- (NSString *)stringByAppendingSuffixForInterfaceIdiom:(UIUserInterfaceIdiom)idiom;

此方法将适用于指定-idiom常量的适当后缀字符串（SPPhoneSuffix、SPPadSuffix或SPDesktopSuffix）追加到字符串中。如果字符串包含文件扩展名，后缀将正确插入在文件扩展名之前。有关更多信息，请参见下面的“图像文件后缀”部分。

- (NSString *)stringByAppendingInterfaceIdiomSuffix;

此方法将当前设备的用户界面idiom后缀（~ipad、~iphone或~mac）追加到字符串中。如果字符串包含文件扩展名，后缀将正确插入在文件扩展名之前。有关更多信息，请参见下面的“图像文件后缀”部分。

- (NSString *)stringByDeletingInterfaceIdiomSuffix;

此方法如果存在，则从字符串中删除用户界面idiom后缀，如果未发现后缀则不执行任何操作。

- (NSString *)interfaceIdiomSuffix;

此方法如果找到则返回用户界面语法的后缀，否则返回@""。

- (BOOL)hasInterfaceIdiomSuffix;

此方法如果字符串包含接口语法的后缀则返回YES。

- (UIUserInterfaceIdiom)interfaceIdiomFromSuffix;

此方法返回由文件接口语法的后缀指定的UIUserInterfaceIdiom值（如果找到的话）。如果没有找到后缀，则返回当前设备的语法定义。UIUserInterfaceIdiom属于UIKit，在Mac OS上未定义，因此StandardPaths在Mac OS上定义了这些常量，并添加了一个额外的UIUserInterfaceIdiomDesktop常量来表示Mac OS的桌面语法定义。此实现与Chameleon iOS-Mac转换库使用的实现兼容，因此您应该能够在两个库一起使用。

- (NSString *)stringByAppendingSuffixForScale:(CGFloat)scale;

此方法将标准比例后缀追加到字符串。例如，如果传递的缩放值为2.0，则该方法将在字符串后追加@2x。此方法正确处理文件扩展名和设备类型后缀，因此如果存在，@2x将插入到文件扩展名或设备类型后缀之前。有关更多信息，请参阅以下“图像文件后缀”部分。

- (NSString *)stringByAppendingDeviceScaleSuffix;

此方法将当前设备比例适当的后缀追加到字符串。目前，这意味着Retina iPhone的@2x后缀或@3x后缀，或对于非Retina设备没有后缀。此方法正确处理文件扩展名和设备类型后缀，如果存在，则@2x将插入到文件扩展名或设备类型后缀之前。有关更多信息，请参阅以下“图像文件后缀”部分。

- (NSString *)stringByDeletingScaleSuffix;

此方法从一个文件路径中移除@2x（或任何其他比例因子）后缀，如果后缀未找到则不执行任何操作。

- (NSString *)scaleSuffix;

如果找到则返回比例因子后缀，如果没有找到则返回空字符串。

- (BOOL)hasScaleSuffix;

如果字符串包含@xx缩放后缀返回YES，否则返回NO。

- (NSString *)stringByAppendingSuffixForHeight:(CGFloat)height;

此方法将屏幕高度后缀追加到字符串。例如，如果传递的高度值是568，则此方法将在字符串后追加-568h。此方法正确处理文件扩展名和设备类型后缀，如果存在，则-568h将在@2x缩放后缀或设备类型后缀之前插入。有关更多信息，请参阅以下“图像文件后缀”部分。

- (NSString *)stringByAppendingDeviceHeightSuffix;

此方法将当前设备的适当后缀追加到字符串。目前，这意味着如果设备具有Retina显示屏则返回@2x后缀，否则不返回后缀。此方法正确处理文件扩展名和设备类型后缀，如果存在，则@2x将插入到文件扩展名或设备类型后缀之前。有关更多信息，请参阅以下“图像文件后缀”部分。

- (NSString *)stringByDeletingHeightSuffix;

此方法从文件路径中移除-568h（或任何其他高度）后缀，如果后缀未找到则不执行任何操作。

- (NSString *)heightSuffix;

如果找到则返回比例因子后缀，如果没有找到则返回空字符串。

- (BOOL)hasHeightSuffix;

如果字符串包含-xxxh高度后缀返回YES，否则返回NO。

- (NSString *)stringByAppendingHDSuffix;

此方法将-hd后缀追加到字符串以指示Retina iPhone或大屏幕设备，如iPad或Mac。有关更多信息，请参阅以下“图像文件后缀”部分。

- (NSString *)stringByAppendingHDSuffixIfDeviceIsHD;

如果设备是Retina显示屏的iPhone或iPad或Mac，则此方法将-hd后缀追加到字符串，如果不是则不执行任何操作。有关更多信息，请参阅以下“图像文件后缀”部分。

- (NSString *)stringByDeletingHDSuffix;

如果在字符串中找到-hd后缀，则此方法将其删除，如果后缀未找到则不执行任何操作。

- (BOOL)hasHDSuffix;

如果字符串包含-hd后缀返回YES，否则返回NO。

- (CGFloat)scaleFromSuffix;

此方法以浮点数形式返回文件路径的图像比例，例如，如果文件包含-hd后缀（仅适用于iPhone）或@2x/@3x后缀，则返回2.0，如果没有后缀，则返回1.0。它还可以正确解析非标准的比例后缀，如@1.5x等。

- (CGFloat)heightFromSuffix;

此方法返回文件路径所对应的屏幕高度值，作为一个浮点数，例如如果文件包含一个-568h后缀（仅在iPhone上），则返回568，如果没有后缀，则返回0.0。它还可以正确解析非标准的后缀，例如iPhone 6的-667h，iPhone 6+的-736h等。

UIKit swizzling

默认情况下，StandardPaths会对一些UIKit和AppKit的方法进行swizzling，使其实现的一些伪标准更加简单和自动。如果您不希望有这种行为，别担心，您可以通过在构建设置中添加以下预处理器宏来禁用它：

SP_SWIZZLE_ENABLED=0

或者，如果您愿意，可以将其添加到您的文件中：

#define SP_SWIZZLE_ENABLED 0

不过，在这样做之前，请放心，StandardPaths所执行的swizzling是最小化和相当安全的。它总是调用原始的swizzled方法，仅仅作为插入一些额外智能的缓冲。它不会破坏UIImage缓存，也不会造成其他一些解决方案中的一系列坏影响。

被swizzled的方法如下：

[UIImage -initWithContentsOfFile:];
[UIImage +imageNamed:];
[NSImage -initWithContentsOfFile:];
[NSImage +imageNamed:];

这些方法被swizzled以自动支持带有-hd和-568h后缀的图像。有关详细信息，请参阅图像文件后缀部分。

[NSBundle -loadNibNamed:owner:options:];
[UINib -nibWithNibName:bundle:];
[UIViewController -loadView];

这些方法都是出于同样的原因被swizzled的：为了自动加载在iPhone 5上后缀为-568h的nib文件，节省您在运行时进行检查所需的麻烦。

图像文件后缀

Mac OS和iOS通过使用文件后缀来管理多个版本的资源，这种方式很聪明。第一代iPad引入了ipad后缀来指定文件的iPad特定版本（例如fooipad.png）。iPhone 4引入了@2x后缀来管理Retina显示的双分辨率图像（例如[email protected]）。第三代iPad可以将这些后缀结合起来，以拥有Retina质量的iPad图像（例如foo@2x~ipad.png）。从Mac OS 10.7开始，同样的@2x图像命名也适用于Retina Mac，尽管在Mac OS中还实行了一套次要的惯例，其中标准分辨率的图像和@2x图像被合并到一个单独的多页HiDPI TIFF文件中。iPhone 6+引入了@3x Retina，等等。

这种文件命名约定对于应用程序来说是一种优雅的解决方案，但有时对于游戏来说是不足够的，因为与游戏不同，混合游戏通常在iPhone、iPad和Mac上使用几乎完全相同的外观界面，资源元素只是简单地放大，这意味着标准定义iPad/Mac和Retina分辨率的iPhone需要使用相同的图像。

使用@2x或@3x后缀为图像命名对Retina iPhone有用，但对标准分辨率的iPad或Mac则不行；使用~ipad后缀对iPad有用，但对iPhone则不行，这迫使您不得不分别以不同的文件名重复相同的资源，或者编写自己的文件加载逻辑。

-hd后缀是由Cocos2D库为了解决想要同时为iPhone Retina显示和iPad标准定义显示使用相同2x图形的问题而引入的解决方案，就是对两个显示都使用相同的-hd文件名后缀。

-568h后缀是在iPhone 5中引入的，以支持高度为568点（1136像素）的默认.png启动图片，而不是常规的480点。StandardPaths扩展了这个约定，使其适用于所有文件。它通常用于图像，因为iPhone 5具有视网膜显示屏，因此应该与图像的@2x缩放后缀结合使用，以便以正确的比例加载。但是，与所有其他后缀一样，StandardPaths也支持与其他文件类型（例如，nibs，后缀的附加@2x部分在不属于图像资源时不使用）一起使用此后缀。iPhone 6和6+引入了两种新的屏幕尺寸，未来可能有更多，因此StandardPaths支持高度值的任何任意尺寸。

StandardPaths通过向NSString添加一些实用方法来支持此解决方案，以便在调用normalizedFilePath:方法时自动将此后缀应用于文件路径。使用@2x、@3x、ipad、-hd和-xxxh约定（或任何组合）的文件将自动检测并按适当的方式进行加载。例如，如果您传入名为foo.png的图像文件，StandardPaths将自动在视网膜iPhone上查找或fooipad.png或foo-hd.png，或者如果您使用的是视网膜iPad，还将找到类似的东西。为了确保跨平台一致性，StandardPaths还通过引入~mac后缀，并将Mac与iPad以相同的- hd后缀对待来扩展这些概念。它还会根据需要查找多页HiDPI TIFF文件替换。

注意：默认情况下，StandardPaths还通过混淆各种UIKit方法来使使用- hd和- 568h后缀的nibs和图像加载尽可能无缝。如果您不想让StandardPaths干预UIKit类的行为，只需将SP_SWIZZLE_ENABLED=0添加到项目的编译设置中项目预处理器宏即可。

使用方法

只要您包含了StandardPaths.h文件，您就可以在NSFileManager的任何实例上调用上述任何方法。例如，如果您想要获取应用程序缓存文件夹中名为“Foo.bar”的文件路径，您可以写以下任何一个

NSString *path = [[NSFileManager defaultManager] pathForCacheFile:@"Foo.bar"];
NSString *path = [[[NSFileManager defaultManager] cacheDataPath] stringByAppendingPathComponent:@"Foo.bar"];

要获取应用程序包内的标准化文件路径，您只需使用文件名，例如

NSString *path = [[NSFileManager defaultManager] normalizedPathForFile:@"Foo.png"];

要获取不在应用程序包内的标准化文件路径，您可以使用绝对文件路径，或者使用其他方法在规范之前将路径转换为绝对路径，例如

NSFileManager *manager = [NSFileManager defaultManager];
NSString *path = [manager normalizedPathForFile:[manager publicDataPath:@"Foo.png"]];

请注意，应用程序包之外的文件查找不进行缓存（因为文件没有更改），因此对于这些文件使用normalizedPathForFile:会更耗CPU。如果您多次访问相同的文件，您可能希望自己缓存路径而不是多次调用此方法。

除非您已禁用swizzling使用SP_SWIZZLE_ENABLED宏，否则StandardPaths将自动处理.jpg或-568h后缀的图像和nibs的加载，因此您无需做任何特殊操作来加载这些文件。

如果您已禁用swizzling或您想操作非文件路径字符串，如信息字典键或nib文件名，您可以使用NSString扩展方法。例如，如果您想在iPhone 5上获取特定于设备的nib文件名，您可以这样做

NSString *infoDictionaryKey = @"resourceName";
if ([UIScreen mainScreen].bounds.size.height >= 568)
{
	infoDictionaryKey = [infoDictionaryKey stringByAppendingDeviceHeightSuffix];
}

在iPhone 4上这会返回"resourceName"，在iPhone 5上则返回"resourceName-568h"。字符串后缀方法在插入后缀的位置上是智能的，因此可以在任何顺序调用它们。

版本发布记录

版本 1.6.7

  • 修复了在iOS 13上加载图像时崩溃的问题

版本 1.6.6

  • 更新了Xcode 9.2的兼容性

版本 1.6.5

  • 修复了在Xcode 7.3中的编译错误

版本 1.6.4

  • 修复了在Xcode 6.3中的编译错误

版本 1.6.3

  • 修复了nib文件中未正确检测到-xxxh后缀的bug

版本 1.6.2

  • 修复了检查-xxxh后缀时的误报问题

版本 1.6.1

  • 增加了对iPhone 6和6 plus更好的支持
  • 修复了nib加载逻辑中可能发生的崩溃

版本 1.6

  • 增加了对新的屏幕尺寸和像素密度的支持
  • 将 stringByAppendingInterfaceIdiomSuffix 重命名为 stringByAppendingDeviceInterfaceIdiomSuffix 以实现一致性
  • 废弃了针对iPhone 4/5硬件过度特定的方法

版本 1.5.6

  • 现在会在非Retina设备上加载Retina图像（如果没有提供非Retina图像）

版本 1.5.5

  • 现在遵守 -Weverything 警告级别

版本 1.5.4

  • 删除了意外留在库中的某些调试代码

版本 1.5.3

  • 修复了swizzled initWithImage:方法中的bug，这意味着它从未被调用

版本 1.5.2

  • 修复了使用storyboards时swizzling崩溃的问题
  • 增加了Podspec文件

版本 1.5.1

  • 修复了在UIImage swizzling中尝试加载已包含-568h后缀的图像名称或路径时失败的bug
  • 修复了"No previous prototype for function"错误

版本 1.5

  • 修复了在省略扩展名时normalizedPathForFile:方法中的一些bug
  • 增加了normalizedPathForFile:ofType:方法以方便使用
  • 现在在Mac OS和iOS上都会swizzle图像加载方法
  • 增加了额外的路径操作方法

版本 1.4.2

  • 增加了对rdar://problem/11017158问题的修复
  • 现在可以正确处理非整数路径缩放因子，例如@1.5x

版本 1.4.1

  • 增加了对具有.foo.gz扩展名的文件的后缀逻辑，以改善与GLView库的兼容性。

版本 1.4

  • 现在包括swizzle UIKit方法，在加载图像和nib文件时自动支持-hd和-568h后缀（如果需要，可以通过SP_SWIZZLE_ENABLED预处理器宏来禁用）。
  • 更新了API，包括更多的字符串后缀操作方法，并为现有方法提供了更合理的命名约定。请注意，某些方法的行为略有变化。
  • 修复了在Retina Mac上加载图像时normalizedPathForFile:方法中的一个小bug（选择了错误图像）。

版本 1.3

  • 增加了对iPhone 5的-568h@2x文件路径后缀的支持。Apple目前在这些文件中未提供对UIImage或加载nib文件的支持，但StandardPaths现在可以自动检测这些文件并在需要时生成正确的路径。

版本 1.2.2

  • StandardPaths的NSString扩展方法将不再修改包含双斜杠的字符串，例如完全限定的URL。然而请注意，Apple自己的路径操作方法（例如stringByAppendingPathExtension:）仍会修改这些字符串。

版本 1.2.1

  • normalizedPathForFile:方法将不再在某些情况下重复应用@2x扩展，这会导致加载错误的文件。

版本 1.2

  • 添加了用于根据标准后缀名加载设备和分辨率特定文件版本的 normalizedPathForFile: 方法
  • 添加了NSString的文件后缀操作分类方法
  • 添加了Mac和iOS测试项目以实现标准化路径功能
  • 现在需要iOS 4或更高版本

版本1.1.1

  • 为了在保存大量文件时提高性能，添加了路径缓存功能
  • 添加了当NSTemporaryDirectory()返回nil时的备用方案

版本1.1

  • 支持了iOS 5.1的新移动备份标志
  • 添加了方便在标准目录内创建文件的便利方法
  • 离线数据路径在iOS 5和iOS 5.0.1之间不再改变，因为在升级过程中的不便超过了iOS 5.0用户（减少iCloud使用）的好处。

版本1.0.1

  • 修正了offlineDataPath，使其正确指向iOS 5及更早版本的离线数据子目录，如文档所述。

版本1.0

  • 初始发布。