Bug 62628 - FILEOPEN: xls file character encoding mismatch
Summary: FILEOPEN: xls file character encoding mismatch
Status: RESOLVED NOTOURBUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.1.0.0.alpha0+ Master
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-03-22 10:17 UTC by Vladislav
Modified: 2015-06-25 08:26 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
A test file (21.00 KB, application/vnd.ms-excel)
2013-03-22 10:17 UTC, Vladislav
Details
Libreoffice screenshot (247.13 KB, image/png)
2013-03-22 10:17 UTC, Vladislav
Details
Openoffice.org screenshot (201.00 KB, image/png)
2013-03-22 10:18 UTC, Vladislav
Details
Excel 2003 opens the test file just fine (52.27 KB, image/png)
2013-03-30 14:20 UTC, Vladislav
Details
LibreOffice git (210.47 KB, image/png)
2013-03-31 06:34 UTC, Vladislav
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Vladislav 2013-03-22 10:17:01 UTC
Created attachment 76897 [details]
A test file

Incorrect character encoding.

How to reproduce:
1. Open attached file.

What expected:
Russian letters in cells.

Actual result:
East-european letters instead of russian ones.
Comment 1 Vladislav 2013-03-22 10:17:49 UTC
Created attachment 76898 [details]
Libreoffice screenshot
Comment 2 Vladislav 2013-03-22 10:18:25 UTC
Created attachment 76899 [details]
Openoffice.org screenshot
Comment 3 A (Andy) 2013-03-30 09:22:11 UTC
I can see it with LO 4.0.1.2 (Win7 Home, 64bit), but I do not have OO and therefore could not test it with OO.  I am wondering why only parts of the Russian text seem to show this mistake.  But if you open this file with MSO 2007 then you get the same result.

@Sasha: Do you maybe have an explanation for this or/and can you confirm this, too?
Comment 4 Vladislav 2013-03-30 14:20:50 UTC
Created attachment 77231 [details]
Excel 2003 opens the test file just fine
Comment 5 Vladislav 2013-03-30 14:30:52 UTC
(In reply to comment #3)
> I can see it with LO 4.0.1.2 (Win7 Home, 64bit), but I do not have OO and
> therefore could not test it with OO.  I am wondering why only parts of the
> Russian text seem to show this mistake.  But if you open this file with MSO
> 2007 then you get the same result.
> 
> @Sasha: Do you maybe have an explanation for this or/and can you confirm
> this, too?

I do not have access to a machine with MSO 2007, but MSO 2003 opens the test file just fine.
A screenshot of MSO 2003 is included.
Maybe MSO 2007 has the same bug too :-)
I'll test the latest git (today or tomorrow) and include more screenshots.
Comment 6 Vladislav 2013-03-31 06:34:54 UTC
Created attachment 77240 [details]
LibreOffice git

Yesterday git still shows the bug.
Comment 7 sasha.libreoffice 2013-04-01 06:34:31 UTC
reproduced in 4.0.1 on Fedora 64 bit and Win XP 32 bit

This file is in format of Excel 95. It contains Russian text not as unicode, but as ANSI Windows cp 1251 encoding. It is one-byte encoding. And looks differently on different locales. On Russian Windows it looks correctly, on another - not.

IMHO this file generated by some old program. If it is 1c then needed upgrading to new version. New version has no such problem.

Possible solution: use Excel to re-save in format of 2003 or more new.
Comment 8 QA Administrators 2015-04-19 03:21:38 UTC
** Please read this message in its entirety before responding **

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

   *Test to see if the bug is still present on a currently supported version of LibreOffice (4.4.1 or later)
   https://www.libreoffice.org/download/

   *If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior
 
   *If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System

Please DO NOT

   *Update the version field
   *Reply via email (please reply directly on the bug tracker)
   *Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 

1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3)

http://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug 
3. Leave a comment with your results. 
4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 
4b. If the bug was not present in 3.3 - add "regression" to keyword


Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa

Thank you for your help!

-- The LibreOffice QA Team This NEW Message was generated on: 2015-04-18
Comment 9 Buovjaga 2015-06-16 16:41:32 UTC
Still bad.

Win 7 Pro 64-bit Version: 5.1.0.0.alpha1+
Build ID: 80ec99db4325a439a8a3f1d420d0a80f8bf9c439
TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-06-16_00:00:20
Locale: fi-FI (fi_FI)
Comment 10 Urmas 2015-06-25 04:33:24 UTC
The intrigue is that it has a wrong encoding with the native Excel 95 Russian version.
Comment 11 Buovjaga 2015-06-25 08:26:52 UTC
(In reply to Urmas from comment #10)
> The intrigue is that it has a wrong encoding with the native Excel 95
> Russian version.

Thanks for notifying, I guess I didn't read the last comment carefully.
Let's set this to NOTOURBUG then.