В процессе разработки одного модуля для внутренней системы заказчика, столкнулся с HTML-Template, UTF-8 и MSSQL. Все шло хорошо, пока не потребовалось вставлять в БД значения типа nvarchar, естественно юникодные, естественно на русском языке. Долго экспериментировал с DBIC, CGI-Simple (все эти модули были задействованы в проекте), и даже с типами данных в БД и кодировками файлов шаблонов, но проблема оставалась - в базе была полная абракадабра или в выводе клиенту - была полная абракадабра... То есть либо там либо там было все хорошо, но не вместе... Это меня навело на мысль, что проблема в шаблонах, а точнее в модуле их обрабатывающих.
В итоге созрел хак для модуля HTML-Template, сперва такой:
open(TEMPLATE,"<:encoding(utf-8)", $filepath);
А затем, благодаря Mons Anderson с moscow.pm, он был оптимизирован:
open(TEMPLATE,'<:utf8', $filepath);
Хакнутый модуль доступен здесь
P.S.
Тема неожиданно получила продолжение в списке рассылки moscow.pm. А именно, высказали опасения насчет безопасности использования второго способа с utf8. В качестве аргумента приводится статья: http://www.perlmonks.org/?node_id=644786. Думаю каждый сам решит для себя как лучше здесь поступить. В коде самого модуля вызов open(TEMPLATE...) встречается всего два раза - и желающие всегда смогут изменить его на нужный вариант.
Благодарю за решение т.к. вскором времени столкнусь с связкой HTML-Template
& MSSQL. Возник вопрос чем вы работали для соединения с MSSQL и возможно дадите пару советов?!
Конектится собираюсь из под linxu Centos 5.4
Для соединения использовал DBD::ODBC (хотя применительно к centOS - немогу дать совет, мой проект пока работает из под Win2003).
В связке с DBIC соединение выглядит примерно так:
sub connect {
my $class = shift;
my %args = (
hostname => '',
database => '',
user => '',
password => '',
@_,
);
my $self = bless {}, $class;
my $dsn = "driver={SQL Server};Server=$args{hostname};database=$args{database};uid=$args{user};pwd=$args{password}";
$self->{connect} = Libs::Schema->connect("dbi:ODBC:$dsn");
return $self;
}
Основной совет, если собираетесь работать с юникодными строками, записывать их в БД, то всегда используйте тип nvarchar, nchar, и т.п. То есть при записи в БД для типа varchar юникодной строки - ничего хорошего не получится.
Еще один баг, который побороть не удалось, это запись ntext полей. Сейчас к сожалению не могу найти ссылку, но баг был то ли в ODBC, то ли еще где-то (в сишной бибилиотеке?)... В данном проекте удалось использовать типы nvarchar с чуть большим размером (позволяли данные), поэтому долго не ковырялся... Но если столкнетесь - пишите сюда - думаю проблема тоже решаема (тем более общими силами).