Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

JSONML.toString() and XML.toString() omit escaping for literal newlines (\n), causing whitespace loss in downstream XML parsers (Regression from #1070)

Aperta
  • Qualcosa non va?
#1,092 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
45/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
java
Ambito
data

Direzione di ricerca

Start with XML.mustEscape(int cp) and XML.escape in the XML class, then trace how JSONML.toString and XML.toString reach them. The known regression is that 0xA, 0xD and 0x9 no longer get escaped on output, while numeric references like 
 must still parse on input. Check the existing tests for the #1059 and #1070 behaviour before changing anything. Done means literal newlines, carriage returns and tabs in values serialize as numeric entities, and the parsing tests still pass.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Awaiting further input from submitter No changes at this time

Hello,

When a JSONObject containing a string with newline characters (\n) is converted to XML using JSONML.toString() (or XML.toString()), the newlines are output as literal newline characters instead of being XML-escaped (e.g., to 
).
Because literal newlines in attribute values or specific text nodes are subject to W3C Newline Normalization by downstream XML parsers, the structural formatting and whitespace are completely lost or altered when the generated XML is parsed by another system.
This behavior is a side effect of the fix introduced in PR #1070 (which solved #1059). While PR #1070 correctly allowed whitespace numeric character references (
) to be accepted during parsing (deserialization), it altered XML.mustEscape(int cp) to return false for 0xA, 0xD, and 0x9. As a result, the serialization path (XML.toString / JSONML.toString) now skips escaping for literal newlines, causing a regression in how whitespaces are preserved during export.

Reproducible Example / Code Snippet
import org.json.JSONObject;
import org.json.JSONML;
import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.assertTrue;

public class XMLNewlineEscapingTest {

    @Test
    public void testJSONMLToStringPreservesNewlines() {
        String jsonString = "{\"tagName\":\"MyTag\", \"value\":\"Lettuce\\nTomato\\nMustard\"}";
        JSONObject jo = new JSONObject(jsonString);

        String xmlOutput = JSONML.toString(jo);
        System.out.println("Generated XML:\n" + xmlOutput);

        // Assert
        // Expected: Newlines should be escaped as 
 to survive XML normalization
        // Actual: It outputs raw, literal newlines <MyTag value="Lettuce\nTomato..."/>
        assertTrue(xmlOutput.contains("&#10;"), "XML should escape literal newlines to preserve them.");
    }
}
Expected Behavior

When serializing to XML, literal control characters like \n (0xA), \r (0xD), and \t (0x9) within string values should be escaped into their corresponding numeric character entities (&#10;, &#13;, &#9;) to prevent downstream XML parsers from stripping or normalizing them.

Actual Behavior

The generated XML string contains raw literal line breaks, which are collapsed or lost according to standard XML whitespace processing rules when loaded by any standard XML parser.

Suggested Root Cause & Fix Hint

The serialization path (XML.escape) heavily relies on XML.mustEscape(int cp). Currently, XML.mustEscape combines both "is this character legally allowed in an XML document?" (W3C range) and "does this character need to be escaped in text/attributes?".
The library needs to differentiate between the deserialization path (where &#10; is valid and shouldn't throw an exception) and the serialization path (where a literal 0xA needs to be actively escaped to ensure data integrity).

Best regards,
Sebastian

Lingua principale
Java
Stelle
4.7k
Fork
2.6k
Merge medio
4g 11h
PR unite (30g)
7

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di stleary/JSON-java

Tutte le issue di stleary/JSON-java

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.