Unibyte strings are meant for representing binary data. In practice, using unibyte versus multibyte strings affects *almost* nothing. It does happen to matter if we use the binary data in an image descriptor (which is, helpfully, not documented anywhere and getting it wrong results in opaque errors like "Not a PNG image: <giant binary spew that is, in fact, a PNG image>"). --- emacs/notmuch-lib.el | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el index ece29c3..fc67b14 100644 --- a/emacs/notmuch-lib.el +++ b/emacs/notmuch-lib.el @@ -504,7 +504,7 @@ (defun notmuch-parts-filter-by-type (parts type) parts)) (defun notmuch-get-bodypart-binary (msg part process-crypto) - "Return the unprocessed content of PART in MSG. + "Return the unprocessed content of PART in MSG as a unibyte string. This returns the \"raw\" content of the given part after content transfer decoding, but with no further processing (see the @@ -515,6 +515,16 @@ (defun notmuch-get-bodypart-binary (msg part process-crypto) ,@(when process-crypto '("--decrypt")) ,(notmuch-id-to-query (plist-get msg :id))))) (with-temp-buffer + ;; Emacs internally uses a UTF-8-like multibyte string + ;; representation by default (regardless of the coding system, + ;; which only affects how it goes from outside data to this + ;; internal representation). This *almost* never matters. + ;; Annoyingly, it does matter if we use this data in an image + ;; descriptor, since Emacs will use its internal data buffer + ;; directly and this multibyte representation corrupts binary + ;; image formats. Since the caller is asking for binary data, a + ;; unibyte string is a more appropriate representation anyway. + (set-buffer-multibyte nil) (let ((coding-system-for-read 'no-conversion)) (apply #'call-process notmuch-command nil '(t nil) nil args) (buffer-string))))) -- 1.9.1