Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Doubt about writeEscapedString() #8

Open
glassfishrobot opened this issue May 8, 2016 · 6 comments
Open

Doubt about writeEscapedString() #8

glassfishrobot opened this issue May 8, 2016 · 6 comments
Assignees

Comments

@glassfishrobot
Copy link

There are some doubts about writeEscapedString(). This method
char c = s.charAt; but then at some place it compares c < 0x10FFFF.

But this test trivially always true since char data type is in the range
0x0000 to 0xFFFF. Is the intention of the code to use s.codePointAt()?

Environment

All

Affected Versions

[1.0.4]

@glassfishrobot
Copy link
Author

@glassfishrobot Commented
Reported by j4nbur53

@glassfishrobot
Copy link
Author

@glassfishrobot Commented
Was assigned to kchung

@glassfishrobot
Copy link
Author

@glassfishrobot Commented
j4nbur53 said:
Given that a Java String uses surrogate pairs for ranges above 0xFFFF, the code
somehow does what it should do, since the escaped codes 0x00-0x1F, 0x22 and 0x5c
are anyway in the lowest Unicode plane, not needing surrogate pairs.

@glassfishrobot
Copy link
Author

@glassfishrobot Commented
robin479 said:
There is another subtle error near those lines: the character U+007F ("delete") and the character range U+0080 through U+009F ("C1 control codes") are control characters, which require escaping according to the JSON specification. The solution might be to escape JSON special characters U+0022 and U+005C (and optionally, U+002F), as well as characters for which java.lang.Character.isISOControl() is true.

Additionally, most JavaScript clients (erroneously) require the escaping of ALL line-terminating characters, which includes characters of the type java.lang.Character#LINE_SEPARATOR (currently only U+2028) and java.lang.Character#PARAGRAPH_SEPARATOR (currently only U+2029). Since JSON allows optional escaping of any character, the escaping of these problematic types of characters would be appreciated (see java.lang.Character.getType()).

Here's a replacement for writeEscapedString() which does all that:

void writeEscapedString(String string) {
        writeChar('"');
        int b = 0, len = string.length(); // b =: start of to-be-written characters (buffer)
        for (int i = b; i < len; i++) {
            final char c = string.charAt(i);
            if (c == '"' || c == '\\' || c == '/') {
writeString(string, b, i); b = i+1; // flush/reset buffer
writeChar('\\'); writeChar(c); // escape JSON special character
            } else if (c < ' ' || '~' < c) { // (outside printable ASCII range)
switch (Character.getType(c)) {
    case Character.CONTROL:
        final int idx = "\n\r\t\f\b".indexOf(c);
        if (0 <= idx) {
            writeString(string, b, i); b = i+1; // flush/reset buffer
            writeChar('\\'); writeChar("nrtfb".charAt(idx)); // escape well-known controls
            break; // from switch
        } // else: fall through
    case Character.LINE_SEPARATOR: // most JavaScript consumers require escaping...
    case Character.PARAGRAPH_SEPARATOR:  // ...of ALL line-terminating characters
        writeString(string, b, i); b = i+1; // flush/reset buffer
        final String hex = Integer.toHexString(c);
        writeString("\\u0000", 0, 6 - hex.length());
        writeString(hex);
}
            }
        }
        writeString(string, b, len); // flush buffer
        writeChar('"');
    }

@glassfishrobot
Copy link
Author

@glassfishrobot Commented
This issue was imported from java.net JIRA JSONP-32

@glassfishrobot
Copy link
Author

@lukasj lukasj transferred this issue from jakartaee/jsonp-api Jun 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants