Двоичные и текстовые файлы

Во всех предыдущих примерах обрабатываются простые текстовые файлы, но сценарии на языке Python могут также открывать и обрабатывать файлы, содержащие двоичные данные - изображения JPEG, аудиоклипы, упакованные двоичные данные, произведенные программами на языке FORTRAN и C, кодированный текст и все остальное, что может храниться в файлах в виде последовательностей байтов. Главное отличие для программного кода заключается в аргументе режима, передаваемом встроенной функции open:

>>> file = open('data.txt', 'wb') # откроет двоичный файл для записи >>> file = open('data.txt', 'rb') # откроет двоичный файл для чтения

После открытия двоичных файлов таким способом можно читать и записывать их содержимое с помощью представленных выше методов: read, write и так далее. Методы readline и readlines, как и построчные итераторы файлов, по-прежнему будут работать с текстовыми файлами, открытыми в двоичном режиме, но нет никакого смысла применять их к действительно двоичным данным, которые не имеют построчной организации (байты, обозначающие конец строки в текстовых данных, не имеют такого смысла в двоичных данных, да и вообще их может не быть в файле).

Во всех случаях данные, перемещаемые между файлами и программами, представляются в сценариях в виде строк Python, даже если они являются двоичными. Однако для файлов, открытых в двоичном режиме, содержимое файла будет представлено в виде строк байтов. Продолжим предыдущий пример:

>>> open('data.txt').read()    # текстовый режим: тип str

‘Hello file world!\nBye file world.\nThe Life of Brian’

>>> open('data.txt', 'rb').read() # двоичный режим: тип bytes b’Hello file world!\r\nBye file world.\r\nThe Life of Brian’

>>> file = open('data.txt', 'rb’)

>>> for line in file: print(line)

b’Hello file world!\r\n’ b’Bye file world.\r\n’ b’The Life of Brian’

Это обусловлено тем, что в Python 3.X содержимое текстовых файлов интерпретируется, как последовательность символов Юникода, которая автоматически декодируется при чтении и кодируется при записи.

Содержимое файлов, открытых в двоичном режиме, напротив, доступно в виде простых строк байтов, для которых никаких промежуточных преобразований не выполняется, - они содержат именно то, что хранится в файле. В Python 3.X строки типа str всегда содержат символы Юникода, поэтому для представления двоичных данных потребовалось ввести специальный строковый тип bytes, представляющий последовательность однобайтовых целых чисел, которые могут иметь любые 8-битовые значения. Обычные строки и строки байтов обладают практически идентичными наборами операций, поэтому различия между ними в большинстве случаев незаметны, но имейте в виду, что действительно двоичные файлы для чтения должны открываться в двоичном режиме, потому что они могут содержать данные, которые невозможно будет декодировать в текст Юникода.

Точно так же при выводе в двоичные файлы необходимо использовать строки байтов, потому что обычные строки интерпретируются не как двоичные данные, а как декодированные символы Юникода (то есть кодовые пункты), которые должны быть закодированы в двоичное представление при записи в файл в двоичном или текстовом режиме:

>>> open('data.bin', 'wb').write(b'Spam\n')

5

>>> open('data.bin', 'rb').read()

b’Spam\n’

>>> open('data.bin', 'wb').write('spam\n')

TypeError: must be bytes or buffer, not str

(TypeError: аргумент должен иметь тип bytes или buffer, но не str)

Но обратите внимание, что в данном примере строки завершаются символом \n вместо последовательности \r\n, принятой в Windows, которая присутствовала в предыдущем примере работы с текстовым файлом в двоичном режиме. Строго говоря, двоичный режим запрещает не только кодирование символов Юникода, но и автоматическое преобразование символов конца строки, которые по умолчанию выполняются для файлов, открытых в текстовом режиме. Но прежде чем нам удастся полностью с этим разобраться, необходимо познакомиться с двумя основными отличиями между текстовыми и двоичными файлами.

Кодирование символов Юникода в текстовых файлах

Как упоминалось выше, объекты файлов, открытые в текстовом режиме, при передаче данных между программой и внешним файлом всегда преобразуют данные в соответствии с кодировкой по умолчанию или указанной явно. При записи в файл выполняется кодирование данных, а при чтении - декодирование. Для файлов, открытых в двоичном режиме, никаких преобразований не выполняется, потому что именно это и требуется для действительно двоичных данных. Например, взгляните на следующую строку, содержащую символ Юникода, двоичное представление которого выходит за рамки 7-битового диапазона представления символов ASCII:

>>> data = 'sp\xe4m'

>>> data

‘spam’

>>> 0xe4, bin(0xe4), chr(0xe4)

(228, ‘0b11100100’, ‘a’)

Эту строку можно закодировать вручную в соответствии с той или иной кодировкой, и для разных кодировок будут получаться различные двоичные представления строки:

>>> data.encode('latin1') # 8-битовые символы: ascii + дополнительные b’sp\xe4m’

>>> data.encode('utf8')    # 2 байта отводится только

b’sp\xc3\xa4m’    # для специальных символов

>>> data.encode('ascii')    # кодирование в ascii невозможно

UnicodeEncodeError: ‘ascii’ codec can’t encode character ‘\xe4’ in position 2: ordinal not in range(128)

(UnicodeEncodeError: кодек ‘ascii’ не может преобразовать символ ‘\xe4’ в позиции 2: число выходит за пределы range(128) )

Интерпретатор Python отображает печатаемые символы в таких строках как обычно, а непечатаемые - в виде шестнадцатеричных экранированных значений \xNN, количество которых увеличивается при использовании некоторых более сложных схем кодирования (cp500 в следующем примере - это кодировка EBCDIC):

>>> data.encode('utf16')    # по 2 байта на символ плюс преамбула

b’\xff\xfes\x00p\x00\xe4\x00m\x00’

>>> data.encode('cp500')    # кодировка ebcdic: двоичное представление

b’\xa2\x97C\x94’    # строки существенно отличается

Результат кодирования здесь отражает двоичное представление строки, которое будет записано в файл при сохранении. Однако выполнять кодирование вручную обычно не требуется, потому что для текстовых файлов кодирование выполняется автоматически при передаче данных - данные декодируются при чтении и кодируются при записи, в соответствии с именем указанной кодировки (или с использованием кодировки, используемой на текущей платформе: смотрите описание функции sys.getdefaultencoding). Продолжим интерактивный сеанс:

>>> open('data.txt', 'w', encoding='latin1').write(data)

4

>>> open('data.txt', 'r', encoding='latin1').read()

‘spam’

>>> open('data.txt', 'rb').read()

b’sp\xe4m’

Если файл открыть в двоичном режиме, никаких преобразований производиться не будет - последняя инструкция в предыдущем примере предъявляет в точности то, что хранится в файле. Чтобы увидеть отличия при использовании других кодировок, сохраним эту строку еще раз:

>>> open('data.txt', 'w', encoding='utf8').write(data) # кодировка utf8 4

>>> open('data.txt',    'r',    encoding='utf8').read()    # декодирование: отменяет

‘spam’    #    кодирование

>>> open('data.txt',    'rb').read()    #    преобразование

b’sp\xc3\xa4m’    #    не производится

На этот раз двоичное содержимое файла получилось другим, но в результате автоматического декодирования, которое выполняется при чтении файла в текстовом режиме, возвращается та же самая строка. В действительности, кодировка имеет значение для строк, только когда они находятся в файлах, - сразу после загрузки в память строки превращаются в простые последовательности символов Юникода («кодовые пункты»). Этот этап преобразования желателен для текстовых файлов, но не для двоичных. При использовании двоичных режимов этап преобразования содержимого пропускается, поэтому при работе с истинно двоичными данными необходимо использовать эти режимы. Если вам нужны доказательства, попробуйте сами: попытка записать или прочитать недекодируемые данные в текстовом режиме приведет к появлению ошибки:

>>> open('data.txt', 'w’, encoding='ascii').write(data)

UnicodeEncodeError: ‘ascii’ codec can’t encode character ‘\xe4’ in position 2: ordinal not in range(128)

(UnicodeEncodeError: кодек ‘ascii’ не может преобразовать символ '\xe4' в позиции 2: число выходит за пределы range(128) )

>>> open(r'C:\Python31\python.exe', 'r').read()

UnicodeDecodeError: ‘charmap’ codec can’t decode byte 0x90 in position 2: character maps to <undefined>

(UnicodeDecodeError: кодек ‘charmap’ не может преобразовать байт 0x90 в позиции 2: символ отображается в символ <undefined> )

Двоичный режим можно также рассматривать, как последний шанс прочитать текстовый файл, если он не может быть декодирован с использованием кодировки по умолчанию, а кодировка файла неизвестна. Следующий программный код воссоздает оригинальные строки, когда кодировка известна, но терпит неудачу, когда она неизвестна, если только не использовать двоичный режим (такие ошибки могут возникать как при чтении данных, так и при записи, но в любом случае программный код терпит неудачу):

>>> open('data.txt', 'w’, encoding='cp500').writelines(['spam\n', 'ham\n'])

>>> open('data.txt', 'r’, encoding='cp500').readlines() [‘spam\n’, ‘ham\n’]

>>> open('data.txt', 'r').readlines()

UnicodeDecodeError: ‘charmap’ codec can’t decode byte 0x81 in position 2: character maps to <undefined>

(UnicodeDecodeError: кодек ‘charmap’ не может преобразовать байт 0x81 в позиции 2: символ отображается в символ <undefined> )

>>> open('data.txt', 'rb').readlines()

[b’\xa2\x97\x81\x94\r%\x88\x81\x94\r%’]

>>> open('data.txt', 'rb').read()

b’\xa2\x97\x81\x94\r%\x88\x81\x94\r%’

Если вы имеете дело только с текстом ASCII, вы можете пропустить все, что связано с кодировками, - данные в файлах будут один-в-один отображаться в символы в строках, потому что ASCII является подмножеством большинства кодировок, используемых по умолчанию. Если вам приходится обрабатывать файлы, созданные с применением других кодировок, и, возможно, на других платформах (например, файлы, полученные из Интернета), вам может потребоваться использовать двоичный режим, если кодировка заранее не известна. Однако имейте в виду, что текст в кодированном двоичном представлении не может обрабатываться так, как вам хотелось бы: текст, закодированный с применением определенной кодировки, не может сравниваться или объединяться с текстом, закодированным с применением других кодировок.

И снова за дополнительной информацией о Юникоде обращайтесь к другим ресурсам. Мы еще не раз будем возвращаться к теме Юникода в этой книге: в главе 9 будет показано, какое влияние оказывает Юникод на виджет Text из библиотеки tkinter, а в части IV, охватывающей вопросы программирования для Интернета, мы узнаем, как это отражается на данных, доставляемых по сети с использованием протоколов FTP, электронной почты и в Интернете в целом. Текстовые файлы обладают еще одной особенностью, отсутствующей у двоичных файлов: преобразование символов конца строки, что является темой следующего раздела.

Преобразование символов конца строки в Windows

По историческим причинам конец строки текста в файле представляется на разных платформах различными символами. В Unix и Linux -это одиночный символ \n, а в Windows - это последовательность из двух символов \r\n. В результате файлы, перемещаемые между Linux и Windows, могут после передачи странно выглядеть в текстовом редакторе - они могут сохранить окончание строки, принятое на исходной платформе.

Например, большинство текстовых редакторов для Windows обрабатывает текст в формате Unix, но Блокнот (Notepad) составляет заметное исключение - текстовые файлы, скопированные из Unix или Linux, обычно выглядят в Блокноте, как одна большая строка со странными символами внутри (\n). Точно так же при копировании файлов из Windows в Unix в двоичном режиме в них сохраняется символ \r (который в текстовых редакторах часто отображается как ^M).

Сценариям на языке Python это обычно безразлично, потому что объекты файлов автоматически отображают последовательность DOS \r\n в одиночный символ \n. При выполнении сценариев в Windows это действует так:

•    Для файлов, открытых в текстовом режиме, при чтении \r\n преобразуется в \n.

•    Для файлов, открытых в текстовом режиме, при записи \n преобразуется в \r\n.

•    Для файлов, открытых в двоичном режиме, никакие преобразования не производятся.

В Unix-подобных системах преобразование не производится в любом режиме, потому что в файлах используется символ \n. Следует запомнить два важных следствия из этих правил. Во-первых, почти всегда во всех сценариях на языке Python символ конца строки представляется одиночным \n, независимо от способа его сохранения во внешних файлах на соответствующей платформе. Путем соответствующего преобразования \n при чтении и записи Python скрывает присущие платформам различия.

Второе следствие из этого преобразования более тонкое: при обработке двоичных файлов использование двоичного режима (например, rb, wb) отключает механизм преобразования символов конца строки. Если выбрать неправильный режим, указанные преобразования вполне могут повредить данные, как при чтении, так и при записи, - случайно оказавшиеся среди двоичных данных байты \r могут быть ошибочно отброшены при чтении или ошибочно добавлены к байтам \n при записи. В итоге двоичные данные окажутся искаженными, что, вероятно, совсем не то, что вам хотелось бы получить при работе с изображениями или аудиоклипами!

В Python 3.X эта проблема ушла на задний план, потому что мы в принципе не можем использовать двоичные данные с файлами, открытыми в текстовом режиме, из-за того, что текстовый режим предполагает автоматическое применение кодировок Юникода к содержимому файлов. Операции чтения и записи просто будут терпеть неудачу, если данные не смогут быть декодированы при чтении или закодированы при записи. Использование двоичного режима позволяет избежать ошибок, связанных с преобразованием Юникода, и автоматически запрещает преобразование символов конца строки как таковое (ошибки, связанные с преобразованием Юникода, можно было бы перехватывать в инструкции try). Итак, стоит запомнить как отдельный факт, что двоичный ре-

жим предохраняет двоичные данные от искажения в результате преобразования символов конца строки, особенно если вы работаете только с текстовыми данными ASCII, когда можно смело забыть обо всех проблемах, связанных с Юникодом.

Ниже демонстрируется действие механизма преобразования символов конца строки в Python 3.1 в Windows - объект файла, открытого в текстовом режиме, выполняет преобразование символов конца строки и обеспечивает переносимость наших сценариев:

>>> open('temp.txt', 'w').write('shrubbery\n') # запись в текстовом режиме:

10    # \n -> \r\n

>>> open('temp.txt', 'rb').read()    # чтение двоичных данных:

b’shrubbery\r\n’    # фактические байты из файла

>>> open('temp.txt', 'r').read()    # проверка чтением: \r\n -> \n

‘shrubbery\n’

При записи в двоичном режиме, напротив, предотвращаются любые преобразования, как и предполагалось, даже когда данные содержат байты, которые в текстовом режиме интерпретировались бы как часть символов конца строки (при выводе строк байтов отдельные байты выводятся как символы ASCII, если они соответствуют печатаемым символам, и как экранированные шестнадцатеричные последовательности в противном случае):

>>> data = b'a\0b\rc\r\nd'    # 4 байта, 4 обычных символа

>>> len(data)

8

>>> open('temp.bin', 'wb').write(data) # запись двоичных данных как есть 8

>>> open('temp.bin', 'rb').read() # чтение двоичных данных: b’a\x00b\rc\r\nd’    # без преобразования

Но при чтении двоичных данных в текстовом режиме, неважно, случайно или нет, механизм преобразования символов конца строки может повредить данные (предполагая, что вообще при декодировании не возникло ошибок, как с нашими ASCII-данными на платформе Windows):

>>> open('temp.bin', 'r').read() # чтение в текстовом режиме: искажены \r! ‘a\x00b\nc\nd’

Тот же эффект может возникнуть при записи двоичных данных в текстовом режиме - могут изменяться или вставляться байты, значения которых совпадают с символами конца строки (и снова имеются в виду данные, успешно прошедшие этап кодирования в кодировку по умолчанию для текущей платформы):

>>> open('temp.bin', 'w').write(data) # в текстовом режиме должна TypeError: must be str, not bytes # передаваться строка типа str

#    используйте bytes.decode()

#    для преобразования типа

>>> data.decode()

‘a\x00b\rc\r\nd’

>>> open('temp.bin', 'w').write(data.decode())

8

>>> open('temp.bin', 'rb').read() # запись в текстовом режиме: добавит \r b’a\x00b\rc\r\r\nd’

>>> open('temp.bin', 'r').read()    # опять искажение, изменит \r

‘a\x00b\nc\n\nd’

Проще говоря, запомните, что во всех текстовых файлах при определении конца строки следует ориентироваться на символ \n, а двоичные файлы всегда должны открываться в двоичном режиме, чтобы предотвратить преобразование символов конца строки и кодирование/ декодирование символов Юникода. Вообще тип содержимого файла определяется режимом его открытия, а режимы открытия определяют способы обработки содержимого, что в точности соответствует нашим желаниям.

Однако следует понимать, что в особых случаях может потребоваться открывать текстовые файлы в двоичном режиме. Так, в примерах из главы 6 мы иногда будем использовать двоичный режим для текстовых файлов, чтобы избежать возможных ошибок декодирования в Юникод при работе с файлами, созданными на разных платформах, где могут использоваться различные кодировки. Данный прием позволяет избежать ошибок кодирования, но при этом некоторые операции с текстом могут выполняться не так, как предполагается, - поиск в таком двоичном тексте не всегда может давать точные результаты, потому что искомый ключ также придется преобразовать в строку байтов в соответствии с некоторой кодировкой, возможно, несовместимой с кодировкой текста в файле.

В примере текстового редактора PyEdit, в главе 11, нам также потребуется перехватывать исключения, вызванные ошибками преобразования Юникода в утилите поиска «grep» по файлам в каталоге, и мы пойдем еще дальше, позволив пользователю определять кодировку символов содержимого файлов для целого дерева каталогов. Кроме того, когда необходимо явно выполнить преобразование символов конца строки в соответствии с соглашениями для двух разных платформ, может потребоваться прочитать текст в двоичном режиме, чтобы сохранить оригинальное представление концов строк, - при открытии в текстовом режиме они могут оказаться преобразованными в \n к моменту, когда данные попадут в сценарий.

Имеется также возможность запретить преобразование символов конца строки в текстовом режиме с помощью дополнительных аргументов функции open, которые мы не будем рассматривать здесь. Подробности ищите в описании аргумента newline в справочной документации по функции open, но, в двух словах: если в этом аргументе передать пустую строку, это предотвратит преобразование символов конца строки и сохранит остальные особенности поведения текстового режима. Теперь обратимся к следующим двум типичным случаям использования двоичных файлов: работа с упакованными двоичными данными и произвольный доступ.

Работа с упакованными двоичными данными с помощью модуля struct

Используя символ b в аргументе режима функции open, вы получаете возможность открывать двоичные файлы с данными платформонезависимым способом, а также читать и записывать их содержимое с помощью обычных методов объекта файла. Но как обрабатывать двоичные данные после того, как они будут прочитаны? Эти данные будут возвращены сценарию в виде простой строки байтов, большая часть из которых наверняка будет соответствовать непечатаемым символам.

Если нужно лишь переписать двоичные данные в другой файл или передать другой программе, тогда все просто - достаточно записать строку байтов в другой файл, открытый в двоичном режиме. Если потребуется извлечь некоторое количество байтов из определенной позиции, можно воспользоваться операцией извлечения среза строки. При необходимости можно даже использовать битовые операции. Кроме того, имеется мощный инструмент, позволяющий получить двоичные данные в структурированном виде или сконструировать их, - модуль struct из стандартной библиотеки.

В модуле struct имеются функции для упаковывания и распаковывания двоичных данных, как если бы данные были созданы с помощью объявления struct языка C. Имеется возможность при упаковывании и распаковывании данных учитывать прямой или обратный порядок следования байтов (порядок следования байтов определяет, где будут находиться старшие значимые биты в двоичном представлении чисел, - слева или справа). Создание двоичного файла с данными, например, - достаточно простая задача: нужно упаковать значения языка Python в строку байтов и записать ее в файл. Строка формата в вызове pack ниже определяет: прямой порядок следования байтов (>), целое число, 4-символьную строку, короткое целое число и вещественное число:

>>> import struct

>>> data = struct.pack('>i4shf', 2, 'spam’, 3, 1.234)

>>> data

b’\x00\x00\x00\x02spam\x00\x03?\x9d\xf3\xb6’

>>> file = open('data.bin’, 'wb’)

>>> file.write(data)

14

>>> file.close()

Обратите внимание, что модуль struct возвращает строку байтов: сейчас мы находимся в царстве двоичных данных, а не текста, и для сохранения должны использовать двоичные файлы. Как обычно, интерпретатор отображает большую часть байтов с упакованными двоичными данными, которые не соответствуют печатаемым символам, в виде шестнадцатеричных экранированных последовательностей \xNN. Чтобы выполнить обратное преобразование этих данных, нужно прочитать их из файла и передать модулю struct с той же строкой формата, как и при создании, - в результате получится кортеж значений, полученных в результате анализа строки байтов и преобразованных в объекты языка Python:

>>> import struct

>>> file = open('data.bin’, 'rb’)

>>> data = file.read()

>>> values = struct.unpack('>i4shf’, data)

>>> values

(2, b’spam’, 3, 1.2339999675750732)

Анализируемые строки - это также строки байтов, и к ним допускается применять строковые и битовые операции для более глубокого анализа:

>>> bin(values[0] | 0b1)    # доступ к битам и байтам

‘0b11’

>>> values[1], list(values[1]), values[1][0]

(b’spam’, [115, 112, 97, 109], 115)

Обратите также внимание, что здесь может пригодиться операция извлечения среза. 4-символьную строку из середины только что прочитанных упакованных двоичных данных легко получить, используя операцию извлечения среза. Числовые значения также можно извлекать подобным способом и передавать функции struct.unpack для преобразования:

>>> data

b’\x00\x00\x00\x02spam\x00\x03?\x9d\xf3\xb6’

>>> data[4:8]

b’spam’

>>> number = data[8:10]

>>> number

b’\x00\x03’

>>> struct.unpack('>h’, number)

(3,)

Упакованные двоичные данные бывают получены из самых разных контекстов, включая некоторые виды сетевых взаимодействий и представление данных другими языками программирования. Однако все это не относится к разряду повседневных задач программирования, поэтому оставим описание подробностей за разделом с описанием модуля struct в руководстве по стандартной библиотеке Python.

Произвольный доступ к данным в файлах

При работе с двоичными файлами часто также применяется операция произвольного доступа. Ранее упоминалось, что добавление символа + в строку режима открытия файла позволяет выполнять обе операции, чтения и записи. Этот режим обычно используется вместе с методом seek объектов файлов, позволяющим выполнять чтение/запись произвольных участков файла. Такие гибкие режимы обработки файлов позволяют читать байты из одного места, записывать в другое и так далее. При объединении этих режимов с двоичным режимом появляется возможность извлекать и изменять произвольные байты в файле.

Выше для перехода в начало файла вместо операций закрытия файла и повторного его открытия использовался метод seek. Как уже упоминалось, операции чтения и записи всегда выполняются в текущей позиции в файле. При открытии файлов текущая позиция обычно устанавливается в смещение 0 от начала файла и перемещается вперед по мере чтения/записи данных. Метод seek позволяет переместить текущую позицию для следующей операции чтения/записи в другое место, для чего ему достаточно передать величину смещения в байтах.

Метод seek в языке Python принимает также второй необязательный аргумент, который определяет физический смысл первого аргумента и может принимать одно из трех значений: 0 - абсолютная позиция в файле (по умолчанию), 1 - смещение относительно текущей позиции и 2 - смещение относительно конца файла. Когда методу seek передается только аргумент смещения 0, это соответствует операции перемотки файла в начало (rewind): текущая позиция перемещается в начало файла. Вообще, метод seek поддерживает произвольный доступ на уровне смещения в байтах. Используя в качестве множителя размер записи в двоичном файле, можно организовать доступ к записям по их относительным позициям.

Метод seek можно использовать и без спецификатора + в строке режима для функции open (например, чтобы просто обеспечить произвольное чтение данных), но наибольшая гибкость достигается при работе с файлами, открытыми для чтения и записи. Возможность произвольного доступа поддерживается и для файлов, открытых в текстовом режиме. Но выполняющиеся в текстовом режиме операции кодирования/деко-дирования Юникода и преобразования символов конца строки сильно осложняют вычисление абсолютных смещений в байтах и длин, необходимых методам позиционирования и чтения, - представление ваших данных может значительно измениться при сохранении в файл. Кроме того, применение текстового режима может также ухудшить переносимость данных между платформами, где по умолчанию используются различные кодировки, если только вы не предполагаете всегда явно указывать кодировку файлов. Метод seek лучше подходит для работы с двоичными файлами; исключение составляет простой некодируемый текст ASCII, в котором отсутствуют символы конца строки.

Для демонстрации создадим файл в режиме “w+b” (эквивалент режима ‘wb+’) и запишем в него некоторые данные - этот режим позволяет читать из файла и писать в него и создает новый пустой файл, если он существовал прежде (это относится ко всем режимам “w”). После записи данных мы вернемся в начало файла и прочитаем его содержимое (несколько целочисленных значений, возвращаемых вызовами методов в этом примере, было опущено ради экономии места):

>>> records = [bytes([char] * 8) for char in b’spam’]

>>> records

[b’ssssssss’, b’pppppppp’, b’aaaaaaaa’, b’mmmmmmmm’]

>>> file = open('random.bin’, 'w+b’)

>>> for rec in records:    # запиcать четыре записи

...    size = file.write(rec)    # bytes означает двоичный режим

>>> file.flush()

>>> pos = file.seek(0)    # прочитать файл целиком

>>> print(file.read())

b’ssssssssppppppppaaaaaaaammmmmmmm’

Теперь повторно откроем файл в режиме “r+b” - он также позволяет читать из файла и писать в него, но не очищает файл при открытии. На этот раз мы будем выполнять позиционирование и чтение с учетом размеров элементов данных («записей»), чтобы показать возможность получения и изменения записей в произвольном порядке:

c:\temp> python

>>> file = open('random.bin’, 'r+b’)

>>> print(file.read())    # прочитать файл целиком

b’ssssssssppppppppaaaaaaaammmmmmmm’

>>> record = b’X’ * 8

>>> file.seek(0)    # изменить первую запись

>>> file.write(record)

>>> file.seek(len(record) * 2)    # изменить третью запись

>>> file.write(b’Y’ * 8)

>>> file.seek(8)

>>> file.read(len(record))    # извлечь вторую запись

b’pppppppp’

>>> file.read(len(record))    # извлечь следующую (третью) запись

b’YYYYYYYY’

>>> file.seek(0)    # прочитать файл целиком

>>> file.read()

b’XXXXXXXXppppppppYYYYYYYYmmmmmmmm’

c:\temp> type random.bin    # посмотреть файл за пределами Python

XXXXXXXXppppppppYYYYYYYYmmmmmmmm

Наконец, имейте в виду, что метод seek можно использовать, даже если файл открыт только для чтения. Следующий пример демонстрирует возможность чтения произвольных записей фиксированной длины. Обратите внимание, что при этом используется текстовый режим “г”: поскольку данные представляют собой простой текст ASCII, где каждый символ представлен одним байтом, и текст не содержит символов конца строки, на данной платформе текстовый и двоичный режимы действуют одинаково:

c:\temp> python

>>> file = open('random.bin’, 'r’)    # текстовый режим можно использовать, если

#    не выполняется кодирование и отсутствуют

#    символы конца строки

>>> reclen = 8

>>> file.seek(reclen * 3)    # извлечь четвертую запись

>>> file.read(reclen)

‘mmmmmmmm’

>>> file.seek(reclen * 1)    # извлечь вторую запись

>>> file.read(reclen)

‘pppppppp’

>>> file = open('random.bin’, 'rb’) # в данном случае двоичный режим действует

#    точно так же

>>> file.seek(reclen * 2)    # извлечь третью запись

>>> file.read(reclen)    # вернет строку байтов

b’YYYYYYYY’

Но в общем случае текстовый режим не следует использовать, если вам требуется произвольный доступ к записям (за исключением файлов с простым некодируемым текстом, подобным ASCII, не содержащим символов конца строки). Символы конца строки могут преобразовываться в Windows, а применение кодировок Юникода может вносить различные искажения - оба эти преобразования существенно осложняют возможность позиционирования по абсолютному смещению. Например, в следующем фрагменте соответствие между строкой Python и ее кодированным представлением в файле нарушается сразу же за первым не-ASCII символом:

>>> data = 'sp\xe4m’    # данные в сценарии

>>> data, len(data)    # 4 символа Юникода,

(‘spam’, 4)    # 1 символ не-ASCII

>>> data.encode('utf8’), len(data.encode('utf8’)) # байты для записи в файл (b’sp\xc3\xa4m’, 5)

>>> f = open('test’, mode=’w+’, encoding=’utf8’) # текст. режим, кодирование >>> f.write(data)

>>> f.flush()

>>> f.seek(0); f.read(1)    # работает для байтов ascii

‘s’

>>> f.seek(2); f.read(1)    # 2-байтовый не-ASCII

‘ a’

>>> data[3]    # а в смещении 3 - не ‘m’ !

‘m’

>>> f.seek(3); f.read(1)

UnicodeDecodeError: ‘utf8’ codec can’t decode byte 0xa4 in position 0: unexpected code byte

(UnicodeDecodeError: кодек ‘utf8’ не может преобразовать байт 0xa4 в позиции 0: неопознанный код)

Как видите, режимы открытия файлов в Python обеспечивают необходимую гибкость при работе с файлами в программах. А модуль os предлагает еще более широкие возможности для обработки файлов, которые представлены в следующем разделе.