Astăzi, am întâmpinat o eroare în timp ce încercam să creăm câteva semințe de baze de date dintr-un CSV. Acest CSV a fost generat inițial de mine folosind un script Ruby care a canalizat ieșirea într-un fișier și a fost salvat ca CSV.

CSV a fost înregistrat în Git și a fost folosit pentru o vreme până când a trebuit să actualizăm unele părți ale acestuia adăugând o nouă coloană și fixând unele valori.

Deși nu știm încă motivul exact, teoria mea este că într-un fel, Excel pentru Mac (folosim cu toții Mac-uri) i-au adăugat metadate suplimentare chiar și după salvarea fișierului ca CSV.

La rândul său, acest lucru a făcut ca oricine utilizează sămânța să primească următoarea eroare:

CSV::MalformedCSVError: Illegal quoting in line 1.

Am deschis fișierul CSV și nimic nu părea suspect. Primul meu gând a fost că unele ghilimele stânga / dreapta au fost cumva amestecate în fișier în loc doar de ghilimele duble „normale”: ". Dar, după investigații suplimentare, nu a existat nimic ieșit din comun. Acest lucru m-a determinat să șterg întregul fișier și să scriu din nou primul rând.

Am salvat din nou fișierul și am executat migrarea:

CSV::MalformedCSVError: Illegal quoting in line 1.

Ce?!

Bine, asta mă înnebunea. Am deschis un fișier nou, am tastat din nou singura linie exactă și am executat migrarea. A mers. Deci, ce era în acel fișier ?!

O singură modalitate de a afla:

cat companies.csv | pbcopy | pbpaste > temp.csv
rm companies.csv
mv temp.csv companies.csv
git diff

Deci OSX are aceste două funcții care sunt foarte utile: pbcopy și pbpaste. Practic, orice ar fi condus pbcopy intră în clipboard și pbpaste pune ceea ce aveți în clipboard la ieșirea standard (stdout). Dar elimină toate formatările.

Foarte util atunci când doriți să copiați doar un text de undeva și doriți să-l lipiți într-un editor WYSIWYG fără toate formatările. De exemplu, atunci când scrieți un e-mail din Gmail.

Am eliminat apoi fișierul original și am salvat noul fișier „neformatat” cu același nume de fișier, astfel încât să văd diferența.

Și în cele din urmă l-am văzut pe omul invizibil:

O poveste rapida despre FEFF un personaj UTF 8 invizibil care
Personajul invizibil care apare în Bitbucket al lui Atlassian.
1611621485 877 O poveste rapida despre FEFF un personaj UTF 8 invizibil care
Numele real al personajului invizibil!

Un Google rapid căutare ne-a spus că prietenul nostru U+FEFF a fost numit a ZERO WIDTH NO-BREAK SPACE. Deasemenea o călătorie rapidă pe Wikipedia ne-a spus despre utilizările efective pentru U+FEFF, mai frecvent cunoscut sub numele de Byte order mark sau BOM.

Prietenul nostru FEFF înseamnă lucruri diferite, dar este practic un semnal pentru un program despre cum să citești textul. Poate fi UTF-8 (mai frecvente), UTF-16, sau chiar UTF-32.

FEFF în sine este pentru UTF-16 – în UTF-8 este mai frecvent cunoscut sub numele de 0xEF,0xBB, or 0xBF.

Din câte am înțeles, când fișierul CSV a fost deschis în Excel și salvat, Excel a creat un spațiu pentru clandestinul nostru invizibil, U+FEFF. Și în fața fișierului pentru a porni!

Excel a făcut ceva magie și probabil că a fost salvat în UTF-16 in loc de UTF-8. UTF-8 nu înțelege BOM și doar îl tratează ca pe un non-personaj, așa că vizual, fișierul a fost în regulă. Dar Ruby CSV am crezut că este ceva în neregulă deoarece presupunea că fișierul pe care îl citea era UTF-8 și nu l-a putut ignora pe dl. U+FEFF.

Deci, lecția învățată: nu deschideți (și salvați!) Un fișier CSV în Excel dacă doriți să-l trimiteți lui Ruby’s CSV analizor.

Dacă întâmpinați vreodată o astfel de eroare, asigurați-vă că căutați caractere ascunse care nu sunt afișate de editorul dvs. Dacă tot nu îl puteți vedea și utilizați OSX, atunci pbcopy și pbpaste vă va ajuta – elimină orice formatare sau caractere ascunse din text, pe lângă copiere și lipire.