Community
Participate
Working Groups
I200406091200 - Platform encoding: ISO-8859-1 - Have a folder with UTF-8 encoding - Create a java class containing some double-byte characters, e.g. �הצ - any non ASCII will do - Save - Select the java file in the package explorer, and drag-copy (hold Ctrl) it within the same folder - Accept the proposed class name in the popup - Open the new class Observe, depending on the original file - The multi-byte characters have been replaced with '?'s - The file cannot be opened because it is not readable using UTF-8 Examining the file shows that it was created using the platform encoding. Acceptable would be either the encoding of the original file, or the encoding of the container (folder in this case).
The actual copy is created by the change "CreateCopyOfCompilationUnitChange". Have to check what the change does with encodings.
The change has two constructors one defaulting to the workspace encoding one having an encoding as an argument. CreateCopyOfCompilationUnitChange using the constructor defaulting to the workspace encoding.
Fix isn't as easy as I thought at the beginning. The problem is that if the original file inherits the encoding the copied file should inherit the encoding as well. Fix is middle risk and must be reviewed by an encoding expert (best Andre).
Created attachment 12204 [details] Patch that fixes the problem
+1 dirk & erich - the user can loose data. need to check whether the navigator's copy exposes the same problem.
Created attachment 12335 [details] Improved patch after review with Andre
Fix release for RC2. Verified by Andre Weinand.
verifying...
verified that the encoding of the original file is copied - if the original's encoding it was explicitely set, the new file's is set as well - if the original's encoding was inherited, the copy's encoding is inherited as well.
