关于steam相关功能的实现

[lsxuan12138]

可以参考这个仓库 https://github.com/kdada/Authenticator 作者已经实现了直接在软件内登录steam（不需要mafile文件），扫码登录Windows的steam客户端，交易确认这些功能。

[lsxuan12138]

当然在这个仓库的实现中使用mafile也是可以的。
另外，仓库实现中的steam数据有一个字段命名错误，如果要参考这个仓库可以稍微注意一下。

[lsxuan12138]

今天突然有时间，测试了一下导入这个软件已经实现的导入mafile文件的功能，发现由steamguard-cli导出的mafile文件中的steam_id因为数值太大会超出ArkTS的数字范围（可能是这个原因，但是反正有概率会出错），使其JSON导入时数值有概率出错。怪不得 https://github.com/kdada/Authenticator 里面实现的时候会转成string😂

[SolidFaker]

今天突然有时间，测试了一下导入这个软件已经实现的导入mafile文件的功能，发现由steamguard-cli导出的mafile文件中的steam_id因为数值太大会超出ArkTS的数字范围（可能是这个原因，但是反正有概率会出错），使其JSON导入时数值有概率出错。怪不得 https://github.com/kdada/Authenticator 里面实现的时候会转成string😂

试了一下似乎没问题？现在还没有用到steam_id这个字段

[lsxuan12138]

今天突然有时间，测试了一下导入这个软件已经实现的导入mafile文件的功能，发现由steamguard-cli导出的mafile文件中的steam_id因为数值太大会超出ArkTS的数字范围（可能是这个原因，但是反正有概率会出错），使其JSON导入时数值有概率出错。怪不得 https://github.com/kdada/Authenticator 里面实现的时候会转成string😂

试了一下似乎没问题？现在还没有用到steam_id这个字段

steam_id这个确实目前还没用到，所以这里只是提醒一下。至于测试没问题，这个问题应该和具体数值有关，感觉应该就是数值太大了，arkts的number的精度不够了，可以在单元测试里试一下以下代码，这里的id是我随机生成的一个和我自己id一样长的id：
let content = '{"steam_id": 74833278383343738}';
let obj = JSON.parse(content) as Record<string,object>;
let value = obj['steam_id']
expect(value).assertEqual(74833278383343740)

理论上说这个测试用例应该是过不了的，但是实际运行却没有报错。

[lsxuan12138]

今天突然有时间，测试了一下导入这个软件已经实现的导入mafile文件的功能，发现由steamguard-cli导出的mafile文件中的steam_id因为数值太大会超出ArkTS的数字范围（可能是这个原因，但是反正有概率会出错），使其JSON导入时数值有概率出错。怪不得 https://github.com/kdada/Authenticator 里面实现的时候会转成string😂

提到这个其实是我自己用mafile导入的时候发现，导入和导出备份的steam_id的值不一样😂

[lsxuan12138]

搜了下相关的问题，确实是数值太大超范围了，所以表示就不精确了，后面如果使用steam_id这个字段的话，可以考虑将其设置为bigint然后在反序列化时设置bigIntMode参考 https://developer.huawei.com/consumer/cn/doc/harmonyos-references/js-apis-json#parseoptions ，或者可以像 https://github.com/kdada/Authenticator 中使用string

[SolidFaker]

搜了下相关的问题，确实是数值太大超范围了，所以表示就不精确了，后面如果使用steam_id这个字段的话，可以考虑将其设置为bigint然后在反序列化时设置bigIntMode参考 https://developer.huawei.com/consumer/cn/doc/harmonyos-references/js-apis-json#parseoptions ，或者可以像 https://github.com/kdada/Authenticator 中使用string

got it, thx