linuxism

Multipurpose Internet Mail Extension ( 다목적 인터넷 메일 확장 )은 규격에 US-ASCII 의 텍스트 밖에 사용할 수없는 인터넷 의 전자 우편에서 다양한 포맷 (형식)을 사용할 수 있도록하는 규격이다. 일반적으로 MIME (마임)로 축약된다. RFC 2045 , RFC 2046 , RFC 2047 , RFC 4288 , RFC 4289 ^[1] , RFC 2049 에 규정되어있다.

인터넷 메일 형식을 정하고있는 RFC 5322 (구 RFC 822 , RFC 2822 )는 영숫자 및 일부 기호를 7 비트로 표현한다 "US-ASCII"라는 문자 코드를 사용하여 한 줄에 1000 바이트 (줄바꿈 포함) 텍스트 데이 터만 허용하지 않는다. 따라서 규격에 부적합되도록 긴 라인, US-ASCII만으로 표현할 수없는 문자 또는 이진 데이터 , 이미지 , 오디오 등의 문자가 아닌 데이터를 사용할 수 없었다.

MIME은 이러한 데이터를 처리하는 데 새로운 몇 가지 헤더를 정의하며 US-ASCII에서 다양한 데이터 타입을 표현하기위한 인코딩 방식 을 규정하고있다.

RFC 5322 (구 RFC 822 , RFC 2822 )에서는 1 통의 메일 하나의 본문 밖에 처리할 수 없지만, MIME에서는 본문을 분할하여 여러 콘텐츠를 처리할 수 있도록했다. 이것을 여러 부분이라고 부른다. MIME 헤더에 MIME 메시지 헤더와 MIME 파트 헤더의 두 가지가있다. MIME 메시지 헤더는 메시지 전체에 적용되고 MIME 파트 헤더는 multipart 메시지의 각 부분에 적용된다.

또한 HTTP 의 데이터 전송에 대해서도 MIME 구조가 원용되고있다.

MIME에서 도입된 헤더 [ 편집 ]

MIME-Version [ 편집 ]

기존의 RFC 5322 ( RFC 822 , RFC 2822 ) 기반의 메시지와 구분하거나 미래 MIME 확장 때 버전을 구별하기위한 헤더. 현재는 1.0만이 규정되어있다.

Mime-Version : 1.0

Content-Type [ 편집 ]

이 메시지의 데이터 유형을 지정합니다. 일반적인 형식은 다음과 같다.

Content-Type : type / subtype ; parameter

type 은 "text"(텍스트), "image"(이미지), "audio"(음성) "video"(동영상) "application"(응용 프로그램 고유의 포맷) 등을 사용하여 데이터 자체 형식을 지정할 수 있으며, "message", "multipart"을 지정하여 하나의 MIME 메시지에 또 다른 MIME 메시지를 지정할 수도있다.

subtype 에는 type 에 대한 자세한 형식을 지정한다. 다음과 같은 것이 흔히 사용된다.

• text / plain ( 일반 텍스트 )
• text / html ( HTML 텍스트)
• application / xhtml + xml ( XHTML 텍스트)
• image / gif ( GIF 이미지)
• image / jpeg ( JPEG 이미지)
• image / png ( PNG 이미지)
• video / mpeg ( MPEG 동영상)
• application / octet-stream (임의의 이진 데이터)
• application / pdf ( PDF 문서)
• message/rfc822 ( RFC 822 형식)
• multipart / alternative (HTML 메일의 HTML 및 일반 텍스트처럼 같은 정보를 다른 형식으로 나타 멀티 파트)
• application / x-www-form-urlencoded ( HTTP 의 POST 메소드에 의한 양식 데이터 전송)
• multipart / form-data (저도 주로 파일 업로드를 수반하는 경우)

또한 정식적인 subtype 이 부여되지 않은 데이터 형식은 x-로 시작하는 독자적인 명칭을 사용할 수있다 (예 : application / x-gzip). 또한 vnd.로 시작 벤더 고유의 명칭을 사용할 수도있다 (예 : application / vnd.ms-excel).

parameter 추가 정보를 제공한다. 자주 사용되는 것으로, text / plain과 text / html의 문자 코드 계를 명기 charset 매개 변수가있다.

type 에 따라 기본 subtype 이 규정되어 있으며, 수신자는 자신이 다룰 수없는 subtype 도 기본 subtype 으로 처리함으로써 최소한의 취급이 가능해진다. text의 기본값은 text / plain, application의 기본값은 application / octet-stream, multipart 기본은 multipart / mixed이다.

Content-Transfer-Encoding [ 편집 ]

MIME는 US-ASCII뿐만 아니라 데이터의 다양한 엔코딩 지정이 헤더 허용되고있다. 형식은 다음과 같다.

Content-Transfer-Encoding : mechanism

mechanism 으로 "7bit", "8bit", "binary", "quoted-printable", "base64"가있다. 일반적으로 이용할 수있는 것은 "7bit", "quoted-printable", "base64"이며, "8bit", "binary"일정한 조건을 충족하는 경우에만 사용할 수 없습니다.

7bit [ 편집 ]

기본값입니다. 7 비트 텍스트를 나타낸다. Content-Transfer-Encoding 헤더 필드를 지정하지 않으면이 7bit를 지정하는 것과 같은 의미가된다.US-ASCII 또는 ISO-2022-JP 확실히 7 비트 텍스트이기 때문에 이에 해당한다.

8bit [ 편집 ]

8 비트 텍스트를 나타낸다. RFC 5322 (구 RFC 822 , RFC 2822 )는 7 비트 텍스트를 전제로하고 있으며,이 8bit 의도적으로 위반하는 것이다. 메일을 전송하는 SMTP 는 기본적으로 7 비트 텍스트만 전송할 수 없기 때문에이 인코딩을 사용할 수는 없다. RFC 1652 에 정의된 SMTP 확장 (ESMTP)의 8BITMIME 를 사용하거나, 8 비트를 허용하는 것 같은 완전히 다른 프로토콜을 사용하는 경우에만 이용이 가능하다.

binary [ 편집 ]

데이터가 텍스트가 아닌 바이너리임을 나타낸다. RFC 5322 (구 RFC 822 , RFC 2822 )는 텍스트를 가정하고이 binary 의도적으로 위반하는 것이다. SMTP는 기본적으로 행 단위로 데이터를 처리하는 행 개념조차없는 바이너리는 전송할 수 없습니다. RFC 3030 로 정의되는 ESMTP의 한개이다 BINARYMIME 를 사용하거나, 바이너리를 허용할 같은 완전히 다른 프로토콜을 사용하는 경우에만 이용이 가능하다.

quoted-printable [ 편집 ]

US-ASCII에있는 문자는 그대로 사용하여 존재하지 않는 글자를 '=?'같은 형태로 코딩한다. 여기서?에 문자 코드를 대문자 16 진수로 지정한다.기타 다음과 같은 규칙이있다.

• '='자체 '= 3D'가된다.
• 줄 끝에 공백이있는 경우, 전송 과정에서 손실될 수 있기 때문에 '= 20'로이를 저장한다.
• 인코딩 과정에서 줄 바꿈 (줄 바꿈을 삽입하는 경우) '='줄 바꿈 조합을 넣고 원래 있던 줄바꿈과 구별할 수있게한다.

유럽계의 언어는 많은 문자가 US-ASCII와 동일 부분에 자신의 캐릭터를 사용하는 것이 많다. 이 경우 quoted-printable을 사용하면 US-ASCII는 그대로 문자를 사용하고 있기 때문에 데이터가 거의 커지지 않고, quoted-pritable 인식 프로그램을 사용하지 않고도 대략의 내용을 읽을 수있다는 장점이 있다. 그러나 보통 이진 데이터 또는 Shift JIS 또는 EUC-JP 같은 카나 칸지 같은 비 유럽계 문자 텍스트 데이터 quoted-printable을 적용하면 base64 를 사용한 경우보다 훨씬 데이터가 커진다. " Quoted-printable "를 참조하십시오.

base64 [ 편집 ]

3 옥텟 (24 비트)를 6 비트씩 4 개로 나누고, 각 6 비트 값에 대해 각각 US-ASCII 64 문자 (글자 52 문자, 숫자 10 문자 "+", "/")를 할당 encode 방식. 자세한 내용은 " Base64 "절을 참조하십시오.

이 encode에 의해, SMTP 등 US-ASCII 밖에 허용되지 않은 통신로에서 바이너리 데이터를 교환할 수있는 장점은 있지만, 데이터 용량은 약 33 % 증가한다.

헤더 비 US-ASCII 문자 처리 [ 편집 ]

위 헤더의 소개로, body 부분의 데이터 타입과 encode 방식은 지정할 수 있도록되었지만, 이대로는 헤더 부분은 여전히 US-ASCII 밖에 이용할 수 없다. MIME는 RFC 2047 와 RFC 2231 에 따라 헤더 부분에서 비 US-ASCII 문자의 취급을 규정하고있다. RFC 2047 에 따르면,

=? charset ? encoding ? encoded-text ? =

형식은 문자 코드 계가 charset , 코딩 방법 이 encoding 에서 encoded-text 와 부호화된 단어를 표현할 수있다. charset 은 Content-Type : Text / Plain의 charset 매개 변수에 지정된 것과 같은 IANA 에 등록된 문자열을 사용한다. encoding 은 Q 또는 B (대문자 또는 소문자로 좋다)이며, 전자는 거의 quoted-printable과 같은 코딩 방법, 후자는 base64를 사용하는 것을 나타낸다.

• RFC 2047 에서는 "" "로 둘러싸인 가운데이 같은 부호화된 단어를 해석하는 것은 불가능하다고되어있다. 따라서 ""=? ISO-2022-JP? B? GyRCRnxLXDhsGyhC? = ""은 "=? ISO-2022-JP? B? GyRCRnxLXDhsGyhC? ="로 해석해야하며, 이것을 "일본어"와 해석하는 것은 표준 위반이다. 그러나 Microsoft Outlook Express 와 같은 일부 MUA 이 같은 잘못된 인코딩을 구현하고 그것이 대중 버렸기 때문에 그것을 표준 위반 알아 MUA 저자도 해당 강요 되고있다.

• RFC 2231 는 MIME 매개 변수의 값을 비 US-ASCII 문자를 지정하는 방법을 규정하고있다. 이에 따르면, 첨부 파일 이름과 같은 MIME 매개 변수로 "ISO-2022-JP '% 1B $ BF | K % 5C8l % 1B % 28B"을 "일본어"로 해석할 수있다 ^{[2 ]} . 또한 RFC 5322 에 적합하지 않은 길이의 문자열을 짧게 분할 지정하는 방법도 규정하고있다.

각주 [ 편집 ]

1. ^ 이전 RFC 2048 .
2. ^ "''"는 인용 부호는 아니고, 2 개의 작은 따옴표이다.

관련 항목 [ 편집 ]

• 확장자
• 이메일
• SMTP (Simple Mail Transfer Protocol)
• MHTML (MIME Encapsulation of Aggregate HTML Documents)
• S / MIME (Secure / Multipurpose Internet Mail Extensions)

MIME (Multipurpose Internet Mail Extensions)는 전자우편을 위한 인터넷 표준 포맷이다. 전자우편은 7비트 ASCII 문자를 사용하여 전송되기 때문에, 8비트 이상의 코드를 사용하는 문자나 바이너리 파일들은 MIME 포맷으로 변환되어 SMTP로 전송된다. 실질적으로 SMTP로 전송되는 대부분의 전자우편은 MIME 형식이다. MIME 표준에 정의된 content types은 HTTP와 같은 통신 프로토콜에서 사용되며, 점차 그 중요성이 커지고 있다.

[편집]소개

기본적으로 인터넷 전자우편 전송 프로토콜인 SMTP는 7비트 ASCII 문자만을 지원한다. 이것은 7비트 ASCII 문자로 표현할 수 없는 영어 이외의 언어로 쓰인 전자우편은 제대로 전송될 수 없다는 것을 의미한다. MIME은 ASCII가 아닌 문자 인코딩을 이용해 영어가 아닌 다른 언어로 된 전자우편을 보낼 수 있는 방식을 정의한다. 또한 그림, 음악, 영화, 컴퓨터 프로그램과 같은 8비트 바이너리 파일을 전자우편으로 보낼 수 있도록 한다. MIME은 또한 전자우편과 비슷한 형식의 메시지를 사용하는 HTTP와 같은 통신 프로토콜의 기본 구성 요소이다. 메시지를 MIME 형식으로 변환하는 것은 전자우편 프로그램이나 서버 상에서 자동으로 이루어진다.

전자우편의 기본적인 형식은 RFC 2821에서 정의하고 있다. 이 문서는 RFC 822를 대체한다. 이 문서는 텍스트 전자우편의 헤더와 본문의 형식을 명시하고 있으며, 그중에는 우리에게 익숙한 "To:", "Subject:", "From:", "Date:" 등의 헤더가 포함되어 있다. MIME은 메시지의 종류를 나타내는content-type, 메시지 인코딩 방식을 나타내는 content-transfer-encoding과 같은 추가적인 전자우편 헤더를 정의하고 있다. MIME은 또한ASCII가 아닌 문자를 전자우편 헤더로 사용할 수 있도록 규정하고 있다.

MIME은 확장 가능하다. MIME 표준은 새로운 content-type과 또 다른 MIME 속성 값을 등록할 수 있는 방법을 정의하고 있다.

MIME의 명시적인 목표 중 하나는 기존 전자우편 시스템과의 호환성이다. MIME을 지원하는 클라이언트에서 비 MIME가 제대로 표시될 수 있고, 반대로 MIME을 지원하지 않는 클라이언트에서 간단한 MIME 메시지가 표시될 수 있다.

[편집]MIME 헤더

[편집]MIME-Version

이 헤더는 해당 메시지가 MIME 형식임을 나타낸다. 현재 사용되는 값은 "1.0"이므로 아래와 같이 사용할 수 있다.

MIME-Version: 1.0

[편집]Content-Type

이 헤더는 메시지의 타입과 서브타입을 나타낸다. 예를 들면

Content-Type: text/plain

타입과 서브타입을 합쳐 MIME 타입이라 부른다. Internet media type 이라고도 부른다. 다양한 파일 포맷이 MIME 타입으로 등록되어 있다. text타입은 charset 인자를 가질 수 있으며 이 인자는 문자 인코딩을 지정한다.

content-type 헤더와 MIME 타입은 전자우편을 위해 정의된 것이지만, 이제는 HTTP, SIP와 같은 인터넷 프로토콜에서 함께 사용하고 있다. MIME 타입 등록은 IANA에서 관리하고 있다.

multipart 메시지 타입을 통해 MIME은 트리 구조의 메시지 형식을 정의할 수 있다. 이 방식은 다음을 지원한다.

• text/plain을 통한 단순 텍스트 메시지 ("Content-type:"의 기본값")
• 첨부가 포함된 텍스트 (text/plain 파트와 텍스트가 아닌 파트로 구성된 multipart/mixed). 파일을 첨부한 MIME 메시지는 "Content-disposition:" 헤더를 통해 파일의 본래 이름을 지정한다. 파일의 종류는 MIME의 content-type 헤더와 파일 확장자를 통해 알 수 있다.
• 원본 메시지가 첨부된 답장 메시지 (text/plain 파트와 원본 메시지를 나타내는 message/rfc822 파트로 구성된 multipart/mixed)
• 평문 텍스트와 HTML과 같이 다른 포맷을 함께 보낸 메시지 (multipart/alternative)
• 그 외 다양한 메시지 구조들

[편집]Content-Transfer-Encoding

MIME (RFC 2045)는 바이너리 데이터를 ASCII 텍스트 형식으로 변환하기 위한 몇가지 방법을 정의하고 있다. content-transfer-encoding MIME 헤더를 통해 변환 방식을 지정한다. RFC 문서와 전송 인코딩에 대한 IANA 목록은 다음을 정의하고 있다.

• 일반 SMTP에 사용 가능
  • 7bit - [1..127]의 ASCII 코드로 이루어진 데이터로 줄 단위로 표현하며 각 줄을 CR, LF로 끝난다. 한 줄의 최대 길이는 CR (ASCII 코드 13), LF (ASCII 코드 10)를 제외하고 998자이다.
  • quoted-printable - 약간의 바이너리 데이터가 포함된 US-ASCII로 이루어진 텍스트 데이터를 표현할 때 효과적이다. US-ASCII는 특별한 변환을 거치지 않고 그대로 표시되기에 효율적이며 인코딩한 데이터를 사람이 이해할 수 있다.
  • base64 - 임의의 바이너리 데이터를 7비트 데이터로 변환한다. 고정된 오버헤드가 발생하고 비 텍스트 데이터의 변환 시 사용한다.
• 8BITMIME 지원하는 SMTP 서버에 사용 가능
  • 8bit - 8비트로 표현된 데이터로 한 줄 당 998자로 표현하며 CR, LF로 끝난다.
  • binary - 일련의 octets. SMTP에서는 사용 할 수 없다.

[편집]Encoded-Word

RFC 2822의 정의에 따르면, 메시지 헤더와 그 값은 항상 ASCII 문자를 사용해야 한다. ASCII가 아닌 헤더 값은 MIME의 encoded-word 문법(RFC 2047)에 따라 인코딩해야 한다. 이 문법은 원본 문자 인코딩("문자셋")과 원본 데이터를 ASCII 문자로 변환하는 데 사용한 인코딩 방식을 포함한다.

encoded-word의 형식: "=?문자셋?인코딩 방식?인코드된 데이터?=".

• 문자셋은 보통 utf-8을 사용한다. 하지만 IANA에 등록된 어떤 문자셋도 사용 가능하다.
• 인코딩 방식은 quoted-printable 인코딩 방식과 비슷한 Q-encoding 방식을 나타내는 "Q"나 base64 인코딩을 나타내는 "B" 중 하나를 사용할 수 있다.
• 인코드된 데이터는 인코딩 방식에 의해 변환된 데이터이다.

Q-encoding과 quoted-printable의 차이

RFC 2047에 따르면, encoded-word는 공백 문자(white space)를 포함해서는 안 된다. 따라서 ASCII 코드로 20h(iso-8859-1에서의 스페이스)인 문자는 인코딩을 거쳐야 한다. ASCII 20h(20h가 공백이 아닐지라도)인 문자는 보통 "_" 문자(ASCII 5Fh)로 변환한다. 공백을 "=20"으로 인코딩한 것보다 이 방식이 인코드된 데이터의 가독성을 높여준다.

예를 들어,

Subject: =?utf-8?Q?=C2=A1Hola,_se=C3=B1or!?=

위 문장은 "Subject: ¡Hola, señor!"를 인코딩한 데이터이다.

encoded-word 형식은 헤더 이름에는 사용할 수 없다. 헤더 이름은 항상 US-ASCII로 표현해야 한다.

[편집]Multipart 메시지

MIME multipart 메시지는 "Content-type:" 헤더에 boundary 파라미터를 포함한다. 이 boundary는 다음과 같이 각 메시지 파트를 구분하는 역할을 하며, 메시지의 시작과 끝부분에도 나타난다.

Content-type: multipart/mixed; boundary="frontier"
MIME-version: 1.0

This is a multi-part message in MIME format.
--frontier
Content-type: text/plain

This is the body of the message.
--frontier
Content-type: text/html; encoding=UTF-8
Content-transfer-encoding: base64
  
PGh0bWw+CiAgPGhlYWQ+CiAgPC9oZWFkPgogIDxib2R5PgogICAgPHA+VGhpcyBpcyB0aGUg
Ym9keSBvZiB0aGUgbWVzc2FnZS48L3A+CiAgPC9ib2R5Pgo8L2h0bWw+Cg==
--frontier--

각 파트는 Content-로 시작하는 자신만의 헤더와 본문을 갖는다. 그리고 multipart 메시지는 중첩 가능하다. 각 파트는 자신만의 문자셋과 인코딩 방식(Content-Transfer-Encoding)을 파트 헤더에서 정의하고 있다. Multipart 메시지에는 아래와 같은 종류가 있다.

Notes:

• 첫 번째 boundary 전에 나오는 내용은 MIME을 지원하지 않는 클라이언트를 위해 제공된다. MIME 호환 클라이언트는 이 내용을 무시한다.
• Boundary를 선택하는 것은 전자 우편을 전송하는 클라이언트의 몫이다. 보통 무작위의 문자를 선택함으로써 메시지의 본문과 충돌을 피한다.

[편집]Mixed

Multipart/mixed는 다른 "Content-type" 헤더를 갖는 파일을 전송하는 데 사용한다. 그림이나 쉽게 읽을 수 있는 파일을 전송할 때, 대부분의 전자 우편 클라이언트는 이를 직접 화면에 표시할 것이다. 그렇지 않을 경우 해당 데이터는 첨부 파일의 형태로 표시된다. "Content-disposition" 헤더는 첨부 파일의 이름을 표시하는 데 사용한다.

[편집]Digest

RFC 2049에 명시되어 있듯이 multipart/mixed와 multipart/digest는 최소한 지원해야 할 MIME 타입이다. mixed 파트의 기본 content-type은 text/plain이며, digest의 경우 message/rfc822이다. Multipart/digest는 하나 이상의 메시지를 포워딩 하기 위한 간편한 방법이다.

[편집]Alternative

Multipart/alternative 메시지는 동일한 내용을 다른 형식으로 표현할 때 사용된다. 각각의 파트는 서로 다른 "Content-type" 헤더를 가지며, MIME을 지원하지 않는 클라이언트에서 처리를 쉽게 하고자 표현하기 쉬운 형식에서 복잡한 형식 순으로 메시지에 나타난다. 따라서 메일 클라이언트는 각 파트를 순서대로 검색하여 자신이 표현할 수 있는 마지막 파트를 선택하게 된다. 일부 클라이언트는 이런 순서를 무시한 채 자신이 선호하는 형식을 표시하기도 한다. 일반적으로 오래된 클라이언트를 위해 text/plain 타입의 파트가 먼저 나오고 최신 클라이언트를 위해 text/html 타입의 파트가 나온다.

예전 스팸 방지 필터는 text/html 파트보다 파싱이 쉽다는 이유로 메시지의 text/plain 파트 만을 검사했다. 스패머들은 이러한 점을 악용해 메시지의 text/plain 파트에는 평범한 내용을 넣고 대신 text/html에는 광고를 포함하였다. 이런 방식을 막기 위해 anti-spam 소프트웨어는 multipart/alternative 메시지 중 각 파트가 매우 상이한 내용을 가질 경우 이를 스팸 메시지로 처리하는 식으로 해당 메시지를 걸러낸다.

[편집]Related

Multipart/related는 상호 연관된 여러 개의 파트들로 구성된 메시지이다. 각각의 파트들은 root 타입을 중심으로 내부적으로 연결되며, 각 파트를 참조하기 위해서 일반적으로 파트의 content-ID를 사용한다. Multipart/related의 type 파라미터는 root 파트의 content-type을 지정하며 필수 파라미터이다. Start 파라미터는 root 파트의 content-ID를 지정하며 start 파라미터가 없을 경우에는 가장 먼저 나오는 파트가 root 파트가 된다.

Multipart/related의 사용 예로 이미지가 포함된 HTML 문서를 들 수 있다. 이 경우 root 파트는 HTML 문서가 되며 HTML에 포함된 이미지들은 뒷따르는 파트로 구성하고 HTML 내부에서 이를 참조하는 식으로 표현할 수 있다.

[편집]Report

Multipart/report 메시지는 메일 서버를 위한 형식화된 데이터를 포함한다. 이 메시지 타입은 text/plain과 message/delivery-status로 나뉜다.

[편집]Signed

Multipart/signed 메시지는 본문과 서명 파트를 갖는다. MIME 헤드를 포함하는 본문 파트는 서명을 생성하기 위해 사용된다. Application/pgp-signature, application/x-pkcs7-signature 등의 서명이 사용된다.

[편집]Encrypted

Multipart/encrypted 메시지 타입은 암호화된 application/octet-stream과 이를 풀기 위한 정보를 갖는 제어 파트로 구분된다.

[편집]참조

RFC 1847 

Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted

RFC 2045 

MIME Part One: Format of Internet Message Bodies.

RFC 2046 

MIME Part Two: Media Types. N. Freed, Nathaniel Borenstein. November 1996.

RFC 2047 

MIME Part Three: Message Header Extensions for Non-ASCII Text. Keith Moore. November 1996.

RFC 4288 

MIME Part Four: Media Type Specifications and Registration Procedures.

RFC 4289 

MIME Part Four: Registration Procedures. N. Freed, J. Klensin. December 2005.

RFC 2049 

MIME Part Five: Conformance Criteria and Examples. N. Freed, N. Borenstein. November 1996.

RFC 2231 

MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations. N. Freed, K. Moore. November 1997.

RFC 2387 

The MIME Multipart/Related Content-type

[편집]바깥 고리

• Blog tracking Internet mail related drafts and standards
• List of IANA registered MIME Media Types
• List of Character Sets
• MIME at the Debian Wiki
• A more detailed overview of MIME (1993)

C 표준 라이브러리(C standard library)는 헤더 파일과 라이브러리 루틴이 모여 있는 것으로 C 프로그래밍 언어에서 입출력과 문자열 관리와 같은 일상적인 작업을 추가할 때 사용한다. 코볼, 포트란, PL/I와 같은 언어와 달리, C는 이러한 작업을 위해 키워드를 내장하고 있지 않으므로 거의 모든 C 프로그램들은 표준 라이브러리를 사용하여 기능을 구현한다.

[편집]같이 보기

• GNU C 라이브러리
• C++ 표준 라이브러리
• C 프로그래밍 언어

[편집]외부 고리

• (영어) C 라이브러리

C의 현재 표준안은 1999년에 제정된 ISO/IEC 9899:1999입니다.

그 이전에 흔히들 ANSI C라고 알려져 있던 C의 표준안은 1990년에 공표된 것으로

ISO/IEC 9899:1990이 되겠습니다.

구글에서 ISO IEC 9899로 찾은 결과를 보시면 되겠습니다. PDF문서로 된 것을 보시면

유용할 듯 합니다.

C++표준안 역시 ISO에서 관리하고 있으며, 1998년에 공표된 ISO/IEC 14882:1998이

현재 C++의 표준안입니다.

이 역시 구글에서 ISO IEC 14882로 찾은 결과를 보시면 되겠습니다. 이 역시 PDF문서로 검색된 결고를 보시면 유용할듯 합니다.

C언어는 참으로 많은 성장을 해 왔습니다.

그러는 동안 표준도 "K&R C" -> X2J11 에 의한 ANSI C -> ISO C -> C90 -> C99 처럼 여러가지로 바뀌었고, 같은 표준이더라도 다른 이름을 가지게 되었스비다.

C99는 C 언어의 현대 개정판이다.

[편집]역사

ANSI의 표준화 이후 C 언어 표준이 상대적으로 정적으로 남아 있었던 동안, C++는 표준화를 위하여 계속 진화하고 있었다. 1995년에 1990년의 C 표준에 대한 규약 수정안 1이 출판되었는데, 이는 약간의 세부 사항을 교정하고 국제적 문자 세트에 대한 보다 확장된 지원을 위한 것이었다. C 표준은 1990년대 후반에 더 개정되어, 1999년 ISO/IEC 9899:1999가 출간되었고, 여기서 명시한 규범을 흔히 C99라 부른다. 이는 기술적 교정에 의하여 현재까지 3번의 수정이 있었다. 국제 C 표준은 실무 그룹 ISO/IEC JTC1/SC22/WG14에 의해 관리되고 있다.

[편집]새로운 기능

C99는 다음과 같은 기능들을 포함하고 있다. 이들 중 일부는 이미 일부 컴파일러에 확장 기능으로서 포함된 적이 있다.

• 인라인 함수의 도입
• 변수의 선언은 더이상 파일 범위나 복합 명령어의 시작에서만 할 필요가 없다.
• long long int, 선택적인 확장 정수형, 명시적 불린 자료형, 그리고 복소수를 나타내기 위한 complex 자료형 등 새로운 자료형 도입
• 가변 길이 배열(VLA: variable-length array)

float read_and_process(int n)
{
    float vals[n];
 
    for (int i = 0; i < n; i++)
        vals[i] = read_val();
    return process(vals, n);
}

• BCPL이나 C++와 같은 //로 시작하는 주석들
• snprintf와 같은 새로운 라이브러리 함수
• stdbool.h 및 inttypes.h와 같은 새로운 헤더 파일들
• 자료형에 무관하게 동작하는(type-generic) 수학 함수들 (tgmath.h에 포함)
• IEEE 부동소수점 자료에 대한 개선된 지원
• 지정된 이니셜라이저(designated initializers)
• 복합 리터럴(compound literals)
• 가변 인수 매크로(Variadic macro)의 도입
• 보다 적극적인 코드 최적화를 위한 restrict 한정자

[편집]C90과의 하위 호환성

C99는 대부분의 영역에서 C90과 하위 호환되지만, 일부는 더 엄격해졌다. 특히, 형식 지정자가 빠진 선언을 int 자료형으로 더이상 간주하지 않는다. C 표준 위원회에서는 컴파일러들이 형식 지정자를 실수로 빠뜨린 것을 조용히 넘어가기보다는 문제로서 진단하는 것이 더욱 가치가 있다고 보고 이러한 결정을 내렸다. 실제 컴파일러는 형식 지정자가 빠진 것을 오류로 지적할 가능성이 높지만, int가 지정된 것으로 보고 번역을 계속 할 수도 있다.

[편집]C++와의 호환성

C99 표준의 일부는 TR1이나 C++0x 같은 C++의 제안된 확장에 포함되어 있다. 정수형, 헤더 파일, 라이브러리 함수 등도 제안에 포함되어 있다.

[편집]버전 감지

표준 매크로 __STDC_VERSION__가 199901L로 정의되면 C99 지원이 가능함을 나타낸다. C90에서의 __STDC__ 매크로처럼, __STDC_VERSION__은 C90과 C99간에 다르게 컴파일할 수 있는 코드를 작성하는데 사용할 수 있다.

#if __STDC_VERSION__ >= 199901L
  /* "inline" is a keyword */
#else
# define inline /* nothing */
#endif

[편집]주요 컴파일러들의 지원

GCC 등의 C 컴파일러들은 이제 C99의 새로운 기능들을 대부분 지원한다. 그러나, 마이크로소프트나 볼랜드 등의 업체들은 C99를 별로 지원하지 않았는데, 이는 비슷한 기능 개선이 이미 되어 있는 C++에 치중했기 때문이다.

GCC의 경우, C99의 기능 명세를 상당히 많이 지원하지만(2008년 11월 현재 41개), 아직 완벽한 지원은 아니다. 2008년 11월을 기준으로 9개의 기능들은 제대로 작동하지 않거나 지원되지 않는다.

썬 마이크로시스템즈는 자사의 썬 스튜디오가 C99의 기능들을 완벽히 지원한다고 주장하고 있다.

C의 인터프리터인 Ch도 C99의 주요 기능들을 지원한다.

[편집]바깥 고리

• Final version of the C99 standard with corrigenda TC1, TC2, and TC3 included, formatted as a draftPDF (3.61 MB)
• (영어) New in C9X

C 프로그래밍 언어는 1969년 ~ 1973년에 켄 톰슨과 데니스 리치가 당시 새로 개발된 유닉스 운영 체제에서 사용하기 위해 만든 프로그래밍 언어이다. 켄 톰슨은 BCPL언어를 필요에 맞추어 개조해서 "B"언어(언어를 개발한 벨 연구소의 B를 따서)라 명명했고, 이 B언어에서 C언어가 탄생했다. 유닉스 시스템의 바탕 프로그램은 모두 C로 쓰여졌고, 많은 운영 체제의 커널도 또한 C로 만들어졌다. 오늘날 많이 쓰이는 C++는 C에서 객체 지향형 언어로 발전된 것이다. 또 다른 다양한 최신 언어들도 그 뿌리를 C에 두고 있다.

[편집]소개

C는 실질적으로 모든 컴퓨터 시스템에서 사용할 수 있는 프로그래밍 언어이다. 예를 들어 BASIC 등과는 달리 다양한 플랫폼에서 ANSI C의 정의에 따르는 비교적 동일한 구현이 가능하다. 모든 C 시스템에는 정규화된 표준 C 라이브러리가 존재한다. 이런 이유와 생성된 프로그램의 높은 성능이 아직까지도 C언어가 사랑받는 이유 중 하나이다.

그러나 C 언어가 기술적으로 보아 현재 기술 수준에 부합하지 않는다는 의견이 있으며, C를 "이식가능한 고급 어셈블리어"정도로 낮추어 부르기도 한다. 이는 반면 오늘날의 널리 쓰이는 거의 모든 운영 체제 커널이 C를 이용해 구현된 이유이기도 하다. C는 시스템 프로그램 개발에 매우 적합하나, 응용 프로그램 개발에도 많이 쓰인다.

[편집]역사

• 1963년 - ALGOL 60에서 CPL이 파생
• 1969년 - BCPL 개발
• 1970년 - B언어 개발
• 1972년 - 벨 연구소 (Bell Laboratories) 에 있는 Dennis Ritchie가 B의 후속으로 C 개발
• 1983년 - 미국 국가 표준 협회(ANSI, American National Standards Institute) 에서 짐 브로디(Jim Brodie) 주축으로 X3J11 위원회 소집
• 1983년 12월 14일 - ANSI X3.159-1989 라는 공식명칭으로 C언어 표준 지정
• 1999년 - C99 표준안이 ISO/IEC 9899:1999라는 명칭으로 출간됨
• 2000년 5월 - ANSI의 표준으로 C99가 채택됨

[편집]C99

 이 부분의 본문은 C99입니다.

C 언어 표준이 상대적으로 정적으로 남아 있었던 동안, C++는 표준화를 위하여 계속 진화하고 있었다. 1995년에 1990년의 C 표준에 대한 규약 수정안 1이 출판되었는데, 이는 약간의 세부 사항을 교정하고 국제적 문자 세트에 대한 보다 확장된 지원을 위한 것이었다. C 표준은 1990년대 후반에 더 개정되어, 1999년 ISO/IEC 9899:1999가 출간되었고, 여기서 명시한 규범을 흔히 C99라 부른다. 이는 기술적 교정에 의하여 현재까지 3번의 수정이 있었다. 국제 C 표준은 실무 그룹 ISO/IEC JTC1/SC22/WG14에 의해 관리되고 있다.

[편집]문법

 이 부분의 본문은 C 언어 문법입니다.

[편집]연산자

 이 부분의 본문은 C와 C++ 연산자입니다.

[편집]변수형

 이 부분의 본문은 char입니다.

 이 부분의 본문은 int (C 프로그래밍 언어)입니다.

 이 부분의 본문은 struct입니다.

[편집]포인터

 이 부분의 본문은 포인터 (프로그래밍)입니다.

[편집]메모리 관리

OS에서 응용프로그램을 실행하거나, CPU의 프로그램을 실행하기 위해 여러가지 영역으로 나누어 메모리를 할당하고 이를 메모리에 올려 실행 한다.

• OS: 주로 저장장치에서 실행 파일을 메모리에 올려 실행 한다. 따라서 프로그램에 필요한 메모리는 거의 RAM에 할당하고 실행 한다.
• CPU을 사용한 장치: OS가 없이 개발자가 설정한 메모리 배치에 따라 코드를 ROM/FLASH에 생산할 때 쓰고, 전원 공급시 실행 한다.

C언어로 개발된 프로그램은 메모리 입장에서 다음과 같은 할당 영역으로 나누어 생각할 수 있다.

• 정적 변수: 전역변수난 static을 이용하면 프로그램이 시작할 생성되어 종료될 때 까지 유지 된다.
• 동적 변수: 힙(HEAP)영역을 이용하여 할당 함수를 호출하여 변수 영역을 할당 받아 사용하고, 해제 함수에 의해 반납한다.
• 자동변수: 함수나 블록({ } 이용) 안에서 선언하는 지역변수를 사용하면 스택(STACK) 영역에서 자동 할당을 받는다.

CPU을 사용하여 개발하여 장치에 넣어 코드를 실행할 때, 힙 영역을 많이 사용하지는 않는다. 따라서 필요 없다면 메모리 공간을 할당할 필요도 없고 힙관리 프로그램 코드(함수를 개발툴에서 라이브러리 형태로 제공)도 필요하지 않는다. 만약 malloc 등의 함수를 사용하면, 힙 영역을 사용하겠다는 의미 이기 때문에 힙 영역을 개발자가 선언하여 관리 해야 한다. 이 때 힙관리 프로그램 코드는 자동으로 링크 된다. 물론 저 사양의 CPU 경우, 이 함수를 제공하지 않을 수 있는 컴파일러도 있을 수 있다.

[편집]변수와 메모리 맵

C언어 작성된 코드는 컴파일 과정과 링크 과정을 거치면 실행 파일이 만들어 진다. 변수는 여러가지 특성이 있다.

• 초기치를 갖는 변수
• 초기치가 없는 변수
• 상수 데이터

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <conio.h>
 
int count = 4;
char name[50] = "홍길동";
char tel[256];
 
///////////////////////////////////
 
int getTel(char *pstr)
{
  static char buff[1024];
   gets(buff);
   strcpy(pstr, buff);
   return strlen(pstr);
}
 
int main(int argc, char **argv)
{
  char *paddr;
 
   printf("이름 = %s\n", name);
   getTel(tel); 
   printf("전화 = %s\n", tel);
   paddr = (char*) malloc(1024);
   if (!paddr) 
      return -1;
   {  // 블록 시작
       int scount;
       char *piaddr = paddr;
       for (scount = 1024;scount > count;scount--,piaddr++) {
         *piaddr = getch();  // getch 함수는 표준함수는 아니다.
         putchar(*piaddr);
         if (*piaddr == '\r')
            break;
       }
       *piaddr = 0; 
       printf("주소 = %s\n", paddr);
   } // 블록 끝
 
   free(paddr);
   return 0;
}

이 프로그램 예에서 변수 별로 분리하면 다음과 같은 특성의 변수로 나눌 수 있다.

각 특성별로 나누어 그룹을 지어 메모리에 배치 하는게, 이것을 링커가 한다. 이렇게 그룹을 나누는 것을 SEGMENT 또는 SECTION이라는 단어를 사용 한다.

위의 그룹은 가장 기본적인 내용만을 표시 한것이다. CPU와 컴파일 마다 다르다. 어떤 컴파일러는 더욱 세밀히 하기도 한다. 그리고 각 세그먼트 이름도 다르다.

Visual Studio의 맵 이름 예

컴파일 마다 각 세그먼트 이름과 구조가 다르지만, 예를 들어 중요한 세그먼트 만 표시 하였다, TEXT와 CONST는 ROM/FLASH에 배치 해도 되는 변하지 않는 세그먼트 이므로 같은 부류이고, CPU를 설계하고 코드를 직접 쓰는 경우 ROM/FLASH을 이용한다.

거의 모든 툴에서 이 맵을 파일로 만들어 준다. 물론 옵션으로 설정을 해야하는 경우도 있지만 구조를 얻을 수 있다. 함수와 변수의 위치와 이름 등을 확인할 수 있고, 각각의 세그먼트 크기 등의 데이터를 알 수 있다. 실제 CPU을 다루는 C언어에서 이런 정보는 중요하다. 내가 사용하는 MCU의 메모리는 얼마나 사용하는지 등을 확인할 필요가 있기 때문이다.

[편집]라이브러리

C언어 함수는 표준함수가 있고, 개발 툴에서 제공하는 함수가 있다. 여러가지 부류가 있고 특성 별로 나누어 lib 파일로 코드를 제공하고 헤더파일로 선언을 알 수 있다.

[편집]C 표준 라이브러리

 이 부분의 본문은 C 표준 라이브러리입니다.

C 표준 라이브러리는 함수 형태와 기능이 정해져 있기 때문에 개발툴별 같다는 특징이 있다.

[편집]ISO C 라이브러리 헤더

[편집]개발 도구

[편집]GCC

 GNU 컴파일러 모음 문서를 참고하십시오.

유닉스 계열(리눅스)의 시스템에서 주로 사용하는 C/C++ 언어 개발 도구이다. 리눅스의 OS을 제 컴파일하거나, 각종 응용프로그램 개발에 사용한다. 또한 X-Windows의 개발 도구로도 사용 할 수 있다.

전자 장치의 개발 시 임베디드 OS 포팅에서, 리눅스 커널이나 리눅스 커널 기반으로 하는 OS 커널 자체를 개발하는 도구로 사용 한다. 리눅스 커널 기반 임베디드에서 실행되는 응용 프로그램 역시 gcc을 많이 사용 한다.

[편집]make

 이 부분의 본문은 make (소프트웨어)입니다.

여러 파일들끼리의 의존성과 각 파일에 필요한 명령을 정의함으로써 프로그램을 컴파일할 수 있으며 최종 프로그램을 만들 수 있는 과정을 서술할 수 있는 표준적인 문법을 가지고 있고, 구조로 기술된 파일(주로 Makefile이라는 파일명)을 [[make]가 해석하여 프로그램 빌드를 수행하게 된다.

[편집]Cygwin

 이 부분의 본문은 시그윈입니다.

gcc을 윈도에서 실행 할 수 있도록 재 포팅한 것이다.

[편집]MinGW

Cygwin에서 분화 된 gcc 기반 개발 라이브러리 이다.

[편집]이클립스

 이클립스 문서를 참고하십시오.

이클립스는 다양한 언어와 다양한 OS에서 실행 되는 IDE 이다. 따라서 여러가지 상황에서 다양하게 적용할 수 있다.

[편집]Eclipse IDE for C/C++ Developers

C/C++언어를 제공하는 IDE으로 리눅스의 경우 기존의 gcc을 사용할 수 있도록 연결 설정만 하면 된다.

MinGW

윈도에서 gcc와 연결하여 C/C++ 언어를 사용하여 프로그램을 개발 할 수 있다. MinGW는 다양한 언어를 지원하므로 다른 언어로도 이클립스와 연결하여 개발 도구로 사용할 수 있다.

[편집]비주얼 C++(비주얼 스튜디오 C++)

비주얼 프로그래밍은 크게 윈도 프로그램과 윈도가 아닌 프로그램으로 나누어 생각할 수 있다. 초기의 마이크로소프트의 개발 도구는 C언어로 부터 출발 하였다. 오브젝트 프로그램의 필요성이 대부되면서 C++이 추가 되었다.

윈도 프로그램은 초기에 Win32 SDK을 기반으로 하였다. 오브젝트의 개념없이 함수를 사용하여 윈도 프로그램을 작성 한다. 후에 C++로 가면서MFC로 진화 하였다.

[편집]Win32 Console Application

C/C++의 라이브러리를 이용하여 윈도 없이 실행되는 프로그램을 말 한다. 비주얼 프로그램에서는 C와 C++가 통합 되어 있으므로 C 표준 라이브러리뿐만 아니라 STL 등도 사용할 수 있다.

[편집]Win32 SDK

SDK(Software Development Kit)라는 말은 일반적인 소프트웨어 개발 도구를 나타내는 말이지만 마이크로소프트의 윈도 개발에서는 클래스화 되지 않는 C 라이브러리를 윈도 SDK라고 부르기도 했다. 윈도 개발 도구를 만들 초기에 붙인 이름이다.

이것은 Visual Studio에 통합되어 C 언어의 라이브러리 형태로 개발할 수 있다.

[편집]MFC

 이 부분의 본문은 마이크로소프트 파운데이션 클래스 라이브러리입니다.

윈도 개발에 필요한 각종 윈도 요소를 클래스화 하였다. Win32 SDK도 같이 사용할 수 있다.

[편집]DirectX

윈도에서 주로 게임 등을 개발할 때 사용하는 툴킷 이다. 고속의 화면 제어, 음성지원, 3D 등을 지원한다.

[편집]디버깅

보통 소프트웨어 개발에서 디버깅의 가장 일반적인 방법은 두가지 이다.

1. IDE를 통해 소스 수준에서 디버깅 한다. 일명 'BREAK POINT'를 설정하면 그 위치에서 멈추고 해당 상황을 파악할 수 있다. 가장 중요한 파악 대상이 변수의 값으로 표시 화면에 해당 변수의 형과 맞게 변수의 값을 표시 한다. 또한 줄단위로 실행하기, 함수로 들어가기와 나오기 등 IDE에 따라 구성이 다양하다.
2. 내부 변수나 기타 상황을 printf 형태의 함수를 UART, 네트워크, USB 등과 연결하여 출력함으로써 프로그램 상황을 표시 할 수 있다. 보통 IDE 처럼 다양한 구성이 불가능 할 때 많이 사용 한다.
   1. 리눅스 커널의 경우 printfk 함수로 출력하면 정해진 출력 메시지 파일 형태로 표시할 수 있다.
   2. MCU와 같은 전자장치의 개발에서 개인용 컴퓨터 처럼 성능이 좋은 IDE을 만들기 쉽지 않다. 따라서 저 성능의 IDE을 사용하거나 UART등으로 상황을 출력해서 디버깅 하는 방법을 사용 할 수 있다. 구성이 간단해서 개발 소스에 printf 형의 메시지 출력을 추가하면 된다. 개발자가 직접 해야하는 것이 번거롭다.

[편집]GDB

 이 부분의 본문은 GNU 디버거입니다.

GCC을 기반으로 하는 디버깅 도구이다. 따라서 유닉스 계열에서 가장 일반적으로 실행된다.

[편집]응용 프로그램 디버깅

GCC 옵션을 디버깅이 되도록 설정하면 디버깅 테이블을 만든다. gdb 실행 중에 이것을 사용한다. GDB을 실행하여 응용프로그램을 실행하면서 break, 변수, 함수 등의 디버깅을 할 수 있다.

[편집]원격 디버깅

GCC에서 gdb는 서버 구조를 사용할 수 있다. gdb-server을 설치하면 네트워크를 통해 더버깅 환경을 구성할 수 있다. 예를 들어 임베디드 개발 시 리눅스 커널을 포팅하고, 해당 리눅스 시스템에 gdb-server를 설치하면 다른 환경에서 이를 통해 응용프로그램을 디버깅 할 수 있다. 임베디드의 많은 경우 자신의 시스템에서는 디버깅이 만만히 않다. 따라서 원격으로 gdb의 실행 결과를 전송 할 수 있고 이 정보를 바탕으로 이클립스와 같은 IDE와 연동할 수 있다. 보통 리눅스 기반의 임베디드 개발 환경을 이클립스 C++를 사용할 수 있는데, 이것과 결합할 수 있다.

[편집]커널 디버깅

원격 디버깅 모드는 리눅스 커널에 사용되는 소스 수준의 디버거인 KGDB에서도 사용된다. KGDB를 사용하면 커널 개발자는 일반 응용 프로그램과 마찬가지로 커널을 디버깅할 수 있다.

[편집]IDE 디버깅

비주얼 스튜디오나 이클립스 등의 도구 들은 기본적으로 디버깅 방법을 제시 한다. 이클립스 디버깅은 GDB와 연동해서 구성할 수 있다.

[편집]헬로 월드 프로그램

#include <stdio.h>            // C 표준 라이브러리 중 하나인 stdio.h 라는 헤더 파일에 선언된 내용을 포함한다는 뜻이다.
                              // 이 문장을 쓰지 않으면, printf 함수의 선언을 찾을 수 없다는 컴파일 오류가 발생한다.
int main(void)                // 매개변수가 없는 C 프로그램의 시작을 나타내는 정수값을 반환값으로 받는 main 함수를 시작한다.
{                             // 함수의 시작점을 나타낸다.
    printf("hello, world\n"); // 표준 콘솔 출력에 hello, world라는 단어를 출력하고 \n 에 의해 다음 줄로 이동하게 된다.
    return 0;                 // 0을 반환하며 이 함수를 종료한다.
}                             // 함수의 종료점을 의미한다.

이 프로그램은 표준 콘솔 출력으로 hello, world를 출력한다.

[편집]같이 보기

• B (프로그래밍 언어)
• C99
• C++
• 오브젝티브-C

[편집]바깥 고리

• comp.lang.c FAQ 한국어 번역판
• joinC C언어 소개
• (영어) Ritchie, Dennis M. The Development of the C Language. History of Programming Languages-II. Second History of Programming Languages conference, Cambridge, Massachusetts, April, 1993. ISBN 0-201-89502-1.
• Richard M. Stallman: Using and Porting the GNU Compiler Collection, Free Software Foundation, ISBN 0-595-10035-X
• Richard M. Stallman: Using Gcc: The Gnu Compiler Collection Reference, Free Software Foundation, ISBN 1-882114-39-6
• Brian J. Gough: An Introduction to GCC, Network Theory Ltd., ISBN 0-9541617-9-3