Community
Participate
Working Groups
See: news://eclipse.org/9rp7ib%249m4%241%40rogue.oti.com
pls investigate this could be a 1.0 fix candidate. Andre can help you with the set-up.
Created attachment 67 [details] test.xsl
e-mail sent to me directly by the newsgroup problem reporter: Hi Dani, I tested on Websphere Studio Site Developer's 10/15 build, so whichever Eclipse is used for that is the one i used. Here's the test file that I used. (See attached file: test.xsl) I just searched for one of the Chinese character elements, and the XSL file wasn't found.
Sent e-mail back to orignal problem reporter: We have looked at the file and have some additional questions. We assume that the wrong encoding is caused by the fact that this type of file (xsl) is interpreted by IE. 1) What is the default encoding inside Eclipse? Evaluate the following code snippet in a scrapbook page: System.getProperty("file.encoding") 2) Please compare the chinese characters in IE with the ones displayed in the text or Java editor inside Eclipse (open the file with the default text editor). Are they rendered the same way? 3) Open the xsl file with Notepad or Word. Are the chinese characters rendered the same way as in IE? 4) Change the type of the test file to text (i.e. txt suffix), open it in IE, compare the characters. We assume that your search scenario will work in this case. 5) Please check the Help->About menu to see the Eclipse build and version info. We do not know on which Eclipse build is used for which WSSD build.
Sent another reminder to the problem reporter.
Here is some more information: 1) What is the default encoding inside Eclipse? MS950 2) Please compare the chinese characters in IE with the ones displayed in the text or Java editor inside Eclipse (open the file with the default text editor). Are they rendered the same way? No, they render as ??? 3) Open the xsl file with Notepad or Word. Are the chinese characters rendered the same way as in IE? Yes, they are the same. 4) Change the type of the test file to text (i.e. txt suffix), open it in IE, compare the characters. We assume that your search scenario will work in this case. The characters are still correct in IE. 5) Please check the Help->About menu to see the Eclipse build and version info. We do not know on which Eclipse build is used for which WSSD build. Build: 20011026
This is a general Eclipse "problem": the platform does not look into the file to detect its type and treat it accordingly. In this case it should recognize the file as of type XML and use the specified encoder to read the file (i.e. provide the contents) - IFile.getContents could do this. If we only enhance the editor to handle such cases then (text) search would give wrong results. Moving to platform ui for comment.
Similiar requests have come up before and there were some discussions about adding mime-type support. This will require involement from multiple teams: SWT & Core to expose platform capabilities and to honour the encodings. UI - To expose this base capability to the user. Taking it up one more level, this enhancement would permit true multi-lingual applications. It's a great idea but I do not believe there is time to address this request now.
Defer
Reopen for investigate
Encoding support needs to improve in 2.1
See duplicate defect report for other cases where encoding support needs work
*** Bug 13949 has been marked as a duplicate of this bug. ***
*** Bug 14435 has been marked as a duplicate of this bug. ***
*** Bug 18751 has been marked as a duplicate of this bug. ***
*** Bug 21161 has been marked as a duplicate of this bug. ***
*** Bug 22332 has been marked as a duplicate of this bug. ***
Is there somebody named Platform-UI-Inbox?
This one of the top 10 issues for 2.1 Anyway, whatever bin we choose, it's still a cross component issue.
Still open in 2.1. Has been shifted to 2.2. The minor improvements in Platform Text don't solve this problem. Moving to Later.
Last I looked improve encoding support was on the to-be-done list for 3.0. Is someone working on it? What progress has been made? Is there any design note? Reason I ask, I'd like a little notice before discovering that some milestone has broken the encoding support I have added to my editor plug-in.
Bug report covering the plan item is bug 37933. Initial APIs changes have been released. Doc to be updated and posted to the web soon. (this week I believe)
Encoding support has been improved for 3.0 and in the 3.1 stream (3.1 M2 or newer) the UI to change the encoding has been unified. Please open new bug reports if the current solution does not fit your needs.
Need to reopen to get rid of LATER.
.
