Internet Engineering Task Force (IETF)                        S. Leonard
Request for Comments: 7763                                 Penango, Inc.
Category: Informational                                       March 2016
ISSN: 2070-1721

The text/markdown Media Type




This document registers the text/markdown media type for use with Markdown, a family of plain-text formatting syntaxes that optionally can be converted to formal markup languages such as HTML.

このドキュメントは、オプションでHTMLなどの正式なマークアップ言語に変換できるプレーンテキストフォーマット構文のファミリーであるMarkdownで使用するために、text / markdownメディアタイプを登録します。

Status of This Memo


This document is not an Internet Standards Track specification; it is published for informational purposes.

このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

このドキュメントは、IETF(Internet Engineering Task Force)の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ(IESG)による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at


Copyright Notice


Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.

Copyright(c)2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定(の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents


   1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  2
     1.1. This Is Markdown! Or: Markup and Its Discontents  . . . . .  2
     1.2. Markdown Is About Writing and Editing . . . . . . . . . . .  3
     1.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . .  5
   2. Markdown Media Type Registration Application  . . . . . . . . .  5
   3. Fragment Identifiers  . . . . . . . . . . . . . . . . . . . . .  8
     3.1. Parameters  . . . . . . . . . . . . . . . . . . . . . . . .  8
   4.  Content Disposition and preview-type . . . . . . . . . . . . .  9
   5.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
     6.1. Markdown Variants . . . . . . . . . . . . . . . . . . . . . 10
   7. Security Considerations . . . . . . . . . . . . . . . . . . . . 13
   8. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     8.1. Normative References  . . . . . . . . . . . . . . . . . . . 13
     8.2. Informative References  . . . . . . . . . . . . . . . . . . 14
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
1. はじめに
1.1. This Is Markdown! Or: Markup and Its Discontents
1.1. これがMarkdownです!または:マークアップとその不満

In computer systems, textual data is stored and processed using a continuum of techniques. On the one end is plain text: computer-encoded text that consists only of a sequence of code points from a given standard, with no other formatting or structural information [UNICODE]. (On the other end is binary data, which computer systems store and process with bit-for-bit accuracy.) Many of these standards include control characters that are used as in-band signaling to cause effects other than the addition of a symbol (or grapheme) to the text.

コンピュータシステムでは、テキストデータは一連の技術を使用して保存および処理されます。一方はプレーンテキストです。コンピュータでエンコードされたテキストで、特定の規格のコードポイントのシーケンスのみで構成され、他のフォーマットや構造情報はありません[UNICODE]。 (もう一方の端はバイナリデータであり、コンピューターシステムはビット単位の精度で保存および処理します。)これらの標準の多くには、記号の追加以外の効果を引き起こすインバンドシグナリングとして使用される制御文字が含まれています(または書記素)をテキストに。

Markup offers an alternative means to encode this signaling information by overloading certain graphic characters (see, e.g., [ISO646]) with additional meanings. Therefore, markup languages allow for annotating a document in a syntactically distinguishable way from the text, while keeping the annotations printable. Markup languages are (reasonably) well-specified and tend to follow (mostly) standardized syntax rules. Examples of formal markup languages include Standard Generalized Markup Language (SGML), HTML, XML, and LaTeX. Standardized rules lead to interoperability between markup processors, but they impose skill requirements on new users that lead to markup languages becoming less accessible to beginners. These rules also reify "validity": content that does not conform to the rules is treated differently (i.e., is rejected) than content that conforms.


In contrast to formal markup languages, lightweight markup languages use simple syntaxes; they are designed to be easy for humans to enter and understand with basic text editors. Markdown, the subject of this document, began as an /informal/ plain-text formatting syntax [MDSYNTAX] and Perl script HTML/XHTML processor [MARKDOWN] targeted at non-technical users using unspecialized tools, such as plain-text email clients. [MDSYNTAX] explicitly rejects the notion of validity: there is no such thing as "invalid" Markdown. If the Markdown content does not result in the "right" output (defined as output that the author wants, not output that adheres to some dictated system of rules), the expectation is that the author should continue experimenting by changing the content or the processor to achieve the desired output.

形式的なマークアップ言語とは対照的に、軽量のマークアップ言語は単純な構文を使用します。基本的なテキストエディタを使用して、人間が簡単に入力して理解できるように設計されています。このドキュメントの主題であるMarkdownは、/テキスト形式の書式設定構文[MDSYNTAX]およびPerlスクリプトHTML / XHTMLプロセッサ[MARKDOWN]とし​​て始まり、プレーンテキストのメールクライアントなどの専門知識のないツールを使用する非技術的なユーザーを対象としています。 [MDSYNTAX]は有効性の概念を明示的に拒否します。「無効な」Markdownのようなものはありません。マークダウンコンテンツが「正しい」出力(作成者が必要とする出力であり、規定のルールシステムに準拠する出力ではない)にならない場合、作成者はコンテンツまたはプロセッサを変更して実験を続ける必要があります。望ましい出力を達成するため。

Since its development in 2004 [MARKDOWN], a number of web- and Internet-facing applications have incorporated Markdown into their text-entry systems, frequently with custom extensions. Markdown has thus evolved into a kind of Internet meme [INETMEME] as different communities encounter it and adapt the syntax for their specific use cases. Markdown now represents a family of related plain-text formatting syntaxes and implementations that, while broadly compatible with humans [HUMANE], are intended to produce different kinds of outputs that push the boundaries of mutual intelligibility between software systems.

2004年の開発[MARKDOWN]以降、多くのWebおよびインターネット向けアプリケーションがMarkdownをテキスト入力システムに組み込んでおり、その多くはカスタム拡張機能を備えています。マークダウンは、さまざまなコミュニティが遭遇し、構文を特定のユースケースに適合させることで、一種のインターネットミーム[INETMEME]に進化しました。 Markdownは、人間と広く互換性がある[HUMANE]ながら、ソフトウェアシステム間の相互了解度の境界を押し広げるさまざまな種類の出力を生成することを目的とした、関連するプレーンテキストフォーマット構文および実装のファミリーを表します。

To support identifying and conveying Markdown, this document defines a media type and parameters that indicate the Markdown author's intent on how to interpret the content. This registration draws particular inspiration from text/troff [RFC4263], which is a plain-text formatting syntax for typesetting based on tools from the 1960s ("RUNOFF") and 1970s ("nroff", et al.). In that sense, Markdown is a kind of troff for modern computing. A companion document [RFC7764] provides additional Markdown background, philosophy, local storage strategies, and variant registrations (including examples).

Markdownの識別と伝達をサポートするために、このドキュメントでは、コンテンツの解釈方法に関するMarkdown作成者の意図を示すメディアタイプとパラメーターを定義しています。この登録は、1960年代( "RUNOFF")および1970年代( "nroff"など)のツールに基づく組版用の平文フォーマット構文であるtext / troff [RFC4263]から特にインスピレーションを得ています。その意味で、Markdownは現代のコンピューティングにとって一種のtroffです。関連ドキュメント[RFC7764]は、追加のMarkdownの背景、哲学、ローカルストレージ戦略、およびバリアント登録(例を含む)を提供します。

1.2. Markdown Is About Writing and Editing
1.2. Markdownは記述と編集に関するものです
     "HTML is a *publishing* format; Markdown is a *writing* format.
      Thus, Markdown's formatting syntax only addresses issues that can
      be conveyed in plain text." [MDSYNTAX]

The paradigmatic use case for text/markdown is the Markdown editor: an application that presents Markdown content (which looks like an email or other piece of plain-text writing) alongside a published format, so that an author can see results instantaneously and can tweak his or her input in real time. A significant number of Markdown editors have adopted "split-screen view" (or "live preview") technology that looks like Figure 1.


| File  Edit  (Cloud Stuff)  (Fork Me on GitHub)  Help                 |
| [ such-and-such identifier ]                 [ useful statistics]    |
| (plain text, with                || (text/html, likely               |
|  syntax highlighting)            ||  rendered to screen)             |
|                                  ||                                  |
|# Introduction                    ||<h1>Introduction</h1>             |
|                                  ||                                  |
|## Markdown Is About Writing and  /|<h2>Markdown Is About Writing and |
/ Editing                          ||Editing</h2>                      |
|                                  ||                                  |
|> HTML is a *publishing* format;  ||<blockquote><p>HTML is a          |
|> Markdown is a *writing* format. || <em>publishing</em> format;      |
|> Thus, Markdown's formatting     || Markdown is a <em>writing</em>   |
|> syntax only addresses issues    || format. Thus, Markdown's         |
|> that can be conveyed in plain   <> formatting syntax only addresses |
|> text. [MDSYNTAX][]              || issues that can be conveyed in   |
|                                  || plain text. <a href="http://darin/
|The paradigmatic use case for     |/
|`text/markdown` is the Markdown   |/ntax#html" title="Markdown: Syntax/
|editor: an application that       |/: HTML">MDSYNTAX</a>              |
|presents Markdown content         ||</p></blockquote>                 |
|...                               ||                                  |
|                                  ||<p>The paradigmatic use case for  |
|[MDSYNTAX]: http://daringfireball./| <code>text/markdown</code> is the|
/net/projects/markdown/syntax#html || Markdown editor: an application  |
|"Markdown: Syntax: HTML"          || that presents Markdown content   |
|                                  || ...</p>                          |

LEGEND: "/" embedded in a vertical line represents a line-continuation marker, since a line break is not supposed to occur in that content.


Figure 1: Markdown Split-Screen / Live Preview Editor


To get the best results, implementations ought to produce and consume mutually intelligible and identifiable bits of Markdown. That way, users on diverse platforms can collaborate with their tools of choice. Those tools can be desktop-based (MarkdownPad, MultiMarkdown Composer); browser-based (Dillinger, Markable); integrated widgets (Discourse, GitHub); general-purpose editors (emacs, vi); or plain old "Notepad". Additionally, implementations ought to have common ways to identify particular areas of Markdown content when the Markdown becomes appreciably large (e.g., book chapters and Internet-Drafts -- not just blog posts). So that users have the option to use Markdown in MIME-capable systems to convey their works in progress, not just their finished products (for which full-blown markups ranging from text/html to application/pdf are appropriate), implementations ought to label such Markdown content with a common media type: text/markdown. This registration facilitates interoperability between these Markdown editors by conveying the syntax of the particular Markdown variant and the desired output format.

最良の結果を得るには、実装はMarkdownの相互に理解可能で識別可能なビットを生成および消費する必要があります。このようにして、さまざまなプラットフォームのユーザーは、選択したツールを使用してコラボレーションできます。これらのツールはデスクトップベース(MarkdownPad、MultiMarkdown Composer)にすることができます。ブラウザベース(Dillinger、Markable);統合されたウィジェット(ディスコース、GitHub);汎用エディター(emacs、vi);またはプレーンな「メモ帳」。さらに、実装には、Markdownがかなり大きくなったときにMarkdownコンテンツの特定の領域を識別する一般的な方法が必要です(たとえば、ブログの投稿だけでなく、本の章やインターネットドラフト)。ユーザーがMIME対応システムでMarkdownを使用して、完成した製品(text / htmlからapplication / pdfまでの本格的なマークアップが適切である)だけでなく、進行中の作業を伝えるために、実装にはラベルを付ける必要があります。一般的なメディアタイプ(テキスト/マークダウン)を持つこのようなマークダウンコンテンツ。この登録により、特定のMarkdownバリアントの構文と目的の出力形式を伝達することにより、これらのMarkdownエディター間の相互運用が容易になります。

1.3. Definitions
1.3. 定義

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。

Since Markdown signifies a family of related formats with varying degrees of formal documentation and implementation, this specification uses the term "variant" to identify such formats.


2. Markdown Media Type Registration Application
2. Markdown Media Type Registration Application

This section provides the media type registration application for the text/markdown media type (see Section 5.6 of [RFC6838]).

このセクションでは、text / markdownメディアタイプのメディアタイプ登録アプリケーションを提供します([RFC6838]のセクション5.6を参照)。

Type name: text


Subtype name: markdown


Required parameters:


charset: Per Section 4.2.1 of [RFC6838], charset is REQUIRED. There is no default value because neither [MDSYNTAX] nor many popular implementations at the time of this registration do either. [MDSYNTAX] clearly describes Markdown as a "writing format"; its syntax rules operate on characters (specifically, on punctuation) rather than code points. Many Markdown processors will get along just fine by operating on characters in the US-ASCII repertoire (specifically punctuation), blissfully oblivious to other characters or codes.

charset:[RFC6838]のセクション4.2.1に従って、charsetが必要です。この登録時に[MDSYNTAX]も一般的な実装も行われていないため、デフォルト値はありません。 [MDSYNTAX]はMarkdownを「書き込みフォーマット」として明確に説明しています。その構文規則は、コードポイントではなく文字(特に句読点)に作用します。多くのMarkdownプロセッサは、US-ASCIIレパートリー(特に句読点)の文字を操作することで、他の文字やコードに気付かずにうまく行きます。

Optional parameters:


variant: An optional identifier of the specific Markdown variant that the author intended. The value serves as a "hint" to the recipient, meaning that the recipient MAY interpret the Markdown as that variant, but is under no obligation to do so. When omitted, there is no hint; the interpretation is entirely up to the receiver and context. This identifier is plain US-ASCII and case-insensitive. To promote interoperability, identifiers can be registered in the registry defined in Section 6. If a receiver does not recognize the variant identifier, the receiver MAY present the identifier to a user to inform him or her of it.


Other parameters MAY be included with the media type. The variant SHOULD define the semantics of such other parameters. Additionally, the variant MAY be registered under another media type; this text/markdown registration does not preclude other registrations.


Encoding considerations:


Markdown content is plain-text content; any octet sequence is valid as long as it conforms to the character codes of the charset parameter. See [RFC2046]. Markup characters in [MDSYNTAX] are limited to printable US-ASCII; however, other variants can define markup characters outside this range (including control characters such as NUL and characters encoded in multiple octets).

マークダウンコンテンツはプレーンテキストコンテンツです。 charsetパラメータの文字コードに準拠している限り、どのオクテットシーケンスも有効です。 [RFC2046]を参照してください。 [MDSYNTAX]のマークアップ文字は、印刷可能なUS-ASCIIに制限されています。ただし、他のバリアントはこの範囲外のマークアップ文字(NULなどの制御文字や複数のオクテットでエンコードされた文字を含む)を定義できます。

Security considerations:


Markdown interpreted as plain text is relatively harmless. A text editor need only display the text. The editor SHOULD take care to handle control characters appropriately and to limit the effect of the Markdown to the text-editing area itself; malicious Unicode-based Markdown could, for example, surreptitiously change the directionality of the text. An editor for normal text would already take these control characters into consideration, however.


Markdown interpreted as a precursor to other formats, such as HTML, carries all of the security considerations as the target formats. For example, HTML can contain instructions to execute scripts, redirect the user to other web pages, download remote content, and upload personally identifiable information. Markdown also can contain islands of formal markup, such as HTML. These islands of formal markup may be passed as they are, transformed, or ignored (perhaps because the islands are conditional or incompatible) when the Markdown is processed. Since Markdown may have different interpretations depending on the tool and the environment, a better approach is to analyze (and sanitize or block) the output markup, rather than attempting to analyze the Markdown.

HTMLなどの他の形式の前兆として解釈されるMarkdownは、ターゲット形式としてすべてのセキュリティ上の考慮事項を備えています。たとえば、HTMLには、スクリプトの実行、ユーザーの別のWebページへのリダイレクト、リモートコンテンツのダウンロード、個人を特定できる情報のアップロードなどの指示を含めることができます。 Markdownには、HTMLなどの正式なマークアップのアイランドを含めることもできます。これらのフォーマルマークアップのアイランドは、Markdownの処理時にそのまま渡されるか、変換されるか、無視されます(アイランドが条件付きまたは互換性がないためと考えられます)。 Markdownの解釈はツールや環境によって異なる可能性があるため、Markdownを分析するよりも、出力マークアップを分析(およびサニタイズまたはブロック)する方が適切です。

Interoperability considerations:


Markdown variations (some might say "innovations") are designed to be broadly compatible with humans ("humane"), but not necessarily with each other. Therefore, syntax in one Markdown derivative may be ignored or treated differently in another derivative. The overall effect is a general degradation of the output that increases with the quantity of variant-specific Markdown used in the text. When it is desirable to reflect the author's intent in the output, stick with the variant identified in the variant parameter, i.e., receivers SHOULD only accept Markdown variants that they explicitly know about, and senders SHOULD avoid use of variants that intended recipients are not known to understand.


Published specification: This specification; [MDSYNTAX].

公開された仕様:この仕様。 [MDSYNTAX]。

Applications that use this media type:


Markdown conversion tools, Markdown WYSIWYG (What You See is What You Get) editors, and plain-text editors and viewers; markup processor targets indirectly use Markdown (e.g., web browsers for Markdown converted to HTML).

Markdown変換ツール、Markdown WYSIWYG(What You See is What You Get)エディター、プレーンテキストエディターとビューアー。マークアッププロセッサターゲットは、Markdownを間接的に使用します(たとえば、HTMLに変換されたMarkdownのWebブラウザ)。

Fragment identifier considerations:


See Section 3.


Additional information:


Magic number(s): None File extension(s): .md, .markdown Macintosh file type code(s): TEXT. A uniform type identifier (UTI) of "net.daringfireball.markdown", which conforms to "public.plain-text", is RECOMMENDED [MDUTI]. See [RFC7764] for other considerations.

マジックナンバー:なしファイル拡張子、.markdown Macintoshファイルタイプコード:TEXT。 「net.daringfireball.markdown」の統一型識別子(UTI)は「public.plain-text」に準拠しており、推奨[MDUTI]です。その他の考慮事項については、[RFC7764]を参照してください。

Person & email address to contact for further information:


      Sean Leonard <>

Restrictions on usage: None.


   Author/Change controller: Sean Leonard <>

Intended usage: COMMON


Provisional registration? No Implementations SHOULD record the value of the variant parameter (and other parameters if defined by the variant) along with the Markdown content when the content leaves the domain of formats that are Internet media type capable. Strategies for doing so are discussed in [RFC7764].


The Content-Disposition header (particularly the preview-type parameter) can be used with Markdown content. See Section 4.


3. Fragment Identifiers
3. フラグメント識別子

[MARKDOWN] does not define any fragment identifiers, but some variants do, and many types of Markdown processor output (e.g., HTML or PDF) will have well-defined fragment identifiers. Which fragment identifiers are available for a given document are variant-defined.


When encoded in a URI, characters that are outside of the fragment production of [RFC3986] are percent-encoded. The default encoding (character set) of percent-encoded octets in URIs is the same as the Markdown content, which is identified by the charset parameter or by other contextual means. Fragment identifiers SHOULD be considered case-sensitive, which maintains consistency with HTML. Variants MAY override the guidance in this paragraph.

URIでエンコードされると、[RFC3986]のフラグメント生成の外にある文字はパーセントエンコードされます。 URIのパーセントでエンコードされたオクテットのデフォルトのエンコーディング(文字セット)は、charsetパラメーターまたは他のコンテキスト手段によって識別されるMarkdownコンテンツと同じです。フラグメント識別子は、HTMLとの一貫性を維持する大文字と小文字を区別する必要があります。バリアントは、この段落のガイダンスをオーバーライドしてもよい(MAY)。

At least the first equals sign "=" SHOULD be percent-encoded to prevent ambiguity as described in the following section.


3.1. Parameters
3.1. パラメーター

Similar to application/pdf [RFC3778] and text/plain [RFC5147], this registration permits a parameter syntax for fragment identifiers. The syntax is a parameter name, the equals sign "=" (which MUST NOT be percent-encoded), and a parameter value. To the extent that multiple parameters can appear in a fragment production, the parameters SHALL be separated by the ampersand "&" (which MUST NOT be percent-encoded).

application / pdf [RFC3778]およびtext / plain [RFC5147]と同様に、この登録はフラグメント識別子のパラメーター構文を許可します。構文は、パラメーター名、等号 "="(パーセントでエンコードしてはなりません)、およびパラメーター値です。複数のパラメーターがフラグメント生成に現れることができる範囲で、パラメーターはアンパサンド "&"で区切られる必要があります(これはパーセントでエンコードされてはいけません)。

The only parameter defined in this registration is "line", which has the same meaning as in [RFC5147], i.e., counting is zero-based. For example: "#line=10" identifies the eleventh line of Markdown input. Implementers should take heed that different environments and character sets may have a wide range of code sequences to divide lines.

この登録で定義されている唯一のパラメータは「行」であり、これは[RFC5147]と同じ意味を持ちます。つまり、カウントはゼロベースです。例: "#line = 10"は、Markdown入力の11行目を識別します。実装者は、さまざまな環境や文字セットに、行を分割するための幅広いコードシーケンスがあることに注意する必要があります。

Markdown variants are free to define additional parameters.


4. Content Disposition and preview-type
4. コンテンツの配置とプレビュータイプ

The Content-Disposition header [RFC2183] conveys presentational information about a MIME entity, using a type and set of parameters. The parameter preview-type is defined here for Markdown content.


When present, preview-type indicates the Internet media type (and parameters) of the preview output desired from the processor by the author. With reference to the "paradigmatic use case" (i.e., collaborative Markdown editing) in Section 1.3, the preview-type parameter primarily affects the "right-hand" side of a Markdown editor. There is no default value: when absent, a Markdown user agent can render or display whatever it wants.


The value of this parameter is an Internet media type with optional parameters. The syntax (including case-sensitivity considerations) is the same as specified in [RFC2045] for the Content-Type header (with updates over time, e.g., [RFC2231] and [RFC6532]).


Implementations SHOULD anticipate and support HTML (text/html) and XHTML (application/xhtml+xml) output, to the extent that a syntax targets those markup languages. These types ought to be suitable for the majority of current purposes. However, Markdown is increasingly becoming integral to workflows where HTML is not the target output; examples range from TeX, to PDF, to Outline Processor Markup Language (OPML), and even to entire e-books (e.g., [PANDOC]).

実装は、構文がそれらのマークアップ言語をターゲットとする範囲で、HTML(text / html)およびXHTML(application / xhtml + xml)出力を予測してサポートする必要があります(SHOULD)。これらのタイプは、現在の目的の大部分に適しているはずです。ただし、Markdownは、HTMLがターゲット出力ではないワークフローにますます不可欠になっています。例は、TeXからPDF、アウトラインプロセッサマークアップ言語(OPML)、さらには電子書籍全体([PANDOC]など)にまで及びます。

The reflexive media type text/markdown in this parameter value means that the author does not want to invoke Markdown processing at all: the receiver SHOULD present the Markdown source as is.

このパラメーター値の再帰メディアタイプtext / markdownは、作成者がMarkdown処理をまったく呼び出さないことを意味します。受信者はMarkdownソースをそのまま提示する必要があります(SHOULD)。

The preview-type parameter can be used for other types of content, but the precise semantics are not defined here.


5. Example
5. 例

The following is an example of Markdown as an email attachment:


    MIME-Version: 1.0
    Content-Type: text/markdown; charset=UTF-8; variant=Original
    Content-Disposition: attachment;;
    Sample HTML 4 Markdown
    This is some sample Markdown. [Hooray!][foo]
    (Remember that link identifiers are not case-sensitive.)
    Bulleted Lists

Here are some bulleted lists...


* One Potato * Two Potato * Three Potato

* 1つのジャガイモ* 2つのジャガイモ* 3つのジャガイモ

- One Tomato - Two Tomato - Three Tomato

- 1つのトマト-2つのトマト-3つのトマト

    More Information

[.markdown, .md]( has more information.


    [fOo]: 'Will Not Work with'
6. IANA Considerations
6. IANAに関する考慮事項

IANA has registered the media type text/markdown using the application provided in Section 2 of this document.


IANA has registered preview-type in the "Content Disposition Parameters" subregistry of the "Content Disposition Values and Parameters" registry, with the following description: "Internet media type (and parameters) of the preview output desired from a processor by the author of the MIME content".

IANAは、「コンテンツディスポジションの値とパラメータ」レジストリの「コンテンツディスポジションパラメータ」サブレジストリにプレビュータイプを登録しました。以下の説明が含まれています。「作成者がプロセッサから要求したプレビュー出力のインターネットメディアタイプ(およびパラメータ) MIMEコンテンツ」。

6.1. Markdown Variants
6.1. マークダウンバリアント

IANA has established a registry called "Markdown Variants". While the registry has been created in the context of the text/markdown media type, the registry is intended for broad community use, so protocols and systems that do not rely on Internet media types can still tag Markdown content with a common variant identifier. Each entry in this registry shall consist of basic information about the variant: Identifier: unique identifier for the variant Name: the commonly known name of the variant Description: a prose description of the variant, including how it differs from other variants such as Original Additional Parameters*: additional Content-Type parameters Fragment Identifiers*: additional fragment identifier syntaxes and semantics References: URIs or other references to documentation Contact Information: whom to contact (email, URI, phone, address, etc.) Expiration Date^: when this provisional registration expires

IANAは「Markdown Variants」と呼ばれるレジストリを確立しています。レジストリはtext / markdownメディアタイプのコンテキストで作成されていますが、レジストリは幅広いコミュニティでの使用を目的としているため、インターネットメディアタイプに依存しないプロトコルとシステムは、Markdownコンテンツに共通のバリアント識別子でタグ付けできます。このレジストリの各エントリは、バリアントに関する基本情報で構成されます。識別子:バリアントの一意の識別子名前:バリアントの一般に知られている名前説明:バリアントの散文の説明。パラメータ*:追加のContent-Typeパラメータフラグメント識別子*:追加のフラグメント識別子の構文とセマンティクス参照:URIまたはドキュメントへの他の参照連絡先情報:連絡先(メール、URI、電話、アドレスなど)有効期限^:これがいつ仮登録期限切れ

* (optional) ^ (if provisional)

* (オプション)^(仮の場合)

While the variant parameter is "plain US-ASCII" (see registration template), the Identifier field (and by implication, all registered identifiers) SHALL conform to the ABNF [RFC5234]:

バリアントパラメータは「プレーンUS-ASCII」(登録テンプレートを参照)ですが、識別子フィールド(および暗黙的に、すべての登録済み識別子)はABNF [RFC5234]に準拠する必要があります。



For style and compatibility reasons, the Identifier field SHOULD conform to the ABNF:


      ALPHA *( ["-" / "." / "_" / "~"] 1*(ALPHA / DIGIT) )

That is, the identifier MUST start with a letter and MAY contain punctuation in the middle, but not at the end: the last character MUST be alphanumeric. The second production uses the same characters as the "unreserved" rule of [RFC3986] and is designed to be compatible with characters in other identification systems, e.g., filenames. Since the identifier MAY be displayed to a user -- particularly in cases where the receiver does not recognize the identifier -- the identifier SHOULD be rationally related to the vernacular name of the variant.

つまり、識別子は文字で開始する必要があり、途中に句読点を含めることはできますが、最後にはできません。最後の文字は英数字でなければなりません。 2番目のプロダクションは[RFC3986]の「予約されていない」ルールと同じ文字を使用し、ファイル名などの他の識別システムの文字と互換性があるように設計されています。識別子はユーザーに表示される可能性があるため(特に、受信者が識別子を認識しない場合)、識別子はバリアントの固有名詞と合理的に関連付けられる必要があります(SHOULD)。

The Name, Description, Additional Parameters, Fragment Identifiers, References, and Contact Information fields SHALL be in a Unicode character set (e.g., UTF-8).


The registry includes the registration in Section 6.1.4 (Original Markdown). [RFC7764] includes additional registrations.

レジストリには、セクション6.1.4(元のマークダウン)での登録が含まれています。 [RFC7764]には追加の登録が含まれています。

6.1.1. Reserved Identifiers
6.1.1. 予約済み識別子

The registry has the following identifiers RESERVED, as they have engendered some controversy in the Markdown community. No one is allowed to register them (or any case variations of them). These identifiers are not and cannot be registered: Standard Common Markdown

Markdownコミュニティでいくつかの論争が生じているため、レジストリには次の識別子が予約されています。それらを登録することはできません(またはそれらのケースバリエーション)。これらの識別子は登録されておらず、登録することもできません。StandardCommon Markdown

The registry includes the following text in the note field: The variant names Standard, Common, and Markdown are reserved and cannot be registered.


6.1.2. Standard of Review
6.1.2. レビューの基準

Registrations are made on a First Come, First Served [RFC5226] basis by anyone with a need to interoperate. While documentation is required, any level of documentation is sufficient; thus, neither Specification Required nor Expert Review are warranted. The checks prescribed by this section can be performed automatically.


All references (including contact information) MUST be verified as functional at the time of the registration.


As a special "escape valve", registrations can be updated with IETF Review [RFC5226]. All fields may be updated except the variant identifier, which is permanent: not even case may be changed.


6.1.3. Provisional Registration
6.1.3. 仮登録

Any registrant may make a provisional registration to reserve a variant identifier. Only the variant identifier and contact information fields are required; the rest are optional. Provisional registrations expire after three months, after which time the variant identifier may be reused. To make a registration permanent, a registrant simply needs to complete a permanent registration with the same identifier as the provisional registration.


6.1.4. Original Markdown
6.1.4. 元の値下げ

The registry includes this initial variant. A conforming implementation that processes the variant parameter MUST recognize this variant (although the processing behavior is not defined here).


Identifier: Original


Name: Markdown Description: Gruber's original Markdown syntax.




   Contact Information:
      (individual) John Gruber <>
7. Security Considerations
7. セキュリティに関する考慮事項

See the Security considerations entry in Section 2.


8. References
8. 参考文献
8.1. Normative References
8.1. 引用文献

[MARKDOWN] Gruber, J., "Daring Fireball: Markdown", December 2004, <>.

[MARKDOWN] Gruber、J。、「Daring Fireball:Markdown」、2004年12月、<>。

[MDSYNTAX] Gruber, J., "Daring Fireball: Markdown Syntax Documentation", December 2004, <>.

[MDSYNTAX] Gruber、J。、「Daring Fireball:Markdown Syntax Documentation」、2004年12月、<>。

[MDUTI] Gruber, J., "Daring Fireball: Uniform Type Identifier for Markdown", August 2011, < markdown-uti>.

[MDUTI] Gruber、J。、「Daring Fireball:Uniform Type Identifier for Markdown」、2011年8月、< markdown-uti>。

[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, <>.

[RFC2045] Freed、N。およびN. Borenstein、「Multipurpose Internet Mail Extensions(MIME)Part One:Format of Internet Message Bodies」、RFC 2045、DOI 10.17487 / RFC2045、1996年11月、<http://www.rfc->。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、< rfc2119>。

[RFC2183] Troost, R., Dorner, S., and K. Moore, Ed., "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, DOI 10.17487/RFC2183, August 1997, <>.

[RFC2183] Troost、R.、Dorner、S。、およびK. Moore、編、「インターネットメッセージでのプレゼンテーション情報の伝達:Content-Dispositionヘッダーフィールド」、RFC 2183、DOI 10.17487 / RFC2183、1997年8月、<http ://>。

[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, DOI 10.17487/RFC2231, November 1997, <>.

[RFC2231] Freed、N。およびK. Moore、「MIMEパラメータ値とエンコードされたワード拡張:文字セット、言語、および継続」、RFC 2231、DOI 10.17487 / RFC2231、1997年11月、<http://www.rfc->。

[RFC3778] Taft, E., Pravetz, J., Zilles, S., and L. Masinter, "The application/pdf Media Type", RFC 3778, DOI 10.17487/RFC3778, May 2004, <>.

[RFC3778] Taft、E.、Pravetz、J.、Zilles、S。、およびL. Masinter、「The application / pdf Media Type」、RFC 3778、DOI 10.17487 / RFC3778、2004年5月、<http:// www。>。

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <>.

[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier(URI):Generic Syntax」、STD 66、RFC 3986、DOI 10.17487 / RFC3986、2005年1月、<http:/ />。

[RFC5147] Wilde, E. and M. Duerst, "URI Fragment Identifiers for the text/plain Media Type", RFC 5147, DOI 10.17487/RFC5147, April 2008, <>.

[RFC5147]ワイルド、E.、M。デュエルスト、「text / plainメディアタイプのURIフラグメント識別子」、RFC 5147、DOI 10.17487 / RFC5147、2008年4月、< / rfc5147>。

[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <>.

[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、DOI 10.17487 / RFC5226、2008年5月、< / info / rfc5226>。

[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <>.

[RFC5234] Crocker、D.、Ed。、およびP. Overell、「構文仕様の拡張BNF:ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<http://www.rfc-editor .org / info / rfc5234>。

[RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized Email Headers", RFC 6532, DOI 10.17487/RFC6532, February 2012, <>.

[RFC6532] Yang、A.、Steele、S。、およびN. Freed、「Internationalized Email Headers」、RFC 6532、DOI 10.17487 / RFC6532、2012年2月、< rfc6532>。

[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <>.

[RFC6838] Freed、N.、Klensin、J。、およびT. Hansen、「メディアタイプの仕様と登録手順」、BCP 13、RFC 6838、DOI 10.17487 / RFC6838、2013年1月、<http://www.rfc->。

8.2. Informative References
8.2. 参考引用

[HUMANE] Atwood, J., "Is HTML a Humane Markup Language?", May 2008, < is-html-a-humane-markup-language/>.

[人間] Atwood、J。、「HTMLは人道的なマークアップ言語ですか?」、2008年5月、< is-html-a-humane-markup-language />。

[INETMEME] Solon, O., "Richard Dawkins on the internet's hijacking of the word 'meme'", June 2013, < richard-dawkins-memes>, <>.

[INETMEME] Solon、O。、「インターネットでのリチャードドーキンスの「meme」という単語のハイジャック」、2013年6月、< richard -dawkins-memes>、<>。

[ISO646] International Organization for Standardization, "Information technology - ISO 7-bit coded character set for information interchange", ISO Standard 646, 1991.

[ISO646]国際標準化機構、「情報技術-情報交換用のISO 7ビットコード化文字セット」、ISO標準646、1991。

[PANDOC] MacFarlane, J., "Pandoc", 2014, <>.

[PANDOC] MacFarlane、J。、「Pandoc」、2014、<>。

[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, <>.

[RFC2046] Freed、N。およびN. Borenstein、「Multipurpose Internet Mail Extensions(MIME)Part Two:Media Types」、RFC 2046、DOI 10.17487 / RFC2046、1996年11月、< / info / rfc2046>。

[RFC4263] Lilly, B., "Media Subtype Registration for Media Type text/troff", RFC 4263, DOI 10.17487/RFC4263, January 2006, <>.

[RFC4263]リリーB.、「メディアタイプtext / troffのメディアサブタイプ登録」、RFC 4263、DOI 10.17487 / RFC4263、2006年1月、<>。

[RFC7764] Leonard, S., "Guidance on Markdown: Design Philosophies, Stability Strategies, and Select Registrations", RFC 7764, DOI 10.17487/RFC7764, March 2016, <>.

[RFC7764] Leonard、S。、「Markdownに関するガイダンス:設計哲学、安定性戦略、および選択登録」、RFC 7764、DOI 10.17487 / RFC7764、2016年3月、< rfc7764>。

[UNICODE] The Unicode Consortium, "The Unicode Standard, Version 8.0", (Mountain View, CA: The Unicode Consortium, 2015. ISBN 978-1-936213-10-8), <>.

[UNICODE] Unicodeコンソーシアム「The Unicode Standard、Version 8.0」(Mountain View、CA:The Unicode Consortium、2015. ISBN 978-1-936213-10-8)、< /versions/Unicode8.0.0/>。

Author's Address


Sean Leonard Penango, Inc. 5900 Wilshire Boulevard 21st Floor Los Angeles, CA 90036 United States

Sean Leonard Penango、Inc. 5900 Wilshire Boulevard 21st Floor Los Angeles、CA 90036アメリカ