rfc2388 doesn't care about the encoding of strings despite of returning them.
The result of a parsed body that doesn't contain binary data is then a vector of octets disguised as string, forcing the ultimate user to jump through this or a similar hoop:
(sb-ext:octets-to-string (map '(vector (unsigned-byte 8)) #'char-int s))
Hunchentoot for example will just return this broken string when rfc2388 is used for parsing a parameter's content.
IMO parse-mime should return a vector of octets and not a string. Its users (e.g. HT) should then apply appropriate character conversion functions to build a proper string.
Leslie
On Tue, Jan 27, 2009 at 13:20, Leslie P. Polzer sky@viridian-project.de wrote:
rfc2388 doesn't care about the encoding of strings despite of returning them.
Replacing the rfc2388 system by something that is better has been on the "should be done" list for a very long time. Are you volunteering to either repair it or come up with something that is better?
-Hans
Replacing the rfc2388 system by something that is better has been on the "should be done" list for a very long time. Are you volunteering to either repair it or come up with something that is better?
I also think that a replacement is needed (I have another patch lying around that is needed for missing final MIME boundaries).
Time is a problem, though. I'm going to put it up on LispNYC's list of SoC projects I'm willing to mentor. Should no one turn up then I'm likely going to work on it myself in a couple of months.
Leslie
Replacing the rfc2388 system by something that is better has been on the "should be done" list for a very long time. Are you volunteering to either repair it or come up with something that is better?
Maybe migrating to CL-MIME would make sense. I'm going to check this later.