Re: More Unicode STuff
On Sat, Feb 14, 2015 at 2:23 AM, Peter Haworth p...@lcsql.com wrote: My brain is too fried to figure out why this should be so my plan is to just always encode/decode stuff when importing/displaying. Sorry for the slow reply, but I note your other post on your tentative move to LC 7 and the gotchas along the way, so this additional information will probably be timely and hopefully explanatory. This additional Important Note in the LC 7 dictionary under 'uniEncode/uniDecode' will be of interest: As of LiveCode 7.0 the uniEncode function has been deprecated. It will continue to work as in previous versions but shoud not be used in new code as the existing behaviour is incompatible with the new, transparent Unicode handling (the resulting value will be treated as binary data rather than text). This functions is only useful in combination with the also-deprecated uniDecode function and unicodeText field property. Also, as to why you need to do the two way encoding/decoding, it's better explained in the LC 7 dictionary under the 'textEncoding/textDecoding' entries: It is highly recommended that any time you interface with things outside LiveCode (files, network sockets, processes, etc) that you explicitly textEncode any text you send outside LiveCode and textDecode all text received into LiveCode. If this doesn't happen, a platform-dependent encoding will be used (which normally does not support Unicode text). It is not, in general, possible to reliably auto-detect text encodings so please check the documentation for the programme you are communicating with to find out what it expects. If in doubt, try UTF-8. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: More Unicode STuff
Thanks Kay. I tried looking at the db with the Firefox SQLite Manager plugin and sure enough it doesn't display correctly. In this case, the accented characters simply aren't there. I went back and imported the data again, this time encoding the data as UTF8. Now it displays correctly in both SQLiteAdmin (with decoding) and in the Firefox plugin. My brain is too fried to figure out why this should be so my plan is to just always encode/decode stuff when importing/displaying. On Thu Feb 12 2015 at 6:52:44 PM Kay C Lan lan.kc.macm...@gmail.com wrote: Have you looked at your data using another db management tool? My own limited experience of dealing with UTF8 with LC 7 and sqlite is that if I don't textEncode(data,utf8) into SQLite and textDecode(data,utf8) out of the db, then although all the data goes and comes back OK, if I look at the db with another program the data isn't the same - most likely any characters that are suppose to have an umlat or similar are instead displayed with a blank space next to them. Conversley if I take some other db that already contains UTF8 data with the characters appearing correctly in another program and just read them straight into LC, then I get scrambled characters. So if I want the charcters to appear correctly in everything, I need to textEncode() and textDecode(). This is purely for UTF8. Not sure how Mac Roman effects the issue. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: More Unicode STuff
Always a good policy. For one it can’t hurt, and for another… well I don’t have another. Bob S On Feb 13, 2015, at 10:23 , Peter Haworth p...@lcsql.commailto:p...@lcsql.com wrote: My brain is too fried to figure out why this should be so my plan is to just always encode/decode stuff when importing/displaying. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: More Unicode STuff
Have you looked at your data using another db management tool? My own limited experience of dealing with UTF8 with LC 7 and sqlite is that if I don't textEncode(data,utf8) into SQLite and textDecode(data,utf8) out of the db, then although all the data goes and comes back OK, if I look at the db with another program the data isn't the same - most likely any characters that are suppose to have an umlat or similar are instead displayed with a blank space next to them. Conversley if I take some other db that already contains UTF8 data with the characters appearing correctly in another program and just read them straight into LC, then I get scrambled characters. So if I want the charcters to appear correctly in everything, I need to textEncode() and textDecode(). This is purely for UTF8. Not sure how Mac Roman effects the issue. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: More Unicode STuff
I think that it depends from the collation declared for DB | table | fields indatabase. I'm using UTF8 bin and have no problems with text full of accented characters. They are the same in my application and any other, even phpmyadmin. Marek ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
