Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#1,092 1 comentario 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
45/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
java
Área
data

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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

Lenguaje dominante
Java
Estrellas
4.7k
Forks
2.6k
Merge medio
4 d 11 h
PR fusionados (30 d)
7

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de stleary/JSON-java

Todos los issues de stleary/JSON-java

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.