|
|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2018-04-04 16:39 UTC] jalesmonteiro at hotmail dot com
Description:
------------
Strings beginning with the '<' char can't be printed.
The functions strlen and ctype_print show the return the expected, however the echo and print shows nothing.
Test script:
---------------
<?php
$str = '<Hello>';
echo strlen($str);
echo '<br/>';
echo ctype_print($str);
echo '<br/>';
foreach (count_chars($str, 1) as $i => $val) {
echo 'There were '.$val.' instance(s) of "' , chr($i) , '" in the string.';
echo '<br/>';
}
echo $str;
?>
Expected result:
----------------
7
1
There were 1 instance(s) of "<" in the string.
There were 1 instance(s) of ">" in the string.
There were 1 instance(s) of "H" in the string.
There were 1 instance(s) of "e" in the string.
There were 2 instance(s) of "l" in the string.
There were 1 instance(s) of "o" in the string.
<Hello>
Actual result:
--------------
7
1
There were 1 instance(s) of "<" in the string.
There were 1 instance(s) of ">" in the string.
There were 1 instance(s) of "H" in the string.
There were 1 instance(s) of "e" in the string.
There were 2 instance(s) of "l" in the string.
There were 1 instance(s) of "o" in the string.
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||||||||||||
Copyright © 2001-2024 The PHP GroupAll rights reserved. |
Last updated: Mon Nov 25 23:01:31 2024 UTC |
@rhsoft: Being aggressive and being right aren't mutually exclusive. @jalesmonteiro: I apologise on behalf of the community for the tone used in previous comments; you did nothing to deserve such strong language. However, it is true that this is a mistake on your part rather than a bug in PHP: the < and > signs are displayed by PHP, but are being hidden by your browser, which interprets anything between those symbols as an HTML tag, even if it has no meaning in a current version of HTML. You can check this by selecting "view source" or "inspect element" in your browser. If your whole page of content is actually pain text, you could tell the browser this using header('Content-Type: text/plain'); more likely, you want to display some text within an HTML page, in which case you can escape it using htmlspecialchars() or html_entities(). Search on http://php.net for documentation and examples of all your functions, and happy programming. :)Whether this is or is not a bug may be debatable. Thank you to the OP for raising this issue -- you've given me something to think about! In any event, the code does work outside of a browser context, i.e. on the command line which produced this result: <hello> Anything to see above this line? When I ran this script: <?php $str = '<hello>'; echo $str,"\n"; echo "Anything to see above this line?"; In order for the script to work as you'd wish, you may use htmlentities() as follows: <?php $str = htmlentities('<hello>'); echo $str,"\n"; echo "Anything to see above this line?"; The reason is as others have stated that the characters '<' and '>' hold special meaning in the browser. The fact that the behavior is not identical given the web browser vs. the command line does appear to be an inconsistency but sometimes that's life and we just need to live with it. Or, do we? Maybe this point merits more discussion before hastily closing and dismissing this report as "No Bug".> The fact that the behavior is not identical given > the web browser vs. the command line does appear > to be an inconsistency but sometimes that's life > and we just need to live with it. Or, do we? > Maybe this point merits more discussion before > hastily closing and dismissing this report seriously? <Hello> for a CLI output is just a string, taht's it <Hello> for a HMTL browser is a invalid tagm but still a tag <Hello> for a browser when you send header('Content-Type: text/plain'); before is the ame behavior as for a CLI script - but when you send the browser a html content-type (which is default for non-cli) it's a tag and is not displayed linke <strong> or <h1> or whatever <Hello>Test</Hello> would display "Test" and a html-validator would complain about the unknown tag - that's it> The fact that the behavior is not identical given the web browser > vs. the command line does appear to be an inconsistency but > sometimes that's life and we just need to live with it. Or, do we? > Maybe this point merits more discussion before hastily closing and > dismissing this report as "No Bug". There is no inconsistency. PHP is sending (almost, see next paragraph) the same output in both cases, but the programs receiving that output are handling it differently. But that is entirely up to how the receiving program interprets the output, it's not PHP's responsibility. The CLI maps bytes to characters according to whatever character encoding it is set to; the web browser parses it as an HTTP response containing an HTML document, with all of their rules about headers and how to interpret characters like '<' and '>'. This is why browsers have had a "view source" option since the very earliest days of the web (right back to NCSA Mosaic) - not to mention all the other debugging tools they've picked up since: because what you see when the page is rendered is not exactly what the browser received. If there is any inconsistency between the CLI and web server interfaces, it's that the former does not include HTTP headers at the start of its output (because the terminal would have no use for them* and would just print them like anything else it receives, probably messing up whatever workflow the CLI script was being used for). If you want consistency there, you'd have to stop the web interfaces from automatically adding headers; write all your scripts to include lines like "header("HTTP/1.0 200 OK"); header('Content-type: text/html');" and so forth. (*I have used Telnet as a web client - typing HTTP requests by hand and separating out the headers from the body myself. So it's _possible_ for a terminal to use a web interface - but that's just a consequence of the common protocol infrastructure that makes the Internet. It's not a reason for Telnet to start parsing HTML tags, or for a web browser to stop doing so.)