คำถามที่ถามบ่อยเกี่ยวกับ MIME และการแปลงเนื้อหาใน Exchange 2000 Server และ Exchange Server 2003

การแปลบทความ การแปลบทความ
หมายเลขบทความ (Article ID): 836555 - ผลิตภัณฑ์ที่เกี่ยวข้องในบทความนี้
ขยายทั้งหมด | ยุบทั้งหมด

สรุป

บทความนี้มีคำตอบสำหรับคำถามที่ถามบ่อยเกี่ยวกับ MIME มาตรฐานและวิธีการเข้ารหัสที่ทำให้เป็นไปได้สำหรับระบบจดหมายอื่นเพื่อทำงานร่วมกัน บทความนี้อธิบายสั้น ๆ อธิบายวิธีการที่คุณสามารถแก้ไขข้อความจดหมาย garbled หรือไม่สามารถอ่านในสภาพแวดล้อมของ Microsoft Exchange

ข้อมูลเพิ่มเติม

Q1: รูปแบบของข้อความอีเมลคืออะไร

A1::ข้อความอีเมล์ของอินเทอร์เน็ตตามมาตรฐานของรูปแบบที่กำหนดไว้ใน RFC 2822 ข้อความขึ้นของเขตข้อมูลส่วนหัวและเนื้อความมา ฟิลด์ในหัวข้อมีชื่อ collectively "หัวข้อ" ของข้อความ เนื้อความของข้อความถูกเลือกได้ สามารถส่งข้อความโดย ไม่มีเนื้อความ แต่ไม่ โดยไม่มีส่วนหัว

หัวข้อที่ประกอบด้วยลำดับของบรรทัดของอักขระที่มีไวยากรณ์ที่พิเศษ ตามที่กำหนดไว้ในรูปแบบมาตรฐาน RFC 2822 เนื้อหาประกอบด้วยลำดับของอักขระที่ตามหัวข้อ และที่ถูกแยกจากหัวข้อ โดยบรรทัดว่าง (นั่นคือ บรรทัดที่มีสิ่งใดก่อนที่จะส่งกลับค่าขนส่ง) และบรรทัดตัวดึง [CRLF]

หัวข้อฟิลด์คือ บรรทัดจะประกอบด้วยชื่อของเขตข้อมูลตาม ด้วยเครื่องหมายจุดคู่ (:), แล้วตาม ด้วยเนื้อหาฟิลด์ และสิ้นสุดลง โดย CRLF ชื่อเขตข้อมูลต้องจะประกอบด้วยอักขระ ASCII สหรัฐอเมริกาสามารถพิมพ์ (นั่นคือ อักขระที่มีค่าระหว่าง 33 126 ครอบคลุมยิ่งขึ้น), ยกเว้นหมายจุดคู่(:) เครื่องหมายทวิภาคถูกใช้เป็นอักขระ separation

เนื้อหาของฟิลด์อาจจะประกอบด้วยอักขระใด ๆ ASCII สหรัฐอเมริกา ยกเว้นสำหรับ CRLF อย่างไรก็ตาม เนื้อหาของฟิลด์อาจประกอบด้วย CRLF เมื่อใช้ในหัวข้อfoldingและunfolding. folding คือ เมื่อ เพื่อความสะดวก บรรทัดเดียวปรากฏในหลายบรรทัด unfolding คือ reverse นี้ เนื้อความของฟิลด์ทั้งหมดต้องตามไวยากรณ์อธิบายไว้ในส่วนที่ 3 และ 4 ของรูป RFC 2822 มาตรฐาน

เนื้อหาของข้อความอาจรวมถึงส่วนอย่าง น้อยหนึ่งรายการ แต่ละส่วนของตัวคั่น โดยมีขอบเขต พารามิเตอร์ขอบเขตเป็นสายอักขระข้อความที่ขึ้นต้น ด้วยสองยัติภังค์(-)

Q2: MIME คืออะไร

A2::mime คือ มาตรฐานที่สามารถใช้การรวมเนื้อหาของชนิดที่แตกต่างกันในข้อความเดี่ยว mime ขยายรูปแบบธรรมดา Mail Transfer Protocol (SMTP) ของข้อความจดหมายที่รวมหลายเนื้อหา ทั้งแบบ และไม่ใช่แบบ ส่วนของข้อความอาจเป็นรูป เพลง หรือการตั้งค่าข้อความในอักขระที่แตกต่างกัน MIME มาตรฐานมาจาก RFCs เช่น 2821 และ 2822

Q3: วิธีใด Exchange จัดการ MIME หรือไม่

A3::มีส่วนสามหลักประกอบในการแลกเปลี่ยนที่ทำการแปลงเนื้อหา:
  • คอมโพเนนต์ IMAIL คือ คอมโพเนนต์หลักของแปลงข้อความของอินเทอร์เน็ตกับ MAPI / Exchange รูปแบบและ vice ทางกลับกัน นอกจากนี้ตรวจสอบความถูกต้องของข้อความ
  • คอมโพเนนต์ EXMIME รับผิดชอบ สำหรับการแปลข้อความของอินเทอร์เน็ตในแทนวัตถุภายในของ Exchange และ สำหรับการสร้างข้อความที่มีการจัดรูปแบบ MIME
  • คอมโพเนนต์ RFHTML แปลงข้อความที่จัดรูปแบบข้อความ Rich (RTF) กับ HTML และกลับ ตาม การตั้งค่าบนไคลเอนต์ Microsoft Outlook และการตั้งค่าบนคอมพิวเตอร์ Exchange Server

Q4: อะไรบ้างข้อกำหนดต่ำสุดของข้อความอีเมล์ที่มีการจัดรูปแบบ MIME

A4::ข้อความอีเมล์ที่มีการจัดรูปแบบ MIME จะมีส่วนหัวและเนื้อความโดยปกติ อย่างน้อยสุด ข้อความ MIME ต้องมีส่วนหัว เนื้อหาถูกเลือกได้ ส่วนหัวข้อประกอบด้วยหัวข้อรุ่น 1.0 MIME (หนึ่งในต่อข้อความ ตามที่กำหนดใน RFC 2822)

รวมส่วนเนื้อความ:
  • เนื้อหาชนิด (ซึ่งจะเป็นตัวเลือก ค่าเริ่มต้นเป็นข้อความ/ล้วน ตามที่กำหนดใน RFC 2822 5.2)
  • หัวเข้าเนื้อหาโอนย้ายรหัส (ซึ่งจะเป็นตัวเลือก ค่าเริ่มต้นเป็น 7 บิต ตามที่กำหนดใน RFC 2822 6.1)
  • ส่วนหัวของเนื้อหา-Disposition (ซึ่งเป็นทางเลือก)
  • การเนื้อหารหัส (ซึ่งเป็นทางเลือก)


Q5: ส่วนหัวของเวอร์ชัน MIME คืออะไร

A5::ฟิลด์ส่วนหัวของเวอร์ชัน MIME แสดงถึงทศนิยมข้อความการจัดรูปแบบ MIME ข้อความที่ส่งจากซอฟต์แวร์ที่ก่อนหน้านี้ที่ไม่สนับสนุน MIME ที่ไม่มีฟิลด์นี้ ไคลเอ็นต์จดหมายใช้การขาดงานของฟิลด์นี้เพื่อแยกข้อความที่ไม่ใช่แบบ MIME

Q6: ส่วนหัวของชนิดของเนื้อหาคืออะไร

A6::ฟิลด์ชนิดของเนื้อหาถูกใช้เพื่อระบุชนิดและชนิดย่อยของข้อมูลในเขตข้อมูล

บางชนิดหัวข้อคือ multipart/ผสม, multipart/อื่น ข้อความ ล้วน / ข้อ ความ/html แอพลิเค ชัน/applefile แอพลิเค ชัน/ms-tnef และแอพลิเค ชัน/octet-กระแสได้ข้อมูล

Q7: What is Content-Transfer-Encoding?

A7::Different mail systems handle data differently, and some earlier mail systems cannot handle multimedia data.

To work around systems that cannot handle multimedia data, an encoding scheme is used to convert the data to a uniform 7-bit format. When the recipient receives the message, the data is restored to its original format. Some examples of Content-Transfer-Encoding formats are:
  • Quoted-printable
  • Base64
  • 8-bit
  • 7-bit
  • Binary


Q8: How is Transfer-Encoding implemented in Exchange 5.5?

A8:Exchange 5.5 encodes in quoted-printable format or in 7-bit format, as required. Additionally, Exchange 5.5 encodes messages in base64 format if 25% of the message is made up of 8-bit characters (that is, characters that are outside the US-ASCII range). This applies only to the message body; attachments are always base64-encoded.

Q9: How is Transfer-Encoding implemented in Exchange 2000 Server?

A9:Routing group boundaries and SMTP target destinations determine how Exchange 2000 Server encodes mail. Exchange 2000 will encode as quoted-printable or 7-bit or Transport-Neutral Encapsulation Format (TNEF) when sending between two servers/recipients in different routing groups, and to the Internet.

Exchange 2000 Server will encode in Binary or Summary TNEF when sending to a recipient/server in the same routing group.

Q10: How is Transfer-Encoding implemented in Microsoft Exchange Server 2003?

A10:When routing group boundaries, Exchange and SMTP target destinations also determine how Exchange Server 2003 encodes mail.

In mixed mode, Exchange Server 2003 encodes as quoted-printable or 7-bit (TNEF format) when sending between two servers/recipients in different routing groups and to the Internet.

In native mode, Exchange Server 2003 encodes in Binary (Summary TNEF) when sending to a recipient/server in the same or other routing groups.

Q11: What is a Content-Disposition header?

A11:This header identifies whether a section will appear as an attachment or appear in the message body.

Q12: How does Exchange handle attachments?

A12:Exchange Server 2003 saves Internet messages in their native format. This means that if the messages are read from an Internet-format-aware client like Outlook Express, they will be rendered in their original format.

However, when messages are read from a MAPI client, IMAIL maps the appropriate elements in the Internet format to MAPI properties. In fact, before an Internet message is even delivered to a mailbox, a minimum set of MAPI properties must be promoted from the Internet message; these include PR_SENT_REPRESENTING, PR_SUBJECT, and recipient table.

Other MAPI properties like PR_BODY, PR_HTML, and PR_ATTACH_DATA_BIN are computed from the Internet format on demand. Conversion occurs when a MAPI client requests the message for the first time. Exchange 2000 Server then promotes those native MIME properties to MAPI format.

During content-conversion in Exchange Server 2003, when rendering an inbound MIME message to a client, IMAIL does the following:
  1. IMAIL checks for a complete file name (ชื่อ:.ดไป) in the MIME header. If a name is found, the file name is used.
  2. IMAIL checks for a partial file name. If one is found, IMAIL looks at the
    HKEY_CLASSES_ROOT/MIME/Database/content-type
    subkey to map a file name extension to the content type. If a matching content type is found, that extension is added to the attachment. If no matching content type is found, the partial file name is used.
  3. If no file names are specified in the Content-type or Content-Disposition headers, IMAIL searches for a matching content type. If one is found, the attachment will have the format ATTชื่อ:.ดไปโดย:ดไปis the extension that is associated with this content type. If no matching content type is found, an extension of ".att" is used. Exchange 2000 Server requires a file name in the Content-type header.


Q13: What is the structure of the full message?

A13:The following is an example of a full message, with all the headers shown. Recipients will generally see only the body parts. Comments have been added in brackets.

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: Why do mail addresses show up in the body of my message?

A14:The first “CRLF CRLF” in the MIME stream denotes the beginning of the message body. Therefore, if there is a <crlf><crlf> sequence between two headers, the client (Microsoft Outlook or Microsoft Outlook Express) will show a garbled message.</crlf></crlf>

แรก “ CRLF CRLF ” แยกส่วนหัวของข้อความอินเทอร์เน็ตจากเนื้อหาของข้อความ ส่วนหัวเหล่านี้ถูกเรียกว่าหัว P1 ส่วนหัว p1 มีส่วนหัวของซองจดหมาย และจะไม่เป็นส่วนหนึ่งของข้อความของอินเทอร์เน็ตที่มีการประมวลผล โดย IMAIL

แลกเปลี่ยนอาจถูกส่งต่อไปยังโฮสต์สมาร์ท อุปกรณ์สแกนเนื้อหา ผนังไวรัส หรือไฟร์วอลล์ ซอฟต์แวร์ไฟร์วอลล์ของบริษัทอื่นบางครั้งอาจ distort ข้อความ

คุณอาจยังได้รับข้อความอีเม ผ่านระบบ UNIX ผ่านไฟร์วอลล์ หรือ ผ่านแบบผนังไวรัส นอกจากนี้ อุปกรณ์กำลังสแกนเนื้อหาของบริษัทอื่นอาจจะบนเครือข่าย ถ้าคุณมีโปรแกรมประยุกต์ที่เหมือนกันหรืออุปกรณ์บนเครือข่ายของคุณ ตรวจสอบข้อจำกัดที่ผู้รับ หลีกเลี่ยงการใช้อุปกรณ์หรือโปรแกรมประยุกต์เช่นในการทดสอบการวินิจฉัย

Q15: ทำไมทำเครื่องหมายคำถามปรากฏในข้อความของฉันหรือไม่

A15::ถ้ามีเครื่องหมายคำถามปรากฏในข้อความ นั่นหมายความ ว่า ระบบจะไม่ทราบวิธีการแปลบาง ANSI Unicode อักขระหรือที่อยู่ในข้อความ คุณต้องมั่นใจว่า ไคลเอนต์ที่ดูข้อความที่มีโค้ดเพจการติดตั้งที่ตรงกับชุดอักขระที่ขาเข้า ตัวอย่างเช่น ตรวจสอบให้แน่ใจว่า เวิร์กสเตชัน Windows มีภาษาของภาษาญี่ปุ่นที่ติดตั้งเมื่อต้องการดูข้อความที่เขียนขึ้นในภาษาญี่ปุ่น

Q16: ทำไมทำฉันมีอุปสรรคในการเปิดข้อความ HTML และฉันจะดูเหตุการณ์ 12002 และ 12003 ในล็อกแอพลิเคชันของฉันได้อย่างไร

A16::เหตุการณ์การบันทึกของโปรแกรมประยุกต์เหล่านี้จากแหล่งที่เก็บข้อมูล Exchange และข้อผิดพลาดในการแปลงเนื้อหา บางส่วนของข้อความเหล่านี้สามารถถูกละเว้น และไม่สามารถมี affect ใด ๆ ในข้อความที่ได้รับ แต่ถ้าคุณเห็นข้อความเหล่านี้ในบันทึกเหตุการณ์ของโปรแกรมประยุกต์จำนวนมาก ดูว่า ไคลเอนต์มีปัญหาในการเปิดข้อความ HTML

หากเป็นกรณีนี้ ข้อมูลการวินิจฉัยเพิ่มเติมเช่นเดียวกับบริการ service pack รุ่น สำเนาของข้อความปัญหา สำเนาของแอพลิเคชันและการบันทึกของระบบ สร้าง และแก้ไขแล้ว

Q17: ทำไมทำฉันในบางครั้งดูเนื้อหาของข้อความเป็นสิ่งที่แนบมาได้อย่างไร

A17::คุณต้องสร้างรายละเอียดเกี่ยวกับแหล่งที่มาของข้อความ คุณต้องสร้างรายละเอียดทั้งหมดของเซิร์ฟเวอร์ต้นทาง คุณต้องตรวจสอบว่า ผู้ส่งที่อยู่บนเครือข่าย UNIXสำหรับข้อมูลเพิ่มเติมเกี่ยวกับปัญหานี้ คลิกหมายเลขบทความต่อไปนี้เพื่อดูบทความในฐานความรู้ของ Microsoft::
323482แลกเปลี่ยนแสดงข้อความที่ใช้ส่วนหัวของเนื้อหา MIME-Disposition "แบบอินไลน์" เป็นสิ่งที่แนบมา
Q18: ทำไมทำฉันดู “นี่คือข้อความในรูปแบบ MIME multi-part ” หรือ “ ข้อความนี้อยู่ในรูปแบบ MIME "ในเนื้อหาของอีเมล์หรือไม่

A18::คุณอาจพบในเนื้อหาข้อความต่อไปนี้อย่างใดอย่างหนึ่ง:
  • “นี้เป็นข้อความในรูปแบบ MIME multi-part ”
  • “ข้อความนี้ได้ในรูปแบบ MIME เนื่องจากผู้อ่านจดหมายของคุณไม่เข้าใจรูปแบบนี้ บางส่วนหรือทั้งหมดของข้อความนี้อาจไม่ได้ legible ”

ข้อความนี้แทรกก่อนขอบเขตแรก มักจะปรากฏในข้อความทุก multipart และไม่สามารถมองเห็นไคลเอ็นต์เว้นแต่ว่าไม่มีปัญหากับการจัดรูปแบบอีเมลที่ ตัวอย่างเช่น ตัวแบ่งบรรทัดฮาร์ดดิสก์อาจได้ถูกแทรกในข้อความในตำแหน่งที่ไม่ถูกต้อง

การแก้ไขปัญหานี้ เปิดข้อความเก็บถาวรในการแลกเปลี่ยนบริการอินเทอร์เน็ตของ Microsoft Mail เมื่อต้องการเปิดข้อความเก็บถาวร ใช้โปรแกรมอรรถประโยชน์ Exchange Server 2003 เก็บถาวร Sink บันทึกข้อความ.eml หรือ.pst แล้ว ทำการวิเคราะห์เพิ่มเติมสำหรับข้อมูลเพิ่มเติมเกี่ยวกับคุณลักษณะการเก็บเก็บถาวร คลิกหมายเลขบทความต่อไปนี้เพื่อดูบทความในฐานความรู้ของ Microsoft:
307798ยูทิลิตี้การเก็บถาวร Sink มีอยู่ใน Service Pack 2
Q19: ทำไมขนาดของจดหมายของฉันประมาณ 33% มีขนาดใหญ่เกินกว่าที่ฉันคาดว่า และสาเหตุเป็นดังกล่าวถูกเข้ารหัส base64 แม้ว่าจะไม่ประกอบด้วยสิ่งที่แนบมาหรือไม่

a19:ลักษณะการทำงานนี้เกิดขึ้นหากคุณใช้ชุดอักขระต่อไปนี้:
  • JIS Shift ภาษาญี่ปุ่น
  • kor
  • EUC ภาษาญี่ปุ่น
  • ภาษาเกาหลี ISO-2202-KR
  • ไต้หวัน ISO-2202-TW
  • ภาษาจีน ISO-2202-CN
  • GB18030 HZ_GB, Big5 จีน


Q20: อะไรบ้างปัญหาทั่วไป และปัญหาอื่น ๆ

a20:ข้อความที่ relayed จากเซิร์ฟเวอร์ Exchange Server 2003 หนึ่งไปยังอีก อาจปรากฏ garbled และผู้รับข้อความอาจปรากฏในเนื้อหาของข้อความ

ตัวอย่างเช่น นี้อาจเกิดขึ้นในข้อความที่มีการกำหนดเส้นทางจากอินเทอร์เน็ตที่คอมพิวเตอร์ขาเข้าของอินเทอร์เน็ต Exchange Server 2003 และจากนั้นไป ยังคอมพิวเตอร์ Exchange Server 2003 อื่น
The message might appear correctly on the Inbound Internet Exchange Server 2003, but garbled on the backend Exchange Server. These symptoms may also change if the number of recipients on the message is reduced. This issue can appear for several reasons, but the two most common reasons are:
  • RFC 2822 message headers that have more than 1000 or 1024 characters in a line, instead of 998 characters in a line. For more information, see Request for Comments (RFC) 2822. To this, visit the following Internet Engineering Task Force (IETF) Web site:
    http://www.ietf.org/rfc/rfc2822.txt?number=2822
    You may experience this issue if messages are relayed to a Exchange Server 2003 computer by using binary data or bychunking. Chunking is an extension to the SMTP format that supports data sent in chunks.

    When Exchange Server 2003 receives a message that has more than 998 characters in a line, the SMTP service parses the header and discovers that the line is longer than 1000 characters. The SMTP service then assumes this line is not a header part and includes it in the body.

    The SMTP service on the Exchange Server computer will then re-write its own headers, including message ID and a DATE header, followed by a blank line or a CRLF.
  • Line length limits. There are many implementations that, in accordance with the transport requirements of RFC 2821, do not accept messages that have more than 1000 characters per line, including the CRLF. Therefore, mail applications must not create such messages. To work around this issue, turn off the ESMTP verb (or chunking) capability on the Exchange Server computer and force the Exchange Server computers to format messages in typical SMTP format when the message is being relayed.สำหรับข้อมูลเพิ่มเติม ให้คลิกหมายเลขบทความต่อไปนี้ เพื่อดูบทความในฐานความรู้ของ Microsoft::
    257569How to turn off ESMTP verbs in Exchange 2000 Server and in Exchange Server 2003
    821733Incoming message is garbled if the To line exceeds 1,022 characters

ข้อมูลอ้างอิง

For more information about the standard for the format of ARPA Internet text messages, see RFC 822. To do this, visit the following IETF Web site:
http://www.ietf.org/rfc/rfc0822.txt?number=822
For more information about MIME, see RFC 2045, 2046, 2047, 2048, and 2049. To this, visit the following IETF Web sites:
http://www.ietf.org/rfc/rfc2045.txt?number=2045
http://www.ietf.org/rfc/rfc2046.txt?number=2046
http://www.ietf.org/rfc/rfc2047.txt?number=2047
http://www.ietf.org/rfc/rfc2048.txt?number=2048
http://www.ietf.org/rfc/rfc2049.txt?number=2049
For more information about the Content-Disposition header field, see RFC 2183. To this, visit the following IETF Web site:
http://www.ietf.org/rfc/rfc2183.txt?number=2183

คุณสมบัติ

หมายเลขบทความ (Article ID): 836555 - รีวิวครั้งสุดท้าย: 14 มกราคม 2554 - Revision: 3.0
ใช้กับ
  • Microsoft Exchange Server 2003 Enterprise Edition
  • Microsoft Exchange Server 2003 Standard Edition
  • Microsoft Exchange 2000 Server Standard Edition
Keywords: 
kbfaq kbinfo kbmt KB836555 KbMtth
แปลโดยคอมพิวเตอร์
ข้อมูลสำคัญ: บทความนี้แปลโดยซอฟต์แวร์การแปลด้วยคอมพิวเตอร์ของ Microsoft แทนที่จะเป็นนักแปลที่เป็นบุคคล Microsoft มีบทความที่แปลโดยนักแปลและบทความที่แปลด้วยคอมพิวเตอร์ เพื่อให้คุณสามารถเข้าถึงบทความทั้งหมดในฐานความรู้ของเรา ในภาษาของคุณเอง อย่างไรก็ตาม บทความที่แปลด้วยคอมพิวเตอร์นั้นอาจมีข้อบกพร่อง โดยอาจมีข้อผิดพลาดในคำศัพท์ รูปแบบการใช้ภาษาและไวยากรณ์ เช่นเดียวกับกรณีที่ชาวต่างชาติพูดผิดเมื่อพูดภาษาของคุณ Microsoft ไม่มีส่วนรับผิดชอบต่อความคลาดเคลื่อน ความผิดพลาดหรือความเสียหายที่เกิดจากการแปลเนื้อหาผิดพลาด หรือการใช้บทแปลของลูกค้า และ Microsoft มีการปรับปรุงซอฟต์แวร์การแปลด้วยคอมพิวเตอร์อยู่เป็นประจำ
ต่อไปนี้เป็นฉบับภาษาอังกฤษของบทความนี้:836555

ให้ข้อเสนอแนะ

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com