Indsæt to konfigurationsfiler side om side og se præcis hvilke nøgler, værdier og kommentarer der er ændret. Virker til .env, TOML, INI, .properties og .conf.
Et gratis browserværktøj til at diffe konfigurationsfiler. Indsæt en staging-.env til venstre, produktionsversionen til højre, og manglende nøgler, ændrede værdier og forældede kommentarer lyser straks op. Samme flow for en pyproject.toml før og efter en Poetry-opdatering, en nginx.conf du er ved at reloade, eller en Java-application.properties der flytter mellem miljøer.
Diffen er på tegnniveau. Ingen parser, intet skema, ingen mening om hvilken dialekt du indsætter. Det er bevidst. Konfigurationsfiler deler ikke en samlet grammatik. INI har ingen formel spec, og hver parser er uenig om quoting og escapes. TOML 1.0 har en stram grammatik men tilføjer typede værdier. .env-filer har ingen spec overhovedet, kun det dotenv eller din shell tilfældigvis gør.
Hvis du kom efter almindelig prosa, er vores tekst-diff-værktøj det rette valg. Til YAML-konfiguration (Kubernetes-manifests, Helm-values, Ansible-playbooks) brug YAML-diff. Til config der kommer som JSON (VS Code-indstillinger, npm-package.json, Terraform-tfstate) håndterer JSON-diff objekt-omarrangering renere end en tekst-diff.
Diffen kører på tegnniveau, og derefter rykker en semantisk efterbehandlingstur highlightsne så de lander på hele nøgler, hele værdier og hele kommentarlinjer i stedet for støj midt i et token. Indsættelser vises i grønt i højre panel, sletninger i rødt til venstre. Ændringstælleren i hver header fortæller hvor mange distinkte ændringer algoritmen fandt.
Konfigurationsformater varierer nok til at én parser ikke kan tjene dem alle, så dette værktøj forbliver bevidst formatagnostisk. .env er det løseste: de fleste loaders behandler hele højresiden som en streng, men nogle udvider $VAR og andre ikke, nogle ærer export, og quoting omkring værdier med mellemrum er parser-specifik. .properties-filer (Java-standarden, dokumenteret i java.util.Properties API) accepterer enten = eller : som separator og kræver Unicode-escapes som \u00e9 for ikke-ASCII-tegn. INI-filer i naturen spænder fra Windows-konventionen (sektioner i firkantede parenteser, semikolon for kommentarer) til den lidt anderledes dialekt som Pythons configparser-modul accepterer.
Tre ægte faldgruber værd at kende, før du stoler på en ren diff. Først, mellemrum til sidst på linjen. En værdi som API_KEY=abc med et farende mellemrum til sidst på linjen er en anden streng for de fleste loaders, og diffen flagger det, men mennesker ser sjældent det skyldige mellemrum. Dernæst, linjeafslutninger. En fil committet på Windows med CRLF og en skrevet på Linux med LF har samme indhold, men diffen viser hver linje som ændret; formatér begge sider eller normalisér afslutningerne først. Til sidst, UTF-8 byte order mark. Notepad på Windows skriver stadig glad et BOM i starten af en gemt .env, hvilket de fleste loaders snubler over og som viser sig som en spøgelses-diff på et enkelt tegn på linje 1.
To tekstpaneler, én diff. Intet uploades. Intet logges.
Indsæt den gamle config til venstre, den nye til højre. Eller klik Upload på en af siderne for at indlæse en .env-, .toml-, .ini-, .properties- eller .conf-fil direkte. Sample-knappen fylder begge paneler med et lille .env-eksempel, så du ser hvordan værdiændringer, nye nøgler og fjernede poster renderes, før du indsætter din egen.
Klik Format på hvert panel for at trimme afsluttende mellemrum og anvende konsekvente linjeafslutninger. Det dræber den mest almindelige klasse af falske positiver: to filer der ser identiske ud, men diffes som helt forskellige fordi den ene er gemt med CRLF og den anden med LF. Diffen fokuserer på rigtige nøgle- og værdiændringer, når begge sider er enige om mellemrum.
Sletninger vises med rød highlight til venstre, indsættelser med grøn highlight til højre. Scroller du den ene side, følger den anden med. Kommentarer og udkommenterede nøgler diffes som almindelig tekst, så en nøgle du fjernede ved at sætte # foran, vises som den tilføjede kommentarlinje frem for som den slettede nøgle.
Du starter en feature branch lokalt, det virker fint, så crasher det på staging fordi STRIPE_WEBHOOK_SECRET mangler i stagings .env. Indsæt den fungerende lokale fil mod stagings, og den manglende nøgle, den ændrede DATABASE_URL-host og det forældede LOG_LEVEL=debug dukker alle op i ét pas. Hurtigere end at gå begge filer linje for linje igennem, og meget sikrere end at køre et script der printer begge variabelsæt til en terminal.
Poetry eller uv har lige skrevet din pyproject.toml om efter et poetry update. Diff den tidligere committede version mod working tree for at bekræfte de faktiske opgraderinger: fastapi gik fra 0.110.0 til 0.115.4, en ny [tool.ruff.lint]-tabel dukkede op, og build-system.requires-pin'en flyttede sig. TOML 1.0-spec'en er stram nok til at diffen normalt er ren og let at læse.
At reloade nginx med en ødelagt config tager et produktionssite ned hurtigere end næsten alt andet på en server. Før nginx -s reload: indsæt den kørende nginx.conf mod den foreslåede og bekræft at ændringen er præcis det du mente: en ny upstream-blok, et opdateret proxy_pass-mål, en TLS-cipher-suite-udskiftning. Diffen fanger det utilsigtet manglende semikolon hver gang.
En service genstarter i loop efter en deploy. Diff den fungerende foo.service mod den nye, og du finder normalt årsagen inden for tredive sekunder: et ændret ExecStart, en bortfalden Environment=-linje, et strammet NoNewPrivileges. Samme flow for supervisord-.conf-blokke, runit-run-skripts og de forskellige .ini-agtige init-configs man stadig ser på ældre maskiner.
Terraform-variabler i terraform.tfvars, Pulumi-stack-configs, Ansible-group_vars, Helm-values til Kubernetes ConfigMaps. Hvert miljø har sin egen kopi, og den eneste sikre måde at merge dem på er at diffe. Indsæt prod mod staging, og driften springer i øjnene: en region pinned til us-east-1 i den ene og us-west-2 i den anden, en instance-type nogen hævede under en incident og aldrig rullede tilbage, et IAM-role-ARN der peger på den forkerte konto.
En ny ingeniør starter, kopierer .env.example fra repoet, og buildet falder stadig på hendes første PR fordi skabelonen er drevet fra det CI-pipelinen rent faktisk forventer. Diff den committede .env.example mod en kendt-god .env fra en hvis builds går igennem, og de manglende nøgler dukker op som rødt til venstre eller grønt til højre. Samme trick virker til Taskfile-env-blokke, GitHub Actions env:-sektioner og direnv-.envrc-filer.
Et kort spickseddel over de formater dette værktøj ser oftest. Konfiguration er rodede end sit ry antyder, og forskellene nedenfor er der hvor de fleste differ kører af sporet.
| Topic | What this tool does |
|---|---|
| Format-dialekter | INI (ingen formel spec, dialekter pr. parser), TOML 1.0 (stram, typed), .env (ingen spec, parser-defineret), .properties (Java, se java.util.Properties), .conf (pr. applikation: nginx, Apache, sshd_config er alle forskellige). |
| Kommentartegn | INI: ; eller #. TOML: kun #. .env: kun #, og kun i starten af linjen i de fleste loaders. .properties: # eller !. nginx .conf: kun #. |
| Sektionshovedlinjer | INI og TOML bruger [section]. TOML tilføjer indlejrede tables via [a.b.c] og arrays af tables via [[a]]. .env og .properties er flade, uden sektioner. nginx bruger { ... }-blokke i stedet for headers. |
| Værditypber | TOML har typede værdier: strenge, ints, floats, bools, datoer, arrays, tables. INI, .env og .properties er kun streng; applikationen bestemmer hvordan true eller 42 skal parses. |
| Interpolation og udvidelse | De fleste dotenv-loaders udvider ikke $VAR som standard. Nogle gør (dotenv-expand, direnv, shell-sourcing via source .env). TOML udvider aldrig. INI sjældent; Pythons configparser understøtter ${section:key} hvis du opt-in:er. |
| Mellemrum til sidst | En reel buggkilde. FOO=bar med et efterfølgende mellemrum sætter FOO til "bar " i de fleste loaders, hvilket fejler streng-lighedstjek nedstrøms. Trim altid eller cita. |
| Linjeafslutninger | CRLF (Windows) vs LF (Unix). To identiske filer gemt på forskellige OS'er diffes som hver-linje-ændret. Brug Format-knappen eller normalisér linjeafslutningerne (dos2unix, git config core.autocrlf) før diffning. |
| Encoding og BOM | TOML kræver UTF-8. .properties krævede historisk ISO-8859-1 med \uXXXX-escapes, men moderne Java accepterer UTF-8 via Properties.load(Reader). En UTF-8 BOM i starten af en .env er en klassisk spøgelses-diff-årsag; Notepad på Windows skriver stadig en som standard. |
Nej. Det er en tekst-diff. TOML skelner mellem strenge, integers, floats, booleans, datoer og arrays, men diffen behandler hver linje som almindelig tekst og viser hvilke tegn der er ændret. Det er normalt fint, fordi konfigurationsændringer er tegnændringer i forvejen. Har du virkelig brug for en typed sammenligning, så parse begge filer i dit foretrukne sprog (Pythons tomllib, Rusts toml-crate, Gos pelletier/go-toml) og sammenlign de resulterende maps. For 95%-tilfældet fanger tekst-diffen det du skal fange.
Det gør du normalt ikke, og du bør være glad for at værktøjet flagde det. En linje der går fra API_KEY=abc til #API_KEY=abc er semantisk meningsfuld: nøglen er nu deaktiveret. Diffen fremhæver kommentar-præfix-ændringen, hvilket er præcis hvad en menneskelig reviewer bør se under en config-gennemgang. Vil du virkelig ignorere kommentar-støj, formatér så begge sider for at smide rene kommentarlinjer ud før indsættelse, men det er sjældent det rette træk for en sikkerhedsrelevant fil.
Indsæt begge filer, kør diffen, og enhver nøgle der findes på den ene side og mangler på den anden, dukker op som en rød sletning eller en grøn indsættelse af hele linjen. Diffen prøver ikke at justere nøgler strukturelt, så en nøgle omarrangeret til en anden position dukker op én gang som sletning og én gang som indsættelse. For en helt rækkefølgeuafhængig sammenligning, sortér først begge filer efter nøgle (sort .env på Unix) og diff derefter. Den formatagnostiske tilgang fanger manglende nøgler uden at have brug for en parser.
Ja, dit input forlader aldrig browseren. Diffen kører helt på klienten. Ingen server-upload, ingen telemetri på panel-indhold, ingen analytics der fanger det du skrev. Det er med vilje, fordi .env-differ er blandt de mest tillidskrævende flows på dette site. Er du paranoid (og det bør du være lidt), så åbn browser-devtools og bekræft at netværksfanen forbliver tom mens du indsætter. For organisationer der foretrækker et helt air-gapped værktøj: åbn sitet offline én gang, og de cachede assets virker uden yderligere netværksadgang.
INI er en konvention; TOML er en specifikation. INI voksede op på Windows, har ingen formel grammatik, og hver parser håndterer kanttilfælde (quoting, escapes, listeværdier, indlejrede sektioner) lidt forskelligt. TOML 1.0 er en stram, versionsstyret spec brugt af Cargo, Poetry, Hugo og i stigende grad Python-pakning via pyproject.toml. Begge bruger [section]-headers og key = value-par, så de ligner hinanden ved første blik, men TOML tilføjer typede værdier, datetime-literaler og inline tables som klassiske INI-filer ikke har.
Nej. API_KEY=abc og api_key=abc er forskellige linjer for diffen, fordi de er forskellige bytes. De fleste loaders er også store-/små-bogstavsfølsomme (dotenv, java.util.Properties, configparser som standard), så det matcher virkeligheden. Mellemrum omkring = bevares som det er, hvilket betyder noget, fordi nogle strammere parsers (især visse Bash-sourcing-mønstre) afviser FOO = bar med mellemrum og kun accepterer FOO=bar. Format-knappen trimmer mellemrum til sidst på hver linje, og det er det eneste normaliseringstrin den anvender.
Dine konfigurationsfiler forlader aldrig din browser. Diffen, formateren og hver byte af dit input bliver lokalt på din maskine. Ingen analytics på panel-indhold, ingen logs, ingen upload. Det vejer tungere her end på de fleste diff-værktøjer, fordi .env-filer rutinemæssigt indeholder database-passwords, API-nøgler og OAuth-client-secrets, og at indsætte dem i et værktøj der pendler dem gennem en server, ville være en reel sikkerhedshændelse. Baggrundslæsning om formaterne: TOML 1.0, INI-filer og Unix-konceptet miljøvariabler. For secrets der slet ikke bør leve i en fil, kig på sops, HashiCorp Vault eller AWS Parameter Store.