JDK-8177105 : String/byte[] conversion with encoding CP1147
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.nio.charsets
  • Affected Version: 8,9
  • Priority: P4
  • Status: Resolved
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2017-03-14
  • Updated: 2018-02-26
  • Resolved: 2018-02-26
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 10
10Resolved
Related Reports
Relates :  
Description
FULL PRODUCT VERSION :
java version "1.8.0_45"
Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)


ADDITIONAL OS VERSION INFORMATION :
ubuntu 16.04 LTS
Linux LIN0125343 4.4.0-64-generic #85-Ubuntu SMP Mon Feb 20 11:50:30 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

A DESCRIPTION OF THE PROBLEM :
We have an JMS message (TEXT), from COBOL, using comp-3.
We try to get the byte[] from the String, in order to recover our hexa values.

We have an issue while decoding a byte (0x15) with the Cp1147 encoding.
The byte is decode as 0x25 instead of 0x15.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Creating a byte array containing the 0x15 value.
Create string from that byte array, using CP1147.
Create a second byte array from the string, using C1147.


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
We expect the byte to be the same (0x15)
ACTUAL -
The byte's value is 0x25.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
@Test
public void testEncoding1147() throws UnsupportedEncodingException{
byte[] bytes = new byte[]{ (byte)0x15, (byte) 0x7B };


printByte(bytes);


System.out.println("##################################################");


String strBytes1147 = new String(bytes, "CP1047");
System.out.println("strByte Cp1147  ["+strBytes1147+"]");
byte[] bytesDecodes = strBytes1147.getBytes("CP1047");

printByte(bytesDecodes);

System.out.println("##################################################");
	    
Assert.assertEquals("Size of bytes tables not corresponding", bytes.length, bytesDecodes.length);
for(int i = 0; i < bytes.length; i++ ){
	Assert.assertEquals("byte N�� ["+i+"] not matching", bytes[i], bytesDecodes[i]);
}
}


private void printByte(byte[] bytes){
StringBuilder sb = new StringBuilder();
for (byte b : bytes) {
    sb.append(String.format("%02X ", b));
}
System.out.println(sb.toString());
}
---------- END SOURCE ----------


Comments
dup of JDK8186803, which has been fixed in 10
26-02-2018

Yes , you are right. This is reproducible on changing the encoding from CP1047 to CP1147 . JDK 8u121 - Fail JDK 9-ea + 161 - Fail JUnit version 4.4 .15 7B ################################################## strByte Cp1147 [ ��] 25 7B ################################################## E Time: 0.3 There was 1 failure: 1) testEncoding1147(JI9048116) java.lang.AssertionError: byte N [0] not matching expected:<21> but was:<37> at org.junit.Assert.fail(Assert.java:74) at org.junit.Assert.failNotEquals(Assert.java:448) at org.junit.Assert.assertEquals(Assert.java:102) at org.junit.Assert.assertEquals(Assert.java:323) at JI9048116.testEncoding1147(JI9048116.java:28) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:547) at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59) at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98) at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79) at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87) at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77) at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42) at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88) at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51) at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44) at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27) at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37) at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42) at org.junit.internal.runners.CompositeRunner.runChildren(CompositeRunner.java:33) at org.junit.internal.runners.CompositeRunner.run(CompositeRunner.java:28) at org.junit.runner.JUnitCore.run(JUnitCore.java:130) at org.junit.runner.JUnitCore.run(JUnitCore.java:109) at org.junit.runner.JUnitCore.run(JUnitCore.java:100) at org.junit.runner.JUnitCore.runMain(JUnitCore.java:81) at org.junit.runner.JUnitCore.main(JUnitCore.java:44) FAILURES!!! Tests run: 1, Failures: 1
04-04-2017

From submitter: I'm able to reproduce it each time. When I'm using CP297 encoding, I've a similar behavior but inversed (ie : 0x25 will be decoded as 0x15). I'm using JDK 1.8.0_102, with junit 4. The problem is also repeatable onto another computer running Windows 7.
04-04-2017

To submitter: I am not able to reproduce the issue using the test case provided by you. I have tried on both Windows and Linux Ubuntu environments. Here are the results that I get: --------------------------------------------------------------------------------------- JUnit version 4.4 .15 7B ################################################## strByte Cp1147 [ #] 15 7B ################################################## Time: 0.3 OK (1 test) --------------------------------------------------------------------------------------- Please let me know if you have any further inputs that may help to reproduce the issue at our end.
20-03-2017