答案是文本文件以字符形式存储并依赖编码解析，二进制文件直接存储原始字节。读写时需区分模式（如’r’与’rb’），使用with语句管理资源，避免内存溢出需分块或逐行处理大文件，并注意编码、权限及模式错误。
读写文本文件和二进制文件，核心在于理解它们的数据存储方式和对应的操作模式。简单来说，文本文件处理的是字符，而二进制文件处理的是原始字节流。在编程中，这通常通过指定文件打开模式（如
'r'
用于文本读取，
'rb'
用于二进制读取）来区分，并使用相应的方法（如文本的
read()
会返回字符串，二进制的
read()
会返回字节串）进行操作。
解决方案
在我看来，掌握文件读写，最关键的是理解
open()
函数及其模式参数，以及
with
语句的妙用。这不仅能让代码更简洁，还能有效避免资源泄露。
读写文本文件
文本文件，顾名思义，是人类可读的字符序列。当我们打开一个文本文件时，系统会根据指定的编码（比如UTF-8）将字节流转换为字符。
读取文本文件：通常，我们会用
'r'
模式打开文件进行读取。如果文件编码不是系统默认的，最好明确指定
encoding
参数。
try: with open('my_text_file.txt', 'r', encoding='utf-8') as f: content = f.read() # 读取整个文件内容为一个字符串 print("文件全部内容:n", content) # 也可以逐行读取，尤其适合大文件 f.seek(0) # 将文件指针移回开头 print("n逐行读取:") for line in f: print(line.strip()) # strip() 去除每行末尾的换行符except FileNotFoundError: print("文件 'my_text_file.txt' 未找到。")except UnicodeDecodeError: print("解码错误，请检查文件编码是否为UTF-8。")
写入文本文件：写入文本文件通常使用
'w'
模式（写入，会覆盖原有内容）或
'a'
模式（追加，在文件末尾添加内容）。
# 写入模式 ('w') - 如果文件存在则清空，不存在则创建with open('output.txt', 'w', encoding='utf-8') as f: f.write("这是第一行文本。n") f.write("这是第二行，我正在写入一些新内容。n") print("内容已写入 output.txt (覆盖模式)。")# 追加模式 ('a') - 在文件末尾添加内容with open('output.txt', 'a', encoding='utf-8') as f: f.write("这是追加的第三行。n") f.write("再加一行，看看效果。n") print("内容已追加到 output.txt。")
读写二进制文件
二进制文件则不同，它不关心字符编码，直接操作原始字节数据。这对于处理图片、音频、视频、可执行文件等非文本数据至关重要。
读取二进制文件：使用
'rb'
模式。读取到的内容将是
bytes
对象。
try: with open('my_image.jpg', 'rb') as f: binary_data = f.read() # 读取整个文件内容为一个bytes对象 print(f"读取到 {len(binary_data)} 字节的二进制数据。") # print(binary_data[:50]) # 打印前50个字节，看看是什么样子except FileNotFoundError: print("文件 'my_image.jpg' 未找到。")
这里我通常会用一个实际存在的图片文件来测试，比如从网上随便下载一张小图。
写入二进制文件：使用
'wb'
模式。写入的内容必须是
bytes
对象。
# 假设我们有一些字节数据data_to_write = b'x48x65x6cx6cx6fx20x42x69x6ex61x72x79x21' # "Hello Binary!" 的ASCII字节表示data_to_write += b'x00x01x02x03x04x05' # 额外的一些字节with open('binary_output.bin', 'wb') as f: f.write(data_to_write) print("二进制数据已写入 binary_output.bin。")# 也可以将一个图片的字节数据写入另一个文件# with open('my_image.jpg', 'rb') as src:# img_data = src.read()# with open('copied_image.jpg', 'wb') as dest:# dest.write(img_data)# print("图片已复制。")
文本文件和二进制文件，究竟有何本质区别？
在我看来，它们最根本的区别在于“解释”的方式。文本文件是面向字符的，它假设文件内容是由特定编码（如UTF-8, GBK）的字符组成的。当我们读取文本文件时，操作系统或编程语言会根据这个编码规则，将底层的字节序列“翻译”成我们能理解的字符。如果编码不对，就会出现乱码。比如，
'你好'
在UTF-8下可能是一串字节
b'xe4xbdxa0xe5xa5xbd'
，但在GBK下可能是另一串字节。文本编辑器就是基于这种“翻译”来展示内容的。
而二进制文件则是面向字节的，它不进行任何字符编码的转换。文件中的每一个字节都被视为独立的原始数据。程序读取二进制文件时，得到的就是一串未经解释的字节序列（通常是
bytes
对象），至于这些字节代表什么，完全取决于应用程序如何去“构造”和“理解”它们。一个字节可能代表一个像素的颜色值，也可能代表一个整数的一部分，或者一个指令码。这种直接操作字节的方式，使得二进制文件可以存储任何类型的数据，但代价是失去了人类的直接可读性。你用文本编辑器打开一个图片文件，看到的只会是乱码，因为文本编辑器试图用字符编码去解释那些本来不代表字符的字节。
处理大文件时，有哪些高效的读写策略？
处理大文件时，最核心的原则是“不要一次性将整个文件读入内存”。内存是有限的，如果文件太大，很容易导致程序崩溃。我通常会采用以下几种策略：
逐行读取（文本文件）： 这是最常用也最简单的策略。Python的
for line in f:
结构就是为此而生。它会在每次迭代时读取一行，而不是一次性读取所有行。这对于日志文件、CSV文件等非常有效。
# 示例：处理一个巨大的日志文件def process_large_log(filepath): processed_count = 0 with open(filepath, 'r', encoding='utf-8') as f: for line_num, line in enumerate(f, 1): # 假设我们只关心包含 "ERROR" 的行 if "ERROR" in line: print(f"在第 {line_num} 行发现错误: {line.strip()}") processed_count += 1 # 模拟一些耗时操作 # time.sleep(0.001) print(f"总共处理了 {processed_count} 条错误记录。")# process_large_log('large_log.txt')
分块读取（二进制文件或非结构化文本文件）： 对于二进制文件，或者那些不以行为单位分割的文本文件（例如大型JSON或XML，虽然它们通常有专门的解析库），我们可以指定每次读取固定大小的块。
# 示例：分块读取一个大二进制文件def copy_large_binary(source_path, dest_path, chunk_size=4096): # 4KB with open(source_path, 'rb') as src, open(dest_path, 'wb') as dest: while True: chunk = src.read(chunk_size) if not chunk: # 读取到文件末尾 break dest.write(chunk) print(f"文件从 {source_path} 复制到 {dest_path} 完成。")# copy_large_binary('very_large_video.mp4', 'copied_video.mp4')
这种方式可以有效地控制内存使用，特别适合文件复制、哈希计算等场景。
使用
mmap
模块（内存映射文件）： 在某些操作系统上，可以使用
mmap
模块将文件的一部分或全部映射到进程的虚拟内存空间。这使得文件操作看起来就像操作内存中的字节数组一样，可以随机访问文件中的任何位置，而无需将整个文件加载到物理内存。操作系统会负责按需加载文件页。这对于需要频繁随机读写大文件的场景非常有用，但它有其平台依赖性和复杂性。
import mmapimport os# 假设有一个大文件 'data.bin'# with open('data.bin', 'wb') as f:# f.write(os.urandom(1024 * 1024 * 100)) # 写入100MB随机数据try: with open('data.bin', 'r+b') as f: # r+b 读写二进制模式 # mmap.ACCESS_READ 表示只读映射 # mmap.ACCESS_WRITE 表示可写映射，但修改不会同步到磁盘 # mmap.ACCESS_COPY 表示私有拷贝，修改不会影响原文件 mm = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ) # 现在可以像操作字节串一样操作mm print(f"文件大小: {len(mm)} 字节") print(f"前10个字节: {mm[:10]}") print(f"从第100000个字节开始的5个字节: {mm[100000:100005]}") mm.close()except FileNotFoundError: print("文件 'data.bin' 未找到，请先创建一个大文件。")except Exception as e: print(f"mmap操作出错: {e}")
mmap
虽然强大，但使用时需要更小心，特别是涉及到跨平台兼容性和同步问题。
文件操作中常见的错误和陷阱有哪些，如何避免？
在我的经验中，文件操作虽然看似简单，但稍不留神就会掉进坑里。以下是一些常见的错误和我的应对之道：
忘记关闭文件句柄（或资源泄露）：这是最常见也最危险的错误。如果打开文件后忘记
f.close()
，尤其是在循环或异常处理中，会导致文件句柄耗尽、文件锁定、数据丢失等问题。
避免方法： 始终使用
with open(...) as f:
语句。
with
语句会确保文件在代码块执行完毕后（无论是否发生异常）自动关闭，极大简化了资源管理。我的所有代码示例都体现了这一点。
FileNotFoundError
：文件不存在当尝试打开一个不存在的文件进行读取时，会抛出此错误。
避免方法： 在尝试读取前，可以使用
os.path.exists(filepath)
来检查文件是否存在。或者，更推荐的方式是使用
try-except FileNotFoundError
块来优雅地处理这种情况，给用户友好的提示。
PermissionError
：权限不足当程序尝试在没有足够权限的目录下创建、写入或读取文件时，会发生此错误。例如，尝试写入C盘根目录或
/root
目录。
避免方法： 确保程序运行的用户拥有目标文件或目录的相应权限。在生产环境中，不要使用root或管理员权限运行不必要的程序。在开发时，注意文件路径的选择。
UnicodeDecodeError
/
UnicodeEncodeError
：编码问题这是处理文本文件时最让人头疼的问题。当读取一个文件时，如果指定的
encoding
与文件的实际编码不符，或者写入时，字符串中包含无法用指定编码表示的字符，就会出现这些错误。
避免方法：读取时： 尽可能明确指定
encoding='utf-8'
，因为UTF-8是目前最通用的编码。如果仍报错，可以尝试
encoding='gbk'
或其他常见编码。如果实在不确定，可以尝试
errors='ignore'
或
errors='replace'
（但这会丢失数据，不推荐用于关键数据）。更好的做法是，尝试使用
chardet
等库来猜测文件编码，但它并非100%准确。写入时： 同样明确指定
encoding='utf-8'
。确保要写入的字符串只包含该编码支持的字符。
模式选择错误：例如，用
'r'
模式打开文件后尝试写入，或者用
'w'
模式打开后期望保留原有内容。
避免方法： 仔细检查
open()
函数的模式参数：
'r'
：只读（默认）。
'w'
：只写，如果文件存在则覆盖，不存在则创建。
'a'
：追加，如果文件存在则在末尾写入，不存在则创建。
'x'
：独占创建，如果文件已存在则会报错。
'r+'
：读写，文件必须存在。
'w+'
：读写，如果文件存在则覆盖，不存在则创建。
'a+'
：读写，在文件末尾追加。二进制模式则在上述模式后加上
'b'
，如
'rb'
,
'wb'
,
'r+b'
。
缓冲区（Buffering）问题：写入文件时，数据通常不会立即写入磁盘，而是先存储在内存缓冲区中。这提高了I/O效率，但也意味着程序崩溃时，缓冲区中的数据可能丢失。
避免方法：使用
f.flush()
强制将缓冲区内容写入磁盘。使用
os.fsync(f.fileno())
（更强力的同步，确保数据写入物理存储）。当然，
with open(...)
会在文件关闭时自动
flush
，所以大部分情况下无需手动处理。但在需要高度数据一致性的场景（如数据库事务日志），可能需要考虑手动刷新。
总之，文件操作需要细心，多用
try-except
处理潜在错误，并始终记住
with
语句是你的好朋友。
以上就是如何读写文本文件和二进制文件？的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1369748.html
微信扫一扫 
支付宝扫一扫 
