Diese Seite mit anderen teilen ...

Informationen zum Thema:
WinDev Forum
Beiträge im Thema:
Erster Beitrag:
vor 2 Jahren, 4 Monaten
Letzter Beitrag:
vor 2 Jahren, 4 Monaten
Beteiligte Autoren:
Fabrice Harari, Peter Holemans

Problem between Unicode string, buffer and CryptStandard

Startbeitrag von Fabrice Harari am 24.09.2015 15:52

Hi Everybody,

I thought I would let you know of a potential pitfall I just identified when working on IOS applications. It's kind of involved, so bear with me.

Lets consider a string containing ABC
In an ANSI String, it's binary content would be 41 42 43
in an UNICODE string, it would be 41 00 42 00 43 00

Now, in a project that has to send data from an iphone to the web, and want to encrypt it beforehand (ys, it's WXReplication), we HAVE TO use the new function cryptstandard (and the reverse one, of course).

As these two function accept only BUFFER as arguments, we need to transfer our ABC string into a buffer before encryption, and that is where the problem lays:

As I was using unicode strings, I was expecting the content of my buffer to be identical to the content of the unicode string (41 00 42 00 43 00), and it's length 6 bytes

This is true (as tested by me and the customer I was working with):
- in windev/windows, GO and EXE mode
- in webdev/window, GO and DEPLOYMENT mode
- In Mobile/Android, GO and Hardware mode

If you do the same thing on the XCODE simulator or on a physical iPhone/iPad, the content of the buffer becomes: 41 00 00 00 42 00 00 00 43 00 00 00 and it's length 12.

As long as you work inside the iphone, that doesn't create any specific problem as the affectation from buffer to unicode recreate the unicode string correctly.

However, as soon as you try to communicate with webdev (by example), you get:
- a buffer twice as big
- it's encrypted by cryptstandard with all the extra 0
- it's then transmitted to the web part (after a bufferothexa)
- on the web side, it's put into a buffer again (hexatobuffer)
- it's decoded, and the result is STILL 12 bytes long (41 00 00 00 42 00 00 00 43 00 00 00)
- and when the result is set in the unicode string waiting for it, we get : A (ie 41 00) instead of ABC, as the first 00 00 found is the End Of String.

This means that it's impossible to use the cryptStandard function as it was intended, ie accross platform, as soon as you work with iphones/iPad

Reproduction protocol:
usMyString is unicode string="ABC"
bufMyBuffer is buffer=usMyString
info(length(usMyString), length(bufMyBuffer),buffertohexa(bufmybuffer))

the info will display 3,6 everywhere but on the xcode simulator or the physical iPhone/ipad where you will get 3,12, 41 00 00 00 42 00 00 00 43 00 00 00

And this of course, is a BIG problem.

I found a workaround by massaging the content of the buffer before setting it into a unicode string, but it still means that the data sent is twice as big as it should be (slower) -AND- has to be extra processed when received from an iPhone (slower again).

So, before you waste your time on that one , I though I would share.

This problem has been sent to PCSoft support a few minutes ago. I'll keep you posted.

Best regards


Hey Fabrice,

Did you read this in the help which would explain what you ar experiencing:

Windows Mobile: In UNICODE, each character occupies two memory bytes. Therefore, the size of a buffer containing a UNICODE string is twice the number of characters actually found in the string in Windows.

LinuxiPhone/iPad: In UNICODE, each character occupies four memory bytes. Therefore, the size of a buffer containing a UNICODE string corresponds to four times the number of characters actually found in the string in Windows.

So I guess you need some sort of conversion between these unicode subsets but it doesn't look like it's really a bug. PCSoft should just provide the means to (automatically) translate between these subsets...

Maybe a function like UTF8ToUnicode() does this already but I haven't tested this.


Peter Holemans

von Peter Holemans - am 25.09.2015 08:26
Hello Peter,

no, I did NOT find that information. Thank you!

So that's the cause of the problem. I guess that's one more avenue of research.

Thanks again

von Fabrice Harari - am 25.09.2015 09:34
Zur Information:
MySnip.de hat keinen Einfluss auf die Inhalte der Beiträge. Bitte kontaktieren Sie den Administrator des Forums bei Problemen oder Löschforderungen über die Kontaktseite.
Falls die Kontaktaufnahme mit dem Administrator des Forums fehlschlägt, kontaktieren Sie uns bitte über die in unserem Impressum angegebenen Daten.