You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug]: A string value starting with a leading unescaped quote (""content) silently drops the escaped quote #220
When a JSON string value begins with a literal, unescaped double quote
(i.e. the raw text is "key": ""content..., meaning: opening quote, then
immediately another quote that is meant to be a literal character, then
the rest of the content), repair_json treats the second quote as if the
string were empty, and silently drops it instead of escaping it.
This looks related to #46 (unescaped quote followed later by a comma), but
that issue is about a quote appearing in the middle of a string and is
now fixed in this version. This report is about the quote being the very first character of the content, which still fails.
Note the leading \" before hello is missing entirely, and the trailing
quote is duplicated/misplaced as a result. Compare with a control case
where the quote is not at the very start of the string, which repairs
correctly:
>>> repair_json('{"title": "hello \\"world\\" test"}')
'{"title": "hello \\"world\\" test"}' # correct, quote is not at the start
The bug reproduces regardless of what follows (with or without a trailing
comma, with or without other keys):
In parse_string(), when the parser is at the very start of a string's
content (position right after the opening quote) and immediately sees
another ", it currently seems to short-circuit to "empty string" instead
of doing the same look-ahead-for-terminator check it already does for
quotes found later in the string. Applying the same "peek ahead for a
plausible terminator (,, }, ], :, or end of input)" logic at
position 0 of the string content — instead of special-casing it as
automatically empty — should resolve this without affecting the already-
fixed #46 case.
Activity
henryjhj commentedon Aug 24, 2026
Suggested fix direction
In
parse_string(), when the parser is at the very start of a string'scontent (position right after the opening quote) and immediately sees
another
", it currently seems to short-circuit to "empty string" insteadof doing the same look-ahead-for-terminator check it already does for
quotes found later in the string. Applying the same "peek ahead for a
plausible terminator (
,,},],:, or end of input)" logic atposition 0 of the string content — instead of special-casing it as
automatically empty — should resolve this without affecting the already-
fixed #46 case.
mangiucugna commentedon Aug 25, 2026
Hi thanks for reporting, agree this is problematic so I implemented a fix that will fix
""hello" world"to'"hello" world'and""hello"}to"hello"}