로그인

Select the product you need help with

MIME 및 Exchange 2000 Server 및 Exchange Server 2003에 콘텐츠 변환에 대한 질문과 대답

기술 자료: 836555 - 이 문서가 적용되는 제품 보기.

기계 번역 고지 사항 보기

기계 번역된 문서와 영문 원본 문서 나란히 보기

모두 확대 | 모두 축소

요약

이 문서에서는 MIME 표준 및 다른 우편물 시스템을 공동 작업을 가능하게 인코딩 메서드에 대한 질문과 대답을 포함합니다. 이 문서에서는 Microsoft Exchange 환경에서 왜곡되거나 읽을 수 없는 메일 메시지를 해결할 수 있는 방법에 대해서도 간략하게 설명합니다.

위로 가기 | 피드백 보내기

Q1: 전자 메일 메시지의 형식은 무엇입니까?

A1: 인터넷 전자 메일 메시지를 RFC 2822 정의된 형식 표준을 따릅니다. 메시지 헤더 필드와 본문이 구성되어 있습니다. 헤더 필드는 집합적으로 메시지의 "헤더" 이름이 지정됩니다. 메시지 본문에 선택 사항입니다. 메시지 본문이 들어 있지만 않는 헤더 없이 보낼 수 있습니다.

머리글 줄 특수 구문을 있는 문자 시퀀스를 RFC 2822 형식으로 표준 정의한 대로 들어 있습니다. 본문 헤더를 따르고 있는 머리글에서 빈 줄이에 의해 (즉, 캐리지 돌아가기 전에 아무 없습니다 줄) 및 줄 바꿈 [CRLF] 분리되어 있는 문자 시퀀스를 포함합니다.

필드 이름 뒤에 콜론 (:), 필드를 본문에 의해 나오고 CRLF에 의해 종료되었습니다. 구성됩니다 줄 헤더 필드가 있습니다. 필드 이름 인쇄 가능한 US-ASCII 문자 (33 포함 126 사이의 값을 갖는, 문자)를 제외한 콜론 구성될 합니다. 콜론 구분 문자로 사용됩니다.

필드 본문이 있는 CRLF 제외한 모든 US-ASCII 문자 구성될 수 있습니다. 그러나 필드를 본문 머리글 접기 및 unfolding 사용되는 경우 CRLF가 포함될 수 있습니다. 접을 때, 편의를 위해 한 줄을 여러 줄로 표시됩니다. unfolding 이 반대입니다. 모든 필드를 본문을 3 및 4 표준 RFC 2822 형식 섹션에서 설명한 구문을 따라야 합니다.

메시지 본문에 하나 이상의 섹션이 포함될 수 있습니다. 각 본문 구역 경계에 의해 구분됩니다. 경계 매개 변수는 두 개의 하이픈 (-) 로 시작하는 텍스트 문자열입니다.

Q2: MIME 무엇입니까?

A2: MIME 단일 메시지를 다양한 형식의 콘텐츠를 포함하도록 사용되는 표준입니다. MIME 텍스트 및 텍스트가 아닌 여러 콘텐츠를 포함하도록 메일 메시지를 단순 메일 전송 프로토콜 (SMTP) 형식을 확장합니다. 이미지, 오디오, 메시지 부분을 수 없거나 다른 문자 텍스트를 설정합니다. 표준 MIME에서 RFC 2821 및 2822 같은 파생됩니다.

Q3: Exchange 어떻게 처리하지 MIME?

A3: 콘텐츠 변환 수행하는 세 가지 주요 구성 요소를 Exchange 에서 다음과 같습니다.

IMAIL 구성 요소는 인터넷 메시지를 위해 MAPI 변환합니다 핵심 구성 요소입니다/Exchange 형식으로 있으며 반대의 경우도 마찬가지입니다. 또한 메시지 무결성을 확인합니다.
EXMIME 구성 요소를 Exchange의 내부 개체 표현 인터넷 메시지를 변환하는 MIME 형식의 메시지를 생성하는 담당합니다.
RFHTML 구성 요소 (RTF) 메시지를 HTML, Microsoft Outlook 클라이언트 설정과 Exchange Server 컴퓨터의 의하면 또는 그 반대로 변환합니다.

Q4: 설명 MIME 형식의 전자 메일 메시지의 최소 요구 사항은?

A4: 일반적으로 머리글 및 본문 MIME 형식의 전자 메일 메시지가 있습니다. 최소한 MIME 메시지 머리글이 있어야 합니다. 본문 선택 사항입니다. MIME 버전 1.0 머리글 (RFC 2822 정의된 대로 메시지 당 하나) 머리글 구역에 포함됩니다.

본문 구역에 다음과 같습니다.

콘텐츠 형식 (선택적 입니다. 기본 텍스트/일반, RFC 2822 5.2 정의한 것입니다.
콘텐츠 전송 인코딩 헤더 (선택적 입니다. RFC 2822 6.1 정의된 대로 7-비트 기본값입니다.)
내용-처리 헤더 (선택적 입니다.)
한 콘텐츠 ID (선택적 입니다.)

Q5: 버전 MIME 헤더를 무엇입니까?

A5: MIME 형식이 지정된 메시지를 MIME 버전 헤더 필드를 나타냅니다. 이 필드에 MIME을 지원하지 않는 이전 소프트웨어를 통해 전송되는 메시지를 있지 않습니다. 메일 클라이언트가 없으면을 이 필드의 비 MIME 메시지를 구별할 수 있습니다.

Q6: 콘텐츠 형식 헤더는 무엇입니까?

A6: Content-Type 필드 형식 및 데이터 하위 종류 필드를 지정하는 데 사용됩니다.

머리글 형식 중 일부는 multipart/혼합, multipart/대체, 텍스트/일반, text/html, 응용 프로그램/applefile, 응용 프로그램/ms-tnef 및 응용 프로그램/8진수 스트림 있습니다.

Q7: 콘텐츠 전송 인코딩 무엇입니까?

A7: 다른 메일 시스템의 데이터를 다르게 처리하여 일부 이전 메일 시스템의 멀티미디어 데이터를 처리할 수 없습니다.

멀티미디어 데이터를 처리할 수 없는 시스템 주위에 작동하도록 통일된 7-비트 형식으로 데이터를 변환하는 인코딩 체계가 사용됩니다. 받는 사람이 메시지를 받을 때 데이터는 원래 형식으로 복원됩니다. 콘텐츠 전송 인코딩 형식 예는 다음과 같습니다.

따옴표 붙은 인쇄할 수
Base64
8 비트
7-비트
이진

Q8: Exchange 5.5 전송 인코딩 구현 방식?

A8: Exchange 5.5 따옴표 붙은 인쇄할 형식 또는 필요한 만큼 7-비트 형식으로 인코딩합니다. 또한, Exchange 5.5 메시지 25 %8비트 문자 (예: US-ASCII 범위 외부에 있는 문자) 구성되어 있으면 메시지를 base64 형식으로 인코딩합니다. 이 메시지 본문에 대해서만 적용되며 첨부 파일을 Base 64 인코딩 항상 있습니다.

Q9: Exchange 2000 Server 전송 인코딩 구현 방식?

A9: 라우팅 그룹 경계 및 SMTP 대상 대상 Exchange 2000 Server 메일 인코딩하는 방법을 결정합니다. Exchange 2000 따라 따옴표 붙은 인쇄할 수 있고 7-비트 인코딩할 수 또는 전송 중립 캡슐화 서식 (두 명의 서버/받는 서로 다른 라우팅 그룹에 및 인터넷 간에 보낼 때 TNEF).

같은 라우팅 그룹에 있는 받는 사람/서버에 보낼 때 Exchange 2000 Server 이진 또는 요약 TNEF 인코딩합니다.

Q10: Microsoft Exchange Server 2003에서 전송 인코딩 구현 방식?

A10: 라우팅 그룹 경계를 때 Exchange 및 SMTP 대상 대상 Exchange Server 2003 메일 인코딩하는 방법을 결정합니다.

혼합된 모드에서 Exchange Server 2003 같은 따옴표 붙은 인쇄할 또는 7-비트 인코딩합니다 TNEF 형식이 두 서버/받는 서로 다른 라우팅 그룹에 및 인터넷 간에 보낼 때.

전용 모드에서 Exchange Server 2003 바이너리 (요약 TNEF) 보낼 때 받는 사람/서버에 같은 또는 다른 라우팅 그룹에 있는 인코딩합니다.

Q11: 내용-처리 헤더 무엇입니까?

앞에: 이 머리글 구역 첨부 파일로 나타나지 않거나 메시지 본문 여부를 식별합니다.

Q12: Exchange 어떻게 처리하지 첨부 파일을?

A12: Exchange Server 2003 인터넷 메시지는 해당 네이티브 형식으로 저장합니다. Outlook Express 와 같은 인터넷 형식-인식 클라이언트에서 메시지를 읽으면 이러한 원래 형식으로 렌더링되는 것을 의미합니다.

그러나 MAPI 클라이언트에서 메시지를 읽을 때 IMAIL 인터넷 형식으로 해당 요소를 MAPI 속성에 매핑합니다. 사실, 인터넷 메시지가 사서함에 경우에도 전달하기 전에 최소 MAPI 속성 집합을 인터넷 메시지가 승격될 합니다. 그리고 이러한 PR_SENT_REPRESENTING, PR_SUBJECT, 및 받는 사람 테이블에 포함됩니다.

다른 MAPI 속성 PR_BODY, PR_HTML, PR_ATTACH_DATA_BIN 등과 같은 요청 시 인터넷 형식으로 계산됩니다. MAPI 클라이언트가 메시지 처음으로 요청할 때 변환이 발생합니다. 다음 Exchange 2000 Server MAPI 형식으로 이러한 네이티브 MIME 속성을 한 수준 올립니다.

IMAIL은 콘텐츠를-변환하는 동안 Exchange Server 2003에서 인바운드 MIME 메시지를 클라이언트에 렌더링할 때, 다음 작업을 수행합니다.

전체 파일 이름을 IMAIL 확인합니다 (Name. ext) MIME 머리글의. 이름을 찾을 수 없으면 파일 이름이 사용됩니다.
IMAIL 부분 파일 이름을 확인합니다. 하나를 찾을 수 없으면
HKEY_CLASSES_ROOT/MIME/Database/content-type
하위 콘텐츠 형식에 파일 이름 확장명을 매핑하려면 IMAIL이 살펴봅니다. 일치하는 콘텐츠 형식을 찾을 수 없으면 첨부 파일은 해당 확장명이 추가됩니다. 일치하는 콘텐츠 형식을 찾을 수 없으면 부분 파일 이름이 사용됩니다.
콘텐츠 형식 또는 내용-처리 헤더 파일 이름을 지정하면 IMAIL 일치하는 콘텐츠 형식을 검색합니다. 첨부 파일 하나를 찾을 수 없으면 굴림 name 형식을 갖게 됩니다. extext 이 콘텐츠 형식과 연결되어 확장 위치. 일치하는 콘텐츠 형식을 찾을 수 없으면 ".att" 확장명이 사용됩니다. Exchange 2000 Server 콘텐츠 형식 헤더에 있는 파일 이름이 필요합니다.

Q13: 전체 메시지 구조를 무엇입니까?

A13: 다음 전체 메시지로 표시된 모든 머리글 예입니다. 본문 부분은 일반적으로 받는 사람이 볼 수 있습니다. 대괄호 안에 주석은 추가되었습니다.

Received: from SMTP server (server1.example1.com IP address) 

by Receiver SMTP version 1.0 (server2.example2.com IP address); 

Mon, 28 Oct 2002 08:42:42 -0500 (EST)

Message-ID: <006@example1.com>

From: "User1" <user1@example1.com> (RFC 2822 sender) 

To: "User2" user2@example2.com> (RFC 2822 recipient) 

Subject: A test message to see if you can see me now!

Date: Mon, 8 Nov 2002 13:46:54 +0100

MIME-Version: 1.0

Content-Type: multipart/mixed; 
boundary="----=_NextPart_000_005A_01C27E88.79B98A90"

X-Priority: 3

Return-Path: user1@domain1.com

X-OriginalArrivalTime: 28 Oct 2002 13:45:00.0541 (UTC) 
FILETIME=[35F0A2D0:01C27E88]

 

This is a multi-part message in MIME format (If you see this in the message 
body, there is a problem. Notice there is no space or CRLF in the headers in the previous text. There must be no space until the message body itself)

 

This message is in MIME format. Since your mail reader does not understand this 
format, some or all of this message may not be legible. (If you see this in the 
message body, there is a problem)

 

------=_NextPart_000_005A_01C27E88.79B98A90 (Boundary) 

 

Content-Type: text/plain;

charset="iso-8859-1"

Content-Transfer-Encoding: 7bit

 

Can you see me now??! (This is the text of the message. You see this in your mail client.)

 

------=_NextPart_000_005A_01C27E88.79B98A90 (Boundary. See Multipart/Mixed 
definition earlier in this article.) 

Content-Type: image/jpeg;

name="Haloweenpictures.jpg"

Content-Transfer-Encoding: base64 (All attachments in Exchange 2000 Server are encoded by using base64 and bloat 33%.)  

Content-Disposition: attachment;

filename="Haloweenpictures.jpg"

 

/9j/4AAQSkZJRgABAQEBLAEsAAD/2wB/9j/4AAQSkZJRgABAQEBLAEsAAD/2wB  (Base64 data in raw format. This is the picture being encoded in binary format; to 
be repackaged later back as a picture.)

/9j/4AAQSkZJRgABAQEBLAEsAAD/2wB/9j/4AAQSkZJRgABAQEBLAEsAAD/2wB

/9j/4AAQSkZJRgABAQEBLAEsAAD/2wB/9j/4AAQSkZJRgABAQEBLAEsAAD/2wB

------=_NextPart_000_005A_01C27E88.79B98A90--

Q14: 메일 주소를 내 메시지 본문에 나타나지 왜?

A14:메시지 본문 부분에 있는 첫 번째 “ CRLF CRLF ” MIME 스트림의 나타냅니다. 따라서 클라이언트 (Microsoft 또는 Microsoft Outlook Express) 사이에 두 개의 머리글 <CRLF><CRLF>시퀀스 경우 잘못된 메시지를 보여 줍니다.

첫 번째 “ CRLF CRLF ” 메시지 본문에서 인터넷 메시지 머리글을 구분합니다. 이러한 헤더는 P1 헤더는 것으로 알려져 있습니다. P1 헤더를 봉투 머리글 및 IMAIL에 의해 처리되는 인터넷 메시지의 일부가 아닙니다.

스마트 호스트, 콘텐츠 검색 장치, 바이러스 벽 또는 방화벽 Exchange 전달할 수 있습니다. 타사 방화벽 소프트웨어 메시지를 비틀기 경우도 있습니다.

또한 UNIX 시스템, 통해 방화벽 또는 바이러스 벽 통해 전자 메일 메시지를 받을 수 있습니다. 네트워크에 있는 콘텐츠를 검색 타사 장치 수도 있습니다. 유사한 응용 프로그램 또는 장치를 네트워크에 있을 경우 받는 사람 수 제한을 확인하십시오. 이러한 장치 또는 응용 프로그램 진단 테스트를 사용하지 않습니다.

Q15: 내 메시지의 물음표 나타나지 왜?

A15: 메시지에서 물음표가 나타날 경우 시스템 메시지에 있는 일부 ANSI 또는 유니코드 문자를 변환할 방법을 알고 의미합니다. 메시지를 보는 클라이언트가 인바운드 문자 집합에 일치하는 설치된 코드 페이지를 있는지 확인해야 합니다. 예를 들어, Windows 워크스테이션에 일본어 로케일을 일본어에서 작성된 메시지 보기 설치되어 있는지 확인하십시오.

Q16: HTML 메시지를 여는 데 어려움이 권한이 및 내 응용 프로그램 로그에 이벤트를 12002가 및 12003 볼 이유?

A16: 이러한 응용 프로그램 로그 이벤트를 원본 Exchange 정보 저장소, 콘텐츠 변환 오류가 것입니다. 이러한 메시지 중 일부는 무시될 수 있으며 모든 영향을 받은 메시지에 대한 권한이 없습니다. 하지만 많은 응용 프로그램 로그에서 이러한 메시지를 볼 경우, 클라이언트는 HTML 메시지를 열 때 문제가 있으면 참조하십시오.

이 경우 서비스 팩 버전, 응용 프로그램 및 시스템 로그의 복사본 문제가 메시지 복사본 같은 자세한 진단 정보를 설정하고 문제 해결.

Q17: 왜 가끔 메시지 본문을 첨부 파일로 보이지 수행할?

A17: 원본 메시지의 정보를 설정해야 합니다. 원본 서버의 모든 세부 사항을 설정해야 합니다. 보낸 UNIX 네트워크에서 여부를 조사해야 합니다. 이 문제에 대한 자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조하십시오.

323482

(http://support.microsoft.com/kb/323482/ )

Exchange 첨부 파일로 "인라인" MIME 내용-처리 헤더를 사용하여 메시지를 표시하는 예제입니다.

Q18: 왜 내가 보이지 “ 다중 파트 메시지를 MIME 형식을. 입니다 ” 또는 “ 이 메시지 MIME 형식을. 있는 전자 메일 본문에."?

A18: 다음 텍스트 본문 중 에서 하나가 나타날 수 있습니다:

“ 이렇게 여러 부분으로 구성된 MIME 형식의 메시지입니다. ”
“ 이 메시지를 MIME 형식으로 되어 있습니다. 메일 판독기가 이 형식을 이해하는 때문에 이 메시지 전체 또는 일부가 보이지 않을 수 있습니다. ”

이 텍스트는 첫 번째 경계 앞에 삽입된 모든 여러 부분으로 나누어진 메시지 일반적으로 있는지, 전자 메일 형식 문제가 아닌 클라이언트에 표시되지 않습니다. 예를 들어, 하드 줄 바꿈은 메시지에 잘못된 위치에 삽입된 수도 있습니다.

이 문제를 해결하려면 메시지에서 보관 Microsoft Exchange 인터넷 메일 서비스를 해제하십시오. 메시지에 대한 보관을 설정하려면 Exchange Server 2003 보관 싱크 유틸리티를 사용하여 .eml 또는, .pst 파일로 메시지 저장 및 자세한 분석을 수행하십시오. 보관 싱크 기능에 대한 자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조하십시오.

307798

(http://support.microsoft.com/kb/307798/ )

보관 싱크 유틸리티는 서비스 팩 2에서 사용할 수 있습니다.

Q19: 왜 내 메일 크기가 약 33% 원하는 것보다 더 큰 있고 경우에도 첨부 파일이 포함되지 않은 경우 Base 64 인코딩 이유는?

A19: 다음 문자 집합을 사용할 경우 이 문제가 발생합니다.

일본어 Shift-JIS
한국어
일본어 EUC
한국어 ISO-2202-KR
대만 ISO-2202-TW
중국어 ISO-2202-CN
HZ_GB, Big5, GB18030 중국어

Q20: 설명 다른 일반적인 및 알려진 문제점은?

A20: 한 Exchange Server 2003 서버에서 다른 서버로 릴레이됩니다 메시지가 잘못된, 나타날 수 있으며 메시지 받는 사람이 메시지 본문에 나타날.

예를 들어, 이 메시지에 있는 인터넷에서 인바운드 인터넷 Exchange Server 2003 컴퓨터 및 다른 Exchange Server 2003 컴퓨터에 라우팅된 발생할 수 있습니다.
메시지를 제대로 있는 인바운드 인터넷 Exchange Server 2003에서 나타날 수 있지만 Exchange Server 백 엔드 왜곡됩니다. 메시지의 받는 사람 수를 줄이면 이러한 현상은 변경될 수도 있습니다. 이 문제는 여러 가지 이유로 나타날 수 있지만 두 가지 가장 일반적인 이유는 같습니다.

한 줄에 998일 문자 대신 줄에 두 개 이상 1000 또는 1024 문자가 있는 RFC 2822 메시지 머리글. 자세한 내용은 요청에 대한 설명 (RFC) 2822 참조하십시오. 이를 위해 다음 인터넷 엔지니어링 작업 강제 (IETF) 웹 사이트를 방문하십시오.
http://www.ietf.org/rfc/rfc2822.txt?number=2822
(http://www.ietf.org/rfc/rfc2822.txt?number=2822)
이진 데이터를 사용하거나 청크 Exchange Server 2003 컴퓨터에 메시지는 릴레이됩니다 경우 이 문제가 발생할 수 있습니다. 청크 청크에서 보낸 데이터를 지원하는 SMTP 형식에 대한 확장입니다.

Exchange Server 2003 있는 줄을 두 개 이상의 998일 문자 메시지를 받으면 SMTP 서비스가 헤더를 구문 분석하고 1000 문자보다 긴 줄이 검색합니다. SMTP 서비스는 다음 이 줄 머리글 속해 있지 않습니다 body에 포함된 가정합니다.

SMTP 서비스가 Exchange Server 컴퓨터에서 다음 자체 헤더 re-write 됩니다 메시지 ID 및 DATE 헤더를 포함하여 빈 줄을 사용하여 CRLF 뒤에는 또는.
줄 길이 제한. 전송 요구 사항을 RFC 2821에 따라 함께 사용하여 CRLF 포함하여 줄 당 1000개 이상의 문자 메시지를 받지 않는 많은 구현이 있습니다. 따라서 메일 응용 프로그램에서 이러한 메시지를 만들어야 합니다지 않습니다. 이 문제를 해결하려면 Exchange Server 컴퓨터의 ESMTP 동사를 (또는 청크) 기능을 해제하고 메시지가 릴레이됩니다 때 형식 일반적인 SMTP 메시지 형식으로 Exchange Server 컴퓨터를 강제로. 추가 정보는 다음 문서 번호를 클릭하여 Microsoft 기술 자료에서 확인하십시오:
257569
(http://support.microsoft.com/kb/257569/ )
Exchange 2000 Server 및 Exchange Server 2003의 ESMTP 동사를 해제하려면 방법
821733
(http://support.microsoft.com/kb/821733/ )
받는 사람 1,022 문자를 초과하는 경우 들어오는 메시지가 왜곡됩니다.

위로 가기 | 피드백 보내기

참조

자세한 내용은 ARPA 인터넷 텍스트 메시지의 표준 형식에 대한 RFC 822 참조하십시오. 이렇게 하려면 다음 IETF 웹 사이트를 방문하십시오.

http://www.ietf.org/rfc/rfc0822.txt?number=822

(http://www.ietf.org/rfc/rfc0822.txt?number=822)

MIME에 대한 자세한 내용은 RFC 2045, 2046, 2047, 2048, 및 2049 참조하십시오. 이를 위해 다음 IETF 웹 사이트를 방문하십시오.

http://www.ietf.org/rfc/rfc2045.txt?number=2045

(http://www.ietf.org/rfc/rfc2045.txt?number=2045)

http://www.ietf.org/rfc/rfc2046.txt?number=2046

(http://www.ietf.org/rfc/rfc2046.txt?number=2046)

http://www.ietf.org/rfc/rfc2047.txt?number=2047

(http://www.ietf.org/rfc/rfc2047.txt?number=2047)

http://www.ietf.org/rfc/rfc2048.txt?number=2048

(http://www.ietf.org/rfc/rfc2048.txt?number=2048)

http://www.ietf.org/rfc/rfc2049.txt?number=2049

(http://www.ietf.org/rfc/rfc2049.txt?number=2049)

내용-처리 헤더 필드에 대한 자세한 내용은 RFC 2183 참조하십시오. 이를 위해 다음 IETF 웹 사이트를 방문하십시오.

http://www.ietf.org/rfc/rfc2183.txt?number=2183

(http://www.ietf.org/rfc/rfc2183.txt?number=2183)

위로 가기 | 피드백 보내기

속성

기술 자료: 836555 - 마지막 검토: 2007년 10월 25일 목요일 - 수정: 3.4

본 문서의 정보는 다음의 제품에 적용됩니다.

Microsoft Exchange Server 2003 Enterprise Edition
Microsoft Exchange Server 2003 Standard Edition
Microsoft Exchange 2000 Server Standard Edition

kbmt kbfaq kbinfo KB836555 KbMtko

기계 번역된 문서

중요: 본 문서는 전문 번역가가 번역한 것이 아니라 Microsoft 기계 번역 소프트웨어로 번역한 것입니다. Microsoft는 번역가가 번역한 문서 및 기계 번역된 문서를 모두 제공하므로 Microsoft 기술 자료에 있는 모든 문서를 한글로 접할 수 있습니다. 그러나 기계 번역 문서가 항상 완벽한 것은 아닙니다. 따라서 기계 번역 문서에는 마치 외국인이 한국어로 말할 때 실수를 하는 것처럼 어휘, 구문 또는 문법에 오류가 있을 수 있습니다. Microsoft는 내용상의 오역 또는 Microsoft 고객이 이러한 오역을 사용함으로써 발생하는 부 정확성, 오류 또는 손해에 대해 책임을 지지 않습니다. Microsoft는 이러한 문제를 해결하기 위해 기계 번역 소프트웨어를 자주 업데이트하고 있습니다.

이 문서의 영문 버전 보기.

위로 가기 | 피드백 보내기