ISO-8859-1 encoding, bad suggestion
The proxy upgrade seems to suggest that you have decided to use ISO-8859-1 instead of utf-8 for all services from trafiklab.
This sounds like a really bad idea since its not very future proof. If you break the API, better do it so you don't have to do it again in a year time.
I don't understand why you would not convert your ISO-8859-1 text to utf8 in the proxy, this is a very cheap process (there are various highly optimized versions in assembler out there) and it ensures that you can include characters as basic as the euro €.
Its just good practice to follow what the (internet) industry is doing, which is converting to using utf-8 in all the places of interoperation. Its just future-proof.
Följ inlägget
0
följare
Hi Thomas!
I also think UTF-8 is a better solution.
However, right now this is about to get things to work.
One of the problem has been that to many fix-encoding has been made in the chain.
Some where in the future, we will fix the backend to handle the encoding properly.
For now it is better to just fix the headers.
/ Lars
I understand this is a quick fix, and I agree that you want that and I agree with the way to do it.
What my suggestion pointed to is that you avoid changing the way that all 3rd party developers interact with the service by doing one more conversion.
I'm suspecting that the ultimate goal is that all back ends use utf-8, and that means you're only going to get rid of all conversions in the proxy if that is what you output.
Again, this is about future proofing this and for those like me to avoid having to force all his users on the appworld upgrading his app now, and again in a couple of months.
Lars, you write "For now it is better to just fix the headers."
You are aware that the actual bytes going over the wire for characters like ö/å are different in utf-8 and ISO-8859-1, right? In utf8 its 2 bytes for each of those chars.
Headers and encoding of the content havn't matched before.
So for now, we change the header.