Arduino的:uint8_t有数组字符串 [英] Arduino: uint8_t array to string

查看:2130
本文介绍了Arduino的:uint8_t有数组字符串的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有基于Android的NFC应用程序发送哈希作为APDU答案。这是code我在Android应用程序用来发送哈希:

I have an NFC application built on android that sends a hash as an apdu answer. This is the code I use in my Android app to send the hash:

@Override
    public byte[] processCommandApdu(byte[] arg0, Bundle arg1) {

        String hash = "e68d3f574009cbbe011150263634c5c0";

        return hash.getBytes(Charset.forName("UTF-8"));

    }

现在,当我收到它的东西,我得到这个RAW数据Arduino的一面:

Now when I receive it on the Arduino side of things I get this RAW data:

10154561005110253555248485799989810148494949534850255255255255255255255255255

我如何获得哈希回来从?

How do I get the hash back from that?

这是我现在所拥有的,但它显然不工作:

This is what I have right now but it's obviously not working:

        uint8_t response[32];

        uint8_t responseLength = sizeof(response);

        if (nfc.inDataExchange(message, sizeof(message), response, &responseLength)) {

            Serial.print("RAW: ");
            for (int i = 0; i < sizeof(response); i++) {
                Serial.print(response[i]);
            }

            Serial.println(" ");

            char buffer[32];
            itoa((int)response,buffer,8);

            Serial.print("ITOA: ");
            for (int i = 0; i < sizeof(buffer); i++) {
                Serial.print(buffer[i]);
            }

            Serial.println(" ");
       }

这是code以上的串行输出:

And this is the serial output of the code above:

RAW: 10154561005110253555248485799989810148494949534850255255255255255255255255255 
ITOA: 4253   µ      + 
  3ü       R    

HALP!

推荐答案

三点建议,虽然他们没有真正解释了为什么最后几个字节被截断:

Three suggestions, though none of them really explains why the last few bytes get truncated:


  1. 不要十六进制哈希再presentation转换为字符串到后来在UTF-8编码发送这些字符。这将是更有效(和更少的解码努力)直接发送哈希作为一个字节:

  1. Don't convert the hexadecimal hash representation to a character string to later send those characters in UTF-8 encoding. It would be much more efficient (and less decoding effort) to directly send the hash as bytes:

@Override
public byte[] processCommandApdu(byte[] arg0, Bundle arg1) {
    byte[] hash = {
            (byte)0xe6, (byte)0x8d, (byte)0x3f, (byte)0x57,
            (byte)0x40, (byte)0x09, (byte)0xcb, (byte)0xbe,
            (byte)0x01, (byte)0x11, (byte)0x50, (byte)0x26,
            (byte)0x36, (byte)0x34, (byte)0xc5, (byte)0xc0
    };

    return hash;
}

如果你已经有了哈希作为十六进制字符串,我建议你将它转换为它的字节重presentation对Android方第一。

If you already have the hash as a hexadecimal string, I suggest you convert it to its byte representation on the Android side first.

在使用HCE,你应该坚持ISO / IEC 7816-4的APDU,而不仅仅是发送随机数据。一个命令APDU(短格式),包括以下内容:

When using HCE, you should stick to ISO/IEC 7816-4 APDUs instead of just sending random data. A command APDU (short format) consists of the following:

+----------+----------+----------+----------+----------+------------+----------+
| CLA      | INS      | P1       | P2       | Lc       | DATA       | Le       |
| (1 Byte) | (1 Byte) | (1 Byte) | (1 Byte) | (1 Byte) | (Lc Bytes) | (1 Byte) |
+----------+----------+----------+----------+----------+------------+----------+

其中LC连接codeS数据的字节数。如果数据为空,LC是空的了。勒烯codeS预期作为响应字节数(与乐= 0×00的特殊情况下,这意味着预期256响应字节。

Where Lc encodes the number of bytes of DATA. If DATA is empty, Lc is empty too. Le encodes the number of bytes expected as response (with the special case of Le = 0x00, which means 256 response bytes expected.

一个响应APDU(这就是你作为一个返回值在发送 processCommandApdu )看起来是这样的:

A response APDU (that's what you send as a return value in processCommandApdu) looks like this:

+----------+----------+----------+
| DATA     | SW1      | SW2      |
| (n Byte) | (1 Byte) | (1 Byte) |
+----------+----------+----------+

DATA为响应数据。 SW1和放大器; SW2形成响应状态字(SW1通常= 0×90,SW2 = 0×00成功)。需要注意的是SW1和SW2是强制性的。

DATA is the response data. SW1 & SW2 form the response status word (typically SW1 = 0x90, SW2 = 0x00 for success). Note that SW1 and SW2 are mandatory.

在通过的响应迭代 inDataExchange 使用由该功能提供的响应长度( responseLength )而不是你的最大缓冲区长度:

When iterating through the response of inDataExchange use the response length provided by that function (responseLength) instead of your maximum buffer length:

for (int i = 0; i < responseLength; ++i) {
    ...
}

此外,我建议你提供一个缓冲区比预期的最大响应长度多。 (特别是在您使用一个32字符的字符串,这可能会(对某些字符)导致更多的32个字节的UTF-8编码你的情况。)

Moreover, I suggest that you provide a buffer with more than the maximum expected response length. (Particularly in your case where you use UTF-8 encoding for a 32 character string, which might (for some characters) result in more that 32 bytes.)

这篇关于Arduino的:uint8_t有数组字符串的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆