Re: xls & encoding [JT]
On 2005.05.19 at 12:17:30 +0400, Ed wrote:
> Victor Wagner wrote:
>
> >>>Не надо изобретать утилиток.
> >>Это неправильный метод. 99% проблем закроет определение
> >>ANSI-кодировки файла на основе локали - в коде OpenOffice.
> >>Кстати, наличие такой проблемы сильно мешает продвижению OOo.
> >>
> >>
>
> к слову - эта же проблема у gnumeric
Ну ды к естественно. Ведь фильтры импорта везде разрабатывались на
основе либо спцификаций от Microsoft, либо reverse engineering-а файлов,
созданных Excel, а не кривыми third-party движками.
> >Внимание, вопрос - какую ANSI-кодировку мы будем использовать при локали
> >ja_JP.UTF-8? Из N-возможны в японии?
> >65001?
> >
> >А при ru_RU.KOI8-R? Откуда-то возьмем информацию о том, что русские
> >файлы скорее всего в1251, или честно будем использовать 20866?
> >
> >
>
> это другой вопрос, решение с макросами малопригодно для реального
> использования.
Пока на этот вопрос не будет точного и вразумительного ответа, надеяться
на принятие соответствующего патча в OO.o или Gnumeric не приходится.
Хотя там патча-то на пару десятков строк.
> >На самом деле, чем дальше тем менее актуальной становится проблема
> >исходной кодировки файла Microsoft Office. Начиная с Office 97 все
> >пишется в UCS2 (1200) и всем хорошо. Кстати говоря распространение
> >OpenOffice началось примерно тогда, когда процент документов сделанных в
> >предыдущих версиях, упал до пренебрежимо малого.
> да вот доля 1с не пренебрежимо малая, а переделывать движок генераии xls
> они не собираются насколько я знаю.
Ну лично я сделал всё что мог. Сейчас текущее cvs-состояние xls2csv при
отсутствии в файле записи codepage использует charset, прописанный в
.catdocrc (или /etc/catdocrc). Не говоря уж о том, что возможность
указать в командной строке charset там была всегда.
Так что могу порекомендовать конвертирть файлы от 1c в csv с помощщью
xls2csv, и уже потом грузить в OO как csv.
Reply to: