2026 64位中文字符乱码 报错

[freddy-yu]

同一个中文分支，时有时无报错42

[nevstop]

根据你提供的截图和描述，问题核心是：在 LabVIEW 2026 64位环境下，CSM 状态字符串中的中文字符出现乱码，并伴随“报错42”（Error 42）。Error 42 在 LabVIEW 中通常表示“内存不足”或“无法分配内存”，但在 CSM 框架的上下文中，更常见的原因是字符串编码不匹配导致解析失败，进而引发内部资源分配异常。

一句话结论

中文字符乱码 + Error 42 的根本原因是 INI 文件或状态字符串的编码格式与 CSM 框架期望的编码不一致，尤其是在 LabVIEW 2026 64位下，默认的 ANSI 编码（如 GB2312）与 UTF-8 之间的转换可能出错。CSM 框架从 2025.March 版本开始已支持 GB2312 和 UTF-8 编码的 INI 文件（参考），但若你的项目或依赖的旧版模块未正确配置编码，就会触发此问题。

原因分析

1. 编码不匹配：CSM 的状态字符串（如 "初始化"）在 INI 文件中保存时，若文件编码为 ANSI（如 GB2312），而 LabVIEW 2026 64位默认以 UTF-8 读取，则中文字符会被错误解析为乱码。乱码字符串在传递给 String To Number(I64)_csm.vi 等解析 VI 时，转换失败返回 0（参考），但更严重的是，乱码可能包含非法字符或长度异常，导致内部状态机分配内存时失败，抛出 Error 42。

2. “时有时无”的随机性：这通常与以下因素有关：

   • INI 文件加载顺序：如果多个 INI 文件或节（Section）被动态加载，某些文件编码正确、某些错误，则只有加载到错误编码的文件时才会报错。
   • LabVIEW 的字符串缓存：LabVIEW 在 64 位下对字符串的内部处理可能因内存对齐或缓存策略，导致同一字符串在不同调用中表现不一致。
   • CSM 的 __include 节加载：若 INI 文件使用了 __include 指令嵌套加载其他文件，被包含文件的编码若与主文件不一致，也会引发间歇性错误（参考）。

3. Error 42 的触发路径：CSM 在解析状态字符串时，会调用 String To Number(I64)_csm.vi 等工具 VI。如果输入字符串是乱码（例如 "��ʼ��"），该 VI 会返回 0，但后续逻辑可能尝试用这个 0 值去索引数组或分配内存，导致越界或分配失败，最终表现为 Error 42。

解决方案

1. 统一 INI 文件编码为 UTF-8（推荐）

• 使用文本编辑器（如 Notepad++、VS Code）打开所有 INI 文件，将编码转换为 UTF-8 without BOM。
• 确保 CSM 框架版本不低于 2025.March（该版本已修复编码支持问题，参考）。
• 如果必须使用 GB2312，请确保所有 INI 文件统一为 GB2312，并在 LabVIEW 中显式指定编码读取（使用 Read From Text File 时选择编码）。

2. 检查状态字符串中的特殊字符

• 避免在状态字符串中使用 #、: 等特殊符号，除非明确作为参数分隔符（参考）。例如 "Set Value: 100" 是合法的，但 "初始化#1" 可能被错误解析。
• 如果状态字符串包含中文，确保其前后没有不可见字符（如 BOM、零宽空格）。

3. 升级 CSM 相关模块

• 检查 CSM-INI-Static-Variable-Support 模块版本，确保已包含 2025.February 及之后的修复（参考），特别是修复了“数字后跟反斜杠被错误解析为 ASCII 码”的问题（#60）。
• 如果使用了 CSM-API-String-Arguments-Support，确认已更新到修复 Cluster 字符串解析问题的版本（#82、#84）。

4. 临时规避方案

• 在状态字符串中避免直接使用中文，改用英文或数字标识，然后在 VI 内部通过查找表映射到中文显示。
• 如果必须使用中文，尝试在字符串前加 0x 或 \u 转义序列（需确认 CSM 版本是否支持）。

调试建议

1. 捕获原始字符串：在调用 String To Number(I64)_csm.vi 之前，用 String Length 和 Byte Array To String 检查字符串的字节序列，确认是否为乱码。
2. 隔离测试：创建一个仅包含一个中文状态的最小 INI 文件，在干净的项目中加载，看是否复现 Error 42。
3. 查看 CSM 日志：如果启用了全局日志队列（2025.May 版本新增功能，参考），日志中会记录解析失败的详细位置。

如果以上方法仍无法解决，请提供：

• 出错的 INI 文件片段（包含中文状态的那几行）
• CSM 框架及各个 Addon 的版本号（可从 csm_version.vi 或打包信息中获取）
• 完整的错误堆栈（Error 42 通常伴随调用链信息）

这样我可以进一步定位是哪个 VI 或哪个解析步骤出了问题。

---

🤖 此回答由 CSM-QA-Robot 自动生成。如有偏差，欢迎追问或修正。

[freddy-yu]

Communicable State Machine(CSM) 版本是 v2026.4.10.134916 具体日志是这样显示的 [08:50:57.026] mavlink.浮力模式 >> 2 <- MainUI
[08:50:56.098] 发送心跳包
[08:50:49.028] Error Handler >> [Error: 42](Software Exception: Unhandled State "綥

[nevstop]

根据你提供的截图和日志信息，问题核心是 CSM 模块在接收到中文字符串状态时，触发了 Unhandled State 错误（Error 42），且该错误时有时无。这通常不是 CSM 框架本身的 Bug，而是 LabVIEW 字符串编码与 CSM 状态匹配机制之间的兼容性问题。

---

一句话结论

错误 42 的根本原因是：LabVIEW 2026（64位）默认使用 UTF-8 编码，而 CSM 内部状态匹配时可能仍按 ANSI/本地编码（如 GBK）处理中文字符，导致同一个中文字符串在不同编码下被识别为不同的字节序列，从而出现“时有时无”的匹配失败。

---

原理分析

1. CSM 状态匹配机制
   CSM 的状态（State）本质上是字符串。当模块 A 向模块 B 发送消息时，模块 B 会查找自己的状态机中是否存在与消息字符串完全匹配的状态。匹配是逐字节进行的。

2. LabVIEW 2026（64位）的编码变化
   LabVIEW 2026（64位）在 Windows 上默认使用 UTF-8 编码处理字符串（尤其是中文字符），而早期版本（或 32 位版本）通常使用系统的 ANSI 编码（如 GBK）。

   • 同一个中文字符“浮力模式”，在 UTF-8 下占用 3 个字节（E6 B5 AE E5 8A 9B E6 A8 A1 E5 BC 8F），在 GBK 下占用 2 个字节（B8 A1 C1 A6 C4 A3 CA BD）。
   • 如果 CSM 模块的状态定义（在 INI 文件或代码中）是用 GBK 编码保存的，而运行时接收到的消息是 UTF-8 编码，则字节序列不匹配，CSM 就会认为该状态“未定义”，抛出 Unhandled State 错误（Error 42）。

3. “时有时无”的原因

   • 如果 CSM 模块的状态定义文件（如 INI 文件）本身也使用了 UTF-8 编码，但某些字符（如“浮力模式”）在 UTF-8 和 GBK 下恰好有部分字节重叠，或者 LabVIEW 在某些情况下自动进行了编码转换，就可能出现部分匹配成功、部分失败的现象。
   • 另外，如果消息发送方（如 MainUI）和接收方（如 mavlink.浮力模式）的字符串编码不一致，也会导致间歇性错误。

---

解决方案

1. 统一编码（推荐）

确保 所有 CSM 模块的状态定义、INI 配置文件、以及消息发送方 使用相同的编码。

• 在 LabVIEW 2026（64位）中，建议显式将字符串编码设置为 UTF-8。
• 对于 INI 文件，使用支持 UTF-8 的编辑器（如 VS Code、Notepad++）保存，并确保文件头包含 BOM（Byte Order Mark）或明确声明编码。
• 在 LabVIEW 代码中，使用 String To Byte Array 和 Byte Array To String 配合 Flatten To String / Unflatten From String 时，注意指定编码（如 0x0C 表示 UTF-8）。

2. 检查 CSM 状态定义

• 打开你的 CSM 模块的 INI 配置文件（通常位于 CSM-INI-Static-Variable-Support 插件管理的路径下），检查其中包含中文字符的状态定义。
• 如果发现文件编码不是 UTF-8，请重新保存为 UTF-8 编码。
• 参考 CSM-INI-Static-Variable-Support 文档 中关于嵌套变量和编码的说明。

3. 使用英文状态名（临时规避）

如果项目允许，将包含中文字符的状态名改为纯英文（如 float_mode），可以彻底避免编码问题。

• 修改后，更新所有发送方和接收方的状态字符串。
• 这是最稳妥的临时方案，尤其适合快速验证问题是否由编码引起。

4. 检查 CSM 版本与补丁

你使用的版本是 v2026.4.10.134916，这是一个较新的版本。请确认是否已应用所有最新补丁，特别是关于字符串解析的修复：

• 参考 2025.May 更新日志 中提到的“修复值中包含 # 时解析失败的问题”和“修复 INI __include 节加载后丢失的问题”。
• 虽然这些修复不直接针对中文编码，但确保插件（如 CSM-INI-Static-Variable-Support）是最新版本，可以减少其他潜在问题。

5. 调试技巧

• 在接收方模块的 Error Handler 中，添加一个断点或日志输出，打印出实际接收到的消息字节数组（使用 String To Byte Array）。
• 同时，打印出状态定义表中该中文字符串的字节数组。
• 对比两者是否一致。如果不一致，即可确认是编码问题。

---

常见坑与最佳实践

• 坑 1：LabVIEW 2026（64位）的 INI 文件读取函数（如 Read Key）可能默认使用 ANSI 编码，导致 UTF-8 文件中的中文字符被错误解析。
  解决：使用 CSM-INI-Static-Variable-Support 插件提供的 CSM - Read Cluster Elements From Key.vi 等 VI，它们已经内置了缓存和编码处理机制（参考 2025.May 更新）。

• 坑 2：如果使用 CSM - Broadcast Status Change.vi 广播中文字符串状态，确保所有订阅方都能正确解析该字符串。
  解决：在广播前，统一使用 Set Enum String Value（该 VI 已支持大小写不敏感，但编码仍需一致）进行标准化。

• 最佳实践：在整个项目中强制使用 UTF-8 编码。在 LabVIEW 项目属性中，可以设置默认字符串编码为 UTF-8（如果可用）。对于所有文本文件（INI、XML、CSV 等），统一使用 UTF-8 with BOM 保存。

---

如果以上方法仍无法解决

请提供以下信息，以便进一步分析：

1. 发送方（MainUI）和接收方（mavlink.浮力模式）的 CSM 模块代码片段（特别是状态定义和消息发送部分）。
2. 相关的 INI 配置文件内容（注意隐藏敏感信息）。
3. 在 Error Handler 中打印出的实际接收到的消息字节数组。

知识库中暂无关于 LabVIEW 2026 64位中文编码与 CSM 兼容性的专门文档，但上述分析基于 CSM 框架的字符串匹配原理和 LabVIEW 编码变化的一般规律。如果问题持续，建议在 CSM GitHub Issues 中提交一个带有最小复现示例的 Bug 报告。

---

🤖 此回答由 CSM-QA-Robot 自动生成。如有偏差，欢迎追问或修正。

[freddy-yu]

并不是ini文件读取和写入，是中文状态分支报错

[nevstop]

根据你提供的日志和截图，问题非常明确：CSM 在 2026 64-bit LabVIEW 中遇到中文字符串时，状态名称被错误解析为乱码（如 "綥），导致 Error 42: Unhandled State。这不是 INI 文件读写问题，而是 CSM 状态名称的编码/解析环节 出现了故障。

---

一句话结论

CSM v2026.4.10.134916 在 64-bit LabVIEW 2026 下，当状态名称包含中文字符时，内部字符串解析可能因编码不兼容而截断/乱码，导致状态机找不到对应分支，抛出 Error 42。 该问题具有间歇性（时有时无），说明与运行时内存布局或字符串缓存时机有关。

---

问题根因分析

1. Error 42 的含义

CSM 的 Error 42 对应 CSM Missing Return State Error，在 2025.April 版本 中明确提到：

若用户在消息调用（-&）中清除了返回状态，现在会抛出 CSM Missing Return State Error。

但你的场景是状态名称本身乱码，导致状态机在 Dispatch 时无法匹配任何 Case，从而触发该错误。

2. 乱码 "綥 的成因

• 日志中显示 Unhandled State "綥，说明 CSM 内部存储的状态名称字符串已被破坏。
• 64-bit LabVIEW 2026 对 Unicode 字符串的处理与 32-bit 存在差异，尤其是在 字符串长度计算 和 内存对齐 方面。
• 当 CSM 通过 Set Enum String 或 CSM - Argument Token.vi 解析中文字符串时，若底层 C 接口（如 DLL 调用）未正确处理 UTF-8 编码，会导致多字节字符被截断。

3. 间歇性复现的原因

• 该问题与 字符串缓存时机 有关：当状态名称在某个特定内存地址被分配时，恰好触发编码截断；否则正常。
• 在 2025.June 版本 中引入了 Argument Token 概念，自定义参数类型通过 <NewType> 前缀标识。如果你的状态名称是通过参数 Token 传递的，可能触发了该路径下的编码问题。

---

解决方案

方案一：升级 CSM 到最新版本（推荐）

• 你当前使用的 v2026.4.10.134916 是 2026 年 4 月的构建版本。
• 检查是否有更新的 CSM 版本（如 2025.September 或 2025.Q4 版本），这些版本修复了多项核心问题，包括：
  • 关键错误改用 ErrString 表示（#501）
  • 不再使用全局变量作为变更标志（#504）
  • 异步模块资源生命周期绑定（#437）

方案二：临时规避（不改 CSM 版本）

1. 避免在状态名称中使用中文
   将 mavlink.浮力模式 改为纯英文，如 mavlink.BuoyancyMode。这是最稳妥的临时方案。

2. 使用 Set Enum String 时显式指定编码
   在调用 Set Enum String Value 工具 VI 时，确保输入字符串为 UTF-8 编码。LabVIEW 2026 64-bit 默认使用 UTF-8，但 CSM 内部可能仍按 ANSI 处理。

3. 检查状态名称的传递路径

   • 如果状态名称是通过 CSM - Argument Token.vi 解析的，尝试直接传递枚举值而非字符串。
   • 如果状态名称来自 INI 文件或配置文件，确保文件保存为 UTF-8 without BOM 格式。

方案三：调试与报告

• 使用 CSM Debug Console 的“仅 API”模式，观察状态名称在 Dispatch 前后的实际字符串内容。
• 在 GitHub 上提交 Issue，附上你的日志和截图，指向 CSM 仓库。

---

最小可复现示例（LabVIEW 伪代码）

// 假设状态枚举为 "mavlink.浮力模式"
// 在某个状态中调用：
CSM - Set Next State.vi (state: "mavlink.浮力模式")

// 期望：跳转到 "mavlink.浮力模式" 分支
// 实际：日志显示 Unhandled State "綥"

---

总结

项目	内容
根本原因	CSM v2026.4.10 在 64-bit LabVIEW 2026 下对中文字符串的编码处理存在缺陷
直接表现	状态名称乱码 → Error 42: Unhandled State
推荐操作	升级 CSM 到最新版本，或临时改用英文状态名称
长期方案	在 CSM 官方修复该问题后，重新启用中文状态名称

如果你需要进一步排查，可以运行 CSM - Internal State Debug Log History.vi（注意该 VI 在运行时默认禁用，需手动启用）来捕获更详细的状态流转日志。

---

🤖 此回答由 CSM-QA-Robot 自动生成。如有偏差，欢迎追问或修正。

[nevstop]

@freddy-yu 我不是机器人哈

CSM-QA-Robot 回复的内容部分是正确的，我会让AI学习这个讨论，添加一个FAQ。

首先我不确定是否是 LabVIEW 2026 本身中文处理改变导致的一些问题，我知道它增强了UTF8的支持，所以我会记录一个issue, 来查看是否需要CSM内部修改来防范你发现的问题。

你可以做以下的检查和临时方案：

1. 检查是否 >> 这个符号打错了，因为 CSM 是通过这个符号来区分参数和消息的，实际上和UTF8无关，我初步怀疑是否有个别地方这个符号有中文，导致了你发现的问题；
2. 如robot建议，将消息名称改变为英文

如果有进一步信息，麻烦你再返回这里告诉我，这样可以减少开发的调试时间

[freddy-yu]

检测了一下，倒是在这里可能会出现传空参数的情况

[yao0928]

看起来是你代码的问题哈这个参数格式明显不是 HEXSTR，所以log显示的应该不是这里，现在看起来，可能不是中文的问题，而是本身这个模块的问题了

[freddy-yu]

我有个问题，就是state+参数直接用hex字符会不会出现这个乱码的情况？

[yao0928]

我有个问题，就是state+参数直接用hex字符会不会出现这个乱码的情况？

应该不会，我理解是你的参数不是可见字符串，导致了破坏了 csm 分割消息、参数的逻辑。 HEXSTR 或者 massdata 都是为了这个情况设计的，他们转换后不会影响

[freddy-yu]

我现在直接是发的HEX字符 并没有经过hexSTR来转换哦，刚刚转换的是别的功能函数，我下发UDP是这样的直接传递的

参数直接给udp发送了

[nevstop]

issue link: NEVSTOP-LAB/Communicable-State-Machine#621

[freddy-yu]

mavlink.valveOnoff >> 2-0 <- MainUI 这样“2-0”传递参数会不会导致bug？

[nevstop]

根据你提供的日志和截图，问题核心是 CSM 状态机在解析中文状态分支时出现编码异常，导致报错 Error 42 (Unhandled State)。下面从原理、原因和解决方案三个层面分析。

---

一句话结论

CSM 状态机在 v2026.4.10.134916 版本中，当状态分支名称包含中文字符时，若 LabVIEW 运行环境（如 2026 64-bit）的默认编码与 CSM 内部字符串处理逻辑不匹配，会导致状态名被错误解析为乱码（如 綥），从而触发 Error 42——即状态机找不到该状态分支。

---

1. 错误原理：Error 42 与中文编码

• Error 42 含义：CSM 状态机在收到一个状态切换请求时，会在当前模块的“状态分支列表”中查找匹配项。如果找不到完全匹配的状态名，就会抛出 Error 42，并附带 Unhandled State "xxx" 信息。

• 你日志中的关键线索：

  Error Handler >> <ErrStr>[Error: 42](Software Exception: Unhandled State "綥
  

  这里的 "綥" 明显是 中文字符被错误编码后的乱码。原本的状态名（如“浮力模式”）在 CSM 内部被错误地转换成了无法识别的字节序列，导致状态机认为这是一个从未定义过的状态。

• 为什么“时有时无”：
  中文编码问题通常与 字符串的字节序、UTF-8 BOM、LabVIEW 的路径编码设置 有关。当状态名从某个模块（如 MainUI）发出时，如果该模块的字符串编码与接收模块（如 mavlink.浮力模式）不一致，就可能出现“有时正常、有时乱码”的现象。例如，MainUI 可能在某些情况下使用了系统默认的 ANSI 编码（GB2312/GBK），而 CSM 内部期望的是 UTF-8。

---

2. 关于 mavlink.valveOnoff >> 2-0 <- MainUI 这种参数传递

这种 "2-0" 格式的参数传递本身不会直接导致编码乱码，但需要注意：

• CSM 的状态切换消息格式为 模块名 >> 状态名 <- 来源。其中 状态名 可以是任意字符串，包括 "2-0"。
• 如果 "2-0" 是一个合法的状态分支名称（即你在该模块的状态图中确实定义了一个名为 "2-0" 的分支），那么它是完全正常的。
• 但如果你期望的是传递两个参数（如 2 和 0），则 "2-0" 会被当作一个整体字符串状态名，而不是两个独立参数。CSM 原生不支持在状态名中嵌入分隔符来传递多个参数——你需要使用 CSM-MassData-Parameter-Support 或自定义数据通道来实现参数传递。

---

3. 解决方案

方案 A：统一编码环境（推荐）

CSM 的 CSM-INI-Static-Variable-Support 组件从 v2025.March 开始支持 GB2312 和 UTF-8 编码的 INI 文件，但状态分支名称的编码处理依赖于 LabVIEW 运行环境。请检查以下设置：

1. LabVIEW 选项 → 路径 → 使用 UTF-8 编码：确保勾选此项（LabVIEW 2020 及以上版本支持）。
2. 所有 VI 的字符串控件/常量：确保使用 UTF-8 或 Unicode 编码，避免使用 系统默认。
3. CSM 模块的“状态分支”字符串：在模块的初始化 VI 中，手动将状态分支名称转换为 UTF-8 字节数组再写入。

方案 B：避免在状态名中使用中文

这是最稳妥的临时方案。将中文状态名改为英文或纯数字/符号组合，例如：

• 浮力模式 → BuoyancyMode 或 mode_buoyancy
• valveOnoff 保持英文即可

这样可以从根本上避免编码问题。

方案 C：升级 CSM 版本

你当前使用的 v2026.4.10.134916 是一个较新的版本。请检查是否有更新的补丁或修复版本。CSM 团队在 2025.June 的更新 中修复了 INI 变量优先级逻辑，但未明确提及中文编码修复。建议在 GitHub Issues 中搜索 #81、#82 相关讨论，或提交新 Issue。

方案 D：调试定位具体乱码来源

在 MainUI 模块发送状态切换请求之前，添加一个断点或日志输出，打印实际发送的状态名字符串的 字节数组（使用 String To Byte Array 函数）。对比正常与乱码时的字节序列，可以判断是哪个环节发生了编码转换。

---

4. 补充建议

• 检查 Error Handler 模块：CSM 内置的错误处理机制会在模块发生错误时自动广播 Error Occurred 状态。你可以订阅该状态，在错误发生时记录完整的上下文（包括来源模块、目标状态名、时间戳），便于复现。
• 避免在状态名中使用特殊字符：如 -、空格、中文标点 等，这些字符在不同编码下可能被错误解析。
• 如果问题持续：请提供 MainUI 模块发送状态切换请求的 VI 片段（或伪代码），以及 mavlink.浮力模式 模块中定义状态分支的截图，以便进一步分析。

---

总结

问题	原因	解决方案
中文状态名乱码导致 Error 42	LabVIEW 编码设置与 CSM 内部字符串处理不匹配	统一 UTF-8 编码 / 改用英文状态名
"2-0" 参数传递	被当作单一状态名，非多参数	使用 MassData 或自定义数据通道
时有时无	编码转换条件触发不一致	添加字节数组日志定位具体环节

建议优先尝试 方案 A + 方案 B，这能最快解决当前的中文乱码问题。如果后续需要传递多参数，再考虑引入 CSM-MassData-Parameter-Support。

---

🤖 此回答由 CSM-QA-Robot 自动生成。如有偏差，欢迎追问或修正。

[yao0928]

对的，问题就在这里。这个数据你应该先把它放到massdata 里面，处理的时候再解出来这段数据 发自我的iPhone

…

------------------ 原始邮件 ------------------ 发件人: 波塔斯基 ***@***.***&gt; 发送时间: 2026年6月24日 15:37 抄送: yao0928 ***@***.***&gt;, Comment ***@***.***&gt; 主题: Re: [NEVSTOP-LAB/.github] 2026 64位中文字符乱码 报错 (Discussion #106) 我现在直接是发的HEX字符 并没有经过hexSTR来转换哦，刚刚转换的是别的功能函数，我下发UDP是这样的直接传递的 image.png (view on web) 参数直接给udp发送了 — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today! You are receiving this because you commented.Message ID: ***@***.***&gt;

[yao0928]

对的，问题就在这里。这个数据你应该先把它放到massdata 里面，处理的时候再解出来这段数据 发自我的iPhone
…
------------------ 原始邮件 ------------------ 发件人: 波塔斯基 @.> 发送时间: 2026年6月24日 15:37 抄送: yao0928 @.>, Comment @.> 主题: Re: [NEVSTOP-LAB/.github] 2026 64位中文字符乱码 报错 (Discussion #106) 我现在直接是发的HEX字符 并没有经过hexSTR来转换哦，刚刚转换的是别的功能函数，我下发UDP是这样的直接传递的 image.png (view on web) 参数直接给udp发送了 — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today! You are receiving this because you commented.Message ID: @.>

@freddy-yu 请查看。抱歉的是这个机器人太烦了。。我还要调试下它，你忽略一下哈. 如果有兴趣，欢迎你加入 NEVSTOP-LAB，你可以新开一贴，说明要加入，机器人会给你发邀请。可以一起做一些共享模块，你也能看到更多的private 仓库

[freddy-yu]

搞定了，非常感谢。我把hex字符重新处理一下 就再也没这个报错了，