Bug 76115 - FILEOPEN: Calc can't read XLSX generated by certain software using backslash "\" as file name separator
Summary: FILEOPEN: Calc can't read XLSX generated by certain software using backslash ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
(earliest affected) release
Hardware: Other All
: medium normal
Assignee: Not Assigned
Whiteboard: BSA
Keywords: filter:xlsx
: 131575 (view as bug list)
Depends on:
Blocks: XLSX-External-Generators
  Show dependency treegraph
Reported: 2014-03-13 11:59 UTC by wolney
Modified: 2021-11-04 08:58 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:
Regression By:

planilhas Excel (36.47 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet)
2014-03-13 11:59 UTC, wolney

Note You need to log in before you can comment on or make changes to this bug.
Description wolney 2014-03-13 11:59:29 UTC Comment hidden (obsolete)
Comment 1 retired 2014-03-13 13:35:02 UTC Comment hidden (obsolete)
Comment 2 Adolfo Jayme Barrientos 2014-03-13 19:32:03 UTC
@Foss: Avoid dick-triaging, things such as Google Translate do exist. LibreOffice bugs in foreign languages should be first forwarded to a LibreOffice translator first, instead of being systematically closed. The LibreOffice project has people who speak different languages, why not ask for their help? Also, let's respect the time and effort this bug's reporter has spent.

I'll try to use my very basic Portuguese here:

"Good day,
I've been using only Microsoft products, but I stumpled upon LibreOffice and I loved it.

"I've got this XSLX file which opens in Excel and Ashampoo but Calc can't read it.

"If Calc could open it, that would be an awesome improvement.

"Thank you for your attention.
Yours, ..."
Comment 3 wolney 2014-03-14 14:50:20 UTC
Good day.
My name is wolney.
In my company we are replacing all Officce Microsoft. and are opting for Libre office. I did some testing and this has been the best. But we found a problem. We work with a system that generates files with extension xlsx (Excel 2007). When we opened the file in Excel, the Archiving opens normally, when we opened the Ashampoo (Plan Maker TRIAL 2012) also opens normally. But when we try to open it in Libre or Open office it does not run and error. 
Our company has over 60 pc and we are willing to replace all Officce 2007 by Libre. But this little problem can not let us do these migration.
In some spreadsheet that contains specific calculations, saving to XLS or XLSX corrupts the planila formulas.

hope you can help us. and hope that our observation make a contribution. Enjoyed the libre.

I sent the attached two spreadsheets.


Wolney Wolghan - analyst T.I

From: bugzilla-daemon@freedesktop.org
Sent: Thursday, March 13, 2014 6:48 PM
To: cpdtrac@tractorbel.com.br
Subject: [Bug 76115] FILEOPEN: Calc can't read this particular spreadsheet

Maxim Monastirsky changed bug 76115
      What Removed Added
      Attachment #95716 [details] mime type application/kset  application/vnd.openxmlformats-officedocument.spreadsheetml.sheet

You are receiving this mail because:
  a.. You reported the bug.

Este email está limpo de vírus e malwares porque a proteção do avast! Antivírus está ativa.
Comment 4 Julien Nabet 2014-03-14 22:11:46 UTC
On pc Debian x86-64 with master sources updated today, I could reproduce this.

Unzipping the file, I noticed the encoding was UTF-8 for all of them except xl/sheet1
Just to be sure (because I know nothing about xlsx format), is it normal?

Another thing, I uncompressed your file and a quick test file I made from LO.
Here's the result.
your file:

the test file:

Could the structure difference explain the difficulties of LO?
Comment 5 tommy27 2014-03-17 19:36:11 UTC
tested under Win7x64. can't read test file with and as well.
status NEW. platform ALL according to previous comment. changed version field.
Comment 6 Joel Madero 2015-05-02 15:42:44 UTC Comment hidden (obsolete)
Comment 7 tommy27 2015-05-02 19:21:21 UTC Comment hidden (obsolete)
Comment 8 Xisco Faulí 2016-04-20 13:56:15 UTC
This issue is still reproducible in

Build ID: 3dca8575d63db50b0120fbff09bbfcd056fa3732
CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; 
TinderBox: Win-x86@39, Branch:master, Time: 2016-04-20_05:07:29
Locale: es-ES (es_ES)
Comment 9 Caolán McNamara 2016-04-21 08:48:20 UTC
The problem is that the zip has "\" instead of "/" as the separators.
Comment 10 Caolán McNamara 2016-04-21 08:49:30 UTC
We could make it possible to open this with https://gerrit.libreoffice.org/#/c/24278/
Comment 11 QA Administrators 2017-05-22 13:24:49 UTC Comment hidden (obsolete)
Comment 12 tommy27 2017-05-22 13:47:11 UTC
FILEOPEN still impossible with LibO under Win7x64
Comment 13 eisa01 2018-03-17 14:38:56 UTC
Still present

Build ID: 8e8dd8f320a3ff59ff8a16c1a7a867888ce80700
CPU threads: 2; OS: Mac OS X 10.12.6; UI render: default; 
TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2018-03-13_23:59:29
Locale: en-US (en_US.UTF-8); Calc: group
Comment 14 Timur 2019-09-19 11:50:51 UTC Comment hidden (obsolete)
Comment 15 Timur 2021-08-20 07:44:42 UTC
*** Bug 143958 has been marked as a duplicate of this bug. ***
Comment 16 Volga 2021-08-20 17:58:26 UTC
(In reply to Caolán McNamara from comment #9)
> The problem is that the zip has "\" instead of "/" as the separators.
This could be fixed via integrating even more powerful library to parse the zip format.
Comment 17 Kevin Suo 2021-11-04 04:36:49 UTC
(In reply to Caolán McNamara from comment #10)
The patch prepared by Colan was abandoned. As commented by Michael Stahl:
"we will be able to create invalid zip files with this change".

So, is this a wontfix, or is there any other ways?

I have reported the issue as reported in https://bbs.libreofficechina.org/thread-2881-1-1.html to the upstream software (Kingdee ERP), hopefully they will address this and generate valid zip file not using backslash as file name separators. But I guess there are many other software who generate such invalid files.
Comment 18 Kevin Suo 2021-11-04 04:55:31 UTC
One question is, how can we know whether the FILEOPEN failing is due to that the xlsx file is using "\" as separator, or due to other issues?
Comment 19 Kevin Suo 2021-11-04 05:38:32 UTC
Well, I debugged and find that the test file reported in bug 143958 raised 
"ZipException: PK64 zip file entry /home/suokunlong/lo/source/core/package/source/zipapi/ZipFile.cxx:950"

In ZipPackage::initialize

Thus bug 143958 should not be marked as a duplicate of this bug.
Comment 20 Kevin Suo 2021-11-04 07:47:32 UTC
The easiest way to detect whether the filename path separator is "\" or "/", under linux, is:

For a invalid zip file:

$ zipinfo ./Planilha.xlsx 
Archive:  ./Planilha.xlsx
Zip file size: 37348 bytes, number of entries: 6
-rw----     2.0 fat      716 b- defN 14-Mar-12 16:55 [Content_Types].xml
-rw----     2.0 fat      312 b- defN 14-Mar-12 16:55 _rels\.rels
-rw----     2.0 fat      448 b- defN 14-Mar-12 16:55 xl\_rels\workbook.xml.rels
-rw----     2.0 fat     6792 b- defN 14-Mar-12 16:55 xl\styles.xml
-rw----     2.0 fat      289 b- defN 14-Mar-12 16:55 xl\workbook.xml
-rw----     2.0 fat   327284 b- defN 14-Mar-12 16:55 xl\sheet1.xml
6 files, 335841 bytes uncompressed, 36676 bytes compressed:  89.1%

And For a "valid" zip file, it would be:

$ zipinfo ./LibreOffice_writer.xlsx 
Archive:  ./LibreOffice_writer.xlsx
Zip file size: 4978 bytes, number of entries: 9
-rw----     5.1 fat     1111 bx defN 16-Mar-14 10:42 [Content_Types].xml
-rw----     5.1 fat      386 bx defN 16-Mar-14 10:42 docProps/app.xml
-rw----     5.1 fat      588 bx defN 16-Mar-14 10:42 docProps/core.xml
-rw----     5.1 fat      288 bx defN 16-Mar-14 10:42 xl/sharedStrings.xml
-rw----     5.1 fat     4971 bx defN 16-Mar-14 10:42 xl/styles.xml
-rw----     5.1 fat      883 bx defN 16-Mar-14 10:42 xl/workbook.xml
-rw----     5.1 fat     2198 bx defN 16-Mar-14 10:42 xl/worksheets/sheet1.xml
-rw----     5.1 fat      549 bx defN 16-Mar-14 10:42 xl/_rels/workbook.xml.rels
-rw----     5.1 fat      571 bx defN 16-Mar-14 10:42 _rels/.rels
9 files, 11545 bytes uncompressed, 3590 bytes compressed:  68.9%
Comment 21 Kevin Suo 2021-11-04 07:55:52 UTC
*** Bug 131575 has been marked as a duplicate of this bug. ***