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.
Related
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
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).
When I upload a file onto mediawiki with Special Characters in the name it mangles the filename into something that looks like this:
Waterford_(Dáil_Éireann_constituency).png
when it actually writes it to the file when it should actually look like this:
Waterford_(Dáil_Éireann_constituency).png
Which means that when another page links to that file it comes up as a broken image link because it's looking for
http://mysite.com/wiki/images/Waterford_(Dáil_Éireann_constituency).png
I don't want to prevent people from using special characters as often they copy the files from wikipedia which supports special characters, and I think it's something to do with the way my host handles files.
So it would be preferable if there was some way to intercept the way that mediawiki creates the files so that the filepath would be free from special characters while all the references would still work.
MediaWiki is 100% UTF-8 safe, but something somewhere in your Apache/PHP configuration is mangling UTF-8 into ISO 8859-1 (Latin1). Start by making sure your PHP install has mbstring enabled as specified here:
http://www.mediawiki.org/wiki/PHP_configuration
If you're stuck with a messed-up host, then this Talk page has some clues for stabbing your Wiki with a knife to make it dumb down filenames:
http://www.mediawiki.org/wiki/Manual_talk:Configuring_file_uploads#Image_File_Names
I can't speak on how and where to do this in Mediawiki, but a good way to do this would be to urlencode() the file name. Percent encoded file names should work on all platforms, and it's easy to restore them into proper form when necessary.
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).
How can I describe something I can't quite put my finger on?
I have a module for RSS reading "magpierss" it uses xml_parse() and after extensive troubleshooting all I can come up with is that it removes certain entities like "?" character.
I haven't written this module myself but I have traced the code until the part uses xml_parse() and then the output is just replaced.
And to my disappointment this behavior exists on our production server only and not the local server.
I have compared both php.ini file to search for any differences but couldn't find anything.
Could anyone please direct on where to search exactly, i don't even know which direction to start from.
Thanks
mb_string was enabled on the server
and somehow it produces this unexpected behavior with xml_parse()