Add JSON-specific escaping, which has different rules from JS escaping.

Add JSON-specific escaping, which has different rules from JS escaping.BUG=http://crbug.com/11431TEST=base_unittests.exe --gtest_filter=StringEscapeTest.Json*

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=16485

[tony, 2009-05-20 00:34:28]

I see, the spec doesn't allow \x escaping in json.  I would just change
JavascriptDoubleQuote to not use \x escaping (but allow the reader to read \x
properly).  Having two methods that are almost the same doesn't seem useful,
especially since JavascriptDoubleQuote is only used in a couple places.

[Erik does not do reviews, 2009-05-20 01:02:06]

new snapshot uploaded

[tony, 2009-05-20 01:28:19]

LGTM, just some suggestions on moving stuff around.

http://codereview.chromium.org/113606/diff/1028/56
File base/base.gyp (left):

http://codereview.chromium.org/113606/diff/1028/56#oldcode269
Line 269: 'string_escape.cc',
Is there a reason for removing the .cc file?  It seems like there will be less
rebuilding in the long term if we keep the .cc file.  Maybe move the functions
into string_util.*?  Then you wouldn't need to move ToUnsigned into the header
file.

http://codereview.chromium.org/113606/diff/1028/51
File base/string_escape.h (right):

http://codereview.chromium.org/113606/diff/1028/51#newcode22
Line 22: // Note: \v is in the reader, but not here since JSON technically
doesn't
Maybe clarify that it's the JSON spec that doesn't allow it.

http://codereview.chromium.org/113606/diff/1028/50
File base/string_escape_unittest.cc (right):

http://codereview.chromium.org/113606/diff/1028/50#newcode10
Line 10: const struct json_narrow_test_data {
Nit: No indent in namespaces.

http://codereview.chromium.org/113606/diff/1028/50#newcode51
Line 51: const struct json_wide_test_data {
Nit: indent

[Erik does not do reviews, 2009-05-20 16:43:53]

fixed your other nits and committed

http://codereview.chromium.org/113606/diff/1028/56
File base/base.gyp (left):

http://codereview.chromium.org/113606/diff/1028/56#oldcode269
Line 269: 'string_escape.cc',
On 2009/05/20 01:28:19, tony wrote:
> Is there a reason for removing the .cc file?  It seems like there will be less
> rebuilding in the long term if we keep the .cc file.  Maybe move the functions
> into string_util.*?  Then you wouldn't need to move ToUnsigned into the header
> file.

The reason for this was because it's a template.  However, from your suggestion,
I changed it to the style of string_util, where the non-template version of the
function is exposed in the header and the template used in the cc file.  I kept
it in string_escape.cc since string_util is already a bit full.  This still
means that ToUnsigned moves out to the header file, but I think it's a generally
useful concept to expose.

[tony, 2009-05-20 16:57:31]

LGTM!