问题
I'm working on a system that uses UTF-8 characters in folder names for URLs. There's been no problem in navigating to these URLs and everything works as expected - except when issuing a redirect to another page on the site; whereupon the browser seems to encode the extended characters.
To give an example, I'm attempting to redirect to the following relative URL:
/geschäft/käfer/
If I visit that URL directly in the address bar, there's no problem. However if I change the location header to redirect the browser to this URL, it ends up at:
/gesch%E4ft/k%E4fer/
If I look in the response headers for the original page (It's a 301 redirect to the translated content) I can see this entry:
Location:/geschäft/käfer/
It seems the correct details are ending up in the header, but the browser's address bar is showing the encoded value with %E4 detailed above. I have attempted various ways of entering the URL into the location header, but all come out with the same result.
I am seeing this behaviour on Chrome 37.0.2062.120 m and on Firefox 32.0.2.
This is running on a dev box, Windows 7 Home with IIS7.5
EDIT:
It seems this issue could be related directly to ColdFusion. If I use Javascript to redirect to the url, this works... with the caveat that the file has to be saved with a BOM.
If I use cflocation, or if I use the pagecontext to insert the header manually, the issue persists regardless of whether or not a BOM is present.
I've also noticed a similar problem with using cfinclude in that these extended characters are displayed incorrectly unless the calling template is saved with a BOM.
回答1:
I went to test this and didn't see the same result. But then I played with it a little more and tried using
<cfprocessingdirective pageencoding = "utf-8"/>
Immediately, I was able to see the exact same issue that you did. It seems natural to include it in any page. This is very speculative, but CFAS may be doing some kind of URL encoding in the cflocation tag when used in conjunction with the pageencoding directive.
Assuming you have this in your code somewhere, try removing it for the redirect. If that works, then I would report this as a bug to Adobe.
Just FYI, I did this -- Output with encoding
<cfprocessingdirective pageencoding = "utf-8"/>
geschäft/käfer/
And I got
geschäft/käfer/
But when I did this -- Relocation with encoding
<cfprocessingdirective pageencoding = "utf-8"/>
<cflocation url="geschäft/käfer/" addtoken="false" />
It relocated me to
gesch%E4ft/k%E4fer/
And when I did this --Output without encoding
geschäft/käfer/
<cfabort>
I got
geschäft/käfer/
But when I did this -- Relocation without encoding
<cflocation url="geschäft/käfer/" addtoken="false" />
Then I was relocated to
geschäft/käfer/
回答2:
I've tried the above but it couldn't get it to work. I ended up doing the cflocation "manually". Like this:
<cfprocessingdirective pageencoding = "utf-8"/>
<cfheader charset="utf-8" name="location" value="geschäft/käfer/">
<cfheader statuscode="302">
This worked like a charm for me.
回答3:
This is still broken with ACF2018 - the CFHeader work-around does the trick, but... yuck..
It appears that Lucee (as of 5.3.3.62) also has the same problem.. I've reported it to them as well (LDEV-2456), we'll see what they have to say about it.
回答4:
Another potential work around for this is to URL Encode the portions of the URL that cflocation will break.
For example, I have some conditional testing that will 301 redirect if the combination of parameters are known to not work well together. One of those parameters is composed of Greek characters. Our solution is to use URLEncodedFormat() where needed.
<cfif Translation EQ "LXX" AND (URL.ot EQ "MGNT" OR URL.ot EQ "TR")>
<cfset URL.word = URLEncodedFormat(URL.word)>
<cflocation statuscode="301" url="/lang/lexicon/inflections.cfm?strongs=G#myStr.StrongsNum#&t=#URL.ot#&ot=#URL.ot#&word=#URL.word#" addtoken="No" />
</cfif>
来源：https://stackoverflow.com/questions/25979344/redirect-to-utf-8-url-with-coldfusion