密钥。
你们念对了吗哈哈哈

还有你知道什么叫阿贾克斯吗哈哈哈

所以 TCP 粘包到底是啥

隐藏自己的劣势，因为内存普遍比安卓小。

macbook 的配置普遍比 PC 高，所以谈配置从来明明白白

请教一下，你这个前端反爬是怎么工作的？
爬虫直接访问的后端接口，不访问你前端页面，而后端并没有鼠标轨迹，停留时间等这些信息

@Chingim 上条打错了..在假想的算法里, 11000000 10000000 表示的码点不是 U+0000 而是 U+0080

@wsxyeah
@BlackL 不会重复的, 有一个计算偏移的操作. 在假想的算法里, 10000000 10000000 表示的码点不是 U+0000 而是 U+0080

@Chingim

0x014E25 少写了一个字节, 应该是 11110000 10000100 10010110 10100101

@BXIA 这么说还是有安全的考虑在里面的...
@msg7086 嗯, 编解码速度可能也是造成它这么设计的原因, 位移确实比加减省事

@DGideas
@GeruzoniAnsasu 抱歉说得不清楚, 我 append 了. 我了解中间字节必须是 10xxxxxx 格式的必要性, 所以我指的不是"占用这两个比特"


@keakon 1100000x 为什么不能出现在 UTF-8 的字节中呢? 11000001 10000000 这样的两个字节应该不会引起歧义吧?


@imn1 如果按照 append 里提到的编码方法:
- 0x4E，0x25 落在单字节区间, 一个字节就表示了, 二进制分别是: 01001110 以及 00100101
- 0x4E25 落在了三字节区间, 在三字节序列里的偏移是 0x45A5, 填入三字节的格式, 最终的二进制: 11100100 10010110 10100101
- 0x014E25 落在了四字节区间, 在四字节序列里的偏移也是 0x45A5, 填入四字节的格式中, 得到: 11110100 10010110 10100101
- 解码器读到这些字节, 应该也可以还原回去

放心吧，按照这个老龄化的趋势，我觉得我可以写一辈子代码。

写了这么多年如果没有年轻人写得好，那我认栽，祖师爷不赏饭吃也没办法，被裁那是应该的。

我每隔一段时间就一个人去电影院，看电影流眼泪，发泄一下情感

@xiao17174

1. 讨论问题请不要倚老卖老，还有谢谢你夸我嫩。
2. 我的意思是你想把数据当成纯文本传输，让另一端想怎么解析就怎么解析(你所谓的更通用)，这完全可以，把 content-type 设置成 plain/text 就 ok 了。而不需要再包一层两层，把 {"dds":2} 变成 "{\"dds\":2}" ，因为前者已经是纯文本了。

@xiao17174 http 报文主体的内容是字节，没什么对象 /文本 /图像的概念。至于这些字节什么含义怎么解析，通过报文头部字段告诉另一端就好了。你举的这个例子，不管 content-type 是 application/json 还是 plain/text，报文主体的内容是一样的字节

无非就是 mapping 谁来做的问题罢了.
这种场景我都是说服后端, 让他们做, 理由:
1. 接口字段应该语义化, 一来方便开发, 需要传什么值一目了然. 二来方便测试, 测试人员抓包的时候如果能一眼看出数据含义, 效率会很高. 不仅仅字段名称语义化, 连字段值也要尽量语言化, 能传 ISO 格式的时间, 就不要传时间戳

2. 如果有多个端(ios/android/其他 web)在消费这个接口, 那么每个端都得做自己做一遍映射, 代码冗余

对于 json 文本，后端应该把 http 头 content-type 设置为 application/json ，一些语言或者框架看到这个头部字段，会帮你转成 json 对象

循环太少不见得电池就健康。可能是一直插电用，电池鼓包的概率会变大