i bought the domain xn--79n.ws which resolves to ∠.ws. (Still counts as one character on twitter)
I built a custom image upload service and i am trying to echo back the link. Instead of echoing back http://xn--79n.ws/image.jpg, i want to echo back http://∠.ws/image.jpg.
Help please?
All you need to do us add a proper Header to your HTML output and it would work
HTML > HEAD
<meta charset="UTF-8" />
Or
<meta http-equiv='Content-Type' content='Type=text/html; charset=utf-8'>
Thanks
:)
Related
I'm using a meta tag on my page for setting the encoding for the page:
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
Everything works fine if it's a GET Request, but when I submit a form (like a search form) and do a POST Request, all of the unicode characters convert to weird letters.
Why this is happening?
I had the same problem and solution i very simple. Put <body> </body> and this will solve the problem.
I'm using the "wordpress pdf templates" plugin.
In my php pdf generating code, I set the type to utf-8 with this:
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
When I do this, it turns the word workers' to:
workers?
If I remove the utf-8 designation it looks like this:
workers’
My code is very simple and looks like this:
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
</head>
<body>
<div class="post-content">
<?php the_content(); ?>
</div>
</body>
</html>
What am I doing wrong?
This could be because of an encoding mismatch.
One of the places to check is your wp-config.ph since that is one place that the encoding is also defined. Ref: https://www.tipsandtricks-hq.com/how-to-fix-the-character-encoding-problem-in-wordpress-1480
Also note that you have a potential for problems to occur anywhere that one part of your system talks to another. Some of these components are:
Your editor that you’re creating the PHP/HTML files in
The web browser people are viewing your site through
Your PHP web application running on the web server
The MySQL database
Anywhere else external you’re reading/writing data from (memcached, APIs, RSS feeds, etc)
Ref:
https://webmonkeyuk.wordpress.com/2011/04/23/how-to-avoid-character-encoding-problems-in-php
I am wondering why php does certain things twice, instead of once, when a certain meta tag is in the html portion of the file and the file is browsed by Firefox.
The code is like this:
<? /*...normal php code, including writing record to MySQL...*/
send('dan#example.com',$subject,$body);
?>
<!DOCTYPE html><html>
<!--PROBLEM on next line-->
<META http-equiv=Content-Type content="text/html; charset=utf-8">
<head>
<title><?= $thisPage?></title>
<link href="<?= $cssURL?>css.freedom-and-purpose.css" rel="stylesheet" type="text/css" media="screen, projection" />
<?
include $dataPath . 'data.php';
?>
The result is TWO records written the database and TWO emails sent, whenever the page is called by FIREFOX. IE and Chrome not producing the problem.
There is a lot of other code in the program, but the reason I showed the portion above is that removing the line that starts with
<META...
solves the problem.
That meta tag is in there because one of the packages I run included it in their code sample.
So, what is that meta tag causes php to double do on DB-writes? And same thing on sending email?
Chances are this is actually a request for favicon.ico being caught by your main PHP file. Putting an empty file in favicon.ico or preventing your PHP from handling that URL should do the trick
enter code hereI would suggest you go through your code in some details and check its formatting.
Phil mentioned the meta tag about which I agree with. His suggestion of <meta charset="utf-8"> would be my preference.
Secondly the line sending the email looks odd. Single quotes aren't an option in php for data replacement, so the line send('dan#example.com','$subject','$body); would result in an email with the subject "$subject" and body just "$body".
Additionally send('dan#example.com','$subject','$body); appears to be missing a quote after $body.
I would advise you to move away from short php tags for opening and closing chunks of php <? ?> and get in the habit of <?php for clarity and to ensure the server you're using processes the code correctly.
Finally, I hope include $dataPath . 'data.php'; adds a </head> and a <body> to the html, as you're currently missing those too.
I'm working on a php site that needs both Japanese and English. In most places I have no trouble getting the Japanese to display correctly, but I can't get the characters to display if I use a function like this:
echo.php:
<?php
function draw(){
echo "日本語";
}
draw();
?>
I get "日本語"
but if I try this :
index.php:
<?php
some stuff
include "echo.php";
draw();
?>
I get "???".
Is there any way for me to get my echo file to send the data to the first file in a way it can read it?
EDIT:
The website works, and shows Japanese characters correctly, except when it tries to pull a function from a php file
Here's the code:
<html lang="ja">
<head>
<title>Running Projects</title>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body>
<div id="header">
<? php include "layout.php" ?>
</div>
</body>
</html>
Where layout.php is just a file with a list of links, I have this on each page so the links are on every page.
For a different part, I have to use functions.php to get some data from a database and write it to the page, so, I tried putting layout.php into the functions.php and calling it: The English links appeared, but the Japanese links appeared as question marks.
You should change your file encoding to UTF-8 and set the header on the website to UTF-8.
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
in HTML5 you should use:
<meta charset="utf-8" />
or in php
header('content-type: text/html; charset=utf-8');
You problem definitely has something to do with the character encoding. Try to check the following:
All your strings in all PHP scripts are Unicode (UTF-8 is a very common choice). Use utf8_encode() and/or utf8_decode() to force UTF-8 on your strings where necessary.
Your server sends PHP output as Unicode (UTF-8 and preferably, but not necessarily, gzipped data)
Your browser understands and accepts Unicode (UTF-8). Typically browser would send Accept-Charset: UTF-8,*;q=0.5 in the GET request to hint it's Unicode capability.
Finally, I have checked your code with PHP version 5.3.6 and Firefox, Chrome and IE 9. Firefox and Chrome prints the Japanese characters as expected. It's only IE 9 which doesn't print it correctly. Snooping on the GET request from IE reveals, it is indeed not sending any Accept-Charset: UTF-8,*;q=0.5. I am not entirely sure how to force IE to send that because in my case, clearly my server (Apache) together with PHP was definitely sending UTF-8 string back.
One more hint - you may try converting your strings into HTML entities. For example - echo "©"; would print ©. But, I am not 100% sure how to convert all strings into HTML entities using PHP. I have unsuccessfully attempted with htmlentities() and htmlspecialchars(). But, it didn't change anything for IE.
i have same problem. But i handle it.
convert "echo.php"'s encoding to EUC-JP or SHIFT-JIS.
<?php
function draw(){
echo mb_convert_encoding("日本語", 'UTF-8', array('EUC-JP', 'SHIFT-JIS', 'AUTO'));
}
draw();
?>
This works for me :)
That happens when charset is not defined or is incorrect.
You can use meta tags to define the charsets. Place the following meta tags as needed on the head section of the page, and It will be rendered correctly.
HTML 4
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
HTML 5
<meta charset="utf-8" />
add below meta tags to header
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
<meta http-equiv="Content-Language" content="ja" />
MySQL and PHP need to be handling the same character set.
Try adding ..
mysqli_set_charset("utf8");
.. after connecting to your database. Always works for me!
If you are using php and mssql you will also need to specify characterset in the mssql connection string.
Like this:
$connectionInfo = array("Database"=>"db name", "UID"=>"username", "PWD"=>"pw","CharacterSet" => "UTF-8");
$serverName = "server";
$conn = sqlsrv_connect($serverName, $connectionInfo);
Please note you still need to do the things suggested above
declare your html charset like this HTML 5:
<meta charset="utf-8" />
php charset like this:
header('content-type: text/html; charset=utf-8');
I am $_POST'ing the following headline from a form:
Google’s New Partner Android Update Initiative: Very Promising — Maybe; We’ll See
And on the handler page, if the first thing I do is
echo "<pre>";
print_r($_POST);
die();
I see:
Google’s New Partner Android Update Initiative: Very Promising — Maybe; We’ll See
I understand that there are functions to convert & escape characters and their HTML equivalents, but how can I ensure that this content is added into the $_POST in the correct encoding?
Cheers,
not sure if that helps, but it seems like the UTF-8 encoding got mixed up (control characters seem somewhat familiar to me ...). Try to output with utf8_encode() or utf8_decode().
Both the page with the form, and the displaying page need to use the same charset. To reproduce the behavior you show, I had to create 2 pages, one a form, with
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
which posted to a page without that.
If I put the meta tag in both pages, it outputs correctly, if I remove it from both pages, it outputs correctly.
If only the form has it, you get what you posted, and if only the receiving page has it, you get the ?'s.
test.php
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
<form method="post" action="test2.php">
<input type="text" name="string">
<input type="submit">
</form>
test2.php
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
<?php
if(isset($_POST['string']))
{
echo "<pre>";
print_r($_POST['string']);
die();
}
?>
If I paste your string into the input box in test.php, hit submit, I get it back properly in test2.php. If I remove the first line of test2.php, I get the behavior you describe.