读取文本时，为什么要明确编码和错误处理

读取配置文件、日志或用户上传的文本时，程序首先拿到的是字节。只有按某种编码规则解码后，字节才会变成可以处理的文字。因此，读文件不只是打开路径，还包含了对数据格式的解释。

编码说明字节与文字之间如何对应。例如，汉字“云”在 UTF-8 中占三个字节。它显示为一个汉字，并不意味着文件只需要一个字节保存。若文件由一种编码写入，读取方却采用另一种规则，可能出现乱码，也可能直接报错。处理跨环境文件时，最好把编码当成接口约定的一部分。

错误处理方式同样需要明确。严格解码会在遇到非法字节时报告错误，提醒调用方检查文件来源或格式。它有助于及时发现输入问题，但调用方也应给出容易理解的提示，而不是让用户只看到一长段异常信息。

忽略错误看起来能让流程继续，却可能丢失内容。本次用一份包含字母 A、一个非法 UTF-8 字节和字母 B 的样例进行验证：严格解码会报错，忽略错误后得到的文本则只剩 AB。程序没有崩溃，但输入已经发生变化，后续搜索、校验和统计都可能受到影响。

另一种处理方式是用替换字符表示无法识别的部分。在相同样例中，两个字母之间会出现一个替换字符。这比直接丢弃更容易让人注意到异常，但替换后的文本仍然不是原始内容，不能据此认为文件已经正确修复。

选择哪种策略，需要结合用途。配置解析、标识符校验和需要精确比对的输入，通常更适合在异常处停止并说明原因。面向人工阅读的日志预览，可以考虑显示替换字符，同时明确提示存在解码问题。不要把为了展示而做的容错结果，直接用于要求精确性的业务判断。

排查时也不宜不断更换编码，直到某一种设置不再报错。能够解码只是一个条件，并不能单独证明得到的文字就是文件原本表达的内容。更可靠的依据是生成文件的系统、导出设置，以及发送方明确提供的格式说明。

实际设计读取流程时，可以分别记录读取是否成功、解码是否成功，以及业务检查是否通过。文件找不到、编码不合法和内容不符合规则，是不同层次的问题。把它们分开，用户才知道应该重新选择文件、检查导出编码，还是修改正文内容。

本次还验证了有效 UTF-8 文本的编码与解码往返，以及非法字节在严格、忽略和替换三种策略下的结果，共五项断言均通过。验证只针对这些样例。保留原始文件、明确编码约定和说明错误处理策略，比单纯追求“读取不报错”更有助于保证结果可信。