This is known as the GIGO principle (Garbage In -> Garbage Out).

Either your file must conform to the standard, or you must write your own importer using whatever language you wish that can deal with your peculiar file format in the manner in which you intend it be dealt with.

may make problems

Does it or does it not? You seem to be ambiguous here. Have you bothered to even try and see what happens? It is unlikely that a "standard format" will be changed to make you happy, especially since you are only guessing that Garbage In will result in Garbage Out.

You said "may make problems" not "does cause an error in the following circumstance". Finally you got around to documenting your issue.

The standard requires that if the first character of a field is a double-quote, that any embeded double-quote must be escaped with a double-quote and that the field ends with a double-quote (right before the field separator or record separator (ie "this""stuff"), and that everything between the two double-quotes is part of the field contents. Embeded double-quotes that are not the first character of the field are not a problem.

For example, this csv file:

a,b,c
test"test,"test""test",doorknob

works exactly according to the standard:

SQLite version 3.41.0 2022-11-28 14:59:27
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> .import crap.txt t0
sqlite> .mode qbox
sqlite> select * from t0;
┌─────────────┬─────────────┬────────────┐
│      a      │      b      │     c      │
├─────────────┼─────────────┼────────────┤
│ 'test"test' │ 'test"test' │ 'doorknob' │
└─────────────┴─────────────┴────────────┘

The developers may take pity and decide to add a --fubarquoting option (or similar) to the .import command, however, that will have to be supported long-term. It would be easier (and better) if you simply complied with the standard or wrote your own custom importer.

The standard requires [...]

Which standard? The CSV one?

The OP mentioned a TAB-separated file.

From that page:

Another common convention is to use the CSV convention from RFC 4180 and enclose these special characters in double quotes. This can lead to ambiguities.

So what you state as Garbage-In may be valid instead, for a TSV file, no? Since that's only a convention?

What about Postel's law we've been reading around SQLite recently?
Seems fairly reasonable to be able to load such unquoted TSV files in the CLI IMHO.

But you can load files containing embedded double-quotes. You just cannot have the first character of a field be a double-quote unless you are quoting the entire field.

It makes no difference what characters are chosen as the FS and RS (Field Separator and Record Separator). The only difference between FS = <tab> and FS = , or FS = FS (the field separator character) is the character separating the fields (and perhaps the RS (record separator).

Of course, everyone is free to define their own format and use it if they so wish.

I think the issue is that a field with quotes like “a b” can be validity seen as a EITHER a properly (but unnecessarily) quoted field or an “unquoted’ field that happens to have quotes.

The de facto standard is that such fields are treated as a quoted field as that allows for the simplest version of the generator that just quotes ALL fields. It also allows a smarter program to omit the quotes if not needed because there is no quote (or field separator) in the field.

Yes, it says that a program can’t take the simple solution of never quoting, but that tends to have the danger of the field having a character (like the separator) that breaks the file, and would require readers to try and “guess” if the quotes were because the writer realized that it needed to quote the field for a special character, likely by trying to read the field both ways and seeing which one makes more sense. This option gets VERY hard to define all the corner cases and how they should be handled.

Yes, if you are going to define that you are using a restricted set for you data that never needs quoting, but the “standard” doesn’t want to limit files to just that set, which is why quoting is defined at all.

You are basically saying you have a NEW data format, that isn’t a “TSV” file, but is a “UNQUOTED TSV” file, so you need to show that enough people would like this ADDITIONAL format to be worth adding and supporting for the life of the product.

You are permitted to have embedded quotes without quoting the field. You only need to quote the field in the following circumstances: the first character is a quote; or, the field data contains a FS or RS character (whatever they happen to be).

This has been the case for as long as I can remember (about 50 years).

NOTE For the greater certainty an "embedded quote" means a quote that occurs at a location other than the first character of a field.

(Edited to reflect doc page revision.)

Please see my revised answer.

it is not documented how .import deal with quoting, one must guess it

I agree with this critique. Soon, the CLI doc page will I have modified the CLI doc page source to address these details, to be published at the next website docs refresh.

Ironically, it was while reading code to ensure that said doc revisions are accurate that I saw that there is indeed an existing way to do what you want with the CLI. This is also mentioned in the revised doc page.

.import imports csv files.

It merely allows you to "change" the separator characters.

The documentation is pretty straightforward and included in the debugging shell.

.import FILE TABLE       Import data from FILE into TABLE
   Options:
     --ascii               Use \037 and \036 as column and row separators
     --csv                 Use , and \n as column and row separators
     --skip N              Skip the first N rows of input
     --schema S            Target table to be S.TABLE
     -v                    "Verbose" - increase auxiliary output
   Notes:
     *  If TABLE does not exist, it is created.  The first row of input
        determines the column names.
     *  If neither --csv or --ascii are used, the input mode is derived
        from the ".mode" output mode
     *  If FILE begins with "|" then it is a command that generates the
        input text.

There is no support for any format other than CSV, although you may change the Field and Row separator characters as your heart desires.

There is no support for any format other than CSV, although you may change the Field and Row separator characters as your heart desires.

Earlier today, I would (and did) agree with that assertion. However, upon closer study of the CLI's import implementation, I saw that the above is incorrect. See details here.

Soon, the CLI doc page will allow these subtleties to be predicted without reading the shell's code.

Another command is necessary: ...

The interaction of {an initial field names line in imported data} with {pre-existence of the table into which import is done} is already well documented. Nothing I have said goes to gainsay that interaction or its description in the CLI doc page.