Ma hibába ütköztünk, amikor megpróbáltunk néhány adatbázis-magot létrehozni egy CSV-ből. Ezt a CSV-t eredetileg én készítettem egy Ruby szkript segítségével, amely a kimenetet egy fájlba csatolta és CSV-ként mentette.
A CSV-t bejelentkezték a Gitbe, és egy ideig használták, amíg néhány részét frissíteni kellett egy új oszlop hozzáadásával és néhány érték rögzítésével.
Bár még nem tudjuk a pontos okot, az az elméletem, hogy valahogy az Excel for Mac (mindannyian Mac-eket használunk) még további metaadatokat adott hozzá, még akkor is, ha a fájlt CSV-ként mentette el.
Ez viszont arra késztette a magot használókat, hogy a következő hibát kapják:
CSV::MalformedCSVError: Illegal quoting in line 1.Megnyitottam a CSV fájlt, és semmi sem tűnt gyanúsnak. Az első gondolatom az volt némi bal / jobb idézőjelbe valahogy kevernek a fájl helyett csak a „szokásos” kettős idézőjelek: ". De további vizsgálatok után nem volt semmi szokatlan. Ez arra késztetett, hogy egyszerűen kitöröljem az egész fájlt, és valójában újra beírjam az első sort.
Újra mentettem a fájlt, és futtattam az áttelepítést:
CSV::MalformedCSVError: Illegal quoting in line 1.Mit?!
Oké, ez diót űzött. Megnyitottam egy új fájlt, újra beírtam a pontos egy sort, és lefuttattam az áttelepítést. Működött. Tehát mi volt abban az aktában ?!
Csak egy módja a megismerésnek:
cat companies.csv | pbcopy | pbpaste > temp.csv rm companies.csv mv temp.csv companies.csv git diffTehát az OSX-nek ez a két funkciója nagyon hasznos: pbcopyés pbpaste. Alapvetően bármi, ami elvezetésre pbcopykerül, bekerül a vágólapra, és pbpastea vágólapon tároltakat standard kimenetre állítja (stdout). De minden formázást eltávolít.
Nagyon hasznos, ha csak szöveget szeretne másolni valahonnan, és be akarja illeszteni egy WYSIWYG szerkesztőbe minden formázás nélkül. Mint például egy e-mail írásakor a Gmailből.
Ezután eltávolítottam az eredeti fájlt, és elmentettem az új „formázatlan” fájlt ugyanazzal a fájlnévvel, hogy lássam a különbséget.
És végre megláttuk a láthatatlan embert:
Egy gyors Google-keresés azt mondta nekünk, hogy barátunkat U+FEFFa ZERO WIDTH NO-BREAK SPACE. Ezenkívül egy gyors utazás a Wikipédiába mesélt nekünk a ( vagy U+FEFFközismertebb nevén) tényleges felhasználásáról .Byte order markBOM
Barátunk FEFFkülönböző dolgokat jelent, de ez alapvetően egy program számára jelzi, hogyan olvassa el a szöveget. Lehet UTF-8(gyakoribb) UTF-16, vagy akár UTF-32.
FEFFmaga a UTF-16- UTF-8arra ismertebb nevén 0xEF,0xBB, or 0xBF.
Az én megértés, amikor a CSV fájlt megnyitja az Excel és a mentett, Excel létrehozott egy helyet a láthatatlan potyautas, U+FEFF. És a fájl előtt a bootoláshoz!
Excel tett néhány mágia, és valószínűleg mentett UTF-16helyett UTF-8. UTF-8nem érti, BOMés csak nem karakterként kezeli ilyen vizuálisan, a fájl rendben volt. De Ruby CSVgondolat, hogy valami baj van, mert feltételezhető, a fájl nem olvasott volt UTF-8, és nem tudta figyelmen kívül hagyni Mr. U+FEFF.
Tehát a tanulság: ne nyisd meg (és ne mentsd el!) Egy CSV fájlt az Excelben, ha azt Ruby CSVelemzőjéhez akarod adni .
Ha valaha is találkozik ilyen hibával, feltétlenül keressen olyan rejtett karaktereket, amelyeket a szerkesztő nem mutat be. Ha még mindig nem látja, és OSX-t használ, akkor pbcopyés pbpastesegít neked - a másolás és beillesztés mellett a formázást vagy a rejtett karaktereket eltávolítják a szövegből.