少し前まで、プログラムがデータを処理するだけでなく、人を読み取り、編集（およびテキストエディターでゼロから作成）できるように、データをテキスト形式で保存できるようにするタスクに直面しました。 JSON、YAML、XMLなど、このための便利で適切なフォーマットがすでに多数あります。 しかし、考慮されたシステムでは、それでも少し好きではなかった瞬間がありました。
私は非常に強力で人気のあるものを含むこれらの形式のほとんどの自然な不便さに自然に注意します（当然、私の意見では）-テキストを保存する問題：テキスト文字を含むことができるテキストフィールドを書く方法サービスの組み合わせに一致するさまざまな部分文字列やさまざまな非標準のインデントが見つかるため、解析に影響はありませんでした。 たとえば、XMLでは、テキストに文字 "<"および ">"を含めることはできません。これらの文字は "＆lt;"に置き換える必要があります および＆gt; それに応じて。 他の多くのシステムでは、テキストを引用符で囲む必要があります。 しかし、テキストに既に引用符が含まれている場合はどうでしょうか？ 他の種類の引用符を使用しますか？ スクリーンに？ これはすべて、テキストに変更を加える必要があることを意味します。その後、ノートパッドやブラウザーの入力フィールド（テキスト領域）などの通常のテキストエディターでデータを操作する必要がある場合は、テキストを読んだり編集したりすると便利です。 また、テキストを引用符で囲む必要のないYAML形式もありますが、正しいインデントを確認することは非常に重要です。これは、複数行および複数レベルのデータを保存するのにあまり便利ではないようです。 また、非データ文字の割合も増加します。各行の左側にあるいくつかのサービススペースにより、重みが大幅に増加します。
テキストに加えて、実際にはさらに2つの基本的なデータ型（整数と小数、および関連付け（データ構造（ブロック）と配列））を保存する必要がありました。 つまり、整数、浮動小数点、テキスト、構造、配列の5つのタイプが取得されます。 マクロ、式、その他の拡張機能を使用する必要はありませんでした-必要なのは、さまざまなブロックと配列に分散された数字とテキストだけです。 このような単純さに関連して、上記のポイントを考慮に入れて、とりわけテキストフィールドを格納できる、非常に単純な形式が必要でした。 また、構文を理解して覚えやすくするために、できるだけ少ない制御文字でデータを見たいと思いました。
一般に、
データフィールドには、単一行（整数、浮動小数点、単一行テキスト）と複数行（構造、配列、複数行テキスト）があります。 最初にフィールド名が書き込まれ、次に制御文字が書き込まれます。これは、フィールド値が1行または複数行を占めることを示します。 そして、フィールド値。 複数の行がある場合、値の最後に終了行が示されます。 実際、これがこのフォーマットの主要なエッセンスであり、簡単に説明しています。
HVフォーマットの機能を例で最も明確に示します。
構文の特徴が明確になるように、一般的な説明から始めて、徐々に、記事で提起された問題を解決するという私のビジョンに進みます。
a：1 b：2.2 c：abcd
以下に3つの単純なデータ型を示します。
aは1に等しい整数です
bは2.2に等しい浮動小数点数です
c-「abcd」に等しい1行で構成されるテキストフィールド
次の例には、データ構造と、この構造内にある配列があります。
xxq +
a：12.33
b：-15
x +
：ab
：cd
：ef
^
^
ここで、構造には2つのフィールドが含まれています。
aは12.33に等しい浮動小数点数です
bは-15に等しい整数です
xは、「ab」、「cd」、および「ef」に等しいテキストフィールドの配列です。
配列要素の場合、フィールド名は書き込まれません。
インデントは重要ではなく、次の例のデータは前のデータとまったく同じであるとすぐに言わなければなりません。
xxq +
a：12.33
b：-15
x +
：ab
：cd
：ef
^
^
そして、オプションは同じデータを表示することですが、スペースはまったくありません：
xxq + a：12.33 b：-15 x + ：ab ：cd ：ef ^ ^
したがって、最も重要な制御文字は「：」（値が1行を占める場合）および「+」（値が複数行を占める場合）です。
そして今、直接、さまざまな文字を含む複数行のテキストを表す問題を解決するという私のビジョン：
t + Abcd EFGH <12> @@ ijklmnopq 「ABC」+「DEF」=「ABCDEF」 "A（ 'a'）" = // = "B"（ '' ''）\ abcd ^
この例では、テキストは次のとおりです。
Abcd EFGH <12> @@ ijklmnopq 「ABC」+「DEF」=「ABCDEF」 "A（ 'a'）" = // = "B"（ '' ''）\ abcd
テキストに含まれる引用符、スラッシュ、およびその他の文字は、いかなる方法でも置換またはエスケープされません-これは必要ありません。 つまり、テキストは完全にオリジナルのままであり、追加の変換を必要としません。
テキストは終了行に制限されます。 終了文字列は、デフォルトではエスケープ文字「^」に等しくなります。 同じ行を使用して、構造や配列などのすべての複数行フィールドを補完します（上記の例に示されています）。 値は、終了行に達するまで、インデントなしで行ごとに読み取られます。 これは部分文字列ではなく、文字列全体です（私が言ったように、インデントは無視され、任意になります）。
テキストフィールドを書くとき、2つの非常に合理的な質問が生じるかもしれません：
1）ソーステキストに、末尾に等しい行、つまり「^」がある場合はどうなりますか？
2）テキスト内のインデントが重要であり、無視できない場合はどうなりますか？
最初のケースを解決するために、HV形式では最終行を再定義できます。 フィールド値の前と、それに応じて次のように指定する必要があります。
eee + END こんにちは ^ ^ ^ ^ abcd 終了
eeeフィールドに含まれるテキストは次のとおりです。
こんにちは ^ ^ ^ ^ abcd
重要なニュアンスは、最終行の再定義がテキストフィールドに対してのみ可能であることです。 残りの複数行の値（構造と配列）は、常にサービス文字「^」で終わります。
2番目のケース（インデントが重要）を解決するには、HVには2つのオプションがあります。
オプションA.各行のテキストの左右にあるすべてのインデントを考慮します。
テキスト@
これは赤い線です。
そして、これは普通の行です。
行の先頭からのすべてのインデントが保存されます。
テキスト内。
行くぞ
^
オプションB.各行の最初の非空白文字のインデントを考慮に入れます。この最初の文字自体は考慮されません。
テキスト％
-A
* B
=どこかで
^
テキストは次のとおりです。
A B どこで
興味深い機能は、シリアル化されたデータをテキストとしてカプセル化することです。
私は別の機能に注意を喚起したいと思います。これは非常に興味深く、便利で、ほとんどユニークですが、そのアプリケーションの必要性は非常にまれです。 この機能は、末尾の行を置き換えて元のテキストを変更しないままにする可能性があるため、自動的に利用可能です。 ポイントは、この方法で、HV形式の一部のデータをテキストフィールドとしてHV形式の他のデータに挿入できることです。 これにより、構文解析時に構文エラーが発生することはありません。 これは、異なるレベルに複数のワードプロセッサがあり、それぞれのフォーマットがわからない場合に便利です。テキストを次のレベルに転送するだけです。
たとえば、最初のレベルでは、2つのアレイをHV形式で転送する必要があります。
ただし、これはテキストの形式で第2レベルに送信する必要があります。
for_level_1フィールドはテキストフィールドです。 ここで、終了行は単に「＆」に置き換えられます。
例の条件に従って、2番目のレベルで最初のレベルを対象としたデータを一度に解析することは不可能です-2番目のレベルはこのテキストの処理方法を認識していません-HV、JSON、または解析対象ではないテキストがあるかもしれません これにより、（例の条件に従って）最初のレベルが解決されます。
つまり、HVテキストフィールドでは、少なくとも同じHV、少なくともJSON、XML、YAMLなどのシリアル化されたデータを転送できます。 テキストを編集せずに安全にカプセル化する機会。私は検討したどのフォーマットでも会ったことがありません。 この機能は、必要とされることはめったにありませんが、それでもあります。
たとえば、最初のレベルでは、2つのアレイをHV形式で転送する必要があります。
+ ：1 ：2 ^ b + ：3 ：4 ^
ただし、これはテキストの形式で第2レベルに送信する必要があります。
level_2 +
for_level_1 +＆
+
：1
：2
^
b +
：3
：4
^
＆
^
for_level_1フィールドはテキストフィールドです。 ここで、終了行は単に「＆」に置き換えられます。
例の条件に従って、2番目のレベルで最初のレベルを対象としたデータを一度に解析することは不可能です-2番目のレベルはこのテキストの処理方法を認識していません-HV、JSON、または解析対象ではないテキストがあるかもしれません これにより、（例の条件に従って）最初のレベルが解決されます。
つまり、HVテキストフィールドでは、少なくとも同じHV、少なくともJSON、XML、YAMLなどのシリアル化されたデータを転送できます。 テキストを編集せずに安全にカプセル化する機会。私は検討したどのフォーマットでも会ったことがありません。 この機能は、必要とされることはめったにありませんが、それでもあります。
そのため、主なキーキャラクターは次の3つです。
：-1行の値
+-複数行の値
^-複数行の値の終わり
さらに3つ：
@-フォーマットされた複数行テキスト
％-マークアップされた複数行テキスト
＃-コメント
必須の括弧、引用符、データ型の明示的な指示はありません。 入力とすべてのコンプライアンスチェックはHVハンドラーで実行されます。彼は、発生する可能性のあるフィールド名と、それらに含まれるタイプとフォーマットの値をあらかじめ知っています。 過度に単純なため、ほとんどすべてのプログラミング言語に移植できます。
一見したところ、HVはYAMLに似ているように見えるかもしれません-また、ミニマルで、引用なしのテキストです。 ただし、HVはゼロから作成され、既存の形式に基づいていないため、YAMLには類似点よりも多くの違いがあります。 HVは、要求の厳しいインデントです。 YAMLではインデントが必要であり、「---」、「：|-」、「：>」、HVなどの2文字以上の組み合わせを使用することが多いため、HV形式のサービステキストの合計シェアは小さくなります。常に単一の文字のみ。 しかし、私は、考慮されたフォーマットのいずれかでテキストを再定義された最終行に制限するメカニズムを見たことはありません。 そして、私には思えますが、これはかなり便利で直感的なメカニズムです。
一般に、単純なデータを保存するための、このような簡潔なフォーマットを手に入れました。 もちろん、関数、連想配列、マクロ、プリプロセッサー、クロージャー、算術式など、他の多くの形式が誇ることができるクールなもののストレージはありません。 しかし、これらの添え字は必要ありません。HV形式は、上記のタスクに対応し、上記のタスクを実行して解決するためです。たとえば、テキストを引用符や括弧で囲む必要はありません。最も基本的なタイプのセットをサポートし、サービス文字をほとんど使用しないなど。
HVフォーマットとその機能を作成する理由を正しく説明できたと思います。 まだ不明な点がある場合は、適切な質問に答えていただければ幸いです。
HV形式をより詳しく知りたい人のために、リソースhttp://vaomark.com/z23F0Czには、より詳細な説明と、すべての側面をカバーする多数の例があります。
HVハンドラーの現在のソースコードとPython 2.7のテストモジュールをそこからダウンロードすることもできます。 ところで、近い将来、C ++、Java、PHP、およびその他の言語にハンドラーを移植する予定です-すべてが同じリンクで利用可能になります。
PS：HV形式は、テキストフィールドをシリアル化された形式で保存するという問題を解決するという私のビジョンに基づいているため、値は元の変更されていない形式であり、簡単なエディターで簡単に読み取りおよび変更できます。 誰かが成功した決定が判明したと考えるだろう、誰か-それどころか; 多分誰かが自分のものを提供するでしょう。 記事で提起された問題は、すべてが非常に便利な問題ではないと考えている人がいます。 ご意見をお聞かせください。