This must be terribly well known, but I can't find anything relevant. Strings in php cant have the characters < and > in them in the wamp environment. It all works fine in the live server. e g under wamp
$teststring = 'aaa<bbb';
echo $teststring;
produces aaa.
I want to edit html files using str_replace() and preg_replace().
I guess I have to modify the php set up but I don't know how.
I assume it doesn't have anything to do with WAMP, and I'm not even sure I understand the situation fully, because you say "Strings in php cant have the characters <> in them in the wamp environment" (I interpret it as: It doesn't work with WAMP) and then directly afterwards "It all works fine in the live server. e g under wamp" (I interpret it as: It does work with WAMP).
But I believe the problem is just that you are adding stray unencoded <'s into the HTML output. Think about what would happen normally:
<?php echo "I can write <em>emphasized</em> text!"; ?>
...would result in:
I can write emphasized text!
...and not:
I can write <em>emphasized</em> text!
Because you can output HTML from PHP, and the browser will read it as it would read any static HTML page. Now if you just include a random <, it will be interpreted as HTML as said in the comments and will not be valid.
So, in order to have a literal < shown in the browser, it has to be encoded as HTML entity, in this case <, e.g. 3 < 4 instead of 3 < 4. This can be automatically done using the function htmlentities. For example:
<?php echo htmlentities("This is a string with < and > and & and other stuff like this which has to be encoded."); ?>
Related
I have this code:
$success = preg_match('/(.+(駅前)?駅) (\(([^線]+線)\) )?((([^線 ]+) )?(\d+[分時])?)/u', $m, $matches);
Example input text is
大正駅 (JR大阪環状線) ﾊﾞｽ 20分
This regex works on https://regex101.com/ and the code works on http://sandbox.onlinephpfunctions.com/. However, when I run the PHP code on my own computer, it never gives me a match. $matches is an empty array, and $success is 0. Yes, the exact same code. I have verified that the regex is correct (using first link) and that the code itself works (using second link). However, it still refuses to work on my own PC.
OS is Arch Linux, running PHP 7.3.11, system locale is ja_JP.UTF-8 (which I don't think matters, but just in case)
Does anyone see anything wrong with the code?
So I was able to find the problem.
First, I tried just the one-liner commented by Nick (3v4l.org/o4ADM) on my PC, and it works. (Of course it should. PHP can't be broken.)
So I figured out that it's the data I'm feeding preg_match that should be broken.
Normal prints and echos were in vain--$m is always how it should be. Then I considered AD7six's comment,
Check that the bytes for 駅 etc. are actually the same
so I looked carefully to check that the characters are all Japanese and no Chinese variants are there. And it's all Japanese, it's fine.
So what could it be?
I tried using PHP's file_put_contents to dump the variable to a file, and then typing the same text with my Japanese keyboard manually and saving them to another file. I opened Meld (a diff tool) and compared the two text and voila--the spaces on the text use a different codepoint than the usual half-width space (0x20). It uses 0xA0 instead, which is a "no-break space", apparently. What the heck.
Fortunately, a simple $m = str_replace("\u{00A0}", " ", $m) did the trick.
Thanks to everyone for leading me to the right answer!
I am having trouble with this piece of code below. Whenever I run this file from browser it shows me the same code load_file($target_url); foreach($html->find(‘a’) as $link){ echo $link->href."
"; } ?> on the browser and not the desired result. I am working on a website using xampp. Php is also properly configured.
<?php
include_once('/simple.php');
$target_url = "http://www.example.com/";
$html = new simple_html_dom();
$html->load_file($target_url);
foreach($html->find(‘a’) as $link){
echo $link->href."<br />";
}
?>
For some reason it seems like the PHP parser interprets the -> in $html->load_file( as if it should close PHP parsing, thus showing you the rest of the code as HTML.
it interprets -> as if it was a ?>
The server is probably misconfigured, or some strange option is in effect.
Other PHP files may work fine if they do not contain -> so if not using objects
If they are allowed on your server, you could try alternative syntax:
<script language="php">
echo "This is HTML script tags.";
</script>
Or ASP style syntax
<%
echo 'This is ASP like style';
%>
Although ugly it might solve your problem
PHP or your server is not properly configured because instead of executing the code, it is simply outputting it to the browser.
The reason you only see the load_file() code onwards, is because the browser interprets the > on that line as a closing HTML tag. If you view->source in your browser, you'll see the full code.
The curly quotes! The curly quotes!
They show the file has been "treated" by the wrong program (Word???), so there is another char that gets modified usually by those nasty softwares, and it is the DASH (-)!
Your dash in $html->load is probably not a real dash "-" but some similar looking charachter like the long dash "—".
Look at the difference:
----------
real dashes -
––––––––––
alternate dash –
For some reason some parser (ftp?webserver?php?) gets confused by this unexpected char, and outputs a ? instead!
And this ? near the > gives a ?> that closes PHP!!!
Rewrite your file using a proper editor, just delete the dashes and write them again and it will work.
I've got this down to a two line php file:
$s = "<option value=\"%id%\">%desc%</option>";
die($s);
This will output:
%desc%
If I change the <>s to & l t ; & g t ;
then it works but the string I am trying to output is to be interpreted as HTML.
I don't see anything in the PHP string docs to indicate that <>s are special characters that need escaping.
Funny thing is, I have the same problem happening when trying to quote the problem in this forum!
Whats the deal?
You are getting the correct output to your browser, that is
<option value=\"%id%\">%desc%</option>
However, your browser is then parsing this as HTML. You can confirm this by viewing the raw HTML source.
If you do not want your browser to parse it as HTML, use < and >.
I am currently working on a replacement tool that will dynamically replace certain strings (including html) in a website using a smarty outputfilter.
For the replacement to take place, I am using PHP's str_ireplace method, which reads the code that is supposed to be replaced and the replacement code from a database, and then pass the result to the smarty output (using an output filter), in a similar way as the below.
$tpl_source = str_ireplace($replacements['sourceHTML'], $replacements['replacementHTML'], $tpl_source);
The problem is, that although it works great on my dev server, once uploaded to the live server replacements occasionally fail. The same replacements work just fine on my dev version though. After some examinations and googling there was not much I could find out regarding this issue. So my question is, what could influence str_replace's behavour?
Thanks
Edit with replacement example:
$htmlsource = file_get_contents('somefile.html');
$newstr = str_replace('Some text', 'sometext', $htmlsource); // the text to be replaced does exist in the html source
fails to replace. After some checking, it looks like the combination of "> creates a problem. But just the combination of it. If I try to change only (") it works, if I try to change only (>) it works.
It might be that special chars like umlauts do not display on the live server correctly and so str_replace() would fail, if there are specialchars inside the string you want to replace.
Is the input string identical on both systems? Have you verified this? Are you sure?
Things to check:
Are the HTML attributes in the same order?
Are the attribute values using the same kind quote marks? (eg <a href='#'> vs <a href="#">)
Is there any other stray HTML code getting in there?
Is the entity encoding the same? (eg vs - same character; different HTML)
Is the character-set the same? (eg utf-8 vs ISO 8859-1: Accented characters will be encoded differently)
Any of these things will affect the result and produce the failures you're describing.
This was a trikcy problem, and it ended up having nothing to do with the str_replace method itself;
We are using smarty as a tamplating system. The str_replace method was used by a smarty ouput filter in order to change the html in some ocassions, just before it was delivered to the user.
Here is the Smarty outputfilter Code:
function smarty_outputfilter_replace($tpl_source, &$smarty)
{
$replacements = Content::getReplacementsForPage();
if (is_array($replacements))
{
foreach ($replacements as $replacementData)
{
$tpl_source = str_replace($replacementData['sourcecode'], $replacementData['replacementcode'], $tpl_source);
}
}
return ($tpl_source);
}
So this code failed now and then for now apparent reason... until I realized that the HTML code in the smarty template was being manipulated by an Apache filter.
This resulted into the source code in the browser (which we were using as the code to be replaced by something else) not being identical to the template code (which smarty was trying to modify). Result? str_replace failed :)
I'm trying to replace something like:
$text = "Hello <--name--> !!";
echo str_replace("--","?",$text);
Expected:
Hello <?name?> !!
Result:
Hello !!
(I'm checking the source code, and I have short open tags enabled)
I have tried so many ways but it seems that I can't never have as result any <? (or <?php) string.
I think it may be related to Suhosin patch that is enabled by default in Ubuntu. Before doing anything else, does someone knows how to get that to work?
Thank you.
UPDATE:
I tried directly in command line and it worked. Yea, the problem was that anything between php tags is not displayed in the browser (Chrome), not even in the source code.
echo "A <"."?"."php"." echo 1 "." ?".">"." B";
In Chrome displays "A B" when looking at the source code. But Firefox displays it complete... So in summary Chrome was tricking me ;)
Thank you!!!
Sorry I had to choose the best answer... but for me the 3 answer were correct.
Did you really look into the source view of the browser? <? ?> sections tend to be interpreted as tags.
If you're not using eval() anywhere, there is no way these tags will be actually interpreted by PHP.
Maybe Suhosin filters those out but that would surprise me. You may be able to get around it by using
< >
instead.
It's got nothing to do with Suhosin.
<?name?> !! when displayed in an HTML page results in !!
Check the page source.
I agree with Pekka and Mike (the other Mike, not me Mike) - you really need to check the HTML source code, as it will show correctly. If you really want to see the less-than and greater-than symbols in the output, you need to replace those with HTML entities (as suggested by Pekka):
$search = array('<', '>', '--');
$replace = array('<', '>', '?');
$text = 'Hello <--name--> !!';
echo str_replace($search,$replace,$text);
You could also use htmlspecialchars, like this:
$text = htmlspecialchars("Hello <--name--> !!");
echo str_replace("--","?",$text); // Hello <?name?> !!
htmlspecialchars will replace:
& with &
" with "
< with <
with >
If you don't want to replace " for some reason or another it's possible (see http://se2.php.net/manual/en/function.htmlspecialchars.php). &, < and >, though, is as far as I know always replaced with &, < and > when you use htmlspecialchars.