再構造化テキスト
| 再構造化テキスト | |
|---|---|
| ファイル名拡張子 | .rst |
| インターネットメディアの種類 |
|
| 開発者 | デビッド・グッドガー |
| 初回リリース | 2001年6月1日[1] |
| 最新リリース | 改訂 8407 2019年10月29日 |
| オープンフォーマット? | パブリックドメイン |
| Webサイト | docutils.sourceforge.io/rst.html |
reStructuredText ( RST、ReST、またはreST ) は、主にPython プログラミング言語コミュニティで技術ドキュメント用に使用されるテキスト データのファイル形式です。
これはPython Doc-SIG(Documentation Special Interest Group)のDocutilsプロジェクトの一部であり、JavaのJavadocやPerlのPlain Old Documentation(POD)に似たツールセットをPython用に作成することを目的としています。DocutilsはPythonプログラムからコメントや情報を抽出し、様々な形式のプログラムドキュメントにフォーマットすることができます。[2]
この意味で、reStructuredText は、 Docutils などのドキュメント処理ソフトウェアで処理可能であり、かつ Pythonソースコードを読み書きする人間のプログラマーが簡単に読めるように設計された軽量マークアップ言語です。
歴史
reStructuredTextは、 Zopeによって開発されたStructuredText [3]と呼ばれる軽量マークアップ言語から発展したものです。StructuredTextには多くの問題があり、reSTはそれらの問題を解決するために開発されました。[4] reStructuredTextという名前は、reSTが「改訂、再加工、そして再解釈されたStructuredText」であることを示すために選ばれました。[5]
reST構文の一部は、1990年代初頭のSetext言語に影響を受けています。また、 RFC822インターネットメッセージフォーマットとJavadocフォーマットの要素も設計に取り入れることが検討されました。[6]
reStructuredTextは2001年6月に初めてリリースされました。[1] Pythonコミュニティでは2002年に広く使われるようになりました。[7]
リファレンス実装
reSTパーサーのリファレンス実装は、 Python プログラミング言語の Docutils テキスト処理フレームワークのコンポーネントですが、他のパーサーも利用可能です。
DocutilsプロジェクトはreStructuredTextのMIMEタイプを登録しておらず、未登録のMIMEタイプを公式として指定していませんが、Pythonウェブサイトのビルドシステムなどで事実上text/x-rst使用されているMIMEタイプを文書化しています。 [8]同じMIMEタイプがLinuxのデスクトップ環境で使用されているfreedesktop.orgファイルタイプデータベースで使用されています。[9]別のMIMEタイプである は、reStructuredTextを表すために2003年にサードパーティによってバニティMIMEタイプとして登録され、reStructuredTextの唯一のIANA登録MIMEタイプとなっていますが、[10] Docutilsプロジェクトではそのように認められていません。[8]text/prs.fallenstein.rst
アプリケーション
reStructuredTextは、Pythonライブラリのドキュメントなど、技術文書によく使用されます。[11]ただし、幅広いテキストに適しています。
2008 年以来、reST は Python のSphinxドキュメント生成システムの中核コンポーネントとなっています。
TracもreStructuredTextをサポートしており、[12] GitHubやBitbucketも同様です。
2011年、プロジェクト・グーテンベルクのテキストを準備していたDistributed Proofreadersは、他の電子書籍フォーマットを生成するための基本フォーマットとしてreSTの採用を検討していました。[13] [更新が必要]
2016年7月、LinuxカーネルプロジェクトはDocBookベースのドキュメントからreStructuredTextとSphinxツールチェーンに移行することを決定しました。[14] [15] [循環参照]
ソフトウェアビルドツールCMakeは、バージョン3.0でドキュメント作成にカスタムマークアップ言語からreStructuredTextを採用しました。[16]
例
| rST構文を使用したテキスト | rSTプロセッサによって生成された対応するHTML | ブラウザで表示されるテキスト |
|---|---|---|
================ドキュメントの見出し=================見出し=======小見出し-----------段落は区切られる空白行で区切られます。 | < h1 >ドキュメントの見出し</ h1 >< h2 >見出し</ h2 >< h3 >小見出し</ h3 >< p >段落は区切られています空白行で区切られます。</ p > | 段落は空白行で区切られます。 |
テキスト属性*emphasis*、**strong enhancement**、``monospace``。水平線:---- | < p >テキスト属性< em >強調</ em >、 < strong >強い強調</ strong >、< code >等幅</ code >。</ p >< p >水平線: </ p ><時間 /> | テキスト属性は強調、強い強調、monospace。水平線: |
箇条書き:*リンゴ*オレンジ*ナシ番号付きリスト:1.泡立てる2.すすぐ3.繰り返すネストされたリスト:1.果物 *リンゴ *バナナ2.野菜 *ニンジン *ブロッコリー | < p >箇条書き: </ p >< ul > < li >リンゴ</ li > < li >オレンジ</ li > < li >梨</ li > </ ul >< p >番号付きリスト: </ p >< ol > < li >泡立てる</ li > < li >洗い流す</ li > < li >繰り返す</ li > </ ol >< p >ネストされたリスト: </ p >< ol > < li >果物 < ul > < li >リンゴ</ li > < li >バナナ</ li > </ ul > </ li > < li >野菜 < ul > < li >ニンジン</ li > < li >ブロッコリー</ li > </ ul > </ li > </ ol > | 箇条書き:
番号付きリスト:
ネストされたリスト:
|
`example < http://example.com> `_。.. 画像:: Icon-pictures.png :alt:画像テキストがインデントされている場合、それはブロック引用として扱われ、最後の帰属行は自動的に処理されます。 配列のインデックスは 0 から始まるべきでしょうか、それとも 1 から始まるべきでしょうか? 私が提案した妥協案の 0.5 は、適切な検討もなしに拒否されたように思いました。 -- スタン・ケリー・ブートルreST は、事前にフォーマットされたコードブロック::の前の段落の末尾に :: を使用します。 Y = ラムダ f: (ラムダ x: f(x(x)))(ラムダ x: f(x(x)))|複数行のテキストは、パイプ文字を使用して表内にまたがる
ことができます。 | < p > < a href = "http://example.com" >の例</ a >。</ p >< p >< img alt = "画像" src = "Icon-pictures.png" /></ p >< p >テキストがインデントされている場合は、ブロック引用として扱われ、最後の帰属行は自動的に処理されます。</ p > < blockquote >配列のインデックスは 0 から始まるべきでしょうか、それとも 1 から始まるべきでしょうか?私が提案した妥協案の 0.5 は、適切な検討もなしに拒否されたように思いました。-- スタン・ケリー・ブートル</ blockquote >< p > reST は、書式設定されたコードブロックの前の段落の末尾に :: を使用します: </ p > < pre class = "literal-block" >Y = ラムダ f: (ラムダ x: f(x(x)))(ラムダ x: f(x(x)))</ pre >< p >複数行のテキストは、パイプ文字を使用して表内で< br />区切ることができます。 < br /> </ p > | 例。
テキストがインデントされている場合、それはブロック引用として扱われ、最後の帰属行は自動的に処理されます。
reST は、事前にフォーマットされたコード ブロックの前の段落の末尾に :: を使用します。 Y = ラムダ f: (ラムダ x: f(x(x)))(ラムダ x: f(x(x))) パイプ文字を使用すると、複数行のテキストを |
参照
参考文献
- ^ ab “Project: reStructuredText - File List”. SourceForge . 2001年10月19日時点のオリジナルよりアーカイブ。2023年2月5日閲覧。
- ^ Mertz, David (2003-02-01). 「XML Matters: reStructuredText」. IBM developerWorks . 2016年10月5日閲覧。
- ^ "zope.structuredtext ドキュメント".ドキュメントを読む. 2022年8月16日閲覧。
- ^ Goodger, David (2016年5月24日). 「StructuredTextの問題」. Docutilsプロジェクト. 2022年8月16日閲覧。
- ^ Goodger, David (2016年2月26日). 「Docutils FAQ (よくある質問)」. Docutilsプロジェクト. 2016年10月5日閲覧。
- ^ Goodger, David (2022年4月2日). 「reStructuredText構文代替案の記録」. docutils.sourceforge.io . Docutilsプロジェクト. 2022年8月16日閲覧。
- ^ 「reStructuredText入門」Write The Docs . 2022年6月25日閲覧。
- ^ ab 「reStructuredTextデータの公式MIMEタイプは何ですか?」(Docutils FAQ). Docutilsプロジェクト. 2017年12月20日閲覧。
- ^ "freedesktop.org.xml.in". shared-mime-info . freedesktop.org .
- ^ Fallenstein, Benja (2003-10-02). "text/prs.fallenstein.rst". IANA .
ReStructuredTextはDavid Goodgerによって設計・実装されたものであり、このメディアタイプの登録者によるものではありません。登録者はたまたまこのメディアタイプの登録を必要としていたのです。[…] この登録の変更管理は現在Benja Fallensteinが行っています。(ReStructuredTextにもっと深く関わっている方が引き継ぎたい場合は、喜んで引き継ぎます。)
- ^ Goodger, David (2002-04-02). 「PEP 287 -- reStructuredText Docstring Format」. Python Software Foundation . 2016年10月5日閲覧。
- ^ "TracにおけるreStructuredTextのサポート". Trac . 2016年9月13日. 2016年10月5日閲覧。
- ^ Newby, Greg (2011年1月8日). 「2010年12月11日の会議議事録」 . Distributed Proofreaders . 2011年1月8日閲覧。
- ^ 「Sphinxによるカーネルドキュメント作成、パート1:これまでの経緯」LWN.net、2016年7月6日。 2016年10月27日閲覧。
- ^ 「Sphinx. Linuxカーネル」Wikipedia. 2024年4月2日. 2024年4月2日閲覧。
- ^ 「CMake 3.0.0 リリースノート」. Kitware, Inc. 2014年6月10日. 2016年10月5日閲覧。
外部リンク
- 参考ページ付きの公式reStructuredTextウェブサイト