Yes I was looking for the inverse operation. My first inclination was the fblock 1, lookup solution, but thought I'd troll here to see if there was some built-in I was unaware of. The change cascade is interesting, although somewhat less elegant than I'd hoped for.
On Feb 5, 2008 3:59 AM, Rob van der Heij <[EMAIL PROTECTED]> wrote: > On Feb 5, 2008 4:38 AM, Bruce Hayden <[EMAIL PROTECTED]> wrote: > > > There is the URLDECODE stage, which may also found under its old name > > of URLDEBLOCK. I find the help for it in the author's help library. > > But I think Bob was actually looking for the inverse operation. > Browsing the RFC gives at least 22 code points that would need to be > escaped. Alternatively, it offers 11 characters plus letters and > digits that would not need to be encoded. > Since the RFC allows for that, would it be an option to escape *all* > characters in the URL (except those that need to have their special > meaning)? > > I see no options beyond a cascade of a lot of "change" stages. Make > sure you put the % first and the most likely ones last. And it might > be attractive to wrap part of the change stages in a "verify" to avoid > needless passing through all stages. > Even when you generate a change for all ~ 180 remaining code points, > it still would be cheaper than a fblock 1 with a lookup stage. > > Rob >
