最終更新日:2004/12/12

Portable Game Notation

私は以前様々な棋譜フォーマットを相互変換するプログラムを作ろうと考えていたんですが、 そのときPGNについていろいろ疑問が出てきました。 例えば、PGNでは通常代数式の棋譜が用いられていますが、記述式ではどうなのか、英米式ではどうなのか、といったことがあります。 また、おかしなところが無さそうな棋譜データがPGNとして読みこめなかったり、といったこともありました。

ということで、PGN規格を探し出して翻訳してみました。 まだ一部翻訳していないところもありますが、主要と思われるところは翻訳したつもりなので、ご自由にお使いください。 また、ご意見ご要望もお寄せください。適宜反映させていただきます。

ところで、見ての通りかなり古い(1994年の)ものしか手に入りませんでした。 なので、文章中にはいくつもの「策定中」の文字があったり、今ではもう使われないだろうという文章もあります。 もっと新しい規格書のあるところをご存知の方は連絡をお願いします。

規格名Portable Game Notation規格と実装のガイド
改定1994.03.12
著者インターネットニュースグループ rec.games.chess に興味を持った読者
調整役Steven J. Edwards (ご意見はsje@world.std.comまで)

序文
1.イントロダクション
2.チェスデータの表現
__ 2.1.データ変換の非互換性
__ 2.2.規格の目的
__ 2.3.PGNゲームサンプル
3.フォーマット:インポートとエクスポート
__ 3.1.手作業で用意されたデータを考慮したインポートフォーマット
__ 3.2.出力をするプログラムに用いられるエクスポートフォーマット
____ 3.2.1.バイト等価性
____ 3.2.2.アーカイブストレージと改行文字
____ 3.2.3.処理スピード
____ 3.2.4.小さくされたエクスポートフォーマット
4.辞書編集上の問題
__ 4.1.文字コード
__ 4.2.タブ文字
__ 4.3.行の長さ
5.注釈
6.エスケープ機構
7.トークン
8.ゲーム解析
__ 8.1.タグ部分
____ 8.1.1.Seven Tag Roster
__ 8.2.指し手部分
____ 8.2.1.指し手の行
____ 8.2.2.指し手部分における手数
____ 8.2.3.指し手SAN (Standard Algebraic Notation)
____ 8.2.4.指し手NAG (Numeric Annotation Glyph)
____ 8.2.5.指し手RAV (Recursive Annotation Variation)
____ 8.2.6.ゲーム終了マーカー
9.補足タグ名
__ 9.1.プレイヤーに関する情報
____ 9.1.1.タグ:WhiteTitle
____ 9.1.2.タグ:WhiteElo
____ 9.1.3.タグ:WhiteUSCF
____ 9.1.4.タグ:WhiteNA
____ 9.1.5.タグ:WhiteType
__ 9.2.イベントに関する情報
____ 9.2.1.タグ:EventDate
____ 9.2.2.タグ:EventSponsor
____ 9.2.3.タグ:Section
____ 9.2.4.タグ:Stage
____ 9.2.5.タグ:Board
__ 9.3.オープニング情報(ローカルスペック)
____ 9.3.1.タグ:Opening
____ 9.3.2.タグ:Variation
____ 9.3.3.タグ:SubVariation
__ 9.4.オープニング情報(サードパーティベンダー)
____ 9.4.1.タグ:ECO
____ 9.4.2.タグ:NIC
__ 9.5.時間と日付に関する情報
____ 9.5.1.タグ:Time
____ 9.5.2.タグ:UTCTime
____ 9.5.3.タグ:UTCDate
__ 9.6.タイムコントロール
____ 9.6.1.タグ:TimeControl
__ 9.7.任意の初期配置
____ 9.7.1.タグ:Setup
____ 9.7.2.タグ:FEN
__ 9.8.ゲーム結果
____ 9.8.1.タグ:Termination
__ 9.9.種々雑多なもの
____ 9.9.1.タグ:Annotator
____ 9.9.2.タグ:Mode
____ 9.9.3.タグ:PlyCount
10.Numeric Annotation Glyphs
11.ファイル名とディレクトリ
__ 11.1.PGNデータファイル名の拡張子
__ 11.2.特定のプレイヤーのPGNデータのファイル名形成
__ 11.3.特定のイベントのPGNデータのファイル名形成
__ 11.4.年代順に並べれられたゲームのPGNデータのファイル名形成
__ 11.5.提案されたディレクトリツリー構造
12.PGNを並べる順
13.PGNソフトウエア
__ 13.1.SANキット
__ 13.2.pgnRead
__ 13.3.mail2pgn/GIICS
__ 13.4.XBoard
__ 13.5.cupgn
__ 13.6.Zarkov
__ 13.7.Chess Assistant
__ 13.8.BOOKUP
__ 13.9.HIARCS
__ 13.10.Deja Vu
__ 13.11.MV2PGN
__ 13.12.The Hansen utilities (cb2pgn, nic2pgn, pgn2cb, pgn2nic)
__ 13.13.Slappy the Database
__ 13.14.CBASCII
__ 13.15.ZZZZZZ
__ 13.16.icsconv
__ 13.17.CHESSOP (CHESSOPN/CHESSOPG)
__ 13.18.CAT2PGN
__ 13.19.pgn2opg
14.PGNデータアーカイブ
15.国際オリンピック委員会の国コード
16.追加のチェスデータ規格
__ 16.1.FEN
____ 16.1.1.歴史
____ 16.1.2.ポジション表記のための使用
____ 16.1.3.データフィールド
____ 16.1.4.ピース配置データ
____ 16.1.5.手番
____ 16.1.6.キャスリング可能性
____ 16.1.7.アンパッサンの目的のマス
____ 16.1.8.ハーフムーブクロック
____ 16.1.9.手数
____ 16.1.10.例
__ 16.2.EPD
____ 16.2.1.歴史
____ 16.2.2.拡張ポジション表記のための使用
____ 16.2.3.データフィールド
____ 16.2.4.ピース配置データ
____ 16.2.5.手番
____ 16.2.6.キャスリング可能性
____ 16.2.7.アンパッサンの目的のマス
____ 16.2.8.命令
____ 16.2.9.一般形式
____ 16.2.10.opcodeの記憶術
____ 16.2.11.opcodeリスト
____ 16.2.12.opcode "acn": analysis count: nodes
____ 16.2.13.opcode "acs": analysis count: seconds
____ 16.2.14.opcode "am": avoid move(s)
____ 16.2.15.opcode "bm": best move(s)
____ 16.2.16.opcode "c0": comment(その1、"c1"から"c9"まで)
____ 16.2.17.opcode "ce": centipawn evaluation
____ 16.2.18.opcode "dm": direct mate fullmove count
____ 16.2.19.opcode "drawn_accept": accept a draw offer
____ 16.2.20.opcode "draw_claim": claim a draw
____ 16.2.21.opcode "draw_offer": offer a draw
____ 16.2.22.opcode "draw_reject": reject a draw offer
____ 16.2.23.opcode "eco": _Encyclopedia of Chess Openings_ opening code
____ 16.2.24.opcode "fmvn": fullmove number
____ 16.2.25.opcode "hmvc": halfmove clock
____ 16.2.26.opcode "id": position identification
____ 16.2.27.opcode "nic": _New In Chess_ opening code
____ 16.2.28.opcode "nop": no operation
____ 16.2.29.opcode "pm": predicted move
____ 16.2.30.opcode "pv": predicted variation
____ 16.2.31.opcode "rc": repetition count
____ 16.2.32.opcode "resign": game resignation
____ 16.2.33.opcode "sm": supplied move
____ 16.2.34.opcode "tcgs": telecommunication: game selector
____ 16.2.35.opcode "tcri": telecommunication: receiver identification
____ 16.2.36.opcode "tcsi": telecommunication: sender identification
____ 16.2.37.opcode "v0": variation number(その1、"v1"から"v9"まで)
17.チェス駒を識別する任意の文字
18.正式なシンタックス
19.正統なポジションのハッシュコード
20.バイナリ表現(PGC)
__ 20.1.バイト
__ 20.2.指し手を表す数
__ 20.3.文字データ
__ 20.4.マーカーコード
____ 20.4.1.マーカー 0x01:小さくされたエクスポートフォーマットのゲーム1つ
____ 20.4.2.マーカー 0x02:タグ
____ 20.4.3.マーカー 0x03:ショートムーブシーケンス
____ 20.4.4.マーカー 0x04:ロングムーブシーケンス
____ 20.4.5.マーカー 0x05:一般的なゲームデータ開始
____ 20.4.6.マーカー 0x06:一般的なゲームデータ終了
____ 20.4.7.マーカー 0x07:単純なNAG
____ 20.4.8.マーカー 0x08:RAV開始
____ 20.4.9.マーカー 0x09:RAV終了
____ 20.4.10.マーカー 0x0a:エスケープ文字
21.E-mailチェスにおける使用方法

序文

バベルの塔の物語から:
“もし今、彼らが単一の民族で、皆が同じ言語を話して、彼らがこれを行ない始めていたら、 その後彼らが行なおうと思うことを止めるものはもはや何もないだろう”
起源XI、v.6

1.イントロダクション

PGNとは“Portable Game Notation”の略で、ASCIIコードのテキストファイルを用いてチェスゲームのデータを表現するためにデザインされた規格である。 PGNは人間が簡単に読み書きが出来るように、かつコンピュータプログラムが簡単に解析生成出来るように構成された。 PGNを定義し普及させる目的は、世界中のあらゆるチェスプレイヤー(組織もそれ以外も)、出版業者、そしてコンピュータチェスの研究者の間で、 公共のチェスゲームデータの共有を容易にすることである。

PGNは全ての可能な用途に適した標準となるつもりはない;考え得るあらゆる要求を満足するような標準は存在しない。 そのかわり、PGNはデータ変換のための万能かつ手軽な表現となることを計画している。 そのアイデアは、チェスアプリケーション間でゲームを受け渡しするためにPGNを使用することで、 チェスゲームデータを早く簡単に処理する事を可能にするチェスアプリケーション群を構成することである。

2.チェスデータの表現

チェスプレイヤーの間でコンピュータを使用することは近年では実に一般的になっており、 様々な種類のプログラムは、商用であれ公共物であれ、チェスゲームデータを生成し、呼び出し、普及させるために用いられている。 これらのプログラムのいくつかはかなり印象的である; 大部分のプログラムは“Law of Chess”に正しく従うように上手に振る舞い、ちょっとした注意でユーザたちのデータを操作する。 不幸にも、多くのプログラムはチェスゲームデータを外部に表すとき、いくつかの点において重大な問題を持っている。 ユーザがあるプログラムから別のプログラムへかなりの量のデータを移そうと思った場合、 それらの問題がより明白となる。 もしデータの移植性を確かなものにするために何らかの努力していなければ、どう見ても転送が成功する可能性は低い。

2.1.データ変換の非互換性

フォーマットに互換性がない理由は簡単に理解できる。 実際、それらのほとんどは、ワープロ、スプレッドシート、フォント、 画像のような他の分野のための商用ソフトウエアで既に見てきた同じ問題において互いに関連がある。 時々製造業者は顧客を囲い込むために、暗号化やその他の秘密にしている、プロプライエタリな技術を用いたデータフォーマットを故意に使用する。 時々デザイナーは大した苦労もなく解読できるフォーマットを作るかもしれないが、 同時に、公的に企業秘密保護を要求することによって、サードパーティのソフトウエアがそのフォーマットを使用することを思いとどまらせる。 別のソフトウエア製作者はプロプライエタリでないシステムを開発するかもしれないが、 それは簡単には拡張できないから、単一のプログラムまたはアプリケーションの場合のみ上手くいくだろう。 最後に、その他のいくつかのソフトウエアは多くの目的において非常に上手く動作するだろう。 だがそれは、それが開発された国の外で利用する人間やコンピュータが簡単には理解できない記号と言語を使用する。

2.2.規格の目的

Portable Game Notationの規格は歴史の教訓に気付き、将来出てくるかもしれない要求を処理できなければならない。 PGNのデザイン基準はこれらの要求に合うように選択された。これらの基準は:
  1. システムの詳細は公的に利用でき、不必要な複雑さからは無縁でなければならない。 理想的には、もし書類が何らかの理由により利用できないなら、 典型的なチェスソフトウエア開発者とユーザが第三者の助力を必要とせずにデータのほとんどを理解できるべきた。
  2. システムの詳細は、知的所有権を侵害することについて心配することによりユーザとソフトウエア開発者を制限しないようにするため、 プロプライエタリであってはならない。この考えは、秘密のデータフォーマットによって作り出された人工的な必要性ではなく、 顧客の本当の必要性を基にソフトウエアを選択する自由な市場でチェスプログラマーに競争させる。
  3. システムは様々なプログラムで動作しなければならない。 そのフォーマットは、不必要に個々のアプリケーションクラスに依存することなしに、 データベース、チェス出版プログラム、チェスサーバプログラム、チェスを指すプログラムで利用できるようなものであるべきだ。
  4. システムは容易に拡張でき、調整できなければならない。 拡張能力は、現在は存在しないかもしれないが将来出現すると予想される、データアイテムを操作できなければならない。 (例:新たなオープニングの分類や新たな国名。) システムは、蓄えているデータの量に依存するような勝手な制限を持つべきではないように調整できるべきである。 また、計画されている拡張モードは以前のデータベースをそのまま使えるか、少なくとも自動変換を考慮すべきである。
  5. システムは国際的でなければならない。チェスソフトウエアのユーザは多くの国に居り、 そのシステムは地域的な慣習によって生じる難しさから無縁であるべきである。
  6. 最後に、システムは同じ種類のデータを操作できるべきであり、 現存するチェスソフトウエアと印刷メディアによってすでに扱われているデータ全てを扱えるべきである。

2.3.PGNゲームサンプル

その記述はかなり長いように見えるかもしれないが、PGNは実際かなりシンプルである。 PGNのサンプルゲームは次のものである;それはこの文章の後の章で記述されている多くの重要な機能を持っている。
[Event "F/S Return Match"]
[Site "Belgrade, Serbia JUG"]
[Date "1992.11.04"]
[Round "29"]
[White "Fischer, Robert J."]
[Black "Spassky, Boris V."]
[Result "1/2-1/2"]
1. e4 e5 2. Nf3 Nc6 3. Bb5 a6 4. Ba4 Nf6 5. O-O Be7 6. Re1 b5 7. Bb3 d6 8. c3
O-O 9. h3 Nb8 10. d4 Nbd7 11. c4 c6 12. cxb5 axb5 13. Nc3 Bb7 14. Bg5 b4 15.
Nb1 h6 16. Bh4 c5 17. dxe5 Nxe4 18. Bxe7 Qxe7 19. exd6 Qf6 20. Nbd2 Nxd6 21.
Nc4 Nxc4 22. Bxc4 Nb6 23. Ne5 Rae8 24. Bxf7+ Rxf7 25. Nxf7 Rxe1+ 26. Qxe1 Kxf7
27. Qe3 Qg5 28. Qxg5 hxg5 29. b3 Ke6 30. a3 Kd6 31. axb4 cxb4 32. Ra5 Nd5 33.
f3 Bc8 34. Kf2 Bf5 35. Ra7 g6 36. Ra6+ Kc5 37. Ke1 Nf4 38. g3 Nxh3 39. Kd2 Kb5
40. Rd6 Kc5 41. Ra6 Nf2 42. g4 Bd3 43. Re6 1/2-1/2
				

3.フォーマット:インポートとエクスポート

PGNスペックには2つのフォーマットがある。それらは"インポート"フォーマットと"エクスポート"フォーマットである。 それらは、ソースに従って同じPGNデータの体裁を整える2つの異なる方法である。 その2つのフォーマットの詳細はこの文章の後に続く章を通して記述される。

フォーマットとは別に、PGN表現には追加の話題がある。 PGNのインポート/エクスポートフォーマットの両方は人間が読めるようにデザインされているが、 これらのどちらもがチェスデータを表現する究極のモードであると勧告しているわけではない。 むしろ、ソフトウエア開発者は彼らのプログラムの表現レベル (すなわち、最も高いレベル) (訳注:OSI参照モデルにおけるアプリケーション層のこと。) におけるチェスデータの表現を高めるために、 それらの処理において様々なテクニックの全てを考慮することを力説される。 これは、異なるフォント、文字サイズ、色、そして相互作用と出版をコンピュータが助けるその他のツールの使用は 個々のプログラムの関数として適した質の高い表現を提供するために探求されるべきであるということを意味する。

3.1.手作業で用意されたデータを考慮したインポートフォーマット

インポートフォーマットはやや柔軟であり、手動で、 もしくは高級プログラミング言語のソースファイルのようなものによって準備されているかもしれないデータを記述するのに用いられる。 PGNデータを読むことの出来るプログラムは、やや緩いインポートフォーマットを扱えなければならない。

3.2.出力をするプログラムに用いられるエクスポートフォーマット

エクスポートフォーマットはかなり厳密であり、コンパイラによって再フォーマットされた、きれいに印刷されたソースプログラムか何かのように、 普通プログラムのコントロール下に準備されたデータを記述するのに用いられる。

3.2.1.バイト等価性

ある与えられたPGNデータファイルから、 同じコンピュータシステム上で異なるPGNプログラムによって生成されたエクスポートフォーマット表現は、 バイト単位で正確に等しいべきだ。

3.2.2.アーカイブストレージと改行文字

エクスポートフォーマットはまたアーカイブストレージとしても用いられるべきだ。 ここで、"アーカイブ"ストレージは様々なコンピュータシステムによってアクセスされるかもしれないストレージと定義される。 アーカイブストレージの追加要求は唯一つ。改行コードが特定の値を持ち、 その値が個々のコンピュータシステムのテキストファイル習慣から独立していることだけである。 改行のアーカイブ表現はASCII制御文字LF(Line Feed, 10進で10、16進で0x0a)である。

残念なことに、改行を表す文字に過度に装飾された表現を持つということが今日まで生き残っているという、歴史のアクシデントがある: それは複数文字の並び、行末レコードマーク、行頭バイト総数、固定長レコードなどである。 これら全てをANSI Cの統一文字に一致させ、1つの'\n'を用いるという慣習の幸せを謳歌することは、 PGNプロジェクトの観点を超えて良いことである。 いくつかのシステムは、アーカイブPGNテキストファイルを、そのシステムが元々持っているテキストエディタで全く操作できないかもしれない。 これらの場合、非アーカイブPGNファイルに独自の改行文字を用いるというある種の特権がこれらのテキストエディタに認められる。

3.2.3.処理スピード

エクスポートフォーマットのいくつかの部分は、 インポートフォーマットの詳細にはない、行とフィールドを整えるための正確な記述を用いる。 エクスポートフォーマットのこれらの制約の主な理由は、 完全なチェスエンジンやその他の複雑な解析ルーチンを持つ必要無しに、 PGNデータを簡単に走査できる簡単なデータ変換プログラムの構成を許すことである。 このアイデアはチェスソフトウエア著者に、 少なくとも限られたPGN読み込み能力を許すことを促進する。 完全なチェスエンジン解析能力が利用できるとしても、 単純なテキスト走査機よりも多分少なくとも2桁は遅いだろう。

3.2.4.小さくされたエクスポートフォーマット

エクスポートフォーマットを用いて表現されたPGNゲームは、 次の条件を全て満たすとき、"小さくされたエクスポートフォーマット"であるといわれる: 1)注釈がなく、2)標準的な"Seven Tag Roster"("STR"は下記参照)の識別情報のみ持ち、 3)"Recursive Annotation Variations"("RAV"は下記参照)がなく、 4)"Numeric Annotation Glyphs"("NAG"は下記参照)がない。 小さくされたエクスポートフォーマットは注釈をつけられていないゲームのかさばるストレージのために用いられる。 それはPGNをエクスポートするアプリケーションのために標準的な一致の最小レベルを表す。

4.辞書編集上の問題

PGNデータは文字から構成される:単語のトークンが重ならない連続した文字の列。

4.1.文字コード

PGNデータは8ビット ISO 8859/1 (ラテン 1) 文字セットのサブセットを用いて表現される。 ("ISO"はInternational Standards Organizationの頭文字である。) この集合はECMA-94としても知られ、他のISOラテン文字セットに似ている。 ISO 8859/1は0から31までの32個の制御文字コード値のための標準の7ビットASCII文字セットを含む。 32から126までの95個の印刷文字はまた7ビットASCIIの使用と等価である。 (コード127、ASCII DEL制御文字、はISO 8859/1では図形文字である;それはPGNデータ表現では用いられない。)

128から159の32個のISO 8859/1コード非表示制御文字である。 それらはPGNデータを表現するためには用いられない。 160から191までの32個のコードは大抵非アルファベットの表示文字であり、 PGNデータでそれらを使用することは、それらの画像表現が他のISOラテンセットの間でかなり異なるとして敬遠される。 最後に、192から255までの64個のコードは大抵様々な発音区別符をもったアルファベットの印刷文字である; それらの使用はそのような文字を要求する言語では奨励される。 この最後の64文字の画像表現はISOラテン族から全く一定である。

7ビットASCIIの範囲の外の印刷文字コードは文字データや解説の中でのみ現れるかもしれない。 これらはシンボルを構成するために使用することは許されない。

いくつかのPGN使用者の環境は非ASCII文字の表示をサポートしていないかもしれない。 PGNゲームの著者は、そのような環境で参照されるかもしれないゲームデータ内で、 評論の注釈や文字の値でのそのような文字の使用を控えるべきである。 PGNソフトウエアの著者は、非ASCII文字コードにクエスチョンマーク("?")を表示することによって、 それらの環境を処理するプログラムを持つべきである。 8ビット文字データを表示することの出来る多くのコンピュータシステムがあるが、 表示画像はマシンや異なる業者の作ったオペレーティングシステムによって異なるかもしれないため、 これは重要な点である。

ASCII制御文字の内4つだけがPGNインポートフォーマットで許されている; これらはラインフィード、キャリッジリターン、水平タブ、垂直タブである。

改行文字の外部表現はプラットフォームによって異なるかもしれない; これは実装の詳細がソフトウエアの実装者とユーザに隠されている限り許容されるバリエーションである。 選択が実用的なとき、UNIXの"改行はラインフィードである"という慣習は好ましい。

訳注:文字コード表
 上位3ビット
01234567
下位4ビット0NULLDLEspace0@P`p
1SOHDC1!1AQaq
2STXDC2"2BRbr
3ETXDC3#3CScs
4EOTDC4$4DTdt
5ENQNAK%5EUeu
6ACKSYN&6FVfv
7BELETB'7GWgw
8BSCAN(8HXhx
9HTEM)9IYiy
ALFSUB*:JZjz
BVTESC+;K[k{
CFFFS,>L\l|
DCRGS-=M]m}
ESORS.<N^n~
FSIVS/?O_oDEL

4.2.タブ文字

タブ文字は、水平方向でも垂直方向でも、エクスポートフォーマットでは許されない。 これは、ホストコンピューティングシステムでの使用で、 タブ文字の取り扱いが個々のソフトウエアにかなり依存するからである。 また、タブ文字は文字データの中で現れないかもしれない。

4.3.行の長さ

PGNデータは、特定のオペレーティングシステムによって課される、 2次的な記録構造のための特別なバイトやマーカーのない、単純なテキストの行として組織される。 インポートフォーマットのPGNテキスト行は改行文字を含めて1行当り最大255文字に制限される。 80文字以上の表示文字を持つ行は、一般的なテキストエディタで長い行を表示することの難しさのために、 強く敬遠される。

いくつかの場合、非常に長いタグ値は80文字以上を要求するだろうが、これらは比較的まれである。 この例は"FEN"タグである;それは長いタグ値を持つかもしれないが、 この特別なタグは普通の初期配置から始まらないゲームを表す場合にのみ用いられる。

5.注釈

コメントテキストはPGNデータの中に現れるかもしれない。 コメントには2種類のものがある。 1つ目は"行の残り"のコメントである; このコメントタイプはセミコロン文字で始まり行の終わりまで続く。 2つ目は左括弧文字で始まり次の右括弧文字まで続く。 コメントはどんなトークンの内側にも現れることが出来ない。

大括弧のコメントはネストしない; 大括弧コメントに現れる左大括弧文字は特別な意味を失い無視される。 大括弧コメントに現れるセミコロンは特別な意味を失い無視される。 セミコロンコメントの中に現れる大括弧は特別な意味を失い無視される。

***コメントのエクスポートフォーマット表現は定義作業が必要である。

6.エスケープ機構

PGNデータには特別なエスケープ機構がある。 この機構は行の最初に現れるパーセント文字("%")によって引き起こされる; その行の残りのデータは公的に利用できるPGN解析ソフトウエアによって無視される。 このエスケープの習慣はPGNストリームの中に非PGNコマンドやデータを埋めこむために、 ソフトウエア開発者や研究者の私的利用のために意図されている。

行の最初以外の場所にあるパーセントの印はエスケープ機構を引き起こさない。

7.トークン

PGN文字データはトークンとして組織される。 トークンは基本的な意味単位として表現される文字の連続した列である。 トークンはスペース文字によって隣接したトークンから分離されるかもしれない。 (スペース文字はスペース、改行、タブ文字である。) いくつかのトークンはそれ自身が境界を定め、スペース文字を要求しない。

文字トークンは引用文字(10進数で34、16進数で0x22のASCII文字)のペアによって境界を定められる、 0個以上の印刷文字の列である。 空の文字は2つの隣接した引用符で表現される。(注記:アポストロフィーは引用符ではない。) 文字列中の引用符は引用符の直前にバックスラッシュを書くことによって表現される。 (訳注:日本語環境においては、バックスラッシュは通常"\"で表される。) 文字列中のバックスラッシュは2つの隣接したバックスラッシュによって表現される。 文字列は一般的にタグ値(下記参照)として用いられる。 改行やタブといった非印刷文字は文字列の中に現れることは許されない。 文字列トークンは引用符によって終了される。 現在は、文字列はデータの中で最大255文字に制限されている。

整数トークンは1個以上の10進数文字の列である。 それは下に記述するより一般的な"シンボル"トークンクラスの特別な場合である。 整数トークンは手数(下記参照)を表現する手助けとして用いられる。 整数トークンは、整数列に続く最初の非シンボル文字の丁度前で終了される。

ピリオド文字(".")はそれ自身トークンである。それは手数(下記参照)のために用いられる。 それは自身で終了させる。

アスタリスク文字("*")はそれ自身トークンである。 それはゲーム終了マーカー(下記参照)の1つとして用いられる。 それは不完全なゲームや分からないゲームやその他利用できないゲームを示す。 それは自身で終了させる。

左括弧文字と右括弧文字("["と"]")はトークンである。それらはタグ(下記参照)の境界を定めるのに用いられる。 両方とも自身で終了させる。

左小括弧と右小括弧("("と")")はトークンである。 それらは Recursive Annotation Variations(下記参照)の境界を定めるのに用いられる。 両方とも自身で終了させる。

左不等号と右不等号はトークンである。それらは将来的な拡張のために予約されている。 両方とも自身で終了させる。

Numeric Annotation Glyph ("NAG"、下記参照)はトークンである; それはドル文字("$")とその直後に続く1つ以上の10進文字で構成される。 それは10進数の列に続く最初の非10進数文字の直前で終了される。

シンボルトークンは綴り文字または10進数の文字と、直後に続く0個以上の続き文字の列によって始まる。 これらの続き文字は綴り文字("A-Za-z")、10進文字("0-9")、アンダースコア("_")、プラス記号("+")、 シャープ記号("#")、イコール記号("=")、コロン(":")、ハイフン("-")である。 シンボルは様々な目的に用いられる。シンボル中の全ての文字は意味がある。 シンボルトークンはシンボル文字の列に続く最初の非シンボル文字の直前で終了される。 現在、シンボルは最大255文字に制限されている。

8.ゲーム解析

PGNデータベースファイルは0個以上のPGNゲームの連続した集合である。 空ファイルは、やや情報価値がないが、妥当なPGNデータベースである。

PGNゲームは2つの部分で構成される。1つ目はタグ部分で2つ目は指し手部分である。 タグ部分は標準的なパラメータの集合に関連した値を定義することにより、ゲームを識別する情報を提供する。 指し手部分は、大抵は列挙された、場合によっては注釈のつけられた、 ゲームの指し手がゲームの終了を表すマーカーと共に与えられる。 チェスの指し手それ自身はSAN (Standard Algebraic Notation)を用いて表され、それはこの文章の後のほうで記述される。

8.1.タグ部分

タグ部分は0個以上のタグが続いたものとして与えられる。

タグは4つの連続したトークンで与えられる:左括弧トークン、シンボルトークン、文字列トークン、右括弧トークンである。 シンボルトークンはタグ名で文字列トークンはタグ名と関連付けられたタグの値である。 (標準的なタグ名と意味の集合が存在し、それは後ろのほうで記述される。) 同じタグ名はタグ部分で2回以上現れるべきではない。

タグ名に関する更なる制約は、専ら文字、数字、アンダースコアで構成されることである。 これはタグ名を、一般的な目的のデータベースプログラムで用いるキーや属性名にマッピングすることを容易にする。

PGNインポートフォーマットでは、0個以上の空白文字がタグ内の隣接したトークンのペアの間にある。

PGNエクスポートフォーマットでは、左括弧とタグ名の間には空白文字はなく、 タグ値と右括弧の間には空白文字はなく、 タグ名とタグ値の間には1つの空白文字がある。

全てのシンボルのような、いくつかのタグ名は大文字と小文字が区別される。 アーカイブストレージに用いられる全てのタグ名は大文字で始まる。

PGNインポートフォーマットでは、同じ行でマルチタグを持つかもしれず、1行以上に広がるタグを持つことすらあるかもしれない。 エクスポートフォーマットでは、それぞれのタグが行の左端に現れることを要求する; 1つの空白行は最後のタグを意味する。

いくつかのタグ値は後に項目が続くかもしれない。 例えば、consultation gameは一方に1人以上のプレイヤーを持つかもしれない。 もしこれが生じた場合、":"(コロン)が隣接した項目の間に現れる。 このように文字列の間にセパレータを用いることにより、コロンは文字列のほかの部分では現れるべきではない。

タグのフォーマットは拡張性を考えてデザインされている; 最初に、文字列だけがタグ値として許されている。 STR(Seven Tag Roster, 下記参照)と関連付けられたタグ値のフォーマットは変わらないだろう; それらは常に文字列だろう。 けれども、非STRタグのためのタグ値として一般的なリスト構造を許すという長項目プランが存在する。 この拡張タグ値の使用は多分特別な調査プログラムに制限されるだろう。 全てのイベントにおいて、タグの最上位構造は同じままである: それは左括弧、タグ名、タグ値、右括弧である。

8.1.1.Seven Tag Roster

PGNデータのアーカイブストレージとして強制的に用いることを定義したタグの集合がある。 これがSTR(Seven Tag Roster)である。 これらのタグの説明はそれらが現れる順番として固定されている。 追加タグの名称や意味を使用したり定義することは、必要なら許されているし推奨されているが、 STRは、全てのプログラムが公的なデータ交換として対応すべき共通基盤である。

インポートフォーマットでは、タグの順番は重要ではない。 エクスポートフォーマットでは、STRタグは全てのその他のタグより前に現れる。 (STRタグはまた順序良く現れなければならない;この順番は下で記述されている。) エクスポートフォーマットではまた、全ての追加タグはタグ名がASCIIコード順で現れる。

その7つのSTRタグ名は(次の順で):
  1. Event (トーナメントかマッチイベントの名前)
  2. Site (イベントの行なわれた地域)
  3. Date (ゲームの開始した日付)
  4. Round (このゲームのラウンド)
  5. White (白のプレイヤー)
  6. Black (黒のプレイヤー)
  7. Result (ゲームの結果)
補足タグ名の集合はこの文章の後のほうで与えられる。

PGNエクスポートフォーマットでは、タグ部分を終了するために、1つの空白行が最後のタグの後で現れる。 これは、タグ部分の最後と指し手部分の始まりをすぐに区別するために、 単純にスキャンするプログラムの手助けをする。 Eventタグの値は適切に記述されるべきだ。 略語は絶対に必要である場合を除き避けられるべきだ。 一貫したイベント名はデータベースのスキャンを容易にするために用いられるべきである。 もしイベントの名前がわからなければ、1つのクエスチョンマークがタグ値として現れるべきだ。

例:
[Event "FIDE World Championship"]
[Event "Moscow City Championship"]
[Event "ACM North American Computer Championship"]
[Event "Casual Game"]
					
Siteタグの値は、その国を表す標準的な名前と町か地域の名前からなるべきだ。 IOC(International Olympic Committee)で使用される3文字の国名の使用は、 それらのコードが利用できる国には提案されている。 もしイベントの開催された国が分からないなら、1つのクエスチョンマークがタグ値として現れるべきだ。 コンマが地域と都市を分けるのに用いられるかもしれない。 都市や地域の名前とIOC国コードを分けるのにコンマは必要ない。 この文章の後のセクションでは、IOCによってカバーされていない地域のためにいくつか追加した、 3文字の国コードのリストが与えられる。

例:
[Site "New York City, NY USA"]
[Site "St. Petersburg RUS"]
[Site "Riga LAT"]
					
Dateタグの値はゲームの開始された日付を与える。 (注記:これは必ずしもイベントの開始日と同じとは限らない。) 日付はEventタグに与えられた地域の時間を考慮して与えられる。 Dateタグ値のフィールドは常に標準的な10文字のフォーマットを用いる:"YYYY.MM.DD"。 最初の4文字は年を表す数字、次の文字はピリオド、次の2文字は月を表す数字、 次はピリオド、最後の2文字は日を表す。 もし分からない数字があれば、クエスチョンマークがその数字の場所に用いられる。

例:
[Date "1992.08.31"]
[Date "1993.??.??"]
[Date "2001.01.01"]
					
Roundタグはプレイされているゲームのラウンドを与える。 マッチにおいては、この値はプレイされたゲームの数である。 ラウンド数の使用が不適当なら、そのフィールドは1つのハイフンであるべきだ。 ラウンドが分からないなら、1つのクエスチョンマークがタグ値として現れるべきだ。 一部の主催者は普通でないラウンド名称や複数の部分からなるラウンドや、 時には条件付のラウンドさえ使用する。 これらの場合、複数の部分からなるラウンド識別子がピリオドで分けられたラウンド数の並びで構成することも出来る。 最も左の整数は最も重要なラウンドを表し、続く整数は階層が下っていく順番でラウンド数を表す。

例:
[Round "1"]
[Round "3.1"]
[Round "4.1.2"]
					
Whiteタグの値は白プレイヤーの名前である。その名前は、それらが電話帳に現れる順番で与えられる。 family nameまたはlast nameが最初に現れる。 もしfirst nameまたはfirst initialが利用できるなら、それはコンマとスペースでfamily nameと分割される。 最後に、1つ以上のmiddle initialが現れる。 (コンマが現れたところならどこでも、その次の文字はスペースであるべきだ。 イニシャルが現れた所ならどこでも、その次の文字はピリオドであるべきだ。) その名前がわからないなら、1つのクエスチョンマークがタグ値として現れるべきだ。

その目的は、地域的な名前の形式に依存しない、タグ値として意味のあるASCII文字列を許すためである。 もし1人以上のプレイヤーが白をプレイしているなら、 名前はアルファベット順で並べられ、隣接したエントリーの間はコロンで区切られる。 プレイヤーがコンピュータプログラムなら適切なバージョン情報がプログラム名の後に並べられるべきだ。

FIDEレーティングリストに用いられているフォーマットはプレイヤーネームタグとして用いられるのに適している。

例:
[White "Tal, Mikhail N."]
[White "van der Wiel, Johan"]
[White "Acme Pawngrabber v.3.2"]
[White "Fine, R."]
					
Blackタグの値は黒プレイヤーの名前である。 名前はWhiteタグの値と同じように与えられる。

例:
[Black "Lasker, Emmanuel"]
[Black "Smyslov, Vasily V."]
[Black "Smith, John Q.:Woodpusher 2000"]
[Black "Morphy"]
					
Resultフィールドの値はゲームの結果である。 それは関連した指し手を終了させるゲーム終了マーカーと正確に常に同じである。 それは常に4つの値の内1つを持つ:"1-0" (白勝ち), "0-1" (黒勝ち), "1/2-1/2" (引き分け), "*" (ゲームは進行中である、ゲームは中断された、もしくは結果がわからない)。 "ゼロ"が最初の2つの場合に用いられることを記しておく;"O(大文字のオー)"ではない。

全ての可能な表記は:
[Result "0-1"]
[Result "1-0"]
[Result "1/2-1/2"]
[Result "*"]
					

8.2.指し手部分

指し手部分はチェスの指し手、手数、付加的な注釈、そして1つのゲーム終了マーカーから構成される。

不正な指し手が実際のチェスの指し手として存在しないため、PGNの指し手においてそれらは許されない。 けれどもそれらは注釈の中で現れるかもしれない。 われわれは不正な指し手がそのゲームを記録するのにふさわしいくらいにゲーム内で比較的まれであることを望む。

8.2.1.指し手の行

PGNのインポートフォーマットでは、指し手内のトークンは特別な行の整頓を要求しない。

PGNのエクスポートフォーマットでは、指し手内のトークンは左に整頓して配置され、それらは80文字より短い。 可能な限り多くのトークンが、連続した行に現れる残り部分と共に行に配置される。 1つのスペースが、指し手部分の同じ行にある2つの連続したシンボルトークンの間に現れる。 タグ部分と同じように、指し手の部分を終了するために、1つの空白行がデータの最後の行に現れる。

エクスポートフォーマットのPGNの行は最初の文字も最後の文字もスペースではない。 (これは注釈の場合には変わるかもしれない:この領域は現在開発中である。)

8.2.2.指し手部分における手数

手数の表示は1つ以上の連続した数字(整数のトークン)で構成され、それに0個以上のピリオドが続く。 表示の整数部分は(もし与えられていれば)直後に続く白の指し手の手数を与え、 (もし与えられていれば)直後に続く黒の指し手を与える。 PGNのインポートフォーマットは手数の表示を要求しない。 それは、手数が正しい限り、指し手のどこでも必要以上の手数表示を禁止しない。

PGNのインポートフォーマットにおける手数表示は0以上の文字を持ち、 手数を表す数字の列が続くかもしれない; 1つ以上の空白文字が数字の列とピリオドの間に現れるかもしれない。 エクスポートフォーマットの手数表示フォーマットには2つある。 1つは白の指し手エレメントのすぐ前に現れ、もう1つは黒の指し手エレメントのすぐ前に現れる。 白の手数表示は手数で与えられる整数と1つのピリオドから形成される。 黒の手数表示は手数で与えられる整数と3つのピリオドから形成される。

全ての白の指し手エレメントは手数表示を前に持つ。 黒の指し手エレメントは次の2つの場合にのみ手数表示を前に持つ: 第1に、もし黒の指し手とその前の白の指し手の間に注釈や解説がある場合; 第2に、特別な場合として黒の手番で始まるゲームのような、直前の白の指し手が存在しない場合。

PGNエクスポートフォーマットでは、指し手の表示が現れるその他の場合は存在しない。

8.2.3.指し手SAN (Standard Algebraic Notation)

SAN (Standard Algebraic Notation)はASCIIラテンアルファベットを用いたチェスの手を表す標準的な表現である。

SANで記録されたゲームの例は現代のチェス出版物においてあらゆる点で最も見つけることが出来る。 このドキュメントで示されるSANはチェスの駒に英語の1文字を用いる。 けれどもこれはソース内で簡単に変えられる。 多くの言語の中から英語が選ばれたのはそれが最も広く認知されているからである。

SANの代わりになるものはFAN (Figurine Algebraic Notation)である。 FANは1文字の駒の略語の代わりに小さな駒のアイコンを用いる。 2つの表記はそれ以外は同じである。 SANは一意の2文字の名前でチェスボード上の64マスそれぞれを見分ける。 マスを区別するものの最初の文字はそのマスのファイルである; ファイルは"a"(最も左またはクイーンサイド)から"h"(最も右またはキングサイド)までの1つの小文字によって指定される8マスの列である。 マスを区別するものの2文字目はマスのランクである; ランクは"1"(最も下の側[白の第1ランク])から"8"(最も上の側[黒の第1ランク])までの1つの数字によって指定される8マスの行である。 駒が最初にあるマスの例は: 白のクイーンサイドルックはa1、白のキングはe1、黒のクイーンサイドナイトの前のポーンはb7、そして黒のキングサイドルックはh8である。 SANは1つの大文字でそれぞれの駒を識別する。 標準的な英語の値は:ポーンは"P"、ナイトは"N"、ビショップは"B"、ルックは"R"、クイーンは"Q"、キングは"K"である。

ポーンの文字コードはPGNのエクスポートフォーマットの指し手では用いられない。 けれども、いくつかのPGNインポートソフトウエアでは、 曖昧さをなくすコードとしてポーンの文字コードの出現を許すかも知れない。 また、ポーンとその他の駒の文字コードはいくつかのタグと注釈の構成を用いるのに必要である。

英語での駒文字を他の言語で用いることは明らかにやや盲目的愛国主義である。 英語がほとんどのチェスプレイヤーとプログラム使用者の間で事実上国際的な第2言語であるということに、 わずかな正当性がある。それが多分今出来る最も良いものである。 この文章の後の章でこれ以外の駒を表す文字を与える。 けれどもこれらは局部的な表現としてのみ用いられるべきで、 アーカイブストレージやプログラム間での動的な変換に用いられるべきではない。 基本的なSANの指し手は動く駒の文字(ポーンも許される)とそれに続く目的のマスによって与えられる。 捕獲の指し手は、目的のマスの直前にある小文字の"x"によって示される; ポーンの捕獲では文字"x"の直前に捕まえるポーンの最初のマスのファイル文字が示される。

SANのキングサイドキャスリングは文字列"O-O"によって示される; クイーンサイドキャスリングは文字列"O-O-O"によって示される。 大文字の"O"が用いられ、用いられるのは数字の0ではないことを記しておく。 ゼロの文字を使用するのは伝統的な文書習慣と合わないだけでなく、 手数とゲーム終了マーカーについても理解しなければならないため、 解析アルゴリズムを混乱させることも出来る。 文字"O"の使用は、全てのチェスの指し手記号は文字で始まると言う習慣に一致することも記しておく; 全てのポーンでない駒の移動を表す記号は大文字で始まるという慣習をフォローするということも記しておく。

アンパッサンは特別な表記を持たない; それらは、捕獲されたポーンが捕獲したポーンの移動先のマス上にあるかのように構成される。 ポーンのプロモーションは移動先のマスの直後に等式記号"="とプロモートした駒の文字(1つのナイト、ビショップ、ルック、クイーン)を記すことによって示される。 上に書いた通り、駒の文字は大文字である。 曖昧な場合(同じマスに複数の同じタイプの駒が移動する場合)、 曖昧さをなくす3つのステップの内最初の適当なステップが採用される:

最初に、もし移動する駒が元のファイルによって区別できるなら、 移動する駒の元のファイルの文字が移動する駒の文字の直後に挿入される。

次に(最初のステップが失敗する場合)、もし移動する駒が元のランクによって区別できるなら、 移動する駒の元のランクの数字が移動する駒の文字の直後に挿入される。

第3に(第1と第2のステップが失敗する場合)、 移動する駒の元のマスの2つの文字による座標が移動する駒の文字の直後に挿入される。

上の曖昧さを無くす手法は、 同じ駒が同じマスに移動することを区別するためにのみ必要されるということを記しておく; それは同じマスへ同じ種類の駒を攻撃することを区別するためには使用されない。 これの例は、2つの白ナイトが、1つがc3に、もう1つがg1にあり、e2が空いて、白の番である時のポジションである。 両方のナイトはe2を攻撃し、もし両方がそこに合法的に移動できるなら、 ファイルにより曖昧さを無くすことが必要である; ナイトの移動は"Nce2"と"Nge2"となるだろう。 けれども、もし白キングがe1にあり、黒ビショップがb4にあり、 d2が空いている(従ってc3の白ナイトはピンされている)なら、 (g1にある)1つの白ナイトのみがe2に移動することが出来る:"Ne2"。 もしそれがチェックをする動きなら、プラス記号"+"が基本的なSAN表記の接尾辞として追加される; もしそれがチェックメイトにする動きなら、オクトスロープ記号"#"がその代わりに追加される。

チェックやチェックメイトの識別子があるかないかは曖昧さを無くす目的で用いられない。 これは、もし2つ(またはそれ以上)の同じ種類の駒が同じマスに移動できるなら、 指し手のチェックをしているかどうかの違いは、 上に記述した曖昧さを無くすための標準的なランクとファイルを使用する必要性を軽くすることはないということを意味する。 (上のチェックしているかどうかの違いはディスカバードチェックの場合にのみ生じるかもしれない。)

チェック識別子もチェックメイト識別子も、それらが主観的な情報を伝えないので注釈として考慮されない。 それにより、それらは"!"や"?"のような指し手の接尾辞注釈とは性質上異なる。 主観的な指し手の注釈はこの文章の後の章で記述されるNumeric Annotation Glyphsを用いて処理される。

ダブルチェックやディスカバードチェックに用いられる特別なマーキングは存在しない。

ドローの指し手に用いられる特別なマークはない。 SANの指し手は2文字まで短く(例えば、"d4")、または7文字まで長く(例えば、"Qa6xb7#"、"fxg1=Q+")出来る。 現実的なゲームで見られる平均的なSANの指し手の長さは多分3文字よりほんの少し長い。 もしSANの規則が複雑に見えたら、 LEN (Long English Notation)やEDN (English Descriptive Notation)といった昔の表記方法はより複雑であり、 LAN (Long Algebraic Notation、SANの前のもの)は不必要にかさばっていることを確かめなさい。 PGNエクスポートフォーマットはPGNゲームの指し手部分で指し手を表現するのに常に上の正統的なSANを用いる。 インポートフォーマットはややゆるく、指し手が正統的なフォーマットに正確には従わないことを許可する。 けれども、これらの許可は異なるPGNインポートプログラムの間では異なるかもしれない。 エクスポートフォーマットに現れるデータのみが全ての場合で全てのPGNリーダーに読みこむことの出来ることを保証する。

正統的でないPGNの指し手表記を許すPGNを読みこむソフトウエアの実装を用いるためにいくつかの提案されたガイドラインが存在する。 そのアイデアは、正統的でないインポートによって表現された指し手を発見することを試みる、 様々な変形を適用するPGNリーダーソフトウエアをもつことである。 いくつかの提案された変形は:文字の再割り当て、捕獲識別子の挿入、チェック識別子の挿入、チェックメイト識別子の挿入である。 インポートフォーマットPGNは指し手に伝統的な接尾辞表現の使用を許す。 正確に6つの注釈が存在する:それは"!", "?", "!!", "!?", "?!", "??"である。 そんな接尾辞注釈は1つの指し手当り高々1つ現れるかもしれず、 そしてもし与えるなら、それは指し手記号の最後の部分に常に存在する。

エクスポートされるときは、指し手の接尾辞注釈は、この文章の後の章で記述される、関連したNumeric Annotation Glyphに翻訳される。 例えば、もし1つの指し手"Qxa8?"がインポートフォーマットPGN指し手に現れたら、 それは2つの並んだ記号"Qxa8 $2"におきかえられる。 (訳注:2002年現在でこれをサポートしているソフトウエアがあるのだろうか?訳者はNAG表記のあるPGNファイルを見たことがない。)

8.2.4.指し手NAG (Numeric Annotation Glyph)

NAG (Numeric Annotation Glyph)は、 言語から独立した方法で単純な注釈を示すのに用いられる指し手の要素である。 NAGは非負の整数接尾辞とドル記号("$")から形成される。 非負の整数は0から255でなければならない。

8.2.5.指し手RAV (Recursive Annotation Variation)

RAV (Recursive Annotation Variation)は1つ以上の指し手を含む括弧で囲まれた指し手の並びである。 RAVは任意のバリエーションを表現するのに用いられる。 RAVで与えられた任意の指し手の並びは、 RAVの直前に現れる最初のプレイされない指し手によって、合法的に指されたかもしれないものである。 RAVは再帰構造なので、それはネストするかもしれない。

***RAV要素のインポート/エクスポート表現の詳細は更なる開発を必要とする。

8.2.6.ゲーム終了マーカー

それぞれの指し手部分は正確に1つのゲーム終了マーカーを持つ; そのマーカーは指し手の最後の要素として常に現われる。 ゲーム終了マーカーは次の4つの値の内1つである: それは"1-0"(白勝ち)、"0-1"(黒勝ち)、"1/2-1/2"(引き分け)、"*"(ゲームは進行中、結果がわからない、放棄された)である。 整数0が上で用いられることを記しておく;それは大文字の"O"ではない。 ゲームの指し手に現れるゲーム終了マーカーはゲームのResultタグの値と一致しなければならない。 (マーカーはResultタグに文字列として現れるので、それは指し手で引用符無しの記号として現れる。)

9.補足タグ名

次のタグ名とそれに関連した意味はSeven Tag Rosterに含まれない情報のために用いることが推奨される。

9.1.プレイヤーに関する情報

もしプレイヤータグ(白、黒)のインスタンス内に1人以上のプレイヤーフィールドがあれば、 それらは次のように関連するマルチフィールドのタグであるだろう。 例えば、もしWhiteタグが3つの値"Jones:Smith:Zacharias"を持っていた場合、 JonesがIM、Smithが無タイトル、ZachariasがGMなら、 WhiteTitleタグは"IM:-:GM"という値を持つことが出来る。

9.1.1.タグ:WhiteTitle

これらは"FM", "IM", "GM"のような文字列を用いる; これらのタグはFIDEタイトルの標準的な略語のみに用いられる。 "-"はタイトルを持たないプレイヤーに用いられる。

9.1.2.タグ:WhiteElo

これらのタグは整数値を用いる; これらはFIDEイロレーティングに用いられる。"-"はレーティングを持たないプレイヤーに用いられる。

9.1.3.タグ:WhiteUSCF

これらのタグは整数値を用いる;これらはUSCF (United States Chess Federation)レーティングに用いられる。 類似したタグ名はその他のレーティング機関のために構築することが出来る。

9.1.4.タグ:WhiteNA

これらのタグは文字列を用いる; これらはプレイヤーの電子メールアドレスまたはネットワークアドレスである。 "-"は電子的なアドレスを持たないプレイヤーに用いられる。

9.1.5.タグ:WhiteType

これらのタグは文字列を用いる; これらはプレイヤーのタイプを表す。 "human"は人間に、"program"はアルゴリズム(コンピュータ)のプレイヤーに用いられるべきだ。

9.2.イベントに関する情報

次のタグはイベントの追加情報を提供するのに用いられる。

9.2.1.タグ:EventDate

これはDateタグフィールドに似たデータ値を用いる。これはイベントの開始した日付を提供する。

9.2.2.タグ:EventSponsor

これはイベントのスポンサー名を表す文字列を用いる。

9.2.3.タグ:Section

これは文字列を用いる; これはトーナメントのプレイされるセクション(例えば"Open"または"Reserve")に用いられる。

9.2.4.タグ:Stage

これは文字列を用いる; これはマルチステージのイベント(例えば"Preliminary"または"Semifinal")に用いられる。

9.2.5.タグ:Board

これは整数を用いる; これはチームイベントや同時対局におけるボード番号を表す。

9.3.オープニング情報(ローカルスペック)

次のタグは伝統的なオープニング名に用いられる。 関連したタグの値は用いられている地域的な言語によって変わるだろう。

9.3.1.タグ:Opening

これは文字列を用いる; これは伝統的なオープニング名に用いられる。これは地域によって変わるだろう。 このタグはこのドキュメントの後のセクションで記述されるEPDオープニングコード"v0"の使用に関連している。

9.3.2.タグ:Variation

これは文字列を用いる; これはOpeningタグをより洗練するのに用いる。これは地域によって変わるだろう。 このタグはこのドキュメントの後のセクションで記述されるEPDオープニングコード"v1"の使用に関連している。

9.3.3.タグ:SubVariation

これは文字列を用いる; これはVariationタグをより洗練するのに用いる。これは地域によって変わるだろう。 このタグはこのドキュメントの後のセクションで記述されるEPDオープニングコード"v2"の使用に関連している。

9.4.オープニング情報(サードパーティベンダー)

次のタグはオープニングの区別を表すために用いられる。 これらの組織の参照は、これらのいかなる是認も、これらによるいかなる是認も意味するものではない。

9.4.1.タグ:ECO

これは"XDD"または"XDD/DD"のどちらかの文字列を用いる。ここで"X"は"A"から"E"の文字で、"D"は数字である; これは5冊の"Encyclopedia of Chess Openings"から、オープニング名称に用いられる。 このタグはこのドキュメントの後のセクションで記述されるEPDオープニングコード"eco"の使用に関連している。

9.4.2.タグ:NIC

これは文字列を用いる; これは"New in Chess"データベースから、オープニング名称に用いられる。 このタグはこのドキュメントの後のセクションで記述されるEPDオープニングコード"nic"の使用に関連している。

9.5.時間と日付に関する情報

次のタグはゲームに関連した時間と日付の情報の更なる改善を助ける。

9.5.1.タグ:Time

これは"HH:MM:SS"という形で時間を表すのに用いる; これは、その地域のゲームがスタートした時間(時、分、秒)を示すことを除いて、Dateタグに似ている。 (ピリオドでなく)コロンがTimeタグの値を分割するのに用いられることを注記しておく。 この値はSiteタグの中で与えられる地域に関連したその地域の時間が採用される。

9.5.2.タグ:UTCTime

このタグは、時間がUniversal Coordinated Time standardで与えられることを除いて、Timeタグに似ている。

9.5.3.タグ:UTCDate

このタグは、日付がUniversal Coordinated Time standardで与えられることを除いて、Dateタグに似ている。

9.6.タイムコントロール

次のタグはゲームで用いられたタイムコントロールを記述する手助けとして用いられる。

9.6.1.タグ:TimeControl

これは1つ以上のタイムコントロールフィールドのリストを用いる。 各フィールドは各タイムコントロールピリオドのための記述子を含む; もし1つ以上の記述子が与えられていたら、それらはコロン(":")で分割される。 記述子は彼らがゲームで用いた順番で現れる。 最後に現れたフィールドは、必要に応じて更なるコントロールピリオドのために、暗黙の内に繰り返されるように考慮される。

6種類のTimeControlフィールドがある。

最初のフィールドは単独のクエスチョンマーク("?")で、これはタイムコントロールモードが不明であることを意味する。 これが用いられるとき、普通は記述子だけが与えられる。

第2のフィールドは単独のハイフン("-")で、これはタイムコントロールモードが用いられなかったことを意味する。 これが用いられるとき、普通は記述子だけが与えられる。

第3のフィールドはスラッシュ("/")で分けられた2つの正の整数という形をしている。 最初の整数はこの時間での指し手の数で、2番目はその時間での秒数である。 従って、40手2時間半のタイムコントロールピリオドは"40/9000"と表されるだろう。

第4のフィールドは"サドンデス"コントロールピリオドに用いられる。 それはTimeControlタグの値の内、最後の記述子としてのみ用いられるべきである。 それは時々、記述子のみが与えられる。 そのフォーマットは、そのピリオド内で秒数を与える単独の整数からなる。 従って、ブリッツゲームは"300"という値のTimeControlタグで表現されるだろう。

第5のフィールドは"追加"のコントロールピリオドに用いられる。 それはTimeControlタグの値の内、最後の記述子としてのみ用いられるべきであり、 普通その値には記述子のみがあるべきである。 そのフォーマットはプラス記号("+")で分割された2つの正の整数からなる。 最初の整数はそのピリオドに割り当てられた最少の秒数を与え、 2つ目の整数は各指し手が指された後追加される秒数を与える。 従って、90分と1手当たり1分時間を追加するタイムコントロールはTimeControlタグの中では"4500+60"と与えられるだろう。

第6のフィールドは"砂時計"のコントロールピリオドに用いられる。 それはTimeControlタグの値の内、最後の記述子としてのみ用いられるべきであり、 普通その値には記述子のみがあるべきである。 そのフォーマットはアスタリスク("*")と直後に与えられる正の整数からなる。 整数は砂時計ピリオドにおいて全秒数を与える。 タイムコントロールは、砂時計が最初2つの"小部屋"に同じ量だけ砂がセットされ、 プレイヤーは指し手の後砂時計を逆にし、使用した時間は上の小部屋の空きによって示される、 というように実装される。物理的な砂時計の電子的な実装が用いられる。 一般的な3分のエッグタイマーという砂時計の例は"*180"となる。

ほかのTimeControlフィールドは必要に応じて定義されるだろう。

9.7.任意の初期配置

普通の初期配置から始まらないゲームを記述する手助けのために2つのタグが定義される。

9.7.1.タグ:Setup

このタグはゲームの状態が"セットアップ"であることを示す整数を取る。 "0"は普通の初期配置からゲームが始まっていることを示す。 "1"はゲームがセットアップポジションから始まったことを示す; このポジションは"FEN"タグによって与えられる。 このタグはセットアップポジションから始まるゲームに使用されなければならない。 もしそのタグが"1"の値を持つなら、FENタグも使用されなければならない。

9.7.2.タグ:FEN

このタグはゲームで用いられた初期配置のためにForsyth-Edwards Notationで与えられた文字列を用いる。 FENはこの文章の後の章で記述される。 もしSetUpタグが"1"で使用されたら、FENタグも使用されなければならない。

9.8.ゲーム結果

ゲームの結果を記述するために1つのタグがある。

9.8.1.タグ:Termination

これはゲームの結果の理由を記述する文字列を取る。 Resultタグがゲームの結果を与えるが、それはそれ以外の情報を提供せず、 そのためTerminationタグがこの目的のために定義されている。

Terminationタグの値として現れる文字列は:

9.9.種々雑多なもの

これらは簡潔に記述することの出来るが、この章以外の章に上手に適さないタグである。

9.9.1.タグ:Annotator

このタグは、プレイヤー名タグのフォーマットで、名前に用いられる; これはゲームの注釈者達を見分ける。

9.9.2.タグ:Mode

これはゲームのプレイモードを与える文字列に用いられる。 例:"OTB" (over the board), "PM" (paper mail), "EM" (electronic mail), "ICS" (Internet Chess Server), "TC" (general telecommunication)

9.9.3.タグ:PlyCount

このタグはゲームが何往復したか(何手指されたか)を与える1つの整数を取る。

10.Numeric Annotation Glyphs

NAGで0はヌル文字に用いられる; それはソフトウエアデザイナーの利便性のためにプレースホルダーとして提供され、 外部PGNデータとしては多分用いるべきではない。

1から9のNAG値は指された指し手の注釈をつける。

10から135のNAG値は現在のポジションを修正する。

136から139のNAG値はタイムプレッシャーを記述する。

他のNAG値は将来の定義のために予約されている。

注記:下に並べられた数の割り当ては当然のことながら予備として考慮されるべきである; それらは多分レビュアーのフィードバックの結果によって変えられるだろう。

NAGの説明
0 ヌル文字
1 好手("!")
2 悪手("?")
3 絶好手("!!")
4 大悪手("??")
5 妙手("!?")
6 疑問手("?!")
7 強要手(その他の手はすぐに負ける)
8 単一手(尤らしい手がない)
9 最悪手
10 引き分けのポジション
11 等しくチャンスがあり、静かなポジション
12 等しくチャンスがあり、激しいポジション
13 不明瞭なポジション
14 白やや有利
15 黒やや有利
16 白有利
17 黒有利
18 白明らかに有利
19 黒明らかに有利
20 白圧倒的に有利(黒はリザインするべき)
21 黒圧倒的に有利(白はリザインするべき)
22 白はツークツワンク状態にある
23 黒はツークツワンク状態にある
24 白ややスペースアドバンテージあり
25 黒ややスペースアドバンテージあり
26 白スペースアドバンテージあり
27 黒スペースアドバンテージあり
28 白明らかにスペースアドバンテージあり
29 黒明らかにスペースアドバンテージあり
30 白ややタイム(展開の)アドバンテージあり
31 黒ややタイム(展開の)アドバンテージあり
32 白タイム(展開の)アドバンテージあり
33 黒タイム(展開の)アドバンテージあり
34 白明らかにタイム(展開の)アドバンテージあり
35 黒明らかにタイム(展開の)アドバンテージあり
36 白に主導権あり
37 黒に主導権あり
38 白に永続的主導権あり
39 黒に永続的主導権あり
40 白攻撃の手あり
41 黒攻撃の手あり
42 白駒損の対価が不足
43 黒駒損の対価が不足
44 白駒損の対価が十分
45 黒駒損の対価が十分
46 白駒損の対価が十二分
47 黒駒損の対価が十二分
48 白ややセンターコントロールアドバンテージあり
49 黒ややセンターコントロールアドバンテージあり
50 白センターコントロールアドバンテージあり
51 黒センターコントロールアドバンテージあり
52 白明らかにセンターコントロールアドバンテージあり
53 黒明らかにセンターコントロールアドバンテージあり
54 白ややキングサイドコントロールアドバンテージあり
55 黒ややキングサイドコントロールアドバンテージあり
56 白キングサイドコントロールアドバンテージあり
57 黒キングサイドコントロールアドバンテージあり
58 白明らかにキングサイドコントロールアドバンテージあり
59 黒明らかにキングサイドコントロールアドバンテージあり
60 白ややクイーンサイドコントロールアドバンテージあり
61 黒ややクイーンサイドコントロールアドバンテージあり
62 白クイーンサイドコントロールアドバンテージあり
63 黒クイーンサイドコントロールアドバンテージあり
64 白明らかにクイーンサイドコントロールアドバンテージあり
65 黒明らかにクイーンサイドコントロールアドバンテージあり
66 白の第1ランクは危険
67 黒の第1ランクは危険
68 白の第1ランクは安全
69 黒の第1ランクは安全
70 白キングは危険
71 黒キングは危険
72 白キングは安全
73 黒キングは安全
74 白キングの位置は危険
75 黒キングの位置は危険
76 白キングの位置は安全
77 黒キングの位置は安全
78 白に非常に弱いポーンストラクチャあり
79 黒に非常に弱いポーンストラクチャあり
80 白に弱いポーンストラクチャあり
81 黒に弱いポーンストラクチャあり
82 白に強いポーンストラクチャあり
83 黒に強いポーンストラクチャあり
84 白に非常に強いポーンストラクチャあり
85 黒に非常に強いポーンストラクチャあり
86 白に悪いナイトあり
87 黒に悪いナイトあり
88 白に良いナイトあり
89 黒に良いナイトあり
90 白に悪いビショップあり
91 黒に悪いビショップあり
92 白に良いビショップあり
93 黒に良いビショップあり
94 白に悪いルックあり
95 黒に悪いルックあり
96 白に良いルックあり
97 黒に良いルックあり
98 白に悪いクイーンあり
99 黒に悪いクイーンあり
100 白に良いクイーンあり
101 黒に良いクイーンあり
102 白ピース的に不利
103 黒ピース的に不利
104 白ピース的に有利
105 黒ピース的に有利
106 白のオープニング非常に悪い
107 黒のオープニング非常に悪い
108 白のオープニング悪い
109 黒のオープニング悪い
110 白のオープニング良い
111 黒のオープニング良い
112 白のオープニング非常に良い
113 黒のオープニング非常に良い
114 白のミドルゲーム非常に悪い
115 黒のミドルゲーム非常に悪い
116 白のミドルゲーム悪い
117 黒のミドルゲーム悪い
118 白のミドルゲーム良い
119 黒のミドルゲーム良い
120 白のミドルゲーム非常に良い
121 黒のミドルゲーム非常に良い
122 白のエンディング非常に悪い
123 黒のエンディング非常に悪い
124 白のエンディング悪い
125 黒のエンディング悪い
126 白のエンディング良い
127 黒のエンディング良い
128 白のエンディング非常に良い
129 黒のエンディング非常に良い
130 白わずかにカウンタープレイあり
131 黒わずかにカウンタープレイあり
132 白カウンタープレイあり
133 黒カウンタープレイあり
134 白決定的なカウンタープレイあり
135 黒決定的なカウンタープレイあり
136 白タイムコントロールプレッシャーあり
137 黒タイムコントロールプレッシャーあり
136 白厳しいタイムコントロールプレッシャーあり
137 黒厳しいタイムコントロールプレッシャーあり

11.ファイル名とディレクトリ

PGNデータに選ばれたファイル名は有益かつ小さくなければならない。 ディレクトリ名と配列もまた同じ理由で選ばれるべきで操作が容易でなければならない。 提案されたファイル名・ディレクトリ名のいくつかは実際のコンピュータシステムで表現するのは難しいか不可能かもしれない。 適切な転換習慣の使用は奨励される。

11.1.PGNデータファイル名の拡張子

ファイル拡張子".pgn"の使用はPGNデータを含むASCIIテキストファイルで奨励される。

11.2.特定のプレイヤーのPGNデータのファイル名形成

特定のプレイヤーのPGNゲームはプレイヤーの苗字とそれに続く".pgn"拡張子からなるファイル名を持つべきである。

11.3.特定のイベントのPGNデータのファイル名形成

特定のイベントのPGNゲームはイベント名とそれに続く".pgn"拡張子からなるファイル名を持つべきである。

11.4.年代順に並べれられたゲームのPGNデータのファイル名形成

(古いものから順に)年代順に並べられたアーカイブに使用されるPGNデータファイルはファイル名のルート文字列として日付情報を用いる。 与えられた年の全てのPGNゲームを含むファイルは"YYYY.pgn"という形式の8文字の名前を持つだろう。 与えられた月の全てのPGNゲームを含むファイルは"YYYYMM.pgn"という形式の10文字の名前を持つだろう。 最後に、ある日のPGNゲームを含むファイルは"YYYYMMDD.pgn"という形式の12文字の名前を持つだろう。 大きなファイルは必要に応じてより小さなファイルに分割される。

ゲームファイルは一般的に年代順に並べられるとき、Dateタグがないまたは不完全なゲームは避けられる。 ファイル内の照合やファイルの名前をつけるのに、 Dateタグの中のどんなクエスチョンマークも数字の0として扱われるだろう。

年代順に並べられた多くのPGNデータは階層的ディレクトリの中に組織化されるべきだ。 与えられた年の全てのPGNデータを含むディレクトリは"YYYY"という4文字の名前を持つだろう; 与えられた月のPGNファイルを含むディレクトリは"YYYYDD"という6文字の名前を持つだろう。

11.5.提案されたディレクトリツリー構造

FTPサイトやCD-ROM配布のために提案されたディレクトリ構造は:
PGNPGN部分木の主ディレクトリ(pub/chess/GameDatabases/PGN)
PGN/Events特定のイベントに関する、PGNファイルのディレクトリ
PGN/Events/Newsイベントのニュースと状態
PGN/Events/ReadMeローカルディレクトリの内容の短い記述
PGN/MGRMaster Games Repository部分木のディレクトリ
PGN/MGR/NewsPGN/MGR部分木全体のニュースと状態
PGN/MGR/ReadMeローカルディレクトリの内容の短い記述
PGN/MGR/YYYYYYYY年のゲームの部分木またはディレクトリ
PGN/MGR/YYYY/ReadMeYYYY年のローカルディレクトリの記述
PGN/MGR/YYYY/NewsYYYY年のニュースと状態
PGN/NewsPGN部分木全体のニュースと状態
PGN/Players特定のプレイヤーの、PGNファイルのディレクトリ
PGN/Players/Newsプレイヤーコレクションのニュースと状態
PGN/Players/ReadMeローカルディレクトリの内容の短い記述
PGN/ReadMeローカルディレクトリの内容の短い記述
PGN/StandardPGN規格(この文章)
PGN/ToolsPGNデータにアクセスするソフトウエアユーティリティ

12.PGNを並べる順

ファイル内のPGNゲームをソートする標準的な順番がある。 この照合は8つのキーを元にしている;これらはSTRの7つのタグ値と指し手そのものである。

(最も重要な基本キーである)1つ目はDateタグである。日付の早いゲームは遅い日付のゲームの前に現れる。 このフィールドは年、月、日の順で、昇順の数値によってソートされる。 不明な日付の10進数値に用いられる疑問符文字は比較の順番として10進数の0として扱われるだろう。

2つ目はEventタグである。これはASCII文字の昇順でソートされる。

3つ目はSiteタグである。これはASCII文字の昇順でソートされる。

4つ目はRoundタグである。 これはプレイラウンドを示すのに用いられる整数値を基に昇順でソートされる。 ラウンドに用いられる疑問符やハイフンはどんな数値よりも前に並べられる。 疑問符文字はハイフン文字の前に並べられる。

5つ目はWhiteタグである。これはASCII文字の昇順でソートされる。

6つ目はBlackタグである。これはASCII文字の昇順でソートされる。

7つ目はResultタグである。これはASCII文字の昇順でソートされる。

8つ目は指し手そのものである。 これはスペースや改行文字を含む全体のテキストのASCII文字の昇順でソートされる。

13.PGNソフトウエア

この章では、一般に手に入るもしくは近い将来手に入ると思われるいくつかのPGNソフトウエアを記述する。 エントリーはそれらがPGN規格の調整役として知られるようになる大雑把な年代順に表示される。 PGNを利用可能なソフトウエアの著者は調整役(Eメールアドレスがこの文章の最初近くに掲載されている)に連絡することを奨励されるため、 情報がこの章に含まれているかもしれない。

PGN規格に加えて、チェスソフトウエアコミュニティが興味のある2つのチェス規格がある。 それらはポジションを表記するためのFEN(Forsyth-Edwards Notation)規格と、 自動化されたプログラム間処理のための包括的なポジション記述のためのEPD(Extended Position Description)規格である。 これらはこの文章の後の章で記述されている。

いくつかのPGNソフトウエアはフリーウエアでFTPサイトや他のソースから得ることが出来る。 他のPGNソフトウエアはペイウエアで、チェスを指すプログラムやチェスデータベースマネージャーのコマーシャルの一部として現れる。 PGN規格の普及に興味を持った人達は規格を用いるチェスソフトウエアの製造業者をサポートすることを奨励される。 もし特定の販売元がPGNとの互換性を提案しない場合、 多分この規格のコピーと一緒に彼ら宛てのいくつかの手紙が次のリリースでPGNのサポートを決定させる助けになるかもしれない。

ノルマンジー地方(USA)のオクラホマの大学にいるスタッフは、 チェスに関連したデータとプログラムの倉庫として、 丁重にFTPサイトchess.uoknor.eduを提供する。 時間経過によりファイル名は変更するため、 これらのサイトを呼び出すのは現在の一覧表のためのファイル"pub/chess/ls-lR.gz"を最初に復活させることを奨励される。 この一覧表のスキャンは、 下に載せられた以外のマシーンタイプやOSのためのPGNプログラムのバージョンを突きとめる助けにもなるだろう。 このアーカイブの更なる情報はその管理者Chris Petroffchris@uoknor.eduから得ることが出来る。

ヨーロッパのユーザのために、ハンブルグ(ドイツ)の大学にいる親切なスタッフがFTPサイトftp.math.uni-hamburg.deを提供している; これはchess.uoknor.edu siteにあるpub/chessディレクトリのミラーに毎日運ぶ。

13.1.SANキット

"SANキット"は、ファイル"SAN.tar.gz"(gzip tarアーカイブ)として、 FTPサイトchess.uoknor.eduのディレクトリpub/chess/Unixからフリーとして提供されているチェスプログラミングツールキットのANSI Cソースである。 このキットはPGNのインポートとエクスポートのためのコードを含み、 その中の"tfgg"コマンドの使用によって小さくされたエクスポートフォーマットへPGNデータを"正規化する"のに用いることが出来る。 SANキットはまたFEN入出力をサポートする。 このキットからのコードは、将来の配布が皆に妨害されていない限り、誰でも自由に再配布できる。 SANキットはいまだ開発中であり、 また、将来の交付の日付は予言するのがかなり難しく、リリースは時々数ヶ月ずれることもある。 提案とコメントはその著者Steven J. Edwards sje@world.std.comに向けられるべきである。

13.2.pgnRead

13.3.mail2pgn/GIICS

13.4.XBoard

13.5.cupgn

13.6.Zarkov

13.7.Chess Assistant

13.8.BOOKUP

13.9.HIARCS

13.10.Deja Vu

13.11.MV2PGN

13.12.The Hansen utilities (cb2pgn, nic2pgn, pgn2cb, pgn2nic)

13.13.Slappy the Database

13.14.CBASCII

13.15.ZZZZZZ

13.16.icsconv

13.17.CHESSOP (CHESSOPN/CHESSOPG)

13.18.CAT2PGN

13.19.pgn2opg

14.PGNデータアーカイブ

基本的なPGNデータアーカイブの貯蔵場所は、 FTPサイトchess.uoknor.eduのディレクトリ"pub/chess/Game-Databases/PGN"に位置する。 それはこのドキュメントのC.5章に与えられる記述にしたがって組織される。 ヨーロッパのサイトftp.math.uni-hamburg.deもまた貯蔵場所の定期的なアップデートのコピーを運ぶことを届け出ている。

15.国際オリンピック委員会の国コード

国際オリンピック委員会の国コードは、国際的なスポーツイベントの報告に伝統的に用いられているため、 場所や民族の情報として使用される。 地理や言語習慣の変化のために、次のようないくつかのものは不正確もしくは古いかもしれない。 校正や拡張はPGNの取りまとめ役に電子メールによって送られるべきだ。 彼のアドレスはこの文章の最初付近に書かれている。
AFG: Afghanistan
AIR: Aboard aircraft
ALB: Albania
ALG: Algeria
AND: Andorra
ANG: Angola
ANT: Antigua
ARG: Argentina
ARM: Armenia
ATA: Antarctica
AUS: Australia
AZB: Azerbaijan
BAN: Bangladesh
BAR: Bahrain
BHM: Bahamas
BEL: Belgium
BER: Bermuda
BIH: Bosnia and Herzegovina
BLA: Belarus
BLG: Bulgaria
BLZ: Belize
BOL: Bolivia
BRB: Barbados
BRS: Brazil
BRU: Brunei
BSW: Botswana
CAN: Canada
CHI: Chile
COL: Columbia
CRA: Costa Rica
CRO: Croatia
CSR: Czechoslovakia
CUB: Cuba
CYP: Cyprus
DEN: Denmark
DOM: Dominican Republic
ECU: Ecuador
EGY: Egypt
ENG: England
ESP: Spain
EST: Estonia
FAI: Faroe Islands
FIJ: Fiji
FIN: Finland
FRA: France
GAM: Gambia
GCI: Guernsey-Jersey
GEO: Georgia
GER: Germany
GHA: Ghana
GRC: Greece
GUA: Guatemala
GUY: Guyana
HAI: Haiti
HKG: Hong Kong
HON: Honduras
HUN: Hungary
IND: India
IRL: Ireland
IRN: Iran
IRQ: Iraq
ISD: Iceland
ISR: Israel
ITA: Italy
IVO: Ivory Coast
JAM: Jamaica
JAP: Japan
JRD: Jordan
JUG: Yugoslavia
KAZ: Kazakhstan
KEN: Kenya
KIR: Kyrgyzstan
KUW: Kuwait
LAT: Latvia
LEB: Lebanon
LIB: Libya
LIC: Liechtenstein
LTU: Lithuania
LUX: Luxembourg
MAL: Malaysia
MAU: Mauritania
MEX: Mexico
MLI: Mali
MLT: Malta
MNC: Monaco
MOL: Moldova
MON: Mongolia
MOZ: Mozambique
MRC: Morocco
MRT: Mauritius
MYN: Myanmar
NCG: Nicaragua
NET: The Internet
NIG: Nigeria
NLA: Netherlands Antilles
NLD: Netherlands
NOR: Norway
NZD: New Zealand
OST: Austria
PAK: Pakistan
PAL: Palestine
PAN: Panama
PAR: Paraguay
PER: Peru
PHI: Philippines
PNG: Papua New Guinea
POL: Poland
POR: Portugal
PRC: People's Republic of China
PRO: Puerto Rico
QTR: Qatar
RIN: Indonesia
ROM: Romania
RUS: Russia
SAF: South Africa
SAL: El Salvador
SCO: Scotland
SEA: At Sea
SEN: Senegal
SEY: Seychelles
SIP: Singapore
SLV: Slovenia
SMA: San Marino
SPC: Aboard spacecraft
SRI: Sri Lanka
SUD: Sudan
SUR: Surinam
SVE: Sweden
SWZ: Switzerland
SYR: Syria
TAI: Thailand
TMT: Turkmenistan
TRK: Turkey
TTO: Trinidad and Tobago
TUN: Tunisia
UAE: United Arab Emirates
UGA: Uganda
UKR: Ukraine
UNK: Unknown
URU: Uruguay
USA: United States of America
UZB: Uzbekistan
VEN: Venezuela
VGB: British Virgin Islands
VIE: Vietnam
VUS: U.S. Virgin Islands
WLS: Wales
YEM: Yemen
YUG: Yugoslavia
ZAM: Zambia
ZIM: Zimbabwe
ZRE: Zaire
			

16.追加のチェスデータ規格

PGNがゲームのストレージとして用いられるとき、チェスの他の目的のための他のデータ表現規格がある。 2つの重要な規格はFENとEPDであり、両方ともこの章に記述されている。

16.1.FEN

FENは"Forsyth-Edwards Notation"である; それはASCII文字の集合を用いてチェスのポジションを記述するための規格である。

1つのFENレコードは6個のデータフィールドで構成される可変長のテキスト行1行を用いる。 FEN規格の最初の4つのフィールドはEPD規格の最初の4つのフィールドと同じである。

専らFENデータレコードから構成されるテキストファイルはファイル名の拡張子に".fen"を持つべきだ。

16.1.1.歴史

FENは、新聞ジャーナリストであるScotsman David Forsythによってデザインされた、 ポジションを記録するための19世紀の企画を基にしている。 元のForsyth規格は、Steven Edwardsとインターネットのコメンテーターの助力によって、 チェスソフトウエアでの使用のために少し拡張されている。 この新しい規格FENはEdwardのSANキットに初めて実装された。

16.1.2.ポジション表記のための使用

標準的なポジションの表記法を持つことは、チェスプログラマーにとって、 ポジションデータベースを共有することをゆるすとして特に重要である。 例えば、チェスを指すプログラムのための古典的なベンチマークテストを多く持つ、 標準的なポジション表記データベースが存在し、 一般的なポジション表記フォーマットを用いることにより、 何時間もの退屈なデータを入れる作業を抑えることが出来る。 加えて、ポジション表記はページレイアウトプログラムやEメールチェスでポジションの状態を確認するのに便利である。

FENを用いて表現された多くの興味深いチェスプロブレムの集合はFTPサイトchess.uoknor.eduのpub/chess/SAN_testsuitesで見つけることが出来る。

16.1.3.データフィールド

FENはピースの配置、手番、キャスリング可能性、アンパッサンの目的のマス、ハーフムーブクロック、手数を明確にする。 これらは、容易に読むことの出来るフォーマットで、テキスト1行に全て上手くはまることが出来る。 FENポジション記述の長さはポジションによってやや変わる。 いくつかの場合、記述は長さで80文字以上であり、 いくつかのディスプレイで都合良くフィットしないかもしれない。 けれども、これらのポジションはかなり普通ではない。

FENの記述は6つのフィールドを持つ。 それぞれのフィールドは空白でないASCII文字のみで構成される。 隣接したフィールドは1つのASCIIスペース文字で分けられる。

16.1.4.ピース配置データ

最初のフィールドはボード上のピースの配置を表す。 ボードの中身は8ランクから始まり1ランクで終わるように指定される。 それぞれのランクでは、マスはファイルaからファイルhの順で指定される。 白のピースはSANの駒文字の大文字("PNBRQK")で特徴付けられ、 黒の駒はSANの駒文字の小文字("pnbrqk")で特徴付けられる。 空のマスは10進数の1から8で表される; 10進数はランクで隣接した空のマスの数を表すのに用いられる。 スラッシュ文字"/"は隣接したランクのデータを分けるのに用いられる。

16.1.5.手番

2番目のフィールドは手番を表す。 小文字の"w"は白の手番のとき用いられる;小文字の"b"は黒の手番のとき用いられる。

16.1.6.キャスリング可能性

3番目のフィールドはキャスリング可能性をあらわす。 これは、駒が邪魔していたり敵のアタックなどでその瞬間で可能かどうか、 将来のキャスリングの可能性を示す。 もしどちらの側もキャスリングが出来ないなら、 1つの文字"-"が用いられる。 でなければ、1から4文字の組み合せが表示される。 もし白がキングサイドキャスリングできるなら、大文字の"K"が現れる。 もし白がクイーンサイドキャスリングできるなら、大文字の"Q"が現れる。 もし黒がキングサイドキャスリングできるなら、小文字の"k"が現れる。 もし黒がクイーンサイドキャスリングできるなら、小文字の"q"が現れる。 これらの現れた文字は、最初に大文字小文字の順で、次にキングサイドクイーンサイドの順で並べられるだろう 文字の間にはスペースは現れない。

16.1.7.アンパッサンの目的のマス

4番目のフィールドはアンパッサンの目的のマスである。 もしアンパッサンの目的のマスがなければ、1文字の"-"が現れる。 もしアンパッサンの目的のマスが1つあれば、小文字のファイル名と直後にランクの10進数が表される。 明らかに、(黒の手番で)白のポーンが2マス動いた後なら、ランクの数字は"3"だろうし、 (白の手番で)黒のポーンが2マス動いた後なら、ランクの数字は"6"だろう。

最後の指し手がポーンを2マス動かしたとき、かつそのときに限り、アンパッサンの目的のマスが与えられる。 したがって、アンパッサンの目的のマスのフィールドは、 アンパッサンの捕獲を直後に実行するかもしれない相手のポーンがなくても、マスの名前を持つかもしれない。

16.1.8.ハーフムーブクロック

5番目のフィールドはハーフムーブクロックを表す非負の整数である。 この数は最後にポーンが進んでからか駒が取られる手を指されてからのハーフムーブの数である。 この値は50手ルールに用いられる。

16.1.9.手数

6番目のフィールドは手数を与える正の整数である。 これは白と黒の両方の第1手から"1"の値を持つだろう。 それは黒の指し手それぞれの直後に1づつインクリメントされるだろう。

16.1.10.例

これは初期配置のFENである:
rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1
そして1.e4の後には:
rnbqkbnr/pppppppp/8/8/4P3/8/PPPP1PPP/RNBQKBNR b KQkq e3 0 1
そして1...c5の後には:
rnbqkbnr/pp1ppppp/8/2p5/4P3/8/PPPP1PPP/RNBQKBNR w KQkq c6 0 2
そして2.Nf3の後には:
rnbqkbnr/pp1ppppp/8/2p5/4P3/5N2/PPPP1PPP/RNBQKB1R b KQkq - 1 2

2つのキングが元の位置にあり、(白の手番で)e2に白のポーンがあり、 38手指され、最後にポーンが動いてからもしくは最後に捕獲が行なわれてからのハーフムーブが5手の場合:
4k3/8/8/8/8/8/4P3/4K3 w - - 5 39

16.2.EPD

EPDは"Extended Position Description"である; それは、ASCII文字集合を用いた、構造化された属性値の拡張された集合と一緒にチェスのポジションを記述するための規格である。 それはチェスを指すプログラムの間でデータとコマンドを変換することを意図している。 それはまた手軽なオープニングライブラリ倉庫の表現も意図している。

1つのEPDは、4つのデータフィールドとそれに続く0個以上の命令から構成される、可変長のテキスト行1行を用いる。 EPD規格の4つのフィールドはFEN規格の最初の4つのフィールドと同じである。

EPDデータレコードで独占的に構成されるテキストファイルはファイル名に拡張子".epd"を持つべきだ。

16.2.1.歴史

EPDは初期のFEN規格の一部を基にしている; それは、オープニングライブラリの準備での使用のためと、上級のチェスプログラム間で一般的なデータとコマンドの交換のための拡張を加えられている。 EPDはJohn StanbackとSteven Edwardsによって開発された; その最初の実装はStanbackの作成したマスタークラスの強さを持つチェスプログラムZarkovである。

16.2.2.拡張ポジション表記のための使用

FENのように、EPDは一般的なポジション記述を使用することも出来る。 けれども、FENと異なり、EPDは、必要性が生じた新たな機能性を提供する新たな命令の追加によって、拡張可能なようにデザインされた。

EPDを用いて表現された多くの興味深いチェスプログラムの集合は、 FTPサイトchess.uoknor.eduのディレクトリpub/chess/SAN_testsuitesで見つけることが出来る。

16.2.3.データフィールド

EPDは、ピースの配置、手番、キャスリング可能性、アンパッサンの目的のマス、を指定する。 これらは読みやすいフォーマットで1行に収めることが出来る。 EPDポジション記述の長さはポジションと関連した命令によってやや変化する。 いくつかの場合、その記述は80文字以上になり、そのためいくつかのディスプレイでは1行に収まらないかもしれない。 けれども、ほとんどのEPD記述はプログラム間でのみやり取りされて、これらはプログラムのユーザに見られることは普通無い。

(注記:将来EPDが拡張されたときのために、 EPDを実装する場合はそのプログラムが1024文字までEPDテキスト行を扱えることを推奨する。)

各EPDデータフィールドはブランクでないASCII印刷文字のみで構成される。 隣接したデータフィールドは1つのASCIIスペース文字で分割される。

16.2.4.ピース配置データ

最初のフィールドはボード上の駒の配置を表現する。 ボード部分は8ランクから始まり1ランクで終わるように指定される。 それぞれのランクは、aファイルからfファイルの順にマスが指定される。 白の駒は大文字のSANの駒文字("PNBRQK")で表され、黒の駒は小文字のSANの駒文字("pnbrqk")で表される。 空白のマスは1から8の数字で表される;数字はあるランクで隣接した空白のマスの数を表すのに用いられる。 スラッシュ文字"/"は隣接したランクのデータを分割するのに用いられる。

16.2.5.手番

2番目のフィールドは手番を表す。小文字の"w"は白番のとき用いられる;小文字の"b"は黒番のとき用いられる。

16.2.6.キャスリング可能性

3番目のフィールドはキャスリングの可能性を表す。 これは、ブロックしているピースや敵のアタックによってその瞬間キャスリングが可能かどうか、将来的な可能性を示す。 もしどちらの側にもキャスリングが出来ないなら、"-"1文字が用いられる。 でなければ、1文字から4文字の組み合せが表される。 もし白がキングサイドにキャスリングできるなら、大文字の"K"が現れる。 もし白がクイーンサイドにキャスリングできるなら、大文字の"Q"が現れる。 もし黒がキングサイドにキャスリングできるなら、小文字の"k"が現れる。 もし黒がクイーンサイドにキャスリングできるなら、小文字の"q"が現れる。 これらの現れた文字はまず大文字が小文字の前に現れ、次にキングサイドがクイーンサイドの前に現れる。 それぞれの文字の間にはスペースは現れない。

16.2.7.アンパッサンの目的のマス

4番目のフィールドはアンパッサンの目的のマスである。もしアンパッサンの目的のマスが無ければ"-"1文字が現れる。 もしアンパッサンの目的のマスがあるなら、小文字のファイルの文字とランクの数字で表される。 明らかに、白ポーンが2マス進んだ後なら(黒の手番なら)、ランクの数字は"3"だろうし、 黒ポーンが2マス進んだ後なら(白の手番なら)、ランクの数字は"6"であるだろう。

アンパッサンの目的のマスが与えられるのは、最後の指し手がポーンを2マス動かしたときであり、かつそのときに限る。 したがって、直後にアンパッサンの捕獲を実行するかもしれない相手のポーンが無いにも関わらず、 アンパッサンの目的のマスのフィールドはマス名を持つかもしれない。

16.2.8.命令

EPDの命令はopcodeの後に0個以上の被演算子が続くことで構成され、セミコロンで終了される。

複数命令は1つのスペースで分割される。 もしEPDの行に少なくとも1つの命令が表されたなら、それは1つのスペースで最後の(4番目の)データフィールドから分割されるだろう。

16.2.9.一般形式

opcodeは綴り文字で始まり14文字までの文字からなる識別子である。 それぞれの追加の文字は綴り文字か数字かアンダースコアかもしれない。

被演算子は隣接した非スペース印刷文字か文字列の集合である。 文字列はそれぞれの終わりをクオート文字で区切られた連続した印刷文字の集合である。 文字列値は256バイトより短くなければならない。

もし命令に少なくとも1つの被演算子が与えられるなら、opcodeと最初の被演算子の間には1つのスペースがある。 もし命令の中に1つ以上の被演算子が与えられるなら、隣接した2つの被演算子の間には1つのブランク文字がある。 もし被演算子が1つも無ければセミコロンが命令の終わりの印をつけるためにopcodeに現れる。 もし被演算子が現れたら、最後の被演算子は命令の最後のマークをつけるセミコロンが追加される。

どんなopcodeもEPDレコード当り高々1回現れる。 1つのEPDレコード内の複数命令はopcode名のASCIIコード順で現れるべきだ。 けれども、EPDレコードを読むプログラムはopcodeのASCIIコード順でなくても良いかもしれない; 意味はどちらでも同じである。

1つ以上の被演算子を許すopcodeは被演算子の順番を決めるかもしれない。 例えば、opcode "pv" (predicted variation)は被演算子がプレイされる順番で現れることを要求する。 それ以外の複数被演算子を許すopcodeはASCII順で現れるべきだ。 後者の例としてはopcode "bm" (best move[s])である;その被演算子は現在のポジションからすぐに指すことの出来る指し手である。

いくつかのopcodeはチェスの指し手の被演算子を1つ以上要求する。これらの指し手はSANを用いて表現されるべきだ。 もし違う表現が用いられるなら、EPDが後の処理で正確に読まれるという保証は無い。

いくつかのopcodeは整数の被演算子を1つ以上要求する。 いくつかのopcodeは与えられた範囲の整数をもった整数の被演算子を持つだろう;その詳細は下に示されるopcodeのリストに記述される。 負の整数はハイフン(マイナス記号)と整数の列で形成される。 プラス記号が非負の整数を示すのに用いられるかもしれないが、そのような使用は要求されないし実際に使われない。

いくつかのopcodeは浮動小数点数の被演算子を1つ以上要求するかもしれない。 いくつかのopcodeは与えられた範囲をもった浮動小数点数の被演算子を持つだろう;その詳細は下に示されるopcodeのリストに記述される。 浮動小数点数の被演算子はオプションの符号文字("+","-")、(少なくとも1つの)十進数、小数点(".")、(少なくとも1つの)十進数の列から構成される。

16.2.10.opcodeの記憶術

アーカイブストレージとプログラム間のコミュニケーションに用いられるopcodeの記憶術は、 小文字の綴りで始まり、小文字の綴り、数字、アンダースコアのみで構成される(すなわち、大文字は出てこない)。 これらの記憶術は全て少なくとも2文字であるだろう。

1つのプログラムまたは実験的なプログラムでのみ用いられるopcode記憶術は大文字で始まるべきだ。 これは他のプログラムが偶然出会ったときに容易に区別できるようにするためである。 そんな"個人的な"opcodeが広範囲で便利であると示されたとき、それは小文字形式で(下にある)公式リストに追加されるべきだ。

もし与えられたプログラムが特別なopcodeを認識できないなら、その命令は単純に無視される;エラーが表示されない。

16.2.11.opcodeリスト

opcodeは記憶術のASCII順でここに並べられている。 新たなopcodeの提案はこの文章のはじめのあたりにあるPGN規格の調整役に送られるべきだ。

16.2.12.opcode "acn": analysis count: nodes

The opcode "acn"は1つの非負整数の非演算子を持つ。それは解析で調べられたノードの数を表すのに用いられる。 その値は広範囲の研究にはかなり大きいと思われるため、 (少なくとも)長表現(4バイト表現)の使用が提案されていることを記述しておく。

16.2.13.opcode "acs": analysis count: seconds

opcode "acs"は1つの非負整数の非演算子を持つ。それは解析に使われた秒数を表すのに用いられる。 その値は広範囲の研究にはかなり大きいと思われるため、 (少なくとも)長表現(4バイト表現)の使用が提案されていることを記述しておく。

16.2.14.opcode "am": avoid move(s)

opcode "am"は0個以上の指し手の集合を示し、それら全ては現在のポジションからすぐにプレイでき、 EPDを書いた人の意見により避けられた指し手である。 それぞれの被演算子はSANの指し手である;それらはASCII順で現れる。

16.2.15.opcode "bm": best move(s)

opcode "bm"は0個以上の指し手の集合を示し、それら全ては現在のポジションからすぐにプレイでき、 EPDを書いた人によって最適な手と判断された指し手である。 それぞれの被演算子はSANの指し手である;それらはASCII順で現れる。

16.2.16.opcode "c0": comment(その1、"c1"から"c9"まで)

opcode "c0"(小文字の"c"と数字の0)は与えられたポジションに適用するトップレベルのコメントを示す。 それは10に分類されたコメントの1つ目で、それぞれは記憶術の形式に従い、小文字の"c"と1つの10進数を持つ。 これらのopcodeは1つの文字列の被演算子を持つか全く被演算子を持たないかのどちらかである。

この10個のコメントのopcodeメンバーは終了したゲームや断片的なゲームの解説を記述するのに用いることを意図している。 これらのopcodeの一般的な処理は次のようになる:
  1. ゲーム(もしくはゲームの断片)の最初で、 指し手の列をスキャンするプログラムはコメント文字列を収めるレジスターの集合の各要素をNULLで初期化する。
  2. ゲームの各ポジションのEPDレコードとして処理され、コメント命令は左から右へ翻訳される。 (実際、n個のEPDレコードにある全ての命令は左から右へ翻訳される。) 命令はopcodeの記憶術に従いASCII順で現れるため、 opcode "c0"は(もしあれば)他の全てのopcodeに先だって操作され、(もしあれば)次にopcode "c1"が、 そしてその順で(もしあれば)opcode "c9"まで操作される。
  3. opcode "cN" (0 <= N <= 9)の処理は2つのステップを含む。 最初に、N以上のインデックスを持った全てのコメント文字列のレジスターはNULLにセットされる。 (これは"cN"から"c9"までの集合である。) 次に、被演算子が与えられるときに限り、関連したコメント文字列のレジスターの値に文字列の被演算子がセットされる。

16.2.17.opcode "ce": centipawn evaluation

opcode "ce"は示されたポジションの評価をポーンの価値を単位として示す。 (訳注:つまり、評価値が1ポイントの場合はポーン1個分有利、といった意味。) それは1つの被演算子を持ち、それは手番のプレイヤーの視点からのポジション評価を与える符号付き整数である。 正の値は手番を持ったプレイヤーに有利であることを示し、負の値は相手のプレイヤーに有利であることを示す。 ポーンの価値を単位とした評価値で0に近い値は対等なポジション評価であることを示す。 (訳注:現在ではこのような評価値のつけ方は一般的ではない。 現在は、正の評価値を持つ場合白が有利、負の評価値をもつ場合は黒が有利、というつけ方のほうが一般的である。)

値は-32767以上32766以下の整数に制限される。

32000より大きい値は手番のプレイヤーによって強制的にメイトすることが出来ることを示す。 メイトまでの手数は32767から評価値を引くことによって与えられる。 したがって、N手でのメイト勝ちは((2 * N) - 1)のハーフムーブでのメイトであり、 そのときのポーンの価値を単位とした評価値は(32767 - ((2 * N) - 1))である。 例えば、1手でメイト出来る場合は評価値は32766で、5手でメイト出来る場合は評価値は32758である。

32000より小さい値は相手のプレイヤーによって強制的にメイトされることを示す。 メイトまでの手数は-32767から評価値を引くことによって与えられる。 したがって、N手でのメイト負けは(2 * N)のハーフムーブでのメイトであり、 そのときのポーンの価値を単位とした評価値は(-32767 + (2 * N))である。 例えば、1手でメイトされる場合は評価値は-32765で、5手でメイトされる場合は評価値は-32757である。

-32767という値は不正なポジションを示す。 ステールメイトのポジションは、メイティングマテリアルが不足していることによるドローのポジションとして、 評価値に0を持つ。 強制的にドローに出来ることが知られているその他のポジションも、評価値に0を持つ。

16.2.18.opcode "dm": direct mate fullmove count

opcode "dm"は示されたポジションで手番のプレイヤーによってチェックメイトがもたらされるまでの手数を示すのに用いられる。 それは常に1つの被演算子を持ち、それは手数を与える正の整数である。 例えば、"3手でメイト"であると分かっているポジションはこれを示すのに、命令"dm 3;"を持つだろう。

このopcodeは、解として直接メイトする答えを要求するポジションで構成される、プロブレムの集合で用いることを意図している。

16.2.19.opcode "drawn_accept": accept a draw offer

opcode "draw_accept"は、手が指された後でドローの提案がなされ、 次の手番のプレイヤーによって受理されるポジションを示すのに用いられる。 このopcodeは被演算子を持たない。

16.2.20.opcode "draw_claim": claim a draw

opcode "draw_claim"は、ドローが存在する手番のプレイヤーによる要求を示すのに用いられる。 三複同形か、50手ルールか、メイティングマテリアルが不足していることにより、ドローは要求される。 supplied move("sm"参照)もまた同じEPDレコードの一部として現れることを要求される。 draw_claim opcodeは被演算子を持たない。

16.2.21.opcode "draw_offer": offer a draw

opcode "draw_offer"は手番のプレイヤーによってドローが提案されたことを示すのに用いられる。 supplied move("sm"参照)もまた同じEPDレコードの一部として現れることを要求される; この指し手は示されたポジションからプレイされたとみなされる。 draw_offer opcodeは被演算子を持たない。

16.2.22.opcode "draw_reject": reject a draw offer

opcode "draw_reject"は、手が指された後でドローの提案がなされ、 次の手番のプレイヤーによって拒否されるポジションを示すのに用いられる。 このopcodeは被演算子を持たない。

16.2.23.opcode "eco": _Encyclopedia of Chess Openings_ opening code

opcode "eco"は示されたポジションと「Encyclopedia of Chess Openings」の分類から得たオープニング名称を結びつけるのに用いられる。 opcodeは1つの文字列の被演算子(ECOのオープニング名)を持つか被演算子を持たない。 もし被演算子が与えられるなら、その値はスキャンするプログラムの"ECO"文字列レジスタと関連付けられる。 もし被演算子が与えられなければ、スキャンするプログラムの"ECO"文字列レジスタはNULLにセットされる。

その使用はPGN規格の"ECO"タグと似ている。

16.2.24.opcode "fmvn": fullmove number

opcode "fmvn"はポジションと関連付けられた手数を表す。 それは常に1つの被演算子を持ち、それは手数を表す正の整数である。

このopcodeは、FENの6番目のフィールドに標準で表されているものを、EPDにおいて手数を明示的に表すのに用いられる。 手数の情報は、(EPDを用いるタスクで一般的に必要とされる)指し手の生成に影響しないため、通常省略されるが、 それは(FENを用いるタスクで一般的に必要とされる)ゲームの表記には影響する。 巨大なEPDファイルの空間最適化の要望のために、手数はEPDの親のFENに落とされた。 ハーフムーブクロックの情報も似たようにして落とされた。

16.2.25.opcode "hmvc": halfmove clock

opcode "hmvc"はポジションに関連付けられたハーフムーブクロックを表す。 ポジションのハーフムーブクロックは、ポーンが最後に動いたか駒が捕獲されてからのハーフムーブの数に等しい。 この情報は50手ルールの実装に用いられる。 それは常に1つの被演算子をもち、それは非負のハーフムーブクロックの値である。

このopcodeは、FENの5番目のフィールドに標準で表されているものを、EPDにおいてハーフムーブクロックを明示的に表すのに用いられる。 ハーフムーブクロックの情報は、(EPDを用いるタスクで一般的に必要とされる)指し手の生成に影響しないため、通常省略されるが、 それは(FENを用いるタスクで一般的に必要とされる)ゲームの終了問題には影響する。 巨大なEPDファイルの空間最適化の要望のために、ハーフムーブクロックはEPDの親のFENに落とされた。 手数の情報も似たようにして落とされた。

16.2.26.opcode "id": position identification

opcode "id"は示されたポジションに単純な識別ラベルを提供するのに用いられる。 それは1つの文字列被演算子を持つ。

このopcodeはチェスを指すプログラムの強さを測るために用いられるテスト列と共に用いることを意図している。 Reinfeldの「1001 Winning Chess Sacrifices and Combinations」の中にある1001問のうち、 757番目のポジションのための"id"の被演算子の例は"WCSAC.0757"で、 Bratko-Kopecのテスト24問のうち15番目のポジションは"id"の被演算子に"BK.15"をもつ。

16.2.27.opcode "nic": _New In Chess_ opening code

opcode "nic"は示されたポジションと「New In Chess」の分類から得たオープニング名称を結びつけるのに用いられる。 opcodeは1つの文字列の被演算子(NICのオープニング名)を持つか被演算子を持たない。 もし被演算子が与えられるなら、その値はスキャンするプログラムの"NIC"文字列レジスタと関連付けられる。 もし被演算子が与えられなければ、スキャンするプログラムの"NIC"文字列レジスタはNULLにセットされる。

その使用はPGN規格の"NIC"タグと似ている。

16.2.28.opcode "nop": no operation

opcode "noop"は命令が無いことを示すのに用いられる。 それは0個以上の被演算子を持ち、それぞれはどんなタイプでも良い。 その命令は処理を必要としない。 それは開発者によって、プログラムをテストする目的で使用されることを意図している。

16.2.29.opcode "pm": predicted move

opcode "pm"は示されたポジションのための1つの予言された指し手を提供するのに用いられる。 それは正確に1つの被演算子を持ち、それはそのポジションからプレイできる指し手である。 この指し手は、EPDを書く人によって、手番のプレイヤーが指せる最も良い指し手であると判断される。

もし、空でない"pv" (predicted variation)の行も同じEPDレコードに与えられていれば、 予言されたバリエーションの最初の指し手は予言された指し手と同じである。 opcode "pm"は一般的な"ヒントを示す"機構に用いることを意図している。

16.2.30.opcode "pv": predicted variation

opcode "pv"は示されたポジションのための1つの予言されたバリエーションを提供するのに用いられる。 それは0個以上の被演算子を持ち、それはそのポジションからプレイできる指し手の列である。 この列は、EPDを書く人によって、最も良い手を表すと判断される。

もし"pm" (predicted move)命令もEPDレコードの中にあれば、予言された指し手は予言されたバリエーションの最初の手と同じである。

16.2.31.opcode "rc": repetition count

opcode "rc"は示されたポジションの生じた数を示すのに用いられる。 それは1つの正の整数の被演算子である。 任意のポジションは、最初のポジションも含めて、少なくとも1つの"rc"の値を持つと考えられる。 値が3であるということは、三複同形ルールによりドローを請求出来ることを示す。

16.2.32.opcode "resign": game resignation

opcode "resign"は手番のプレイヤーがそのゲームを投了したことを示すのに用いられる。 このopcodeは被演算子を持たない。

16.2.33.opcode "sm": supplied move

opcode "sm"は示されたポジションのために与えられた1つの指し手を提供するのに用いられる。 それは正確に1つの被演算子を持ち、そのポジションからプレイできる指し手である。 この指し手はこのポジションからプレイされる指し手である。

opcode "sm"はプレイされているゲームでの最も後に指された指し手を伝えるのに用いられる。 それはネットワーク経由で自動的にプレイされるプログラムの間で指し手を伝えるのに用いられる。 これは電子メールを用いた通信チェスや人間のプレイヤーのネットワークフロントエンドとして振舞うプログラムも含む。

16.2.34.opcode "tcgs": telecommunication: game selector

opcode "tcgs"は電子メールや同じような手段で行なわれるゲームで用いられるopcodeの通信族の1つである。 このopcodeは1つの被演算子を持ち、正の整数を持つ。 それは、同じ送信者と受信者の間で、様々な進行中のゲームの間で選択するのに用いられる。

16.2.35.opcode "tcri": telecommunication: receiver identification

opcode "tcri"は電子メールや同じような手段で行なわれるゲームで用いられるopcodeの通信族の1つである。 このopcodeは順番に依存する文字列の被演算子を2つ持つ。 最初の被演算子はEPDレコードを受け取る人の電子メールアドレスである。 2つ目の被演算子はアドレスを持つプレイヤー(プログラムもしくは人間)の名前であり、EPDレコードを実際に受け取る人である。

16.2.36.opcode "tcsi": telecommunication: sender identification

opcode "tcsi"は"は電子メールや同じような手段で行なわれるゲームで用いられるopcodeの通信族の1つである。 このopcodeは順番に依存する文字列の被演算子を2つ持つ。 最初の被演算子はEPDレコードを送信する人の電子メールアドレスである。 2つ目の被演算子はアドレスを持つプレイヤー(プログラムもしくは人間)の名前であり、EPDレコードを実際に送信する人である。

16.2.37.opcode "v0": variation number(その1、"v1"から"v9"まで)

opcode "v0" (小文字の"v"と数字の0)は与えられたポジションに適用するトップレベルのバリエーション名を示す。 それは10に分類されたバリエーション名の1つ目で、それぞれは記憶術の形式に従い、小文字の"v"と1つの10進数で形成される。 これらのopcodeは1つの文字列の被演算子を持つか全く被演算子を持たないかのどちらかである。

この10個のバリエーション名のopcodeメンバーは終了したゲームや断片的なゲームの伝統的なバリエーション名として用いることを意図している。 これらのopcodeの一般的な処理は次のようになる:
  1. ゲーム(もしくはゲームの断片)の最初で、 指し手の列をスキャンするプログラムはバリエーション名の文字列を収めるレジスターの集合の各要素をNULLで初期化する。
  2. ゲームの各ポジションのEPDレコードとして処理され、バリエーション名の命令は左から右へ翻訳される。 (実際、n個のEPDレコードにある全ての命令は左から右へ翻訳される。) 命令はopcodeの記憶術に従いASCII順で現れるため、 opcode "v0"は(もしあれば)他の全てのopcodeに先だって操作され、(もしあれば)次にopcode "v1"が、 そしてその順で(もしあれば)opcode "v9"まで操作される。
  3. opcode "vN" (0 <= N <= 9)の処理は2つのステップを含む。 最初に、N以上のインデックスを持った全てのバリエーション名の文字列のレジスターはNULLにセットされる。 (これは"vN"から"v9"までの集合である。) 次に、被演算子が与えられるときに限り、関連したバリエーション名の文字列のレジスターの値に文字列の被演算子がセットされる。

17.チェス駒を識別する任意の文字

英語の駒名はPGNの指し手において駒を見分けるための文字として用いられる。 けれども、ローカルの表現や指し手のデータをスキャンすることのみに利用されるプログラムの著者は、 彼らの地域で一般的な駒のコードを用いる方が便利であると思うかもしれない。 これは、アーカイブの保存場所に属するか、 SAN(イギリス)の駒文字コード"PNBRQK"を用いるプログラム間で変換されたPGNデータである限り問題ではない。

上記の著者には、任意の駒文字コードのリストが提供されている:
Language     Piece letters (pawn knight bishop rook queen king)
----------   --------------------------------------------------
Czech        P J S V D K
Danish       B S L T D K
Dutch        O P L T D K
English      P N B R Q K
Estonian     P R O V L K
Finnish      P R L T D K
French       P C F T D R
German       B S L T D K
Hungarian    G H F B V K
Icelandic    P R B H D K
Italian      P C A T D R
Norwegian    B S L T D K
Polish       P S G W H K
Portuguese   P C B T D R
Romanian     P C N T D R
Spanish      P C A T D R
Swedish      B S L T D K
			

18.正式なシンタックス


<PGN-database> ::= <PGN-game> <PGN-database>
                   <empty>
<PGN-game> ::= <tag-section> <movetext-section>
<tag-section> ::= <tag-pair> <tag-section>
                  <empty>
<tag-pair> ::= [ <tag-name> <tag-value> ]
<tag-name> ::= <identifier>
<tag-value> ::= <string>
<movetext-section> ::= <element-sequence> <game-termination>
<element-sequence> ::= <element> <element-sequence>
                       <recursive-variation> <element-sequence>
                       <empty>
<element> ::= <move-number-indication>
              <SAN-move>
              <numeric-annotation-glyph>
<recursive-variation> ::= ( <element-sequence> )
<game-termination> ::= 1-0
                       0-1
                       1/2-1/2
                       *
<empty> ::=

19.正統なポジションのハッシュコード

***策定中

20.バイナリ表現(PGC)

20.1.バイト

20.2.指し手を表す数

20.3.文字データ

20.4.マーカーコード

20.4.1.マーカー 0x01:小さくされたエクスポートフォーマットのゲーム1つ

20.4.2.マーカー 0x02:タグ

20.4.3.マーカー 0x03:ショートムーブシーケンス

20.4.4.マーカー 0x04:ロングムーブシーケンス

20.4.5.マーカー 0x05:一般的なゲームデータ開始

20.4.6.マーカー 0x06:一般的なゲームデータ終了

20.4.7.マーカー 0x07:単純なNAG

20.4.8.マーカー 0x08:RAV開始

20.4.9.マーカー 0x09:RAV終了

20.4.10.マーカー 0x0a:エスケープ文字

21.E-mailチェスにおける使用方法

***策定中

バナー