This repository has been archived by the owner on May 27, 2024. It is now read-only.
Application doesn't handle non-ASCII characters #25
Comments
Closed
|
@james2432 Thanks for filing this bug! Do you have a stack trace or any other information about what currently happens when it doesn't handle non-ASCII characters correctly? It would be good to document this if possible. |
james2432
added a commit
to james2432/gtfs-osm-sync
that referenced
this issue
May 13, 2016
Fix for CUTR-at-USF#25 - When obtaining data from OSM non-ASCII characters might be mishandled - When reading data from GTFS files non-ASCII characters might be mishandled - When writing output non-ASCII characters might be mishandled
|
It makes the characters render incorrectly. Like in the image below, "DE LA CITÉ & DE LA GAPPE" appears as "DE LA CITÃ%...." and from osm it says "De la Cité". This is due to invalid decoding(encoding on filewrite) as the old method was using default charsets defined by the operating system and may not be UTF8 (highly likely on windows machines) |
|
Perfect! |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Characters like èÈéÉ etc are not currently handled when downloading from OSM
Will create pull request
The text was updated successfully, but these errors were encountered: