Keywords: JSON escaping | Unicode handling | cross-language serialization
Abstract: This article delves into the core mechanisms of character escaping in JSON, with a focus on Unicode character processing. By analyzing the behavior of JavaScript's JSON.stringify() and Java's Gson library in real-world scenarios, it explains why certain characters (e.g., the degree symbol °) may not be escaped during serialization. Based on the RFC 4627 specification, the article clarifies the optional nature of escaping and its impact on data size, providing practical code examples and workaround solutions. Additionally, it discusses common text encoding errors and mitigation strategies to help developers avoid pitfalls in cross-language JSON processing.
Core Principles of JSON Character Escaping
JSON (JavaScript Object Notation), as a lightweight data interchange format, adheres to strict specifications for string representation. According to RFC 4627, strings must be enclosed in double quotes, and all Unicode characters may be included directly, except for certain characters that must be escaped: double quote ("), backslash (\), and control characters (U+0000 to U+001F). Notably, the specification explicitly states that "any character may be escaped," indicating that escaping non-control characters is optional, not mandatory.
Handling of Unicode Characters in JSON
Taking the degree symbol (U+00B0) as an example, when serializing the string '15\u00f8C' in JavaScript using JSON.stringify(), the output is "15°C" rather than "15\u00f8C". This is not an implementation error but a result of the specification allowing direct output of printable Unicode characters. Escaping all characters would lead to data bloat: for instance, \u00f8 occupies 6 bytes, while the original character “°” takes only 2 bytes in UTF-8, affecting transmission efficiency.
Potential Issues in Cross-Language JSON Deserialization
When JSON data is passed from JavaScript to Java (e.g., using the Gson library), parsing errors may occur if the receiver expects escaped forms. This often stems from inconsistent text encoding rather than library defects. Ensuring uniform Unicode encoding (e.g., UTF-8) on both ends is crucial. The following code demonstrates an optional workaround in JavaScript to escape non-ASCII characters:
function JSON_stringify(s, emit_unicode) {
var json = JSON.stringify(s);
return emit_unicode ? json : json.replace(/[\u007f-\uffff]/g,
function(c) {
return '\\u'+('0000'+c.charCodeAt(0).toString(16)).slice(-4);
}
);
}
// Test case
var s = '15\u00f8C';
console.log(JSON_stringify(s, false)); // Output: "15\\u00f8C"
console.log(JSON_stringify(s, true)); // Output: "15°C"Avoiding Common Errors and Best Practices
Developers often mistakenly attribute escaping issues to library implementations, overlooking encoding consistency. Recommendations include: 1) verifying that data sources use standard Unicode; 2) manually escaping non-ASCII characters in scenarios requiring strict compatibility; and 3) employing tools to detect encoding conflicts. For example, in Java, ensure Gson is configured to handle UTF-8 correctly:
Gson gson = new GsonBuilder().setDateFormat("yyyy-MM-dd").create();
String json = "{\"temp\": \"15°C\"}";
Data obj = gson.fromJson(json, Data.class); // Assuming proper Data class definitionIn summary, understanding the optional nature of JSON escaping, combined with encoding best practices, can significantly enhance the reliability of cross-platform data exchange.