YGO决斗助手协议（YGO-DA协议）

该文章的pdf版本链接：点击下载pdf

YGO决斗助手协议（以下简称DA协议）旨在帮助用户更便捷的进行ygo相关操作，包括但不限于卡组、加房等操作。

协议版本：1.0

创建日期：2021年9月30日

最后修改日期：2021年9月30日

协议主要分为以下两个部分：

1. 卡组协议
2. 加房协议

DA协议对文本的检测顺序也应按照上述顺序进行

1.卡组协议

卡组协议用以将卡组文件与卡组文本相互转换，使卡组更容易在社交软件中传播。
卡组协议识别的文本有两种：卡组代码文本、卡组URL文本。
进行判断时应先判断文本为多行文本还是单行文本，若为多行文本，将其作为卡组代码文本判断；若为单行文本，将其作为卡组URL文本判断。

① 卡组代码文本

卡组文件的实质为文本文件，里面的文本内容即为卡组代码文本。
卡组代码文本由三部分组成：主卡组、额外卡组、副卡组。
卡组代码文本的语法格式为（带方括号[]的为可选项）：

[#main
卡密1
……
卡密n]
[#extra
卡密1
……
卡密n]
[!side
卡密1
……
卡密n]

示例：

#main
63941210
#extra
87116928
87116928
!side
63941210

"#main"、"#extra"、"!side"为 卡组代码标识 ，分别声明主卡组、额外卡组、副卡组。
卡片以卡密表示，一行一个卡密，一个卡密表示一张卡。

卡组代码文本转换卡组文件：

判断方法： 判断文本中是否含有任意卡组代码标识，只要含有其中一个卡组代码标识，即视为该文本包含卡组代码文本。
处理： 从第一个卡组代码标识开始，取文本到原文本末尾，将取出来的文本以文本文件的方式保存为.ydk结尾的文件。

卡组文件转换卡组代码文本：

处理： 将本地卡组文件以文本文件方式读取，将其文本内容直接分享。

② 卡组URI文本

卡组URI主要以参数是否含有"decktype=deck"来判断是否为卡组URI，协议和主机没有限制，即各开发者可以将协议和主机改为自己的服务器，用户可以直接点击卡组URI打开到自己网站展示或是跳转到应用。

卡组URI由三部分组成： 协议、主机、参数

语法格式：

协议://主机&参数1?参数2?参数n

协议列表：

主机列表：

参数列表：

在协议版本1中，卡组参数值为Base64Url，转换规则如下：

单种类卡： 由29位二进制位组成，前两位为数量位，后27位为卡密位。格式如下(小括号为格式类别区分，实际值不需要写)：

(卡片数量位*2)(卡片数量位*27)

主/额外/副卡组： 由多个单种类卡文本直接拼接而成,最后将主卡组、额外、副卡组所有卡片文本依次直接拼接，作为卡组信息文本。格式如下：

(单种类卡1)(单种类卡2)(单种类卡n)

最终卡组文本参数： 由16位二进制卡组数量位和卡组信息文本拼接后二进制数进行Base64Url转换得到的文本。卡组数量位中其中前8位为主卡组卡片种类数量位，9-12位为4位卡片种类额外卡组位，13-16位为4位副卡组卡片种类数量位。二进制数格式如下：

(8位主卡组卡片种类数量位)(4位额外卡组卡片种类数量位)(4位副卡组卡片种类数量位)(卡组信息文本)

Base64Url: 为Base64表中将"/"和"+"替换为"-"和"_"的表

卡组URI示例：
http://deck.ourygo.top?ygotype=deck&v=1&d=FNhefVLXC2RMpY_w-43iOvy2SnXARcGDa4Gf-WWVKlHxmGQN9gbi5Y-FDdvkNIpufUXGkPmlV3n70HzV3OV58le_LRnThgSJlIImmKZAMuPJSqBUEax8yF1rIQy7GidRET65azdhGIVy2w4rI9b5cwTxrZ5JsWGN-uRnxrXZ0jdujdvkOJ9zVDCtMtezkT-6CuKtQso-yA

卡组URL转换为卡组文件：

判断方法： 判断文本中是否含有"ygotype=deck"这个参数，如果含有，则从该参数开始往文本前面查找，依次查找是否含有"ygo://deck"、"http"、"https",如果有其中任意一个，则停止判断，视为该文本中含有卡组URI，其他情况视为文本中不包含卡组URI。

处理： 从查找到的协议文本开始，取文本到原文本末尾，将取出的文本作为卡组URI；判断URI中参数"v"的值（即协议版本），如果为1执行以下步骤：

• 取出参数d中的值，该值为Base64Url文本，将该文本转换为二进制文本
• 分别取出该二进制的前8位、9~12位、13~16位，分别作为主卡组、额外卡组、副卡组的卡片种类数量
• 从17位开始，依次往后取出各卡组卡片种类数量*29位的文本，作为各卡组的卡片
• 每个卡组文本中，以每29位为一组取出作为单种类卡片信息，其中前两位为该种类卡片数量，后27位为卡密，将卡密转化为10进制，根据卡片数量，每行一个卡密进行拼接。
• 将拼接文本以以文本文件的方式保存为.ydk结尾的文件。
  
  

卡组文件转换为卡组URI：

处理：

• 将卡组文件以文本的方式按行读出，分别判断三个卡组代码标识的位置。
• 将卡组代码标识之后到下一个卡组标识之前（或者文本末尾）的每行文本进行卡密判断-如果该行文本为数字则视为卡密，否则舍弃该文本；
• 将每种类卡组里面的卡密文本进行排序，相同的排在一起。
• 将每种类的卡组里面的每种类卡密转换为27位二进制卡密，不够补0，然后判断该种类卡密在其后相同的加上本身共有几个，把该种类卡密的数量转换为2位二进制，作为第一二位拼接在27位二进制卡密头部，最终形成29位单种类卡片信息。
• 将主卡组的卡片种类数量转换为8位二进制，额外卡组4位二进制，副卡组4位二进制，共16位二进制依次拼接，作为各卡组卡片种类数量。
• 将该种类卡组里所有转换后的位卡片信息前后以此拼接起来，再将16位卡组卡片种类数量位拼接在参数的头部，作为最终卡组的参数值（参数为d）。
• 协议和主机使用上面列表的任何一个（协议为ygo的话主机只能是deck），加入"decktype=deck"和"v=1"参数，即URI类型为卡组，协议版本为1，再拼接上卡组参数（如果参数没有值则不加入该参数），最终得到卡组URI。
  
  

③ 客户端支持：

客户端应支持ygo://deck协议，以确保可以点击卡组URL直接使用客户端打开。

2.加房协议

卡组协议用以记录决斗房间信息，使用户可以更方便的进行约战。
加房协议识别的文本有两种：加房URI、加房密码。
判断时应优先判断加房URI，如果没有再去判断加房密码。

① 加房URI

加房URI主要以参数是否含有"decktype=room"来判断是否为加房URI，协议和主机没有限制，即各开发者可以将协议和主机改为自己的服务器，用户可以直接点击加房URI跳转客户端提示用户进行决斗。

加房URI由三部分组成： 协议、主机、参数

语法格式：

协议://主机&参数1?参数2?参数n

协议列表：

主机列表：

参数列表：

判断方法： 判断文本中是否含有"ygotype=room"这个参数，如果含有，则从该参数开始往文本前面查找，依次查找是否含有"ygo:// room"、"http"、"https",如果有其中任意一个，则停止判断，视为该文本中含有加房URI，其他情况视为文本中不包含加房URI。

处理： 从查找到的协议文本开始，取文本到原文本末尾，将取出的文本作为加房URI；判断URI中参数"v"的值（即协议版本），如果为1执行以下步骤：

1. 分别取出房间ip、房间端口、房间密码三个参数，进行url解码，将解码后的值作为房间信息，加入该房间。

② 加房密码

加房密码即为日常约战使用的密码，如"M#废话"，"T#废话"等。通过查找是否含有加房密码标识来判断是否含有加房密码。

加房密码标识列表（|为或者的意思，分割同类多个标识，自己本身不作为标识）：

判断方法： 判断文本中是否含有任意加房密码标识，只要含有其中一个加房密码标识，即视为该文本包含加房密码。

处理： 从第一个加房密码标识开始，取文本到原文本末尾，将取出来的文本作为房间密码，ip和端口使用客户端默认的信息，加入该房间。

③客户端支持：

客户端应支持ygo://room协议，以确保可以点击加房URL直接使用客户端打开。