python string -> binary

если я прально тебя понял, то тебе нужно заюзать модуль struct... в частности функции pack unpack...

Но в какой тип мне паковать? Если все данные паковать struct.pack ('c', data) - на выходе получается то же самое, т.е. не то; возможно, надо паковать разные части по-разному, но как узнать, какие и в какой тип? Эх, неужто всё так сложно?

Скорее всего, проблема не при записи, а при чтении. Читать тоже надо "rb".

>Читать тоже надо "rb"
А тут вариант только один: в python-serial возможен единственный способ чтения из порта - port.read (), возвращающий строку.

А разве здесь нельзя провести аналогию с email - там ведь тоже сообщения пересылаются в текстовом формате, а вложения могут и двоичные файлы содержать. Может кто знает как в письме сохранить octet-stream? Что-то мне кажется, что тут похоже будет.

Самое обидное, что сохранённый файл от оригинала лишь несколькими битами отличается...

атачи в письмах кодируются, обычно base64

ты посмотри сперва что за сообщение приходит с телефона.
что значит "текстовое" -- ASCII или UTF-8 или что-то еще?
какие такие метки? почему "метка" не может случиться в середине jpeg?

строка в питоне это последовательность 8-битных беззнаковых целых.
поэтому "конвертировать строку в бинарный формат" -- бессмыслица.
это совсем не то же самое что строки в java, где строка состоит из
unicode-символов; для этого есть тип unicode.

>ты посмотри сперва что за сообщение приходит с телефона. что значит "текстовое" -- ASCII или UTF-8 или что-то еще?

скорее всего, это "quoted_printable" (т.е. пропустив через этот фильтр на выходе получается то же самое, что и на входе; а есть какой-нибудь другой способ определить исходную кодировку?)

>какие такие метки? почему "метка" не может случиться в середине jpeg?

когда телефону даётся запрос на получение файла, я получаю ряд ответов формы: "+FSFR: 512, 1,кусок файла (длина должна быть равна 512 kb)#OK#" "+FSFR: size,part," и "#OK#" и есть метки; ну и навряд ли #OK# встретится в середине jpeg.

Хмм, самое интересное: побитовое сравнение оригинального файла и закаченноо с телефона показало, что при чтении с порта просто "проглатываются" определённые символы (\x11 и \x13). Причём после отключения xon/xoff control порта эти символы уже "проходят", но "съедаются" другие... Так что, скорее всего, проблема либо с модулем USB->Serial конвертера, либо с python-serial, либо с настройками порта (но с любыми настройками всё равно иногда теряются _определённые_ символы).

stty raw пробовал?

>stty raw пробовал?

В смысле stty 115200 raw </dev/ttyUSB0? Результат такой же, но за идею с stty спасибо