JSON 문자열의 이진 데이터. Base64보다 나은 것

JSON 형식은 기본적으로 바이너리 데이터를 지원하지 않습니다. 바이너리 데이터는 JSON에서 문자열 요소 (백 슬래시 이스케이프를 사용하여 큰 따옴표로 묶은 0 개 이상의 유니 코드 문자)에 배치 될 수 있도록 이스케이프되어야합니다.

이진 데이터를 이스케이프 처리하는 확실한 방법은 Base64를 사용하는 것입니다. 그러나 Base64는 처리 오버 헤드가 높습니다. 또한 3 바이트를 4 자로 확장하여 데이터 크기를 약 33 % 증가시킵니다.

이에 대한 한 가지 사용 사례는 CDMI 클라우드 스토리지 API 사양 의 v0.8 초안입니다 . JSON을 사용하여 REST-Webservice를 통해 데이터 객체를 생성합니다.

PUT /MyContainer/BinaryObject HTTP/1.1
Host: cloud.example.com
Accept: application/vnd.org.snia.cdmi.dataobject+json
Content-Type: application/vnd.org.snia.cdmi.dataobject+json
X-CDMI-Specification-Version: 1.0
{
    "mimetype" : "application/octet-stream",
    "metadata" : [ ],
    "value" :   "TWFuIGlzIGRpc3Rpbmd1aXNoZWQsIG5vdCBvbmx5IGJ5IGhpcyByZWFzb24sIGJ1dCBieSB0aGlz
    IHNpbmd1bGFyIHBhc3Npb24gZnJvbSBvdGhlciBhbmltYWxzLCB3aGljaCBpcyBhIGx1c3Qgb2Yg
    dGhlIG1pbmQsIHRoYXQgYnkgYSBwZXJzZXZlcmFuY2Ugb2YgZGVsaWdodCBpbiB0aGUgY29udGlu
    dWVkIGFuZCBpbmRlZmF0aWdhYmxlIGdlbmVyYXRpb24gb2Yga25vd2xlZGdlLCBleGNlZWRzIHRo
    ZSBzaG9ydCB2ZWhlbWVuY2Ugb2YgYW55IGNhcm5hbCBwbGVhc3VyZS4=",
}

이진 데이터를 JSON 문자열로 인코딩하는 더 좋은 방법과 표준 방법이 있습니까?

JSON 사양에 따라 1 바이트로 표시 될 수있는 94 개의 유니 코드 문자가 있습니다 (JSON이 UTF-8로 전송 된 경우). 이를 염두에두고 공간적으로 할 수있는 최선의 방법 은 4 바이트를 5 문자로 나타내는 base85 입니다. 그러나 이것은 base64에 비해 7 % 개선 된 것이며 계산 비용이 더 비싸며 base64보다 구현이 덜 일반적이므로 승리하지 않을 것입니다.

모든 입력 바이트를 U + 0000-U + 00FF의 해당 문자에 간단히 매핑 한 다음 JSON 표준에 필요한 최소 인코딩을 수행하여 해당 문자를 전달할 수도 있습니다. 여기서 장점은 필요한 디코딩이 내장 함수를 능가하는 것이 아니라 공간 효율성이 나쁘다는 것입니다 .105 % 확장 (모든 입력 바이트가 동일 할 가능성이있는 경우) 대 base85의 경우 25 % 또는 base64의 경우 33 %입니다.

최종 판결 : base64는 대체적 으로 보증 하기에 충분 하고 일반적이며 쉽고, 나쁘지 않다는 근거에서 승리 합니다.

참조 : Base91 및 Base122

같은 문제가 발생하여 multipart / form-data 라는 솔루션을 공유한다고 생각했습니다 .

여러 부분으로 된 양식을 보내면 먼저 JSON 메타 데이터 를 문자열로 보낸 다음 Content-Disposition 이름으로 인덱싱 된 원시 이진 (이미지, wav 등)으로 별도로 보냅니다 .

다음 은 obj-c 에서이 작업을 수행하는 방법에 대한 유용한 자습서 이며 문자열 데이터를 양식 경계로 분할하고 이진 데이터와 구분하는 방법을 설명하는 블로그 기사 입니다.

실제로해야 할 유일한 변경 사항은 서버 쪽입니다. POST의 바이너리 데이터를 적절하게 참조 해야하는 메타 데이터를 캡처해야합니다 (Content-Disposition 경계를 사용하여).

서버 측에서 추가 작업이 필요하지만 많은 이미지 또는 큰 이미지를 보내는 경우 그만한 가치가 있습니다. 원하는 경우 이것을 gzip 압축과 결합하십시오.

base64로 인코딩 된 데이터를 보내는 IMHO는 해킹입니다. RFC multipart / form-data는 텍스트 또는 메타 데이터와 함께 이진 데이터를 보내는 것과 같은 문제를 위해 만들어졌습니다.

UTF-8의 문제점은 공간 효율적인 인코딩이 아니라는 것입니다. 또한 일부 임의의 이진 바이트 시퀀스는 잘못된 UTF-8 인코딩입니다. 따라서 임의의 이진 바이트 시퀀스를 UTF-8 데이터로 해석 할 수는 없습니다. UTF-8 인코딩이 유효하지 않기 때문입니다. UTF-8 인코딩에 대한 이러한 제약의 이점은 견고하고 멀티 바이트 문자를 찾아서 시작하는 모든 바이트를 찾고 종료 할 수 있다는 것입니다.

결과적으로 [0..127] 범위의 바이트 값을 UTF-8 인코딩으로 인코딩하는 데 1 바이트 만 필요한 경우 [128..255] 범위의 바이트 값을 인코딩하면 2 바이트가 필요합니다! 그보다 더 나쁘다. JSON에서 제어 문자 "및 \는 문자열에 표시 할 수 없으므로 이진 데이터를 올바르게 인코딩하려면 일부 변환이 필요합니다.

보자. 바이너리 데이터에 균일하게 분포 된 랜덤 바이트 값을 가정하면 평균적으로 바이트의 절반이 1 바이트로 인코딩되고 나머지 절반은 2 바이트로 인코딩됩니다. UTF-8로 인코딩 된 이진 데이터의 초기 크기는 150 %입니다.

Base64 인코딩은 초기 크기의 133 %로만 증가합니다. 따라서 Base64 인코딩이 더 효율적입니다.

다른 Base 인코딩을 사용하는 것은 어떻습니까? UTF-8에서는 128 ASCII 값을 인코딩하는 것이 가장 공간 효율적입니다. 8 비트에서는 7 비트를 저장할 수 있습니다. 따라서 바이너리 데이터를 7 비트 청크로 잘라 UTF-8 인코딩 문자열의 각 바이트에 저장하면 인코딩 된 데이터는 초기 크기의 114 %로만 커집니다. Base64보다 낫습니다. 불행히도 JSON은 ASCII 문자를 허용하지 않기 때문에이 쉬운 트릭을 사용할 수 없습니다. ASCII의 33 개 제어 문자 ([0..31] 및 127)와 "및 \는 제외해야합니다.이 경우 128-35 = 93 자만 남습니다.

이론적으로 우리는 인코딩 된 크기를 8 / log2 (93) = 8 * log10 (2) / log10 (93) = 122 %로 증가시키는 Base93 인코딩을 정의 할 수 있습니다. 그러나 Base93 인코딩은 Base64 인코딩만큼 편리하지 않습니다. Base64는 간단한 비트 단위 연산이 잘 작동하는 입력 바이트 시퀀스를 6 비트 청크로 잘라 내야합니다. 133 % 외에는 122 %를 넘지 않습니다.

그렇기 때문에 Base64가 바이너리 데이터를 JSON으로 인코딩하는 가장 좋은 선택이라는 일반적인 결론에 독립적으로 도달했습니다. 내 대답은 그것에 대한 정당성을 제시합니다. 성능 측면에서 그다지 매력적이지는 않지만 모든 프로그래밍 언어에서 조작하기 쉬운 사람이 읽을 수있는 문자열 표현으로 JSON을 사용하는 이점도 고려하십시오.

순수한 이진 인코딩보다 성능이 중요한 경우 JSON을 대체하는 것으로 간주해야합니다. 그러나 JSON을 사용하면 Base64가 가장 좋습니다.

BSON (Binary JSON)이 도움이 될 수 있습니다. http://en.wikipedia.org/wiki/BSON

편집 : 참고로 .NET 라이브러리 json.net 은 C # 서버 쪽 사랑을 찾고 있다면 bson 읽기 및 쓰기를 지원합니다.

대역폭 문제를 해결하려면 먼저 클라이언트 측에서 데이터를 압축 한 다음 base64-it로 압축하십시오.

이러한 마술의 좋은 예는 http://jszip.stuartk.co.uk/ 에 있으며이 주제에 대한 자세한 설명 은 Gzip의 JavaScript 구현에 있습니다.

yEnc가 당신을 위해 일할 수 있습니다 :

http://en.wikipedia.org/wiki/Yenc

"yEnc는 [텍스트]로 이진 파일을 전송하기위한 이진-텍스트 인코딩 체계입니다. 8 비트 확장 ASCII 인코딩 방법을 사용하여 이전 US-ASCII 기반 인코딩 방법보다 오버 헤드를 줄입니다. yEnc의 오버 헤드는 종종 uuencode 및 Base64와 같은 6 비트 인코딩 방법의 33 % –40 % 오버 헤드와 비교할 때 각 바이트 값은 평균적으로 거의 동일한 빈도로 1 ~ 2 %로 나타납니다. ... 2003 년까지 yEnc는 사실상 표준이되었습니다. Usenet의 바이너리 파일 인코딩 시스템. "

그러나 yEnc는 8 비트 인코딩이므로 JSON 문자열에 저장하면 원래 이진 데이터를 저장하는 것과 동일한 문제가 있습니다. 순진한 방법은 약 100 % 확장을 의미하므로 base64보다 나쁩니다.

base64의 확장 률이 ~ 33 % 인 것은 사실이지만 처리 오버 헤드가 이보다 훨씬 높다는 것은 아닙니다. 실제로 사용중인 JSON 라이브러리 / 툴킷에 따라 다릅니다. 인코딩 및 디코딩은 간단한 작업이며 JSON 문자 인코딩 (JSON이 UTF-8 / 16 / 32 만 지원)으로 최적화 할 수 있습니다. base64 문자는 항상 JSON 문자열 항목의 단일 바이트입니다. 예를 들어 Java 플랫폼에는 작업을보다 효율적으로 수행 할 수있는 라이브러리가 있으므로 오버 헤드는 주로 확장 된 크기 때문입니다.

나는 두 가지 이전 답변에 동의합니다.

• base64는 간단하고 일반적으로 사용되는 표준이므로 JSON과 함께 사용하기에 더 나은 것을 찾을 수는 없습니다 (base-85는 포스트 스크립트 등에서 사용되지만 이점에 대해서는 생각할 때 이점이 거의 없습니다)
• 인코딩 전 (및 디코딩 후) 압축은 사용하는 데이터에 따라 많은 의미가있을 수 있습니다.

스마일 형식

인코딩, 디코딩 및 압축이 매우 빠릅니다.

속도 비교 (자바 기반이지만 의미가 있음) : https://github.com/eishay/jvm-serializers/wiki/

또한 바이트 배열의 base64 인코딩을 건너 뛸 수있는 JSON의 확장입니다.

공간이 중요한 경우 스마일 인코딩 문자열을 압축 할 수 있음

( 7 년 후 수정 : Google Gears가 사라졌습니다.이 답변은 무시하십시오.)

Google Gears 팀은 이진 데이터 형식 부족 문제에 부딪 쳤으며이를 해결하려고 시도했습니다.

Blob API

JavaScript에는 텍스트 문자열에 대한 데이터 형식이 내장되어 있지만 이진 데이터에는 없습니다. Blob 개체는이 제한을 해결하려고합니다.

어쩌면 당신은 그것을 어떻게 든 짜낼 수 있습니다.

바이너리 데이터를 텍스트 기반의 매우 제한된 형식으로 변형시키는 기능을 찾고 있기 때문에 Base64의 오버 헤드는 JSON으로 유지 관리 해야하는 편의성과 비교할 때 최소입니다. 처리 능력과 처리량이 중요한 경우 파일 형식을 재고해야합니다.

토론에 리소스와 복잡성 관점을 추가하기 만하면됩니다. 새로운 자원을 저장하고 변경하기 위해 PUT / POST 및 PATCH를 수행하기 때문에 컨텐츠 전송은 저장되고 GET 조작을 실행하여 수신되는 컨텐츠의 정확한 표현임을 기억해야합니다.

여러 부분으로 된 메시지는 종종 구세주로 사용되지만 단순성 이유와 더 복잡한 작업을 위해 콘텐츠 전체를 제공하는 아이디어를 선호합니다. 그것은 스스로 설명하고 간단합니다.

그리고 그렇습니다 .JSON은 끔찍한 것이지만 결국 JSON 자체는 장황합니다. 그리고 BASE64에 대한 매핑 오버 헤드는 작습니다.

멀티 파트 메시지를 올바르게 사용하려면 전송할 객체를 해체하거나 속성 경로를 자동 조합을위한 매개 변수 이름으로 사용하거나 페이로드를 표현하기 위해 다른 프로토콜 / 포맷을 만들어야합니다.

또한 BSON 접근 방식을 좋아하므로 원하는대로 광범위하고 쉽게 지원되지 않습니다.

기본적으로 우리는 여기서 뭔가를 놓쳤지만 base64가 잘 구축되어 바이너리 바이너리를 포함시키는 것은 실제로 바이너리 전송을 수행해야 할 필요성을 실제로 확인하지 않는 한 갈 길이 멀다.

나는 (의 구현 동안 조금 더 파고 base128 ), 그리고 노출 우리가 아스키 코드는 두 개의 문자 (바이트) 사실 보내기 128 다음 브라우저 (크롬)보다 큰 문자 대신 하나를 :( 보낼 때 . 그 이유가 있다는 것입니다 JSON 에 의해 언급 무엇인지 두 바이트로 코딩 127 위 아스키 코드로 된 문자가 기본으로 사용 UTF8 문자로 chmike의 . 대답 나는이 방법으로 테스트를했다 : 유형을 크롬 URL 표시 줄에 크롬 : // 넷 - 수출 / 선택 "원시 포함 bytes ", 캡처 시작, POST 요청 전송 (맨 아래 스 니펫 사용), 캡처 중지 및 원시 요청 데이터로 json 파일 저장. 그런 다음 해당 json 파일 내부를 살펴 봅니다.

• 우리는 문자열을 찾아 우리의 base64로 요청을 찾을 수 있습니다 4142434445464748494a4b4c4d4e이의 코딩 진수이며 ABCDEFGHIJKLMN우리는 그것을 볼 것이다 "byte_count": 639그것을.
• 우리는 위의 요청을 찾을 수 있습니다. C2BCC2BDC380C381C382C383C384C385C386C387C388C389C38AC38B이 문자열 은 request-hex utf8 문자 코드입니다 ¼½ÀÁÂÃÄÅÆÇÈÉÊË(그러나이 문자 의 ASCII 16 진수 코드는 c1c2c3c4c5c6c7c8c9cacbcccdce). 따라서 "byte_count": 703ASCII 코드가 127보다 큰 문자는 요청에서 2 바이트 씩 코드화되므로 base64 요청보다 64 바이트 더 깁니다. (

실제로 우리는 코드가 127보다 큰 문자를 보내는 것으로 이익을 얻지 못합니다. lex 응답에 설명 된 POST multipart / form-data의 이진 부분으로 데이터 보내기 (그러나이 경우 일반적으로 기본 코딩을 전혀 사용할 필요가 없습니다 ...)

대체 방법은 base65280 / base65k 와 같은 코드를 사용하여 2 바이트 데이터 부분을 하나의 유효한 utf8 문자로 매핑하여 의존 할 수 있지만 utf8 사양 으로 인해 base64보다 덜 효과적입니다 ...

function postBase64() {
  let formData = new FormData();
  let req = new XMLHttpRequest();

  formData.append("base64ch", "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/");
  req.open("POST", '/testBase64ch');
  req.send(formData);
}


function postAbove127() {
  let formData = new FormData();
  let req = new XMLHttpRequest();

  formData.append("above127", "¼½ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö÷øùúûüý");
  req.open("POST", '/testAbove127');
  req.send(formData);
}

<button onclick=postBase64()>POST base64 chars</button>
<button onclick=postAbove127()>POST chars with codes>127</button>

데이터 유형은 실제로 우려됩니다. RESTful 리소스에서 페이로드를 전송하는 다양한 시나리오를 테스트했습니다. 인코딩에는 Base64 (Apache)와 압축 GZIP (java.utils.zip. *)를 사용했습니다. 페이로드에는 필름, 이미지 및 오디오 파일에 대한 정보가 포함되어 있습니다. 이미지와 오디오 파일을 압축하고 인코딩하여 성능이 크게 저하되었습니다. 압축하기 전에 인코딩이 잘 이루어졌습니다. 이미지 및 오디오 컨텐츠는 인코딩 된 바이트 및 압축 된 바이트 []로 전송되었습니다.

참조 : http://snia.org/sites/default/files/Multi-part%20MIME%20Extension%20v1.0g.pdf

이진 데이터의 base64 변환없이 'CDMI content type'작업을 사용하여 CDMI 클라이언트와 서버간에 이진 데이터를 전송하는 방법을 설명합니다.

'비 CDMI 컨텐츠 유형'조작을 사용할 수있는 경우 오브젝트와 데이터를 전송하는 것이 이상적입니다. 그런 다음 후속 'CDMI 콘텐츠 형식'작업으로 메타 데이터를 개체에 추가하거나 개체에서 검색 할 수 있습니다.

내 솔루션은 이제 XHR2가 ArrayBuffer를 사용하고 있습니다. 이진 시퀀스로서의 ArrayBuffer는 여러 컨텐츠 유형을 갖는 멀티 파트 컨텐츠, 비디오, 오디오, 그래픽, 텍스트 등을 포함합니다. 하나의 응답으로 모두.

최신 브라우저에서는 다른 구성 요소에 대해 DataView, StringView 및 Blob이 있습니다. 자세한 내용은 http://rolfrost.de/video.html 을 참조하십시오.