GNOME Bugzilla – Bug 765544
Convert from XLSX to CSV cannot duplicate values in column
Last modified: 2016-04-26 12:13:38 UTC
Created attachment 326697 [details] Screenshot Hello! We installed Gnumeric 1.12.28, converting form XLSX to CSV mostly ok, but have a problem with first column. When first column value duplicate in other rows, only first row contains a value, other rows are empty in this column. Screenshot added
It's hard to tell what is going on without a sample. Please attach one and also state precisely how you convert. My guess is that the file really does contains the values that you are getting out, i.e., empty strings in some cells. (Those values would be incorrectly computed values.) Also, what program created that xlsx file?
XLSX file http://www.avtoto.ru/test/gnumeric/r14a1.xlsx CSV file http://www.avtoto.ru/test/gnumeric/r14a1.csv COMMAND='ssconvert ' COMMAND="${COMMAND} --export-type=Gnumeric_stf:stf_assistant" COMMAND="${COMMAND} -O 'locale=C format=automatic separator=; eol=windows quoting-mode=always'" COMMAND="${COMMAND} $NAMEEXT $NAME.csv " >> what program created that xlsx file? I can find out tomorrow.
I get a "403 Forbidden" error at that link.
Sorry, try this https://drive.google.com/file/d/0B03a8oqDDaIcQkpZa0N5d2ZjdVk/view?usp=sharing
Got it. I am seeing a large number of message of the form: Лист1!A1406 : Invalid sst ref '2931 ' Лист1!D1406 : Invalid sst ref '14 ' Лист1!E1406 : Invalid sst ref '3657 ' Лист1!F1406 : Invalid sst ref '11 ' Лист1!A1407 : Invalid sst ref '2931 ' Лист1!D1407 : Invalid sst ref '9 ' Лист1!F1407 : Invalid sst ref '11 ' Clearly we are not interpreting this file as intended. Note the space inside the quotes. The standard isn't entirely clear on whether that is allowed, but it is certainly a crazy thing to do. The shared-strings table is weird. It claims to have 14 entries, but then goes on to list thousands. <?xml version="1.0" encoding="utf-8"?> <sst xmlns="http://schemas.openxmlformats.org/spreadsheetml/2006/main" count="14" uniqueCount="14"> <si> <t>Бренд</t> </si> ...
The open question is: what created this file? It claims to be created by Excel, but I really doubt that. In the meantime I have enhanced the parser to accept this.