Python直接用open()按行split('=')解析Properties文件会出错，因该格式支持注释、空行、空格、反斜杠续行、Unicode转义及值中含等号，硬切会导致截断和误解析；应优先用pyjavaproperties库，它专为Java风格设计，能正确处理各类边界情况。
Python读取Properties文件时，为什么直接用open()按行split('=')会出错
因为Properties文件支持注释（#或!开头）、空行、键值间空格、反斜杠续行、Unicode转义（如u4f60），还有等号可能出现在值里（如url=http://a=b.com）。硬切'='第一处会把值截断，忽略注释还会把配置项当键值对。
实操建议：
- 别自己写正则或
str.split()解析，优先用成熟方案 - 如果项目已依赖
configparser，它原生不支持.properties语法（比如不认#注释为注释，也不处理反斜杠），得绕过 - 轻量场景推荐
pyjavaproperties库，专为Java风格Properties设计，能正确处理转义、续行、注释
用pyjavaproperties读取并转成Python字典的最小可行代码
它返回的是dict，但键值都是字符串，且自动去除首尾空格，值里的
uXXXX也已解码。
安装和使用：
立即学习“Python免费学习笔记（深入）”；
pip install pyjavaproperties
代码示例：
from pyjavaproperties import Properties<br><br>p = Properties()<br>p.load(open('app.properties', 'rb')) # 注意：必须用二进制模式<br>config_dict = dict(p.items())注意点：
-
load()必须传bytes，所以open(..., 'rb')不能写成'r'，否则报AttributeError: 'str' object has no attribute 'decode' - 如果文件含BOM（如Windows记事本保存的UTF-8 with BOM），
pyjavaproperties会把BOM当键名开头，导致键异常；建议用VS Code或Notepad++另存为「UTF-8 无BOM」 - 它不自动做类型转换（比如
timeout=30仍是字符串'30'），需业务层自行int()或float()
不用第三方库：手写安全解析函数的关键边界处理
如果环境禁止装包（如某些生产沙箱），就得自己写。核心是三件事：跳过注释/空行、找最后一个等号、剥离前后空格、处理反斜杠续行。
简易但健壮的实现要点：
- 逐行读，用
line.strip()前先判断是否为空或以#/!开头 - 用
line.find('=')从右往左找等号（line.rfind('=')），避免URL类值被误切 - 键用
line[:idx].strip().rstrip('\')，值用line[idx+1:].strip()，再手动处理\和codecs.decode(value, 'unicode_escape')） - 遇到
\要合并下一行——这意味着你得缓存上一行未完成的键或值
为什么configparser配defaults或read_file()仍不推荐用于Properties
有人试过把.properties当.ini读，改后缀或加[default]节头，但这会掩盖真实问题：
-
configparser把#当节注释，但Properties中# key=value是合法注释行，不该被当成配置 - 它不识别
u6709这种Unicode转义，会原样保留字符串 - 值里有
%时，configparser默认启用插值，抛InterpolationSyntaxError，关掉又失灵活性 - 即使强行适配，后续维护者看到
configparser会默认按INI逻辑理解，容易引发误改
真正麻烦的不是读取动作本身，而是“看起来能跑通”的错觉——尤其在测试环境用简单配置没暴露问题，上线后遇到带转义或续行的真实Properties就崩。
