Special character `á` incorrectly encoded in raw Geocoding API request URL
What kind of issue is this?
- [ ] Questions are better to ask on Stack Overflow. We are actively monitoring the questions there and oftentimes, others have already asked a similar question.
- [ ] Feature request should start off by describing the problem the feature will resolve. Please open a GitHub ticket beforehand with information about the feature to spark some discussion about the topic and once you have our support.
- [x] Bug Report can be reported using the provided template below:
Expected Behavior
Using a geocoder with the Mapbox Maps SDK for Android should support special characters. So the search Santa Catarina Mártir,Puebla should yield results whether the Geocoding API call is initiated in a browser or via the Mapbox Maps SDK for Android.
Current Behavior
Expected results return when geocoding api request is initiated in a browser (i.e. in the Search Playground), but when using the SDK the raw geocoding API request URL includes the incorrect encoding for special character á so no results are returned.
Possible Solution
Steps to Reproduce
- Run your app (including a geocoder) in Android Studio and use this code to log out the raw geocoding API request URL:
Log.d("GeocodingActivity", "onResponse: call.request() = " + call.request());
- Enter the search "Santa Catarina Mártir,Puebla" and grab the geocoding API request URL.
- See that it doesn't return any results and the query contains incorrect encoding: https://api.mapbox.com/geocoding/v5/mapbox.places/Santa+Catarina+M%25C3%25A1rtir%252CPuebla.json?access_token={{access-token}}&country=mx%2Cmx&types=poi%2Caddress&language=en
- Compare to the same search with the same parameters in the Search Playground and the raw request: https://api.mapbox.com/geocoding/v5/mapbox.places/Santa%20Catarina%20M%C3%A1rtir%2C%20puebla.json?access_token={{access_token}}&cachebuster=1551922406234&autocomplete=false&country=mx&limit=1&language=en
Context (Environment)
using gradle, compiling the following versions:
compile "com.mapbox.mapboxsdk:mapbox-sdk-services:4.5.0"
compile "com.mapbox.mapboxsdk:mapbox-sdk-geojson:4.5.0"
Detailed Description
Possible Implementation
cc @langsmith
Use String.replace() to swap out accented letters before building the .query parameter of MapboxGeocoding?
https://stackoverflow.com/questions/2774320/how-to-know-if-a-string-contains-accents
@langsmith Do we need the swap or do we need to provide the right encoding?
I saw something online about declaring encoding, but I'm not sure what's best for us off the top of our head. Encoding is probably better than having to check for an accented letter and then find the equivalent to be swapped in. Lots of languages out there.
https://docs.oracle.com/javase/tutorial/i18n/text/normalizerapi.html
https://dzone.com/articles/java-may-use-utf-8-as-its-default-charset
https://stackoverflow.com/questions/3322152/is-there-a-way-to-get-rid-of-accents-and-convert-a-whole-string-to-regular-lette
https://stackoverflow.com/questions/15190656/easy-way-to-remove-accents-from-a-unicode-string
https://www.rgagnon.com/javadetails/java-0456.html
@kbauhaus I modified BasicGeocoding to load the example you provided and got the following response:
public class BasicGeocoding {
public static void main(String[] args) {
MapboxGeocoding geocoding = MapboxGeocoding.builder()
.accessToken(BuildConfig.MAPBOX_ACCESS_TOKEN)
.query("Santa Catarina Mártir,Puebla")
.build();
geocoding.enqueueCall(new Callback<GeocodingResponse>() {
@Override
public void onResponse(Call<GeocodingResponse> call, Response<GeocodingResponse> response) {
System.out.println("GeocodingActivity: onResponse: call.request() = " + response.raw().request());
}
@Override
public void onFailure(Call<GeocodingResponse> call, Throwable t) {
System.out.println(t);
}
});
}
}
GeocodingActivity: onResponse: call.request() = Request{method=GET, url=https://api.mapbox.com/geocoding/v5/mapbox.places/Santa%20Catarina%20M%C3%A1rtir,Puebla.json?access_token=pk.XXXXX, tags={}}
which seems to be exactly what we were looking for. Maybe the problem is how the string is passed into the query?
Please let me know if there is still something that we should address.
This issue has been automatically detected as stale because it has not had recent activity and will be archived. Thank you for your contributions.