Objective-C till XML-konverterare
Klistra in Objective-C-interfaces eller objekt. Få tillbaka ren XML.
Det här gör verktyget
Om du någon gång har varit tvungen att bygga ihop en XML-payload för hand som matchar en Objective-C-modell — för en gammal SOAP-tjänst, en plist-fil, en Cocoa-config eller ett testfixture — känner du rutinen. Du räknar @property-rader, drar bort typkvalificerare, försöker minnas vilka som är NSArray-containrar och hoppas att formen blir rätt. Klistra in Objective-C här och du får välformad XML i ett svep. En ensam alloc/init-snutt, en hel headerfil med flera @interface-block, eller en djupt nästlad modell — samma resultat.
Det är ingen naiv textersättning. Konverteraren följer hur Cocoa faktiskt mappar mot XML. NSString-värden blir textnoder (korrekt escape'ade). NSNumber och NSDecimalNumber tappar sin wrapper och blir vanlig numerisk text — så [NSDecimalNumber decimalNumberWithString:@"249.99"] kommer ut som 249.99. BOOL-värden blir true / false, eller varianten YES / NO om ditt schema vill ha det. NSArray<OrderItem *> blir ett container-element med ett barn per item, döpt efter elementtypen — samma form som träd av NSXMLElement skickar ut.
Backing via instansvariabler hanteras också. Använder din @property @synthesize customerName = _customerName; heter elementet fortfarande customerName, inte _customerName — iVar-namnet är en implementationsdetalj, inte del av wire-formatet. Nästlade objekt (en Order med en Address-@property) expanderas på plats, och nil-värden blir tomma element så att formen förblir konsekvent. Klistrar du in flera @interface-block hamnar alla i utdatan. Klistra in det som det står i din .h-fil — inget städ behövs — och jämför resultatet med vad NSXMLDocument skulle producera.
Så använder du det
Tre steg. Fungerar likadant oavsett om du klistrar in en klass eller ett helt headerknippe.
Klistra in din Objective-C (eller prova exemplet)
Släpp ner din Objective-C i vänstra editorn som den är. Ett @interface-block, en alloc/init-objektliteral, flera klasser eller nästlade typer — allt funkar. Klicka på Ladda exempel för att först se ett realistiskt Order / OrderItem / Address-exempel.
Du behöver inte rensa bort @property-attribut, ta bort pragmas eller städa bland importer. Lämna koden som den ser ut i Xcode. Parsern kan läsa en riktig .h- eller .m-fil.
Tryck Konvertera
Klicka på den gröna Konvertera-knappen. Verktyget läser Objective-C, behåller varje @property, bevarar nästlade objekt och bygger XML:en i ett svep. En kort laddningsindikator snurrar medan det pågår.
Kopiera XML:en
Den högra panelen fylls med indenterad, välformad XML som varje standardenlig parser — även NSXMLParser — accepterar. Kopiera in den i en plist, en SOAP-request-body, ett testfixture eller din dokumentation.
När det verkligen hjälper
Bygga plist-fixtures för iOS
Du har en Objective-C-modell och behöver en matchande Info.plist eller seed-plist. Klistra in klassen, plocka XML:en, släpp den i bundlet — inga handskrivna <code><dict></code> / <code><key></code>-par.
Cocoa XML-konfigfiler
Gamla desktop-Cocoa-appar skeppar fortfarande XML-config. Gör om din <code>Settings</code>-klass till en färdig mall att redigera, så konfigurationen matchar koden som läser den.
Legacy SOAP- / WCF-klienter på iOS
Pratar din iOS-app fortfarande med en SOAP-endpoint kan du klistra in kontraktsklassen för requesten och få XML-envelope-bodyn — enklare än att bygga <code>NSXMLElement</code>-träd för hand.
Mata XML-workflows på Mac OS
Gamla AppleScript- / Automator- / XML-RPC-integrationer vill ha XML. Klistra in Objective-C-modellen, ta XML:en, mata in den i flödet — ingen manuell översättning.
Vanliga frågor
Kan jag klistra in flera @interface-deklarationer samtidigt?
Ja. Klistra in en hel headerfil. Varje @interface följer med, med nästlade typer expanderade. Oavsett om din @interface deklarerar ivars explicit (inuti { }) eller använder den moderna bara-@property-stilen fungerar båda likadant.
Hur hanteras @property-attribut?
Attribut som (nonatomic, copy), (strong), (weak), (readonly) och (assign) är metadata för runtimen — de påverkar inte den serialiserade formen. Elementnamnet är propertyns namn. readonly-properties skickas också ut (de har fortfarande ett värde). Beräknade properties med egna getters behandlas som vilken annan property som helst.
Vad händer med iVar-namn — får jag element med _understreck?
Nej. Om din property heter customerName och backing-iVar:en är _customerName blir XML-elementet <customerName>. Understrecket är en Objective-C-konvention, inte ett wire-format. Vill du byta namn på ett element, döp om själva @property och klistra in på nytt.
Hur behandlas NSString, NSNumber, NSDecimalNumber, BOOL och NSDate?
NSString blir en textnod med korrekt XML-escape. NSNumber och NSDecimalNumber tappar sin wrapper och blir vanlig numerisk text. BOOL blir true / false (eller YES / NO om källkoden använder plist-konventionen). NSDate kommer ut som en ISO-8601-sträng. nil-värden blir tomma element i stället för att försvinna.
Och NSArray, NSDictionary och nästlade objekt?
NSArray<OrderItem *> blir ett container-element med ett barn per item, döpt efter elementtypen: <items><OrderItem/><OrderItem/></items>. NSDictionary blir en container med <entry><key/><value/></entry>. Nästlade objekt (en property vars typ är ett annat @interface) expanderas på plats med alla fält intakta.
Lagras min kod?
Din kod skickas till backenden för konverteringen och sparas inte — vi loggar inte nyttolasten. Som alltid med onlineverktyg: är koden verkligen känslig, läs igenom den innan du klistrar in.
Andra verktyg du kan ha nytta av
Objective-C till XML är bara en bit av pusslet. De här verktygen passar ihop med det: