JISX0201 Not recognized in multi-character set encoding using ISO_IR 13

[homerocda]

Describe the bug
SpecificCharacterSet.valueOf(String... codes) does not get JISX0201 encoding for "ISO_IR 13/ISO 2020 IR 87".

To Reproduce
Add the following test to SpecificCharacterSetTest. The test fails.

@Test
public void testEncodeJapanesePersonNameJISX0201_withAlias() {
      assertArrayEquals(JAPANESE_PERSON_NAME_JISX0201_BYTES,
              SpecificCharacterSet.valueOf("ISO_IR 13", "ISO 2020 IR 87").encode(JAPANESE_PERSON_NAME_JISX0201, PN_DELIMS));
}

Expected behavior
The test should pass as if "ISO 2022 IR 13" was given instead of "ISO_IR 13"

[gunterze]

According DICOM PS 3.3, C.12.1.1.2 Specific Character Set:

If the Attribute Specific Character Set (0008,0005) has more than one value, Code Extension techniques are used and Escape Sequences may be encountered in all character sets. Requirements for the use of Code Extension techniques are specified in PS3.5. In order to indicate the presence of Code Extension, the Defined Terms for the repertoires have the prefix "ISO 2022", e.g., ISO 2022 IR 100 for the Latin Alphabet No. 1. See Table C.12-3 and Table C.12-4. Table C.12-3 describes single-byte character sets for value 1 to value n of the Attribute Specific Character Set (0008,0005), and Table C.12-4 describes multi-byte character sets for value 2 to value n of the Attribute Specific Character Set (0008,0005).

And all Defined Terms listed in Table C.12-3 and Table C.12-4 have the prefix "ISO 2022".

"ISO_IR 13" is listed in Table C.12-2. Defined Terms for Single-Byte Character Sets Without Code Extensions

[gunterze]

I don't argue, that we should not make it more lenient - particularly because I think it's quite easy - , but I would not labeling it "fixing a bug".

[gunterze]

Fixed by 70d1262 and 5921973 (cherry-picked from #870)