And I repeat that the file produced by BoA is read as is by Microsoft
Excel and LibreOffice and many other popular spreadsheet programs,
without preprocessing.
On 6/8/26 12:04 AM, David T. wrote:
It seems to me that the source file from BOA inadvertently contains an
escaped quote character, which throws off the remaining parsing. To
paraphrase an earlier comment, that's a BOA problem, not a GnuCash
one. Preprocessing the file to correct the error seems like the proper
solution.
David T.
On June 8, 2026 7:19:04 AM GMT+05:30, Tom Teixeira
<[email protected]> wrote:
06/01/2026,"Descri\ption 1\","-123.34","2282.45"
06/01/2026,"Description 2\","-234.45","2048.00"
06/02/2026,"Description 3","-943.00","3225.45" The backslash
before the p in the first line is not like anything I have seen
from BoA, but something I tried to verify that it was a backslash
immediately before a quote which causes problems. I have no idea
why some payments have a backslash at the end of the description,
but it is what it is. Anyway, you can observe the result on the
"Import Preview" step of the "Import Transactions from CSV..."
Assistant since only two transactions are shown as available for
import. On 6/7/26 5:18 PM, David Cousens wrote:
Thanks John, I haven't done any testing on it. Then that seems
to imply that BoA is using the backslash in some context in
which the parser is unable to interpret it. I think earlier in
the thread Tom mentioned something about it being used at the
end of a description field rather than as an escaping of the
comma (or other character) being used as the field terminator.
Tom can you post a line or two from the file where it is
giving the problem so we can see the context (modify any
identifying data as necessary preserving the context). David
On Sun, 2026-06-07 at 12:07 -0700, John Ralls wrote:
On Jun 6, 2026, at 20:50, David Cousens
<[email protected]> wrote: which means that
Microsoft Excel. Apple's Numbers, LibreOffice and
Google Sheets and BoAwho implement the backslash as an
escape character which is not part of the official
RFC4180 definition i.e. GnuCash is actually compliant
with RFC4180.
David, The implication of that is that GnuCash doesn’t
treat `\` as an escape character. It does. See
https://bugs.gnucash.org/show_bug.cgi?id=795666,
https://bugs.gnucash.org/show_bug.cgi?id=799529, and
https://bugs.gnucash.org/show_bug.cgi?id=799774 (Tom
Teixeira’s bug) all of which are variations on that theme.
See also
https://github.com/Gnucash/gnucash/blob/f3c053fbee8c290d0fd111b1
25a4a52b03de862e/gnucash/import-export/csv-imp/gnc-tokenizer-
csv.cpp#L51:ff which implements the escaping. Regards,
John Ralls
------------------------------------------------------------------------
gnucash-user mailing list [email protected] To update your
subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
------------------------------------------------------------------------
Please remember to CC this list on all your replies. You can do
this by using Reply-To-List or Reply-All.
_______________________________________________
gnucash-user mailing list
[email protected]
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
