Artikkel
Sammenligne kodebitene uten å laste dem opp
Hver gang du limer inn to filer i et diff-verktøy på nett, forlater den koden maskinen din. Konfigurasjonsfiler, databasespørringer, API-nøkler begravet i et .env-utdrag: alt dette reiser til en server du ikke kontrollerer. Denne artikkelen dekker hvordan diff-algoritmer fungerer, hva granularitetsalternativer betyr i praksis, og hvorfor det er viktig å holde sammenligningen lokal.
Hva en diff beregner
Et diff-verktøy tar to tekster og finner det minimale settet med endringer som konverterer den ene til den andre. Kjerneprinsippet er den lengste felles delsekvensen, eller LCS: den lengste sekvensen av linjer (eller tokens) som vises i begge tekster i samme rekkefølge, selv om de ikke er tilstøtende. Alt som ikke er i den felles delsekvensen er enten et tillegg i den nye versjonen eller en sletting fra den gamle. Den klassiske algoritmen for dette er fra Myers (1986), som finner det korteste redigeringsskriptet i O((N+M)D) tid, der N og M er lengdene til de to tekstene og D er antall redigeringer. I praksis legger de fleste verktøy til et forbehandlingstrinn for å ignorere ledende felles linjer og etterfølgende felles linjer, noe som reduserer problemet til det endrede området. Resultatet er en patch: en sekvens av hunks, der hver beskriver en sammenhengende blokk med kontekstlinjer, slettinger og tillegg. Dette er formatet som brukes av Unix diff, Git og de fleste kodegjennomgangsverktøy.

Linje-, ord- og tegnkornethet
Kornetheten til en diff bestemmer hva som teller som en sammenligningsenhet. Linjebasert diff er standarden i de fleste verktøy: hver linje behandles som ett enkelt token. Dette er raskt og produserer utdata som er enkle å lese i kontekst, men det merker hele linjen som endret selv om bare ett ord på den linjen er forskjellig. Diff på ordnivå deler hver linje inn i ord før LCS kjøres. Dette gir et mer detaljert bilde av hva som endret seg innen en linje, noe som er nyttig for prosa, konfigurasjonsverdier eller JSON. Diff på tegnnivå går videre og kan markere én enkelt endret bokstav inne i en lang identifikator. Hvitromhåndtering legger til støy. En linje som slutter med CRLF og den samme linjen som slutter med LF vil vises som forskjellige under en streng bytessammenligning. De fleste verktøy tilbyr et flagg for å normalisere linjeavslutninger før differensiering. Tilsvarende kan etterfølgende mellomrom, tabulatorkontra-mellomrom-innrykk og tomme linjer alle produsere spuriøse diff-utdata. Å aktivere hvitromnormalisering er vanligvis riktig standard når kode fra ulike redaktører eller operativsystemer sammenlignes.
Personvernsrisikoen ved diff-verktøy på nett
Nettbaserte diff- og pastebin-tjenester er praktiske: åpne en URL, lim inn to utdrag, få fargekodet utdata. Problemet er at teksten du limer inn overføres til en tredjeparts server. Avhengig av tjenesten kan teksten bli logget, indeksert, lagret på ubestemt tid eller delt med analyseleverandører. Dette er viktigst når koden inneholder sensitivt materiale. Hardkodede legitimasjonsinformasjon, interne vertsnavn, proprietær forretningslogikk eller personlig identifiserbar informasjon kan alle havne i et innlim. Selv uten eksplisitte hemmeligheter kan strukturen til intern kode avsløre arkitektoniske beslutninger du helst vil holde privat. Risikoen er ikke hypotetisk. Sikkerhetsforskere har gjentatte ganger funnet legitimasjonsinformasjon og interne tokens i offentlige innlimmer. Noen tjenester beholder innlimmer selv etter at en bruker sletter dem, fordi kopier finnes i cacher eller sikkerhetskopier. Det er ingen måte å bekrefte hva en ekstern tjeneste gjør med teksten når den ankommer. Det eneste pålitelige tiltaket er å holde diff-en lokal, noe som betyr å kjøre den i et verktøy som aldri sender teksten over nettverket.

Praktiske bruksområder for en lokal diff
Diff er ikke bare for kodegjennomgang. Noen vanlige tilfeller der en lokal diff er nyttig: Gjennomgang av redigeringer i et dokument eller en konfigurasjonsfil før innlevering. Sammenligning av to versjoner av en Dockerfile, en Nginx-konfig eller et Kubernetes-manifest for å forstå nøyaktig hva som endret seg mellom distribusjoner. Kontroll av konfigurasjonsdrift mellom miljøer. Hvis produksjons- og iscenesettingsconfigs skal være identiske bortsett fra vertsnavn og hemmeligheter, viser en diff umiddelbart ubevisste avvik. Sammenligning av API-responser under feilsøking. Å lime inn to JSON-nyttelaster fra en REST- eller GraphQL-API og kjøre en diff på ordnivå peker ut tillagte felt, endrede verdier eller fjernede nøkler uten å lese gjennom hundrevis av linjer manuelt. Gjennomgang av LLM-generert kode mot en basislinje. Når en modell skriver om en funksjon, viser en diff på linjenivå hvilken logikk som endret seg og hvilken som forble den samme, raskere enn å lese begge versjonene uavhengig. I alle disse tilfellene kan teksten som er involvert være sensitiv, og å holde den borte fra en ekstern server er det naturlige valget.
Gjøre det i nettleseren, uten å laste opp
Text-diff-verktøyet på dette nettstedet kjører hele diff-beregningen i nettleseren din ved hjelp av JavaScript. Du limer inn to tekster i de to panelene, og diffen gjengis umiddelbart, linje for linje, opptil 3000 linjer per side. Ingenting sendes til en server. Teksten forlater aldri enheten din. Implementasjonen bruker en standard LCS-basert algoritme som opererer på linjer: hver linje er et token, og verktøyet finner ut om den er uendret, lagt til eller fjernet ved å finne den lengste felles delsekvensen mellom de to versjonene. Uendrede linjer vises uten utheving, tillagte linjer i grønt, fjernede linjer i rødt, ved siden av en løpende telling av tillegg og slettinger. Det finnes ingen ord- eller tegnnivå-modus og ingen bryter for hvitromnormalisering i dag, så en linje som bare skiller seg i etterfølgende mellomrom eller linjeskift-stil, vises fortsatt som endret. Fordi beregningen kjører klientsiden, fungerer den frakoblet. Det er ingen konto, ingen historikk, ingen oppbevaring. Du kan sammenligne en lokal konfigurasjonsfil mot en mal, gjennomgå en patch før du bruker den, eller sjekke to API-responser uten at noe av den teksten når en tredjepart.
Verktøy i denne artikkelen
Ofte stilte spørsmål
Er linjebasert diff eller ordbasert diff bedre for kode?
For de fleste kodegjennomgangsoppgaver er linjebasert diff standarden og den enkleste å lese, fordi kode er strukturert etter linjer. Ordbasert diff kan hjelpe når linjer er lange og bare en liten del har endret seg, for eksempel i en JSON-verdi på én linje, men dette verktøyet sammenligner kun på linjenivå; i så fall bruker du den uthevede linjen som en pekepinn og ser selv etter den mindre forskjellen i den.
Hvorfor utgjør nettbaserte diff-verktøy en personvernsrisiko selv om de bruker HTTPS?
HTTPS beskytter teksten under transport mot avlytting, men beskytter den ikke når den ankommer serveren. Tjenesteleverandøren har full tilgang til det limte innholdet og kan logge, lagre eller dele det. TLS handler om transportsikkerhet, ikke om hva mottakeren gjør med dataene.
Lagrer text-diff-verktøyet noen historikk over tidligere sammenligninger?
Nei. Verktøyet har ingen backend og sender ingen nettverksforespørsler. Når du lukker eller laster inn fanen på nytt, er teksten borte. Det er ingen konto, ingen lagret historikk og ingen serverside-logg.