EncInfo (content-плагин)

Обсуждение только плагинов и утилит для Total Commander.

Модераторы: Моторокер, Avada, CaptainFlint, Nik, d-view

Аватара пользователя
CaptainFlint
Сообщения: 6243
Зарегистрирован: Вт дек 14, 2004 22:34
Контактная информация:

Сообщение CaptainFlint »

Согласно ридми:
"Binary" (binary files, containing special chars #00..#1F)
UTF-16-файлы в большинстве своём содержат нулевые байты. Возможно, это поле предназначено показать, можно ли трактовать файл как текстовый при побайтовой обработке. Служебные символы в подобных сценариях часто ломаются (например, нулевой байт заменяется пробелом), и от исходного юникодного текста останутся рожки да ножки.
Почему же, ё-моё, ты нигде не пишешь "ё"?
Аватара пользователя
Orion9
Сообщения: 1315
Зарегистрирован: Пн янв 01, 2024 17:18

Сообщение Orion9 »

CaptainFlint
Даже если с технической точки зрения всё верно, на мой взгляд, в логику работы плагина это не вписывается.

Провел небольшие тесты. Баг, о котором говорил mig73, подтверждаю: без BOM плагин кодировки UTF-16 LE и UTF-16 BE не определяет. В CudaViewer всё нормально.

Alextp
Вы больше не планируете развивать и поддерживать плагин?
Аватара пользователя
CaptainFlint
Сообщения: 6243
Зарегистрирован: Вт дек 14, 2004 22:34
Контактная информация:

Сообщение CaptainFlint »

Orion9 писал(а):Даже если с технической точки зрения всё верно, на мой взгляд, в логику работы плагина это не вписывается.
А какой должна быть логика? Ведь тогда с точки зрения UTF-16 90% файлов можно считать текстовыми, ибо практически любая комбинация байтов окажется валидным символом (разве что нулевые байты числом больше одного подряд или непарные суррогатные последовательности попадутся случайно). Текст — это же не только русский-английский-немецкий, это и всякие иероглифы, которыми забита юникодная таблица.
Почему же, ё-моё, ты нигде не пишешь "ё"?
Аватара пользователя
Orion9
Сообщения: 1315
Зарегистрирован: Пн янв 01, 2024 17:18

Сообщение Orion9 »

CaptainFlint писал(а):А какой должна быть логика?
Простой и понятной пользователю. Если в readme написано:
This content plugin shows information about actual encoding of text files.
То и при определении кодировки в поле "Type" должно быть "Text", раз уж автор сам избрал такую парадигму.
CaptainFlint писал(а):Ведь тогда с точки зрения UTF-16 90% файлов можно считать текстовыми
Нельзя, пока алгоритм не определит иначе (вы же прекрасно это понимаете). Но вот именно алгоритма в плагине, похоже, и нету, отсюда все проблемы. Как-то я сразу это упустил, но в readme же написано:
- "UTF-16 LE" (detection by signature)
- "UTF-16 BE" (detection by signature)
Следует понимать, что, никаких определений кодировок, за исключением простого считывания маркера BOM, нет? Мне и в голову такое не могло прийти. Да, похоже, именно так. Добавил в начало mp3-файла FFFE - теперь он определяется как "UTF-16 LE" в поле плагина.

Интересует продвинутый и полноценный детект кодировки, как это делает CudaView или AkelPad. Если автор не планирует больше заниматься плагином, то какие есть альтернативы, кто-нибудь в курсе?
Аватара пользователя
Orion9
Сообщения: 1315
Зарегистрирован: Пн янв 01, 2024 17:18

Сообщение Orion9 »

Вот примерно о чём идет речь:
uchardet

uchardet is an encoding detector library, which takes a sequence of bytes in an unknown character encoding without any additional information, and attempts to determine the encoding of the text. Returned encoding names are iconv-compatible.

uchardet started as a C language binding of the original C++ implementation of the universal charset detection library by Mozilla. It can now detect more charsets, and more reliably than the original implementation.

History

As said in introduction, this was initially a project of Mozilla to allow better detection of page encodings, and it used to be part of Firefox. If not mistaken, this is not the case anymore (probably because nowadays most websites better announce their encoding, and also UTF-8 is much more widely spread).

Techniques used by universalchardet are described at https://www-archive.mozilla.org/project ... tdetection

It is to be noted that a lot has changed since the original code, yet the base concept is still around, basing detection not just on encoding rules, but importantly on analysis of character statistics in languages.

https://www.freedesktop.org/wiki/Software/uchardet/
Если верить этой странице, даже Notepad++ когда-то использовал эту библиотеку для определения кодировки текста.

В общем, очень хотелось бы иметь плагин, основанный на этой (или подобной этой) библиотеке. Пока я нашел только скомпилированную версию консольной утилиты:
https://github.com/JetDemo/uchardet
Консольную утилиту можно использовать в плагине WinScriptAdv или Autorun для вывода данных в колонки ТС. Но это только версия 0.0.6 библиотеки, а сейчас уже есть версия 0.0.8, кто-нибуть может скомпилировать последнюю версию? Очень неплохо себя показывает на тестовых файлах по второй ссылке.

Если кому-то интересно, то:
Подключение через Autorun

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

Pragma AutorunPluginFields "Encoding:::CharDetect"

Func CharDetect(FileName, FieldIndex, UnitIndex)
    Local pipe, exe_tool = %COMMANDER_PATH% & "\Ini\Tools\uchardet.exe"
    ProcessExecGetOutput pipe %exe_tool% '"%FileName%"'   
    Return pipe
EndFunc
Ответить