The filename is decoded wrongly on Safari

[YDX-2147483647]

I'm opening this issue because:

• I have found a bug

• My Go version / GOPATH is: N/A
  (N/A because I use the pre-compiled binary.)

How to Reproduce

touch 啊.txt
# ISO/IEC 8859-1 (Latin 1) does not contain 啊
qrcp send 啊.txt

Then open the link in iOS Safari. You'll find å.txt.

Reason

The filename is declared in UTF-8 as \xe5\x95\x8a.txt in the header Content-Disposition, but Safari interprets it in ISO/IEC 8859-1 as å\x95\x8a.txt.

# Inspect the response with HTTPie
$ https http://*.*.*.*:**/send/****
HTTP/1.1 200 OK
Accept-Ranges: bytes
Content-Disposition: "attachment; filename=\xe5\x95\x8a.txt"
Content-Length: 110
Content-Type: text/plain; charset=utf-8
…

Possible solution

Add filename* in Content-Disposition.

qrcp/server/server.go

Lines 222 to 223 in 8b35ad8

	w.Header().Set("Content-Disposition", "attachment; filename="+
	app.payload.Filename)

§4.3. Disposition Parameter: 'Filename' - RFC 6266:

The parameters filename and filename* differ only in that filename* uses the encoding defined in [RFC5987], allowing the use of characters not present in the ISO-8859-1 character set ([ISO-8859-1]).

Appendix D. Advice on Generating Content-Disposition Header Fields - RFC 6266:

Include a filename* parameter where the desired filename cannot be expressed faithfully using the filename form. Note that legacy user agents will not process this, and will fall back to using the "filename" parameter's content.

An example in RFC 6266:

Content-Disposition: attachment;
                     filename="EURO rates";
                     filename*=utf-8''%e2%82%ac%20rates

The syntax of the value of filename* is specified in RFC 5987 §3.2.1:

ext-value     = charset  "'" [ language ] "'" value-chars
                   ; like [RFC 2231](https://www.rfc-editor.org/rfc/rfc2231)'s <extended-initial-value>
                   ; (see [[RFC2231], Section 7](https://www.rfc-editor.org/rfc/rfc2231#section-7))

---

I can make a PR if you want.

[YDX-2147483647]

I guess #253 should work?

It drops filename, which is against RFC 6266.