• Stephan Bergmann's avatar
    tdf#120158: Base CMimeContentType on INetMIME::scanContentType · b75e3ded
    Stephan Bergmann yazdı
    ...instead of using yet another local implementation of parsing media types.
    CMimeContentType is the implementation of the UNO
    css.datatransfer.XMimeContentType interface.  One observable change in behavior
    is that type, subtype, and parameter names will now always be reported in lower
    case instead of with the casing from the input preserved (but those differences
    in casing are functionally equivalent per the media type specification).  Also,
    parameter names supplied to the hasParameter and getParameterValue functions are
    now also treated case-insensitive.
    The upside of this change is that INetMIME::scanContentType (via "The encoding
    of rMediaType should be US-ASCII, but any Unicode values in the range U+0080..
    U+FFFF are interpreted 'as appropriate.'") already implicitly supports RFC 6532
    "Internationalized Email Headers" extensions for media types, allowing quoted-
    string parameter values to contain non-ASCII Unicode characters.
    That means that tfd#120158 "Impossible to paste special in Writer from Calc in
    Libreoffice 6.1.x in some UI languages - the dialogue caption says 'unknown
    source'" can be fixed by just allowing non-ASCII typename parameters being
    generated in ImplGetParameterString in svtools/source/misc/transfer.cxx, and
    reverting the problematic (see the comments there) previous fix
    <https://gerrit.libreoffice.org/61601> "tdf#120158: fix ImplGetParameterString
    for typename".  (Which will be done in a follow-up commit, to ease potential
    backporting, as that previous fix has already been backported to some versions
    but not to others.)
    Change-Id: I5d4d3586e8046f288a97605b000e262a8db5a4e9
    Reviewed-on: https://gerrit.libreoffice.org/61684
    Tested-by: Jenkins
    Reviewed-by: 's avatarStephan Bergmann <sbergman@redhat.com>
Library_mcnttype.mk 1.29 KB