Re: replacement for iconv(1) that handles unconvertable chars correctly
On 2004.02.28 at 12:17:50 +0400, Vlad Harchev wrote:
> Hi,
>
> В общем задача - есть текст в cp1251, надо его перегонять скриптами в koi8r.
> iconv(1) даже с ключем -c вываливается в середине со словами
> iconv: illegal input sequence at position 1385
Первое о чём бы я подумал - поменять технологию, и не использовать
koi8-r. Ведь iconv не просто так ругается. Он предупреждает что
информация будет теряться.
В koi8-r есть далеко не все символы, которые пользователи кодировки 1251
используют в обычных текстовых файлах. Кавычек нет, длинного тире нет и
так далее.
Если заменить koi8-r на 1251 или utf-8 не удаётся - подумать о том,
на что заменять эти символы. И уже в соответствии с этим искать решение.
В принципе, утилита которая используя iconv(3) перекодирует всё, что
перекодируется, а остальное заменяет по таблице, пишется на коленке за
два часа.
Аналогичная фунциональность у меня предусмотрена в catdoc, который,
правда, не пользуется iconv даже на тех платформах, где iconv
работоспособен. (сatdoc умеет перекодировать и текстовые файлы, не
только вордовые)
Кроме того, можно использовать в качетсве перекодировочной engine
любой продвинутый скриптовый язык - Tcl (>=8.1), Perl (>=5.8) или Python
(>=2.0).
Tcl по умолчанию заменяет неизвестные символы на вопросительный знак,
что не всегда удобно. Точно так же, кстати, поступает Oracle, если
кодировка клиента не совпадает с кодировкой сервера.
Кстати, да, если тексты потом предполагается складывать в БД, то лучше
всего поручить перекодировку самой БД. Они это умеют.
> Есть ли какие-либо утилиты которые могут такие ситуации обрабатывать - в смысле
> не отваливаться?
> Помню в altlinux iconv(1) (то есть часть glibc) специально патчится чтобы
> это можно было обрабатывать, но их патч почему-то в официальном glibc (2.2.5)
> отсутствует..
В 2.3 есть.
Reply to: