Знаки Èíà вместо кириллицы на сайте написанном на Perl. Как исправить кодировку?

Question

[Олег Ас]

Переношу учебный портал одного института со старого сервера на новый.
На старом сервере: CentOS 5.11, Perl 5.8.6, Postgres, очень ограниченные права и много совершенно сторонних файлов.
Новый сервер: Debian 9.9, Perl 5.24.1 из коробки, и отдельно собранный 5.8.9, Postgres.
На новой версии Perl по понятной причине начались разные мелкие проблемы, решились все кроме одной.
Сайт работает в Win1251, вывод русского текста через print работает нормально, а вот через qq кракозябры вида ÈíГ.
Вот скриншот:

Перерыл массу мануалов, проверял локали, сверял настройки на двух серверах, но что то точно упускаю.
Поменять qq на print не решение.
От безысходности собрал древний Perl 5.8.9. Запустил на нём - всё тоже самое, только в лог ошибок пишется AH01215: Wide character in print at с указанием на строку, где как раз и печатаются кракозябры.
Подскажите пожалуйста, в какую сторону смотреть.
Последняя из идей: проверить и поставить модуль Locale::RecodeData::CP1251

UPD 24.09.19 Определил кодировки строк. В чистом Perl без Postgres всё работает правильно. Как только интерполируется строка из Postgres, всё ломается. Пример: запрашивается одна строка из Postgres, кодировка данных первого столбца win1251, второго x-mac-cyrillic(!!!) если верить модулю perl Encode::Encoding::Detector, при подстановке данных из второго столбца кодировка результирующей строки ломается, отсюда и кракозябры.
После подключения к базе в postgres устанавливается client_encoding win-1251, если закомментировать эту строку и работать UTF-8 и конвертировать уже полученные строки в win-1251 на месте, всё работает правильно, но таких мест во всех файлах проекта - сотни, да и насчёт правильной записи обратно в базу я очень сомневаюсь.
Проверить кодировку той же строки на старом сервере нет возможности так как нет прав на установку модуля Encode::Encoding::Detector
Из старого сервера сливал бэкап и в UTF-8 и в win-1251 - конечный результат не меняется

Конечный вопрос: каким образом настроить Postgres или как слить бэкап таким образом, чтобы на результирующем сервере всё отработало правильно без глобальных изменений кода?

Comments

[сергей кузьмин]

https://habr.com/ru/post/147843/

Answer 1

[Olgeir]

Кракозябры это вывод юникода, нужно проверить в какой кодировке текст

Answer 2

[Konvergent]

А use utf8; у вас есть?

Попробуйте еще такое добавить - use open qw(:std :utf8);

Comments

[Олег Ас]

use utf8; ставил- кодировка ломается по всей странице, в логах Wide Character in Print и указывает на проблемное место.
тоже самое с вариантом use open qw(:std :utf8); сыпятся ошибки вида: AH01215: Malformed UTF-8 Character со ссылкой на блок вывода qq

[Konvergent]

Олег Ас, попробуй подключить use Encode::Detect::Detector;
и получить имя кодировки my $charset = Encode::Detect::Detector::detect( $text );
а дальше можно энкодить например или по ситуации. Возможно у тебя в дургом модуле/классе уже есть энкодинг и получается, что два раза в utf8 перегоняется. Я сам долго с этим мучался(

Answer 3

[Олег Ас]

Из свежего: взял два основных файла из проекта, удалил все запросы в Postgres, чтобы не поднимать его на рабочем компьютере (Mint 19.3), запустил, всё работает, по кодировке всё идеально. Эти же файлы на будущем боевом сервере с теми же кракозябрами. Конфиги апача - идентичны, настройки локали - идентичны. Пока не знаю, что ещё можно проверить

Comments

[Олег Ас]

UPD 24.09.19 Определил кодировки строк. В чистом Perl без Postgres всё работает правильно. Как только интерполируется строка из Postgres, всё ломается. Пример: запрашивается одна строка из Postgres, кодировка данных первого столбца win1251, второго x-mac-cyrillic(!!!) если верить модулю perl Encode::Encoding::Detector, при подстановке данных из второго столбца кодировка результирующей строки ломается, отсюда и кракозябры.
После подключения к базе в postgres устанавливается client_encoding win-1251, если закомментировать эту строку и работать UTF-8 и конвертировать уже полученные строки в win-1251 на месте, всё работает правильно, но таких мест во всех файлах проекта - сотни, да и насчёт правильной записи обратно в базу я очень сомневаюсь.