<p>Java .properties 文件在 C# 中无法直接通过 IConfiguration 加载，因 .NET 无内置解析器，需用 PropertiesParser 库或手写解析器处理注释、空格、转义、ISO-8859-1/UTF-8 编码等细节。</p>
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 文件存储，三者稍有错位，中文就全废了。
