核心数据中的NSNumber（整数16,32,64）应该用来保留NSUInteger
我想保留NSUInteger到我的核心数据，我不知道应该使用哪种types（整数16,32,64）来适应所需的空间。
从我的理解
Integer 16 can have minimum value of -32,768 to 32,767 Integer 32 can have minimum value of -2,147,483,648 to 2,147,483,647 Integer 64 can have minimum value of -very large to very large 而NSUInteger是unsiged longtypes的def，它等于unsigned int（ iPhone上的objective-c中的types ）
所以如果我将我的NSUInteger转换为NSNumber与numberWithUnsignedInteger：并将其保存为NSNumber（整数32）我可以安全地检索我的数据回来吗？
你真的需要一个NSUInteger的整个范围？ 在iOS上，这是一个无符号的32位值，可以变得非常大。 它会find一个有符号的64位。
但是，你可能不需要那么多的精度。 uint32_t是UINT32_MAX ，即4294967295（40亿）。 如果每秒增加一次，就会花费超过136年才能达到这个价值。 您的用户的iPhone将不会在那时… 🙂
如果可能，在将数据写入磁盘或通过networking时，最好明确数值的大小。 而不是使用NSUInteger作为数据types，根据您需要的范围使用uint16_t ， uint32_t或uint64_t 。 这自然会转换为核心数据中的整数16,32和64。
要理解为什么，请考虑这种情况：
- 您可以select使用Integer 64types来存储您的值。
- 在64位的iOS设备上（例如iPhone 6），它存储的值为5,000,000,000。
- 在一个32位的iOS设备上，这个值被从商店中提取到一个
NSUInteger（使用NSNumber的unsignedIntegerValue）。
现在，由于NSUInteger在32位器件上只有32位，因此没有足够的位来表示50亿。 如果你已经在步骤3换了NUInteger for uint64_t那么这个值仍然是50亿。
如果你绝对必须使用NSUInteger，那么你只需要谨慎对待上面描述的问题，并为它防守编码。
至于存储无符号值到看起来签名的核心数据types，你可以安全地存储和检索它们：
NSManagedObject *object = // create object object.valueNumber = @(4000000000); // Store 4 billion in an Integer 32 Core Data type [managedObjectContext save:NULL] // Save value to store // Later on NSManagedObject *object = // fetch object from store uint32_t value = object.valueNumber.unsignedIntegerValue; // value will be 4 billion
