困扰十年，VFP中使用winsock控件网络收发时数据要么丢，要么不对，瓜哥一招解决。

社群的强哥最近在研究RFID,用winsock来接收RFID的数据，发现了百思不得奇解的问题,说为么VFP接到的数据怎么地就变化了，看看 EE就变成了3F了。

强哥在虎哥的帮助下解决了，虎哥说是VFP不支持BYTE，但设备发送是BYTE，所以直接取是取不到正确的数据。然后用了虎哥VB封装的一个 ActiveX DLL 组件，经过转换后得到了正确的数据。

看到这里猫猫觉得有点不太对，BYTE本质也是字符，怎么就不支持了？我就去找一下原因？

?ASC(STRCONV(STRCONV(“EE”,16),11)) =63 = 3F
原来真是进行了Uincode的转换，把EE变成了3F，
我倒着转不就行了，结果掉坑了，转不回来了。
?ASC(STRCONV(STRCONV(“3F”,16),9))=63 =3F
3F转完还是3F。
此时神秘的木瓜大侠（myfll作者）出手了。
他说:
如果包含有二进制数据，总是会丢失，或者与实际数据不符，这是由于字符转换的问题引起的。

vfp的字符串本质与二进制数据没有任何区别，而所有的OCX控件和COM组件(OCX控件本质是一种有界面的COM)，默认都是UNICODE字符传输，虽然COM定义了几十种数据类型，但在VFP中，基本就只数字和字符可以用了，所以VFP在与组件交换数据时，会自动进行ansi->unicode或者unicode->ansi转换，大于128的字符如果成对则不易转错，但不成对出现时，这种转换就失败了，导致数据不是原始的数据，为了避免VFP的自动转换，可按如下方式处理：

1. 从VFP传给组件

只需要简单套个CreateBinary()，VFP在把字符串传给组件时，不做任何转换，相当于BYTE或者LPBYTE，比如在winsock中发送二进制数据时，可以这样：

this.SendData(CreateBinary(你的字符串))

2 .从组件到VFP

这种情况比较复杂，可以使用的数组做为COM字节数组传递，比如在winsock中接收二进制数据，需要按如下方式处理：

DataArrival事件中：

LPARAMETERS bytestotal

ComArray(this.object,11)

Dimension lcBuffer[1] as Byte

this.object.GetData(@lcBuffer,17,bytesTotal)

?lcBuffer

?Strconv(lcBuffer,15)

这样获取到的数据就是原始的二进进制数据，不会被VFP转换。
在使用其他ocx控件或者com组件时，如果遇到需要处理二进制数据，均可按此方法，稍加修改即可。

问题完美解决。

未了，瓜哥说：
这个问题似乎困扰VFP开发者十多年了，我搜到09年就有人提出的这个问题，各种方法都试过了

https://blog.csdn.net/h57020877/article/details/5938389

这个研究的是比较深的，最后也放弃了，离成功只差一步了