Lim inn eller last opp to CSV-filer og se de endrede radene, prisene og feltene side ved side. Kjører i nettleseren, ingen registrering, ingen opplasting.
Et gratis verktøy i nettleseren for å sammenligne to CSV-filer. Lim inn gårsdagens leverandøreksport til venstre, dagens til høyre, og de endrede cellene lyser opp. Ingenting forlater maskinen din. Ingen konto, ingen opplasting, ingen kvote.
Selve diff-en er på tegnnivå, med en semantisk etterbehandling som drar uthevingene over på hele feltverdien i stedet for å spre dem mellom kommaene. Grammatikken dette verktøyet antar, er den de facto-CSV-spesifikasjonen, RFC 4180: kommaseparerte felt, valgfrie doble anførselstegn, doblede anførselstegn for å unnvike et bokstavelig anførselstegn, CRLF-linjeskift.
Hvis du noen gang har åpnet to leverandørprislister på 8 000 rader i Excel, scrollet kolonne for kolonne for å finne SKU-en hvis pris flyttet seg, og gitt opp, er dette verktøyet som tar deg til endringen på sekunder. For fri prosa, bruk vårt tekst-diff-verktøy. For strukturerte data med stabile nøkler håndterer JSON-diff objektomrokering langt bedre enn CSV noensinne kan. XML-diff er det riktige valget for legacy-dataeksporter fra eldre ERP-er.
Sammenligningen er linje for linje, tegnbevisst. Innsettinger vises i grønt til høyre, slettinger i rødt til venstre. Linjemodus-passet holder ytelsen på et rimelig nivå på 5 MB-filer, og en finjustering i tegnmodus på de endrede linjene henter deretter fram det nøyaktige feltet som flyttet seg. For de fleste regnearkseksporter er det raskere og renere enn å kjøre diff i en terminal.
Vær ærlig om hva dette ikke er. Det er tekst-diff, ikke en sammenligning som er virkelig bevisst på radnøkler. Hvis du omrokerer rader ved å sortere på en annen kolonne, ser hver linje endret ut selv om de underliggende dataene er identiske. Hvis du omrokerer kolonner, skjer det samme. Det finnes ingen forestilling om en primærnøkkel her, slik csvjoin fra csvkit eller en pandas-merge på en SKU ville gitt deg. Sorter begge filene på samme måte før du limer inn, eller bruk et av de verktøyene når du virkelig trenger mengdebasert sammenligning.
Overskriftsraden er data for dette verktøyet. Linje 1 behandles som enhver annen linje, noe som betyr at en omdøping av overskrift vises som en enkeltlinjes diff på toppen. Det er som regel det du vil ha når du gjennomgår skjema-drift. Hvis du bare bryr deg om datarader, fjern overskriften fra begge sider før du limer inn. Selve CSV-formatet, inkludert overskriftskonvensjoner, er beskrevet i bakgrunnsartikkelen om CSV og i RFC 7111, som definerer URI-fragmenter for å velge celleområder inne i en CSV-ressurs.
To tekstpaneler, én diff. Ingen registrering, ingen opplasting, ingen tur til serveren.
Lim inn den eldre CSV-en til venstre og den nyere til høyre. Eller klikk Last opp på en av sidene for å lese inn en .csv-, .tsv- eller .txt-fil rett fra disk. Eksempel-knappen fyller begge paneler med en liten produktprisliste, slik at du først ser verktøyet i arbeid.
Excel lagrer CSV med CRLF (\r\n) på Windows; verktøy som Pythons csv.writer eller en Unix-shell-pipeline skriver ofte LF (\n). Hvis den ene siden er CRLF og den andre LF, ser hver linje ut til å være endret. Åpne begge i samme editor (eller kjør gjennom dos2unix) før du limer inn, slik at linjeskiftene matcher. UTF-8-BOM i starten av en Excel-lagret CSV er den andre klassiske skurken; fjern den hvis den andre filen ikke har den.
Slettinger vises med rød utheving til venstre, innsettinger med grønn utheving til høyre. Skroll på en av sidene, den andre følger med. Se etter endrede priser, nye rader lagt til i bunnen og e-postadresser som er rettet midt i lista. Overskriftsendringer vises som en enkeltlinjes diff på linje 1.
En leverandør sender en fersk prisliste hver uke. Slipp forrige ukes fil i venstre panel, denne ukes til høyre, og prisbevegelser på SKU-nivå hopper fram uten at du må skrolle 4 000 rader i Excel og lete etter hvilken celle som ble gul. Å gjøre det i Excel med VLOOKUP mot et annet ark går, men er tregt; diff-en er raskere når du bare trenger en rask fornuftssjekk før du dytter de nye prisene inn i butikken.
Før du sender et kunde-dump til en partner, redigerer du PII: e-post blir [email protected], telefon maskeres, fulle navn forkortes til initial. Diff den opprinnelige eksporten mot den sanerte kopien og bekreft at kun de redigerte kolonnene er endret. Hvis en billing_address-kolonne uventet dukker opp i diff-en, har redigeringsskriptet ditt mistet et felt, og du fanger det før filen forlater laptopen.
Google Merchant Center, Facebook Catalog og de fleste markedsplasser sluker en CSV- (eller TSV-)feed. Etter at CMS-et ditt har generert feeden på nytt, diff den mot gårsdagens kjente gode kopi for å fange en regex som har fjernet etterstilte nuller fra price, en tilgjengelighetskolonne som på grunn av en IF()-feil har gått fra in_stock til out_of_stock på hver rad, eller et nytt GTIN-felt teamet ditt har lagt til uten å si fra.
Når noen fra sales ops spør "hvilke kontakter har endret seg siden forrige uke?", eksporter den samme rapporten to ganger (da og nå) og diff de to filene. CSV-en er ikke sortert etter post-ID som standard, så sorter begge sidene på ID-kolonnen først; ellers ser hver rad omrokkert ut. Etter sortering trer reelle endringer tydelig fram (en lead-status flyttet fra MQL til SQL, en e-post rettet etter en bounce).
En nattlig ETL-jobb skriver en CSV til S3. Antallet rader i dag er mistenkelig forskjellig fra i går. Hent begge filene, diff dem, og du finner skjema-driften: en ny kolonne dukket opp midt i tabellen fordi det oppstrøms-API-et la til et felt, og det forskjøv hver celle nedstrøms én plass. Diff-en fanger den strukturelle endringen umiddelbart, mens en ren rad-tellingssjekk bare ville fortalt deg at noe var galt.
Din data scientist leverer en CSV med eksperimentresultatene. De kjører analysen på nytt etter en metodisk justering. Diff v1 mot v2: endret bare teststatistikk-kolonnene seg, eller flyttet også tildelingstellingene seg (noe som ville bety at kohortdefinisjonen flyttet seg)? Å diffe analyseutdata ærlig er den billigste fornuftssjekken før du slipper en feature basert på resultatet.
En kort huskelapp for parsing-grensetilfellene dette verktøyet oftest får fram. Grammatikkreferansen er RFC 4180 pluss det som ekte regnearksverktøy faktisk produserer.
| Topic | What this tool does |
|---|---|
| Sitering ifølge RFC 4180 | Felt som inneholder kommaer, doble anførselstegn eller linjeskift må være pakket inn i doble anførselstegn. "Widget, small" er ett felt. Vanlige verdier som 4.99 trenger ingen anførselstegn. Se RFC 4180. |
| Escapede doble anførselstegn | Et bokstavelig " inne i et sitert felt unnvikes ved å doble det. "He said ""hi""" er verdien He said "hi". Backslash-escape er ikke standard CSV, selv om noen verktøy godtar det. |
| Innebygde linjeskift | Linjeskift er tillatt inne i et sitert felt ifølge RFC 4180. En adresse over flere linjer i én celle er gyldig CSV. Diff-en behandler hver fysisk linje som en enhet, så et felt med et linjeskift kan vise endringer på den omsluttende linjen. |
| Linjeskift (CRLF vs LF) | RFC 4180 sier CRLF (\r\n). Excel sender ut CRLF. De fleste Unix-verktøy sender ut LF. Å blande de to mellom venstre og høyre panel får hver linje til å se endret ut. Normaliser linjeskift før diff-ing. |
| BOM (UTF-8) | Excel-lagrede CSV-er starter ofte med en UTF-8-BOM (EF BB BF). Unicode-BOM-FAQ markerer den som valgfri og unødvendig for UTF-8. En usymmetrisk BOM mellom de to filene produserer en spøkelses-diff på linje 1. |
| Skilletegn-dialekter | Komma er standard; europeiske Excel-eksporter bruker semikolon (;) fordi kommaet er desimaltegn i mange lokaliseringer. TSV (tab-separert) er en vanlig variant; se TSV-bakgrunnen. Begge filer må bruke samme skilletegn for at en diff skal være meningsfull. |
| Overskriftsrader | Dette verktøyet behandler linje 1 som data. En kolonneomdøping vises som en enkeltlinjes diff i toppen. Hvis du bare vil sammenligne datarader, fjern overskriften fra begge paneler før innliming. De fleste parsere (Pythons csv.DictReader, pandas) behandler linje 1 som en overskrift etter konvensjon, men selve filformatet krever det ikke. |
| Koding | Bare UTF-8 via FileReader i nettleseren. Latin-1 (ISO-8859-1) og Windows-1252 lastes inn, men aksenttegn vises forvridde. Konverter med iconv eller VS Codes "Save with Encoding" før innliming. |
Ja: motoren sammenligner tegn linje for linje, så omrokering av rader eller kolonner vil vises som forskjeller selv når underliggende data er identiske. Det er en tekst-diff med et par CSV-bevisste lesehjelpemidler. Det finnes ingen radnøkkelmatching, ingen bevissthet om kolonneomrokering og ingen semantisk forståelse av typer. For det nivået av sammenligning, bruk et verktøy som csvkit, pandas med en merge på primærnøkkel, eller last begge filene inn i SQLite og kjør en EXCEPT-spørring. Til daglig regnearkssammenligning dekker dette verktøyet det meste av det du trenger.
Excel skriver CSV med CRLF (\r\n), Pythons csv.writer skriver typisk LF (\n), og en shell-pipeline kan produsere det ene eller det andre alt etter flagg. Hvis det ene panelet er CRLF og det andre LF, ser diff-en en forskjell på hver eneste linje. Løsningen er å normalisere begge sider før innliming: åpne dem i samme editor og lagre med ett linjeskift, eller send en av dem gjennom dos2unix eller unix2dos. RFC 4180 påbyr CRLF, men virkelige CSV-filer bruker begge.
Nei. Dette er en tekst-diff linje for linje. Hvis rad 1 har kolonnene i rekkefølgen sku,name,price til venstre og name,sku,price til høyre, ser hver celle på hver linje endret ut, fordi diff-en ser rå tekst og ikke en kolonnemodell. Det samme gjelder hvis du sorterer de to filene på ulike kolonner. Omroker kolonner og rader så de samsvarer før du diff-er, eller ta i bruk et radnøkkelbevisst verktøy som csvjoin fra csvkit eller en pandas-merge når kolonnemodellen virkelig betyr noe.
Excel under Windows skriver ofte et UTF-8-byte-order-mark i starten av en CSV (bytene EF BB BF), selv om Unicode-BOM-FAQ sier at det er unødvendig for UTF-8. Hvis en av filene dine har en BOM og den andre ikke, ser du en spøkelses-diff på ett tegn på linje 1, kolonne 1. Åpne filen i en ordentlig teksteditor (VS Code, Notepad++, Sublime) og lagre på nytt uten BOM, eller fjern de tre første bytene manuelt før du limer inn.
UTF-8 er den eneste kodingen FileReader-stien dekoder riktig her. En Latin-1- eller Windows-1252-fil lastes inn, men aksenttegn ser forvridde ut (f.eks. café blir café). UTF-16 med BOM ser fullstendig ødelagt ut. Konverter ikke-UTF-8-filer først: i terminalen iconv -f WINDOWS-1252 -t UTF-8 input.csv > out.csv; i VS Code, bruk "Reopen with Encoding" og deretter "Save with Encoding" til UTF-8. Pythons csv-modul og pandas lar deg begge angi kildens koding ved lesing.
Opp til et par MB er greit og føles umiddelbart. Forbi 10 MB begynner nettleseren å merke det, og det meste av kostnaden er å rendre den uthevede diff-en (ikke å beregne den). For svært store eksporter (50 MB+) bør du først filtrere begge filene ned til kolonnene eller radene du virkelig bryr deg om. csvcut og csvgrep fra csvkit, jq for CSV konvertert til JSON, eller en kjapp awk/grep er alle gode forhåndspasser. Lim deretter inn den klippede biten her.
CSV-en din forlater aldri nettleseren din. Leseren, diff-en og rendringen kjøres alle på din egen maskin, lokalt. Ingen analytics på inndataene dine, ingen logger, ingen "hjelpsom" tur ut til skyen. For å sjekke, åpne DevTools, bytt til Network-fanen og se. Det er ingen utgående forespørsler når du sammenligner. Formatreferansen er RFC 4180, og Pythons dokumentasjon for csv-modulen er referansen vi krysstjekker parsing-grensetilfeller mot.