php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Request #78064 var_dump() should display the invisible characters code
Submitted: 2019-05-24 11:12 UTC Modified: 2019-06-09 04:22 UTC
From: jerome at deuchnord dot fr Assigned:
Status: No Feedback Package: *General Issues
PHP Version: 7.3.5 OS: Arch Linux
Private report: No CVE-ID: None
View Developer Edit
 [2019-05-24 11:12 UTC] jerome at deuchnord dot fr 
Description:
------------
In some circumstances, we may get invisible characters in a variable. Currently, these characters are not visible with var_dump() - the only way you can figure out their presence is by copying it and paste it on an editor that displays it (for instance Vim).
This behavior leads to strong difficulties for the developers to debug their script.

This becomes really a problem for instance when your variable is an array and there is an invisible character in one key.

Test script:
---------------
$bom = chr(0xef) . chr(0xbb) . chr(0xbf);
$str = $bom.'Hello World!';
var_dump($str); // string(15) "Hello World!"

Expected result:
----------------
$bom = chr(0xef) . chr(0xbb) . chr(0xbf);
$str = $bom.'Hello World!';
var_dump($str); // string(15) "\0xef\0xbb\0xfeHello World!"

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2019-05-25 10:20 UTC] sjon@php.net 
While an interesting request - you have some incorrect assumptions.

First of all - var_dump actually shows you the difference in the number of characters as illustrated by the included string-length. (it will be string(12) without the BOM).

Additionally - var_dump actually outputs these characters just fine - it's probably your browser that decides not to show them. This can be verified by passing the output through xxd (or an editor that displays it).

For example, when encoding the output from var_dump as json:

$ curl -HAccept:application/json https://3v4l.org/rjuMl

will show you

"output": [{"versions":"7.1.25 - 7.3.5","output":"string(12) \"Hello World!\"\n---------------\nstring(15) \"\ufeffHello World!\"\n"}]

With encoding set to HTML it's also visible:

$ curl https://3v4l.org/rjuMl|xxd

will show you:

00000fd0: 2d2d 2d2d 2d2d 2d2d 2d0a 7374 7269 6e67  ---------.string
00000fe0: 2831 3529 2022 efbb bf48 656c 6c6f 2057  (15) "...Hello W
00000ff0: 6f72 6c64 2122 0a3c 2f64 643e 3c2f 646c  orld!".</dd></dl
 [2019-05-27 11:17 UTC] sjon@php.net
-Status: Open +Status: Feedback
 [2019-05-27 11:23 UTC] nikic@php.net 
Personally I'd like to have this at least for NUL bytes -- NUL bytes in mangled properties are a big source of binary tests in php-src. I'm not sure if encoding much beyond that makes sense though. In particular the characters in the original report are perfectly fine in many non-UTF8 (but still ASCII-compatible) encodings.
 [2019-05-27 11:32 UTC] jerome at deuchnord dot fr 
I agree with Nikita.
Furthermore, I don't think the solutions you provided to see them are actually good solutions, because they assume you know there is an invisible character, which is not always true.
In my case, I struggled several hours looking for the reason why I couldn't reach a key in an array generated from a CSV file, and finally figured out it was because there was the BOM at the beginning of the file.

I do think the presence of such characters should be more explicit.
 [2019-06-09 04:22 UTC] php-bugs at lists dot php dot net 
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Fri May 09 04:01:27 2025 UTC