Een klant van WP Adminify stuurde me ooit twee exports van zijn plugin instellingen - & quot; voor de update werkte alles; daarna is het admin menu kapot Niets anders veranderd." Twee JSON blobs, elk ongeveer 340 regels Ik las ze naast elkaar, twee keer, en was het vol vertrouwen met hem eens: identiek Niets veranderd Moet onze bug zijn.
Het was niet. Toen ik eindelijk stopte met het vertrouwen in mijn ogen en de twee bestanden verdeelde, was het daar op regel 217: een menuroltoets was verdwenen van "administrator" tegen "administrator "- met een achterliggende ruimte. 1 onzichtbaar personage. 2 keer persoonlijk voorbij gelezen, omdat menselijke ogen don't strings vergelijken; ze patroon-match vormen, en administrator en administrator dezelfde vorm hebben.
Dat ondersteuningsticket heeft mijn regel permanent gewijzigd: Als twee teksten langer zijn dan ongeveer tien regels, vergelijk ik ze niet door te lezen. ooit. Een diff-algoritme heeft geen snelkoppelingen voor patroonmatching om voor de gek te houden - het vergelijkt elk teken en rapporteert precies wat verschilt De Tekstdiff-tool Op Toolz.dev doet dit in uw browser, wat betekent dat klantconfiguraties, contracten en niet-afgegeven code nooit uw machine verlaten. Hier is hoe differen eigenlijk werkt en hoe je het goed kunt gebruiken.
tl;dr: Vergelijk nooit visueel teksten langer dan een paar regels - ogen missen achterliggende spaties, verwisselde cijfers en bewerkingen van één woord Plak beide versies in de Tekstdiff-tool: groen = toegevoegd, rood = verwijderd, berekend door dezelfde Myers-algoritmefamilie die aandrijft
git diff. goed doen Lijnmodus Voor code en configuraties, Woordmodus voor proza en contracten. Voor gestructureerde gegevens wordt de JSON-differentiatie Vergelijkt door betekenis in plaats van door tekst. Alles loopt aan de clientzijde.
Hoe werkt een diff-algoritme eigenlijk?
Het kernidee: vind de Langste gemeenschappelijke subreeks (LCS) van de twee teksten - de langste reeks regels (of woorden, of tekens) die in beide voorkomt, in dezelfde volgorde Alles in de LCS is "unchanged." Whatever's die in versie A is overgebleven is een verwijdering; whatever's die in versie B is achtergelaten is een toevoeging Een & quot;modified" regel is slechts een verwijdering en een toevoeging die toevallig naast elkaar zitten.
De standaardmanier om dit efficiënt te berekenen komt van Eugene Myers' paper, "Een O(nd) verschilalgoritme en zijn variaties". Het elegante deel is wat de complexiteit gebonden zegt: N is de invoergrootte, maar re is de Aantal verschillen. Twee vrijwel identieke teksten diffunderen vrijwel onmiddellijk, hoe lang ze ook zijn, omdat het algoritme & #39;s schalen met hoe verschillend ze zijn, niet alleen hoe groot. Dat en #39; waarom het verspreiden van twee configuraties van 300 regels die één regel verschillen onmiddellijk aanvoelt - het algoritme doet bijna niets, wat precies de situatie is waarin je ogen het meeste werk doen en falen.
Dezelfde algoritmefamilie is de standaard engine in git diff, GNU diff, en de meeste vergelijkingstools die je ooit hebt gebruikt. (Git biedt ook patience en histogram varianten die soms meer voor mensen leesbare groeperingen van dezelfde veranderingen produceren - de stand van wijzigingen is hetzelfde, de presentatie verschilt.)
Een belangrijke niet voor de hand liggende eigenschap: een diff is niet altijd uniek. Als u een lege regel toevoegt tussen twee bestaande lege regels, is "Welke" lege regel nieuw is echt dubbelzinnig, en verschillende tools kunnen verschillende wijzen op de markering. Beide antwoorden zijn correct.
Lijn-, woord- of karakterverschil - Welke modus wanneer?
De granulariteit die je vergelijkt bij verandert waar de output goed voor is. Als je dit verkeerd doet, is de belangrijkste reden waarom mensen diff-output "ruis" vinden."
| lijnniveau | woordniveau | Karakterniveau | |
|---|---|---|---|
| vergelijking | Hele lijnen als atomen | Individuele woorden | Individuele karakters |
| Een bewerking van één woord toont als | Hele regel verwijderd + opnieuw toegevoegd | Alleen dat woord | Alleen de gewijzigde letters |
| het beste voor | Code, Configs, CSV-rijen | Proza, Contracten, Docs | Typo's, hashes, gecodeerde strings |
| zwakke plaats | Bewerkingen met lange alinea's: je jaagt nog steeds binnen de lijn | Lawaaierig over gereflowde/gereplofte tekst | Onleesbaar voor grote bewerkingen |
| Klassieke gebruiker | git diff |
Juridische Blackline / Redactie | "Deze twee API-sleutels zien er identiek uit" |
concreet voorbeeld. origineel: The quick brown fox jumps over the lazy dog. gewijzigd: The quick red fox leaps over the lazy cat.
- Lijnmodus markeert de hele zin als gewijzigd - nauwkeurig, nutteloos.
- Woordmodus hoogtepunten precies
brown→red,jumps→leaps,dog→cat. - Karaktermodus is hier overkill, maar het is de enige modus die zou vangen
admlnistratorversus Amerikaans wagenadministrator.
Vuistregel: gestructureerde tekst (één zinvolle verklaring per regel) wil de regelmodus; vloeiende tekst wil woordmodus; karaktermodus is een vergrootglas dat je eruit haalt als de andere twee zeggen "gewijzigd" en je kunt niet zien waarom. Mijn trailing-space-bug is de canonieke karakter-mode geval.
Wanneer is een op zichzelf staande diff-tool beter dan git?
Git's diff is uitstekend Voor dingen die in dezelfde repository leven. Een verrassende hoeveelheid vergelijkingswerk is niet:
Steun tickets. Het scenario uit mijn intro - twee instellingen exporteert van een klant Ze' staan niet in een repo Plakken beide in de Tekstdiff-tool En het antwoord verschijnt in seconden in plaats van twee mislukte doorlezingen.
Config drift. Staging Nginx Config VS Productie Nginx Config. gangbaar .env VS de back-up van voordat dingen kapot gingen. git diff Kan geen bestanden zien op twee verschillende servers; Copy-Paste kan.
Formatterverificatie. Je hebt mooier (of PHPC's of zwart) door een bestand gelopen en wilt vertrouwen dat het veranderde Alleen formatteren. Verschil de voor en na: als je iets anders ziet dan witruimte, aanhalingstekens en puntkomma's, raakte de formatter logica en wil je het nu weten.
Twee API-reacties. Staging retourneert een JSON-lichaam, de productie retourneert een andere en de frontend breekt alleen in enscenering. Diff de reacties. (Voor JSON specifiek, geef de voorkeur aan de JSON-differentiatie- het vergelijkt geparseerde structuur, dus sleutelvolgorde en witruimte don't maken valse positieven Voer beide payloads uit via de JSON-formatter Eerst als u in plaats daarvan een leesbare tekstdiff wilt.)
documenten en contracten. Een leverancier retourneert " hetzelfde contract met kleine updates." Word-mode diff is hoe u ontdekt dat de betalingsvoorwaarden van Net 30 naar Net 15 zijn gegaan in een document van 40 pagina's Redacteuren en advocaten weten dit al een eeuwigheid - ze noemen het een blackline of redline.
Vertaling en lokalisatiebestanden. Vergelijking van twee versies van een .po bestand om te zien welke tekenreeksen daadwerkelijk zijn gewijzigd voordat het naar vertalers wordt teruggestuurd - een echte WP Adminify-workflow die betalen bespaart om 400 ongewijzigde tekenreeksen opnieuw te vertalen.
De rode draad: op het moment dat beide versies bestaan als tekst die u kunt selecteren, antwoordt een diff-tool & quot;wat is er veranderd?" mechanisch En omdat de Toolz.dev-tool client-side is, wordt een klant geplakt's config of een niet-ondertekend contract doet't verzend het overal - hetzelfde argument als de rest van de Privacy-eerste toolbox.
Hoe lees je diff-output zonder jezelf voor de gek te houden?
De kleurconventie is universeel: Rood is de exclusieve inhoud van de oude versie (verwijderd), groen is de nieuwe versies (toegevoegd), Ongewijzigde tekst wordt duidelijk voor context. Een gewijzigde regel verschijnt als een rode lijn gevolgd door de groene vervanging.
Drie gewoonten die diff review eigenlijk betrouwbaar maken:
Zet de versies in de rechtersleuven. Oud/origineel links (of eerste veld), nieuw/aangepast rechts Wissel ze en elke toevoeging leest als een verwijdering - I' heb mensen hierdoor tien minuten lang de verkeerde richting zien debuggen Als de uitvoer naar achteren kijkt, is dat waarschijnlijk het geval.
Bepaal wat geluid is voordat je begint. Opnieuw geformatteerde code vergelijken? wijzigingen in de witruimte zijn ruis - normaliseren of negeren. YAML-configs vergelijken? Witruimte is veelbetekenend- inspringen is structuur in YAML, dus valideer beide zijden in de YAML-validator en behandel elke ruimte als signaal. Dezelfde tool, het tegenovergestelde beleid en het verkeerde kiezen van een verkeerde, begraaft de echte verandering in geluid of verbergt het.
Lees elke hunk, niet alleen de eerste. De klant's achterliggende ruimte was verandering #1 van 1. Maar wanneer een diff vier veranderingen laat zien en de eerste je symptoom verklaart, is de verleiding om te stoppen met lezen sterk - en verandering #3 is soms degene die je volgende week bijt Het diff deed het moeilijke deel al; don't herintroduceer menselijke bemonsteringsfout bij de laatste stap.
Wat kan een tekstverschil je vertellen?
De moeite waard om eerlijk te zijn over de grenzen:
- Verplaatste blokken gelezen als Delete + Add. Knip een functie uit de bovenkant van een bestand en plak deze onderaan: de diff meldt dat deze is verwijderd en toegevoegd, niet verplaatst. Sommige gespecialiseerde tools detecteren bewegingen; gewone LC's niet.
- Het vergelijkt tekst, geen betekenis.
0.1 + 0.2en0.3diff als anders (ze zijn) maar ook zich gedragen anders in drijvende komma - en omgekeerd,"key": 1versus Amerikaans wagen"key": 1.0Kan tekstueel verschillend zijn, maar semantisch identiek in uw taal. gestructureerde vergelijking (zoals de JSON-differentiatie) een deel van deze kloof voor dataformaten dichten. - Binaire inhoud valt buiten het bereik. Afbeeldingen, PDF's als bytes, uitvoerbare bestanden - tekst diff heeft tekst nodig Eerst de tekst uitpakken, of formaatspecifieke tools gebruiken.
- Case en codering worden letterlijk vergeleken.
README≠readme, en een UTF-8 Curly Quote ≠ Een ASCII rechte quote, ook al zien ze er in de meeste lettertypen identiek uit. (Nog een vormpatroonval voor ogen, nog een overwinning voor het algoritme.) normaliseer met de doosomvormer Als het geval zou moeten uitmaken voor uw vergelijking.
Veelgestelde vragen
Kan ik bestanden vergelijken, of alleen geplakte tekst?
de Tekstdiff-tool werkt op geplakte tekst: open elk bestand in elke editor, kopieer, plak beide zijden Dat maakt het formaat-agnostisch - alles wat ' leesbare tekst (code, config, CSV, SQL, proza) kan worden vergeleken, ongeacht de extensie.
Is er een maatlimiet voor vergelijking?
De praktische limiet is het geheugen van uw apparaat, aangezien de verwerking in de browser is. Bestanden met een paar duizend regels vergelijken onmiddellijk; de kostenschalen van het Myers-algoritme met het aantal verschillen, dus zelfs grote maar vergelijkbare teksten blijven snel. Honderdduizenden lijnen met enorme verschillen kunnen enkele seconden duren.
Welke diff-modus moet ik gebruiken voor code?
Lijnmodus Code is van nature één-statement-per-line, dus uitvoer op lijnniveau wordt netjes toegewezen aan hoe u over de verandering denkt. Schakel alleen over naar de woord- of tekenmodus als een regel als gewijzigd is gemarkeerd en u kunt 't het verschil daarin ontdekken - dat 's meestal witruimte, aanhalingstekens of een enkel teken.
Welke modus is het beste voor contracten en proza?
Woordmodus Prozawijzigingen zijn meestal woordvervangingen en ingevoegde clausules in lange alinea's; de lijnmodus markeert hele alinea's en laat je jagen. Markeren op woordniveau laat precies zien welke woorden zijn veranderd - dezelfde aanpak als een legale zwarte lijn.
Wijzigt het diff of bewaart het mijn tekst?
heel weinig Markering bestaat alleen in de gerenderde uitvoer; uw invoertekst is ongewijzigd en omdat de tool volledig aan de clientzijde wordt uitgevoerd, wordt geen van beide versies verzonden of ergens opgeslagen. Sluit het tabblad en de teksten zijn verdwenen.
Waarom markeert de diff een lijn die er identiek uitziet?
Bijna altijd onzichtbare karakters: volgspaties, tabbladen versus spaties, vensters \r\n versus unix \n lijnuitgangen, niet-brekende spaties of Unicode-lookalikes (krullende versus rechte aanhalingstekens).Dit is precies de klasse van veranderingen die menselijke ogen niet kunnen zien en diff-algoritmen altijd vangen - mijn ondersteuningskaartje voor de volgruimte was daar een van.
Kan het verplaatste tekst detecteren?
Niet als een zet Standaard LCS-gebaseerde diffing rapporteert een verplaatst blok zoals verwijderd van de oude locatie en toegevoegd bij de nieuwe Als u een zet vermoedt, zoekt u in de "added" tekst in het origineel - een exacte hit elders in het bestand bevestigt het.
Waarin verschilt JSON Diff van tekstverschil?
Tekstvergelijkingen vergelijkt tekens; JSON-differentiatie Parseert beide documenten en vergelijkt de structuur. Herschikte sleutels, gewijzigde inspringing en volgkomma's produceren structurele verschillen zonder structurele, zodat u alleen wijzigingen in de werkelijke waarden en sleutels ziet. Gebruik het wanneer beide kanten geldig zijn JSON; val terug naar tekstverschillen wanneer ze dat niet zijn.
Hoe negeer ik witruimte of case bij het vergelijken van tekst?
Bepaal eerst of witruimte ruis of signaal is: in geherformatteerde code is het ruis, maar in YAML of Python-inspringing is het structuur Als het ruis is, normaliseer dan beide zijden voordat u diffundeert - laat herhaalde spaties instorten, strook achter witruimte en maak lijnuitgangen consistent - dus er blijven alleen echte wijzigingen over. Om hoofdletters te negeren, kleine letters in beide teksten voordat u ze vergelijkt, aangezien het diff README en readme standaard als verschillend behandelt.
Welk algoritme gebruikt git diff?
Standaard gebruikt git diff een variant van het Myers algoritme, dezelfde langst-common-subsequence benadering van Eugene Myers' 1986 paper die de meeste diff tools delen Git biedt ook geduld - en histogramvarianten die veranderingen leesbaarder kunnen groeperen, maar ze rapporteren dezelfde set verschillen - alleen de presentatiewijzigingen Deze tool gebruikt dezelfde Myers algoritmefamilie.
