VFP does not support unicode/UTF-8. It uses windows specific code pages which is discouraged now.
Lianja uses Unicode/UTF-8 to represent data if the command line switch –locale utf-8 is specified on the desktop shortcut. Lianja will auto-detect many locales that use double byte characters and automatically use Unicode/utf-8 internally.
The standard character encoding for web browsers is UTF-8.
If you want to import your VFP data that you have stored via a codepage you must add –codepagedata to the desktop shortcut for Lianja App Builder and Lianja App Center.
Lianja/VFP has a set of functions that operate on double byte characters. LENC() being one of them. There is a list on the development roadmap that we have implemented. These are:
LENC(), LEFTC(), RIGHTC(), AT_C(), RAT_C(), SUBSTRC(), CHRTRANC(), and STUFFC()
These are the correct functions to use when working with Unicode/UTF-8 characters.
UTF-8 is the standard for double byte character sets and Lianja stores and retrieves data in UTF-8 format so as to make your data interoperable across desktop and web apps. It also is code page independent so you can display Korean, Chinese, Japanese, english and other characters without any concern for collating sequences or code pages.
One of the great advantages of UTF-8 is that the characters are represented in the correct collating sequence order. The disadvantage is that it uses more space to represent the characters.
When building Web and Mobile Apps no matter what locale the user is in that is working with your App and Data then the characters will be correctly displayed.
So to summarize.
LENC() will return 1 for a Korean character NOT 2 and not 3.
LEN() will return 3 as this is the UTF-8 character encoding for a Korean character.
So if you want to perform string manipulation use the functions listed above.
In v1.3 I have added SET CURRENCY TO “EURO” or SET CURRENCY TO “€” which are both handled when used with the currency() function.
in v1.3 you can specify the desktop shortcut with –unicode or –utf8 also which is the same as –locale utf-8
Note that since Lianja v1.2 unicode/UTF-8 is automatically used for recognized DBCS such as chinese, Japanese, and Korean.
If you want to share data and/or apps between desktop apps and web / mobile apps it is recommended that you use unicode/utf-8.
In the desktop shortcut you need to add
In the next version v1.1.6 I have also added an environment variable which you can specify the locale.
Then that works also without having to change the shortcut.
The following locales can be specified but will need tested by other developers as we don’t have all these keyboards available.
ISO 8859-1 to 10
ISO 8859-13 to 16
Iscii-Bng, Dev, Gjr, Knd, Mlm, Ori, Pnj, Tlg, and Tml
JIS X 0201
JIS X 0208
Windows-1250 to 1258
In v1.2.4 I have added the ability to override the month and day names in the popup date picker in Web Apps. Note that in Mobile Apps such as iOS or Android Apps the native date picker is used.
Full localization is planned for v2.0. This is an interim solution for those complaining about the date picker using english words.
You need to specify a two character locale name e.g. de for Germany, fr for France etc.
This causes the date picker to display with localized text in Web Apps.
Dates are always displayed in ANSI standard format so that the server does not have to understand the locale of the user. Here is an example using ‘de’ for German.
In v1.2.4 I have added “RightToLeft” as a caption position in Form and Canvas sections for both desktop and web to better support RTL languages such as Arabic.
Yes Lianja works with Unicode/UTF-8 by default in arabic locale.
If you have existing VFP data that is not in unicode/UTF-8 you need to specify –codepagedata on the “Lianja App Builder” and the “Lianja App Center” desktop shortcut so that Lianja will read the arabic characters via the codepage without trying to convert them to/from Unicode/UTF-8.
All you need to do is specify –locale utf-8 on the desktop shortcut. This should now work with Japanese and Russian also. Let me know if you have any issues.
I append 2 screenshots with Russian content (Version 1.2):
– field caption o.k.
– field content before beeing stored o.k. and after that wrong (only ???????)
– section header (Фамилия и имя = name and prenome) wrong
You also need to install Russian language fonts on your computer for this to work.