Issue Escaping characters since last update

[gijsbert]

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?

 

[Bitpalast]

I think that neither of the two issues is linked to a Plesk update.

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.

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

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.

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.

 

[moswak]

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.

This seems to be a bug in phpmyadmin 4.6.5.1 ? and fixed in 4.6.5.2
""fixes an issue with exporting certain character sequences including a backslash (\), such as \r\n.""
https://www.phpmyadmin.net/news/2016/12/5/phpmyadmin-4652-released/

 

[Bitpalast]

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.

 

[Christopher Lewis]

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.

 

[SanderHa]

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.

Any updates on this??

 

[Christopher Lewis]

Any updates on this??

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.

 

[SanderHa]

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.

Thanks I'll try that out.. Could be really great if this minor update to phpMyAdmin came soon though.

 

[Christopher Lewis]

Plesk has updated phpMyAdmin to 4.6.6 today: https://docs.plesk.com/release-notes/onyx/change-log/#17017

 

[SanderHa]

Plesk has updated phpMyAdmin to 4.6.6 today: https://docs.plesk.com/release-notes/onyx/change-log/#17017

Thanks for the response!!