I am running a PHP CLI script on my local machine, which calls an API and receives back UTF encoded string. Now, this string is basically a simple word in Portuguese, and I can see it properly when printed on the screen(terminal). However, on a different machine, some characters are not shown properly. The question is, which php.ini option would I need to set in order to see string properly on the other machine? I haven't touched my PHP.ini in regards to encoding and everything works fine, so I'm not sure what do I need to enable for UTF to work on a php cli app?
Edit: this should not be a terminal issue. To be more specific, API returns back a string(UTF encoded) which is supposed to be found inside an array. However, PHP is issuing a warning on another machine saying that can't find that string inside an array. It is the key doesn't exist error that I'm getting, and the key or the string that is shown doesn't look right, so that's the case.
It is basically
$stringReturnedFromApi = $apiCall();
$this->myArray[$stringReturnedFromApi];
it works right on my machine, on another is complaining that the key doesn't exist, and when I looked up $stringReturnedFromAp, it doesn't look UTF encoded
The other terminals need to be set to UTF-8 encoding. For instance, PuTTY needs to be told what encoding, or he will use (on windows) ANSI if i remember well.
If the other host is not on Windows, just verify the locales to be sure it is UTF-8. This is not on your side that the error is, this is just an encoding which is client-side.
If the result is printed out to a webpage, be sure the charset encoding is set to UTF8 also;
I am not sure that this is actually a PHP problem.
Without seeing your script I can't say anything 100%, but I am guessing that the PHP script is actually correctly outputting the UTF character. The reason it looks odd is because the terminal doesn't understand UTF encoding and is unable to display the character.
You would need to be a little more specific on the details of the terminal application you are using to determine where the actual problem lies. I doubt it is something you can fix in the php.ini
Related
I'm not sure how to debug this, or even how best to describe the problem, but all symfony requests are returning strange characters at the beginning of every page. Example:
§{"id":"c8184631","version":0.1}
This should be a json response. Those two characters appear at the beginning of every response no matter the bundle or controller. But only happens on symfony, regular PHP on that server is fine.
This doesn't happen locally. I'm unsure how to start debugging this or even which questions to ask.
Maybe there are some files with different encoding (utf-8 or iso-8859-13), that happened to me before, but I was not using symfony2, just php.
What I did was open every file and changed the file encoding to utf-8.
You can check the encoding for each file for example in "Notepad ++"
Encoding->Convert to UTF-8.
It worked for me.
So I was developing something with PHP and MongoDB on windows with xampp, and I moved my php files to linux mint, it runs apache2 with php cgi 5.4.
After I moved my files (without changing) to linux, the php started returning these weird characters after every response.
echo 'success';
response comes like this
sucess����������������
when converted it looks like this
sucess�
It seems like they are appended to the end of everything, here is a screenshot of responses with firebug (only left side of the pic)
Link to the Image
Also mongod started echoing some errors that never existed on windows (right side of the picture for reference).
I do not use any special characters, languages, encodings, nothing of that sort.
Did anyone experience anything like this?
Mongo stores all strings as utf-8 and expects them to be delivered as such. Simply convert your data to utf-8 before getting it from mongo and you're set.
I am using mb_convert_encoding for converting texts entered by the user (to utf-8 format) in a X cart site. But when I was trying to run the code the execution terminates at the encoding point. The following code is what I am using for conversion:
mb_convert_encoding($str,"iso-8859-7");
I even checked the phpinfo and the mbstring is enabled there. I don't know whether I need to enable any other settings?. Any help on this will be much appreciated.
Updated : There is one more thing that I missed. We are also converting Greek letters and we don't know whether mb_convert_encoding supports Greek letters.
Check your error log, it will give you plentyful loads of detail on the problem.
On UNIX systems like Linux it is usually configured to be at /var/log/apache2/error.log or /var/log/httpd/error.log.
For the last years I used Notepad++ on Win XP SP2.
As I just have seen, the setting in Notepad++ is to encode new files in "ANSI" in "Windows Format". Basically all files on my harddisk should be ANSI files then, but I'm not sure.
Most .html-files have a charset-tag as "text/html; charset=iso-8859-1", but some have none.
Other files, especially text-files (for example keyword-lists) I stored with Firefox XPCOM-system, I don't know how they are currently encoded.
On Server-side I have Apache with PHP and MySql.
For Upload I used Filezilla.
Now the problem is: I want to use Japanes signs (or arabic, etc.). This only works partly.
I can get my selfmade Firefox-Application to constantly write or read UTF-8. But I can't check everytime which of the old files is which encoding.
Having just read Joel Spolsky's old article about UTF-8 strengthens my view that I simply have to get my whole system changed as much as possible to UTF-8.
As long as I have it running that way locally on my Hard-Disk I could just re-upload everything to the server.
So: How do I get all my files locally transfered to UTF-8?
And: Is it possible at all to have Win XP SP2 using constantly UTF-8 everywhere? Or do I have to check it with every program, or even worse with every file, that the right encoding is to be used.
How about files I get for example in E-Mails or via an USB-stick, or that I download in zip-files? (Or a thousand possibilities more.)
Update:
1.-4. went OK so far. I tried first with BOM, but without seems to be better.
So to 5.) Something I have to change there too. I changed as in 3.) the charset in the html-template-file, and the text coming from the template is displayed correctly. But the text coming from MySql/Php shows the UnknownChar-sign at some places currently, i.e. where there should be Umlaute äöü.
I have changed all collations for text fields in the MySql-Database via phpmyadmin to "utf8_unicode_ci", but that didn't do the trick.
Is it a php-issue, or do I only have to convert somehow the data in the MySql-Database once?
The beauty of UTF-8 is that it's a superset to ASCII, so if your html and php files only contain Latin alphabets (i.e. English and programing/HTML syntax), you don't need to convert the file at all. You can leave most of your file unchanged.
Should you find few exceptions that you want to convert it manually, you may open them up in Notepad++, and do 'Encoding' - 'Convert to UTF-8 (No BOM)'.
Yes, you do need to change/add <meta> charset tag to all the HTML files to make sure the browser render your files in UTF-8.
In Notepad++ you could set the new file to always open with 'UTF-8 (No BOM), Unix'. Also, check the tick on "Apply to ANSI files" so old file can be correctly saved to the new encoding. I suggest the format is because even though you are working on a Windows machine, the web servers usually runs Linux/BSD so the format is the native form (keeping files in native form is important especially when you are using a version control system).
Migrate a live site with database is a different issue. Data in MySQL comes with their own encoding, and from your question I cannot tell if you need to do it and how to do it. Need more specifics on that (if you need to).
I am running a fairly standard LAMP stack.
The problem is an intermittent rendering of UTF-8 characters correctly. About 50% of the time the non-ASCII UTF-8 characters render correctly (e.g. with appropriate diacritical marks), but about 50% of the time I get the '?' rendition instead. If I reload the page, sometimes it corrects the problem and sometimes it does not. It happens with all browsers on all platforms, which suggests a MYSQL or Apache problem but I have not been able to figure it out.
The data base itself is in UTF-8 format and I have never seen the problem while browsing the database in phpMyAdmin.
I issue a SET NAMES utf-8 command upon opening the data base (and have tried changing that to a SET CHARSET utf-8 command) with no luck.
What's confusing me is that it is intermittent, happening in streaks, e.g. it will happen on 30 pages in a row (even if they are just reloads), and then clear up for 10 pages, and then happen again for a few pages, etc.
You can try to see the problem by hitting the 'list' button here: http://latin-words.com/list_vocab.php though it may take many reloads to either make it happen or make it go away
Server Configuration:
Ubuntu: 9.10
Mysql: 5.1.37
PHP 5.2.10
Apache 2.2.12
Any hints would be greatly appreciated?
edit:
For searchers sake, from the comments, the problem was actually an issue doing a SET NAMES utf-8; (incorrect) instead of an SET NAMES utf8; (correct) That doesn't mean my much more obscure reason posted below cannot also be the reason ;)
Sounds like a problem with locales & iconv, try to determine what locale is used in the webserver process the moment all is well, and the moment it doesn't work anymore (try $currentlocale = setlocale(LC_ALL,NULL); or $currentlocale = setlocale(LC_CTYPE ,NULL); to get the used locale).