NSDictionary 中的最大密钥长度是多少？
我目前正在开发一个应用程序，它在表格中显示一堆文件，您可以添加和删除它们等等。为了防止表中重复，我想使用文件完整路径作为另一个包含所有文件信息的 NSDictionary 的键来创建一个 NSDictionary，但我有点担心 NSDictionary 的最大键长度，以及这是否解决方案是否会成为性能杀手......
I'm currently working on an app which displays a bunch of files in a table, and you can add and remove them and whatsoever. To prevent duplicates in the table, I'd like to create a NSDictionary using the files full path as keys for another NSDictionary which contains all the file information, but I am a little concerned about the maximum key length of NSDictionary, and also whether this solution would be performance killer or not...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您使用的 NSString 的大小没有具体限制，只要它不会大到填满所有内存即可！字典不会加载字符并开始查看它们本身，因此不会出现任何与之相关的内部 NSDictionary 问题或性能问题，因为它所做的只是使用 isEqual: 方法，如果它返回 true，则它匹配。
希望有帮助。
There are no specific limits on the size of the NSString you use as long as it's not so big you fill up all the memory! The dictionary doesn't load in the characters and start looking at them itself so there won't be any internal NSDictionary issues related to that, or performance issues, as all it does is use the isEqual: method and if it returns true, it matches.
Hope that helps.
没有具体限制。字典的一个先决条件是密钥必须符合
NSCopying协议。当您将键值对插入字典时，字典会创建键对象的副本，以确保它在字典内不会发生变化。它使用密钥对象的哈希值来确定在内部对其进行排序的位置。如果对象在字典中时发生变化，它会破坏排序并且字典将无法工作，这就是字典创建副本的原因（尽管作为一种优化，当不可变对象如NSString 被要求提供一个副本，它可以简单地增加保留计数并返回自身，但这是一个实现细节）。由于键必须符合
NSCopying协议，这意味着您可以使用许多对象作为字典的键，包括NSArray、NSData、等等。不要担心在 NSDictionary 集合中使用大字符串的性能，除非您发现这实际上是一个瓶颈。There is no specific limit. One prerequisite for dictionaries is that the key must conform to the
NSCopyingprotocol. When you insert a key-value pair into a dictionary, the dictionary makes a copy of the key object to ensure that it does not mutate while inside the dictionary. It uses the key object's hash value to determine where to order it internally. If the object mutated while it was in the dictionary, it would throw the ordering off and the dictionary wouldn't work, so that's why the dictionary makes a copy (although as an optimisation, when immutable objects such asNSStringare asked for a copy, it could simply increase the retain count and return itself, but this is an implementation detail).Since keys must conform to the
NSCopyingprotocol, it means you can use a number of objects as keys to a dictionary, includingNSArray,NSData, etc. Do not worry about performance of using large strings inNSDictionarycollections unless you have discovered that this is actually a bottleneck.没有任何最大值，除了 NSString 的最大长度，我认为理论上是无限的/UIntMax。 NSDictionary 接口需要通过 -hash 和 -isEqual: 方法进行索引，由任何用作键的对象实现，以允许键是任何东西，而不仅仅是 NSString。 NSString 当然实现了这两个函数，但这不是重点——散列是一个 int，所以基本上由 NSString 找到一种方法将其内容转换为整数——它不必（并且物理上不能） ）是唯一的，只是可重复的（每次都返回相同的结果）。有关哈希的详细信息，请参阅此处。基本上，这意味着每个 NSString（实际上是任何对象）都可以有一个哈希值。因此，如果你可以将它存储在 NSString 中，那么将它存储在 NSDictionary 中就没有限制。另外，不用担心性能/字典的字典是一个完全有效的设计，并且速度足够快，可以应用。
There is no maximum whatsoever, except perhaps the maximum length of NSString, which I think is theoretically unlimited/UIntMax. The NSDictionary interface necessitates indexing via the -hash and -isEqual: methods, implemented by whatever object is being used as a key, to allow keys to be anything, not just NSStrings. NSString of course implements both functions, but that is not the point -- the hash is an int, so basically it is up to NSString to find a way to turn its contents into an integer -- it does not have to (and physically cannot) be unique, just repeatable (returning the same result every time). See here for details on hashing. Basically, this means that every NSString -- any object, really -- can have a hash. Therefore, if you can store it in an NSString, then there is no limit on putting it in an NSDictionary. Also, don't worry about performance/dictionaries of dictionaries are a perfectly valid design and are fast enough to be applicable.
没有理论上的最大值。另外，在您确定性能确实是一个问题之前，我不会担心性能。
There is no theoretical maximum. Also, I wouldn't worry about performance until you determine that it's really a problem.