§

Options

Weergave
Nauwkeurigheid
Preprocessing
§

Input

Nederlandse ontwikkelteams stoten dagelijks tientallen keren op een diff-oppervlak: Git-pull-request-reviews op GitHub en GitLab, contractwijzigingsregistratie in Microsoft Word, collegiale beoordelingsworkflows in Google Docs. Overheidsleveranciers die werken onder de BIO (Baseline Informatiebeveiliging Overheid) moeten vaak configuratiebestanden en toegangscontrolelijsten vergelijken vóór het vastleggen van wijzigingen in BIV-geclassificeerde omgevingen, en die fragmenten in een publieke SaaS-vergelijkingsservice plakken is doorgaans een beleidsschending. De vergelijking uitvoeren in een browsertabblad — geen upload, geen account, geen log bij een derde partij — houdt de workflow snel voor engineers en acceptabel voor de mensen die het gegevensverwerkingsbeleid schrijven.

Hoe diffalgoritmen werken

Elke diffweergave op deze pagina wordt gegenereerd door het Myers-algoritme — een techniek uit 1986 van Eugene W. Myers die het kortste bewerkingsscript tussen twee tokenreeksen vindt in O((N+M)D) tijd, waarbij D de bewerkingsafstand is. Het algoritme is gebaseerd op het Longest Common Subsequence-probleem en de engine draait volledig in je browser met behulp van de open-source jsdiff-bibliotheek.

  1. De invoer tokeniseren — Vóór het vergelijken splitst het algoritme elke invoer op in een reeks tokens. Regelnauwkeurigheid splitst op nieuwe regels; woordnauwkeurigheid splitst op witruimte- en interpunctiegrenzen; tekennauwkeurigheid behandelt elk Unicode-codepunt als zijn eigen token.
  2. De bewerkingsgraph opbouwen — Het Myers-algoritme modelleert de vergelijking als een pad door een 2D-raster waarbij naar rechts bewegen betekent "verwijderen uit origineel", naar beneden bewegen betekent "invoegen uit gewijzigde versie" en diagonaal bewegen betekent "token komt overeen in beide". Het algoritme vindt het kortste diagonaalzware pad.
  3. De LCS extraheren — De diagonale bewegingen in het kortste pad traceren de Longest Common Subsequence — de tokens die in beide invoeren in dezelfde relatieve volgorde voorkomen. Elk token in de LCS is "ongewijzigd"; al het andere is ofwel een toevoeging of een verwijdering.
  4. Voorbewerkingsopties toepassen — Als je “Hoofdletters negeren” inschakelt, worden beide invoeren vóór de LCS-doorgang in kleine letters omgezet zodat “HALLO” en “hallo” als identiek worden beschouwd. “Witruimte negeren” vouwt meerdere spaties samen tot één. “Elke regel bijsnijden” verwijdert voorloop- en nalopende witruimte per regel vóór de vergelijking.
  5. De geselecteerde weergave renderen — De uitvoer is hetzelfde LCS-resultaat weergegeven op drie manieren: Naast elkaar toont origineel links en gewijzigd rechts in een tweekoloms raster met rode en groene rijmarkeringen. Unified toont een enkele kolom met − en + voorvoegsels, zoals de uitvoer van git diff. Inline toont verwijderingen als rode doorhaling en toevoegingen als groene onderstreping binnen dezelfde tekststroom.
  6. De samenvattingsstrook berekenen — Na het renderen telt de tool hoeveel tokens zijn toegevoegd, verwijderd en ongewijzigd, en berekent de gelijkenis als de verhouding van ongewijzigde tokens tot de grotere van de twee invoerlengten. Een gelijkenis van 100% betekent dat de invoeren identiek zijn na voorbewerkingsopties.

Waarom een diff checker gebruiken

  • Code review zonder een Git-client — Plak twee versies van een configuratiebestand, een SQL-migratie of een shell-script en zie wat er is veranderd zonder een repo te klonen, van branch te wisselen of te wachten op een CI-pipeline. De tool is handig voor snelle reviews tijdens pair programming, voor aannemersopdrachten waarbij de andere kant geen Git-geschiedenis heeft gedeeld, en voor legacy-codebases die dateren van vóór versiebeheer. De unified weergave produceert uitvoer die je direct in een chatthread of een ticket kunt kopiëren.
  • Contracten en documentwijzigingen — Diff op woordniveau toont welke termen tussen contractconcepten zijn verschoven sneller dan het Track Changes-paneel van Word. Plak clausule A van het eerste concept en clausule B van de uitvoeringsversie en de wijziging licht op rood-op-groen op de exacte zin die is aangepast. Juridische medewerkers en inkoopteams gebruiken dit om last-minute wijzigingen te verifiëren voordat een contract wordt ondertekend.
  • Essay- en conceptrevisies — Schrijvers die een eerste concept vergelijken met een bewerkte versie kunnen overschakelen naar woordnauwkeurigheid om elke vervanging, invoeging en schrapping te zien zonder beide versies opnieuw te lezen. Dezelfde workflow werkt voor vertalers die wijzigingen controleren tegen de brontekst, voor redacteuren die controleren of een copyedit de stem van de auteur heeft behouden, en voor journalistieke teams die een gepubliceerd artikel afstemmen op het ingediende concept.
  • Logboek- en configuratievergelijking — Systeembeheerders die twee serverconfiguratie-snapshots, twee cron-planningen of twee ps aux-uitvoeren vergelijken, kunnen regelnauwkeurigheid gebruiken om de enige gewijzigde parameter in een bestand van 200 regels in seconden te vinden. Combineer het met de optie Witruimte-negeren en een ruis-overbruggende uitlijningsdiff krimpt in tot de parameterwijzigingen die er werkelijk toe doen.

Veelvoorkomende toepassingen

Tekstdiff duikt op aan het einde van elke bewerkingscyclus in schrijf-, ontwikkel- en operationeel werk.

  • Pull-request-review: plak twee functie-implementaties naast elkaar om de logicawijziging te begrijpen vóór goedkeuring, zonder de overhead van het uitchecken van de branch.
  • Internationalisatie-QA: vergelijk een Engelse brontekenreeks met het vertaalde equivalent op woordniveau om invoegingen, weglatingen of terminologiewijzigingen te detecteren die de vertaler mogelijk heeft geïntroduceerd.
  • Incidentanalyse: vergelijk twee Kubernetes-manifests-snapshots of twee "docker inspect"-uitvoeren op regelniveau om de configuratiewijziging te isoleren die aan een uitval voorafging.

Een praktijkvoorbeeld

Neem een serverconfiguratie van vijf regels. Origineel: host=localhost, port=5432, dbname=app_db, user=app, password=secret. Gewijzigd: host=db.prod.example.com, port=5432, dbname=app_db, user=app_prod, password=secret. Met regelnauwkeurigheid en Naast-elkaars-weergave toont regel 1 rood links (host=localhost) en groen rechts (host=db.prod.example.com), regel 4 toont rood (user=app) en groen (user=app_prod), en regels 2, 3 en 5 blijven ongewijzigd aan beide kanten. De samenvattingsstrook meldt 2 toevoegingen, 2 verwijderingen, 3 ongewijzigd, en een gelijkenis van 60% — drie van de vijf regels behouden. Wissel naar woordnauwkeurigheid en de diff wordt scherper: alleen de waarden rechts van = op regels 1 en 4 lichten op, de sleutels blijven ongewijzigd, en de gelijkenis stijgt naar ongeveer 85% omdat de LCS nu host, user en de omliggende interpunctie als behouden beschouwt.

Draait dit in mijn browser?

Ja. De volledige diffberekening draait client-side met behulp van de open-source jsdiff-bibliotheek die met de pagina wordt geladen. Niets wat je typt, plakt of vergelijkt wordt naar een server gestuurd. Je kunt dit zelf verifiëren: open browser DevTools, wissel naar het tabblad Netwerk, wis het log, klik op Vergelijken, en bevestig dat er geen netwerkverzoeken worden gedaan voor de vergelijkingsstap.

Wat betekent het gelijkenispercentage?

Gelijkenis wordt berekend als ongewijzigde tokens / max(totale tokens in origineel, totale tokens in gewijzigd). Een score van 100% betekent dat de twee invoeren identiek zijn na het toepassen van je voorbewerkingsopties (hoofdlettervouwing, witruimtesamenvoegen, regelafsnijden). Een score van 0% betekent dat er geen token wordt gedeeld tussen de invoeren. De maatstaf is een ruwe benadering van bewerkingsafstand — handig als snelle indicator — niet een plagiaat- of originaliteitsscore.

Kan ik JSON / YAML / XML semantisch vergelijken?

Niet in deze tool. Dit is een vergelijking op tekstniveau, dus alleen-opmaak-wijzigingen van JSON of XML tonen nog veel wijzigingen ook al zijn de gegevens logisch identiek. Het herordenen van objectsleutels in JSON toont ook wijzigingen, ook al behandelen de meeste parsers sleutelvolgorde als onbelangrijk. Voor een echte semantische diff die geparseerde objectbomen vergelijkt en sleutelvolgorde en opmaak negeert, plannen we een speciale JSON Diff-tool. Normaliseer voor nu beide invoeren naar dezelfde inspringing en sleutelvolgorde vóór het hier plakken.

Hoe verschillen unified- en naast-elkaarweergaven?

Naast elkaar rendert twee kolommen: het origineel links en de gewijzigde versie rechts, met verwijderde regels rood gemarkeerd links en toegevoegde regels groen gemarkeerd rechts. Ongewijzigde regels verschijnen in beide kolommen op dezelfde rij. Unified rendert een enkele kolom met een voorvoegsel en rode achtergrond voor verwijderde regels en een + voorvoegsel en groene achtergrond voor toegevoegde regels — dezelfde lay-out die git diff naar je terminal drukt. Gebruik unified als je het resultaat als patchbestand wilt kopiëren of in een code-reviewthread wilt plakken. Gebruik naast elkaar als de visuele uitlijning van wat wat heeft vervangen er meer toe doet dan de ruwe patchtekst.

Plak het origineel links, de gewijzigde versie rechts, kies een weergave en een nauwkeurigheid, en de vergelijking verschijnt in milliseconden. Schakel Live-modus in en de diff wordt bij elke toetsaanslag opnieuw uitgevoerd terwijl je een van beide kanten bewerkt. Download het resultaat als een standaard unified .patch-bestand dat git apply direct verwerkt. Geen upload, geen account, geen leveranciers-API-sleutel, geen quota.