[crossfire] Data File (Maps, Archetypes) Encodings

[tchize]

En l'instant précis du 02/06/07 09:03, Mark Wedel s'exprimait en ces termes:

(OT: Did not post for a long time, hello to everyone)
>   #3 probably makes the most sense, and at least for the gtk2 client, looks like 
> it would actually be handled properly (as the message generated on the wine 
> bottle is about invalid utf8 character).
>
>   Also, I'm not sure how easy #2 is - it is easy from a person writing the maps 
> or archetypes, but as demonstrated, pretty much all clients would have to do 
> special string handling.
>   
Well, it's just a 256 entries table to convert those character to
destination system.
>   #3 does make it harder for people putting the strings in (I'd think the map 
> editors could try to do the right thing in those cases and covert ISO 8859 15 
> characters to unicode)
>   
At least for java editor, it's not a problem. Java natively supports
UTF-8 strings. On the onther hand, java does not support easily
iso-8859-1 or iso-8859-15. Java supports UTF-8 and US-ASCII, the other
encoding formats support is platform dependent.
>   So I'd vote unicode.  I'd suspect that for clients that don't support utf8, 
> things won't really be any more broken than right now - the client would display 
> a funky character instead of the correct one.  But I don't believe that would 
> break any portion of the clients or protocol.
>   
Here is how some special utf-8 characters looks like when drawn in
iso-8859-1
utf-8 stored string: é - à - µ - ù - €
iso-8859-1 read string: é - à - µ - ù - €

Nothing very critical i think...
> _______________________________________________
> crossfire mailing list
> crossfire at metalforge.org
> http://mailman.metalforge.org/mailman/listinfo/crossfire
>
>