KNX DPT16 的 14 字节能放几个中文：怎样区分 ASCII 与 Latin-1

DPT16.000使用ASCII，16.001使用Latin-1，负载固定14字节，两者都不能直接承载中文。不能把“14字节”理解成任意14个Unicode字符；本题在维护者公开格式之上添加严格编码保护，拒绝不能表示的文本。

适用版本与输入范围

依据 XKNX 维护者仓库固定标签 3.6.0 的下列源码，只实现本文明示的数据点或组值解析子集。它不是 KNX 规范全文，也不是设备互通认证；组地址与DPT应由项目点表明确提供。 本文所有输入均为原创合成数据，未接真实设备。

子类型先决定字符集

附件ASCII文本Hall-1占六字节，后补八个零；Latin-1文本Cafeé含E9字节，后补到总长十四。字符看起来都是西文也可能在ASCII与Latin-1之间有差异，必须由完整DPT编号选择编码。中文“前厅”在这两个字符集中均无表示，不能用UTF-8六字节直接塞入同样长度的负载，那样对端仍会按ASCII或Latin-1解释，显示错误字符。

严格检查是本程序的额外策略

XKNX 3.6.0的固定字符串实现对无法编码或解码的字符使用替换行为，并在解析时过滤零字节。本附件为防止工程名称无声丢失，发送前用errors=strict检查；因此中文负例明确拒绝，不声称维护者库也会抛出相同错误。这个差别应写进交付契约：替换可以用于宽松显示，不能直接用于依赖名称精确匹配的点位映射。原文、子型与编码后的字节最好同时保留。

十四字节上限在编码后核算

程序先按指定编码生成字节，再检查长度，超过十四则拒绝，不静默截断到能放下。15个ASCII数字负例能清晰验证边界，与中文不兼容是两种不同错误。成功后补零到恰好十四，报告bytes=14，hex给完整线上内容。本示例按维护者行为过滤零字节再解码；如果项目把内嵌零当特殊分隔，需另行定义，不要假定所有接收端都会采用相同显示策略。

文字显示与控制地址分开

固定字符串适合有明确字符集限制的短标签，不应替代组地址或内部唯一ID。界面可以另外保存UTF-8中文名称，协议字段仍按其DPT支持范围生成；这属于工程数据模型选择，不是自动把DPT16变成中文协议。附件所有文件自身均是有效UTF-8，待编码文本作为JSON字符串保存，没有非法编码下载文件。程序不发总线电报，未测试任何实际面板或显示设备对替换字符和零填充的处理。

下载与复跑

将输入 fixture.json与独立程序 verify.py放在同一目录，用 Python 3.12 执行 python verify.py，无需安装第三方包。程序从自身目录读取输入并写入 report.json，不要求当前终端恰好位于下载目录。也可查看本次实跑报告和复跑说明。

本次实际运行通过 4 条输入断言，包括标有“显式负例”的记录；负例以JSON字段承载，不会把下载文件本身做成损坏编码。hex包含全部14字节；严格拒绝不兼容字符是本交付保护策略，未冒充维护者的替换行为。 修改输入后应同时审查期望结果，不能只改断言数字让测试变绿。

对象或字段的基础关系可回到KNX 组地址与DPT入门核对，更多接口入口在设备协议库。若需要把已确认的数据点接入展项编排，可了解SoftControl 展厅中控；具体接入能力以项目确认和实际测试为准。

一级依据

• DPTString / DPTLatin1 / DPTASCII

来源核对日期：2026-10-24。离线结果只证明给定输入的解析或计算行为；现场兼容性、响应时间、硬件准确度和具体产品支持均未测量。