请教关于接口的使用

1021263881 commented 5 years ago

/live/LiveService.java里面有以下这一条 /**

获取直播间信息
登录后访问该 API 将在服务器新增一条直播间观看历史
2018-05-11 现在用假的房间 ID 也能获得正确的信息
@param roomId 房间号 */ @GET("AppRoom/index") Call getRoomInfo(@Query("room_id") long roomId);

请问下这个的url是多少？最近在写一个B站的脚本，用不了你的类，只能自己写

1021263881 commented 5 years ago

http://api.live.bilibili.com/AppRoom/index?roomid=xxxxxxxx的get请求返回{"code":-404,"message":"Document is not exists."}

czp3009 commented 5 years ago

实际使用的参数名是 @Query 注解里的值

示例

https://api.live.bilibili.com/AppRoom/index?room_id=3&platform=android

房间必须存在

platform 参数在这个 API 是必须的。在这个 API 中，ios 平台返回的数据结构有差异(并非所有API都必须有 platform 参数，但是 platform 属于固定参数之一，在真实的客户端中所有请求都会带上固定参数)

1021263881 notifications@github.com 于 2018年12月4日周二下午6:44写道：

http://api.live.bilibili.com/AppRoom/index?roomid=xxxxxxxx的get请求返回{"code":-404,"message":"Document is not exists."}

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/czp3009/bilibili-api/issues/19#issuecomment-444055756, or mute the thread https://github.com/notifications/unsubscribe-auth/AQcnrs6p51SIvxVYX5Zgic8sJ3uqlQU2ks5u1lICgaJpZM4ZAXji .

1021263881 commented 5 years ago

谢谢啦，请问有没有已知API的整合文档呢

czp3009 commented 5 years ago

不止没有，我甚至想咕咕咕

1021263881 notifications@github.com 于 2018年12月4日周二下午9:56写道：

谢谢啦，请问有没有已知API的整合文档呢

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/czp3009/bilibili-api/issues/19#issuecomment-444107733, or mute the thread https://github.com/notifications/unsubscribe-auth/AQcnrhkmEJcCsk4JXs4eo7OGtYj7E2b3ks5u1n8CgaJpZM4ZAXji .

1021263881 commented 5 years ago

请问下{cmd:LIVE,roomid:xxxxx}是进房间的数据包么

czp3009 commented 5 years ago

与弹幕推送服务器的 socket 通信内容(比特数组)详见 https://github.com/czp3009/bilibili-api/blob/master/src/main/java/com/hiczp/bilibili/api/live/socket/Package.java

需要客户端来发送的数据包只有两种, 进房数据包和心跳包, 详见 https://github.com/czp3009/bilibili-api/blob/master/src/main/java/com/hiczp/bilibili/api/live/socket/PackageHelper.java

服务端发来的数据包也是一个复杂的比特数组, 经过解析可以得到一个 Json, 里面持有一些信息.

所有带有 cmd 字段的 json 都是服务端发来的, cmd 用于标记数据包类型.

例如上文给出的 LIVE 为开播提醒数据包, 由服务端主动发送.

所有已知的 cmd 详见 https://github.com/czp3009/bilibili-api/blob/master/src/main/java/com/hiczp/bilibili/api/live/socket/handler/LiveClientHandler.java

(B站经常会增加 cmd 类型)

进房数据包差不多是这样的一个东西

00 00 00 28 00 10 00 00 00 00 00 07 00 00 00 00

{"roomid":3,"uid":123456}

(注意, 第二行是 byte 数组, 因为不易表示所以写为人类可读模式)

本来是要写一篇关于数据包的博文的, 但是一直没空写.

这是一个江大学长的博文 http://www.lyyyuna.com/2016/03/14/bilibili-danmu01/

里面的一些关于平台类型的 byte 的值是错误的, 但是不影响浏览.

数据头上的一些 magic number 可以看 https://github.com/czp3009/bilibili-api/blob/master/src/main/java/com/hiczp/bilibili/api/live/socket/Package.java 里面的 enum 的值.

1021263881 commented 5 years ago

我不知道为啥sso得不到cookie(一脸怂样 httpurlconnection返回的header里面就是没cookie

czp3009 commented 5 years ago

那个 sso，好像已经更新好几个版本了，新的 API 我还没研究，大概是不可用了。

实际上几乎所有 API 都有客户端版本，没有必要使用 cookie 去访问 Web 版 API。

1021263881 notifications@github.com 于 2018年12月7日周五下午9:18写道：

我不知道为啥sso得不到cookie(一脸怂样 httpurlconnection返回的header里面就是没cookie

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/czp3009/bilibili-api/issues/19#issuecomment-445230080, or mute the thread https://github.com/notifications/unsubscribe-auth/AQcnrjSF3BKZ-2Uepgf0Ubv7icTfdXNeks5u2mqSgaJpZM4ZAXji .

1021263881 commented 5 years ago

tcp连接到弹幕服务器的时候，有几率收到一些不正常的数据，比如长度只有2的回包，是怎么回事呢

1021263881 commented 5 years ago

还有的包头4个字节明明应该是数据包长度，结果是“e6adbbe4”这种东西

czp3009 commented 5 years ago

这是 tcp 黏包.

OSI 七层模型(部分国内书刊使用的是五层模型一词)中, 应用层是得不到底层 tcp 数据包的长度的(所以要在 tcp 正文里面定义正文总长度). 应用程序只能得到一个操作系统给予的 InputStream, 而底层传输层存在大包拆分问题. 即服务端发送一个大包时, 传输层可能会分两个实际上的帧来发送数据包. 于是客户端使用 socket.read 时, 收到一个长度明显过小的包(只有数据包正文, 没有包头).(也有可能是 tcp 发送窗口里的重发导致数据包顺序错位等, 操作系统会保证应用层一定接收到正确顺序的内容)

这个问题的解决方案就是先循环读取四个字节, 得到数据包正文总长度, 然后再循环读取那么多的内容进行手动包拼接.

具体原理详见 Google 搜索 tcp粘包.

大部分语言的异步 IO 框架都提供了现成的方案来实现包的组装, 例如在 Java Netty 中, 提供了预制的 Decoder.

new LengthFieldBasedFrameDecoder(
                                            Integer.MAX_VALUE,
                                            0,
                                            Package.LENGTH_FIELD_LENGTH,
                                            -Package.LENGTH_FIELD_LENGTH,
                                            0
                                    )

这个解码器可以直接组装整个包, 避免接下去的解析流程遇到粘包和拆包问题

1021263881 commented 5 years ago

会不会出现一个大包被拆成许多小包然后里面有的小包丢失了

1021263881 commented 5 years ago

打算手动拆包(小声

czp3009 commented 5 years ago

大包被拆成小包是经常发生的, 此时就会收到长度过小的数据包.

数据包丢失是不存在的, 操作系统实现的 tcp 发送窗口会在目标对某个数据包无响应时重新发送. 也就是说, 操作系统会始终保证对方收到了全部的数据包. 对于重复数据包, 接收方会根据 tcp 数据帧中的序号保持应用层收到的数据的顺序一定是正确的. 所以应用层不需要考虑数据完整性问题, 数据一定是完整的.

有关 tcp 原理的描述你可以随便买本书花五分钟精通一下.

1021263881 commented 5 years ago

加密房间里面的宝箱抽奖会是钓鱼么

czp3009 commented 5 years ago

钓鱼问题我没有研究过，你可以去隔壁QQ群问问 55308141

1021263881 notifications@github.com 于 2018年12月25日周二下午5:50写道：

加密房间里面的宝箱抽奖会是钓鱼么

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/czp3009/bilibili-api/issues/19#issuecomment-449833500, or mute the thread https://github.com/notifications/unsubscribe-auth/AQcnrkSDbwqPNDp3pzQDyLgyeiJ-RhtXks5u8fTxgaJpZM4ZAXji .

czp3009 / bilibili-api

请教关于接口的使用 #19