内容はサーバーにアップロードされますか？
されません。ソースの整理、プレビューの描画、リッチテキストの変換、ダウンロードはすべてブラウザ内の JavaScript で完結します。ページにバックエンドの API はなく、貼り付けた内容がどのサーバーにも送信されることはありません。未公開の原稿や社内文書の処理にも向いています。最も直接的な確認方法は、ページを読み込んだあとネットワークを切ってみることです。それでもツールは通常どおり動きます。
この言葉は二つの意味に取られがちです。一つは .md を整った見た目に描画して読むこと。それは閲覧であり、MD ファイルをオンラインで開くの役割です。もう一つはソースそのものをきちんと書くこと。空行が必要な場所に空行を入れ、揃えるべき表を揃える、といった作業です。このページが行うのは後者で、入るのも出るのも Markdown、ただ整っているだけです。誰かに渡して読んでもらうのが目的なら、必要なのはおそらくMarkdown → Word / PDF 変換。
Markdown には空白に敏感な箇所がいくつかあり、間違えてもエラーにはならず、ただ黙って別のものとして描画されます。最も多いのは、リストが前の段落のすぐ下に空行なしで置かれている場合で、多くのレンダラーはリスト全体を普通の段落の続きとみなし、記号をそのまま表示します。見出しの # の後ろのスペース抜けも同じ種類の問題で、GitHub では効かないのに一部のエディタでは正常に見えます。こうした不具合はソースを見ている限り問題なさそうで、別の場所で開いて初めてレイアウトが崩れていると分かります。空行を補う項目が直しているのはこれで、「見た目を良くした」のではなく「正しく直した」に当たります。
漢字かなと英字・数字が隣り合うときに半角スペースを 1 つ入れるのは、中国語圏の技術文書で広く行われている組版の習慣です。漢字は正方形で、ラテン文字はそうではないため、間を空けないと両者が詰まって見えるからです。本ツールはこの規則で処理し、あわせて日本語の後ろで誤って使われた半角のカンマ・ピリオド・疑問符を全角に置き換えます。ただし 2 か所は意図的に触りません。コードブロックとインラインコードの中身は 1 バイトも変更しません。そうしないと my_var_name のような識別子が壊れてしまいます。また中文.md のように後ろに英字が続くピリオドも句点とはみなさず、本当に文末にあるものだけを変換します。英語の文書なら「日本語まわりの組版」の 2 項目をオフにしてください。
これらの場所からコピーすると、クリップボードにはプレーンテキストのほかに HTML も入り、見出し・リスト・表・太字といった構造がそこに記されています。ですから貼り付け時に Markdown へ変換するのは確定的な変換であって、文字の見た目から推測しているわけではありません。逆に、プレーンテキストを貼り付けても自動で # と -が付くことはありません。その手の推測はよく外れますし、外れたときの代償は手作業での戻し作業です。プレーンテキストだけが欲しい場合は Ctrl+Shift+V を押すか、「貼り付け」の項目のチェックを外してください。
ソースの整理は純粋なテキスト処理であり、プレビューの描画もブラウザ内で完結できるため、サーバーに渡さなければならない工程は一つもありません。これはプライバシー上の利点だけではありません。アップロードしないのでファイルサイズの上限も、順番待ちも、回数制限もなく、ページの読み込み後にネットワークを切っても動作します。未公開の原稿、社内文書、書きかけの技術メモを、素性の知らないサーバーに預ける必要はありません。
されません。ソースの整理、プレビューの描画、リッチテキストの変換、ダウンロードはすべてブラウザ内の JavaScript で完結します。ページにバックエンドの API はなく、貼り付けた内容がどのサーバーにも送信されることはありません。未公開の原稿や社内文書の処理にも向いています。最も直接的な確認方法は、ページを読み込んだあとネットワークを切ってみることです。それでもツールは通常どおり動きます。
されません。 ``` または ~~~ で囲まれたコードブロックと、バッククォートで囲まれたインラインコードは 1 バイトも変更しません。スペースの追加も約物の変更もインデントの変更も再整形も行いません。これは絶対の制約です。そうでなければ my_var_name が斜体とみなされ、a,b の中のカンマが全角に置き換えられ、コードが動かなくなってしまいます。リンク内の URL も同様に保護され、処理されるのはリンクの表示文字だけです。
付きません。これは意図的にそうしています。Word や Web ページからコピーした内容はクリップボードに HTML を伴い、見出しやリストが明示されているため、Markdown への変換は確定的です。一方、プレーンテキストのどの行が見出しでどの行がリストなのかは見た目から推測するしかなく、外れたときは手作業で戻す必要があり、自分で # を打つより手間がかかります。そのためこのページは、書式付きの内容を検出したときだけ自動変換します。
最も多い原因は、リストが前の段落のすぐ下にあり、間に空行がないことです。GitHub は CommonMark に従って解析するため、この書き方ではリストが前の段落の続きとみなされ、 - がそのまま表示されます。もう一つよくある原因は、見出しの # の後ろのスペース抜けです。内容を貼り付けて「整形」を押してください。「見出し・リスト・コードブロック・表の前後に空行を補う」と「見出しは # 記法に統一」の 2 項目がまさにこれを直します。
仕様上の要求ではなく、中国語圏の技術文書で広く行われている組版の習慣です。多くの技術文書やチームの執筆規約がこの方式を採っています。Markdown の解析には影響せず、純粋に読みやすさの問題です。プロジェクトがそう求めていない場合や、文書がもともと英語の場合は、「日本語まわりの組版」の 2 項目のチェックを外せば、それ以外の整理はそのまま実行されます。
「番号付きリストを振り直す」にチェックが入っていれば 1. 2. 3. に変わります。すべてを 1. と書くのはよくある書き方で、描画結果は連番と完全に同じです。途中に項目を挿入しても後続の番号を直さずに済むという利点もあります。この書き方を残したい場合は、この項目をオフにしてください。なお注意点として、空行 1 つだけを挟んだ 2 つの番号付きリストは、CommonMark では依然として同じリストとみなされます。そのため番号は続けて振られ、1 に戻りません。本当に分けるには、間に段落や別の内容を挟む必要があります。
されません。Markdown では行末の 2 個のスペースが強制改行を意味します。ツールはこの書き方を認識して残し、3 個以上ある場合はちょうど 2 個にまとめます。打ち間違いとして一括削除することはありません。削除されるのはそれ以外の場合の行末の空白だけです。バックスラッシュで改行する書き方を使っている場合は、もともと影響を受けません。
崩れることはあります。位置合わせはセルにスペースを補うことで行っており、全角文字は等幅フォントで 2 文字分の幅を占めます。ツールはこの規則で計算するため、VS Code や Typora のように等幅で表示される環境では揃います。ソースをプロポーショナルフォントで表示するエディタでは揃って見えません。これはソースの見た目だけの問題で、描画された表は常に正しく表示されます。描画は縦線の位置だけを見ており、スペースの数は見ていないからです。
あちらは純粋なビューアです。ドラッグすれば整った見た目でそのまま読め、編集も書き出しもしません。受け取った README をひととおり読みたいときに向いています。このページはソースを書き換え、出力もやはり Markdown です。読みたいときはMD ファイルをオンラインで開く、整えたいときはこのページを使ってください。
このページで「コピー」を押し、Markdown → Word / PDF 変換に貼り付けて書き出してください。先に「.md をダウンロード」してから、そのファイルをあちらのページにドラッグしても構いません。2 ページに分かれているのは成果物が違うからです。こちらは Markdown のソースを、あちらは同僚にそのまま送れる .docx や .pdf を返します。
表には対応しており、列幅を揃えます。タスクリスト（- [ ]）、取り消し線、脚注といった拡張記法はそのまま保持され、壊れることはありません。ただしそれら専用の整理ルールはありません。プレビューには GitHub 風のパーサーを使っているため、表とタスクリストは右側で正しく表示されます。
整理そのものは純粋なテキスト処理なので、数万行でも高速です。重くなり得るのは右側のリアルタイムプレビューで、要素ごとに DOM を生成する必要があります。文書が非常に大きくて重いと感じる場合は、必要な部分だけを切り出して処理してください。再描画は入力が止まってから約 0.2 秒後に行われるため、通常の入力で 1 文字ごとに再レイアウトされることはありません。