Страница 5 из 6

Добавлено: Чт окт 17, 2013 02:20
Skif_off
Alextp
Почему эти два файла определяются как ANSI, хотя .txt по идее ANSI Ru, а .cmd - определенно OEM 866? Настройки по умолчанию, rus_percent= выставить побольше? Но разве не достаточно хотя бы одной буквы из кириллицы?

Добавлено: Чт окт 17, 2013 02:29
Alextp
Skif_off
для Txt выстави поменьше rus_percent, скажем 10. А для Cmd выставить rus_word_len=6, хотя это уже на другие файлы повлияет. лучше тогда совсем низкий rus_percent

Добавлено: Чт окт 17, 2013 04:14
Skif_off
При rus_percent <= 8 файл описания xdoc2txt из DOS Ru (на самом деле 932 ANSI/OEM - японская Shift-JIS) превращается в ANSI Ru.
Выставил rus_word_len=3 (ниже никак) и rus_percent=10: с .cmd норма, файл описания xdoc2txt остается DOS Ru.

autoupdate_response.xml/tasks.xml/typed_history.xml из профиля Opera 12.16 определяются как ANSI, хотя первой строкой идет <?xml version="1.0" encoding="utf-8"?>, но это, так понимаю, из-за этого:
UTF-8 без BOM и ANSI, при отсутствии кириллицы (символов из расширенного набора) - одно и то же.

В общем, как-то до боли напоминает эксперименты с буфером автоопределения кодировки в AkelPad: с одним файлом прогон, подбираешь размер - внезапно гон с другим. Тогда просто забил в итоге :(
Ппц, как меня бесят все эти кодировки, так понимаю - UTF-8/UTF-16LE с головой хватило бы на все...

Добавлено: Чт окт 17, 2013 14:15
Alextp
Да, из-за этого. детекта xml utf8 нет

Добавлено: Чт окт 17, 2013 14:32
Serge Yolkin
Alextp писал(а):детекта xml utf8 нет
И очень хорошо! Файлы с кодировкой, отличной от декларируемой, попадаются с завидной регулярностью.

Добавлено: Чт окт 17, 2013 15:22
Alextp
SY, Ok, буду знать..

Добавлено: Чт окт 17, 2013 17:00
Serge Yolkin
Alextp
Можно учитывать, но после детекта: если уверенно не распознали, берём из декларации (например, та же ситуация при отсутствии нелатинских символов), или сразу брать декларацию за умолчание (вместо ANSI), а потом детектить.

Добавлено: Чт май 16, 2024 12:36
Orion9
Заметил, что плагин иногда определяет текстовые файлы UTF-16 LE как Binary, это так задумано или это ошибка?

Добавлено: Чт май 16, 2024 14:19
imig73
Orion9
Так и есть. Если текстовый файл UTF-16 LE без BOM, то определится как binary и это явная ошибка, которая меня здорово заставила блудить, пока я не разобрался в чём дело. С BOM определяет верно.

Добавлено: Чт май 16, 2024 23:46
Orion9
imig73
Спасибо за пояснение, а то я уже начал сомневаться.)

А что, нет шансов на багофикс? Очень бы хотелось исправный плуг :)

Добавлено: Пт май 17, 2024 00:33
imig73
Orion9
/К сожалению бох не научил меня писать плагины и как халявщик Лёня я не знаю как попросить автора пояснить ситуацию. Над как-то попробовать через оффорум обратиться. Этот плагин очень важен для меня.

Добавлено: Пт май 17, 2024 11:31
Orion9
imig73 писал(а):Orion9
/К сожалению бох не научил меня писать плагины и как халявщик Лёня я не знаю как попросить автора пояснить ситуацию. Над как-то попробовать через оффорум обратиться. Этот плагин очень важен для меня.
Он не халявщик, он - партнёр :mrgreen:

Надежда тут только на Progman13. Сколько он уже помог в таких случаях с заброшенными проектами на дельфях.
Показать
Спасибо тебе, человек! ))

Добавлено: Пт май 17, 2024 12:19
yozhik
Если что, исходники здесь.

Добавлено: Пт янв 24, 2025 23:12
Orion9
Alextp
Меня всё ещё мучает вопрос :D
Заметил, что плагин иногда определяет текстовые файлы UTF-16 LE как Binary, это так задумано или это ошибка?

Добавлено: Сб янв 25, 2025 23:04
Orion9
Думаю, всё-таки стоит сделать одно уточнение, а то как-то неоднозначно получилось.

В общем, плагин вроде бы корректно определяет кодировку файла, но почему-то показывает вот так:

Код: Выделить всё

Type                            : Binary
Encoding                        : UTF-16 LE
Отсюда вопрос: тип Binary здесь указан правильно, или у таких файлов он должен быть Text?