Bug 59232

Summary:

DBCS: compare improperly in EUC-JP encoding project on workbench encoding MS932

Product:

[Eclipse Project] Platform

Reporter:

Masayuki Fuse <fuse>

Component:

Compare

Assignee:

Andre Weinand <andre_weinand>

Status:

CLOSED FIXED

QA Contact:

Severity:

normal

Priority:

CC:

eclipse

Version:

3.0

Target Milestone:

3.0 RC2

Hardware:

OS:

other

Whiteboard:

Bug Depends on:

61986

Bug Blocks:

Attachments:

Description	Flags
sample java programs	none
screen shot	none

Description Masayuki Fuse

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

2004-04-20 08:06:58 EDT

Created attachment 9697 [details]
sample java programs

Comment 2 Masayuki Fuse

2004-04-20 08:08:10 EDT

Created attachment 9698 [details]
screen shot

Comment 3 Rafael Chaves

2004-04-20 09:46:10 EDT

Moving to Platform/Compare. Please try opening bugs against the specific component.

Comment 4 Andre Weinand

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

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

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

2004-06-02 19:11:12 EDT

fixed for RC2

Comment 8 Masayuki Fuse

2004-06-29 23:26:31 EDT

verified in 3.0 and closing