Скрыть опции темы

случайно не попадалась ли кому программка (под венду) для пакетного перевода файлов в UTF-8 из других кодировок?

я такую программу нашел в конце прошлого года (точно помню), а потом протерял куда-то и найти не могу, и название вспомнить не могу.

плиз, очень надо!

P.S. iconv не предлагать.

даже под cygwin?

Вот маленькая программка на питоне. Тестировал под виндой - проблем не замечено.
Комеентарии, думаю излишни.

З.Ы.
Думаю, можно сделать аналогичную и на пых-пыхе, но не мастак.

Однако, такие задачи следует решать инструментальным способом.
Вот пример кода на языке bash.

Один инструмент - ls - перечисляет объекты, а другой - iconv - только конвертирует.
Таким образом, соблюдается правило прозрачности и система остается разложимой
на элементарные компоненты, что упрощает ее анализ и аудит.

Заметим, что все эти инструменты: ls, iconv, mv, bash - стандартизированы,
следовательно дополнительных программ устанавливать не надо.

И что только люди не придумают чтобы не использовать Unix

З.Ы.
установщик питона под винду можно найти на www.python.org

Параметризованная версия утилиты

Пример использования:

Сгенерировал exe-ник под винду.

Однако выгрузить не получается. Выдается сообщение:
"""
ОБНАРУЖЕНЫ СЛЕДУЮЩИЕ ОШИБКИ
Вы не можете загружать такой тип файлов
"""

положи на ifolder.ru

текст_программы
дистрибутив( требует python )


Интерпретатор python можно скачать здесь: python-2.5.2_win32_installer

Оказывается существуют сборки iconv под win32, например, в графическом редакторе GIMP.

Таким образом, пользователи win32 могут тоже воспользоваться этой замечательной утилитой и конвертировать тексты из одной произвольной кодировки в другую.

Вот код, адаптированный для windows:

Коммент:
Ключ -f задает исходную кодировку, ключ -t - конечную.

Комплект состоящий из интерпретатора bash, конвертора iconv а так же самого сценария и пуcкового батника можно скачать здесь:

bash+iconv (win32)

Результат получился даже несколько компактнее чем в предыдущем случае.

ЗЫ
Только будьте осторожны, делайте резервные копии конвертируемых текстов.
ЗЫЗЫ
Приведенные выше примеры программного кода наглядно демонстрируют
неоспоримые преимущества применения специализа

sensey
спасибо за ответы!
я с iconv не работал пока, по сображениям лени и религиозным тоже.
ты скажи, он без BOM может перекодировать?


собственно, из того что я нашел под венду:
Tea(Win32). чудный текстовый редактор, который при весе в 1 мегабайт умеет даже открывать формат OpenOffice (ридонли), ну и кучу всего-всего умеет.
имеет сотни функций по обработке текста - сортировка, создание словарей, анализ текста, фильтрация, массовое изменение кодировок, запуск внешних программ и многое другое. недостаток - нельзя оперировать BOM-заголовками.

Kaboom - отличный перекодировщик, поддерживает массовое перекодирование файлов, которые перетащили в его окно. На паре текстовых файлов у меня почему-то сглючил, зараза - не перевел в юникод...

Textpipe - программа имеет больше сотни гибко настраиваемых фильтров замены и перекодировки. Платная. Про BOM я не нашел, подозреваю что не умеет.

PS вот как вы относитесь у UTF-8?
я лично видел два противоположных мнения:
1) плохо. php с ним не работает без геморроя, весит в два раза больше, глючит часто из-за BOM
2) хорошо! мультиязычность же!

Да, может - для этого надо указать порядок следования байтов.

Примеры конвертирования:

1. Исходный порядок от младшего к старшему:

2. Исходный порядок от старшего к младшему:

Туда и обратно конвертирует, и без вcяких BOM-ов.
Iconv старейшая утилита и какие можно глюки в ней выловили.
Лучший выбор для пакетной конвертации.

Что касается прикладных аспектов utf-8, то я не стану отрицать неготовность некоторого ПО (читай php) к использованию данного стандарта. Плюс до недавнего момента существовала проблема медленной сортировки UTF-строк в системе FreeBSD.


Но, на мой взгляд, у utf-8 есть неоспоримое приемущество - не надо думать о кодировках.

А что касается размера, то при применении компрессии файл в utf-кодировке и файл в традиционной кодировке не сильно будет отличаться по размеру, ведь количество информации останется неизменным.

Да и к тому же на на современных http-серверах есть модуль аля mod_gzip, делающий процесс компрессии текстовых потоков прозрачным и сводящий к минимуму сетевые задержки.


В стане пропонентов юникодизации есть такие гиганты как Google, IBM, Sun, MS, Adobe.
Любой их продукт полагается на юникод.

Возьмите любой стандарт документооборота, будь то ISO 32000 - PDF или ISO 26300
- ODF и вы увидите там юникод.



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

А ты попробуй назло собственной лени.

А так, да, лень штука полезная, если она конструктивна.
Один китайский философ сказал, что когда умный человек воздерживается от действия, то могущество его чувствуется за сотни миль.
Нежелание выполнять ненужную работу считается великой добородетелью у программистов.
В этом ключ автоматизации.

Но лень может быть и деструктивной. Это проявляется не сразу, и только по прошествии времени осознаешь свою неправоту. Например, некоторые программисты пребывают в ловушке ручного труда.
Парадокс - им лень автоматизировать рутину, но не лень идти у нее на поводу.

Вчера на сайте IBM была опубликована статья, посвященная использованию юникода в языке программирования `php`:
http://www.ibm.com/developerworks/ru/libra...code/index.html

Надо отметить, что php{4,5} работает только с ascii-символами.
Полноценная поддержка будет только в версии 6.

с осени прошлого года еще висит.

статья полубредовая, ибо у автор явно не в теме.

он не знаком с таким понятием, как локаль.
а судя по примерам кода, он не знает, что такое юникодный редактор.
кроме того, он не знает, как с обычной клавиатуры вводить юникодные символы («…» например он задает как "…").
символ — он и есть символ, и при чем тут html-entities — ни разу не понятно.

в общем, сгодится для тех, кто первый раз слышит слово unicode.

Некоторые строковые/библиотечные функции php{4,5} неверно работают с многобайтными кодировками.
Вот обзор некоторых проблем

Как видно из перечисления, большинство функционала так или иначе связанного с обработкой строк ведут себя некорректно по отношению к UTF и их применение небезопасно.

sensey
ахуенная новость!

Last modified: 2006/12/09

где ты ее столько времени прятал??

Хотелось бы увидеть чейнджлоги того что изменилось с тех пор в плане UTF.
Разумеется, пруфлинки в студию!

sensey
воспользуйтесь официальной документацией на php.net и списком рассылки php.internals.