Przejdź do treści
TextArray1.41.0
100% lokalnie

JSON na schemat Zod

Wygeneruj schemat walidacji Zod i typy TypeScript z przykładu JSON, z wykrywaniem formatów i wyliczań.

Wejście
Wynik
Powiązane narzędzia
JSON na TypeScriptNarzędzia dla programistów
Walidator schematu JSONNarzędzia dla programistów
Formatowanie i walidacja JSONFormatowanie
różnica kluczy i18nNarzędzia dla programistów
Konwerter TOML na JSONNarzędzia dla programistów
SQL do JSONNarzędzia dla programistów
JSON na schemat Zod
Wklej próbkę JSON — odpowiedź API, plik konfiguracyjny, wiersz bazy danych — i uzyskaj gotowy schemat Zod w TypeScript. Typy są wnioskowane dla każdego pola: pierwotne typy mapują się do z.string(), z.number() i z.boolean(), pola zawierające listy mają wnioskowany typ elementu, a wartość, która różni się między wystąpieniami, staje się z.union(). Łańcuch, który wygląda jak adres e-mail, URL, UUID lub data ISO, otrzymuje pasujący walidator — .email(), .url(), .uuid(), .date() lub .datetime() — zamiast zwykłego z.string().
Podaj mu pole obiektów o tym samym kształcie, takie jak wiersze z punktu końcowego listy, a generator połączy każdy element przed wpisaniem pola: klucz brakujący w niektórych wierszach staje się .optional(), klucz, który jest czasem null, staje się .nullable() lub .optional() w zależności od wybranego ustawienia, a pole powtarzające mały zestaw wartości — kolumna stanu lub roli — staje się prawidłowym z.enum() zamiast otwartego łańcucha. Włącz „Podziel zagnieżdżone obiekty”, aby wyciągnąć każdy zagnieżdżony obiekt do własnego nazwanego eksportu zamiast jednego głęboko zagnieżdżonego literału, gdzie identyczne kształty automatycznie współdzielą jeden schemat. Włącz „Obiekty rygorystyczne”, aby odrzucić dowolny klucz, który próbka nigdy nie wykazała, łapiąc literówki i nieoczekiwane pola API przy parsowaniu zamiast później w strumieniu.
Nazwij wyeksportowany schemat w taki sposób, aby oczekiwał go twój kod, i opcjonalnie dodaj export type X = z.infer<typeof X> tuż poniżej, aby walidator czasu wykonywania i typ czasu kompilacji pochodziły z tego samego źródła i nigdy nie mogły się cicho oddalić.
Wszystko działa lokalnie w Twojej przeglądarce. JSON, który wklejasz — odpowiedzi API zawierające tokeny, rekordy użytkowników, wewnętrzne ładunki — jest analizowany i wpisywany całkowicie na Twoim urządzeniu i nigdy nie jest przesyłany nigdzie. Wklej próbkę, skopiuj wygenerowany schemat do swojego projektu i zacznij walidować to, co parsowujesz.
Częste pytania
Jak się decyduje między .optional() a .nullable()?
Klucz brakujący w niektórych próbkach pola to zawsze .optional() — nie ma innego sposobu na zezwolenie brakującemu kluczowi. Klucz, który jest obecny, ale czasem null, jest dwuznaczny, więc opcja „Obsługa wartości null” decyduje: nullable dokładnie typuje to z .nullable(), optional traktuje wartość null tak samo jak brakującą.
Jak obsługiwane są obiekty zagnieżdżone?
Domyślnie zagnieżdżony obiekt jest wpisywany inline, dokładnie tam, gdzie się pojawia. Włącz „Podziel zagnieżdżone obiekty”, aby każdy zagnieżdżony kształt miał swój własny export const ...Schema i identyczne kształty automatycznie współdzielą jeden schemat zamiast go duplikować.
Kiedy pole staje się z.enum() zamiast z.string()?
Gdy opcja „Wykryj wyliczenia” jest włączona i pole powtarza mały zestaw odrębnych wartości łańcucha — od 2 do 5 — w tablicy próbek, takie jak kolumna stanu lub kategorii. Pole zawierające tylko unikalne wartości lub zbyt wiele odrębnych pozostaje z.string().
Co robi opcja „Obiekty rygorystyczne”?
Dołącza .strict() do każdego wygenerowanego z.object(), więc parsowanie nie powiedzie się, jeśli dane wejściowe zawierają klucz, który próbka nigdy nie wykazała — przydatne do łapania literówek lub niezapowiedzianych dodatków API zamiast ich cichego ignorowania.
Czy mój JSON jest przesyłany gdziekolwiek?
Nie. Schemat jest generowany całkowicie w Twojej przeglądarce — Twój JSON nigdy nie opuści Twoje urządzenie.