• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:
    https://pt-research.typeform.com/to/AmZvSXkx
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

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

C
Question Strategic questions
Replies
9
Views
1K
mow
M
W
Question How can I stop plesk listening on port 443 completely?
Replies
3
Views
663
AYamshanov
AYamshanov
B
Issue High latency, unreliable performance & 522 errors on a Plesk server that ran fine for 6+ months
Replies
1
Views
229
Sebahat.hadzhi
Sebahat.hadzhi
E
Issue Abnormal CPU usage and Apache crash
Replies
13
Views
3K
MartinT
M
Tim Clarke
Issue Problems with recidive jail
Replies
3
Views
641
La Linea
L
Back
Top