Портится кодировка скачанных perl-скриптом данных при добавлении в базу?

Question

[Вячеслав Голованов]

Перешёл на новый хостинг, система та же осталась, freebsd, и один из скриптов перестал работать.



Он скачивает данные с другого https сайта и сохраняет их в базу.

Данные в кодировке cp1251, база, таблицы и соединение mysql в той же кодировке.



my.cnf:

character-set-server=cp1251
    collation-server=cp1251_general_ci
    init-connect="SET NAMES cp1251"

Когда соединяюсь с базой из скрипта, выполняю:



$dbh->do('SET CHARACTER SET cp1251');<br>



Данные выкачиваются так:

$ua = new LWP::UserAgent;<br>
    ....<br>
    $res = $ua->get(....)<br>
    $s = $res->decoded_content();<br>
<br>

Потом перменная $s парсится и результат вставляется в базу. И в базе кодировка испорченная:

Ñáåðáà íê ÐÔ (ÌÑÊ), ïîïîëíåíèå



Очень странную вещь обнаружил, ковыряясь со скриптом. Если просто сохранить полученные данные в текстовый файл, потом их из этого же файла прочесть и вставить в базу — кодировка не портится!



Если просмотреть этот текстовый файл, видно что кодировка там правильная, cp1251



Что изменилось с предыдущего хостинга:



perl: было 5.10.1, стало 5.14.4

libwww: было 5.835, стало 6.05

mysql server как был, так и остался 5.1



UPDATE: Только что обнаружил. Если вместо $res->decoded_content() написать $res->content(), то всё работает.

Возможно, из-за того, что у скачиваемой страницы нет в заголовках charset.

Но я всё равно не понимаю, что происходит со строкой, что если её в базу вставить, она в неправильной кодировке, а если в файл записать — то в правильной. То ли utf-флаг какой-то ставится? Не понимаю :(

Answer 1

[vsespb]

> Возможно, из-за того, что у скачиваемой страницы нет в заголовках charset.
или наоборот, есть.

> Если просто сохранить полученные данные в текстовый файл, потом их из этого же файла прочесть и вставить в базу — кодировка не портится!
хорошо бы увидеть код как читали, как писали.

> Если просмотреть этот текстовый файл, видно что кодировка там правильная, cp1251
это ещё ничего не доказывает )

По идее нужно знать как работает unicode

perldoc.perl.org/perlunitut.html
perldoc.perl.org/perluniintro.html
perldoc.perl.org/perlunifaq.html

habrahabr.ru/post/190584/

так же включить use strict, use warnings.

А так же в нужных местах делать Dump данных модулем Devel::Peek, а потом уже можно будет понять где баг. Ещё хорошо бы все используемые опции DBD::mysql видеть.

Пока что у меня впечатление что Ваш код не работает правильно с текстовыми строками perl, вместо этого использует везде legacy однобайтовую кодировку. Так тоже можно, тогда нужно использовать content а не decoded_content, раньше возможно работало, т.к. старая версия LWP не понимала кодировку именно этой страницы и вызов decoded_content был эквивалентен content. Непонятно правда, почему после чтения и записи из файла данные меняются. Впрочем на это могут повлиять опции, которые Вы используете при работе с файлами.

Comments

[Вячеслав Голованов]

Нет, у страницы в заголовках charset нет, я проверил.
А сам контент отдаётся в cp1251
И раньше decoded_content выдавался без проблем. А сейчас он выдаётся как-то не так.

В этом скрипте используется однобайтовая кодировка, да.
Файл просто открываю: open TST, '>', 'test';

[vsespb]

Нет, у страницы в заголовках charset нет, я проверил.

Значит в meta-тэгах есть? Как раз в LWP 6.x виднеется новый код по парсингу meta-тэгов при определении кодировки.

Файл просто открываю: open TST, '>', 'test';

Хм, да, если в этот файл записать unicode строку, в которой есть non-Latin1 символы, потом их прочитать так же, то это будет уже строка байтов. (при этом выдастся warning, если use warnings есть)

Соответственно, если теория верна (а пока всё совпадает), то Вам нужно использовать content а не decoded_content (а лучше decoded_content с параметром charset => 'none', тогда, если вдруг у страницы будет gzip, то он декодируется). Верна ли теория или нет, нельзя сказать наверняка, не увидев весь код.

[Вячеслав Голованов]

Нет, мета-тегов нет, это csv-файл отдаётся.
Код, за вычетом ненужного:

#!/usr/bin/perl

use POSIX qw(strftime);
use LWP::UserAgent;
use HTTP::Headers;
use HTTP::Cookies;
use Digest::MD5 qw(md5_hex);
use DBI;
use common::sense;
no utf8;
no strict;

$ua = new LWP::UserAgent;
$hh = HTTP::Headers->new(
  User-Agent => 'Mozilla/5.0 (Windows NT 5.1; rv:21.0) Gecko/20100101 Firefox/21.0',
  Accept => 'text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8',
  Accept-Language => 'en-us,en;q=0.7,ru;q=0.3',
  Accept-Encoding => 'gzip, deflate',
  Connection => 'keep-alive',
);
$ua->default_headers( $hh );
$ua->cookie_jar({});
$ua->timeout(20);

YMoney();

sub YMoney {
  # Заглавная страница, для куков
  $res = $ua->get('...');
  
  # Логин
  $res = $ua->post(... );
  
  # Список пополнений в csv

  .....
  
  $res = $ua->get("...");
  say $res->decoded_content();
  $s = $res->decoded_content();
  @list = reverse split("\n", $s);
  
  # Обработка списка и добавление данных в базу
  $dbh = DBI->connect("DBI:mysql:database=orders;host=localhost;port=3306", "...");
  $dbh->do('SET CHARACTER SET cp1251');
  
  for $line (@list) {
    next if ($line !~ /^\+;/);
  
    @pay{'data', 'amount', 'comment'} = map { s/"+//g; $_ } (split(';', $line))[1, 2, 5];
    $pay{hash} = md5_hex( join('', @pay{'data', 'amount', 'comment'}) );
  
    $id = $dbh->selectrow_array("SELECT id FROM ymoney WHERE hash = ?", {}, $pay{hash});
  
    # Новый платёж
    if (!$id) {
      $dbh->do(
        "INSERT INTO ymoney (operator, hash, data, amount, comment) VALUES ('yandex', ?, ?, ?, ?)", {},
        $pay{hash}, DB_Date($pay{data}), DB_Amount($pay{amount}), $pay{comment}
      );
    }
  }
}

sub DB_Date {
...
}

sub DB_Amount {
...
}

[vsespb]

Попробовал с URL, который возвращает text/csv в 1251, без charset header'ов.

use POSIX qw(strftime);
use LWP::UserAgent;
use HTTP::Headers;
use HTTP::Cookies;
use Digest::MD5 qw(md5_hex);
use common::sense;
no utf8;
no strict;

my $URL = '...'; # mime text/csv, no encoding

$ua = new LWP::UserAgent;
$hh = HTTP::Headers->new(
  User-Agent => 'Mozilla/5.0 (Windows NT 5.1; rv:21.0) Gecko/20100101 Firefox/21.0',
  Accept => 'text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8',
  Accept-Language => 'en-us,en;q=0.7,ru;q=0.3',
  Accept-Encoding => 'gzip, deflate',
  Connection => 'keep-alive',
);
$ua->default_headers( $hh );
$ua->cookie_jar({});
$ua->timeout(20);

$res = $ua->get($URL);
$s = $res->decoded_content();
use Devel::Peek;

print LWP->VERSION, "\n";
Dump $s;
print $s;

open my $f, ">", "test.tmp";
print $f $s;
close $f;

open $f, "<", "test.tmp";
my $s2 = join('', <$f>);
close $f;

Dump $s2;
print $s2;

С lwp 5.x это будут бинарные данные в кодировке 1251

SV = PV(0x14d0b50) at 0x127e580
  REFCNT = 1
  FLAGS = (POK,pPOK)
  PV = 0x15043b0 "\362\345\361\362, \363\360\340, 3\n\362\345\361\3622, \363\360\340, 4\n"\0
  CUR = 27
  LEN = 32
SV = PV(0x1728660) at 0x127e778
  REFCNT = 1
  FLAGS = (PADMY,POK,pPOK)
  PV = 0x178ff60 "\362\345\361\362, \363\360\340, 3\n\362\345\361\3622, \363\360\340, 4\n"\0
  CUR = 27
  LEN = 32
5.835
тест, ура, 3
тест2, ура, 4
тест, ура, 3
тест2, ура, 4

с LWP 6 это будут строковые данные,

SV = PV(0x1905370) at 0x1803ed0
  REFCNT = 1
  FLAGS = (POK,pPOK,UTF8)
  PV = 0x1cf4480 "\303\262\303\245\303\261\303\262, \303\263\303\260\303\240, 3\n\303\262\303\245\303\261\303\2622, \303\263\303\260\303\240, 4\n"\0 [UTF8 "\x{f2}\x{e5}\x{f1}\x{f2}, \x{f3}\x{f0}\x{e0}, 3\n\x{f2}\x{e5}\x{f1}\x{f2}2, \x{f3}\x{f0}\x{e0}, 4\n"]
  CUR = 41
  LEN = 48
SV = PV(0x1cd2520) at 0x1804110
  REFCNT = 1
  FLAGS = (PADMY,POK,pPOK)
  PV = 0x1cb4890 "\362\345\361\362, \363\360\340, 3\n\362\345\361\3622, \363\360\340, 4\n"\0
  CUR = 27
  LEN = 32
6.03
тест, ура, 3
тест2, ура, 4
тест, ура, 3
тест2, ура, 4

При этом LWP думает, что текст был в Latin1 (вот код, почему оно так думает metacpan.org/source/GAAS/HTTP-Message-6.06/lib/HTTP/Message.pm#L359 ). Так что строковые денные неправильные (а именно Cp1251, перекодированное из Latin1 в Utf-8). Тем не менее Latin1 имеет особый статус в perl. В бинарном контексте, (т.е. если, например, вывести в файл без указания кодировки), они ведут себя как оригинальные данные (из соображений совместимости). Подробнее я тут писал habrahabr.ru/post/190584/

Поэтому запись и чтение из файла (бинарного!) возвращает их в оригинальный вид.

По идее, они вообще должны вести себя как оригинальные данные всегда. Но, в некоторых местах это точно не происходит. Одно из таких мест — DBI (возможно это даже можно считать багом, ведь кодировку в DBI не указали, значит оно должно воспринимать их как бинарные, хотя наверняка из соображений совместимости это не считается багом).

Пофиксить всё можно, использовав content, вместо decoded_content, а лучше decoded_content(charset=>'none');.
Использовать decoded_content(charset=>'windows-1251'); не получится, для этого нужно будет исправлять весь скрипт.

Answer 2

[vsespb]

del

Answer 3

[kirichenko]

decoded_content() — во-первых разжимает gzip/deflate, во вторых, переводит из реальной кодировки (которую сумел определить) в utf-8 (во внутреннем представлении перла). Чтоб с кодировкой махинаций не было, можно вот так делать:

decoded_content(charset=>'none')

в общем, прежде, чем задавать такие вопросы, неплохо бы было почитать документацию…

Comments

[Вячеслав Голованов]

Да я читал много документации… Просто по lwp и всем сопутствующим модулям она не самая структурированная, можно мозг сломать :(