Arduino : uint8_t 배열에서 문자열로

Question

나는 apdu 대답으로 해시를 보내는 android 기반의 NFC 응용 프로그램이 있습니다.

10154561005110253555248485799989810148494949534850255255255255255255255255255 

은 어떻게받을 수 있나요 : 나는이 RAW 데이터를 얻을 사물의 아두 이노 측을받을 때 지금

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

     String hash = "e68d3f574009cbbe011150263634c5c0"; 

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

    } 

: 이것은 내 안드로이드 응용 프로그램에서 사용하는 코드는 해시를 보낼 수 있습니다 그 해시 백?

 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(" "); 
     } 

을 그리고 이것은 위의 코드의 시리얼 출력 :

이것은 내가 지금 가지고 있지만 분명히 작동하지 않는 것입니다

RAW: 10154561005110253555248485799989810148494949534850255255255255255255255255255 
ITOA: 4253 µ  + 
    3ü  R  

HALP!

Answer 1

세 제안, 지난 몇 바이트가 잘립니다 왜 그들 중 누구도 정말 설명 없지만 :

1. 나중에 UTF-8 인코딩에서 해당 문자를 보낼 문자열을 16 진수 해시 표현을 변환하지 마십시오 . 그것은 바로 바이트로 해시를 보내 훨씬 더 효율적 (적은 디코딩 노력)이 될 것입니다 : 이미 16 진수 문자열로 해시가있는 경우

   @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; 
   } 
   

   , 난 당신이 안드로이드에 자사의 바이트 표현으로 변환 제안 측면에서 먼저.

2. HCE를 사용하는 경우 임의의 데이터를 보내는 대신 ISO/IEC 7816-4 APDU를 사용해야합니다. 명령 APDU (짧은 형식)는 다음으로 구성됩니다.

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

   여기서 Lc는 DATA의 바이트 수를 인코딩합니다. DATA가 비어 있으면 Lc도 비어 있습니다. 르 예상 256 응답 바이트를 의미 르 = × 00의 특별한 경우에 대한 응답으로 예상 바이트 수를 (인코딩합니다.

   응답 APDU () 당신이 processCommandApdu의 반환 값으로 보낼 무엇과 같이 보이는 :

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

   DATA 응답 데이터 인 SW1 & SW2 응답 상태 워드 (일반적 SW1 = 0x90, SW2 = 0x00으로 성공)을 형성 SW1 및 SW2는 필수 참고...

는

3. 대신 최대 버퍼 길이의 기능 (responseLength)에 의해 제공되는 응답의 길이를 사용 inDataExchange의 응답을 반복 : 또한

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

   , 난 당신이 더와 버퍼를 제공하는 것이 좋습니다 최대 기대 응답 길이. 특히 32 자 문자열에 UTF-8 인코딩을 사용하는 경우 (일부 문자의 경우 32 바이트 이상이 될 수 있음)

Answer 2

그래, 내 대답을 알아 냈어. 나는 itoa가 필요하지 않습니다. 난 그냥 숯불 내가 필요한 것을 얻을 수있는 RAW 입력 타입 변환 할 수 있습니다

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

      Serial.println(" "); 

을 그리고 그 출력 됨 : 지난 9 개 문자를 255로 대체되고있는 이유

e68d3f574009cbbe0111502ÿÿÿÿÿÿÿÿÿ 

지금 난 그냥 궁금?