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 diff
Tehát az OSX-nek ez a két funkciója nagyon hasznos: pbcopy
és pbpaste
. Alapvetően bármi, ami elvezetésre pbcopy
kerül, bekerül a vágólapra, és pbpaste
a 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+FEFF
a ZERO WIDTH NO-BREAK SPACE
. Ezenkívül egy gyors utazás a Wikipédiába mesélt nekünk a ( vagy U+FEFF
közismertebb nevén) tényleges felhasználásáról .Byte order mark
BOM
Barátunk FEFF
kü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
.
FEFF
maga a UTF-16
- UTF-8
arra 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-16
helyett UTF-8
. UTF-8
nem érti, BOM
és csak nem karakterként kezeli ilyen vizuálisan, a fájl rendben volt. De Ruby CSV
gondolat, 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 CSV
elemző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 pbpaste
segí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.