Nejčastější dotazy týkající se formátu MIME a převodu obsahu na serveru Exchange 2000 a 2003 Exchange Server

Překlady článku Překlady článku
ID článku: 836555 - Produkty, které se vztahují k tomuto článku.
Rozbalit všechny záložky | Minimalizovat všechny záložky

Souhrn

Tento článek obsahuje odpovědi na časté otázky o MIME standard a kódování metody, které umožňují různé poštovní systémy společně pracovat. Tento článek stručně vysvětluje, jak lze řešit nečitelné nebo nečitelný e-mailových zpráv v prostředí serveru Microsoft Exchange.

Další informace

Otázka č. 1: Co je formát e-mailové zprávy?

A1: Internet e-mailové zprávy podle formátu normy, které jsou definovány v dokumentu RFC 2822. Zpráva je tvořena záhlavím a subjekt. Pole záhlaví jsou společně s názvem "záhlaví" zprávy. Těla zprávy je nepovinné. Zprávu lze odeslat bez karoserie, nikoli však bez záhlaví.

Hlavička obsahuje posloupnost znaků, které mají speciální syntaxi, řádky podle definice v RFC 2822 standardní formát. Posloupnost znaků, postupujte podle záhlaví a které jsou odděleny z hlavičky prázdný řádek (to znamená, který nemá nic před návratu vozíku řádek) a odřádkování [CRLF] obsahuje text.

Jsou pole záhlaví řádků, které se skládají z názvu pole následované dvojtečkou (:) následované subjekt pole a ukončeny znak CRLF. Název pole musí skládat tisknutelných znaků US-ASCII (to znamená, že znaky, které mají hodnoty mezi 33 a 126, včetně), s výjimkou dvojtečka. Dvojtečka se používá jako znak pro oddělení.

Subjekt pole může být složena z libovolné US-ASCII znaky kromě CRLF. Však subjekt pole může obsahovat CRLF v záhlaví Skládání a unfolding. Skládání je jeden řádek pro pohodlí, zobrazí na více řádcích. Unfolding je naopak této. Všechna pole subjekty musí splňovat syntaxi popsané v oddílech 3 a 4 standardu RFC 2822 formátu.

Text zprávy může obsahovat jeden nebo více oddílů. Každá část těla oddělena hranici. Parametr hranice je textový řetězec, který začíná dva spojovníky (-).

Dotaz č. 2: Co je to MIME?

A2: MIME je standard, který umožňuje zahrnout obsah různých typů v jedné zprávě. MIME rozšiřuje e-mailových zpráv, které chcete zahrnout více obsahu, textové i jiný než textový formát protokolu SMTP (Simple Mail Transfer Protocol). Části zprávy mohou být obrázky, zvukové, nebo text v jiné znakové sady. MIME standard se odvozuje z RFC například 2821 a RFC 2822.

Q3: Jak Exchange zpracovat MIME?

A3: Existují tři hlavní součásti serveru Exchange, které provedení převodu obsahu:
  • Součást IMAIL OZNAČENÁ je základní součást, která převede Internetu zprávy MAPI / Exchange formátu a naopak. Také zkontroluje integritu zprávy.
  • Součást EXMIME odpovídá pro překlad internetových zpráv v zastoupení vnitřní objekt na serveru Exchange a generování zpráv ve formátu MIME.
  • Součást RFHTML převede zprávy ve formátu RTF (RICH Text Format), HTML a naopak, podle nastavení v klientovi aplikace Microsoft Outlook a nastavení v počítači Exchange Server.

Q4: Jaké jsou minimální požadavky ve formátu MIME e-mailové zprávy?

A4: Ve formátu MIME e-mailové zprávy mají obvykle hlavičku a subjektem. Minimálně musí mít zprávy MIME hlavičky. Subjekt je nepovinné. Sekce záhlaví obsahuje hlavičku MIME verze 1.0 (jeden na zprávu, jak je definováno v dokumentu RFC 2822).

Těla zahrnuje:
  • Typ obsahu (to je nepovinné. Ve výchozím nastavení je text/plain, jak je definováno v dokumentu RFC 2822 5.2).
  • Obsah-přenos-kódování záhlaví (to je nepovinné. Výchozí hodnota je 7 bitů, jak je definováno v dokumentu RFC 2822 6.1.)
  • Záhlaví Content-Disposition (to je nepovinné.)
  • Obsah-ID (to je nepovinné.)


Dotaz č. 5: Co je verze záhlaví MIME?

A5: V poli záhlaví verze MIME označuje formátované zprávy MIME. Zprávy odeslané z dřívějších softwaru, které nepodporují MIME není nutné toto pole. Poštovní klienti používají absence tohoto pole Rozlišovat zprávy bez kódování MIME.

Dotaz č. 6: Co je hlavička typu obsahu?

A6: Pole Content-Type slouží k určení typu a podtyp dat v poli.

Některé typy záhlaví jsou multipart/smíšené, multipart/alternativa, text/plain, text/html, aplikace a applefile, application/ms-tnef a application/octet-stream.

Dotaz č. 7: Co je obsah-přenos-kódování?

A7: Jiné poštovní systémy zpracování dat odlišně a některé starší systémy pošty nemůže zpracovat multimediální data.

Obejít systémy, které nelze zpracovat multimediální data, schéma kódování lze data převést do formátu uniform 7 bitů. Obdrží-li příjemce zprávy, data se obnoví původní formát. Obsah-přenos-kódování formátů příklady:
  • Uvozovky vytisknout
  • Base64
  • 8 bitů
  • 7 bitů
  • Binární


Otázka č. 8: Způsob kódování přenosu implementace serveru Exchange 5.5?

A8: Exchange 5.5 kóduje kotované tisknutelného formátu nebo ve formátu 7 bitů, podle potřeby. Navíc Exchange 5.5 kóduje zprávy ve formátu base64, pokud 25 % zprávy je tvořena 8bitové znaky (to znamená, že znaky, které jsou mimo rozsah US-ASCII). To platí pouze pro těla zpráv; přílohy jsou vždy kódování base64.

Dotaz č. 9: Způsob kódování přenosu implementace serveru Exchange 2000 Server?

A9: Směrování hranice skupiny a určení cílového SMTP určit, jak Exchange 2000 Server kóduje pošty. Server Exchange 2000 bude kódovat jako uvozovky vytisknout nebo 7bitové nebo dopravní neutrální zapouzdření formát TNEF () při odesílání mezi dvěma servery nebo příjemci v různých skupin směrování a k Internetu.

Exchange 2000 Server bude kódovat v binárním nebo souhrn TNEF odeslání příjemce/server ve stejné skupině směrování.

Otázka č. 10: Jak přenos-kódování implementován v Microsoft Exchange Server 2003?

A10: Při směrování skupiny hranice, Exchange a SMTP cílových míst také určit, jak Exchange Server 2003 kóduje pošty.

V kombinovaném režimu, Exchange Server 2003 zakóduje jako uvozovky vytisknout nebo 7 bitů (formát TNEF) při odesílání mezi dvěma servery nebo příjemci v různých skupin směrování a k Internetu.

V nativním režimu Exchange Server 2003 kóduje v binárním (TNEF souhrn) při odesílání na příjemce a server ve stejné nebo jiné skupiny směrování.

Otázka č. 11: Co je záhlaví Content-Disposition?

A11: Toto záhlaví se označuje, zda oddíl bude zobrazen jako přílohu nebo zobrazí v těle zprávy.

Dotaz č. 12: Jak se Přílohy popisovač Exchange?

A12: Exchange Server 2003 ukládá zprávy na Internetu v původním formátu. To znamená, že pokud jsou zprávy číst z Internetu formát aware klienta jako aplikace Outlook Express, budou budou vykresleny v jejich původním formátu.

Však v případě, že jsou číst zprávy z klienta MAPI, IMAIL OZNAČENÁ mapuje příslušných prvků ve formátu Internet vlastnosti rozhraní MAPI. Ve skutečnosti před internetovou zprávu i do poštovní schránky, minimální sadu vlastností rozhraní MAPI musí být povýšen z Internetu zprávy; patří PR_SENT_REPRESENTING, PR_SUBJECT a tabulky příjemců.

Další vlastnosti rozhraní MAPI, jako PR_BODY, PR_HTML a PR_ATTACH_DATA_BIN jsou počítány z formátu Internet na požádání. Pokud klient rozhraní MAPI požádá první zprávy, dojde k převodu. Exchange 2000 Server pak podporuje nativní formát MAPI vlastnosti MIME.

Při převodu obsahu v Exchange Server 2003 při vykreslování příchozích zpráv MIME klientovi IMAIL OZNAČENÁ provádí následující:
  1. Kontroluje IMAIL OZNAČENÁ (název) celý souborNázev.ext) v záhlaví MIME. Pokud je nalezen název, název souboru se používá.
  2. IMAIL OZNAČENÁ kontroluje částečný název. Pokud je nalezen, IMAIL OZNAČENÁ prohlédne
    Klíč HKEY_CLASSES_ROOT a MIME/databáze nebo typu obsahu
    podklíč mapování přípony názvu souboru k typu obsahu. Pokud je nalezen odpovídající typ obsahu, doplňuje se příloha rozšíření. Pokud je nalezen žádný odpovídající typ obsahu, se používá název souboru částečné.
  3. Jestliže se žádné názvy souborů v záhlaví typu obsahu nebo Content-Disposition, IMAIL OZNAČENÁ vyhledá odpovídající typu obsahu. Pokud je nalezen, příloha bude mít formát ATTnázev.ext, kde ext je rozšíření, který je přidružen k typu obsahu. Pokud je nalezen žádný odpovídající typ obsahu, se používá příponu ".att". Exchange 2000 Server vyžaduje název souboru v záhlaví typu obsahu.


Dotaz č. 13: Co je struktura celou zprávu?

ODPOVĚĎ Č. 13: Následuje příklad celou zprávu s všechna záhlaví zobrazena. Příjemcům se obvykle zobrazí pouze části těla. Byly přidány komentáře v hranatých závorkách.

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: Proč poštovní adresy zobrazí v těle zprávy?

ODPOVĚĎ Č. 14: První "CRLF CRLF" v proudu MIME označuje začátek textu zprávy. Proto pokud je <crlf>,<crlf> bude zobrazovat pořadí mezi dvěma záhlaví, klient (aplikace Microsoft Outlook nebo Microsoft Outlook Express) zkomolené zpráva.</crlf></crlf>

První "CRLF CRLF" odděluje Internetová záhlaví zprávy z textu zprávy. Tato záhlaví jsou označovány jako P1 záhlaví. P1 záhlaví záhlaví obálky jsou a nejsou součástí internetovou zprávu, která je zpracována IMAIL OZNAČENÁ.

Výměna může předat inteligentnímu hostiteli, obsahu skenovacího zařízení, virus zdi nebo brány firewall. Software brány firewall jiných výrobců mohou někdy narušovat zprávy.

Můžete také přijímají e-mailové zprávy prostřednictvím systému UNIX, přes bránu firewall nebo přes zeď viru. Zařízení pro prohledávání obsahu třetích stran mohou být v síti. Pokud máte podobné aplikace nebo zařízení v síti, zkontrolujte omezení počtu příjemců. Vyhněte se použití těchto zařízení nebo aplikace diagnostických testů.

Otázka č. 15: Proč otazníky zobrazí ve zprávě?

A15: Pokud zprávy se zobrazují otazníky, znamená to, že systém neví, jak převést některé znaky ANSI nebo Unicode, které jsou ve zprávě. Musí se proto ujistěte, že klienta, kde je zobrazena zpráva má znakové stránky nainstalován, které odpovídají příchozí znakové sady. Například zajistěte k pracovní stanici Windows nainstalován zobrazení zpráv, které jsou napsány v japonštině japonské národní prostředí.

Otázka č. 16: Proč musím potíže při otevření zprávy ve formátu HTML a v tématu události 12002 a 12003 mé protokolu aplikace?

A16: Tyto události protokolu aplikace jsou ze zdroje úložiště informací serveru Exchange a převodu obsahu chyby. Některé tyto zprávy mohou být ignorovány a nemají vliv na všechny přijaté zprávy. Ale pokud mnohé z těchto zpráv v protokolu aplikací, pokud klienti mají problémy při otevírání zprávy ve formátu HTML.

Pokud se jedná o tento případ, stanovit další diagnostické informace jako verze aktualizací service pack, kopie zpráv problém, kopie aplikace a systémové protokoly a pak řešení.

Č. 17: Proč někdy zobrazit zprávy jako přílohu?

A17: Je nutné vytvořit informace o zdroji zprávy. Je nutné vytvořit všechny podrobnosti zdrojového serveru. Zjistit, zda je odesílatel je v síti UNIX. Další informace o tomto problému získáte článku znalostní báze Microsoft Knowledge Base:
323482 Exchange zobrazí zprávu, která obsahuje záhlaví MIME Content-Disposition "vložené" jako přílohu
Dotaz č. 18: Proč zobrazit "Je zpráv ve formátu MIME." nebo "Tato zpráva je ve formátu MIME." do těla e-mailu?

A18: Může zobrazit jedna z následujících možností v těle textu:
  • "Toto je zpráva ve formátu MIME s více částmi."
  • "Tato zpráva je ve formátu MIME. Protože vaše poštovní nerozumí tento formát, některá nebo všechna tato zpráva nemusí být čitelné."

Tento text je vložen před první hranice se obvykle nachází v každé vícedílné zprávy a není viditelný pro klienta, pokud došlo k potížím s formát e-mailu. Například zalomení řádku pevný pravděpodobně byly vloženy ve zprávě na nesprávném místě.

Chcete-li tento problém vyřešit, zapněte zpráva archivace na Microsoft Exchange Internet Mail Service. Chcete-li zapnout zprávy archivace, použít nástroj Exchange Server 2003 archiv jímky, uložit zprávu jako EML nebo PST a poté provést další analýzu. Další informace o funkci jímky archivu klepněte na následující číslo článku databáze Microsoft Knowledge Base:
307798Nástroj jímky archivu je k dispozici v aktualizaci Service Pack 2
Č. 19: Proč je velikost pošty o 33 % větší než očekávané a proč je kódování base64 i v případě, že neobsahuje přílohy?

ODPOVĚĎ 19: K tomuto chování dojde, pokud pomocí následujících znakových sadách:
  • Japonština Shift-JIS
  • KOR
  • Japonština EUC.
  • Korejský ISO-2202-KR
  • Tchaj-wanu ISO-2202-TW
  • Čínský ISO-2202KN
  • Čínský HZ_GB, Big5, GB18030


Otázka č. 20: Jaké jsou další běžné a známé problémy?

A20: Zprávy, které mají být přenášeny z jednoho serveru 2003 Exchange Server do jiného může být zkomolené a, příjemci zprávy pravděpodobně zobrazí v těle zprávy.

Například to může dojít ve zprávě, který je směrován z Internetu, počítač se příchozí Internet Exchange Server 2003 a poté do jiného počítače Exchange Server 2003.
Zpráva se může zobrazit správně na příchozí Internet Exchange Server 2003, ale nečitelné na serverové části Exchange Server. Tyto příznaky mohou změnit také v případě, že se sníží počet příjemců zprávy. Tento problém se může zobrazit z několika důvodů, ale dva nejběžnější důvody jsou:
  • RFC 2822 záhlaví zpráv, které mají více než 1000 nebo 1024 znaků v řádku namísto 998 znaky v řádku. Další informace naleznete v tématu požadavek for Comments (RFC) 2822. Naleznete na následujícím webu sdružení IETF (Internet Engineering Task Force):
    http://www.IETF.org/RFC/rfc2822.txt?number=2822
    Tento problém může nastat, pokud mají být přenášeny zprávy do počítače Exchange Server 2003 pomocí binární data nebo bloků. Bloků je rozšířením formátu protokolu SMTP, který podporuje data odesílaná v bloky.

    Exchange Server 2003 obdrží zprávu, která obsahuje více než 998 znaky v řádku, služba SMTP analyzuje záhlaví a zjistí, že řádek je delší než 1000 znaků. Služba SMTP pak předpokládá, že tento řádek není součástí záhlaví a zahrnuje ji do těla.

    Služba SMTP v počítači Exchange Server pak opětovného zápisu vlastní záhlaví, včetně ID zprávy a záhlaví datum, následuje prázdný řádek nebo znak CRLF.
  • Omezení délky řádku. Existuje mnoho implementací, které, v souladu s požadavky RFC 2821, dopravní přijímat zprávy, které mají více než 1000 znaků na řádek, včetně CRLF. Pošta aplikace proto musí vytvořit takové zprávy. Chcete-li tento problém vyřešit, vypněte možnost ESMTP sloveso (nebo bloků) v počítači Exchange Server a vynutit počítače Exchange Server do formátu formát zprávy v typické SMTP v případě, že je právě přenášené zprávy. Další informace získáte klepnutím na následující číslo článku databáze Microsoft Knowledge Base:
    257569Jak vypnout protokol ESMTP slovesa v serveru Exchange 2000 a 2003 Exchange Server
    821733 Příchozí zpráva je poškozen, v případě, že řádek Komu více než 1,022 znaků

Odkazy

Další informace o standardu pro formát textových zpráv ARPA Internet naleznete v dokumentu RFC 822. Chcete-li to provést, naleznete na následujícím webu sdružení IETF:
http://www.IETF.org/RFC/rfc0822.txt?number=822
Další informace o MIME naleznete v dokumentu RFC 2045, 2046, 2047, 2048 a 2049. Naleznete na následujících webech IETF:
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
Další informace o poli záhlaví Content-Disposition naleznete v dokumentu RFC 2183. Naleznete na následujícím webu sdružení IETF:
http://www.IETF.org/RFC/rfc2183.txt?number=2183

Vlastnosti

ID článku: 836555 - Poslední aktualizace: 22. května 2011 - Revize: 5.0
Informace v tomto článku jsou určeny pro produkt:
  • Microsoft Exchange Server 2003 Enterprise Edition
  • Microsoft Exchange Server 2003 Standard Edition
  • Microsoft Exchange 2000 Server Standard Edition
Klíčová slova: 
kbfaq kbinfo kbmt KB836555 KbMtcs
Strojově přeložený článek
Důležité: Tento článek byl přeložen pomocí software společnosti Microsoft na strojový překlad, ne profesionálním překladatelem. Společnost Microsoft nabízí jak články přeložené překladatelem, tak články přeložené pomocí software na strojový překlad, takže všechny články ve Znalostní databázi (Knowledge Base) jsou dostupné v češtině. Překlad pomocí software na strojový překlad ale není bohužel vždy dokonalý. Obsahuje chyby ve skloňování slov, skladbě vět, nebo gramatice, podobně jako když cizinci dělají chyby při mluvení v češtině. Společnost Microsoft není právně zodpovědná za nepřesnosti, chyby nebo škody vzniklé chybami v překladu, nebo při použití nepřesně přeložených instrukcí v článku zákazníkem. Společnost Microsoft aktualizuje software na strojový překlad, aby byl počet chyb omezen na minimum.
Projděte si také anglickou verzi článku:836555

Dejte nám zpětnou vazbu

 

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