elharo opened a new issue, #175:
URL: https://github.com/apache/maven-shared-jar/issues/175

   ### Affected version
   
   HEAD
   
   ### Bug description
   
   JarFileExposer looks inside a jar file for text files to try to find the 
version info. However, it can find this in many different kinds of files. The 
different kinds of files can have different encodings. Worse yet, some like 
MANIFEST.MF are mandated to have UTF-8 while others like pom.properties are 
mandated to by ISO-8859-1. It reads all of them with the platform default 
encoding.
   
   Honestly this whole code looks like a big hack, and something better is 
required that looks for specific files and parses each in a format-appropriate 
way.
   
   Per Gemini
   
   Here are the text encodings expected or mandated by the official 
specifications for each of those metadata file types commonly found inside JAR 
files:
   
   ### 1. `META-INF/MANIFEST.MF`
   
   * **Mandated Encoding:** **UTF-8**
   * **Specification Details:** The [[JAR File 
Specification](https://www.google.com/search?q=https://docs.oracle.com/en/java/javase/21/docs/specs/jar/jar.html%2523jar-manifest&utm_source=gemini)](https://www.google.com/search?q=https://docs.oracle.com/en/java/javase/21/docs/specs/jar/jar.html%2523jar-manifest&utm_source=gemini)
 strictly defines `MANIFEST.MF` as a UTF-8 encoded text file. It explicitly 
mandates that all characters outside the ASCII range must be represented using 
valid UTF-8 byte sequences. Furthermore, lines cannot exceed 72 bytes (not 
characters) without line-folding.
   
   ---
   
   ### 2. `pom.properties`
   
   * **Mandated Encoding:** **ISO-8859-1 (Latin-1)**
   * **Specification Details:** `pom.properties` is generated as a standard 
Java `.properties` file (via `java.util.Properties.store()`). Per the 
traditional Java `.properties` specification, the file format is strictly 
defined as **ISO-8859-1**. Any non-Latin-1 or non-ASCII characters must be 
escaped using Unicode escape sequences (e.g., `\uXXXX`).
   *(Note: While `java.util.Properties` introduced UTF-8 support loading via 
API in Java 9, Maven's underlying generator and standard file spec remain tied 
to the default ISO-8859-1 format with escapes).*
   
   ---
   
   ### 3. `pom.xml`
   
   * **Mandated Encoding:** **Declared in the XML prolog (Defaults to UTF-8 / 
UTF-16)**
   * **Specification Details:** As a standard XML document governed by the 
[[W3C XML 
Recommendation](https://www.w3.org/TR/xml/?utm_source=gemini)](https://www.w3.org/TR/xml/?utm_source=gemini),
 the encoding is determined by the `encoding` attribute in the XML declaration 
(e.g., `<?xml version="1.0" encoding="UTF-8"?>`). If no prolog or encoding 
declaration is present, the W3C spec mandates that XML parsers **must** treat 
the file as **UTF-8** (or UTF-16 if a Byte Order Mark is present). In practice, 
Maven enforces UTF-8 across build POMs.
   
   ---
   
   ### 4. Custom Property Files (`.properties` vs `.txt` / `.json` / `.yaml`)
   
   The expected encoding depends entirely on the file extension and format used:
   
   * **Standard `.properties` files (e.g., `git.properties`, 
`build.properties`):**
   * **Mandated Encoding:** **ISO-8859-1 (Latin-1)** with `\uXXXX` escapes, 
following the `java.util.Properties` specification.
   
   
   * **Plain Text files (e.g., `version.txt`, `VERSION`):**
   * **Expected Encoding:** **UTF-8** or **ASCII**. There is no official Java 
specification for plain `.txt` files, but UTF-8 is the universal defacto 
standard across modern JVM build tools.
   
   
   * **JSON-based config files (e.g., `version.json`):**
   * **Mandated Encoding:** **UTF-8**. Per [[RFC 8259 Section 
8.1](https://www.google.com/search?q=https://datatracker.ietf.org/doc/html/rfc8259%2523section-8.1&utm_source=gemini)](https://www.google.com/search?q=https://datatracker.ietf.org/doc/html/rfc8259%2523section-8.1&utm_source=gemini),
 JSON text exchanged between systems **must** be encoded using UTF-8.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to