Непечатаемые символы (как различить?)

[/dev/random]

Если я видел "кракозябры" - это меня вполне устраивало (я просто переключу кодировку в программе, запрошу данные вновь и прочитаю).

А вы правда видели кракозябры? При попытке воспринять cp1251 как utf8, обычно вылезают квадратики, а не кракозябры.

Shell

$ echo привет | iconv -t cp1251
������

[olecya]

запрошу данные вновь и прочитаю). Другое дело, что символ 0x00 или 0xFF отобразятся "квадратиками". А мне нужен либо текст, либо HEX.

Зачем переключать? Не пробовали читать лог с помощью команды less?

[devilr]

А вы правда видели кракозябры?

Видел. Допустим, есть 2 девайса, в одном из которых KOI8-R. в другом KOI8-U. Там "кракозябры" увидеть можно запросто.
И с ними я разберусь. Мне гораздо важнее различить текстовые и двоичные данные.

Добавлено (14:28):

Зачем переключать? Не пробовали читать лог с помощью команды less?

А зачем мне его читать? Оператору его глазами надо видеть. В приложении. И смочь прочитать по телефону. "Кракозябры" он точно не прочитает.

[olecya]

В приложении. И смочь прочитать по телефону. "Кракозябры" он точно не прочитает.

Ну если в приложении. А так less не выводит кракозябры хоть из бинаря хоть другая кодировка

[Bizdelnick]

Допустим, есть 2 девайса, в одном из которых KOI8-R. в другом KOI8-U.

Слушайте, не морочьте себе и остальным головы. Сделайте параллельный вывод в шестнадцатеричном и текстовом виде, как в hexdump -C. А там уж оператор разберётся, куда глядеть.
Если на входе неизвестная кодировка, задача в поставленном виде нерешаема. Можно заюзать enca, конечно, но я не знаю, как она себя будет вести, когда на входе полная белиберда (двоичные данные).

[devilr]

А там уж оператор разберётся, куда глядеть.

Он и сейчас разбирается - просто выбирая чекбоксом TEXT или HEX. Но, хотелось бы автоматики.

Если на входе неизвестная кодировка, задача в поставленном виде нерешаема.

Задача не в определении кодировки, а в отличии бинарных данных от текстовых.

Как по мне - задача интересная. И вполне прикладная. Думал, может кто что знает. Или сталкивался.

[math]

Что то тут не так, это числа до трёх байт.

Всё так. Да для записи достаточно трёх байт. Так что в кодировке UTF-32 каждый четвёртый байт — гарантированно нулевой. Поэтому она и не в ходу, что слишком уж нерациональная. Средняя длина символа в других кодировках тоже будет примерно равна трём, но это средняя, от неё есть отклонения в обе стороны, поэтому в UTF-16 длина равна 2 или 4, а в UTF-8 от 1 до 4 байт.

[Bizdelnick]

Задача не в определении кодировки, а в отличии бинарных данных от текстовых.

Не просто от текстовых, а от текстовых в неизвестной кодировке. Это две большие разницы.

[ormorph]

devilr
По вашему описанию задачи, можно прийти к выводу, что это не реальная задача. Так как у вас просто идёт поток байтов, и если эта информация не поделена на блоки, то определить это не реально, так как у вас по одному каналу может идти текст в разных кодировках и вы не знаете его длины. Тогда в отдельную выборку у вас может попасть текст в разных кодировках, как результат мы имеем фарш а не информацию.
Вы же понимаете, что текст на экране(терминале), это просто поток байтов идущий в stdout, а терминал просто обрабатывает его в соответствии с кодировкой, которая прописана в переменных среды и в соответствии с кодом(выборкой) выводится отдельный символ. Просто в зависимости от кодировки, даже текстовая информация в одной кодировке, может определяться как не текстовая в другой, так как по разному проходит выборка кодов.
Это я к чему, если я обычный бинарник отправлю в stdout с помощью cat, то тоже на экране будет целая куча символов, но это же не текстовый файл...

[devilr]

ormorph я всё понимаю. И сложность задачи понимаю. Мне, как говорила моя бабушка: "не шешнадцать лет"
Просто была надежда, что у кого то будет свежая идея. Решение этой проблемы. Но, нет - так нет. Значит, пока обойдусь чекбоксом.

[ormorph]

AT - команды не от хорошей жизни придумали. Просто была такая необходимость.

[devilr]

AT - команды не от хорошей жизни придумали. Просто была такая необходимость.

Раньше и машины слабее были.

[Bizdelnick]

Можете попробовать извратиться таким образом: https://github.com/Perl/perl5/blob/b864a746559843cd8bc1720eaf14c83faeb8fcc7/cpan/Compress-Raw-Zlib/zlib-src/trees.c#L1092-L1132
Но с UTF-16 и UTF-32 точно не прокатит. (Надеюсь, хотя бы EBCDIC детектить не надо?)

[ormorph]

Раньше и машины слабее были.

Можно сказать, что это что то меняет. Если канал один, то по нему нужно как то передавать пакеты, а следовательно что то должно быть началом пакета а что то концом, иначе весь смысл информации теряется.

[devilr]

Если канал один, то по нему нужно как то передавать пакеты, а следовательно что то должно быть началом пакета а что то концом, иначе весь смысл информации теряется.

В моём случае, я знаю что за пакет придёт. Потому как с другой стороны подсоединён вполне конкретный прибор. Просто, с одной стороны, довольно утомительно каждый раз расставлять чекбоксы. С другой стороны, если ошибся с переключателем - можно получить на экране мусор и не понять часть данных. Автоматизация решала бы эту проблему.

[Bizdelnick]

довольно утомительно каждый раз расставлять чекбоксы

Бодрейт, контроль чётности и прочее тоже утомительно. Переводите аппаратуру на USB или Bluetooth, и проблем не будет. ☺

[devilr]

Бодрейт, контроль чётности и прочее тоже утомительно. Переводите аппаратуру на USB или Bluetooth, и проблем не будет.

Принципиально ничего не изменится. Отечественная измерительная техника - это RS-232 на выходе. Даже, если это USB.
P.S. Если бы идентификаторы хотя бы были - было бы легче. Но, у нас такое делать - западло. Шоб враг не догадался, видимо.

[ormorph]

В моём случае, я знаю что за пакет придёт.

Ага ещё бы компьютер тоже знал, то было бы совсем хорошо.

[Bizdelnick]

Принципиально ничего не изменится.

Если бы идентификаторы хотя бы были

Ну как бы USB и Bluetooth подразумевают идентификаторы.
Но ладно. Код, на который я давал ссылку выше, смотрели? Устроит, нет?

[devilr]

Ну как бы USB и Bluetooth подразумевают идентификаторы.

Подразумевают. В тех приборах, о которых я говорил, наружу будет светиться RS-232. Даже, если это будет выглядеть, как USB.

Но ладно. Код, на который я давал ссылку выше, смотрели? Устроит, нет?

Я пока его логики не понял. А просто так, скопировать-вставить ведь не выйдет. Из-за всяких deflate_state и прочего.

[Bizdelnick]

Я пока его логики не понял.

Так в комментарии, вроде, подробно описано. Сам код, конечно, напрямую неприменим (там заранее подсчитано число вхождений разных символов).

TEXT if the two conditions below are satisfied:

1. There are no non-portable control characters belonging to the "block list" (0..6, 14..25, 28..31).
2. There is at least one printable character belonging to the "allow list" (9 {TAB}, 10 {LF}, 13 {CR}, 32..255).

BINARY otherwise.

[devilr]

Если это просто поиск в таблице "запрещённых" и "разрешенных" однобайтовых символов - то не пойдёт сразу.

[Bizdelnick]

Если это просто поиск в таблице "запрещённых" и "разрешенных" однобайтовых символов - то не пойдёт сразу.

Почему? И, собственно, какие тут ещё могут быть варианты?

[devilr]

Почему? И, собственно, какие тут ещё могут быть варианты?

Потому как, тот же QString("hello.") и QString("привет") отнесутся, скорее всего к TEXT для первой строки и BINARY ко второй. Во втором случае символов в 2 раза больше, если приводить к QByteArray. И нулевые символы всё испортят. Тут либо делать 100500 проверок для символа из 1 и 2 байт, либо плюнуть и остаться с чекбоксом.
Как сейчас и сделано, собственно.

[/dev/random]

если приводить к QByteArray

Эээ, что? Приводить к QByteArray? Разве вы не массив байтов получаете от устройства? Вот и оставляйте его массивом байтов. Не приводите к QString, пока не будете уверены, что это текст, а не двоичные данные. И проверяйте наличие байтов \x01-\x08, \x0B, \x0C, \x0E-\x1F, \x7F. Не зная заранее кодировки, больше ничего сделать нельзя.

[devilr]

Не приводите к QString, пока не будете уверены, что это текст, а не двоичные данные.

Если бы я был уверен - этой темы бы не было.
Мне нужно было различить. Я нашёл некий пример в интернете. Проверил его. Как раз приведя массив к строке. Не получилось. Спросил здесь. Похоже, здесь тоже никто ничего оригинального предложить не может. Остался пока на чекбоксе, но надежды найти решение не теряю.

[/dev/random]

Если бы я был уверен - этой темы бы не было.

Вы не поняли. Я имел в виду, что вам нужно _сначала_ проверить, есть ли там "плохие" байты, и только если их нет, создавать QString. А не как вы изначально сделали, сначала создаёте QString, а потом пытаетесь регуляркой посмотреть, что там Qt нагородил при конвертации.

[Bizdelnick]

Потому как, тот же QString("hello.") и QString("привет") отнесутся, скорее всего к TEXT для первой строки и BINARY ко второй. Во втором случае символов в 2 раза больше, если приводить к QByteArray.

То есть Вы боитесь за неверную интерпретацию UTF-8? Напрасно. Все байты многобайтовых последовательностей UTF-8 имеют старший бит 1 и, соответственно, попадают в список допустимых в тексте.

Я нашёл некий пример в интернете. Проверил его. Как раз приведя массив к строке.

Ну так он потому и не сработал, что Вы привели массив к строке, когда этого делать нельзя. QRegularExpression работает только с UTF-16, а у Вас входная кодировка априори неизвестна.

[devilr]

Ну так он потому и не сработал, что Вы привели массив к строке, когда этого делать нельзя. QRegularExpression работает только с UTF-16, а у Вас входная кодировка априори неизвестна.

Я в курсе, что он не сработал. Потому и создал тему.

[Bizdelnick]

Я в курсе, что он не сработал.

Пожалуйста, перечитайте сообщение, на которое ответили. Его смысл не в том, что регулярка не сработала, а в том, почему она не сработала.

Добавлено (16:56):

Offtopic

Потому как, тот же QString("hello.") и QString("привет") отнесутся, скорее всего к TEXT для первой строки и BINARY ко второй. Во втором случае символов в 2 раза больше, если приводить к QByteArray.

Вообще, насколько я разумею, байтов в обеих строках будет равное количество, потому что конструктор QString выполнит преобразование из UTF-8 в UTF-16, а при приведении к QByteArray размер строк никак не изменится. Можете проверить на досуге.