I have found in different web sites (for example here) this statement:
This PHP code prints a newline using 10 bytes:
echo "\n";
This PHP code prints a newline using 9 bytes:
echo "
";
This PHP code prints a newline using 8 bytes (using the bitwise NOT operator ~):
echo ~õ;
My problem is that I can't make that last solution work in any possible way, test and environment that I used. I have tested on online PHP sandboxes, on local machine, etc, when I execute
echo ~õ;
I get always this output:
<J
Why? Can someone explain why I get this output and why it should print a newline?
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!
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."); ?>
This question already has answers here:
Trim whitespace ASCII character "194" from string
(7 answers)
Closed 6 months ago.
I have a piece of code that reads in values from a CSV file, all working grand and then each individual record is validated and used in an API call to an external source, all of this is working grand.
Now today I have a CSV file uploaded that when I open it it looks to have 3 spaces at the end of each entry in the CSV which causes the API call to fail.
I've tried using trim() but it doesn't do anything, I've also tried using preg_replace('/^((?=^)(\s*))|((\s*)(?>$))/si', '', $pValue) and this isn't having any affect either.
I opened the CSV file in Notepad++ and enabled it to show all symbols, there are clearly 3 spaces and the CR and LF.
Has anyone come across an issue like this before, code snippets below and an example on codepad.
EDIT:
Example: http://codepad.org/DfjzPcUU
Code snippets, if more is needed please let me know.
$vCSVData = self::getCSVData($vPendingFilePath);
foreach ($vCSVData AS $vKey => $vValue)
{
echo self::getNubmer($vValue);
...
}
getCSVData():
private function getCSVData($pFilePath)
{
return call_user_func_array('array_merge', array_map('str_getcsv', file($pFilePath, FILE_SKIP_EMPTY_LINES)));
}
CSV File Snippet:
Blue Table
Green Chair
Temp. Table
As it turns out that what I thought was white space was actually ASCII 194 characters (Thanks to MikeB) for figuring this out, as trim, rtrim, preg_replace, str_replace with the normal " " (empty space) check didn't work the below snippet is what worked for me.
preg_replace("/[\xA0\xC2]/", "", "Table ")
xA0 is char 160 and xC2 is char 194.
Also you can use trim in this instance by using the below statement, using trim over preg_replace is slightly faster for processing time, with that said the overheads in each case and the difference are negligible, in my case either will suffice.
trim("Table ", "\xA0\xC2")
Example: http://codepad.org/8H5Ut2KA
I was able to find out what the 'space' was by using the below code snippet:
var_dump(ord($vString{5}));
Well the title sums it up. If I do this:
fwrite($handle, 'test\r\ntest');
I get litreally that written to a file. That is:
test\r\ntest
It doesn't work for echo or any other function manipulates strings.
This became a problem when I needed to write to a printer in the serial port using ESC/POS. If I use PHP, it prints a bunch of question makrs and french characteres. With Python (plus pyserial), using the following code, works amazingly:
from __future__ import print_function
import serial
ser = serial.Serial('COM4');
ser.write('\x1b\x40');
ser.write('\x0a');
ser.write('\x0a');
ser.write('Hello there');
ser.write('\x0a');
ser.write('\x1d\x56\x42\x03');
My system:
WAMP 2.4 (PHP 5.4.16, Apache 2.4.4) on Windows 7 Home Basic x64
For the backslash sign to escape special characters you need to use double-quoted strings, not single-quoted ones, try these :
fwrite($handle, 'test\r\ntest'); // not working
fwrite($handle, "test\r\ntest"); // works as expected
It may be worth noting that the problem could have been skipped altogether if your data came from another source (non-php file, web form), and happens only when you hardcode your strings inside your script file. For further details, feel free to browse the relevant manual page :
http://www.php.net/manual/en/language.types.string.php
Using a single quote will literally write your string.
To use escaped characters you need to use a double quote instead :
echo "This output will \n expand";
http://www.php.net/manual/en/language.types.string.php
Try using " instead of ' for these escape sequences:
fwrite($handle, "test\r\ntest");
Of course this has been asked before and have searched for solutions, all which have not worked thus far. I want to change out the TM symbol and the ampersand to their html equivelents by using htmlentities or htmlspecialchars:
$TEST = "Kold Locker™ & other stuff";
echo "ORGINIAL: " . $TEST . "<BR/>";
echo "HTML: " . htmlentities($TEST, ENT_COMPAT, 'UTF-8');
This displays:
ORGINIAL: Kold Locker™ & other stuff
HTML:
I have also tried it with htmlspecialchars and the second parameter changed with the same result.
What am I missing that others have claimed worked in other solutions?
UPDATE: I tried just displaying utf8_encode($TEST) and it displayed HTML: Kold Locker™ & other stuff
I dont know why , this worked for me (htmlentities has to be called twice for me)
$html="<html> <head><head>something like this </html>"
$entities_correction= htmlentities( $html, ENT_COMPAT, 'UTF-8');
echo htmlentities( $entities_correction, ENT_COMPAT, 'UTF-8');
output :
<html> <head><head>something like this </html>
I thought I had the same problem as Pjack (msg of Jul 14 at 8:54):
$str = "A 'quote' is <b>bold</b>";
echo htmlentities($str);
gives in the Browser (Firefox in my case) the original string $str (without any translation), while
echo htmlentities(htmlentities($str));
gives:
A 'quote' is <b>bold</b>
(I use PHP/5.4.16 obtained from windows-7 XAMPP).
However, after some more thought it occurred to me that the Browser shows the strings < and > as > and <.
(See the source code in the browser). Second call of htmlentities translates & into & and only then the Browser shows what you expected in the first place.
Your code works for me :-?
In the manual page for htmlentities() we can read:
Return Values
Returns the encoded string.
If the input string contains an invalid code unit sequence within the
given encoding an empty string will be returned, unless either the
ENT_IGNORE or ENT_SUBSTITUTE flags are set.
My guess is that the input data is not properly encoded as UTF-8 and the function is returning an empty string. (Assuming that the script is not crashing, i.e., code after that part still runs.)
I had almost the same problem (in which somehow it showed the same text every time) and with a combination of different echo´s i got it. It seems that webbrowsers like firefox show the same text every time. That´s because when you echo the htmlentities-text, its being converted back into normal text while echoing. When I echo a script with the variable/text to be console.logged, it actually echo´s the htmlentities text (almost) correctly. Instead of replacing every special char with html-codings, it replaces ´em with some other coding i already saw before (I can´t remember the name). Htmlentities-ing it again, I get the same text echo´d again (remember it converts everything), but echoing it in console.log-version gives to me the expected result. Now, again, as a result:
1. Execute htmlentities two times!
2. Don´t (at least with firefox) echo the htmlentities as normal into the webpage. If you´d like to check if the value is actually correct, echo a script that logs it into console.
I hope this could help other guys with the same problem,
VicStudio
EDIT: 3. If you are using a $_POST formular, don´t forget to add accept-charset="UTF-8" (or some other charset) to the <form> tag.
EVEN MORE EDIT: Only do 2 times htmlentities if you wish to echo your result normal into the page. If you wish to directly send in f.e. a database, only do it once! -> what i said before is partually wrong. :(
This is an old post, but for anyone still looking for a solution, here is what I use with success:
echo html_entity_decode($htmlString);