CSV export: false contents in some columns

Bug Reports
#1

Platform: Windows
OS Version: 10

Version: 3.0.7

I am currently programming some tools to generate ODT reports (LibreOffice) and yWriter projects from the CSV export file. I am using the example project “Murder on the Orient Express”.
I have noticed that not all columns of the CSV export file are formed correctly. Gender, Relevance and Status, for example, contain cryptic strings, presumably Aeon’s internal UIDs. As not all columns are filled in the example, other element types could also be affected.

#2

Check if you have hard line shift (Hard Returns) in any multiline text fields…

In Version 2 I had a lot of problems with that, a new row was added for each Hard Return, and the text field didn’t seem to accept Soft Returns

(Enter vs. Shift+Enter)

So all of my citations from Zotero caused a new row when opening the csv in both Excel and VS Code with CSV extension…
It will usually be caused by the text field above the field you find are problematic…*
So if i.e. Summary or Notes is over this fields, it might be a Hard Return causing it to show another fields data in that property field instead…

Not sure it is the same problem, but worth checking…

#3

Thank you for the tip, Jaran. Your point has nothing to do with the topic of my bug report, but it is always worth taking a close look at the CSV format.

As far as I can tell, Aeon gets it right: multi-line fields are surrounded by double quotes, which is a common convention. If this causes you problems when importing into a spreadsheet, you may have to change the “string separator” import parameters. OpenOffice/LibreOffice Calc show a dialogue when opening CSV files, in which you can specify, among other things, the form of marking cells within which there are commas or line breaks. Single or double quotes are possible. Excel does not ask in this case, but perhaps there is a setting option somewhere.

For my self-programmed tools, I use CSV processing functions of the Python standard library, which are configurable in this respect. The CSV format exported by Aeon can be read in with the default parameters without any problems. Multi-line fields are also processed correctly.

Cheers,
Peter

#4

For me it happened regardless of the “String separator”, I’m using Norwegian and the double quotes is standard for it…
Had to remove all the “Hard Breaks” to get it imported correctly, same when viewing it in VS Code.
There was a few other software I tried to import to, but they didn’t like the hard return for some reason. Even though the string was correctly formatted with double quates… and the settings was as it should be…

To much job, so I dropped using it and imported and mapped the json instead.

but it was just a tips about looking at something out of scope than might have an impact, so…

#5

I just tried it with Excel, and it actually doesn’t work properly there. Microsoft seems to be using its own standards once again. By the way, the csv module of the Python standard library also knows an “Excel dialect”.
Have you ever tried it with LibreOffice Calc? It works fine for me (German language version).

For my tools, I would also like to bypass Aeon’s csv export and access the project file directly. However, the format is undocumented and, from Aeon 2 experience, might be volatile.

Have you created your own library routines for accessing the Aeon file format? That’s what I originally wanted to do, but then I limited myself to csv for the time being.

#6

I don’t remember if I tried OO at that time, but I think I did so…

I also tried with at least 2 other none Microsoft software in addition to CS Code and Notepad++

json:
All I do is opening the json using Power Query in Excel, and based on the “Fields” mapping them to tables in worksheets… it took time but worked, biggest problem was to split the multi-value fields that used the pipe character as a delimiter, but with a little trial and error I got it to work directly in Excel PQ.

I have not tried to do this with the Developer import data feature in excel, only tried that with XML.

#7

The initial problem reported (where there is junk text in some exported columns) is an issue specifically related to properties of the dropdown type. We have submitted it to the development team to fix at the earliest opportunity.