From 6845648a09fc28c0ac854e67fa7ecd2f0924cdc9 Mon Sep 17 00:00:00 2001
From: siyuan <17797776520@163.com>
Date: Tue, 18 Jun 2024 23:42:40 +0800
Subject: [PATCH] =?UTF-8?q?6=E6=9C=8818=E5=8F=B7=E6=97=A5=E6=8A=A5?=
 =?UTF-8?q?=E5=86=85=E5=AE=B9?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 2024-6-18.-.md | 47 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 47 insertions(+)
 create mode 100644 2024-6-18.-.md

diff --git a/2024-6-18.-.md b/2024-6-18.-.md
new file mode 100644
index 0000000..f5dd0af
--- /dev/null
+++ b/2024-6-18.-.md
@@ -0,0 +1,47 @@
+# 完成了什么？
+
+主要是对昨天出现的问题进行调研，为什么修改之后设备之后，显示修改成功，却没有修改。有以下两个原因：
+
+一： 设备本身不支持，无法进行修改。
+
+二： 设备支持，但是参数不在设备允许范围内
+
+三： 遇到错误没有返回ERROR的原因是，还是对项目没有更深入的了解，在遇见错误时，没有进行通知，导致程序不知道遇见错误，从而忽略，导致出现显示修改成功，却没有修改的问题。
+
+还有就是设备名称中文乱码问题，旭哥对我说是因为UTF-8编码问题，我定位了很久没有定位出来，还是不够细心，没有考虑到xml本身就是使用utf-8编码的，对代码理解不深刻。
+
+在定位到问题之后，我就开始查阅怎么打开将utf-8 转化为 Gb2312， 查阅了https://www.cnblogs.com/cheyunhua/p/15915130.html 发现使用 simplifiedchinese.HZGB2312.NewEncoder()进行转化处理。
+
+然后我就使用该编码进行转换，但是还是乱码，就开始怀疑是不是这里的问题，就继续测试，将GB2312 转化成 UTF-8 发现也是乱码，最后确定是是自己转码错误所导致的问题，但是我经过google 和 百度之后，发现都是使用 simplifiedchinese.HZGB2312.NewEncoder() 函数将UTF-8 进行转化的，就没有怀疑，直至下班之前也没发现问题所在。
+
+直到下班之后，蔡总给我说GBK可以完全兼容GB2312，然后我就使用了GB18030 进行编码转换，发现确实可以，那么我就思考，为什么HZGB2312编码不行呢？在经过了解之后，经过源码的阅读发现：
+
+HZGB2312编码是基于ASCII 的编码和GB2312 的处理方式不同导致了字符的错误显示，HZGB2312主要用于这种编码在传输过程中使用了 ~{ 和 ~} 来切换到 GB2312 模式和返回到 ASCII 模式，所以乱码一般都包含~{ ，~{后面的字符就是GB2312编码。下午没有解决编码的主要原因是没有深入源码，通过源码阅读一切就明了了。
+
+# 学到了什么？
+
+1. 学到了如何进行编码转换，并以后尽量使用兼容性好的，遇见错误尽量多测试，考虑为什么会出现这样的情况，并深入源码，查找答案！
+
+2. 学到了不能一头撞到墙上，需要多思考。
+
+3. 更加深入源码，之前不知道观察者是干嘛的，通过对源码阅读和理解，得知通过观察者阻塞消息，判断设备发送的信令是否收到了，或者是否有错误，如果有错误的话，应该在Hander层进行相应的处理，例如通过Notify进行通知观察者错误消息，这样观察者就可以在server层向上抛出异常。
+
+4. 根据文档理解了设备设置的其他功能，如设置录像计划等，并更加的熟练抓包分析信令，通过信令分析收发包是否正确。
+
+
+# 后续任务
+
+将会观看级联相关代码，深入理解sdk相关代码
+
+# 反思
+
+没有认真的思考，没有认真深入源码，后续将会改正。
+
+
+
+
+
+
+
+
+