Assume there is some “not-latin” text (it could be russian or umlauts or something similar). And we have to store it to the Valentina database and then read it back.
UTF16 Encoding
Revolution has a property to get an UTF16-encoded content – unicodeText. So we can easily get it doing something like this one:
put unicodeText of field “ValueField” into uniText
Seems to be ready to pass this value to some vField, but Revolution externals (including V4REV) receive the data as a char* in C language. But UTF16 have ZERO bytes, so REV external cannot operate on it so far. It is obviously we should pass the data encoded with some single-byte code-page to avoid it. In most cases it could be UTF8.
UTF8 Encoding
So we do following –
- Set an appropriate IOEncoding property for the database first (we promise pass any strings to this db as UTF8 and vice versa – any string received from this database will be in UTF8):
get VDatabase_IOEncoding( mDBRef, “UTF-8” )
- Prepare UTF16 value:
- Decode it to UTF8:
- Write it to the database:
- Reading data back:
get VTable_FirstRecord(inTblRef)
put VTable_Field( inTblRef, 1 ) into fldRef
put uniEncode( VField_Value( fldRef ), “UTF8”) into fldValue
Native Encoding (Recomended)
Also, you can omit UTF16-UTF8 transformation using some “natural” code-page. But you should note it is OS dependent.
// If MacOS Then
get VDatabase_IOEncoding( mDBRef, “Macintosh” )
// else
get VDatabase_IOEncoding( mDBRef, “Latin1” )
…
// WRITING data into db:
put text of field “ValueField” into myValue
// READING data back from db:
get VTable_FirstRecord(inTblRef)
put VTable_Field( inTblRef, 1 ) into fldRef
put VField_Value( fldRef ) into fldValue
NOTE: you must set VDatabase_IOEncoding() after each VDatabase_Open() or VDatabase_Create() or after connect to a Valentina Server. This is your “contract” with database about encoding of IO strings.