-
Bug
-
Resolution: Fixed
-
P3
-
6
-
b85
-
generic
-
generic
Tony Wyant wrote:
>
> While working on the PBP hosting environment of the BluRay Disc platform,
> I've encountered a number of discrepancies between what the PBP 1.1 TCK
> expects and our Java SE 5 behavior. Many of these can be explained by differences
> between Unicode databases version 3.0 and 4.0. However, there is (at least)
> one difference, which I cannot explain:
>
> For 8859-7 (Greek) the bytes 0x7F-0xAF are mapped to 0xFFFD (no Mapping),
> but for all other encodings, these characters are left untranslated. TCK expects
> the bytes to be converted without changing their values.
>
> Is there any reason for this behavior. Is this a bug in J2SE, a bug in the previous
> implementation, or is the mapping undefined for these characters (so either implementation
> is correct, and the TCK is wrong?). The Unicode mappings at:
> http://www.unicode.org/Public/MAPPINGS/ISO8859/8859-7.TXT
> seem to imply that they should retain their values (i.e. 0x80 -> 0x0080).
>
> While working on the PBP hosting environment of the BluRay Disc platform,
> I've encountered a number of discrepancies between what the PBP 1.1 TCK
> expects and our Java SE 5 behavior. Many of these can be explained by differences
> between Unicode databases version 3.0 and 4.0. However, there is (at least)
> one difference, which I cannot explain:
>
> For 8859-7 (Greek) the bytes 0x7F-0xAF are mapped to 0xFFFD (no Mapping),
> but for all other encodings, these characters are left untranslated. TCK expects
> the bytes to be converted without changing their values.
>
> Is there any reason for this behavior. Is this a bug in J2SE, a bug in the previous
> implementation, or is the mapping undefined for these characters (so either implementation
> is correct, and the TCK is wrong?). The Unicode mappings at:
> http://www.unicode.org/Public/MAPPINGS/ISO8859/8859-7.TXT
> seem to imply that they should retain their values (i.e. 0x80 -> 0x0080).