Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#1,092 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
45/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
java
Lĩnh vực
data

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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

Ngôn ngữ chính
Java
Star
4.7k
Fork
2.6k
Merge trung bình
4 ngày 11 giờ
Pull request đã merge (30 ngày)
7

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của stleary/JSON-java

Tất cả issue của stleary/JSON-java

Issue tương tự

Thêm issue về Java

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.