ACR39U----写方法里的16进制String转byte

因为是给接触式磁卡使用的读写软件,磁卡里面的数据都是以byte存储,所以软件上免不了一个过程,就是String-byte-byte[]-String。

这不禁让我想起了刚入门时,我还不会使用eclipse,于是我的老师手把手的教我们配置环境,然后给我在电脑屏幕上输入Hello World的场景,然后第二天我们就开始研究String,byte,char这些变量的含义和类型。

可惜当时没好好听课,直到现在使用了,只能面向百度和csdn编程。

首先要解决的就是写数据与读数据时,总是转换为char的问题,这个问题非常容易解决,因为一打开源码,第一页里就非常清晰的标注了读写方法的位置。在读写方法里,我们看到一个charat↓

charat.png

也就是说,这串代码会把所有读到的数据自动转换为char值,无论是读写都是。于是,把这串代码码掉之后,我们重新换上了helper.java中的getbytes方法↓
getbytes.png

在原始sdk里,为了将文本框里获取到的String转换为Byte,他使用了byte.parseByte的方法
但是这个方法会导致一个问题,就是数值越界。也就是说当你转换9D这种数字的时候,他会直接报错。因为byte的取值范围为-127~128,而9D由16进制转换为10进制的结果是157。

于是就需要将数据的转换方法进行调整,改为了Integer.parseInt()的方法,但是与此同时,又出现一个问题。发现转换出来的数据.........变为负数了。例如9D转换出来的数据,又变成了-99。

仔细检查了一下问题,发现是编码的问题,GBK采用双字节8位表示,总体编码范围为 8140 -- FEFE,首字节在 81 -- FE 之间,尾字节在 40 -- FE 之间。ASCII是7位编码,只使用前7位,第8位补0,所以转换成整数始终为正数,而GBK是8位编码,也就是说一个字节中的第8位可以为1,如1010 1101,而将其转换成byte类型时,byte值为10101101,以补码存储,第8位被当成符号位,当然是负数了,值为:-83。
↑以上答案来自于百度

但是测试了一下,发现好像不影响读写数据,整体都正常,于是就没再修改了。
毕竟编程嘛,开心就好,人和程序有一个能跑的,那么这次的编程就是成功而且愉快的。

发表评论

电子邮件地址不会被公开。 必填项已用*标注