Agreed -- looking at the player data[1], IMO the format type is unrecognizable:
## GK / Goalkeepers
Kawashima|Eiji Kawashima, 20 Mar 1983
Nishikawa|Shusaku Nishikawa, 18 Jun 1986
Gonda|Shūichi Gonda, 3 Mar 1989
## DF / Defenders
Inoha|Masahiko Inoha, 28 Aug 1985
G. Sakai|Gōtoku Sakai, 14 Mar 1991
Nagatomo|Yuto Nagatomo, 12 Sep 1986
Uchida|Atsuto Uchida, 27 Mar 1988
Konno|Yasuyuki Konno, 25 Jan 1983
Kurihara|Yuzo Kurihara, 18 Sep 1983
H. Sakai|Hiroki Sakai, 12 Apr 1990
Yoshida|Maya Yoshida, 24 Aug 1988
Masato Morishige, 21 May 1987 ## Japan F.C. Tokyo
Comments as a double-hash, key fields are either player last name or occasionally first initial-space-last name, then three different delimiters of pipe, then comma, then tab. Choosing either a consistently delimited format or a more verbose JSON/YAML structure with clear metadata would seem to be a better approach.
The size of JSON files is huge compared to delimited data. Languages like Python make it equally easy to consume delimited data and JSON, so it shouldn't matter much.
At work I built a system to consume feeds of numerous automotive dealer inventories and the easiest to work with is always comma delimited. There are some people out there who have no business building an XML document, and unfortunately I've had to build adapters for many of them. It takes me a few hours to get set up to consume a new CSV feed and a few days for XML, not counting mapping their industry / category / manufacturer data to ours.
[1] https://github.com/openfootball/players/blob/master/asia/jp-...