Klistra in eller ladda upp två CSV-filer och se ändrade rader, priser och fält sida vid sida. Körs i din webbläsare, ingen registrering, ingen uppladdning.
Ett gratis verktyg i webbläsaren för att jämföra två CSV-filer. Klistra in gårdagens leverantörsexport till vänster, dagens till höger, och ändrade celler tänds. Inget lämnar din maskin. Inget konto, ingen uppladdning, ingen kvot.
Diffen i sig är på teckennivå, med ett semantiskt efterbearbetningssteg som drar markeringarna till hela fältvärdet i stället för att sprida ut dem mellan kommatecknen. Grammatiken som det här verktyget utgår från är de facto-CSV-specifikationen, RFC 4180: kommaseparerade fält, valfria dubbla citattecken, dubblerade citattecken för att escapa ett bokstavligt citattecken, CRLF-radslut.
Om du någonsin öppnat två leverantörsprislistor på 8 000 rader i Excel, scrollat kolumn för kolumn för att hitta SKU:n vars pris flyttat sig och gett upp, är det här verktyget som tar dig till ändringen på sekunder. För fri prosa, använd vårt textdiff-verktyg. För strukturerad data med stabila nycklar hanterar JSON-diff objektomordning betydligt bättre än CSV någonsin kan. XML-diff är rätt val för äldre dataexports från lite gamla affärssystem.
Jämförelsen är rad för rad, teckenmedveten. Insättningar visas i grönt till höger, borttagningar i rött till vänster. Linjelägespasset håller prestandan rimlig på 5 MB-filer, sedan tar en finjustering i teckenläge på de ändrade raderna fram det exakta fältet som rörde på sig. För de flesta kalkylbladsexports är det snabbare och renare än att köra diff i en terminal.
Var ärlig om vad det inte är. Det är textdiff, inte en jämförelse som verkligen är medveten om radnycklar. Om du flyttar om rader genom att sortera på en annan kolumn ser varje rad ändrad ut även om den underliggande datan är identisk. Om du flyttar om kolumner händer samma sak. Det finns ingen primärnyckel-tanke här, så som csvkit:s csvjoin eller en pandas-merge på en SKU skulle ge dig. Sortera båda filerna på samma sätt innan du klistrar in, eller använd ett av de verktygen när du verkligen behöver mängdbaserad jämförelse.
Rubrikraden är data för det här verktyget. Rad 1 behandlas som vilken annan rad som helst, vilket innebär att en rubrikomdöpning visas som en enradig diff längst upp. Det är vanligen vad du vill när du går igenom schema-drift. Bryr du dig bara om datarader, ta bort rubriken på båda sidor innan du klistrar in. Själva CSV-formatet, inklusive rubrikkonventioner, beskrivs i bakgrundsartikeln om CSV och i RFC 7111, som definierar URI-fragment för att välja cellintervall inuti en CSV-resurs.
Två textpaneler, en diff. Ingen registrering, ingen uppladdning, ingen serverresa.
Klistra in den äldre CSV-filen till vänster och den nyare till höger. Eller klicka på Ladda upp på endera sidan för att läsa in en .csv-, .tsv- eller .txt-fil rakt från disken. Exempel-knappen fyller båda panelerna med en liten produktprislista så att du först ser verktyget i arbete.
Excel sparar CSV med CRLF (\r\n) på Windows; verktyg som Pythons csv.writer eller en Unix-shell-pipeline skriver ofta LF (\n). Om en sida är CRLF och den andra LF kommer varje rad att se ändrad ut. Öppna båda i samma editor (eller skicka genom dos2unix) före inklistringen så att raderna stämmer. UTF-8-BOM i början av en Excel-sparad CSV är den andra klassiska boven; ta bort den om din andra fil saknar den.
Borttagningar visas med röd markering till vänster, insättningar med grön markering till höger. Skrolla på endera sidan, den andra följer med. Leta efter ändrade priser, nya rader tillagda i botten och e-postadresser korrigerade mitt i listan. Rubrikändringar visas som en enradig diff på rad 1.
En leverantör skickar en färsk prislista varje vecka. Släpp förra veckans fil i vänsterpanelen, denna veckas till höger, och prisrörelser på SKU-nivå hoppar fram utan att du behöver scrolla 4 000 rader i Excel och leta efter vilken cell som blev gul. Att göra det i Excel med VLOOKUP mot ett andra blad går, men är långsamt; diffen är snabbare när du bara behöver en snabb sundhetskoll innan du knuffar de nya priserna in i butiken.
Innan du skickar en kunddump till en partner redigerar du PII: e-post blir [email protected], telefon maskeras, fullständiga namn kortas till en initial. Diffa källexporten mot den sanerade kopian och bekräfta att endast de redigerade kolumnerna ändrats. Om en billing_address-kolumn oväntat dyker upp i diffen har ditt redigeringsskript missat ett fält, och du fångar det innan filen lämnar laptopen.
Google Merchant Center, Facebook Catalog och de flesta marknadsplatser sväljer ett CSV- (eller TSV-)flöde. När ditt CMS regenererat flödet, diffa mot gårkvällens kända goda kopia för att fånga en regex som tagit bort efterföljande nollor från price, en tillgänglighetskolumn som tippat från in_stock till out_of_stock på varje rad på grund av en IF()-bugg, eller ett nytt GTIN-fält som ditt team lagt till utan att säga ett ord.
När någon från sales ops frågar "vilka kontakter har ändrats sedan förra veckan?", exportera samma rapport två gånger (då och nu) och diffa de två filerna. CSV:n sorteras inte efter post-ID som standard, så sortera båda sidorna efter ID-kolumnen först; annars ser varje rad omkastad ut. Efter sortering träder verkliga ändringar fram tydligt (en lead-status flyttad från MQL till SQL, en e-post korrigerad efter en bounce).
Ett nattligt ETL-jobb skriver en CSV till S3. Dagens radantal är misstänkt annorlunda än gårdagens. Hämta båda filerna, diffa dem, och du hittar schema-driften: en ny kolumn dök upp mitt i tabellen för att uppströms-API:t lade till ett fält, vilket flyttade varje cell nedströms ett steg. Diffen fångar den strukturella förändringen direkt, där en ren radantalskontroll bara skulle ha sagt att något var fel.
Din data scientist levererar en CSV med experimentresultaten. De kör om analysen efter en metodikjustering. Diffa v1 mot v2: ändrades bara teststatistik-kolumnerna, eller flyttade sig även tilldelningsantalen (vilket skulle betyda att kohortdefinitionen flyttats)? Att ärligt diffa analysoutput är den billigaste sundhetskontrollen innan du släpper en feature byggd på resultatet.
En kort fusklapp för parsningens gränsfall som det här verktyget oftast tar fram. Grammatikreferensen är RFC 4180 plus det som riktiga kalkylbladsverktyg faktiskt skickar ut.
| Topic | What this tool does |
|---|---|
| Citering enligt RFC 4180 | Fält som innehåller kommatecken, dubbla citattecken eller radslut måste omslutas av dubbla citattecken. "Widget, small" är ett fält. Vanliga värden som 4.99 behöver inga citattecken. Se RFC 4180. |
| Escapade dubbla citattecken | Ett bokstavligt " inuti ett citerat fält escapas genom att dubblera det. "He said ""hi""" är värdet He said "hi". Backslash-escape är inte standard-CSV, även om vissa verktyg accepterar det. |
| Inbäddade radslut | Radslut är tillåtna inuti ett citerat fält enligt RFC 4180. En flerradsadress inuti en cell är giltig CSV. Diffen behandlar varje fysisk rad som en enhet, så ett fält med radbrytning kan visa ändringar på den omslutande raden. |
| Radslut (CRLF vs LF) | RFC 4180 säger CRLF (\r\n). Excel skickar ut CRLF. De flesta Unix-verktyg skickar ut LF. Att blanda de två mellan vänster och höger panel gör att varje rad ser ändrad ut. Normalisera radslut före diffning. |
| BOM (UTF-8) | Excel-sparade CSV-filer börjar ofta med en UTF-8-BOM (EF BB BF). Unicode-BOM-FAQ:n markerar den som valfri och onödig för UTF-8. En icke matchande BOM mellan de två filerna ger en spök-diff på rad 1. |
| Avgränsardialekter | Komma är standard; europeiska Excel-exports använder semikolon (;) eftersom kommat är decimaltecken i många lokaler. TSV (tabbavgränsad) är en vanlig variant; se TSV-bakgrunden. Båda filerna måste använda samma avgränsare för att diffen ska bli meningsfull. |
| Rubrikrader | Det här verktyget behandlar rad 1 som data. En kolumnomdöpning visas som en enradig diff längst upp. Vill du bara jämföra dataraderna, ta bort rubriken från båda panelerna före inklistringen. De flesta parsare (Pythons csv.DictReader, pandas) behandlar rad 1 som rubrik enligt konvention, men själva filformatet kräver det inte. |
| Kodning | Endast UTF-8 via webbläsarens FileReader. Latin-1 (ISO-8859-1) och Windows-1252 läses in men renderar accenttecken konstigt. Konvertera med iconv eller VS Codes "Save with Encoding" före inklistring. |
Ja: motorn jämför tecken rad för rad, så att flytta om rader eller kolumner kommer att visas som skillnader även när underliggande data är identisk. Det är en textdiff med några CSV-medvetna läshjälpmedel. Det finns ingen radnyckelmatchning, ingen medvetenhet om kolumnordning och ingen semantisk förståelse av typer. För den nivån av jämförelse, använd ett verktyg som csvkit, pandas med en merge på primärnyckel, eller läs in båda filerna i SQLite och kör en EXCEPT-fråga. För daglig kalkylbladsjämförelse täcker det här verktyget det mesta av det du behöver.
Excel skriver CSV med CRLF (\r\n), Pythons csv.writer skriver typiskt LF (\n), och en shell-pipeline kan producera endera beroende på flaggor. Om en panel är CRLF och den andra LF ser diffen en skillnad på varje rad. Lösningen är att normalisera båda sidorna innan inklistringen: öppna dem i samma editor och spara med ett radslut, eller skicka en genom dos2unix eller unix2dos. RFC 4180 kräver CRLF, men verkliga CSV-filer använder båda.
Nej. Det här är en textdiff rad för rad. Om rad 1 har kolumner i ordningen sku,name,price till vänster och name,sku,price till höger ser varje cell på varje rad ändrad ut, för diffen ser rå text och inte en kolumnmodell. Samma gäller om du sorterar de två filerna på olika kolumner. Flytta om kolumner och rader så att de matchar innan du diffar, eller ta till ett radnyckelmedvetet verktyg som csvkit:s csvjoin eller en pandas-merge när kolumnmodellen verkligen spelar roll.
Excel under Windows skriver ofta en UTF-8-byte-order-mark i början av en CSV (byten EF BB BF), trots att Unicode-BOM-FAQ:n säger att den är onödig för UTF-8. Om en av dina filer har en BOM och den andra inte ser du en spök-diff på ett tecken på rad 1, kolumn 1. Öppna filen i en riktig texteditor (VS Code, Notepad++, Sublime) och spara om utan BOM, eller ta bort de tre första byten manuellt innan du klistrar in.
UTF-8 är den enda kodning som FileReader-vägen avkodar korrekt här. En Latin-1- eller Windows-1252-fil läses in men accenttecken ser konstiga ut (t.ex. café blir café). UTF-16 med BOM ser helt trasig ut. Konvertera filer som inte är UTF-8 först: i terminalen iconv -f WINDOWS-1252 -t UTF-8 input.csv > out.csv; i VS Code, använd "Reopen with Encoding" och sedan "Save with Encoding" till UTF-8. Pythons csv-modul och pandas låter dig båda ange källans kodning vid läsning.
Upp till några MB är okej och känns omedelbart. Förbi 10 MB börjar webbläsaren känna det, och det mesta av kostnaden är att rendera den markerade diffen (inte att beräkna). För riktigt stora exports (50 MB+), filtrera först båda filerna ner till de kolumner eller rader du verkligen bryr dig om. csvcut och csvgrep från csvkit, jq för CSV omvandlad till JSON, eller en snabb awk/grep duger som förbearbetning. Klistra sedan in den nedklippta biten här.
Din CSV lämnar aldrig din webbläsare. Läsaren, diffen och renderingen körs alla på din maskin, lokalt. Ingen analytics på din input, inga loggar, ingen "hjälpsam" tur ut till molnet. För att kontrollera, öppna DevTools, byt till Network-fliken och titta. Det går inga utgående anrop när du jämför. Formatreferensen är RFC 4180, och Pythons dokumentation för csv-modulen är referensen vi stämmer av parsningens gränsfall mot.