Topic Path: Symbol Reference > Classes > TIdMessage Class > TIdMessage Properties > ContentType Property
ContentsIndexHome
PreviousUpNext
TIdMessage.ContentType Property

Identifies the MIME media type for the message.

property ContentType: string;

ContentType is a String property that specifies the MIME media type and subtype for the message. ContentType is used to identify and describe the data contained in the body of the message, and to fully specify the native representation (canonical form) of such data. 

ContentType allows a user agent to determine how to present data for the message. The ability to recognize the ContentType for the message, and invoke the appropriate display process accordingly, will improve the readability of messages and allow the exchange of messages containing mathematical symbols, or foreign language characters. 

ContentType contains information about the media type, subtype, and optional parameter information in the following notation: 

 

  type/subtype; param=value

 

In general, the top-level media type is used to declare the general type of data, while the subtype specifies a specific format for that type of data. An initial set of seven top-level media types are defined in RFC 2046, including: 

 

Media Type 
text 
image 
audio 
video 
application 
message 
multipart 

 

Five of these are discrete types whose content is essentially opaque as far as MIME processing is concerned. The remaining two are composite types whose contents require additional handling by MIME processors. This set of top-level media types is intended to be substantially complete. It is expected that additions to the larger set of supported types can generally be accomplished by the creation of new subtypes of these initial types. In the future, more top-level types may be defined. 

Parameters are modifiers of the media subtype, and do not fundamentally affect the nature of the content. The set of meaningful parameters depends on the media type and subtype. Most parameters are associated with a single specific subtype. However, a given top-level media type may define parameters which are applicable to any subtype of that type. The type, subtype, and parameter names are not case sensitive. For example, TEXT, Text, and TeXt are all equivalent top-level media types. Parameter values may be case sensitive, but sometimes are interpreted in a case-insensitive fashion, depending on the intended use. (For example, multipart boundaries are case-sensitive, but the "access-type" parameter for message/External-body is not case-sensitive.) 

The default content type for RFC 2822 messages without a MIME Content-Type header are taken by this protocol to be plain text in the US-ASCII character set, which can be explicitly specified as: 

 

  text/plain; charset=us-ascii

 

Use the CharSet property to indicate the character set required (or detected) for the message body. Use ContentTransferEncoding to identify the encoding scheme for the message. For additional information on ContentType values and their usage, please refer to the following Internet Standards and reference documents: 

RFC 2822 - Standard for the Format of ARPA Internet Text Messages  

RFC 1049 - Content-type header field for Internet messages.  

RFC 1437 - The Extension of MIME Content-Types to a New Medium.  

RFC 1896 - The text/enriched MIME Content-type.  

RFC 2045 - Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies  

RFC 2046 - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types  

RFC 2387 - The MIME Multipart/Related Content-type.  

Internet Assigned Numbering Authority (IANA) Official Media Types  

Copyright 1993-2006, Chad Z. Hower (aka Kudzu) and the Indy Pit Crew. All rights reserved.
Post feedback to the Indy Docs Newsgroup.