Использование str.splitlines()
.
splitlines()
правильно обрабатывает переводы строк, в отличие от split("\n")
.
Он также имеет преимущество, упомянутое @efotinis, заключающееся в необязательном включении символа новой строки в результат разделения при вызове с аргументом True
.
Подробное объяснение того, почему вы не должны использовать split("\n")
:
\n
в Python представляет разрыв строки Unix (десятичный код ASCII 10) независимо от платформы, на которой вы его запускаете. Однако представление переноса строки зависит от платформы . В Windows \n
- это два символа, CR
и LF
(десятичные коды ASCII 13 и 10, AKA \r
и \n
), в то время как в любом современном Unix (включая OS X) это один символ LF
.
print
, например, работает правильно, даже если у вас есть строка с окончаниями строки, которые не соответствуют вашей платформе:
>>> print " a \n b \r\n c "
a
b
c
Однако явное разбиение на «\ n» приведет к зависимому от платформы поведению:
>>> " a \n b \r\n c ".split("\n")
[' a ', ' b \r', ' c ']
Даже если вы используете os.linesep
, оно будет разделяться только в соответствии с разделителем новой строки на вашей платформе и завершится ошибкой, если вы обрабатываете текст, созданный на других платформах, или с использованием \n
:
>>> " a \n b \r\n c ".split(os.linesep)
[' a \n b ', ' c ']
splitlines
решает все эти проблемы:
>>> " a \n b \r\n c ".splitlines()
[' a ', ' b ', ' c ']
Чтение файлов в текстовом режиме частично смягчает проблему представления новой строки, поскольку она преобразует Python \n
в представление новой строки платформы.
Однако текстовый режим существует только в Windows. В системах Unix все файлы открываются в двоичном режиме, поэтому использование split('\n')
в системе UNIX с файлом Windows приведет к нежелательному поведению. Кроме того, нет ничего необычного в том, чтобы обрабатывать строки с потенциально новыми символами новой строки из других источников, например из сокета.