• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Issue Escaping characters since last update

G

gijsbert

Basic Pleskian
We are running plesk 12.5 on centos 6.5 OS. Since one of the last updates we receive various complaints about characters being escaped.

From one customer we received a question why all "enters" are being replaced by \n\r\ when they download a website from there server (FTP) and upload to the same location.

Another customer tells me that when they export a database from phpMyAdmin all \n and \r are being escaped and replaced by \\n and \\r.

Both these problems seem to be related. Has there been any changes in recent plesk updates which could explain this behaviour? If not, does anyone know how this issue can be resolved?
 
I think that neither of the two issues is linked to a Plesk update.

gijsbert said:
From one customer we received a question why all "enters" are being replaced by \n\r\ when they download a website from there server (FTP) and upload to the same location.
Click to expand...
This is probably due to a wrong FTP transfer type setting. Linux and Windows use different line end control sequences. Try to download the file in ASCII mode, then do the same download in BINARY mode and compare the result. When you download the file from Linux to Windows and upload the same file again, it can happen that the files loses some of the control characters, because the line end control sequences are auto-updated by the FTP client according to the operating system (source/target). I suggest this article that explains the problem in more detail: https://danielmiessler.com/study/crlf/#gs.1IaD0S0

gijsbert said:
Another customer tells me that when they export a database from phpMyAdmin all \n and \r are being escaped and replaced by \\n and \\r.
Click to expand...
If a data field value contains literally "\n" this must be escaped to "\\n" when a dump is created, because else upon importing the dump, the expored "\n" would result in "n". The first slash is the escape character, the second slash is part of the field content, so that an import on \\n results in field value "\n", not simply "n". In SQL a dump's linebreaks are never escaped or translated into \n or \r, so you must be talking about a field content. And for field content, the behavior is correct.
 
I see, so what you were initially posting is not what you meant. You did not mean that there is a literal character sequence "\n" in your dataset, but that there is a line break in a text field that translates to \\n on export. That's a big difference. If your customer has a visible "\n" in his dataset, then it must export as \\n. If he has a line break in his dataset, then it must export as \n.
 
Does anyone know when Plesk will update phpMyAdmin to version 4.6.5.2? We are heavily using the export feature and are desparately wating for the fix.
 
Christopher Lewis said:
Unfortunately not. I'm using Plesk's built-in database export functionality in the meantime, but this exports only the whole database. Maybe that's not what you need.
Click to expand...

Thanks I'll try that out.. Could be really great if this minor update to phpMyAdmin came soon though.
 
You must log in or register to reply here.

Similar threads

K
Issue mail_auth_dump Invalid or unsupported Unicode character
Replies
1
Views
928
Peter Debik
P
GDuck24
Issue 18.0.59 (Update #2) failing to update to 18.0.60
Replies
4
Views
441
Kaspar@Plesk
Kaspar@Plesk
V
Resolved All sites hosted on Plesk server not delivering emails only to Google Workspace mail ids
Replies
2
Views
1K
vhon2022
V
Alex Presland
Issue Emails forwarded by Plesk fail DKIM checks with certain attachments
2
Replies
21
Views
2K
Alex Presland
Alex Presland
L
Issue Problems with SSL certificate
Replies
1
Views
875
Martin Dias
Martin Dias
Back
Top