CSA形式: komabetsuline の中身が空だと読み込めない

[mizar]

Shogi.js の toCSAString() は例えば平手初期局面だと以下のような出力（P+,P-の行に記述される駒が空）をしますが、

input:

(new ShogiJS.Shogi()).toCSAString()

output:

'P1-KY-KE-GI-KI-OU-KI-GI-KE-KY\nP2 * -HI *  *  *  *  * -KA * \nP3-FU-FU-FU-FU-FU-FU-FU-FU-FU\nP4 *  *  *  *  *  *  *  *  * \nP5 *  *  *  *  *  *  *  *  * \nP6 *  *  *  *  *  *  *  *  * \nP7+FU+FU+FU+FU+FU+FU+FU+FU+FU\nP8 * +KA *  *  *  *  * +HI * \nP9+KY+KE+GI+KI+OU+KI+GI+KE+KY\nP+\nP-\n+'

output:

P1-KY-KE-GI-KI-OU-KI-GI-KE-KY
P2 * -HI *  *  *  *  * -KA * 
P3-FU-FU-FU-FU-FU-FU-FU-FU-FU
P4 *  *  *  *  *  *  *  *  * 
P5 *  *  *  *  *  *  *  *  * 
P6 *  *  *  *  *  *  *  *  * 
P7+FU+FU+FU+FU+FU+FU+FU+FU+FU
P8 * +KA *  *  *  *  * +HI * 
P9+KY+KE+GI+KI+OU+KI+GI+KE+KY
P+
P-
+

これは JSONKifuFormat.JKFPlayer.parseCSA() では解釈できない文字列となっているようです。

input:

JSONKifuFormat.JKFPlayer.parseCSA((new ShogiJS.Shogi()).toCSAString())

error:

{
    "message": "Expected [0-9] but \"\\n\" found.",
    "expected": [
        {
            "type": "class",
            "parts": [
                [
                    "0",
                    "9"
                ]
            ],
            "inverted": false,
            "ignoreCase": false
        }
    ],
    "found": "\n",
    "location": {
        "start": {
            "offset": 272,
            "line": 10,
            "column": 3
        },
        "end": {
            "offset": 273,
            "line": 11,
            "column": 1
        }
    },
    "name": "SyntaxError"
}

json-kifu-format/src/peg/csa-parser.pegjs

Line 132 in 879bcdf

komabetsuline = "P" teban:teban pieces:(xypiece)+ nl {return {teban: teban, pieces: pieces}}

にて、 pieces:(xypiece)+ と1つ以上の持ち駒が記述される前提となっている事が原因のようです。

[gemmaro]

CSAの解釈によっては、 toCSAString を変更する見方もできそうです。

CSA標準棋譜ファイル形式 (V2.2)（以下便宜上CSAと呼びます）の「2.5 開始局面」の文脈から、挙げていただいた指将棋初期局面の例での toCSAString は、一括表現と駒別単独表現の両方を出力しています。ただし駒別単独表現は空です。

ここで疑問が2点あります：

• このような同居（複数の開始局面の表現が1つの棋譜に含まれること。例：一括表現と駒別単独表現の同居）の妥当性がわからない。 ...a
• 空の駒別単独表現（例： P+, P-）の妥当性がわからない。 ...b
  • 実際のCSA形式の棋譜が大量に存在する場合は覆る可能性はありますが、後者については個人的に妥当ではないと思っています。なぜなら「一つ一つの駒を示すときは、先後の区別に続き、位置と駒の種類を記述する。」とあり、明示的に空の表現が許される旨の記述がないためです。

以上の疑問についてそれぞれ場合分けをすると次のようになります：

	aが妥当	aが妥当ではない
bが妥当	w	x
bが妥当ではない	y	z

• w: parseCSA は空の駒別単独表現を受理するように修正する必要があります。なお、 toCSAString は変更する必要はありません。
• x: toCSAString は一括表現のみを出力するように修正する必要があります。また、 parseCSA は空の駒別単独表現を受理するように修正する必要があります。
• y: toCSAString は空の駒別単独表現を出力しないように修正する必要があります（複数の開始局面の表現を出力することはOKです）。ただし、 parseCSA は変更できません。
• z: toCSAString は複数の開始局面の表現を出力しないように修正する必要があります。ただし、 parseCSA は変更できません。

説明がややこしくなってしまい恐縮ですが、以上について検討する必要があるのではないかと思います。

[mizar]

CSA標準棋譜ファイル形式 (V2.2) に関連した定義の、将棋所-CSA対局サーバ 間の通信などで用いられる CSAサーバ プロトコル ver.1.2.1 # 3.2. 対局条件と対局の開始 では、対局条件の通知メッセージの例として、駒別単独表現が空である例が挙げられています。そのため、駒別単独表現が空になるケースは認めたほうが自然かもしれません。

BEGIN Game_Summary
Protocol_Version:1.2
Protocol_Mode:Server
Format:Shogi 1.0
Declaration:Jishogi 1.1
Game_ID:20150505-CSA25-3-5-7
Name+:TANUKI
Name-:KITSUNE
Your_Turn:+
Rematch_On_Draw:NO
To_Move:+
Max_Moves:256
BEGIN Time
Time_Unit:1sec
Total_Time:600
Byoyomi:10
Least_Time_Per_Move:1
END Time
BEGIN Position
P1-KY-KE-GI-KI-OU-KI-GI-KE-KY
P2 * -HI *  *  *  *  * -KA * 
P3-FU-FU-FU-FU-FU-FU-FU-FU-FU
P4 *  *  *  *  *  *  *  *  * 
P5 *  *  *  *  *  *  *  *  * 
P6 *  *  *  *  *  *  *  *  * 
P7+FU+FU+FU+FU+FU+FU+FU+FU+FU
P8 * +KA *  *  *  *  * +HI * 
P9+KY+KE+GI+KI+OU+KI+GI+KE+KY
P+
P-
+
+2726FU,T12
-3334FU,T6
END Position
END Game_Summary

[gemmaro]

ご教示いただきありがとうございます。例ではたしかに駒別単独表現が空になっており、かつ複数の種類の開始局面の表現が含まれていることを確認しました。
#53 について良いと思います。

[na2hiro]

丁寧なPRの提案と議論ありがとうございます。この修正で良いと思います。

[na2hiro]

Merged #53

[na2hiro]

json-kifu-format@1.2.8 を publish しました。