The problem of UTF-8 encoding and Chinese File Download in ASP

It was written a long time ago and stored here.

We generally know how to set response. charset = "UTF-8" is used to ensure that the browser can correctly interpret the page content, and <% @ codePage = 65001%> is used to ensure the correctness of the page source code, but many people will forgetSession. codePageAttribute.

Session. codePageIs used to ensure the output encoding of dynamic content. For example, you can control the string encoding output by response. Write. If not setSession. codePageThe ASP engine is generally set to the encoding format of ASP source code instead of the encoding specified in response. charset.

Example: ASP code is saved in UTF-8 format. The correct codePage and response are set on the page. charset, response. write outputs a string of Chinese characters, which can be correctly displayed in the browser according to UTF-8 encoding. in response. set the session before the Write statement. codePage = 936. If you refresh the page again, the browser displays garbled characters. If you force the browser to display the code according to gb2312, the code is correct.

As mentioned above, let's talk about a usage of session. codePage.

The current file download generally does not directly provide a real URL, but uses the component write, such as adostream. in this case, set Content-Type to application/octet-stream, and set header: Content-disposition to attachment=filename=youfilename.txt to ensure that the download dialog box is displayed in the browser instead of directly displaying it.

There is a problem here: IE6 has a bug, that is, it cannot correctly handle attachment; filename encoding in filename, ie uses the default Operating System encoding to handle it. the default encoding for windows in Chinese is GBK. Therefore, if the ASP page output uses the gb2312 format, there will be no errors. If the UTF-8 format is used, the output will be out of code 100%.

Now session. codePage comes in handy.

Refer to the following code:

Fn = "Chinese file name .doc"
Session. codePage = 936 'is set to gb2312 encoding output
Response. addheader "content-disposition", "attachment; filename =" & FN
Response. addheader "Content-Type", "application/octet-stream"
Session. codePage = 65001 'restored to UTF-8 encoded output

In this way, the returned header filename is forcibly encoded as gb2312 encoding, and IE can handle it correctly.

BTW: It is said that in a certain version of IE6, there is still a bug that it cannot handle filename with a length of more than 150 bytes. I have never encountered it. Maybe I have worked hard on patching.
Firefox uses UTF-8 to decode attachment; filename = by default, but it is amazing to use gb2312 as above.
I wonder if IE7 has changed in this regard.