You have provided us with vague hints about what you are experiencing and what you think it is doing wrong. A concrete example would do more to encourage people to investigate and perhaps help you.

Apologies - I didn't notice the test data below the fold....

Before throwing the word "bug" around, or becoming much attached to notions of what should happen such that "surprise" occurs, I recommend that you read the "standard" (so-to-speak) on CSV. There, you will find that neither of your TSV input files conforms (allowing for substitution of the delimiter, which is a common extension.) Pay particular attention to item 5 at the link regarding use of double-quote in the field content rather than as a delimiter.

Here is a session which acted as I expected, because I created input which does conform to RFC4180 (except for using tab as the delimiter, which I often prefer.) SQLite version 3.35.5 2021-04-19 18:32:05 ... sqlite> .mode tabs sqlite> .import ok.tsv SeeTSV sqlite> select * from SeeTSV; no quotes a "quoted" word sqlite> .q $ cat ok.tsv "Col_1" "Col_2" no quotes "a ""quoted"" word" $ . Note that there is an ASCII 9 (aka "tab") between the fields within each of the two TSV records.

I had enough trouble understanding your post that I decoded your base64 so that I could examine your inputs. At that point, it was clear that you have ideas about escaping within CSV that do not find support in RFC4180. Given that your input is not proper CSV or TSV, I cannot regard what you saw, however unexpected, as a bug.

Further to Richard's point:

Within your post(s) is much extraneous matter and a scarcity of: (1) what you saw; (2) what you got; (3) with what provided as input^a; (4) what you would regard as correct; and (5) why you believe as you do regarding correctness.

a. Providing your inputs in base64, which also contain 20 or more times the data needed to demonstrate the issue, hardly counts as aiding those who might help you. A short, properly quoted for markdown, inline example of your problematic or demonstration inputs is far more likely to be examined by those poised to help.

Your Tab Separated Value file does not comform with the requirements for a valid TSV/CSV file. The valid compliant format is:

ISSN	TITLE
0949-1570	Materialien zur Pflegewissenschaft.
1095-6840	General and comparative endocrinology.
0036-973X	Scripta mercaturae
2286-038X	"""Ovidius"" University Annals of Chemistry."
1572-9567	International journal of thermophysics.
1224-581X	Analele ştiinţifice ale Universităţii "Al.I. Cuza" din Iaşi
1570-0844	Semantic web.
0323-3391	Wissenschaftliche Beiträge des Instituts Ökonomik der Entwicklungsländer an der Hochschule für Ökonomie "Bruno Leuschner" Berlin.
0041-798X	Proceedings of the United States Naval Institute.
0333-5879	Frswm - Hđtknywn-Mkwn đTknwlwgy Lyśr'l, Hfqwlđth Lhndsh đHql'yt  ̨"š Frwf' L'wdrmylq
0946-2104	Trace elements and electrolytes
2248-3276	Analele ştiinţifice ale Universităţii "Al.I. Cuza" din Iaşi
2662-4176	Disaster research and management series on the global South.
0408-9936	Saopštenja Instituta za vodoprivredu "Jaroslav Černi".
1552-3594	Criminal justice and behavior.
2537-3137	Annals of "Valahia" University of Târgovişte
1437-1073	Cardio-News.
1476-4679	Nature cell biology.
1382-4139	Attractor.
0776-0086	Bulletin de la Société royale belge d'études géologiques et archéologiques "Les chercheurs de Wallonie"
0983-0537	Journal de la marine marchande et du transport multimodal.
0005-5115	Buletin ekonomi suku tahunan - Bank Negara Malaysia
0174-8319	Archiv für Genossenschaftswesen
1095-9238	Journal of archaeological science.

The "rules" for field content are that if the field contents contain either the field or record separator or begins with a double-quote mark, then the field must be quoted with double-quotes and all embeded double-quotes must be replaced with two double-quotes side by each.

Once you create a properly formatted input file, everything works correctly.

SQLite version 3.38.0 2022-02-16 19:54:02
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> .mode csv
sqlite> .separator "\t"
sqlite> .import example_compliant.tsv x
sqlite> .mode list
sqlite> select * from x;
ISSN|TITLE
0949-1570|Materialien zur Pflegewissenschaft.
1095-6840|General and comparative endocrinology.
0036-973X|Scripta mercaturae
2286-038X|"Ovidius" University Annals of Chemistry.
1572-9567|International journal of thermophysics.
1224-581X|Analele stiintifice ale Universitatii "Al.I. Cuza" din Iasi
1570-0844|Semantic web.
0323-3391|Wissenschaftliche Beiträge des Instituts Ökonomik der Entwicklungsländer an der Hochschule für Ökonomie "Bruno Leuschner" Berlin.
0041-798X|Proceedings of the United States Naval Institute.
0333-5879|Frswm - Hdtknywn-Mkwn dTknwlwgy Lysr'l, Hfqwldth Lhndsh dHql'yt  ?"s Frwf' L'wdrmylq
0946-2104|Trace elements and electrolytes
2248-3276|Analele stiintifice ale Universitatii "Al.I. Cuza" din Iasi
2662-4176|Disaster research and management series on the global South.
0408-9936|Saopstenja Instituta za vodoprivredu "Jaroslav Cerni".
1552-3594|Criminal justice and behavior.
2537-3137|Annals of "Valahia" University of Târgoviste
1437-1073|Cardio-News.
1476-4679|Nature cell biology.
1382-4139|Attractor.
0776-0086|Bulletin de la Société royale belge d'études géologiques et archéologiques "Les chercheurs de Wallonie"
0983-0537|Journal de la marine marchande et du transport multimodal.
0005-5115|Buletin ekonomi suku tahunan - Bank Negara Malaysia
0174-8319|Archiv für Genossenschaftswesen
1095-9238|Journal of archaeological science.
sqlite>

I find it strange that TSV has different rules to CSV ...

"TSV" is a more nebulous term than even "CSV", in the big wide world. As far as the CLI's .import command works, it's just a different separator, as you say.

To get CLI output that can be brought back in via .import, with tab field separators, this is needed: .mode csv .separator "\t" . Note that ".mode tabs" does not have the same effect on output.

You will note that the format for a "separated values" file is as follows:

<field>FS<field>FS<field> ... RS
<field>FS<field>FS<field> ... RS
<field>FS<field>FS<field> ... RS
...
<field>FS<field>FS<field> ... RS

where FS = the Field Separator Character
and RS = the Record Separator Character

For each field, if (instr(field, RS)>-1 || instr(field, FS)>-1 || field[0]=='"') then the field MUST BE DIDDLED. Otherwise diddling is not required (though there are many formats of separated values files that do diddle with fields that do not require diddling. Applying extra field diddling where not required merely consumes resources but does not have any affect on the value because it will be de-diddled before use.

If the field required DIDDLING, then the following diddling should be performed and the diddled result used as the field in the separated file.

replace all double-quotes (") with two double-quotes side-by-each (""), then
prepend a double-quote (") and append a double-quote (")

On reading a "separated values" file, then if the FIRST CHARACTER of an input field (that is, the byte immediately following the RS or FS or beginning of file) is a double-quote (") then the read contents need to be DE-DIDDLED before they are used. Otherwise the field result value is the entire literal value contained between the separators.

If the field is DIDDLED (ie, the first byte is a double-quote (")) then the field value must be de-diddled. The first byte, which is a double-quote (") is removed. The last byte, which must be a double-quote (") is also removed. Any two byte sequence that contains two double-quotes side-by-each ("") is replaced with a single double-quote (").

It should be noted that if a field begins with a double-quote then it must also end with a double-quote. If this is not the case, then the result would be erroneous and the failure should be very noisy and very loud.

For each field, if (instr(field, RS)>-1 || instr(field, FS)>-1 || field[0]=='"') then the field MUST BE DIDDLED. Otherwise diddling is not required (though there are many formats of separated values files that do diddle with fields that do not require diddling.

I notice that sqlite does indeed handle unquoted fields with a double not at the beginning this way, but on export it diddles them:

▶▶▶ .sh cat tt.csv
a,b,c
1,"b c",d
2,e"f,g
▶▶▶ .import -csv tt.csv tt
▶▶▶ select * from tt;
┌───┬─────┬───┐
│ a │  b  │ c │
├───┼─────┼───┤
│ 1 │ b c │ d │
│ 2 │ e"f │ g │
└───┴─────┴───┘
▶▶▶ .mode csv
▶▶▶ select * from tt;
1,"b c",d
2,"e""f",g

RFC 4180 insists on diddling those fields, though:

If fields are not enclosed with double quotes, then double quotes may not appear inside the fields.

So it is good to know that sqlite creates conforming csv, while being more liberal on input. But it could also be useful to know that the standard is indeed more strict. (I only point this out because of the frequent references to RFC4180 when the topic comes up. Similar comments apply to CRLF versus LF endings: I am happy that every csv reader that I know of, recognises the latter.)