TL; DR

요약; 전송할 이진 (영숫자가 아닌) 데이터 (또는 크기가 큰 페이로드)가있는 경우을 사용하십시오 multipart/form-data. 그렇지 않으면을 사용하십시오 application/x-www-form-urlencoded.

언급 한 MIME 유형 Content-Type은 사용자 에이전트 (브라우저)가 지원해야하는 HTTP POST 요청에 대한 두 개의 헤더입니다. 이 두 가지 유형의 요청의 목적은 이름 / 값 쌍 목록을 서버로 보내는 것입니다. 전송되는 데이터의 유형과 양에 따라 방법 중 하나가 다른 방법보다 효율적입니다. 왜 그런지 이해하려면, 각각이 무엇을하고 있는지 살펴 봐야합니다.

의 경우 application/x-www-form-urlencoded서버로 전송 된 HTTP 메시지 본문은 본질적으로 하나의 거대한 쿼리 문자열입니다. 이름 / 값 쌍은 앰퍼샌드 ( &)로 구분되고 이름은 값과 등호 ( =)로 구분됩니다. 이에 대한 예는 다음과 같습니다. 

MyVariableOne=ValueOne&MyVariableTwo=ValueTwo

사양 에 따르면 :

[예약 및] 영숫자가 아닌 문자는 문자의 ASCII 코드를 나타내는 퍼센트 부호 및 2 개의 16 진수로`% HH ‘로 대체됩니다.

그것은 우리의 값 중 하나에 존재하는 영숫자가 아닌 각 바이트에 대해 그것을 표현하기 위해 3 바이트가 필요하다는 것을 의미합니다. 큰 이진 파일의 경우 페이로드가 3 배가되는 것이 비효율적입니다.

사용자들은 multipart/form-data(다른 응답에 의해 기술 된 바와 같이)에 온다. 이름 / 값 쌍을 전송하는이 방법은, 각각의 쌍은 MIME 메시지의 “일부”로서 표현된다. 부품은 특정 문자열 경계로 구분됩니다 (이 경계 문자열이 “값”페이로드에서 발생하지 않도록 구체적으로 선택). 각 부분에는와 같은 자체 MIME 헤더 세트가 Content-Type있으며 특히 Content-Disposition각 부분에 “이름”을 부여 할 수 있습니다. 각 이름 / 값 쌍의 값 부분은 MIME 메시지의 각 부분의 페이로드입니다. MIME 사양은 값 페이로드를 나타낼 때 더 많은 옵션을 제공합니다. 대역폭을 절약하기 위해 이진 데이터의보다 효율적인 인코딩을 선택할 수 있습니다 (예 : 기본 64 또는 원시 이진).

왜 multipart/form-data항상 사용하지 않습니까? 대부분의 웹 양식과 같은 짧은 영숫자 값의 경우 모든 MIME 헤더를 추가하는 오버 헤드가보다 효율적인 이진 인코딩으로 인한 비용 절감보다 훨씬 클 것입니다.

답변

POST /images
Content-type: multipart/mixed; boundary="xxxx"
... multipart data

201 Created
Location: http://imageserver.org/../foo.jpg

<main-resource>
 ...
 <link href="http://imageserver.org/../foo.jpg"/>
</main-resource>

 public IActionResult Search([FromForm]IFormCollection type)
    {
        return Ok();
    }