Klistra in SQL till vänster och klicka på "Konvertera" — vi gör om det till XMLKlistra in SQL

Vad verktyget gör

Har du någonsin behövt dumpa en hög databasrader till en XML-fil åt en leverantör, en legacy SOAP-endpoint eller ett gammalt ETL-jobb som fortfarande förväntar sig XML, så känner du mönstret — öppna ett query-verktyg, kör SELECT, exportera, masera utdatan för hand, bråka med datumformat. Klistra in din SQL här istället och du får tillbaka välformad XML i ett svep. Flerrads INSERT-satser, bara ett CREATE TABLE-schema, eller en blandning — samma resultat.

Konverteraren läser SQL så som en databas hade gjort. Varje rad i ett flerrads INSERT blir ett element, och varje kolumn blir ett barnelement uppkallat efter kolumnen. NULL-värden blir tomma element (så formen på varje rad förblir densamma). Datumliknande litteraler — '2024-01-15 10:30:00', DATE '2024-01-15' eller råa timestamps — skrivs ut som ISO-8601-strängar, så parsers i Java, .NET, Python eller var som helst läser in dem utan trubbel. Numeriska typer behåller sin precision; booleaner kommer ut som true/false.

Schemakvalificerade namn som public.orders eller dbo.Orders kortas ner till bara orders eller Orders i elementnamnet, eftersom XML-elementnamn inte får innehålla punkter. Citerade identifierare, backticks från MySQL och dubbelcitat-namn från PostgreSQL hanteras på samma sätt. Släng in ett CREATE TABLE och du får ett XML-skelett för det schemat — ett tomt element per kolumn, användbart för att starta en XSD eller en exempel-payload. Flera tabeller i samma query? Var och en hamnar i utdatan som en egen sektion, i ordning.

Hur du använder det

Tre steg. Funkar lika oavsett om du klistrar in en rad eller tusen.

1

Klistra in din SQL (eller testa exemplet)

Släng in SQL-koden som den är i vänstra editorn. INSERT-satser med en eller många rader, CREATE TABLE-definitioner, eller en blandning — allt är okej. Klicka på Ladda exempel om du vill se hur en realistisk dump av flera orders-tabeller ser ut.

Kommentarer (-- och /* ... */), schemaprefix, dialektspecifika citeringar (MySQL-backticks, SQLite-dubbelcitat, SQL Server-hakparenteser) och avslutande semikolon funkar alla utan problem — du behöver inte städa upp nåt i förväg.

2

Tryck på Konvertera

Klicka på den gröna Konvertera-knappen. Verktyget parsar SQL:en, expanderar varje rad i ett flerrads-insert, normaliserar datum och booleaner och bygger XML:en i en enda körning. En kort laddningsindikator visas medan den jobbar.

3

Kopiera XML:en

Högra panelen fylls med indragen, välformad XML som vilken standardenlig XML-parser som helst accepterar. Kopiera det rakt in i en SOAP-body, en test-fixture, en ETL-drop-mapp, eller dit du behöver.

När det här faktiskt är användbart

Seed-fixtures för databasen

Du har en trave <code>INSERT</code>s från ett seed-skript och behöver samma data som XML till ett integrationstest eller en mock-server. Klistra in inserts, ta XML:en, klart — ingen manuell redigering rad för rad.

SOAP och legacy enterprise-integration

Ett äldre partnersystem förväntar sig en XML-body som speglar en uppsättning databasrader. Hoppa över mellanlagerkoden som stringifierar rader en och en; klistra in INSERT:en direkt och kopiera in XML:en i din SOAP-request.

Audit- och compliance-exporter

Regulatorer och revisorer älskar fortfarande XML. Gör om raderna du precis INSERT:ade (eller de du fångade från en loggquery) till ett signerbart, arkiverbart XML-dokument utan att dra igång en exportpipeline.

XML-baserade ETL-pipelines

Matar du ett ETL-verktyg som SSIS, Informatica eller en egen XSLT-pipeline? Konvertera SQL-exemplet uppströms till XML för att prototypa transformationen innan det riktiga batch-jobbet kopplas in.

Vanliga frågor

Hur hanteras flerrads INSERT-satser?

Ett flerrads INSERT INTO orders (...) VALUES (...), (...), (...); blir ett behållarelement för tabellen, med ett barnelement per rad — varje barn uppkallat efter tabellens singularform (så rader från orders blir <order>-element inuti en <orders>-wrapper). Varje rad har samma kolumnbarn i samma ordning som kolumnlistan, så utdatan blir förutsägbar även med hundratals rader.

Vad händer med NULL-värden?

Ett NULL i värdelistan blir ett tomt element (t.ex. <middle_name/>) istället för att tappas bort. Det håller formen på varje rad identisk, vilket spelar roll för konsumenter som itererar kolumner positionsmässigt eller bygger en XSD från exemplet. Om du behöver xsi:nil="true" istället, slå in utdatan i en liten XSLT eller efterbearbeta — konverteraren håller sig till vanliga tomma element för portabilitetens skull.

Kommer datum och timestamps ut i ISO-8601?

Ja. SQL-litteraler som '2024-01-15 10:30:00', DATE '2024-01-15', TIMESTAMP '2024-01-15 10:30:00+00' och MySQL-varianten '2024-01-15T10:30:00' kommer alla ut som ISO-8601-strängar (2024-01-15T10:30:00Z när tidszon finns, annars bara 2024-01-15T10:30:00). Det är formatet som XML-stacken i varje större språk parsar utan krångel.

Kan jag klistra in bara ett CREATE TABLE — utan rader?

Ja. Ett CREATE TABLE med bara schema ger ett XML-skelett: ett element per kolumn, tomt, i den ordning kolumnerna deklarerades. En bra startpunkt för en exempel-payload, ett XSD-utkast eller en testfixture som du fyller i för hand. Datatyperna i CREATE TABLE läses som hintar (datum förblir datum, numeriska förblir numeriska) men de tomma elementen bär ingen typinfo i utdatan.

Tänk om min query innehåller flera tabeller?

Varje INSERT- eller CREATE TABLE-sats producerar sin egen toppnivåsektion i utdatan, i den ordning du skrev dem. Ett blandat skript som skapar orders, lägger in tre orders och sedan lägger in sex order_items blir ett dokument med tre tabellsektioner, var och en inpackad i ett behållarelement. Parsern försöker inte joina eller relatera dem — den bevarar bara strukturen du klistrat in.

Tar den bort schemaprefix som public.orders eller dbo.Orders?

Ja. XML-elementnamn får inte innehålla punkter, så public.orders blir <orders>, dbo.Orders blir <Orders> och my_schema."User Table" blir <User_Table> (mellanslag blir understreck eftersom XML-namn inte heller får ha mellanslag). MySQL-backticks, dubbelcitat från PostgreSQL och hakparenteser från SQL Server tas alla bort på samma sätt.

Andra verktyg du kan behöva

SQL till XML är bara en pusselbit. De här passar bra ihop med det: