Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||Can't open files with Unicode filename or path from Explorer|
|Status:||CLOSED FIXED||QA Contact:||issues@framework <issues>|
|Priority:||P3||CC:||issues, kpalagin, mikhail.voytenko, nkanovsky, rainerbielefeld_ooo_qa, taipeitech, www.openoffice.org|
|Version:||OOo 2.0.2||Keywords:||needmoreinfo, oooqa|
|Target Milestone:||AOO Later|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
Description joren 2006-04-26 05:29:05 UTC
The problem: Files with either Unicode in the path or in the filename will not open. (ie, c:\ã‚ã‚ŠãŒã¨ã†\ã²ã‚‰ãŒãª.odt will not open.) The Open Office splash screen will appear, then disappear and no application window will open. This occurs for all OpenOffice file types. Unicode was tested using Japanese IME in Windows 2000 - I'm assuming this also applies to any Unicode set in any version of Windows that supports them in filenames. Steps to reproduce problem: 1. Create a new folder in Windows Explorer. Give it a name containing Unicode characters. Open the folder and create an OpenOffice file, with or without Unicode. 2. From within the Windows Explorer interface, double-click on the file to open it. OR 1. Create a new OpenOffice file, in any folder. Give it a name containing Unicode characters. 2. From within the Windows Explorer interface, double-click on the file to open it. Workaround: You can open the file from within any OpenOffice.org application, using the File menu's "Open..." item. P.S. I tried to find a duplicate for this entry but cannot. It seems like an incredibly obvious one, so I was surprised not to find anything. Apologies in advance if I am in error.
Comment 1 Rainer Bielefeld 2006-04-26 11:45:35 UTC
Confirm the problem for "2.0.2 German version WIN XP: [680m5(Build9011)]" To reproduce the problem. pls use attached file 'test.odt' 1. Open file 2. Save as 'ï»ï»¥ï»±ï»µï»º.odt', by copying the new name from the document to the "save as name pane" (I used standard WIN dialogue) The letters are ARIAL, inserted with Menu "Insert - Special Characters" 3. close all documents without closing OOo 4. Open 'ï»ï»¥ï»±ï»µï»º.odt' by using "recent documents" expected: document will be reopened actual: as expected 5. close again 6. Try with "open document expected: document will be reopened actual: as expected 7. close document again 8. doubleclick on document name in WIN explorer expected: document will be reopened actual: nothing, document will not be opened This seems to be an OOo problem Another test 11. Open file 12. Save as 'ï¼®ï¼®ï¼¡ï¼ï¼¡.odt', by copying the new name from the document to the "save as name pane" (I used standard WIN dialogue, Unicode-letters were shown as rectangles) The letters are ARIAL UNICOED MS , inserted with Menu "Insert - Special Characters" 13. close all documents without closing OOo 14. Open 'ï¼®ï¼®ï¼¡ï¼ï¼¡.odt' by using "recent documents" expected: document (name is shown correctly in dialogue) will be reopened actual: as expected 15. close again 16. Try with "open document" (I used standard WIN dialogue, Unicode-letters were shown as rectangles) expected: document will be reopened actual: as expected 17. close document again 18. doubleclick on document name in WIN Explorer (Unicode-letters were shown as rectangles) expected: document will be reopened actual: Error message "c:\somepath\NNAMA.odt does not exist" (correct path structure, But name 'NNAMA' instead of 'ï¼®ï¼®ï¼¡ï¼ï¼¡' will be shown. This seems to be a OOo problem, because a textfile 'ï¼®ï¼®ï¼¡ï¼ï¼¡.txt' was opened with the standard text editor without problems. I believe that we had something like this in the issue tracker some times ago, but I also failed searching for it.
Comment 2 joren 2006-04-26 19:21:08 UTC
This appears to be a separate, though possibly related, issue. The files named with the Unicode English-alphabet actually give a dialog error saying the file does not exist. Files named with Japanese IME don't even give the error; they just fail to open without explanation. I could not find your test.odt. I would have attached a test case myself, with directories, except that WinZip seems to have the same problem! I'll try uploading an ODT with some Unicode characters people can copy-paste into filenames.
Comment 3 joren 2006-04-26 19:46:44 UTC
Created attachment 36073 [details] Test cases for folders and filenames with Japanese Unicode and Unicode English-alphabet
Comment 4 joren 2006-04-26 19:49:29 UTC
I've got UniTest.odt up. It's got both the NNAMA test-case and a Japanese character case.
Comment 5 thorsten.martens 2006-04-27 08:32:31 UTC
TM-MAV: please have a look, thanks
Comment 6 mikhail.voytenko 2006-04-27 08:54:22 UTC
MAV->HRO: Seems to be a duplicate to issue 51233. Could you please take a look.
Comment 7 Rainer Bielefeld 2006-05-29 13:18:21 UTC
*** Issue 65843 has been marked as a duplicate of this issue. ***
Comment 8 Rainer Bielefeld 2006-08-20 07:45:20 UTC
*** Issue 52240 has been marked as a duplicate of this issue. ***
Comment 9 Rainer Bielefeld 2006-09-29 10:46:11 UTC
*** Issue 55629 has been marked as a duplicate of this issue. ***
Comment 10 stefan.baltzer 2006-11-29 16:23:52 UTC
*** Issue 69691 has been marked as a duplicate of this issue. ***
Comment 11 stefan.baltzer 2006-11-29 16:32:55 UTC
SBA->HRO: see also issue 49889 ("sys file picker (win) crashes with file names containing ASCII characters 1..31"). In there, AS described some results of his evaluation.
Comment 12 kpalagin 2007-02-10 11:11:44 UTC
Dear users, please vote for issue http://www.openoffice.org/issues/show_bug.cgi?id=53184 as it describes very simmilar behavior and probably has the same root cause.
Comment 13 hennes.rohling 2007-07-12 12:15:01 UTC
Was fixed by with different issue and works with OOo 2.2.1
Comment 14 hennes.rohling 2007-07-12 12:15:41 UTC
Comment 15 joren 2007-07-12 16:25:31 UTC
Congratulations on finally closing this bug! I've been waiting to be able to use OpenOffice with my Japanese documents, and now I have tested it and everything works. In my eyes, OOo can now truly claim to be an international product :). Thanks to everyone who helped with this issue.