Page 1 of 1
Is this an ASCII conversion bug.
Posted: Wed Aug 29, 2018 8:33 pm
by swhite
Hi
I am using PB 5.62 64bit on Windows and when I run the following code the result is that Ascii character 149 gets changed to ascii character 63 using the PokeS() or the ASCII(). Have I done something wrong or this indeed a bug?
Code: Select all
lcTxt.s = Chr(149)
Debug Asc(lcTxt)
Debug PeekA(@lcTxt)
*txBuffer=AllocateMemory(10)
PokeS(*txBuffer,lcTxt,1,#PB_Ascii)
Debug Str(PeekA(*txBuffer))
Debug PeekS(*txBuffer,1,#PB_Ascii)
*Buffer = Ascii(Chr(149))
Debug PeekA(*Buffer)
FreeMemory(*txBuffer)
FreeMemory(*Buffer)
Re: Is this an ASCII conversion bug.
Posted: Wed Aug 29, 2018 8:48 pm
by swhite
Hi
The following code shows that this happens for ASCII values between 128 - 159
Code: Select all
*txBuffer=AllocateMemory(5)
For ln.i=1 To 255
lcTxt.s = Chr(ln)
PokeS(*txBuffer,lcTxt,StringByteLength(lcTxt,#PB_Ascii),#PB_Ascii)
If PeekA(*txBuffer) <> ln
Debug Str(ln)+" "+Str(PeekA(*txBuffer))
EndIf
Next
FreeMemory(*txBuffer)
Re: Is this an ASCII conversion bug.
Posted: Wed Aug 29, 2018 9:37 pm
by infratec
Hi,
that's not a bug. It's a feature
If you open the 'Character-Table' in the Tools menue, then you can see that the 'ASCII'
values for 128 to 159 are not defined.
The not defined values are replaced by a questionmark '?' wich is dezimal 63.
But it's more complicated:
As you can read in the help of Chr() it is working in unicode mode.
And in unicode 0x80 (128) to 0x9F (159) is not defined.
That's the reason why it is not working as you thought.
What's your 'real' intention?
Re: Is this an ASCII conversion bug.
Posted: Thu Aug 30, 2018 12:11 am
by swhite
Hi
I have a host authorization service that returns these characters as part of a bitmap so they must be accurate to be interpreted. It currently runs in ASCII mode but I recently updated to Unicode and started seeing problems with the application when ASCII values fell in this range.
It seems to me that the ASCII value is an ASCII value and there is no reason to change it.
Simon
Re: Is this an ASCII conversion bug.
Posted: Thu Aug 30, 2018 12:44 am
by swhite
Hi
This issues does not exist in the Linux version so it seems to me it should not be the case in Windows version either.
Simon
Re: Is this an ASCII conversion bug.
Posted: Thu Aug 30, 2018 8:58 am
by infratec
If the behaviour in Linux is different to windows, then it's a bug.
The results should be consistant.
Maybe a flag for Chr() is needed to specify the mode (ASCII, UTF8, UNICODE)
The normal codeset in linux is UTF8, so it's possible that the Chr() functions returns other values than '?'
The only workaround which I see is an own DataSection with your needed ASCII values inside.
At least for the values between 128 and 159. Maybe for all values above 127.
Bernd
Re: Is this an ASCII conversion bug.
Posted: Thu Aug 30, 2018 11:33 am
by wilbert
infratec wrote:If the behaviour in Linux is different to windows, then it's a bug.
The results should be consistant.
Why should the results be consistent ?
Linux probably uses ISO-8859-1 as the default codepage in which case code 0 - 255 are identical to unicode and therefore can be converted.
Windows most likely uses Windows-1252 in which case code 128 - 159 are not identical to unicode so they can not be converted and are substituted by a question mark.