Consider this code:
[code] dim source as String = “abc”
dim target as String = “B”
source = source.ConvertEncoding (Encodings.UTF16LE)
target = target.ConvertEncoding (Encodings.UTF16LE)
if source.Instr (target) > 0 then
break ’ correct
else
break ’ wrong!
end if[/code]
Even with 2015r3.1, this goes wrong.
Same when using UTF16BE.
But works with UTF16 - even though that’s technically the SAME as UTF16 on an Intel CPU, isn’t it?!
DaveS
(DaveS)
November 17, 2015, 7:52pm
2
“abc” and “B” have the save binary representation regardless of encoding…
0x61 0x62 0x63 and 0x42
so UTF8, UTF16, UTF16LE, UTF16BE, ASCII all represent those character strings the exact same way
So, yes I would say it should work
Norman_P
(Norman P)
November 17, 2015, 7:56pm
3
No they dont
In UTF16 they are 16 bit values - either BE or LE
In UTF8 , ASCII and other single byte encodings they are single byte values
Tested your code on 2015r3 on Windows using 32 Bit and 64 Bit and always get “correct”. For UTF16BE, too. So it seems there is a little bug in the Mac-Framework.
DaveS
(DaveS)
November 17, 2015, 8:07pm
5
[quote=230394:@Norman Palardy]No they dont
In UTF16 they are 16 bit values - either BE or LE
In UTF8 , ASCII and other single byte encodings they are single byte values[/quote]
Sorry… you are correct… I used UltraEdit to test this and did it wrong
UTF16LE : 2F 00 C2 00 C4 00
UTF16BE: 00 2F 00 C2 00 C4
Now that everyone finally agrees with me, I’ve filed a bug report
<https://xojo.com/issue/41608 >
230397:@Thomas Kaltschmidt:
Tested your code on 2015r3 on Windows using 32 Bit and 64 Bit and always get “correct”. For UTF16BE, too. So it seems there is a little bug in the Mac-Framework.
Thanks for double checking.