[
https://issues.apache.org/jira/browse/AVRO-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14066718#comment-14066718
]
Brandon Forehand commented on AVRO-1546:
----------------------------------------
The problem with the previous test was actually using Jackson to do the JSON
parsing normalizes the string output automatically.
This test is more like what I originally wrote, but it doesn't explain _why_
the change is desirable.
> Make GenericData.Record.toString consistent
> -------------------------------------------
>
> Key: AVRO-1546
> URL: https://issues.apache.org/jira/browse/AVRO-1546
> Project: Avro
> Issue Type: Bug
> Components: java
> Affects Versions: 1.7.6
> Reporter: Brandon Forehand
> Priority: Minor
> Attachments: unescape_slash.patch, unescape_slash2.patch
>
>
> Currently, if you have a GenericData.Record and call toString on it, it
> provides a JSON representation of this record type. However, if the record
> contains a string that contains a literal forward slash, the forward slash
> gets escaped by the writeEscapedString function which means that the string
> representation is not equivalent after round-tripping the value.
> According to the [ECMA standard for
> JSON|http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf],
> forward slash can be escaped; however, the values {{"\u002F"}},
> {{"\u002f"}}, {{"\/"}}, and {{"/"}} are all the same. Thus, it seems
> preferable to produce the shortest version. This is the way that Jackson
> works as well:
> {code}
> JsonMapper mapper = new JsonMapper();
> JsonFactory factory = new JsonFactory();
> JsonNode node = mapper.readTree(factory.createJsonParser("\"/path/\""));
> mapper.readValue(node, String.class); // => "/path/"
> node = mapper.readTree(factory.createJsonParser("\"\/path\/\"");
> mapper.readValue(node, String.class); // => "/path/"
> {code}
> This shows that whether or not the input is escaped that the JSON output
> produced in both cases is the unescaped forward slash.
--
This message was sent by Atlassian JIRA
(v6.2#6252)