File cosiddetti "delimitati", character separated values: CSV, dove cioè i campi sono riconosciuti praticamente solo per i caratteri che li delimitano e separano dagli altri sono comunissimi, non solo perché storicamente sempre usati, ma perché tuttora prodotti da uno degli strumenti di lavoro più diffusi ed utilizzati a livello basilare (e riduttivo) come i "fogli elettronici", spreadsheets, quali MS-Excel, Corel-Quattro Pro, OpenOffice Calc etc. ed anche da vari programmi per gestire archivi di dati (DBMS database management systems)

Un file delimitato è scritto in puro testo (ad es. ASCII, Unicode...) può essere considerato una tabella di righe e colonne. Esso tiene i record su una riga e i campi in colonne.
La struttura del file non è definita da uno standard ma dalla pratica (o meglio le pratiche) dominanti per uso.
Un record su una riga non esclude sempre che la riga possa anche andare accapo, ma deve concludersi con il carattere previsto per il fine riga solo là dove effettivamente finisce: il carattere di fine riga richiesto è normalmente -in ambiente operativo Windows, DOS- il CR+LF (carriage return+line feed), corrispondenti nella tabella di caratteri ASCII (ed ANSI) a decimale <13><10>; questo -o altro- carattere (che viene variamente visualizzato, qui sotto ad es. viene mostrato col carattere del paragrafo "¶" (ASCII 20).
I campi all'interno di ogni riga-record sono separati da un carattere definito (virgola, punto e virgola, tabulatore ...)
Quello che è fondamentale è che tutti i record devono avere lo stesso numero di campi (vuoti o pieni che siano) e nello stesso ordine, perché è la quantità e la posizione che determinano il nome e la natura del campo per il programma che lo riceverà e i record non possono cambiare di ordine all'interno dello stesso file.
Spesso, per pratica ma non per regola, i campi sono racchiusi, oltre che separati, da una coppia di caratteri, ad esempio dalle virgolette doppie " " (ASCII 34).

Un diffusissimo tipo di file delimitato è stato ed ancora è il CDF comma delimited file (o CSV: comma separated value, con lo stesso acronimo di cui sopra) ossia un file delimitato da virgola, ossia un file in cui i campi dei record sono separati da virgola.

Normalmente un confine, delimitatore, non deve anche stare dentro il campo.  
Ossia : né il carattere che separa i record (¶), né quello che separa i campi (ad es. la virgola), né quello che li racchiude, (ad es. le virgolette doppie) possono essere anche parte del contenuto dei campi.
Ma talora invece ciò è ammesso con l'accortezza di una metacodifica che spesso consiste nel racchiudere il carattere che di norma è di confine ed invece si trova nel campo, fra delimitatori particolari (ad es. doppi se erano già previsti come semplici), ad es.:

Ci possono poi essere altre, varie, specifiche, ad es.: come trattare gli spazi (blanks ASCII 32), come sostituire o marcare il carattere che racchiude i campi se il programma lo trova contenuto nei campi, come indicare i campi vuoti, come separare più occorrenze di uno stesso campo, come trattare i numeri, le date .... occorre vedere, caso per caso, quali sono appunto le specifiche del programma che tratta il file delimitato. E non è affatto escluso che uno debba prima ricorrere all'uso di un programma di scrittura (editori di testo) per risistemare il file prima che venga trattato dal programma.

Trattare questi file delimited non è proprio lineare in un programma di gestione di dati perché occorre che si possa stabilire una corrispondenza se non una simmetria speculare fra l'ordine dei campi sulle righe e quello nei record del database (DBMS). Siccome certi DBMS non consentono di modificare l'ordine dei campi nei record configurare quella ordinata corrispondenza può essere difficile o anche impossibile.
[EndNote ad es. non consente di modificare l'ordine dei campi nei suoi schemi di record (templates, workformi) però fa aggirare l'ostacolo ammettendo che i record in entrata abbiano i campi in un ordine sequenziale diverso e che questo venga dichiarato, e dunque reso interpretabile, da una prima riga del file in cui sono scritti i nomi dei campi (secondo la nomenclatura, naturalmente, propria di EndNote. Segue sotto la spiegazione e l'esemplificazione.]

Il tab delimited file usa il carattere di tabulazione orizzontale (ASCII 9) come separatore di campi e non richiede delimitatori del contenuto dei campi, ma anche qui ci possono essere varianti e file che presentano i campi racchiusi da virgolette o apici e programmi più o meno pronti ad intendere questa scansione.

EndNote non tratta -e, per quanto mi consta, non ha mai trattato- file delimitati da virgola, CDF (comma delimited file come invece consente di fare ProCite), ma tratta i tab delimited sia in importazione che in esportazione. Ha la particolarità, appena annunciata, di non pretendere che i campi siano già nello stesso ordine.
Ecco le specifiche che richiede.

Sulla prima linea il RT dei record preceduto da asterisco e seguito da 'accapo' <¶>
Il nome deve essere esattamente quello usato in EndNote così come per i campi nei vari RT (pare che tolleri differenze in maiuscolo minuscolo)
Seguono poi i nomi dei campi usati nello RT indicato separati da <tab> tabulatore senza spazi aggiunti cfr. l'esempio (A) ma N.B. i tabulatori e gli accapo sono resi in chiaro e non con gli effettivi caratteri corrispondenti
Se un file da importare contiene diversi RT allora niente nome di RT sulla prima riga e lo RT indicato anche come nome di campo e poi come primo campo di ogni record; i nomi dei campi devono essere quelli dello RT Generic (C)

L'ordine dei campi in input può variare rispetto a quello dei campi nella RT di EndNote, ma deve essere coerente con la dichiarazione della prima riga e i nomi non possono variare
I campi non devono contenere né <tab> né "accapo" <¶> (o <CR/LF>
Separare le occorrenze di campi multipli (Author e simili e Keywords) con "//" o con ";" (A)
I campi in input vuoti vanno comunque segnalati con <tab> (A)
Si possono eliminare, omettere campi, nell'importazione denominandoli "Unused" (A), (altrimenti lo si potrà fare dopo dentro EndNote)
Tratta accenti caratteri ASCII/ANSI e Unicode
L'importazione con errori viene segnalata anche con un messaggio: controllare anzitutto che la struttura sia corretta e non ci siano spazi blanks in più dove non richiesti

Esemplificazioni (N.B. <tab> e  <¶> stanno al posto dei corrispondenti caratteri per tabulazione ed accapo)

(A)
*BOOK
Author<tab>Year<tab>Title<tab>Keywords<tab>Notes<tab>Unused <¶>
Geremicca, Federico; Eco, Umberto; ABI,<tab> 2013 Titolo di prova Santa Eva//Storia sacra  Contenuto extra <¶>
Lidolfi, Mario 2011 Cercami  Traduzione mai pubblicata Extra <¶>

(B)
*Journal Article<¶>                 
Author<tab>Year< tab>Title<tab>Journal <tab>Volume<¶>
Jones, J//Shoe, S <tab> 1994 <tab> Easy Food <tab> J. of Eating <tab> 1 <¶>
Woo, W //Lee, L <tab> 1995 <tab> Rain Hats <tab> J. of Clothing <tab> 2 <¶>
Carlos, C\\Luis, L <tab> 1991 <tab> Cell Phone <tab> J. of Phones <tab> 3 <¶>

(D)
Reference Type<tab> Author<tab>Year< tab>Title<tab>Secondary Title<tab>Volume<¶>
Journal Article<tab> Jones, J//Shoe, S <tab> 1994 <tab> Easy Food <tab> J. of Eating <tab> 1 <¶>
Book Section<tab> Woo, W //Lee, L <tab> 1995 <tab> Rain Hats <tab> J. of Clothing <tab> 2 <¶>
Report<tab> Carlos, C\\Luis, L <tab> 1991 <tab> Cell Phone <tab> J. of Phones <tab> 3 <¶>

N.B: I nomi dei campi in questo caso sono quelli dello RT Generic