Java .properties 文件在 C# 里不能直接用 ConfigurationManager
或 IConfiguration
因为 .properties 是 Java 生态的纯文本键值格式（
key=value），没有标准的 .NET 内置解析器。.NET 的
ConfigurationBuilder默认只认
.json、
.xml、
.ini（Windows 风格）等，
.properties不在支持列表里——硬塞进去会静默失败或报
FileFormatException。
常见错误现象：
– 直接把
app.properties加进
AddJsonFile()→ 报错
JSON parse error
– 用
AddIniFile()加载 → 键名被截断（如
db.url变成
db节区）、注释行崩溃
– 手动
File.ReadAllLines()后用
Split('=') → 遇到带等号的值（password=abc=123）或空格缩进就崩 必须自己处理注释（
#和
!开头）、空行、键值间空格、反斜杠转义（
\n、
\uXXXX） Java 规范要求键名末尾空格保留，值开头空格默认忽略——C# 字符串操作不默认满足这点 如果项目已用
IConfiguration统一管理配置，最好封装成
IConfigurationProvider，而不是每次手动解析
用 PropertiesParser
NuGet 包最省事（但要注意版本兼容性）
社区有个轻量库
PropertiesParser（作者：davidfowl，非官方但稳定），它专为 .properties 设计，能正确处理转义、Unicode、多行值（用
\续行）。
安装命令：
dotnet add package PropertiesParser
立即学习“Java免费学习笔记（深入）”；
只支持 .NET Standard 2.0+，.NET Framework 4.6.1+；不支持 .NET Core 2.0 以下 不支持带 profile 的分环境加载（比如application-dev.properties），得自己按需读取文件 返回的是
IDictionary<string string></string>，要接入
IConfiguration需包装一层
ConfigurationProvider示例用法：
var parser = new PropertiesParser();
var dict = parser.Parse(File.OpenText("config.properties"));
// dict["db.url"] → "jdbc:mysql://localhost:3306/test"
手写解析器时，=
和 :
都得当分隔符，且要跳过前面的空格
Java 规范允许用
=、
:、空格作为键值分隔符，且键名前后空格有意义（但值前空格丢弃、值后空格保留）。所以不能简单
line.Split('=')。
先 TrimStart() 去掉行首空格和 #/
!注释 再找第一个
=或
:或空白字符的位置，取左侧为 key，右侧为 value value 要 TrimStart()，但不能 TrimEnd() —— 末尾空格是合法内容 遇到
\结尾的行，要合并下一行（并去掉续行符的换行和开头空格） Unicode 转义如
\u0020必须手动解码，
Regex.Unescape()不管用，得用
System.Text.Encodings.Web.JavaScriptEncoder或正则替换
别忽略编码问题：Java 默认用 ISO-8859-1，不是 UTF-8
Java
Properties.load()默认按 ISO-8859-1 读取，中文会变成乱码（如
\u4f60\u597d）。如果 .properties 文件实际存的是 UTF-8（常见于现代编辑器），直接
File.ReadAllText()会错读 Unicode 转义序列。 安全做法：用
File.ReadAllBytes()+
Encoding.GetEncoding("ISO-8859-1") 读原始字节，再手动解码 \uXXXX
如果确认所有文件都是 UTF-8 且不含 \uXXXX，可强制指定 Encoding.UTF8，但这是妥协，不是合规 VS 或 Rider 编辑 .properties 时，默认保存为 UTF-8，但 Java 运行时仍按 ISO-8859-1 解析 —— 所以真正跨语言共享时，要么统一用英文键值，要么约定全部转义
最麻烦的点其实不在语法解析，而在编码和转义的混合处理：ISO-8859-1 字节流 + \uXXXX 占位符 + UTF-8 文件存储，三者稍有错位，中文就全废了。
