NSDictionary `description` 格式化问题——将结构视为 char 数据 [英] NSDictionary `description` formatting problem -- treats structure like char data

问题描述

我有一个自定义类(它在概念上类似于 NSArray，并且希望是格式化​​的外观)，它有一个 description 格式化程序.

I've got a custom class (which resembles an NSArray in concept and, hopefully, formatted appearance) which has a description formatter.

当格​​式化程序的输出本身被打印(NSLog)时，它看起来很好，但是当它作为 NSDictionary description 的元素包含时，NSDictionary 格式化程序似乎决定它是一个字符串，不是结构定义，将其括在引号中，并转义字符串中的所有控制字符.

When the output of the formatter is printed (NSLog) by itself it looks fine, but when it's included as an element of an NSDictionary description the NSDictionary formatter seems to decide that it's a character string, not a structure definition, encloses it in quotes, and escapes all of the control characters in the string.

当然，对于标准的 NSArray，它不会这样做，所以我想知道它是如何决定以一种方式处理字符串而不是另一种方式的.

It doesn't do this for a standard NSArray, of course, so I'm wondering how it decides to treat the string one way vs the other.

例如，而不是输出看起来像:

Eg, rather than having output that looks like:

theChildren = (
                  {
                      "@meta.type" = "ns3:location";
                      "childNumber" = 0;
                      ...

看起来像:

theChildren = "( 
		 {
	  "@meta.type" = "ns3:location";
	   "childNumber" = 0;
...

谁能提出改变这种行为的方法?

Can anyone suggest a way to alter this behavior?

FWIW，我在 NSMutableString 中累积描述字符串(数据主要由调用 NSDictionary description 的结果组成)，然后在出口处执行 NSString stringFromString (虽然我不知道那有什么作用).

FWIW, I accumulate the description string (with data consisting primarily of the results from calls to NSDictionary description) in an NSMutableString, then do NSString stringFromString at the exit (though I don't know that that does anything).

我想我在 NSDictionary 的文章中找到了答案(尚未检查):

I think I found the answer (haven't checked yet) buried in the NSDictionary writeup:

讨论

返回的 NSString 对象包含字典的每个条目.descriptionWithLocale:缩进:获取给定键或值的字符串表示形式，如下所示:

The returned NSString object contains the string representations of each of the dictionary’s entries. descriptionWithLocale:indent: obtains the string representation of a given key or value as follows:

If the object is an NSString object, it is used as is.

If the object responds to descriptionWithLocale:indent:, that

调用方法来获取对象的字符串表示.

method is invoked to obtain the object’s string representation.

If the object responds to descriptionWithLocale:, that method is

调用以获取对象的字符串表示形式.

invoked to obtain the object’s string representation.

If none of the above conditions is met, the object’s string

表示是通过调用其描述方法获得的.

representation is obtained by invoking its description method.

更新

好吧，事实证明他们在撒谎.我实现了 descriptionWithLocale:indent: 并且它永远不会被调用.

Update

Well, turns out they lie. I implemented descriptionWithLocale:indent: and it never gets called.

有趣的是，如果我让我的类成为 NSArray 的子类，那么 NSDictionary 会调用 descriptionWithLocale:indent: 并且它的格式正确.听起来 NSDictionary 是在作弊"并测试 isKindOfClass 而不是 respondsToSelector，否则只是对非 NS 的东西有偏见.

Interestingly, if I make my class a subclass of NSArray then NSDictionary calls descriptionWithLocale:indent: and it formats correctly. Sounds like NSDictionary is "cheating" and testing isKindOfClass rather than respondsToSelector, or else is just prejudiced against non-NS stuff.

但是，在获取许多我不想模仿的行为以及携带额外未使用的数据方面，必须将 NSArray 子类化有点丑陋.

It's kind of ugly to have to subclass NSArray, though, in terms of acquiring a lot of behaviors I don't want to mimic, and carrying extra unused data.

另一种选择是将转义的字符串转换回其原始字符串.这需要一个 31 行的过程来处理基础知识( 、 、" 和 \).好处是我不需要继承 NSArray.主要的缺点是这个例程必须插入​​到任何可以显示我的类的 NSLog 调用中.另一个小缺点是转义的字符串被包装了引号字符我无法消除，但这几乎不引人注意.

Another option is to convert the escaped string back to its original. This takes a 31-line procedure to handle the basics ( , , ", and \). The up-side is that I don't need to subclass NSArray. The main downside is that this routine must be inserted in any NSLog call that could display my class. Another minor downside is that the escaped strings were wrappered with quote characters I can't eliminate, but that's hardly noticeable.

现在知道#ifdefed -- 不确定我会选择哪个.

Got it #ifdefed for now -- not sure which I'll pick.

推荐答案

这个问题没有真正的答案(OS X 的安全功能"似乎不会影响 iOS 控制台写入)，但是有这两个工作-周围:

There's no real answer to this question (the "security feature" of OS X doesn't appear to affect iOS console writes), but there are these two work-arounds:

#1: 有趣的是，如果我让我的类成为 NSArray 的子类，那么 NSDictionary 会调用 descriptionWithLocale:indent: 并且它的格式正确.听起来 NSDictionary 是作弊"，测试 isKindOfClass 而不是 respondsToSelector，否则只是对非 NS 的东西有偏见.

#1: Interestingly, if I make my class a subclass of NSArray then NSDictionary calls descriptionWithLocale:indent: and it formats correctly. Sounds like NSDictionary is "cheating" and testing isKindOfClass rather than respondsToSelector, or else is just prejudiced against non-NS stuff.

但是，在获取许多我不想模仿的行为以及携带额外未使用的数据方面，必须将 NSArray 子类化有点难看.等等

It's kind of ugly to have to subclass NSArray, though, in terms of acquiring a lot of behaviors I don't want to mimic, and carrying extra unused data. Etc

#2: 另一种选择是将转义字符串转换回其原始字符串.这需要一个 31 行的过程来处理基础知识( 、 、" 和 ).好处是我不需要继承 NSArray.主要的坏处是必须插入此例程在任何可以显示我的类的 NSLog 调用中.另一个小缺点是转义的字符串被我无法消除的引号字符包装，但这几乎不引人注意.

#2: Another option is to convert the escaped string back to its original. This takes a 31-line procedure to handle the basics ( , , ", and ). The up-side is that I don't need to subclass NSArray. The main downside is that this routine must be inserted in any NSLog call that could display my class. Another minor downside is that the escaped strings were wrappered with quote characters I can't eliminate, but that's hardly noticeable.

(接受这个答案，即使它不是真正的"答案，因为否则我接受的百分比会受到影响.我猜我问了太多困难的问题.)

(Accepted this answer, even though it's not the "real" answer, because my accepted % would suffer otherwise. I ask too many difficult questions, I guess.)

这篇关于NSDictionary `description` 格式化问题——将结构视为 char 数据的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！