Markdownの表からJSONへ
このコンバーターは、GitHub風のMarkdownテーブルを、ブラウザ内でJSONレコードの配列に変換します。ヘッダー行がキーを提供し、セルはトリムされ、数値、ブール値、nullの型推論が行われます。空のセルはnullにマッピングされます。エスケープされたパイプはデコードされ、区切り行は必須です。何もアップロードされません。
Markdownの表からJSONへとは
Markdownテーブルは、README、ドキュメント、課題追跡ツールがレコードを表示する方法です。JSONは、スクリプトがそれらを消費する方法です。テーブルはすでに行と列を持っているため、変換とは主に列に名前を付け、各セルの意味を決定することです。このコンバーターは、GitHub風のMarkdownテーブルをJSONレコードの配列にパースします――本文行1行につき1つのオブジェクト、キーはヘッダーから取得されます。
注意が必要な部分は型付けです。Markdownのセルは単なるテキストですが、JSONには数値、ブール値、nullがあり、「42」という文字列の羅列のテーブルは、下流の何かが本当に望むものではありません。このコンバーターは推論します：数字は数値に、trueとfalseはブール値に、空のセルはnullになります。推論は時折驚くものであるため、ルール（先頭ゼロの郵便番号を含む）は、罠として残すのではなく、ここに明記します。
すべてがこのブラウザのタブで動作します：テーブルはページ内エンジンでパースされ、JSONはその横でシリアライズされ、いかなる種類のリクエストも行われません――DevToolsを開き、変換中にネットワークパネルが空のままになるのを確認してください。
テーブルは逆方向にも流れることがよくあります――JSONエクスポートをドキュメント内に配置する必要がある場合、JSONをMarkdownテーブルに変換がパイプのエスケープを適用したGitHub風テーブルを出力します。
交換のJSON側がより馴染みのない半分である場合、サイトのJSONの平易なガイドが基本的な原則からオブジェクト、配列、型について説明しています。
変換は実際にどのように機能するか
GitHub風のMarkdownは、テーブルを3つの部分で定義しています：列名のヘッダー行、ハイフンの区切り行、0行以上の本文行です。区切り行は装飾ではありません――GFMでは、それが前の行をテーブルにするものです。コンバーターは、順にこれらの部分を処理します：
- 正規化：GFMでは先頭と末尾のパイプはオプションであり、ここでは許容されます。各セルの前後の空白は、何が起こる前にトリムされます。
- 分割：セルはエスケープされていないパイプで分割されます。バックスラッシュ付きのパイプ（\|）は、値の中でリテラルの|文字になります。
- マッピング：ヘッダー行が列順にオブジェクトキーを提供し、すべての本文行がそのキーを持つ1つのオブジェクトになります。
- 型変換：各トリムされたセルは、数値、ブール値、またはnullとして推論されます。それ以外はすべて文字列のままです――ダブルクォートで囲まれたセルも含まれ、これは推論から除外されます。
型推論、平易に説明
テーブルセルには型システムがないため、コンバーターは型を選択する必要があり、正直さとは、どこで問題が発生するかを言うことです。ルールは、トリムされたセルテキストにこの順序で適用されます：
最後の2行は、よく知られた問題です。郵便番号、電話番号、製品コードが裸で入力されると数値になり、先頭のゼロは保持できません。値をリテラルとして保持するには、Markdownのセルをダブルクォートで囲み、コンバーターが文字列のままにします。これは意図的なトレードオフです：すべて文字列にすると郵便番号は救われますが、実際の数値を期待するすべてのコンシューマーを静かに壊してしまいます。
| セルの内容 | JSONの値 |
|---|---|
| 42 | 数値の42 |
| -3.5 | 数値の-3.5 |
| true / false | ブール値のtrueとfalse |
| null | null |
| （空のセル） | null |
| "02134" | 文字列の"02134"――クォートで推論から除外 |
| 02134 | 数値の2134――先頭のゼロは消える |
出力の見た目
以下の作業例は、「サンプルを読み込む」ボタンが生成するものと全く同じペアです：数値、ブール値、空のセルを持つ4列のテーブルです。2番目のレコードの空のメモセルは、空の文字列ではなく明示的なnullになるため、テーブル作成者が行った区別がJSONに保持されます。出力は、差分が読み取り可能になるように2スペースで整形されています。
このコンバーターが壊すより拒否する境界ケース
2つの不正な入力は、推測された出力ではなく名前付きエラーになります。なぜなら、そうでなければレコードが不正確なものになるためです：
- 区切り行がない――GFMでは、ハイフンの行の下にパイプの行がない場合、それはパイプを含む段落であり、テーブルではありません。区切り行がないと、ヘッダーとして信頼できるものが何もなく、コンバーターは拒否し、見つかった行を名前で特定します。
- ヘッダーより広い行――余分なセルはキーの下に存在できず、GFM自体は余分なものを静かに無視します。データを静かに削除することは、エラーよりも悪いため、コンバーターは代わりに問題のある行番号を報告します。短い行はnullでパディングされ、すべてのレコードが同じ形状を保ちます。
よくある質問
MarkdownテーブルをJSONに変換すると、データがどこかにアップロードされますか？
いいえ。パースとシリアライズの両方が、このブラウザのタブ内、ページと一緒に読み込まれたJavaScriptで行われます。ページのコードにはアップロードのエンドポイントがなく、サイトのContent-Security-Policyは送信接続をブロックするため、ページは偶発的にでも「ホームに電話」できません。数秒で確認できます：DevToolsを開き、ネットワークパネルを監視し、変換してください――リクエストは表示されません。
なぜハイフンの区切り行は必須ですか？
GitHub風のMarkdownでは、区切り行（| --- | --- |）が2行のパイプをテーブルに変えるものです。これがないと、テキストは単にパイプを含む段落です。ヘッダーがJSONキーを提供するため、区切り行がないとスキーマとして使用できる信頼できるものが何もなく、コンバーターは入力を拒否し、行を名前で特定します。:---:のような配置コロンは許容されます。
セル内にリテラルのパイプ文字を入れるにはどうすればよいですか？
バックスラッシュでエスケープします：セル内の\|は、JSON文字列内の単一の|になります。これはGFMのルールであり、コンバーターの好みではありません――エスケープされていないパイプは列区切りとして読み取られ、その後のすべてのセルがシフトします。逆コンバーターはテーブルを書き出す際に同じエスケープを適用するため、パイプを持つ値は往復で変更されません。
先頭にゼロがある値、例えば郵便番号はどうなりますか？
裸の02134は数値の2134として推論されます。なぜなら、JSONの数値は先頭のゼロを表現できないからです。コンバーターは郵便番号、電話番号、SKUコードについて静的な例外を作ることはありません――代わりにルールを明示します。値をテキストとして保持するには、Markdownでセルをダブルクォートで囲みます（"02134"）。クォートは意図的な文字列としてマークされ、値からは削除されます。
行のセル数が異なる場合はどうなりますか？
ヘッダーより短い行は、欠落した列ごとにnullでパディングされ、すべてのレコードが同じ形状を保ちます。ヘッダーより長い行は行番号で拒否されます。なぜなら、余分なセルにはキーがなく、それらを破棄するとレコードが静かに壊れてしまうからです。行を修正してください。スキーマではありません。
JSONをMarkdownテーブルに戻すことはできますか？
はい――この方向の変換はこのサイトで完全にサポートされています。JSONをMarkdownテーブルに変換するコンバーターは、レコードの配列を受け取り、キーをヘッダーに結合し、必要に応じてパイプのエスケープを適用したGFMテーブルを出力します。2つのページを合わせると、テーブルが表現できるすべての形状について、ドキュメントの往復が損失なしに行われます。