NSDictionary 'Beschreibung' Formatierungsproblem - behandelt Struktur wie char-Daten

8

Ich habe eine benutzerdefinierte Klasse (die einem NSArray im Konzept ähnelt und hoffentlich formatiert aussieht), die einen description Formatierer hat.

Wenn die Ausgabe des Formatierungsprogramms (NSLog) selbst gedruckt wird, sieht es gut aus, aber wenn es als Element eines NSDictionary description enthalten ist, scheint der NSDictionary-Formatierer zu entscheiden, dass es sich um eine Zeichenfolge, nicht um eine Strukturdefinition handelt. umschließt es in Anführungszeichen und entfernt alle Steuerzeichen in der Zeichenfolge.

Es tut dies natürlich nicht für ein Standard-NSArray, also frage ich mich, wie es sich entscheidet, die Zeichenfolge in einer Richtung gegen die andere zu behandeln.

Beispiel: Anstatt eine Ausgabe zu haben, die wie folgt aussieht:

%Vor%

Es sieht so aus:

%Vor%

Kann jemand vorschlagen, dieses Verhalten zu ändern?

FWIW, ich akkumuliere den Beschreibungsstring (mit Daten, die hauptsächlich aus den Ergebnissen von Aufrufen von NSDictionary description bestehen) in einem NSMutableString, dann mache NSString stringFromString am Ausgang (obwohl ich nicht weiß, dass das irgendwas macht).

Hinzugefügt

Ich glaube, ich habe die Antwort (noch nicht überprüft) in der NSDictionary-Beschreibung gefunden:

  

Diskussion

     

Das zurückgegebene NSString-Objekt enthält die Zeichenfolgendarstellungen von   jedes der Einträge des Wörterbuchs. descriptionWithLocale: Einrückung:   Ruft die Zeichenfolgendarstellung eines bestimmten Schlüssels oder Werts wie folgt ab:

%Vor%      Die

-Methode wird aufgerufen, um die Zeichenfolgendarstellung des Objekts abzurufen.

%Vor%      

wurde aufgerufen, um die Zeichenfolgendarstellung des Objekts zu erhalten.

%Vor%      

Darstellung wird durch Aufrufen seiner Beschreibungsmethode erhalten.

Aktualisieren

Nun, es stellt sich heraus, dass sie lügen. Ich habe descriptionWithLocale: indent: implementiert und wird nie aufgerufen.

Aktualisieren 9/23

Interessanterweise ruft NSDictionary, wenn ich meine Klasse zu einer Unterklasse von NSArray mache, descriptionWithLocale: indent: und formatiert sie korrekt. Klingt wie NSDictionary ist "Cheating" und testet isKindOfClass anstatt respondsToSelector , oder ist nur Vorurteile gegen Nicht-NS-Zeug.

Es ist ziemlich hässlich, NSArray von der Unterklasse ableiten zu müssen, wenn es darum geht, viele Verhaltensweisen zu erkennen, die ich nicht nachahmen möchte, und zusätzliche ungenutzte Daten zu tragen.

usw.

Eine weitere Option besteht darin, die maskierte Zeichenfolge zurück in das Original zu konvertieren. Dies erfordert eine 31-Zeilen-Prozedur, um die Grundlagen zu behandeln ( \n , \t , \" und \ ). Der Vorteil ist, dass ich NSArray nicht ableiten muss. Der Hauptnachteil ist, dass diese Routine in jeden NSLog-Aufruf eingefügt werden muss, der meine Klasse anzeigen könnte. Ein weiterer kleiner Nachteil ist, dass die entdeckten Strings mit Zitatzeichen versehen sind, die ich nicht eliminieren kann, aber das ist kaum bemerkbar.

Habe es für jetzt geklärt - bin mir nicht sicher, welches ich wählen werde.

    
Hot Licks 22.09.2011, 21:23
quelle

2 Antworten

2

Es gibt keine wirkliche Antwort auf diese Frage (die "Sicherheitsfunktion" von OS X scheint die Schreibvorgänge der iOS-Konsole nicht zu beeinflussen), aber es gibt diese zwei Umgehungslösungen:

# 1: Interessanterweise ruft NSDictionary, wenn ich meine Klasse zu einer Unterklasse von NSArray mache, descriptionWithLocale: indent: und formatiert sie korrekt. Klingt wie NSDictionary ist "Cheaten" und Testen isKindOfClass anstelle von AntwortenToSelector, oder sonst nur Vorurteile gegen Nicht-NS Zeug.

Es ist irgendwie hässlich, NSArray von der Unterklasse ableiten zu müssen, wenn es darum geht, viele Verhaltensweisen zu erfassen, die ich nicht nachahmen möchte, und extra ungenutzte Daten zu tragen. Etc.

# 2: Eine weitere Option besteht darin, die maskierte Zeichenfolge zurück in das Original zu konvertieren. Dies erfordert eine 31-zeilige Prozedur, um die Grundlagen (\ n, \ t, \ "und \) zu behandeln. Der Nachteil ist, dass ich NSArray nicht ableiten muss. Der Hauptnachteil ist, dass diese Routine eingefügt werden muss in einem beliebigen NSLog-Aufruf, der meine Klasse anzeigen könnte. Ein weiterer kleiner Nachteil ist, dass die entdeckten Strings mit Zitatzeichen versehen sind, die ich nicht eliminieren kann, aber das ist kaum bemerkbar.

(Akzeptiert diese Antwort, obwohl es nicht die "echte" Antwort ist, weil mein akzeptiertes% sonst leiden würde. Ich stelle zu viele schwierige Fragen, denke ich.)

    
Hot Licks 12.11.2011, 13:00
quelle
5

Dies ist ein wunderbares sicherheitsrelevantes "Feature", das in OS X 10.5 + Version von syslog() eingeführt wurde.

Wie von einem Apple-Techniker in diesem Beitrag erklärt: Wer hat NSLog gebrochen? auf Leopard? ,

  

Das ist das Verhalten von syslog() . Von der Manpage:

     
    
      

Newlines und andere nicht druckbare Zeichen, die in die Nachricht eingebettet sind       Zeichenfolge wird in einem alternativen Format gedruckt. Dies verhindert jemanden von       Verwenden nicht druckbarer Zeichen zum Erstellen eines irreführenden Protokolls       Nachrichten in einer Ausgabedatei. Newlines werden als "\ n" gedruckt, Registerkarten werden als gedruckt       "\ t". Andere Steuerzeichen werden mit einem Caret ("^") gedruckt       Darstellung, zum Beispiel "^ M" für Wagenrücklauf.

    
  
     

Das ASL-Subsystem, in das NSLog () schreibt, tut dasselbe (zumindest in   Leopard). Das Schreiben der XML in eine Datei ist eine sinnvolle Alternative.

     

Chris Kane Kakao Frameworks, Apple

Weitere Informationen finden Sie unter man syslog Info.

    
NSGod 23.09.2011 01:09
quelle

Tags und Links