URL : http://blog.startnfc.com/3
.....
NDEF
NDEF (NFC Data Exchange Format)는 NFC에서 데이터를 교환하기 위한 포맷입니다. NFC 포럼에서 정의 했습니다.
.....
NDEF 메시지
기본적인 메시지 단위 하나를 'NDEF 메시지 (NDEF Message)'라고 부릅니다. 하나의 NDEF 메시지는 여러 개의 'NDEF 레코드 (NDEF Record)'로 구성되어 있습니다.
NDEF 레코드
하나의 NDEF 레코드는 하나의 데이터를 담고 있는데, 이 데이터를 '페이로드'라고 합니다. 결국 이 페이로드를 전달하기 위해서 NDEF 레코드가 필요한 것입니다.
.....
하나의 메시지에 여러 개의 레코드가 존재하므로, 어떤 레코드가 다른 레코드를 참조하는 경우가 생길 수 있습니다. 이 경우 레코드에 대한 식별자가 필요할 것입니다. 이것을 페이로드 'ID'라고 합니다. 대부분의 경우에는 이 ID가 필요하지 않은데, 그래서 ID는 생략될 수 있습니다.
이렇게 '페이로드', '타입', 'ID' 세 가지가 NDEF 레코드의 주요 구성 요소가 됩니다. 실제로는 각 구성요소의 길이와 '레코드 헤더'가 추가되기 때문에, NDEF 레코드는 아래와 같이 구성됩니다.
항목 | 길이 | 설명 |
레코드 헤더 (header) | 1byte | 레코드에 대한 기본적인 정보 |
타입 길이 (type length) | 1byte | 데이터 타입의 길이 |
페이로드 길이 (payload length) | 1byte 혹은 4byte | 페이로드의 길이 |
ID 길이 (id length) | 1byte | ID의 길이 |
타입 (type) | '타입 길이' byte | 레코드가 담고 있는 페이로드의 타입 |
ID | 'ID 길이' byte | 페이로드 ID |
페이로드 (payload) | '페이로드 길이' byte | 레코드가 담고 있는 페이로드 |
NDEF 레코드의 구성
1byte의 '레코드 헤더'에는 아래와 같은 정보가 포함되어 있습니다.
헤더 항목 | 길이 | 설명 |
MB (Message Begin) | 1bit | NDEF 메시지의 첫 레코드는 이 비트가 1 입니다. |
ME (Message End) | 1bit | NDEF 메시지의 마지막 레코드는 이 비트가 1입니다. |
CF (Chunk Flag) | 1bit | 하나의 페이로드를 여러 개의 레코드로 나누어 전송하는 경우가 있는데, 이때 사용합니다. |
SR (Short Record) | 1bit | 이 비트가 1이면 '페이로드 길이'의 크기는 1byte이고, 0이면 4byte입니다. |
IL (ID Length) | 1bit | 레코드 ID가 존재하는 경우 이 비트가 1입니다. |
TNF (Type Name Format) | 3bit | (별도로 설명) |
NDEF 레코드 헤더 정보
.....첫 번째 레코드는 MB가 1이고, 마지막 레코드는 ME가 1입니다. 만약 NDEF 메시지 안에 하나의 레코드만 있다면, MB ME 모두 1로 세팅됩니다.
CF는 사용하는 경우가 별로 없습니다. 전송하고자 하는 데이터가 매우 크다면 여러 조각으로 나누어 전송할 수가 있는데 (chunked record), 이렇게 하면 모든 데이터가 전송되기 전에 액션을 실행할 수 있다는 장점이 있다고 합니다. 하지만 안드로이드에서는 NDEF 메시지를 모두 전송 받은 다음에 Intent가 발생하므로, 별로 의미가 없습니다.
SR이 1로 설정되어 있으면 '페이로드 길이' 항목의 크기는 1byte이고, SR이 0이면 4byte입니다. 그렇다면 실제 '페이로드'의 길이는 어디까지 가능할까요? SR이 설정되어 있으면 (2^8 - 1) = 255 byte가 될 것이고, SR이 설정되어 있지 않으면 (2^32 - 1) = 약 4GB 가 될 것입니다. 그래서 약 4GB가 페이로드의 이론적인 최대 길이가 됩니다......
위에서 '페이로드'와 '타입'은 반드시 존재해야 하지만, 'ID'는 존재하지 않을 수도 있다고 했습니다. 이에 대한 구분자도 필요할텐데, 이것이 IL입니다. ID가 존재하는 경우 IL이 1로 설정됩니다.
.....
TNF 와 Type
.....
MIME 타입 이외의 다른 타입들도 포함하고자 했습니다. 그렇다면 '타입' 외에 이 타입이 MIME 타입 형식으로 정의된 타입인지, 아니면 다른 형식의 타입인지를 구분할 필요가 있을 것입니다. 이것이 TNF 입니다. Type Name Format, 즉 '타입이 어떤 형식으로 되어있는가'를 나타냅니다.
TNF는 3bit의 크기를 가지므로, 8 가지의 TNF를 정의할 수 있습니다. 하지만 실제로는 4가지가 의미있는 TNF이고, 나머지는 특수한 용도로 사용합니다.
TNF (Type Name Format) | 값 | 설명 |
Empty | 0x00 | 비어있는 레코드. 즉, 페이로드가 없음. |
WKT (NFC Forum well-known type) | 0x01 | NFC 포럼에서 정의한 타입 형식. (예: URI, Text, Smart Poster) |
MIME (MIME Media type) | 0x02 | MIME 타입 형식. (예: plain/text, image/jpeg) |
AURI (Absolute URI type) | 0x03 | 예를 들어 XML의 경우 URI 형식의 DTD나 XML Schema를 타입으로 사용함. (예: http://www.w3.org/TR/html4/strict.dtd, http://www.w3.org/2000/svg) |
EXT (NFC Forum external type) | 0x04 | NFC 포럼에서 정의한 규칙대로, 임의의 타입 형식을 만들어 사용할 수 있음. (예: startnfc.com:U) |
Unknown | 0x05 | 알 수 없는 형식의 페이로드. 그냥 byte 덩어리로 취급됨. |
Unchanged | 0x06 | 데이터를 여러 조각으로 나누어 전송하는 경우 (chunked record) 이전 레코드의 타입과 같은 타입이라는 것을 나타내기 위해 사용. |
Reserved | 0x07 | 사용하지 않음. |
NDEF 메시지의 예
지금까지 설명했던 내용으로, NDEF 메시지를 하나 만들어보겠습니다. 'http://blog.startnfc.com' 이라고 하는 URL을 NDEF 메시지로 만들면 아래와 같이 됩니다. (모두 16진수입니다.) 어떻게 이렇게 만들어지는지에 대한 상세한 설명은 다음 포스트에서 할 것이므로, 일단은 이런 형태라는 것만 알아두면 됩니다.
D1 01 12 55 03 62 6C 6F 67 2E 73 74 61 72 74 6E 66 63 2E 63 6F 6D
항목 | 데이터 | 설명 |
레코드 헤더 | 0xD1 | 이진수로 하면 11010001 MB=1 ME=1 : 첫 레코드인 동시에 마지막 레코드임 CF=0 : Chunked record가 아님 SR=1 : 따라서 페이로드 길이의 크기가 1byte임 IL=0 : 따라서 ID는 존재하지 않음 TNF=1 : TNF는 Well-Known type |
타입 길이 | 0x01 | 타입의 길이가 1byte임 |
페이로드 길이 | 0x12 | 페이로드의 길이가 18byte임 |
타입 | 0x55 ('U') | Well-Known type에서 'U'는 URI를 나타냄 |
페이로드 | 0x03 0x62 ... 0x6D | 실제 데이터. 첫번째 바이트 0x03은 URI 페이로드의 헤더이고, 이후 0x62부터 "blog.startnfc.com"의 아스키코드. (URI를 표현하는 방식에 대한 것은 이후 포스팅에서 자세히 다룰 것임) |
'Wireless Network > NFC' 카테고리의 다른 글
NFC Forum Assigned Numbers Register (0) | 2014.09.21 |
---|---|
NDEF NFC Forum Spec (0) | 2014.09.21 |
NDEF란 무엇인가? (0) | 2014.09.20 |
NFC 안테나에 대해서 (0) | 2014.09.20 |
NFC with Android (0) | 2014.09.20 |