-
Bug
-
Resolution: Fixed
-
P3
-
1.3.0, 1.4.0
-
beta2
-
x86
-
windows_95, windows_98
In Windows 95/98/Me, we read text from the Clipboard or from a DnD operation
using the CF_TEXT data format. We assume that this text is encoded in the
default encoding for the JRE. This encoding is determined from the active ANSI
code page when the JRE is first initialized.
This turns out to be a great guess, and works very well. However, Win32
applications are free to post ANSI text data in any encoding they wish if they
also post CF_LOCALE data. A truly robust application should read both CF_TEXT
and CF_LOCALE and decode the text according to the specified locale. We
currently do not do this.
We need to modify the data transfer subsystem so that whenever we read CF_TEXT
data we decode it using the locale specified by the clipboard. I assume that
CF_LOCALE data is of type LCID (created by the MAKELCID macro), but I'm not
sure.
using the CF_TEXT data format. We assume that this text is encoded in the
default encoding for the JRE. This encoding is determined from the active ANSI
code page when the JRE is first initialized.
This turns out to be a great guess, and works very well. However, Win32
applications are free to post ANSI text data in any encoding they wish if they
also post CF_LOCALE data. A truly robust application should read both CF_TEXT
and CF_LOCALE and decode the text according to the specified locale. We
currently do not do this.
We need to modify the data transfer subsystem so that whenever we read CF_TEXT
data we decode it using the locale specified by the clipboard. I assume that
CF_LOCALE data is of type LCID (created by the MAKELCID macro), but I'm not
sure.
- duplicates
-
JDK-4399903 System Clipboard cannot handle Unicode Text
-
- Closed
-