Hva er Sammenlign tekst?
Sammenlign tekst er et nettverktøy som tar to tekster og viser deg nøyaktig hva som er endret mellom dem. Lim inn den gamle versjonen på den ene siden og den nye på den andre, så lyser forskjellene opp i farge. Grønt er lagt til, rødt er fjernet.
Det fungerer med hvilken som helst ren tekst: avsnitt, kodebiter, konfigurasjonsfiler, kontraktsklausuler, oversettelser. Linjer som stemmer forblir nøytrale, så øyet går rett til det som er ulikt.
Bruk det når du ikke vil åpne et skrivebordsverktøy, men ønsker et nøyaktig resultat med ett klikk. Ingen registrering, ingen opplasting, ingen logg over det du sammenlignet.
Hva det gjør
Compare Text tar to tekster og merker det som er lagt til i grønt og det fjernede i rødt. Arbeidet skjer tegn for tegn, så et manglende komma eller et endret variabelnavn dukker tydelig opp. Motoren er Googles diff-match-patch-bibliotek (Apache 2.0). Den generelle teknikken kalles diff, og det underliggende problemet (å finne det minste settet av redigeringer mellom to strenger) reduseres til det klassiske longest common subsequence-problemet.
Motoren håndterer naturlig språk og kode like bra — samme type tilnærming som driver versjonsloggen i dokumentredigerere. Hvis du sammenligner strukturerte data i stedet for prosa, parser JSON-diff-verktøyet vårt først begge sider og ignorerer nøkkelrekkefølgen: annet problem, annet verktøy.
Ingen server. JavaScript leser teksten din med FileReader-API-et, sammenligner og tegner resultatet i siden. Lukker du fanen, er det borte.
Slik sammenligner du to tekster
Tre trinn. Diff-en oppdateres mens du skriver, ingen knapp å trykke på.
- 1
Legg inn originalen
Lim inn i panelet til venstre, eller klikk Last opp for en .txt- eller .md-fil. Eksempel setter inn en kort prøvetekst.
- 2
Legg inn den nye versjonen
Lim inn eller last opp på høyre side. Når begge panelene har innhold, vises slettinger i rødt til venstre og tillegg i grønt til høyre.
- 3
Gå gjennom endringene
Du kan scrolle på en av sidene, begge panelene følger med. Overskriften viser hvor mange endringer som er funnet. Kopier eller last ned en av tekstene.
Når det er nyttig
Fange redline-endringer i en kontrakt
Lim inn V1 av en leverandøravtale til venstre og den merkede V2 til høyre. Klausuler om skadesløsholdelse, betaling og oppsigelse som stille har endret seg, kommer opp med én gang. Nyttig når motparten sender en ren kopi uten endringssporing slått på.
Korrekturlese utkast og redigeringer
Sammenlign utkastet ditt med redaktørens reviderte versjon, eller blogginnlegget ditt før og etter en korrektur. Hvert ord som er endret vises; du trenger ikke lese gjennom hele teksten på nytt for å finne setningen som falt ut.
Gå gjennom en oversettelsesrunde
Originalen på den ene siden, oversetterens revideringer på den andre. Se hvilke uttrykk som er omskrevet, og hvor redaktøren slo tilbake mot en ord-for-ord-oversettelse. Sparer en ny gjennomlesning av hele dokumentet når du stoler på den som gjennomgår.
Diff-e konfigurasjonsfiler
nginx.conf, systemd unit-filer, .env-maler. To versjoner side ved side på sekunder. Raskere enn å starte diff i en terminal når begge filer allerede ligger i utklippstavlen fra en chattetråd.
Sammenligne snapshot av loggfiler
Gårsdagens deploy-logg mot dagens, eller samme jobbs utdata fra to CI-kjøringer. Stabile linjer faller i bakgrunnen, og det nye feilmønsteret stikker fram. For loggfiler på flere MB, snevr inn med grep først.
Hurtigreferanse for tekst-diff
Grensetilfeller dette verktøyet oftest får fram, med begrunnelsen bak.
| Emne | Hva dette verktøyet gjør |
|---|
| Linjeskift | LF, CRLF og CR er forskjellige tegn. En Windows-fil (CRLF) sammenlignet mot en Unix-fil (LF) ser ut som om hver linje er forskjellig. Normaliser til LF i begge kilder, eller fjern carriage return-tegnene før sammenligning. |
|---|
| Mellomrom på slutten av linjen | Vises som en reell forskjell: uthevingen strekker seg forbi det synlige tegnet. Nyttig for å fange avsluttende mellomrom i YAML eller CSV som stille bryter parsere. |
|---|
| Unicode-normalisering | café med en pre-komponert é (U+00E9) er ett tegn; den dekomponerte formen e + kombinerende aksent (U+0301) er to. De rendres likt, men diff-er ulikt. Bruk Unicode Normalization Form C via String.prototype.normalize() for å få dem til å matche. |
|---|
| Match-granularitet | Tegnnivå under panseret, med en semantisk oppryddingsfase som grupperer endringer ved ordgrenser når den kan. Det er derfor korte vanlige ord noen ganger ser matchet ut på tvers av ellers urelatert tekst. |
|---|
| Filkoding | Opplastede filer leses som UTF-8 via FileReader API. Andre kodinger ser forvridde ut. Konverter på forhånd, eller lim inn fra et verktøy som allerede har dekodet filen. |
|---|
| Store inndata | Opp til et par hundre KB er sub-sekund. 1–2 MB føles merkbart tregere. Forbi 5 MB er rendringen — ikke selve diff-algoritmen — flaskehalsen. Snevr inn før innliming. |
|---|
| Tom side | Hvis ett panel er tomt, vises den andre siden i sin helhet som et tillegg (eller en sletting). Det er diff-en som oppfører seg riktig, ikke en feil. |
|---|
| Identiske inndata | Når begge sider matcher nøyaktig (inkludert mellomrom, linjeskift og Unicode-form) er det null endringer, og overskriftene viser ingen tellere. |
|---|
Ofte stilte spørsmål
Lagres teksten min?
Nei. Hele sammenligningen kjører i nettleseren din. Ingenting sendes til en server, logges eller lagres. Åpne DevTools og se på Network-fanen: det er ingen utgående forespørsler mens du sammenligner. Lukk fanen, og teksten din er borte.
Hva er forskjellen mellom dette og en JSON-diff?
En tekst-diff sammenligner tegn i rekkefølge, så å bytte rekkefølge på nøkler i JSON eller endre mellomrom dukker opp som forskjeller, selv når dataene er identiske. Hvis du sammenligner JSON spesifikt, bruk verktøyet Compare JSON: det parser begge sider først og er rekkefølgebevisst. For prosa, konfigurasjoner, vanlig kode eller alt som ikke er strukturerte data, er tekst-diff det du vil ha.
Håndterer det Windows- mot Unix-linjeskift (CRLF vs LF)?
Det sammenligner dem som de er, så en Windows-fil (CRLF) limt inn mot en Unix-fil (LF) ser ut som om hver linje er forskjellig, selv når innholdet samsvarer. Det er diff-en som fungerer riktig: inndataene er virkelig forskjellige. For å fikse det, normaliser linjeskift i begge kilder, eller fjern carriage return-tegnene før innliming.
Er det en størrelsesgrense?
Praktisk grense er minnet i enheten din. Tekster opp til et par hundre KB diff-es på godt under et sekund. Forbi 1 MB begynner nettleseren å merke det, mest fordi rendering av uthevingene blir kostbar. For enorme loggfiler eller hele bokmanuskripter, snevr først inn til den delen du faktisk er opptatt av.
Hvorfor ser diff-en noen ganger fragmentert ut?
Diff på tegnnivå prøver å justere korte felles delstrenger (the, a, enkeltbokstaver, skilletegn) der den kan. En semantisk oppryddingsfase grupperer dem i biter på ordnivå der det er mulig, men to urelaterte avsnitt gir likevel et fragmentert resultat. Algoritmen kan ikke vite når to tekster ikke var ment å sammenlignes.
Kan jeg sammenligne filer i ulike tegnkodinger?
Filer som lastes opp via opplastingsknappen leses som UTF-8 (FileReaders standard). Filer i andre tegnkodinger (Latin-1, Shift-JIS, Windows-1252) ser forvridde ut; konverter dem til UTF-8 først. For tekst som allerede ligger i utklippstavlen, har operativsystemet løst tegnkodingen før innliming, så det fungerer som regel uten videre.