I am trying to simply prompt for a movie file and set the filename of a
player to that filespec. Essentially:
answer file Pick a movie:
set the fileName of player 1 to shortFilePath(it)
If I have a movie file, say video.mov in a folder with Unicode
characters, say Κάποια έρευνα (Greek
I think you should be able to use uniDecode to convert the filename string
to its Unicode equivalent.
Pete
lcSQL Software http://www.lcsql.com
Home of lcStackBrowser http://www.lcsql.com/lcstackbrowser.html and
SQLiteAdmin http://www.lcsql.com/sqliteadmin.html
On Wed, May 6, 2015 at 4:08 PM
Normalisation, folding and collation all require a fair bit of data to do
(proportional to the size of the current iteration of the unicode character
tables in fact) which will be why SQLite externalises such functions as hooks.
It might be we can hook this up to the routines in the engine
Interesting, thanks Mark.
In case any database developers are interested, it seems that the SQLite
upper() and lower() functions only work with ASCII characters as does
COLLATE NOCASE so at least Livecode is ahead of SQLite. It is possible to
write your own collation handlers for SQLite but
If I read that correctly the LC 7.0.4 results for Unicode media paths
could be summarized as:
Works:
- Windows QuickTime
- OS X 10.10 AV Foundation
- OS X 10.9 AV Foundation
- OS X 10.8 AV Foundation
Fails:
- OS X 10.7 QuickTime
- OS X 10.6 QuickTime
Not described:
- OS X 10.7
and
SQLiteAdmin http://www.lcsql.com/sqliteadmin.html
On Tue, May 5, 2015 at 3:13 PM, Peter W A Wood peterwaw...@gmail.com
wrote:
Are you sure that the two Greek words are actually the same? I don’t know
Greek but from a quick scan of the Unicode docs, it seems that not all
Greek letters have an uppercase
Are you sure that the two Greek words are actually the same? I don’t know Greek
but from a quick scan of the Unicode docs, it seems that not all Greek letters
have an uppercase equivalent. Google translate cannot find a Greek translation
of PETER other than PETER which is clearly not equal
On 5/5/2015 1:00 PM, Peter Haworth wrote:
I just set up the following test
2 fields and a button
Using the Greek keyboard, I keyed qwerty into the first field and
QWERTY into the second field.
The button script has in its mouseUp handler:
set the caseSensitive to false
put
of caseSensitive
work OK when comparing textDecoded strings?
All string operations support Unicode in LC 7. Obviously, binary data
operations (e.g. byte x to y of ...) don't!
To answer your specific question: when applied to Unicode strings, the
toUpper, toLower, and the caseSensitive property
I tried pasting from Google translate using my first name in lower and
upper case, but I still get false,false.
The variable seems to be OSX vs Windows.
Maybe someone from RunRev will chime in on this. If not, I'll probably
enter a QCC report and see what they have to say.
Pete
lcSQL Software
On 2015-05-04 22:31, Peter Haworth wrote:
Does toUpper/toLower work? Similarly, does the setting of
caseSensitive
work OK when comparing textDecoded strings?
All string operations support Unicode in LC 7. Obviously, binary data
operations (e.g. byte x to y of ...) don't!
To answer your
Interesting. I wonder why my results are different. I'm using LC 7.0.4
and Yosemite. and get false,false no matter what caseSensitive is set to.
If I use US keyboard, everything works as expected. It's only when keying
in Greek characters that I always get false,false.
Pete
Pete
lcSQL
On 5/5/2015 1:52 PM, Peter Haworth wrote:
Interesting. I wonder why my results are different. I'm using LC 7.0.4
and Yosemite. and get false,false no matter what caseSensitive is set to.
If I use US keyboard, everything works as expected. It's only when keying
in Greek characters that I
Greece has to pay a lot back to the EU, it must be a hack...
Peter Haworth p...@lcsql.com wrote:
Interesting. I wonder why my results are different. I'm using LC 7.0.4
and Yosemite. and get false,false no matter what caseSensitive is set to.
If I use US keyboard, everything works as
Busy converting SQLiteAdmin to be Unicode compliant using LC 7.0.4. It's
going very smoothly so far and no performance issues or crashes.
Couple of things I'm not clear on. These questions all refer to variables
that hold textDecoded strings
Does toUpper/toLower work? Similarly, does
Peter Haworth wrote:
Does toUpper/toLower work? Similarly, does the setting of
caseSensitive work OK when comparing textDecoded strings?
Can I use char references, e.g. char x to y of tVar or offset, or
do I need to use byte x to y, byteOffset?
Character is safer for strings since it
Great, thanks Richard.
Pete
lcSQL Software http://www.lcsql.com
Home of lcStackBrowser http://www.lcsql.com/lcstackbrowser.html and
SQLiteAdmin http://www.lcsql.com/sqliteadmin.html
On Mon, May 4, 2015 at 1:39 PM, Richard Gaskin ambassa...@fourthworld.com
wrote:
Peter Haworth wrote:
Does
Two more useful links:
http://www.howsoft.com/runrev/downloads/vanilla_utf-8_chooser_demo_linux.txt
http://www.howsoft.com/runrev/downloads/vanilla_utf-8_chooser_demo_windows.txt
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please
In the Demo, at the beginning of the callChooser handler, you will see
these 3 lines:
put empty into field choice
put empty into field thePath
put empty into button theFiles
These are OK in the Demo, but if you copy the handler to your own app as
suggested, it will complain about
Now 100% UTF-8 Unicode (no more HTML for file I-O).
Multiple file selection.
Better navigation.
Much easier to employ in your app.
Links (info, and single file download):
http://www.howsoft.com/runrev/ulinchoosers/ (Linux)
http://www.howsoft.com/runrev/uwinchoosers/ (Windows
in context:
http://runtime-revolution.278305.n4.nabble.com/LC7-Unicode-tp4689927p4690286.html
Sent from the Revolution - User mailing list archive at Nabble.com.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe
and the theories
and websites persist. People have decided that Unicode is to blame for LC
This is especially a really bad analogy.
Some people and 1100 Engineers and architects who say steel buildings don't
collapse by a jet fuel fire.
There are false flags all around us. But people believe what
On Tue, Mar 17, 2015 at 4:38 AM, TEDennis teden...@softwaredetails.com
wrote:
Apparently all those references have been wrong. How
did we ALL (or most of us) get to the point where we thought Unicode was
the
culprit?
Probably because LC7 was billed as the Unicode version and it's simple
.
Currently, I have no reason to open up the app.
In the meantime, any other community members who use 7.x can benefit from a
fix of a glitch in file read processing they don't even know they have.
TED
--
View this message in context:
http://runtime-revolution.278305.n4.nabble.com/LC7-Unicode
for clarification of a
claim made by one of the developers (?) which made it sound like LC was
determining all by its lonesome that Unicode was being used. If that were
the case, and we could disable that auto-determination, I would readily use
it as an easy way out of a situation that affects my
On 17/03/2015 18:19, TEDennis wrote:
re: Have you submitted it? [the eof bug]. If not, do you have a sample
script I might use to verify the issue and submit it for you?
I submitted it, complete with a detailed script/recipe. It was accepted as
a bug, and they [claim to have] fixed it. When
mean I have to sit by quietly and let issues that affected
an entire user community go by with nary a comment.
And there you have it.
TED
--
View this message in context:
http://runtime-revolution.278305.n4.nabble.com/LC7-Unicode-tp4689927p4690286.html
Sent from the Revolution
TEDennis wrote:
Kay C Lan: Well, I'm glad you got that off your chest. Feel better?
It seems you have an emotional tie to somebody or something at RunRev. It
could simply be that your years of Revolution/LiveCode usage has created a
strong loyalty. Whatever ... It's likely your view is
If
Unicode is what's behind the performance glitches, then that's most
certainly not the answer I want to hear. But, life goes on.
This is what I understand the LC engineers are actively working on, so
hopefully there should be some performance improvements in the future. I really
suspect
No response to my prior post, so let's try this again ...
Dr Peter Brett wrote: Internally, the LC7 engine only uses Unicode if it
has to. If your application only uses native strings, then LC7 will only
use native strings. Built-in Unicode support has very little to do with the
fact that LC7
Bernard: I didn't see the transition in Dr. Brett's discussion to be as black
and white as your interpretation.
re: all the goodness of widgets and the javascript engine and the new DSL
language enhancements seem to me to be far more significant than unicode.
Agree 100%, and I am looking
then on.
At which time I will encounter the performance glitch. Again.
Sigh ...
TED
--
View this message in context:
http://runtime-revolution.278305.n4.nabble.com/LC7-Unicode-tp4689927p4690269.html
Sent from the Revolution - User mailing list archive at Nabble.com
No response to my prior post, so let's try this again ...
I'll give some answers as far as I understand LC7 at present, if I get
something wrong no doubt someone will correct me! It wouldn't be the first
time. :)
Dr Peter Brett wrote: Internally, the LC7 engine only uses Unicode if it
has
Paul: Thanks for the response.
I asked: /Can we turn off that /[Unicode]/ detection, thus eliminating
Unicode processing?/
You replied: /No, this has been asked several times on the list, it's part
of the internal processing that LC uses and is too deeply embedded to
eliminate/.
I have been
I think the important part of Peter Brett's answer comes after his remarks
on Unicode:
Internally, the LC7 engine only uses Unicode if it has to. If your
application only uses native strings, then LC7 will only use native
strings. Built-in Unicode support has very little to do with the fact
On Thu, Mar 12, 2015 at 9:16 AM, Richard Gaskin ambassa...@fourthworld.com
wrote:
I'll keep you posted with any definitive news from them.
thanks, Richard
--
Stephen Barncard - Sebastopol Ca. USA - Deeds Not Words
___
use-livecode mailing list
stephen barncard wrote:
On Wed, Mar 11, 2015 at 10:27 PM, Richard Gaskin wrote:
Is that on Dreamhost, or have you been able to reproduce it on
another shared host?
I have a standby shared account at Intersever.. thanks to your
suggestion.
I am pretty sure I did a test but maybe not.
I do not know much, if anything about the LC implementation of Unicode or
Unicode itself but I have been wondering.
LC 7.0.3 performance without doubt (to my eyes) seems to be less than LC 6.7.3
and from my reading of posts on this list it seems to be due to LC 7.0.3
implementing Unicode?
So
On Wed, Mar 11, 2015 at 10:27 PM, Richard Gaskin ambassa...@fourthworld.com
wrote:
Is that on Dreamhost, or have you been able to reproduce it on another
shared host?
I have a standby shared account at Intersever.. thanks to your suggestion.
I am pretty sure I did a test but maybe not.
re: Internally, the LC7 engine only uses Unicode if it has to. If your
application only uses native strings,
then LC7 will only use native strings. Built-in Unicode support has very
little to do with the fact that LC7 is slower for some workload
I don't now, and don't intend to, use Unicode
On Wed, Mar 11, 2015 at 6:27 AM, TEDennis teden...@softwaredetails.com
wrote:
re: Internally, the LC7 engine only uses Unicode if it has to. If your
application only uses native strings,
then LC7 will only use native strings. Built-in Unicode support has very
little to do with the fact
stephen barncard wrote:
something make the load time an intolerable one second or more that
wasn't there before in earlier 32 bit versions of LC Server.
Really annoying. This had nothing to do with 'workload'.
Is that on Dreamhost, or have you been able to reproduce it on another
shared host?
It should be noted that Gmail incorrectly quoted TED.
On Wed, Mar 11, 2015 at 7:30 PM, stephen barncard
stephenrevoluti...@barncard.com wrote:
Stephen Barncard - Sebastopol Ca. USA - Deeds Not Words
--
Stephen Barncard - Sebastopol Ca. USA - Deeds Not Words
Terence Heaford wrote:
Can LC 7 LC 8 be coded to enable Unicode to be switched “on”/“off”
either globally or on an individual control basis?
Not likely.
Unicode affects all things that deal with strings. That's pretty much
most of the engine.
Moreover, the refactoring for Unicode wasn't
On 2015-03-10 19:41, Richard Gaskin wrote:
Terence Heaford wrote:
Can LC 7 LC 8 be coded to enable Unicode to be switched “on”/“off”
either globally or on an individual control basis?
Not likely.
Unicode affects all things that deal with strings. That's pretty much
most of the engine
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
to implement unicode in an app using LC 6.6.2 and OSX 10.10.
I switched to the French keyboard to do some testing keying in French
accented characters into text field and storing the data into an SQLite
database.
Then I switched to the Greek keyboard. The unicode/SQLite stuff still
Continuing to implement unicode in an app using LC 6.6.2 and OSX 10.10.
I switched to the French keyboard to do some testing keying in French
accented characters into text field and storing the data into an SQLite
database.
Then I switched to the Greek keyboard. The unicode/SQLite stuff still
On Feb 18, 2015, at 2:14 PM, Peter Haworth p...@lcsql.com wrote:
Continuing to implement unicode in an app using LC 6.6.2 and OSX 10.10.
I switched to the French keyboard to do some testing keying in French
accented characters into text field and storing the data into an SQLite
database
OK, thanks Devin, just checking.
On Wed Feb 18 2015 at 2:06:53 PM Devin Asay devin_a...@byu.edu wrote:
On Feb 18, 2015, at 2:34 PM, Peter Haworth p...@lcsql.com wrote:
Reading the bug report, it sounds like it was only fixed in 7.0 not prior
releases.. Have you seen it work OK in
On Feb 18, 2015, at 2:34 PM, Peter Haworth p...@lcsql.com wrote:
Reading the bug report, it sounds like it was only fixed in 7.0 not prior
releases.. Have you seen it work OK in releases prior to 7.0, Devin?
Whoops, yes, I missed that detail in your original post, that you were working
in
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
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
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
Continuing down the path of making SQLiteAdmin unicode compliant.
I just took a file with French characters in Mac OS Roman format and and
used SQLiteAdmin to import it into an SQLIte database set up for UTF8
encoding. The import procedure did no decoding or encoding just read the
file and used
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
___
Update: Paul Depuis has submitted an enhancement request, commented on the
Unicode blog posting and got a reply from Fraser (who suggested a
guessEncoding function). More details at
http://forums.livecode.com/viewtopic.php?f=68t=22949p=118538#p118538
-
Some are born coders, some achieve
Home of lcStackBrowser http://www.lcsql.com/lcstackbrowser.html and
SQLiteAdmin http://www.lcsql.com/sqliteadmin.html
On Fri, Jan 30, 2015 at 8:25 AM, Dave Kilroy d...@applicationinsight.com
wrote:
Update: Paul Depuis has submitted an enhancement request, commented on the
Unicode blog posting
The Quality Center entry is http://quality.runrev.com/show_bug.cgi?id=14474
Personally, I really like Fraser's guessEncoding(somefile) vs my
suggested textEncoding(somefile) as it reminds the developer it is an
algorithmic and educated guess, but a guess none the less.
Leaving the Caribbean alone for a bit ... Fraser wrote a couple of blog posts
on Unicode back in March and April 2014:
http://livecode.com/blog/2014/03/31/examining-unicode-part-i-the-dissection/
http://livecode.com/blog/2014/04/02/examining-unicode-part-ii-digesting-text/
The second
since it has no unicodeText
property? Seems like I would need a hidden filed to act as an intermediary.
Maybe I just need to bite the bullet and use LC 7 for this project since it
doesn't need to address the unicodeText property. This for making my
SQLiteAdmin program unicode capable
filed to act as an intermediary.
Maybe I just need to bite the bullet and use LC 7 for this project since it
doesn't need to address the unicodeText property. This for making my
SQLiteAdmin program unicode capable.
Pete
lcSQL Software http://www.lcsql.com
Home of lcStackBrowser http://www.lcsql.com
is a
lot better to use than pre 7.0 when heavy unicode handling is needed!
But in the meantime, how should I be handling the above situation in pre
7.0?
Pete,
I’ve done this a lot pre-7. Here’s the relevant bit of code:
put unidecode(the unicodeText of line 1 of fld “russStuff,utf8
On Jan 26, 2015, at 10:01 AM, Devin Asay devin_a...@byu.edu wrote:
It would be great if there were a stack property we could set that would
specify what format outputted text would be. The default could be “native”;
i.e., the native encoding for the platform, but then we could set it to
Hi Devin,
That works perfectly in pre 7 and 7, thanks a lot.
It's somewhat of a pain to deal with this when putting data into a datagrid
since it requires a custom column behavior to format the data correctly. I
haven't tried editing a datagrid cell with unicode in it yet, but I'm
guessing
On Mon, Jan 26, 2015 at 3:42 AM, Fraser Gordon fraser.gor...@livecode.com
wrote:
One way of looking at things is that all external interfaces (files,
processes, etc) return binary data and you need to do something to turn
that into text (textDecode) and you need to turn your text into binary
textDecode - because you
are decoding some binary data to text.
The big difference between 7.0 and previous versions is that Unicode text
works everywhere - you don’t need to use special Unicode properties or
commands any more.
That does answer another question I had though which
to
get the correct value into the variable but it either ends up as question
marks or something that looks nothing like the characters in the field.
This is all with pre 7.0. I think I'm beginning to understand why 7.0 is a
lot better to use than pre 7.0 when heavy unicode handling is needed
7.0 and previous versions is that Unicode text works
everywhere - you don’t need to use special Unicode properties or commands any
more.
That does answer another question I had though which is what is needed if
the database is UTF-16 encoded. Sounds like nothing needs to be done. I
guess
Is there a lesson/guide anywhere that shows how to use unicode in LC 7?
All I need to do is SELECT data from an UTF8 encoded SQLite
database/display it in fields/datagrid and read input from fields/
INSERT/UPDATE it to the database.
I've got things working using unicodeText/uniencode/unidecode
Pete
I think the real coding advantage with Unicode in 7+ comes when processing
text.
Personally, I think that it is safer to stick with UTF-8 encoding for external
data as it is the only encoding format that you don’t need to worry about
processor “endianness”.
Regards
Peter
On 26 Jan
Over the years, many of you have downloaded my File/Folder/Picture
Chooser Widgets for Linux and Windows, which work only in English.
Well now, thanks to LiveCode 7.0.1, a Unicode Compliant (international)
Edition is available. Here are the relevant links:
GENERAL DESCRIPTION:
http
to use unicode in LC 7?
All I need to do is SELECT data from an UTF8 encoded SQLite
database/display it in fields/datagrid and read input from fields/
INSERT/UPDATE it to the database.
I've got things working using unicodeText/uniencode/unidecode in LC 6.6 but
wondering how things work in 7
that shows how to use unicode in LC 7?
All I need to do is SELECT data from an UTF8 encoded SQLite
database/display it in fields/datagrid and read input from fields/
INSERT/UPDATE it to the database.
I've got things working using unicodeText/uniencode/unidecode in LC 6.6
but
wondering how
is invisible when
viewed in a browser. Either way, once I cleaned off characters from the Xpath
function results, it did the right thing.
Kee
On Jan 14, 2015, at 9:48 AM, kee nethery k...@kagi.com wrote:
In the pre-Unicode days, this code:
set the itemdelimiter to tab
put empty into theData
In the pre-Unicode days, this code:
set the itemdelimiter to tab
put empty into theData
put “jumbo” into item 4 of theData
would produce something that looked like this (in your mind replace “tab”
with the blank spacing of a tab)
tabtabtabjumbo
In the Livecode 7 Unicode world
Just FYI, I just got this from the mother ship. I was under the impression that
the system property
the stackFileVersion
showed the file format (7.0 or earlier) of the currently open stack. It
doesn’t: all it shows is the format that any new stack will have when created
in the IDE. To find
On Nov 21, 2014, at 5:08 AM, Graham Samuel livf...@mac.com wrote:
Just FYI, I just got this from the mother ship. I was under the impression
that the system property
the stackFileVersion
showed the file format (7.0 or earlier) of the currently open stack. It
doesn’t: all it shows is
On 11/21/2014, 6:08 AM, Graham Samuel wrote:
When I switched from LC 6.x series to 7.x, I assumed my ‘saves’ would
save in the new format. They didn’t. That explains a lot. I suppose
everyone else here already knows that you have to do a ‘Save As…’ to
get the new format - but just in case…
I
I’ve got a strange problem that (so far) I haven’t been able to reduce to a
simple recipe.
I’m using a few Unicode characters in some menus in a cross-platform app (I
mean special characters that don't appear on a Windows keyboard - I do realise
that everything in LC is Unicode now
Graham
It may be that that whilst string data processed by our LiveCode scripts and
handlers is Unicode that is not the case with UI objects. I think that there is
a chance that LiveCode is still using native encoding (Windows Code Page on
Windows, ISO-8859-1 on Linux and the truly venerable
, at 14:06, Peter W A Wood peterwaw...@gmail.com wrote:
Graham
It may be that that whilst string data processed by our LiveCode scripts and
handlers is Unicode that is not the case with UI objects. I think that there
is a chance that LiveCode is still using native encoding (Windows Code
On 10 Nov 2014, at 13:06, Brahmanathaswami bra...@hindu.org wrote:
i tried that already:
case original_script
set the unicodetext of field lyrics to uniencode(tContent, utf8)
break
but still get garble
??
?? 555
555
? 555
[snip]
You need
... these appear as
\r\n\r\n
in the JSON and with unicode before and after... are they understood but
all these unicode functions (LC's, MergJson) etc... ?
bf\u0bb5\u0b9a\u0bbf\u0bb5\r\n\r\n\u0baa\u0bca
I've got mergJSON and will test that...
Swasti Astu, Be Well!
Brahmanathaswami
Kauai's Hindu
On 10 Nov 2014, at 10:26 pm, Peter W A Wood peterwaw...@gmail.com wrote:
That is unless mergJSON “de-escapes the JSON for you.
It should but Brahmanathaswami wasn't using it. mergJSON handles UTF8 though so
there's no need to have all the escapes. The only char it doesn't like is null.
Can someone enlighten me on the
/r/n/r/n
that appear in the unicode string that is being delivered (by a PHP
database access lib/api that we post to from this desktop app)
These are obviously two new lines, the break between verses of the
song... but how do they mix and match
in LC 6.6.2, Mac OS X Maveriks, calling data from MySQL dBase on our web
server into a desktop thin client.
I have a field that is being set to unicode... the default font is
Lucida Grande, which supports Tamil.
I'm on a mac: if I paste Inaimathi (Tamil Unicode font) into the field
much faster...
BTW I'm not sure why your server is escaping all the unicode characters instead
of just sending utf8. It's bloating your data unnecessarily.
Cheers
Monte
--
M E R Goulding
Software development services
Bespoke application development for vertical markets
mergExt - There's
your server is escaping all the unicode characters
instead of just sending utf8. It's bloating your data unnecessarily.
Cheers
Monte
--
M E R Goulding
Software development services
Bespoke application development for vertical markets
mergExt - There's an external for that!
--
M
too quick. You should be setting the unicodeText rather than the text... otherwise you
would want to do something like uniDecode( uniEncode(tContent,UTF8),ANSI)
BTW I'm not sure why your server is escaping all the unicode characters instead of just sending utf8. It's bloating your data
mentioning some unicode related issues with the Mark Smith libs that
there was a fix floating around for.
Where does one get mergeJSON?
From mergExt.com
Cheers
--
M E R Goulding
Software development services
Bespoke application development for vertical markets
mergExt - There's an external
original_script
set the unicodetext of field lyrics to uniencode(tContent, utf8)
break
Hmm... If tContent is UTF8 text then that should work fine. I vaguely recall
some folks mentioning some unicode related issues with the Mark Smith libs that
there was a fix floating around
http://qz.com/292364/why-you-probably-wont-understand-the-web-of-the-future/
--
-Mark Wieder
ahsoftw...@gmail.com
This communication may be unlawfully collected and stored by the National
Security Agency (NSA) in secret. The parties to this email do not
consent to the retrieving or storing
, utf-8 is very popular and utf8_general_ci is often
nowadays the default collation in web database front ends.
HTH
Martin Baxter
On 29/10/14 16:11, Tiemo Hollmann TB wrote:
Hello,
I have a LC 6 program communicating through PHP with a MySQL db. Because my
background about Unicode, PHP and MySQL
] Im
Auftrag
von Martin Baxter
Gesendet: Freitag, 31. Oktober 2014 11:19
An: How to use LiveCode
Betreff: Re: Unicode: LC 7.0 - PHP - MySQL?
A little additional info from me.
If your database will only ever contain ascii characters, then
ascii_general,
utf-8 and latin1_swedish will all
that for single-byte characters, UTF-8 is equivalent
to ISO-8859-1, so if your single byte umlaute are encoded using a
compatible variant of that, then there won't be a problem whichever
character set LC is expecting.
Ü (Uuml)
for example is at position 220 for unicode (e.g utf8) and also
ISO-8859-1
Thank you for your explanations
Tiemo
-Ursprüngliche Nachricht-
Von: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] Im
Auftrag
von Martin Baxter
Gesendet: Freitag, 31. Oktober 2014 13:46
An: How to use LiveCode
Betreff: Re: AW: Unicode: LC 7.0 - PHP - MySQL?
Tiemo
communicating through PHP with a MySQL db. Because my
background about Unicode, PHP and MySQL is limited I wonder what I have to
care about, when migrating to LC 7.
I have read the release notes of LC 7. My limited thinking was, that UniCode
really has a unique code for each sign on the planet. But why
a Valentina-DB. Where I have to
set the Encoding to Macintosh / Latin, depending on the platform. Does this
platform related conversion gets obsolete with LC 7 UniCode, or is this
still valid, because of data coming from outside, though Valentina probably
also is Unicode.
Thanks for coaching
Tiemo
am importing data from a Valentina-DB. Where I have to
set the Encoding to Macintosh / Latin, depending on the platform. Does this
platform related conversion gets obsolete with LC 7 UniCode, or is this
still valid, because of data coming from outside, though Valentina probably
also is Unicode
301 - 400 of 831 matches
Mail list logo
