On Mon, Oct 19, 2009 at 4:29 AM, Hans <[email protected]> wrote: > > Dan, it is important that we don't confuse various issues here! > My suggested code changes were directed to > > 1. Have messages display utf-8 characters and not code. > you suggested changes to function function BOLTmsg() > $BOLTsession['MSG'][$id] = BOLTurl2utf($value); > This seems to fix the coded utf message problem. > > 2. Have a correct redirect to a new page if the page name contains > '&' characters. > I suggested changes to BOLTredirect() so $nextpage is utf encoded, > since it is > not filtered or translated at all before that, but taken straight from > input. > This seems to fix the redirect problem.
Actually, I don't think I am confusing the issues at all. If you type index.php?p=test.%c3%9cberflu%c3%9f in your browser address bar it will be instantly converted to index.php?p=test.Überfluß as soon as you hit enter. I'm not talking about messages but about the address bar. That's because it is properly encoded. Now in your case... When you create a page name using a>b<c you get exactly that in the browser, not url encoded a<b>c. It's what I would expect of course,--but not what you want I think. If it were properly encoded you would see a<b>c in the browser address bar as well as in the messages. > Now you say: >> 1) It doesn't display properly in the url bar of the browser like other utf >> pages. >> 2) I can't seem to edit it. Ignores my changes... > > But the changes above 1. and 2. do not change the url in the browser bar. > So if you got a problem with that it is a different issue. As for editing, because there is an & in there, [[test.a>b<c]] gets interpreted as test.a & some malformed $_GET variables. So my edit link goes to test.a. Same if I manually type &action=edit into the address bar. Regardless, it's not a redirect problem at all because the redirect function only occurs after the form has been submitted and fully processed. Nothing to do with links or form editing. To be honest--I agree with Kevin, that while we should have UTF page names, we don't need to accommodate page names like a<b>c or a—b in our page names. I'm still leaning toward the idea we should exclude & from page names because of the confusion it causes with $_GET variables. I don't know how I overlooked it in the first place. > As to editing: it works fine here. > > Question: were htmlcharacter codes allowed/working in urls before at some > point? > i suspect not, and the '&' is always used as a separator for url arguments. > Only percent-encoded html character codes makes it possible to use > html special characters in page names. I'm not sure where the difference is between our codes. Happy to make it work. But I'm evidently missing something. Of course, the allowed escape characters are configurable for those who want something different. Cheers, Dan --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "BoltWire" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/boltwire?hl=en -~----------~----~----~----~------~----~------~--~---
