[
https://issues.apache.org/jira/browse/XERCESJ-1288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold resolved XERCESJ-1288.
--------------------------------------------
Resolution: Cannot Reproduce
### Summary Diagnosis
This bug report is **no longer relevant** in modern Java and Xerces-J runtimes.
It stems from historical behavior in legacy JDK versions (specifically Java
1.3/1.4 era) and how character encoding canonicalization was handled between
IBM and Sun/Oracle JVMs.
---
### Is it a user error or a code problem?
It was originally a **platform interoperability/code problem** caused by
mismatched encoding alias aliases between JVM implementations and Xerces'
internal mapping table:
* **Java Spec Case Insensitivity:** In Java (`java.nio.charset.Charset` and
`java.lang.String`), canonical encoding names and aliases are
**case-insensitive**. Requesting `"cp1141"`, `"Cp1141"`, or `"CP1141"` via
standard Java APIs resolves to the exact same encoding.
* **Xerces `EncodingMap` Lookup:** Historically,
`org.apache.xerces.util.EncodingMap` maintained internal static hash tables or
lookups mapping IANA names to Java encoding names and vice versa. In early
versions of Xerces-J, casing mismatches between the keys in `EncodingMap`
(e.g., storing `CP1141` in uppercase for Java-to-IANA but `Cp1141` for
IANA-to-Java) caused lookups to fail on IBM JREs, which returned specific
canonical strings differing in case from Sun's JRE.
---
### Are encoding names case-sensitive in Java?
**No.** According to both the IANA character set specification and Java's
`java.nio.charset.Charset` specification:
1. Encoding names and aliases are strictly **case-insensitive** (e.g., `UTF-8`,
`utf-8`, and `UtF-8` are identical).
2. The `Charset.forName(String)` method normalizes all names to
uppercase/lowercase ASCII internally when performing lookups.
---
### Is it still relevant today?
**No.** This report can be safely resolved as **WONTFIX**, **WORKSFORME**, or
**OBSOLETE** for the following reasons:
1. **Modern `Charset` Integration:** Modern versions of Xerces-J delegate
encoding lookups directly to `java.nio.charset.Charset` and standard Java NIO
charsets rather than relying solely on hardcoded string lookup tables in
`EncodingMap`.
2. **EBCDIC/IBM Encoding Standardization:** `Cp1141` (IBM EBCDIC Germany with
Euro sign) is natively handled across modern OpenJDK, IBM Semeru / Eclipse
OpenJ9, and Oracle JDK builds identically without throwing
`MalformedByteSequenceException` or `Invalid encoding name` errors due to
string casing.
> Problems with encoding name Cp1141
> ----------------------------------
>
> Key: XERCESJ-1288
> URL: https://issues.apache.org/jira/browse/XERCESJ-1288
> Project: Xerces2-J
> Issue Type: Bug
> Components: Other
> Affects Versions: 2.9.1
> Reporter: Ilker Yümsek
> Priority: Major
>
> Hello,
> We develop an xml-based framework for desktop and web applications.
> This framework parses XML-Data with encoding Cp1141.
> If the application, that use our framework, runs in a SUN JRE, all works fine.
> If the runtime environment is an IBM JRE, we become following exception from
> Xerces: "Invalid encoding name: Cp1141".
> org.apache.xerces.util.EncodingMap maps this (and other) encoding(s) in two
> differently ways:
> By IANA to Java mapping with low "p": Cp1141
> By Java to IANA mapping in upper case: CP1141
> And in the official document from SUN are such encoding names defined as
> "CpXXXX":
> http://java.sun.com/j2se/1.3/docs/guide/intl/encoding.doc.html
> Please unify the mapping of such encodings.
> Thank you
> Ilker Yümsek
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
