Konwerter JSON na XML

Konwerter JSON na XML

Konwerter JSON na XML zamienia dane JSON na dokument XML 1.0 w kodowaniu UTF-8: każdy klucz obiektu staje się elementem, a każda pozycja tablicy osobnym elementem listy. Przydaje się tam, gdzie odbiorca przyjmuje tylko XML – w bankach, integracjach B2B i starszych API.

W formularzu ustawiasz nazwę elementu głównego (domyślnie response) i elementu listy (domyślnie item), sposób nazywania pozycji tablic, deklarację <?xml version="1.0" encoding="UTF-8"?> oraz wcięcie: 2 spacje, 4 spacje albo tabulator. Po wyłączeniu formatowania cały XML trafia do jednej linii. Wynik odświeża się podczas pisania, a nad nim widać liczbę elementów i linii, rozmiar JSON i XML w bajtach oraz procentową zmianę rozmiaru. Gdy JSON ma błąd składni, narzędzie podaje linię, kolumnę i przyczynę, np. zbędny przecinek przed „}” albo apostrofy zamiast cudzysłowów.

Zasady konwersji

Przykład

{"status":"ok","users":[{"id":1},{"id":2}]}

Zamiana JSON na XML przy ustawieniach domyślnych (element główny response, element listy item, wcięcie 2 spacje, deklaracja włączona) daje:

<?xml version="1.0" encoding="UTF-8"?>
<response>
  <status>ok</status>
  <users>
    <item>
      <id>1</id>
    </item>
    <item>
      <id>2</id>
    </item>
  </users>
</response>

Po przełączeniu „Nazwa elementów tablicy” na „Powtórzona nazwa klucza” znika element grupujący, a każdy obiekt z tablicy dostaje nazwę klucza (deklarację pominięto):

<response>
  <status>ok</status>
  <users>
    <id>1</id>
  </users>
  <users>
    <id>2</id>
  </users>
</response>

Jak działa konwersja JSON na XML

Narzędzie przechodzi rekurencyjnie po całym dokumencie JSON. Dla każdej pary klucz-wartość tworzy element XML, którego nazwą jest klucz, a zawartością wynik przetworzenia wartości. Na końcu całość opakowuje w element główny ustawiony w formularzu. Struktura XML jest więc bezpośrednim odbiciem struktury JSON: zagnieżdżony obiekt staje się zagnieżdżonym elementem, a tablica elementem grupującym z powtarzalnymi elementami listy. Tablica w tablicy daje kolejny poziom elementów listy, a jeśli cały JSON jest tablicą, jej pozycje trafiają bezpośrednio do elementu głównego. Nie musisz ręcznie mapować każdego pola, dopóki układ JSON odpowiada oczekiwanej strukturze XML.

Tekst, liczba i boolean trafiają do wnętrza elementu jako tekst, a null tworzy pusty element. XML nie przechowuje informacji o typie, więc liczba 1 i tekst „1” wyglądają w wyniku tak samo. Odbiorca musi wiedzieć ze schematu, czy dane pole ma być liczbą, czy napisem. To ważne przy integracjach, gdzie XSD wymaga konkretnego typu, a XML sam z siebie go nie narzuca. Liczby z częścią ułamkową są zapisywane w najkrótszej postaci (10.0 → 10, 99.50 → 99.5), a bardzo duże liczby całkowite, np. 20-cyfrowe identyfikatory, przechodzą bez zaokrąglenia.

Nazwy elementów są budowane z kluczy JSON. Litery (także polskie), cyfry, podkreślenia, myślniki i kropki zostają bez zmian, a każdy inny znak – spacja, dwukropek, ukośnik, nawias – zamienia się na podkreślenie. Klucz, który nie zaczyna się od litery ani podkreślenia, dostaje prefiks field_. Nazwy elementu głównego i elementu listy są czyszczone inaczej: niedozwolone znaki znikają, a nazwę zaczynającą się od cyfry poprzedza litera x. Z soap:Envelope powstaje więc soapEnvelope, a puste pole daje root lub item. Narzędzie nie tworzy atrybutów, nie dodaje przestrzeni nazw i nie waliduje dokumentu względem XSD. Wynik jest składniowo poprawnym XML, ale zgodność ze schematem odbiorcy zależy od ustawień nazw oraz od tego, czy Twój JSON ma odpowiedni kształt. Przed wdrożeniem porównaj wynik z przykładowym dokumentem wymaganym przez system docelowy.

Przykład krok po kroku z policzonym wynikiem

1. Startowy JSON z poprzedniej sekcji to obiekt z dwoma polami: status oraz users. Element główny response opakowuje całą strukturę, a jego nazwa nie wpływa na nazwy pól wewnątrz.
2. Pole status ma wartość tekstową ok. Powstaje element status z tekstem ok w środku, bez dodatkowego elementu pośredniego.
3. Pole users jest tablicą o długości 2. Powstaje element users, a każdy z dwóch obiektów staje się osobnym elementem item. Element users pełni rolę kontenera, a nie zwykłego pola z tekstem.
4. Pierwszy obiekt w tablicy ma pole id równe 1, więc wewnątrz pierwszego itemu powstaje element id z tekstem 1. Drugi item ma identyczną strukturę i różni się tylko wartością 2.
5. Kafelek „Elementów” pokaże 6: status, users, dwa itemy i dwa id. Element główny i deklaracja XML nie są wliczane. W trybie „Powtórzona nazwa klucza” wynik spada do 5, bo znikają dwa itemy, a users występuje dwa razy.
6. Wejściowy JSON ma 43 bajty. Sformatowany XML z deklaracją ma 12 linii i 185 bajtów, więc „Zmiana rozmiaru” pokaże +330%. Po wyłączeniu formatowania i deklaracji XML zajmuje 101 bajtów w jednej linii, czyli +135%. Różnicę robią znaczniki zamykające i wcięcia.

Praktyczne wskazówki przed konwersją

• Ustaw element główny pod odbiorcę. Jeśli system oczekuje response, request albo envelope, wpisz dokładnie taką nazwę. Zmiana nazwy roota nie zmienia danych, ale często decyduje o przejściu walidacji.
• Nazwa z pola „Element listy” dotyczy wszystkich tablic w dokumencie. Wiele API wymaga item, row, entry albo record. Gdy różne listy potrzebują różnych nazw, wybierz tryb „Powtórzona nazwa klucza” i nadaj kluczom w JSON docelowe nazwy, np. "user":[…] zamiast "users":[…].
• Przejrzyj klucze przed konwersją. Spacje, dwukropki i ukośniki zamienią się na podkreślenia, a cyfra na początku doda prefiks field_. Jeśli odbiorca wymaga konkretnych nazw elementów, popraw je w JSON.
• Liczby i booleany staną się tekstem. Jeśli XML ma przejść walidację XSD, upewnij się, że schemat akceptuje takie wartości, np. true i false dla typu xs:boolean.
• Atrybutów nie będzie. Gdy potrzebujesz na przykład id jako atrybutu, zaplanuj ręczną edycję lub transformację XSLT przed wdrożeniem integracji.

Ograniczenia i ryzyka

• Brak atrybutów i przestrzeni nazw. Nie odwzorujesz elementu z identyfikatorem w atrybucie ani prefiksów typu soap:, bo dwukropek w kluczu zamienia się na podkreślenie. Jeśli API wymaga atrybutów, konwerter będzie tylko pierwszym krokiem.
• Kolizje nazw. Klucze a b i a_b dadzą po zamianie ten sam element a_b, co utrudni odczyt lub walidację. Lepiej unikać takich nazw już na etapie tworzenia JSON.
• Brak walidacji względem schematu. Narzędzie tworzy poprawny składniowo XML, ale nie sprawdza XSD, DTD ani wymagań konkretnego API. Nie poprawi też błędów logicznych w danych, na przykład brakujących pól.
• Limit rozmiaru. JSON może mieć do 200 000 znaków liczonych w bajtach, więc polska litera zajmuje dwa. Większy plik podziel na części albo przekonwertuj skryptem.
• Znaki sterujące. Niewidoczne znaki niedozwolone w XML 1.0 (kody 0–31 z wyjątkiem tabulatora, LF i CR) są usuwane z tekstu bez ostrzeżenia.