Stephan Bergmann
fb896ebc7e
INetMIMEEncodedWordOutputSink had been intended to encode (non-ASCII) content of a "free-form text" header field as per RFC 2047. It used a heuristic trying to detect already encoded words (=?...?...?...?=) in the input, to pass them through unmodified. (Arguably, it could just as well have encoded them, assuming they were meant to be genuine input.) However, that heuristic had a bug ever since8ab086b6cc"initial import", going from STATE_FIRST_EQUALS to STATE_FIRST_EQUALS instead of STATE_FIRST_QUESTION, rendering the heuristical detection logic effectively unused. Instead of fixing the bug,6e12729f71"remove unused enumerator from EncodedWordState" andb8d8fb3f0c"convert EncodedWordState to scoped enum" crippled the code further by removing any reputedly unused cases. But the only remaining use of INetMIMEEncodedWordOutputSink is in INetMIMEMessage::SetHeaderField_Impl, encoding MIME-Version, Content-Transfer- Encoding, Content-Type, and Content-Disposition header fields. And none of those headers have any "free-form text" content that should be encoded as per RFC 2047. The first two have fixed ASCII-only content ("1.0" and "7bit", "8bit", etc., respectively), while the latter two have structured content that may contain parameters of arbitrary content, which must be encoded according to RFC 2231 (but currently isn't). And the only place where such arbitrary-content parameters are generated is in the two calls to SetContentTransferEncoding in forms/source/component/DatabaseForm.cxx. (The calls to SetContentType there and in tools/source/inet/ itself are all known to have unproblematic ASCII-only content.) So mark those two places with TODOs about the missing encoding (which had been missing since forever) and, in INetMIMEMessage::SetHeaderField_Impl, liberally convert the content to 8-bit via OUString::toUtf8 for now. Change-Id: I4b2a219b396953b219ca66441a5227157a35951f
Embedded forms control and pieces (design forms in documents, fields and database driven).