Repository navigation
bug: mb_parse_str null byte ends the parsing, not handled literally #25147
Description
Description
The following code:
<?php
$a = mb_parse_str("b=\x00", $output);
print_r( $output );Resulted in this output:
nothing printed, same for "b=\x00baz" printed nothing, when piping it to xxd
But I expected this output instead in xxd:
00000000: 00
and for the second baz appear in xxd
PHP Version
PHP 8.5.4 (cli) (built: Oct 19 2026 14:35:18) (NTS)
Copyright (c) The PHP Group
Built by Ubuntu
Zend Engine v4.5.4, Copyright (c) Zend Technologies
with Zend OPcache v8.5.4, Copyright (c), by Zend Technologies
Operating System
Ubuntu 26.04
Activity
[-]bug: md_parse_str null byte ends the parsing, not handled literally[/-][+]bug: mb_parse_str null byte ends the parsing, not handled literally[/+]alexdowad commentedon Nov 6, 2026
Thanks for the report! This is indeed surprising, and not terribly desirable, behavior. However, at this point, it cannot be considered a "bug". We might call it "surprising legacy behavior which has become the de-facto standard for
mb_parse_str".It seems that this behavior has existed for (perhaps) more than 20 years. During that time, a large amount of extant code has been developed which relies on mbstring. If we suddenly change the behavior today, it's almost certain that some people's code will break. (See: https://www.hyrumslaw.com/) Your "expected" behavior is also divergent from
parse_str, and the inconsistency would also be surprising and non-intuitive.The manual doesn't say anything either way. An actual null byte in a real query string should be encoded as
%00, and the function handles that correctly.Thanks again for the report. If you would like to help to make the situation a bit better, you could consider contributing a documentation update to warn others about this surprising legacy behavior.
alexdowad commentedon Nov 6, 2026
FYI @youkidearitai
youkidearitai commentedon Nov 6, 2026
@alexdowad Thank you for your help.