This is my first time with MAC on php, earlier I have been using ubuntu machines for PHP.
I have successfully installed MAMP. and now I have a file(index.php) in htdocs
<?php
echo “hello”;
and its output on safari is :
“helloâ€
I have tried with several different texts, all of them generate absurd output on browser.
Where is the problem in mac, safari or MAMP ?
update :
Without curly quotes the output is ‘hello’
Don't use special quotes like “ and ” but use " or ' instead. Be sure to use a simple text editor when you write code and not something like Word, for example, which will replace the simple quote characters to more fancy ones.
PHP doesn't understand the fancy quotes and won't substitute them with " or ', which have a special meaning in the language.
So, why didn't it break? PHP is incredibly forgiving, which has advantages and disadvantages. Consider the following code, which uses a constant:
define('HELLO', 'Hello world!');
echo HELLO;
This works and will output "Hello world!"
Now, if we pass what looks like a constant to PHP but don't define it, PHP will just output the (inexistent) constant's name instead:
echo HELLOWORLD;
this will output "HELLOWORLD".
The same happens with the text bit “hello” – it tries to look for a constant with that name, doesn't find any, and so just outputs “hello”. This only outputs an E_NOTICE error, which may be disabled by default. It is recommended to output all errors during development to avoid errors such as this:
error_reporting(E_ALL);
echo “hello”;
This will output:
Notice: Use of undefined constant “hello†- assumed '“helloâ€'
And indeed, if we tried to add a space between those special quotes, it would fail as constants can't have a space in their name, and so the text can't be interpreted at all:
echo “hello world”;
Parse error: syntax error, unexpected 'worldâ€' (T_STRING), expecting ',' or ';'
As to why the special quotes like “ aren't being displayed properly, this is because of an encoding problem. “ has an ASCII value above 127 and so can be interpreted in different ways depending on the encoding. Your file is saved in a certain encoding but your server and browser may assume it is in another one, yielding false characters.
you must set your docmuent as utf-8 encode.
method-1: add following html code to your page
<meta charset="utf-8" />
method-2: using php code like below
<?
header("Content-Type: text/html;charset=utf-8");
echo “hello”;
?>
the header must be in the first line of your code.
it will output “hello” ; if you want to output hello please change your double-quote to 'hello'or "hello". because your current double-quote are not english.
You can quote with quote ', double-quote ".
Your double quotes are supposed to be " not “ or ”.
Your Problem With encoded You Must Make It UTF-8 (utf8_encode)
string utf8_encode ( string $data )
Note If Not Work That Mean Problem With Your Pc or Browsers Then Go To Langs In Control panal..
Hope Hear Your Answer...
Related
I want to do a search & replace in PHP with a symbol.
This is the symbol: ➤
I want to replace it with a dash, but that doesn't work. The problem looks like that the symbol cannot be found, even though it's there.
Other 'normal' search and replace operations work as expected. But replacing this symbol does not.
Any ideas how to address this symbol, so that the search and replace function actually can find it and replace it?
Your problem is (almost certainly) related to text/character encoding.
Special characters such as the ➤ you are referring to, are not part of the classical ISO-8859-1 character set; they are however part of Unicode family (codepoint U+27A4 to be exact). This means that, in order to use this (multibyte)character, you have to use a unicode character set, which generally means UTF-8.
All the basic characters (think A-Z, numbers, spaces, ...) overlap between UTF-8 and ISO-8859-1 (which is effectively the default character set), so when you don't use any special characters, you could use the wrong charset and things will pretty much continue to work just fine; that is until you try to use a character that is not part of the basic set.
Since your problem takes place entirely on the server side (inside PHP), and doesn't really touch upon the HTTP and HTML layers, we won't have to go into utf-8 content-type headers and the like, but you should be aware of them for future issues (if you weren't already).
The issue you have should be resolved once you meet 2 criteria:
Not all PHP functions are multibyte-aware; I'm not 100% sure, but i think str_replace is one of those which is not. The preg_replace function with its u flag enabled definitely is multibyte aware, and can serve the exact same function.
The text editor or IDE that you used to create the .php file may or may not be set to UTF-8 encoding, if it wasn't then you should switch that in order to be able to use such characters literally inside the source code.
Something like this should function correctly assuming the .php-file is stored in UTF-8 format:
$output = preg_replace('#➤#u', '-', $input);
Most likely you did not set the header of your PHP script to use the UTF-8 character set. Consider the following:
header('Content-type: text/plain; charset=utf-8');
$input = "This is the symbol: ➤";
$output = str_replace("➤", "-", $input);
echo $input . "\n" . $output;
This prints:
This is the symbol: ➤
This is the symbol: -
as that is simply replaceable using builtin php str_replace function, so that would be better if you can share us your code to check it more.
$str = "hey same let's change this to a dash: ➤";
echo "before: $str \n";
echo "after: ".str_replace("➤", "-", $str);
before: hey same let's change this to a dash: ➤
after: hey same let's change this to a dash: -
example
I am a PHP programmer since 12 years now, but i run out of my possibilities now.
I never had such issue, and i dont know, what's going wrong there.
It is really simply. I want to declare the number 84367 as a variable.
I minimized my script to 1 line, in a new php file, but.. what is going wrong?!
<?php
$x = "84367";
?>
results in
Parse error: syntax error, unexpected '' (T_STRING) in C:\xampp\htdocs\me7dtc\test.php on line 2
Why ?
Simple. Your code contains a unicode character.
Copy and paste this exactly as shown:
<?php
// $x = "84367";
^ unicode hidden character between the last quote and the semi-colon.
$x = "84367";
?>
The commented line is the one that contains the unicode character.
To be more specific, it's the (hidden) character between the last quote and the semi-colon.
A.k.a.: "POP DIRECTIONAL FORMATTING".
Consult the following links on this:
http://www.fileformat.info/info/unicode/char/202c/index.htm
http://www.codetable.net/decimal/8236
This would likely not have shown it when encoded/editing under an UTF-8 environment, but will in ANSI.
In an ANSI encoded environment, it would have shown ‬ immediately following the last quote.
More precisely:
<?php
$x = "84367"‬;
?>
You more than likely were under an UTF-8 coding environment where it is needed for you, but were unable to see it. You could temporarily convert your file to ANSI then switch back to UTF-8 in order to pick up on (hidden) characters such as these.
If you notice the two line below, the double quotes are not the same. the first one is what i have a problem with. They are shown as strange characters like - �. But the secound line double quotes is just fine.
“this is line 1.”
and
"this is line 2."
What is the difference between the two double quotes, and how can the special characters be prevented?
You should make sure, your PHP script uses utf-8, as well as the html meta tag says utf-8.
For the first thing, try in PHP (before any output occurs)
header('Content-Type: text/html; charset=utf-8');
In php, you can escape most HTML specialchars with "htmlentities". See http://php.net/manual/de/function.htmlentities.php
First line you copied probably from MS word/MS Excel. Their double quotes are different and will not parse properly using HTTP. You need to convert them using UTF-8 charset and then display on your website.
In line 1, those quotes are sometimes called "smart quotes". They are ascii code #147 and #148.
In line 2, those are "normal" quotes, ascii code #34.
Because character definition beyond ascii code #127 can become somewhat arbritrary depending on the font used, I try to avoid using the smart quote characters.
Micorosoft Word will (infamously) convert normal quotes to "smart quotes". This "feature" can be turned off in settings.
This issue occurred to me when I copy pasted text text from word document to label. If you observe carefully Word document double quotes looked little curvy opposed to HTML double quotes. Just removing copy pasted doubled quotes and typing again helped. ” - This from Word ." - This is from HTML . You can see the difference yourselves
Here are two versions of a line in a php file:
First version:
if ($projet['sourceDonnees'] === (string)$CONSTANTS['sourceDonnees_saisie']) {
Second version:
if ($projet['sourceDonnees'] === (string)$CONSTANTS['sourceDonnees_saisie']) {
Although they look identical, the first version results in a PHP Parse error: syntax error, unexpected T_STRING, whereas the second version works fine. The difference between the two is that the first version was pasted in and modified whereas the second version was written out by hand entirely. What's going on here?
Notes: The line was copied from a text file encoded in UTF-8 and pasted into another UTF-8 text file. All operations done within gedit, both files written by me in gedit.
You've copied UTF-8 quote marks, which are not parse-able by PHP. Remove the quote marks and replace them with ASCII equivalents (i.e. by typing them).
For more information on ASCII vs UTF-8 quote marks see http://www.cl.cam.ac.uk/~mgk25/ucs/quotes.html
When I copied & pasted your first line into my text editor and turned on the "show invisible characters" option, it looked like this:
if ($projet['sourceDonnees']•=== (string)$CONSTANTS['sourceDonnees_saisie']) {
Notice the • between the ] and the ===.
Your second line of code showed perfectly clean.
Many times you will pick up stray invisible characters when you copy & paste text from websites. However, I do not know what keyboard combination will reproduce this from scratch.
Further experimentation reveals this invisible character as "non-ASCII"... the BBEdit text editor simply calls them "gremlins", and even has a "zap gremlins" function.
unexpected T_STRING is usually an issue with your quotes or tick marks. The 's in the code that you copied are UTF-8 and probably a version of the quote that PHP cannot parse, like the backticks we use for inline code here on SO. Try changing them to a regular single quote and it'll likely solve your issue.
If that's not the case, make sure you didn't miss the semicolon at the end of your function. This can cause the same error.
I am using shared server with a php script that sends a number to my application. The server like to mess with me by adding an invisible ' to that number. I've been trying for around 6 hours fix this but there is no way for me to access the '. As soon as I convert the number(string form) to a real number it give an error that say the number looks like this: '200. You can never see the ' in logcat, only if the error occurs. If I log the string's length, it counts one more character than there should be. It works when I test it localy on my computer but when I upload it to the shared server it adds the '. Do anyone know why this is happening? Also is there any method to convert a string with a ' in it to a number without using any string manipulation methods since there is no way to access the ' ?
Try trimming the string before converting:
String number = dataFromServer.trim();
Integer.parseInt(number);
Are you sure the invisible thing is the quote character? It may be that the code that generates the error message attempts to put quotes around the string, but that there is something after the digits that eats the closing quote when displayed. (For example, a leading UTF-16 surrogate codepoint, or a U+0000?). Try to log out the numerical code units in the string you receive one by one.
Isn't your php script file encoded in "UTF-8 with BOM"?
If yes try "UTF-8 without BOM", since it's a nasty-sometimes-invisible caracter that gets added at the beginning of the file and "sometimes" gets interpreted by the server.