go: mime: BEncoding and QEncoding don't respect the 76 character line limit in RFC2047

As a continuation of Issue #12300, mime: BEncoding and QEncoding don’t respect the 76 character line limit in RFC2047.

Here is the relevant part from Section 2 of RFC2047. (emphasis mine)

An ‘encoded-word’ may not be more than 75 characters long, including ‘charset’, ‘encoding’, ‘encoded-text’, and delimiters. If it is desirable to encode more text than will fit in an ‘encoded-word’ of 75 characters, multiple 'encoded-word’s (separated by CRLF SPACE) may be used.

While there is no limit to the length of a multiple-line header field, each line of a header field that contains one or more 'encoded-word’s is limited to 76 characters.

What version of Go are you using (go version)?

1.8

What operating system and processor architecture are you using (go env)?

set GOARCH=amd64 set GOBIN= set GOEXE=.exe set GOHOSTARCH=amd64 set GOHOSTOS=windows set GOOS=windows set GOPATH=E:\gowork
set GORACE= set GOROOT=C:\Go set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64 set CC=gcc set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\graj04\AppData\Local\Temp\go-build930053034=/tmp/go-build -gno-record-gcc-switches set CXX=g++ set CGO_ENABLED=1

What did you do?

https://play.golang.org/p/vO6pcZgesh

What did you expect to see?

=?utf-8?q?=C2=A1Hola,_se=C3=B1or_this_is_to_see_what_happens_if_the_test_?= 
 =?utf-8?q?is_really_long._ltkhetslk_lskthe_lt_slkth_sekltse_ltksht_lskejt?= 
 =?utf-8?q?_lsht_lsht_lht_lht_lsht_lhtlshtlsetlksje_tlsejt_lksetlkse_tlkse?= 
 =?utf-8?q?_tlkst_lkstlkst_lskht_lstlsht_lshtlshtlshtslhtlshtlstle_tlse_tl?= 
 =?utf-8?q?se_tlkse_tlkse_tlse_tlst_lsetlstlset_setsle_tlset_lst_lset_lskt?= 
 =?utf-8?q?_alkthalkht_alkth_aeklth_aeslth_aeslth_eajraoiflanvwoalnwoaiehf?= 
 =?utf-8?q?_awesi_leahr_aflhf_awelh_aweh_awelh_wahwe_!?=

What did you see instead?

=?utf-8?q?=C2=A1Hola,_se=C3=B1or_this_is_to_see_what_happens_if_the_test_?= =?utf-8?q?is_really_long._ltkhetslk_lskthe_lt_slkth_sekltse_ltksht_lskejt?= =?utf-8?q?_lsht_lsht_lht_lht_lsht_lhtlshtlsetlksje_tlsejt_lksetlkse_tlkse?= =?utf-8?q?_tlkst_lkstlkst_lskht_lstlsht_lshtlshtlshtslhtlshtlstle_tlse_tl?= =?utf-8?q?se_tlkse_tlkse_tlse_tlst_lsetlstlset_setsle_tlset_lst_lset_lskt?= =?utf-8?q?_alkthalkht_alkth_aeklth_aeslth_aeslth_eajraoiflanvwoalnwoaiehf?= =?utf-8?q?_awesi_leahr_aflhf_awelh_aweh_awelh_wahwe_!?=

About this issue

  • Original URL
  • State: open
  • Created 7 years ago
  • Comments: 15 (6 by maintainers)

Most upvoted comments

@bradfitz As far as what these encoders should do, I would think it would depend on if they are trying to implement RFC2047 or just be a QEncoder and BEncoder. I would think if they are just being a Q/BEncoder then they wouldn’t add the spaces to break the encoded text into chunks and add “=?utf-8?q?=”, etc. If they are trying to implement RFC2047, then they should break into chunks, line wrap, etc. Right now I think it is straddling the line.