qs

With + , percent-encodes the structural nesting-separator dots, not just the literal dots inside a key. That breaks the documented -> round-trip for any nested object whose keys do not contain a literal dot. Repro Deeper nesting clobbers every separator except the last: The control case ( alone) round-trips correctly, so the regression is specific to . What the option means Per the README, encodes the dots that appear in the keys of an object: The dot in is part of the key and must be encoded; the dot before / is the separator inserts and must stay literal. The bug encodes both. Root cause : is the accumulated key path, so this replace runs again at every level of recursion and re-encodes separator dots that were inherited from parent levels. The literal dots inside an individual key are already handled per segment a few lines down (), so the prefix-wide replace is the source of the over-encoding. Fix Encode the dots once per key segment in the top-level driver (the same place and the same way nested child keys are already encoded), and let be the plain accumulated path. Two lines in . Relationship to #562 This is a different defect from the open #562, which fixes the opposite failure: a top-level key that contains a literal dot and has a primitive value was under-encoded ( produced instead of ). #562 never touches the line, so applying it leaves this over-encoding bug present: The two fixes share one line (moving the per-segment encode into the driver), because removing the prefix-wide replace requires the top-level key's own literal dots to be encoded there instead, otherwise the README example regresses. The distinct defect addressed here is the prefix-wide re-encoding on the recursion path. Verification Added a test for the nested separators plus a round-trip assertion; it fails on current HEAD (red) and passes with the fix (green). Full suite green: assertions pass. passes, so every documented example still produces its documented output (the literal-dot cases are unchanged). clean (no new warnings on the changed lines).

Closes #558. This changes parser behavior for malformed nested keys that start a bracket group after a parent key but never close it. Instead of treating the rest of the key as a literal segment, now throws a , which matches the maintainer direction in the issue discussion. Existing behavior is preserved for bracket-prefixed keys and for keys with unterminated inner bracket groups that are already handled as literal segments. Verification:

With , a literal in a key or value is emitted unencoded, so it round-trips back as a space: The iso-8859-1 path encodes via , which leaves untouched, but a in a query string decodes to a space, so the value is silently corrupted. The utf-8 path already percent-encodes it (). I encode as in the iso-8859-1 branch too, matching utf-8, so values containing a survive a round-trip.