I think this is my last question about WFS and URL-encoding this time. I had a look how the WFS requests look in hexadecimals.
My TinyOWS and Mapserver WFS both accepts two ways to express letter "ä" inside ogc:Filter with http GET. First of those alternatives is an UTF-8 letter "ä" in URL-encoded format which looks as text like %C3%A4. Corresponding hex values in the GetFeature request seem to be 25-43-33-25-41-34. Another alternative that works also it to give letter "ä" in UTF-8 without URL-encoding it and then the hex values are C3-A4. My question is that are both alternatives correct to use in http GET? I have thought that URLs should use URL-encoding. OGR WFS driver is itself doing URL encoding for <,>," and [space]. Could it be so that expressing "ä" as plain C3-A4 in a filter works only because the http GET route is passing them on as raw, and WFS server by accident interprets them back to "ä" because it is internally using UTF-8? There seem to be more to puzzle ordinary people like me. What looks like character "ä" to me is also an extended ASCII character #228 and some URL-encoders are translating it to %E4 (probably the reason for gvSIG WFS filter error). http://www.blooberry.com/indexdot/html/topics/urlencoding.htm Some others are considering "ä" as a two-byte UTF-8 character and URL-encode that into %C3%A4 http://www.w3schools.com/tags/ref_urlencode.asp It must be funny to be a coder. -Jukka- _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
