You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It outputs s="green;d=domain;i=sender+ä@domain" instead of the expected s=green;d=domain;i=sender+ä@domain.
In isolation, I expected the decoding function to return the exact original UTF-8 text but when I looked into it, I found that mediatype parsing depends on this function being aware it is being used to parse only a single parameter pair, hence the quote adding logic.
I tried moving the quote logic to mediatype parsing but got stuck on the "voice call" testcases.
When I run my string through mime.WordDecoder, I get the correct result.
Should this be fixed? i.e. move the quote logic to mediatype parsing and keep this function as a pure RFC2047 decoder or should its documentation mention that you can't just decode any random header value with it?
The text was updated successfully, but these errors were encountered:
I'd be OK with renaming the existing to RFC2047DecodePair or similar, and removing the single parameter pair specialization from the originally named func, if you think that would make more sense to folks using it.
I'd be OK with renaming the existing to RFC2047DecodePair or similar, and removing the single parameter pair specialization from the originally named func, if you think that would make more sense to folks using it.
That would make sense. I think just in case, it should be marked as a breaking change, should anyone depend on the pair specialization in the current func.
I've created the following testcase which fails:
It outputs
s="green;d=domain;i=sender+ä@domain"
instead of the expecteds=green;d=domain;i=sender+ä@domain
.In isolation, I expected the decoding function to return the exact original UTF-8 text but when I looked into it, I found that mediatype parsing depends on this function being aware it is being used to parse only a single parameter pair, hence the quote adding logic.
I tried moving the quote logic to mediatype parsing but got stuck on the "voice call" testcases.
When I run my string through
mime.WordDecoder
, I get the correct result.Should this be fixed? i.e. move the quote logic to mediatype parsing and keep this function as a pure RFC2047 decoder or should its documentation mention that you can't just decode any random header value with it?
The text was updated successfully, but these errors were encountered: