• Our team is looking to connect with folks who use email services provided by Plesk, or a premium service. If you'd like to be part of the discovery process and share your experiences, we invite you to complete this short screening survey. If your responses match the persona we are looking for, you'll receive a link to schedule a call at your convenience. We look forward to hearing from you!
  • We are looking for U.S.-based freelancer or agency working with SEO or WordPress for a quick 30-min interviews to gather feedback on XOVI, a successful German SEO tool we’re looking to launch in the U.S.
    If you qualify and participate, you’ll receive a $30 Amazon gift card as a thank-you. Please apply here. Thanks for helping shape a better SEO product for agencies!
  • The BIND DNS server has already been deprecated and removed from Plesk for Windows.
    If a Plesk for Windows server is still using BIND, the upgrade to Plesk Obsidian 18.0.70 will be unavailable until the administrator switches the DNS server to Microsoft DNS. We strongly recommend transitioning to Microsoft DNS within the next 6 weeks, before the Plesk 18.0.70 release.
  • The Horde component is removed from Plesk Installer. We recommend switching to another webmail software supported in Plesk.

Resolved Encoding Problem ?

K

karam

Basic Pleskian
Hello Everyone, this might sound strange, but encoding of languages such as Arabic, isn't working recently. (Seems old)
We haven't actually changed any thing, we just recently noticed it.

Can anyone confirm it ?

This is what's happening
Problem.png




That's what should appear

Expected.png
 
Last edited:
How is the encoding done?
What character encoding has the .php or .html file been saved as?
What is the meta charset in your html page?
What is your default PHP charset?
Did you recently upgrade your web server?
Did you recently change the PHP version?
Have there been modifications to the .htaccess file that influence character encoding of the page?
 
Peter Debik said:
How is the encoding done?
What character encoding has the .php or .html file been saved as?
What is the meta charset in your html page?
What is your default PHP charset?
Did you recently upgrade your web server?
Did you recently change the PHP version?
Have there been modifications to the .htaccess file that influence character encoding of the page?
Click to expand...
Hello Peter, thank you.

It's simply a text file with عربي characters
.html file
nothing set
didn't change what comes out of the box in Plesk
Plesk latest update
No
No

But I just figured out it's not new problem, it seems to be old.
What's strange that the same HTML file works locally as expected, but doesn't when hosted on Plesk.

Sorry my knowledge with this subject on webservers is limited.
 
On newer Apache versions, the default character set is UTF-8. The web server expects your file and the characters in the file to be in that format. If they are not, you need to set a different character set, e.g. in the "Apache & Nginx Settings". For example, if you want the webserver to interpret the file content as ISO-8859-1 (probably not suited for your needs, just an example), you'd need to set
AddDefaultCharset ISO-8859-1
in the additional HTTP and HTTPS settings fields of Apache
charset iso-8859-1;
in the additional settings of Nginx and
default_charset = "iso-8859-1"
in the additional PHP settings.

As we don't know what format your file has and how the special characters are encoded in the file itself, you probably need to play around a bit with the settings. Likely all is UTF-8 or UTF-16 (or should be).

In your HTML file you need a line
<meta charset="your character encoding"/>
for example
<meta charset="iso-8859-1"/>
in the <head>...</head> section, too.

And it is a good idea to save the file itself in the desired character encoding. That is an "invisible" thing. Youc an find more information on this with the "file" command manual in Linux and display the encoding with
# file -i <filename>

The trick is to bring all settings into sync, then the content of your file will be correctly displayed. iso-8859-1 in this post is an example only. I am not familiar with Arabic, so I cannot really say whether UTF-8 would be the right format for that or maybe UTF-16 or other character sets.
 
Peter Debik said:
On newer Apache versions, the default character set is UTF-8. The web server expects your file and the characters in the file to be in that format. If they are not, you need to set a different character set, e.g. in the "Apache & Nginx Settings". For example, if you want the webserver to interpret the file content as ISO-8859-1 (probably not suited for your needs, just an example), you'd need to set
AddDefaultCharset ISO-8859-1
in the additional HTTP and HTTPS settings fields of Apache
charset iso-8859-1;
in the additional settings of Nginx and
default_charset = "iso-8859-1"
in the additional PHP settings.

As we don't know what format your file has and how the special characters are encoded in the file itself, you probably need to play around a bit with the settings. Likely all is UTF-8 or UTF-16 (or should be).

In your HTML file you need a line
<meta charset="your character encoding"/>
for example
<meta charset="iso-8859-1"/>
in the <head>...</head> section, too.

And it is a good idea to save the file itself in the desired character encoding. That is an "invisible" thing. Youc an find more information on this with the "file" command manual in Linux and display the encoding with
# file -i <filename>

The trick is to bring all settings into sync, then the content of your file will be correctly displayed. iso-8859-1 in this post is an example only. I am not familiar with Arabic, so I cannot really say whether UTF-8 would be the right format for that or maybe UTF-16 or other character sets.
Click to expand...

Thank you so much Pater for this great explanation, it'll help me and definitely others a lot.
 
I had a similar issue when after being migrated from a grandfathered WiredTree sever on LiquidWeb to a new server on Plesk at LiquidWeb my websites HTML pages encountered what I call "diamond question mark virus" issue where a variety of characters and European letters were not displaying or displaying as a diamond shaped icon with a question mark in it. The LiquidWeb support tried to send me to "my developer" while I am "the developer" and I created those pages using Frontpage Express software, which is WYSIWYG. NO problems for decades displaying the fonts on the internet until I was migrated to a new LW server on Plesque. After several "table tennis matches" with LiquidWeb support and after repeated insistance by me, finally one of the hifgher level technicians at LiquidWeb came up with a fix, which I would liike to contribute to mankind in the form it was posted in the ticket while editing it in certain areas for privacy. I hope this will be "my" or rather that technician's contribution to Earthians:

"In order to get this working I had to disable "proxy mode" within Plesk. What this does is prevents Apache from proxying the content through it, instead Nginx handles the requests by itself. What this means is the UTF coding is being forced through Apache, by default Plesk uses the UTF-8 format. Since your sites are using the format iso-8859-1 characters aren't loading as expected. Comparing the two sites I saw the below code within the Apache includes for thisismydomain.com:


SetHandler proxy:unix:///var/www/vhosts/system/thisismydomain.com/php-fpm.sock|fcgi://0.0.0.0:9000

(The IP address was edited by me as well. Post author)

I am not sure what about this code is causing the issue but once I disabled it the site started loading as it should with proxy mode enabled."

That's it. I hope you find this helpful in some way.
 
You must log in or register to reply here.

Similar threads

M
Issue Error Code 404 for callback URL
Replies
2
Views
523
MISHO0o
M
Heinrich
Resolved PHP sends \ before each response...
Replies
2
Views
305
Heinrich
Heinrich
Y
Question Issue Implementing Dynamic CORS Headers in Plesk’s Additional NGINX Directives
Replies
1
Views
336
yfain
Y
jola
Issue Firewall stops working
Replies
7
Views
836
Peter van der Kleij
P
A
Question Alternative ways to forward emails
Replies
2
Views
788
Aslanj
A
Back
Top