Следующий ответ частично освещает эту проблему.
Как верно указывает Дж. Эшли, существует разница между тем, как Excel обрабатывает файл CSV при двойном щелчке по сравнению с Файл-> Открыть (или Данные-> Импорт).
В дополнение к замечанию Дж. Эшли я проверил и сделал следующие выводы:
- Когда инкапсулированные поля содержат \ n (LF) или \ r \ n (CR-LF), они открываются правильно при двойном щелчке, но создают проблему, упомянутую OP при использовании File-> Open (или импорт)
- Когда инкапсулированные поля содержат \ r (CR), они вызывают проблему, упомянутую OP, независимо от того, что вы делаете. Использование UTF8-BOM, без Bom, двойной щелчок, Файл-> Открыть, Данные-> Импорт ... всегда одна и та же проблема.
Следовательно, кажется, нет никакого способа обойти эту проблему в Excel.
Возможный обходной путь
Выполните поиск / замену Regex в вашем файле, чтобы заменить '\ r ([^ \ n])' на '\ n \ 1'. Это изменяет все CR, за которыми не следует LF, в LF. \ 1 просто для сохранения завершающего символа.
Заключительные шаги
Excel продолжает удивлять меня таинственными способами того, как произвольно он обрабатывает файлы с плоскими текстовыми данными без обратной связи с пользователем ... Опять же, большинство пользователей будут поражены и смущены тем, что плоские текстовые файлы не являются файлами Excel .
Изменить: скрипт Powershell для поиска замены в огромных файлах
$Utf8NoBomEncoding = New-Object System.Text.UTF8Encoding $False Get-Content -Encoding UTF8 -ReadCount 1000 input.txt | Foreach-Object { [System.IO.File]::AppendAllLines( [string]'output.txt', [string[]]($_) // TODO: add regex replacement here ) }