UTF-16-файлы в большинстве своём содержат нулевые байты. Возможно, это поле предназначено показать, можно ли трактовать файл как текстовый при побайтовой обработке. Служебные символы в подобных сценариях часто ломаются (например, нулевой байт заменяется пробелом), и от исходного юникодного текста останутся рожки да ножки."Binary" (binary files, containing special chars #00..#1F)
EncInfo (content-плагин)
Модераторы: Моторокер, Avada, CaptainFlint, Nik, d-view
- CaptainFlint
- Сообщения: 6243
- Зарегистрирован: Вт дек 14, 2004 22:34
- Контактная информация:
Согласно ридми:
Почему же, ё-моё, ты нигде не пишешь "ё"?
CaptainFlint
Даже если с технической точки зрения всё верно, на мой взгляд, в логику работы плагина это не вписывается.
Провел небольшие тесты. Баг, о котором говорил mig73, подтверждаю: без BOM плагин кодировки UTF-16 LE и UTF-16 BE не определяет. В CudaViewer всё нормально.
Alextp
Вы больше не планируете развивать и поддерживать плагин?
Даже если с технической точки зрения всё верно, на мой взгляд, в логику работы плагина это не вписывается.
Провел небольшие тесты. Баг, о котором говорил mig73, подтверждаю: без BOM плагин кодировки UTF-16 LE и UTF-16 BE не определяет. В CudaViewer всё нормально.
Alextp
Вы больше не планируете развивать и поддерживать плагин?
- CaptainFlint
- Сообщения: 6243
- Зарегистрирован: Вт дек 14, 2004 22:34
- Контактная информация:
А какой должна быть логика? Ведь тогда с точки зрения UTF-16 90% файлов можно считать текстовыми, ибо практически любая комбинация байтов окажется валидным символом (разве что нулевые байты числом больше одного подряд или непарные суррогатные последовательности попадутся случайно). Текст — это же не только русский-английский-немецкий, это и всякие иероглифы, которыми забита юникодная таблица.Orion9 писал(а):Даже если с технической точки зрения всё верно, на мой взгляд, в логику работы плагина это не вписывается.
Почему же, ё-моё, ты нигде не пишешь "ё"?
Простой и понятной пользователю. Если в readme написано:CaptainFlint писал(а):А какой должна быть логика?
То и при определении кодировки в поле "Type" должно быть "Text", раз уж автор сам избрал такую парадигму.This content plugin shows information about actual encoding of text files.
Нельзя, пока алгоритм не определит иначе (вы же прекрасно это понимаете). Но вот именно алгоритма в плагине, похоже, и нету, отсюда все проблемы. Как-то я сразу это упустил, но в readme же написано:CaptainFlint писал(а):Ведь тогда с точки зрения UTF-16 90% файлов можно считать текстовыми
Следует понимать, что, никаких определений кодировок, за исключением простого считывания маркера BOM, нет? Мне и в голову такое не могло прийти. Да, похоже, именно так. Добавил в начало mp3-файла FFFE - теперь он определяется как "UTF-16 LE" в поле плагина.- "UTF-16 LE" (detection by signature)
- "UTF-16 BE" (detection by signature)
Интересует продвинутый и полноценный детект кодировки, как это делает CudaView или AkelPad. Если автор не планирует больше заниматься плагином, то какие есть альтернативы, кто-нибудь в курсе?
Вот примерно о чём идет речь:
В общем, очень хотелось бы иметь плагин, основанный на этой (или подобной этой) библиотеке. Пока я нашел только скомпилированную версию консольной утилиты:
https://github.com/JetDemo/uchardet
Консольную утилиту можно использовать в плагине WinScriptAdv или Autorun для вывода данных в колонки ТС. Но это только версия 0.0.6 библиотеки, а сейчас уже есть версия 0.0.8, кто-нибуть может скомпилировать последнюю версию? Очень неплохо себя показывает на тестовых файлах по второй ссылке.
Если кому-то интересно, то:
Если верить этой странице, даже Notepad++ когда-то использовал эту библиотеку для определения кодировки текста.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/
В общем, очень хотелось бы иметь плагин, основанный на этой (или подобной этой) библиотеке. Пока я нашел только скомпилированную версию консольной утилиты:
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