В C ++ (Visual C ++ MFC) у меня есть char *
который пришел из базы данных. Это на самом деле картина. PostgreSQL возвращает его как char *, потому что нет байта [] в C ++ (насколько я знаю -yet- :))
Дело в том, что я пытаюсь написать это изображение так:
ofstream myFile ("C:\\picture.jpg", ios::out | ios::binary);
myFile.write(contents, size);
myFile.close();
Это выводится как:
\xffd8ffe000104a46494600010101006000600000ffe1005a4578696600.......
Я пытался изменить содержимое на reinterpret_cast<char *>(&contents)
тогда я получил несколько двоичных данных, как, но только несколько. Остальных их нет в файле.
Я также попробовал это:
fstream binary_file("C:\\picture.jpg", ios::out | ios::binary | ios::app);
binary_file.write(reinterpret_cast<char *>(&contents),size);
binary_file.close();
Для обоих с reinterpret_cast<char *>(&contents)
или без него. Все еще есть немного байтовых данных в файле. Больше не надо.
Я тоже пытался изменить size
, Размер пришел из Postgresql’s PQgetlength
метод, так что это точно. (Не может быть не так, не так ли?)
Я наконец-то даю size
сам и сказал C ++, что это 5000
, Он выводит двоичные данные с 5.000, но на самом деле он не соответствует исходному файлу. Начинается с «ч», а затем что-то другое …
Я также попытался загрузить эти данные в ByteArray от Chilkat, а затем записать его методом доступа к файлу oen. Все еще получил тот же результат с \xfdd...
,
Итак, какова главная цель? Что мне здесь не хватает? Любая помощь будет оценена.
редактировать: Это символ *. Извините за недопонимание.
Заключение: Я выбираю Крейг Рингер* решение из-за моих потребностей. Но из-за характера этого вопроса я выбираю Н2СО3ответ как принятый ответ.
Если contents
действительно char *
, а не массив, то проблема в том, что вы передаете адрес указатель сам. И затем вы пытаетесь записать значение указателя в файл. Проходить contents
(вместо &contents
) чтобы fstream::write()
,
Насколько я вижу, ваш вывод испорчен
\xffd8ffe000104a46494600010101006000600000ffe1005a4578696600...
это не допустимая шестнадцатеричная запись. Вам нужно что-то вроде этого
\xff\xd8\xff\xe0\x00...
использование libpqtypes
. Это заботится о bytea
преобразование и все виды другой обработки данных более высокого уровня, которая не встроена в libpq
собственно.
В двоичном режиме передачи можно использовать libpq
, но, честно говоря, это будет намного проще в использовании libpqtypes
и пусть он справится со всем этим. Вы действительно не нужно иметь дело с двоичной передачей дат и другими значениями нестандартного формата, поэтому, если вы все же используете двоичную передачу, обычно следует указывать двоичный режим только для столбцов байтов.
Во-первых, ваш вывод выглядит как начало хорошего, действительного файла JPG, преобразованного в текст с помощью некоторой самодельной процедуры. Некоторым разработчикам баз данных не нравится хранить двоичные данные в BLOB-файлах, а родной формат PostreSQL для хранения двоичных файлов в текстовых полях, bytea, довольно неудобен. Поэтому многие разработчики используют Base64, UUENCODE или решения собственного производства.
И ваш первый фрагмент выглядит хорошо. Вы не дали нам определения содержания и размера, но если они такие, какими кажутся, это должно сработать. Он должен выводить содержимое без каких-либо изменений. Итак, чтобы убедиться, что проблема в содержимом, запустите отладчик, установите точку останова на myFile.Write и посмотрите на переменную содержимого. Скорее всего, он будет содержать тот же «\ xffd8ffe000» вместо двоичных данных.
Если это так, вам нужно вручную преобразовать эти текстовые данные.