O
O
Oleg As2019-08-30 11:57:18
Perl
Oleg As, 2019-08-30 11:57:18

Signs Г€ГГ instead of Cyrillic on a site written in Perl. How to fix encoding?

I am transferring the educational portal of one institute from the old server to the new one.
On the old server: CentOS 5.11, Perl 5.8.6, Postgres, very limited permissions and a lot of completely third-party files.
New server: Debian 9.9, Perl 5.24.1 out of the box, and separately built 5.8.9, Postgres.
On the new version of Perl, for obvious reasons, various minor problems began, all but one were resolved.
The site works in Win1251, the output of the Russian text through print works fine, but through qq krakozyabry like Г€ГГ.
Here is a screenshot:
5d68df784e162790975696.png
I rummaged through a lot of manuals, checked locales, checked settings on two servers, but I definitely miss something.
Changing qq to print is not a solution.
From hopelessness collected ancient Perl 5.8.9. I ran it on it - everything is the same, only AH01215: Wide character in print at is written in the error log with an indication of the line where krakozyabry is printed.
Please tell me which way to look.
The last of the ideas: check and install the Locale::RecodeData::CP1251 module
UPD 09/24/19 Defined string encodings. In pure Perl without Postgres everything works correctly. As soon as a string from Postgres is interpolated, everything breaks. Example: one row from Postgres is requested, the data encoding of the first column is win1251, the second is x-mac-cyrillic(!!!) according to the perl module Encode::Encoding::Detector, when substituting data from the second column, the encoding of the resulting string breaks, hence krakozyabry.
After connecting to the database in postgres, client_encoding win-1251 is set, if you comment out this line and work with UTF-8 and convert the already received lines to win-1251 on the spot, everything works correctly, but there are hundreds of such places in all project files, and what about correct record back to base I very much doubt.
It is not possible to check the encoding of the same string on the old server, since there are no rights to install the Encode::Encoding::Detector module. I
merged the backup from the old server both in UTF-8 and in win-1251 - the end result does not change
The final question: how to configure Postgres or how to merge a backup in such a way that everything works correctly on the resulting server without global code changes?

Answer the question

In order to leave comments, you need to log in

3 answer(s)
O
Olgeir, 2019-09-04
@Olgeir

Krakozyabry is a unicode output, you need to check what encoding the text is in

K
Konvergent, 2019-09-12
@Konvergent

And use utf8; you have?
Try to add this - use open qw(:std:utf8);

O
Oleg As, 2019-09-16
@eXcNightRider

From the latest: I took two main files from the project, removed all requests to Postgres so as not to raise it on a working computer (Mint 19.3), launched it, everything works, everything is perfect in encoding. The same files are on the future combat server with the same bugs. Apache configs are identical, locale settings are identical. Not sure what else to check

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question