Приветствую, если шанс перекодировать данные в таблице ? Я так полагаю

данные каким-то образом испорчены
(1558, 'mem', 'domod', 1, 1367215466, 'Óäàëåííûå ðåãèñòðàöèè', '46.2.179.220'),
(1557, 'group', 'doedit', 1, 1367118019, 'Îòðåäàêòèðîâàíà ãðóïïà \'×èòàëüíûé çàë\'', '46.2.179.220'),
(1556, 'group', 'doedit', 1, 1367117927, 'Îòðåäàêòèðîâàíà ãðóïïà \'Çàáëîêèðîâàííûå\'', '46.2.179.220'),
(1555, 'group', 'doedit', 1, 1367117868, 'Îòðåäàêòèðîâàíà ãðóïïà \'Ïîëüçîâàòåëè\'', '46.2.179.220'),
(1554, 'group', 'doedit', 1, 1367117787, 'Îòðåäàêòèðîâàíà ãðóïïà \'Ìîäåðàòîðû\'', '46.2.179.220'),
(1553, 'group', 'doedit', 1, 1367117601, 'Îòðåäàêòèðîâàíà ãðóïïà \'Àäìèíèñòðàòîðû\'', '46.2.179.220'),

А если перекодировать как-то через спец программу возможно?

способ довольно понятный - данные просто сохранили в однобайтовой кодировке (судя по всему в windows-1251), там вот их надо считать чем-нибудь, что понимает 1251 и потом умеет сохранять в вашей кодировке

А почему вы думаете, что это данные в таблицэ испорчены, а не что-нибудь ещё?

И да, перекодировать их, судя по всему, можно... Но, как минимум, надо выяснить -- в каком виде они должны быть. А то так можно очень долго как минимум перекодировать, если способа получить нужное вам, например, не имеется. Опять жэ, когда архитектура будет разъяснена -- вполне вероятно и перекодировать ничего не потребуется.

Ну записи имеют такой вид Îòðåäàêòèðîâàíà, или вы предполагаете что клиент записал так?

Откуда Вы это знаете? Может, это вообще результат перекодировки сервер-клиент, и записи вовсе не имеют такого вида? Т.е. где Вы это видите (какой клиент и настройки)? Что показывает \l про эту базу? Ну и т.д.

Я предполагаю, что, возможно, клиент так их вам отобразил. Почему-либо. И да, кстати, если что это выглядит как честный windows-1251, который воспринят почему-то как iso8859-1. И потом, очевидно, перекодированный в telegram в utf8. А проверять там много чего -- encoding сервера ( https://www.postgresql.org/docs/current/multibyte.html ), encoding соединения, а потом весь ваш клиентский стэк. Ещё можэт быть у типа столбца свой encoding, но это редкость.

> Ещё можэт быть у типа столбца свой encoding, но это редкость. Вот этого, к счастью, не может быть. Т.е. @GoDevelopment не придётся это проверять, по крайней мере.

Я как-то, ещё для 8 делал хранение rfc2047, с выдачей по умолчанию в клиентской кодировке (и функцыями для получения/записи оригинала). То есть по сути дажэ с отдельной кодировкой для каждой записи, не то что для столбца.

Так можно устроить всё, что угодно (хоть разные кодировки для частей каждой записи ;) ), используя bytea и собственные функции. Но возможности задавать encoding отдельно для каждого текстового поля в PostgreSQL просто нет.

Ну, учитывая, что автор не показал нам определение таблицы -- там именно всё, что угодно можэт быть. Я жэ предполагаю, что можэт быть всё, что угодно в его неназванном клиентском стэке? Почему бы не предположыть тожэ самое и про хранение, про которое он спрашывал. Хотя это, конечно, редкость, и я тожэ предлагаю этим не заморчаиваться.

Кроме того, банальность в том, что там, например, можэт быть bytea, в котором по архитектуре будет лежать строка в cp1251, наплевав на кодировки сервера и клиента. Хотя это тожэ не слишком вероятно.