How to escape strings in feature update requests?

Jump to solution
03-15-2011 07:00 AM
by Anonymous User
Not applicable
Original User: aaverett

I've been struggling with this for a couple of weeks now, and I can't figure it out.  It doesn't appear to be documented anywhere in the docs that come with ArcGIS Server, and Google turns up nothing useful at all.

I need a reference or some description of what the proper way to escape special characters in requests to the REST API is.

For instance, here is a request, sent to the following address:
 "geometry" : null,
 "attributes" : 
  "OBJECTID" : 1366095,
  "api_number" : "420413176600",
  "alt_well_ident" : "M082078",
  "_operator" : 115974,
  "reservoir" : 51334,
  "ground_elevation" : null,
  "kb_elevation" : null,
  "total_depth" : null,
  "location" : "474.6'FNW UNIT & 1460.63'FSW UNIT ELI SEALE 028 SUR SEALE 028 SUR",
  "comment" : null,
  "SHAPE" : null,
  "drill_date" : null,
  "lease_name" : "CONNER ODOM UNIT #1",
  "well_number" : null,
  "approx" : false,
  "state_fips" : 48,
  "county_fips" : 41,
  "_abstract" : null,
  "district" : null,
  "section" : null,
  "block" : null,
  "survey" : null

That request returns a 400 error message that talks about "invalid graphic features."  Some trial and error revealed that it works if I remove the ampersand character in the "location" attribute.  I found that it also works if I replace the ampersand with a hexadecimal escape - "%26" in this case.  Doing the same thing also works for string values containing a modulus character.  It doesn't work with just the literal modulus, but replacing it with "%25" allows the request to succeed, and returns a valid result.

The problem I have with this is that the escaped characters are not un-escaped on the server side, so I still have the "%26" when I call the record up again.  Un-escaping them on the client side is technically possible, but not ideal, because there are other clients for this dataset that would have to be modified as well.

Can anyone point me toward a reference that explains how these characters are supposed to be handled?
0 Kudos
1 Solution

Accepted Solutions
by Anonymous User
Not applicable
0 Kudos
2 Replies
by Anonymous User
Not applicable
0 Kudos
New Contributor II

I have the same problem and I don't understand how the suggested solution relates to the question...

Edit: never mind - URL encoding (%26) works for me.

0 Kudos