Bug 59232 - DBCS: compare improperly in EUC-JP encoding project on workbench encoding MS932
Summary: DBCS: compare improperly in EUC-JP encoding project on workbench encoding MS932
Status: CLOSED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Compare (show other bugs)
Version: 3.0   Edit
Hardware: PC other
: P3 normal (vote)
Target Milestone: 3.0 RC2   Edit
Assignee: Andre Weinand CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on: 61986
Blocks:
  Show dependency tree
 
Reported: 2004-04-20 08:06 EDT by Masayuki Fuse CLA
Modified: 2004-06-29 23:26 EDT (History)
1 user (show)

See Also:

Attachments
sample java programs (1.70 KB, application/octet-stream)
2004-04-20 08:06 EDT, Masayuki Fuse CLA 		no flags Details
screen shot (116.08 KB, image/jpeg)
2004-04-20 08:08 EDT, Masayuki Fuse CLA 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Masayuki Fuse CLA 2004-04-20 08:06:28 EDT 
OS:  Windows2003 Standard Edition
Language: Japanese
Build level: wswb-I20040413-200404191247
JDK Version: IBM JDK 1.4.2 Beta
Test case #:    

Description:
Steps to recreate problem:
1-create java program on RHEL 3.0WS Japanese locale (workbench default encoding 
is EUC-JP).
2-create java project on windows2003 (workench default encoding is MS932), and 
change EUC-JP at the project properties > info page
3-import the java programs into the project
4-edit a text in comment, and save
5-compare from local history

<<error>>
bogus all of Japanese text in the file at local history and they are indicated 
as changed.
Comment 1 Masayuki Fuse CLA 2004-04-20 08:06:58 EDT 
Created attachment 9697 [details]
sample java programs
Comment 2 Masayuki Fuse CLA 2004-04-20 08:08:10 EDT 
Created attachment 9698 [details]
screen shot
Comment 3 Rafael Chaves CLA 2004-04-20 09:46:10 EDT 
Moving to Platform/Compare. Please try opening bugs against the specific component.
Comment 4 Andre Weinand CLA 2004-06-02 13:17:17 EDT 
The problem is that FileState.getCharset() returns null in this case.
I suggest to return the getCharset() of the associated IFile.
Moving to platform.core
Comment 5 Rafael Chaves CLA 2004-06-02 13:36:17 EDT 
Andre, I would say that when someone calls IFileState#getCharset, that
information should be extracted from the state itself, and not default to the
corresponding file's charset.

We already have bug 61986 (the one this depends on) for the issue with states
not remembering their charsets at the time they were created. Even when that one
is fixed, I would not expect the corresponding file to be queried anyway.

Isn't there anything you can do on your side to work around bug 61986? For
instance, you could do the same thing you suggested (default to the
corresponding file's charset), or allow the user to manually select a different
charset to use when reading a given state.

If it cannot be worked around, feel free to mark this one as a duplicate of bug
61986.

Moving back (again!) to Compare for comments/further action.
Comment 6 Andre Weinand CLA 2004-06-02 19:10:26 EDT 
I had the impression that delegating the IFileState.getCharset request to the IFile would be a better 
approximation of the desired behavior than the current implementation.

Yes, I can try to workaround this problem in my code (and all other clients need to do the same).
Comment 7 Andre Weinand CLA 2004-06-02 19:11:12 EDT 
fixed for RC2
Comment 8 Masayuki Fuse CLA 2004-06-29 23:26:31 EDT 
verified in 3.0 and closing