CBOR
CBOR |
| 파일 이름 확장명 | .cbor |
|---|---|
| 인터넷 미디어 유형 | 애플리케이션/코보르 |
| 형식 유형 | 데이터 교환 |
| 연장 위치 | 메시지 팩 |
| 표준 | RFC 8949 |
| 오픈 포맷? | 네 |
| 웹사이트 | cbor |
간결한 이진 객체 표현(CBOR)은 C가 작성한 JSON에 느슨하게 기초한 이진 데이터 직렬화 형식이다.보르만.JSON과 마찬가지로 이름-값 쌍을 포함하지만 보다 간결한 방식으로 데이터 객체를 전송할 수 있다.이것은 인간의 가독성을 희생시키면서 처리와 전송 속도를 증가시킨다.IETF RFC 8949에 정의되어 있다.[1]null
다른 용도들 중에서, 그것은 CoAP 사물 인터넷 프로토콜 제품군에[2][failed verification] 권장되는 데이터 직렬화 계층과 COES 메시지의 기반이 되는 데이터 형식이다.FIDO2 프로젝트의 범위 내에서 CTAP(Client-to-Authenticator Protocol)에서도 사용된다.[3]null
CBOR는 후루하시 사다유키가 개발하고 추진한 메시지팩에서 영감을 얻었다.CBOR 확장 MessagePack, 특히 2013년 MessagePack에서 구현된 텍스트 문자열과 바이트 문자열을 구별할 수 있도록 허용.[4][5]null
CBOR 인코딩 규격
CBOR로 인코딩된 데이터는 데이터 항목의 스트림으로 보여진다.각 데이터 항목은 3비트 유형과 5비트 단축 카운트를 포함하는 헤더 바이트로 구성된다.그 다음에는 옵션 확장 카운트(짧은 카운트가 24-27 범위에 있는 경우)와 옵션 페이로드(Payload)가 뒤따른다.null
유형 0, 1, 7의 경우 페이로드(payload)가 없으며 카운트는 값이다.유형 2(바이트 문자열) 및 3(텍스트 문자열)의 경우 카운트는 페이로드의 길이입니다.유형 4(어레이) 및 5(지도)의 경우 카운트는 페이로드에 있는 항목(페어) 수입니다.타입 6(태그)의 경우, 페이로드(payload)는 단일 항목이고 카운트는 동봉된 항목을 설명하는 숫자 태그 번호다.null
| CBOR 데이터 | 데이터 항목 1 | 데이터 항목 2 | 데이터 항목 3...null | ||||||
|---|---|---|---|---|---|---|---|---|---|
| 바이트 수 | 1바이트(CBOR 데이터 항목 헤더) | 변수 | 변수 | 1바이트(CBOR 데이터 항목 헤더) | 변수 | 변수 | 기타... | ||
| 구조 | 전공형 | 쇼트카운트 | 확장 카운트(선택 사항) | 데이터 페이로드(옵션) | 전공형 | 쇼트카운트 | 확장 카운트(선택 사항) | 데이터 페이로드(옵션) | 기타... |
| 비트 수 | 3비트 | 5비트 | 8비트 × 변수 | 8비트 × 변수 | 3비트 | 5비트 | 8비트 × 변수 | 8비트 × 변수 | 등등.. |
각 데이터 항목의 주요 유형 및 카운트 처리
각 데이터 항목의 동작은 주 유형과 카운트에 의해 정의된다.주요 유형은 각 데이터 항목의 주 행동 또는 유형을 선택하는 데 사용된다.null
5비트 쇼트카운트 필드 인코드는 직접 0-23을 카운트한다.24–27의 짧은 카운트는 카운트 값이 다음 8, 16, 32 또는 64비트 확장 카운트 필드에 있음을 나타낸다.값 28~30은 할당되지 않으며 사용해서는 안 된다.null
형식은 계수 필드가 값을 직접 암호화하는 "원자" 형식 0–1과 6–7과 계수 필드가 다음 페이로드 필드의 크기를 암호화하는 비원자 형식 2–5로 나뉜다.null
31의 짧은 카운트는 무제한 길이를 나타내기 위해 비원자형 2–5와 함께 사용된다. 페이로드(payload)는 255의 "차단" 마커 바이트(type=7, short count=31)까지 다음과 같은 항목이다.다른 원자 유형 0, 1 또는 6에서는 31의 짧은 카운트가 허용되지 않는다.
6타입(태그)은 그 카운트 필드가 값을 직접 부호화하지만 페이로드 필드(항상 단일 항목으로 구성됨)도 있다는 점에서 특이하다.null
확장된 카운트 및 모든 멀티바이트 값은 네트워크(빅엔디안) 바이트 순서로 인코딩된다.null
CBOR 데이터 항목 필드 인코딩
작은 필드 인코딩
| 바이트 수 | 1바이트(CBOR 데이터 항목 헤더) | |
|---|---|---|
| 구조 | 전공형 | 짧은 카운트(값) |
| 비트 수 | 3비트 | 5비트 |
| 원자 | 0–1, 7 | 0–23 |
| 브레이크 마커 | 7 | 31 |
짧은 필드 인코딩
| 바이트 수 | 1바이트(CBOR 데이터 항목 헤더) | 변수 | |
|---|---|---|---|
| 구조 | 전공형 | 쇼트카운트 | 가치 |
| 비트 수 | 3비트 | 5비트 | 8비트 × 변수 |
| 원자 | 0–1, 7 | 24–27 | 8, 16, 32 또는 64비트 |
| 끈 | 2–3 | 0–23 | ×8비트를 세다 |
| 항목들 | 4–5 | 0–23 | 항목/항목을 ×계수하다 |
| 태그 | 6 | 0–23 | 한 항목 |
긴 필드 인코딩
| 바이트 수 | 1바이트(CBOR 데이터 항목 헤더) | 1, 2, 4, 8바이트 | 변수 | |
|---|---|---|---|---|
| 구조 | 전공형 | 쇼트카운트(24–27) | 확장 개수(페이로드의 길이) | 가치 |
| 비트 수 | 3비트 | 5비트 | 8, 16, 32 또는 64비트 | 8비트 × 변수 |
| 끈 | 2–3 | 24–27 | 최대 2-164 | ×8비트를 세다 |
| 항목들 | 4–5 | 24–27 | 최대 2-164 | 항목/항목을 ×계수하다 |
| 태그 | 6 | 24–27 | 태그, 최대 2-164 | 한 항목 |
정수(0 및 1)
정수의 경우 카운트 필드가 값이며 페이로드도 없다.0타입은 값이 최대 2-1인64 양수 또는 부호화되지 않은 정수를 인코딩한다.유형 1은 -264 ~ -1의 값에 대해 -1-카운트 값을 갖는 음의 정수를 인코딩한다.null
문자열(유형 2 및 3)
타입 2와 타입 3은 페이로드의 길이를 바이트 단위로 인코딩하는 카운트 필드를 가지고 있다.유형 2는 구조화되지 않은 바이트 문자열이다.유형 3은 UTF-8 텍스트 문자열이다.null
31의 짧은 카운트는 무한 길이의 문자열을 나타낸다.이 다음에는 "break" 마커 바이트로 종료된 동일한 유형의 0개 이상의 한정된 길이의 문자열이 뒤따른다.항목의 가치는 동봉된 항목의 값을 결합한 것이다.다른 유형 또는 중첩된 무한 길이 문자열의 항목은 허용되지 않는다.텍스트 문자열은 개별적으로 잘 형성되어야 하며 UTF-8 문자는 항목 간에 분할할 수 없다.null
배열 및 지도(유형 4 및 5)
유형 4에는 다음 항목 수를 인코딩하는 카운트 필드가 있고, 그 다음 항목이 많다.이 항목들이 모두 같은 유형이 될 필요는 없다; 일부 프로그래밍 언어들은 이것을 "어레이"가 아니라 "투플"이라고 부른다.null
또는 짧은 카운트가 31인 무한 길이 인코딩을 사용할 수 있다.이것은 255의 "차단" 마커 바이트까지 계속된다.내포된 항목도 무한 인코딩을 사용할 수 있기 때문에 파서는 브레이크 마커를 해당 무한 길이 헤더 바이트와 쌍을 이루어야 한다.null
유형 5는 유사하지만 키/값 쌍의 지도(사전 또는 연관 배열이라고도 함)를 인코딩한다.이 경우 카운트는 항목 쌍의 수를 인코딩한다.무한 길이 인코딩을 사용할 경우, "break" 마커 바이트 이전에 짝수 수의 항목이 있어야 한다.null
의미 태그(유형 6)
의미 태그는 카운트가 값인 또 다른 원자형이지만 페이로드(하나의 추종 항목)도 가지고 있으며, 그 둘은 배열이나 지도와 같은 하나의 항목으로 간주된다.null
태그 번호는 3비트 전공 타입이 제공할 수 있는 것 이상의 다음 항목에 대한 추가 유형 정보를 제공한다.예를 들어 태그가 1이면 다음 숫자가 Unix 시간 값임을 나타낸다.2의 태그는 다음 바이트 문자열이 부호화되지 않은 비그넘을 인코딩한다는 것을 나타낸다.32의 태그는 다음 텍스트 문자열이 RFC 3986에 정의된 URI임을 나타낸다. RFC 8746은 고정 크기 정수 또는 부동 소수점 값의 균질 배열을 바이트 문자열로 인코딩하기 위해 태그 64–87을 정의한다.null
55799 태그는 "CBOR 데이터가 뒤따른다"는 의미에 할당된다.이것은 의미론적 no-op이지만 해당 태그 바이트를 허용한다.d9 d9 f7CBOR 파일의 의미에 영향을 주지 않고 CBOR 파일로 확장됨.이 바이트들은 CBOR 데이터의 시작을 구별하기 위해 "마법 번호"로 사용될 수 있다.null
모든 원 태그 값 0xffffff, 0xffffffffffff 및 0xffffffffffffff는 CBOR 디코딩 라이브러리에 태그가 없음을 나타내기 위해 예약되어 있으므로 데이터 스트림에 절대 나타나지 않아야 한다.null
브레이크 마커 의사-항목은 태그의 페이로드가 아닐 수 있다.null
특수/플로트(유형 7)
이 주요 유형은 다른 범주에 맞지 않는 다양한 특수 값을 인코딩하는 데 사용된다.다른 원자형(0, 1, 6)과 같은 인코딩 크기 규칙을 따르지만, 계수 필드는 다르게 해석된다.null
20-23 값은 false, true, null 및 정의되지 않은 특수 값을 인코딩하는 데 사용된다.값 0~19는 현재 정의되어 있지 않다.null
24의 짧은 카운트는 추가 특수 값을 인코딩하는 데 사용될 수 있는 1바이트 확장 카운트가 뒤따른다는 것을 의미한다.디코딩을 단순화하기 위해 0~31 값은 이 형식으로 인코딩되지 않을 수 있다.32~255의 값 중 현재 정의된 것은 없다.null
25, 26 또는 27의 짧은 카운트는 다음과 같은 확장 카운트 필드를 (빅엔디안) 16, 32 또는 64비트 IEEE 부동소수 값으로 해석해야 함을 나타낸다.이것들은 확장된 카운트와 같은 크기지만 다르게 해석된다.특히 다른 모든 주요 유형의 경우 2바이트 확장 카운트 0x1234와 4바이트 확장 카운트 0x00001234가 정확히 동일하다.부동 소수점 값은 그렇지 않다.null
쇼트카운트 28~30은 다른 모든 주요 유형과 마찬가지로 유보적이다.null
31의 짧은 카운트는 비한정 길이의 인코딩을 종료하는 특수 "브레이크" 마커를 인코딩한다.이는 31의 짧은 카운트가 무제한 길이 인코딩을 시작하는 다른 주요 유형과 관련되지만 이와는 다르다.이것은 항목이 아니며 정의된 길이의 페이로드에 나타나지 않을 수 있다.null
의미 태그 등록
IANA는 https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml에 위치한 CBOR 태그 레지스트리를 만들었다. 등록에는 이러한 템플릿이 포함되어야 한다.null
| 의미 태그 유형 | 범위 | 템플릿 | |||
|---|---|---|---|---|---|
| 데이터 항목 | 의미 설명(짧은 형식) | 접촉점 | 의미론(URL) 설명 | ||
| 표준 동작 | 0–23 | 필수의 | 필수의 | 해당 없음 | 해당 없음 |
| 필요한 사양 | 24–255 | 필수의 | 필수의 | 해당 없음 | 해당 없음 |
| 먼저 온 사람에게 우선권이 주어진다. | 256–18446744073709551615 | 필수의 | 필수의 | 필수의 | 설명은 선택 사항이다.null URL은 인터넷-대안 또는 웹 페이지를 가리킬 수 있다.null |
https://www.rfc-editor.org/rfc/rfc8949.html#name-cbor-tags-registry
구현
참고 항목
참조
- ^ "CBOR — Concise Binary Object Representation Overview".
- ^ "CoAP — Constrained Application Protocol Overview".
- ^ "FIDO2 Project". FIDO Alliance. Retrieved 2018-05-11.
- ^ "Discussions on the upcoming MessagePack spec that adds the string type to the protocol". Retrieved 2022-01-04.
- ^ "RFC 8949: Concise Binary Object Representation (CBOR)". IETF. December 2020.
