Wklej Swifta po lewej i kliknij "Konwertuj" — zamienimy to na XMLWklej kod Swift

Co robi to narzędzie

Jeśli kiedykolwiek musiałeś ręcznie klepać XML-a, który odzwierciedla Swiftowego structa — pod plist, pod klienta SOAP gadającego z legacy ERP, pod fixture testowy XMLParsera — wiesz, ile klamerek się wstukuje. Wklej tu Swifta i w jednym przebiegu dostaniesz poprawny XML. Jeden struct, plik z kilkoma structami i enumami, albo wypełniona instancja let order = Order(...) — wynik ten sam: kompletny dokument XML z zachowanymi wszystkimi property.

To nie jest głupie zamienianie stringów. Konwerter wie, jak Swift serializuje w praktyce — mniej więcej tak, jak zrobiłby to XMLEncoder oparty na Codable. Wartości Decimal wychodzą jako zwykły tekst liczbowy, Date jako string ISO-8601, UUID w standardowym formacie hex 8-4-4-4-12, a Optional<T> z nil staje się pustym elementem, zamiast po prostu zniknąć. Tablice trzymają się spójnego kształtu kontenera — każda tablica zamienia się w element wrapper z jednym dzieckiem na item, nazwanym od typu elementu.

Customizacje Coding też są respektowane. Zagnieżdżony enum CodingKeys: String, CodingKey przemapowuje nazwy property w outpucie, więc orderId może pojawić się w XML-u jako OrderId, bez dotykania structa. Zagnieżdżone structy i enumy rozwijają się inline. Wklej kilka typów naraz — każdy ląduje w outpucie z zachowanym kształtem. Konwerter trzyma się tych samych ogólnych założeń co Swift API Design Guidelines, więc nazwy i casing są przewidywalne.

Jak używać

Trzy kroki. Działa tak samo, czy wklejasz pięciolinijkowego structa, czy cały plik z modelami.

1

Wklej swojego Swifta (albo odpal przykład)

Wrzuć Swifta do lewego edytora as-is. Struct, enum z associated values, wypełniona instancja let albo plik z wieloma typami — wszystko gra. Kliknij Wczytaj przykład, żeby najpierw zobaczyć realistyczny przypadek.

Nie musisz usuwać import-ów, @propertyWrapper-ów ani sprzątać składni Swifta. Zostaw kod tak, jak wygląda w Xcode. Wystarczy wkleić.

2

Kliknij Konwertuj

Kliknij zielony przycisk Konwertuj. Narzędzie czyta Swifta, zachowuje każdy typ i property, i buduje XML-a w jednym przebiegu. W trakcie leci krótki wskaźnik ładowania.

3

Skopiuj XML-a

Prawy panel zapełnia się wciętym, dobrze sformułowanym XML-em, który przyjmie każdy zgodny ze standardem parser XML (XMLParser, lxml, System.Xml, co tylko chcesz). Skopiuj go wprost do swojego plista, body SOAP albo fixture’a testowego.

Kiedy to się naprawdę przydaje

Generowanie plistów na iOS / macOS

Weź Swifta structa z ustawieniami i dostań dokument XML w stylu Info.plist, którego nie musisz ręcznie poprawiać — klepiesz go wprost do Xcode. Żadnych ręcznych par <code>&lt;key&gt;&lt;/key&gt;</code>, żadnych bugów z whitespace. Ładnie gra z Apple’owskim <a href="https://developer.apple.com/documentation/foundation/propertylistserialization" target="_blank" rel="noopener">PropertyListSerialization</a> po stronie dekodowania.

Klienci SOAP na platformach Apple

Swift-owy typ requestu musi wyjść z apki jako SOAP. Wklej structa, wrzuć XML-owy body do SoapUI albo Postmana, zweryfikuj kontrakt bez pisania envelope’a ręcznie.

Seedowanie fixture’ów testowych

Zamień wypełniony <code>let order = Order(...)</code> z testu jednostkowego w plik seedu XML do testów integracyjnych XCTest, do mock serwerów albo do backendów, które wciąż mówią XML-em.

Trzymanie dokumentacji w synchro

Generuj przykłady XML-owe do README, do wewnętrznej wiki albo do docsów schematu opartego o XSD prosto ze swoich realnych modeli Swifta, żeby dokumentacja nigdy nie rozjeżdżała się z kodem.

Częste pytania

Czy mogę wkleić kilka structów naraz?

Tak — wklej cały plik. Każdy top-level struct albo enum przechodzi z rozwiniętymi zagnieżdżonymi typami i wypełnionymi wartościami domyślnymi. Nic nie znika po cichu.

Czy respektuje CodingKeys?

Tak. Zagnieżdżony enum CodingKeys: String, CodingKey przemapowuje nazwy property w outpucie XML — case orderId = "OrderId" wypluwa <OrderId> zamiast <orderId>. Property nie wymienione w CodingKeys wracają do swoich swiftowych nazw. To samo zachowanie, co Codable w praktyce.

Jak obsługuje Decimal, Date i Optional?

Decimal wychodzi jako zwykły tekst liczbowy. Date jako string ISO-8601. UUID jako standardowy hex string 8-4-4-4-12. Optional<T> z nil staje się pustym elementem zamiast zniknąć — dzięki czemu kształt pozostaje spójny dla konsumentów, którzy walidują wg XSD.

A co z enumami z associated values i tablicami?

Enumy z associated values wychodzą z atrybutem dyskryminatora, który nazywa case, plus dzieci dla associated values — tyle, żeby dało się zrobić round-trip. Tablice stają się elementem kontenera z jednym dzieckiem na item, nazwanym od typu elementu. Dictionary<K,V> staje się kontenerem z <Entry><Key/><Value/></Entry>.

Czy mój kod jest zapisywany?

Twój kod leci do backendu do konwersji i nie jest przechowywany dalej — nie logujemy payloadu. Jak zawsze z narzędziami online: jeśli kod naprawdę jest wrażliwy, rzuć na niego okiem przed wklejeniem.

Co jeśli Swift ma property wrappery, protokoły albo computed properties?

Property wrappery są rozpakowywane do wartości wewnętrznej w outpucie. Protokoły definiują kształt, a nie treść, więc same w sobie nie produkują XML-a — ale typy im zgodne już tak. Computed properties są pomijane, bo są pochodne, a nie stanem. Jeśli w kodzie są błędy składni, najpierw wygładź te oczywiste — parser jest tolerancyjny, ale nie jest jasnowidzem.

Inne narzędzia, które mogą się przydać

Swift → XML to tylko kawałek układanki. Te grają z nim dobrze: