В документе, сохраненном с помощью блокнота, удалены разрывы строк
283
BunnyKnitter
Происходит очень странная ситуация:
(Работает под управлением Windows 7 Enterprise, SP1, 64bit)
Графический интерфейс, который я использую на работе (создан специально для этой цели и предназначен для работы в среде Windows), создает файлы .dat. Мне нужно немного отредактировать один, прежде чем я его использую. Я открываю его в простом старом блокноте, редактирую и сохраняю (все выглядит хорошо). Когда я снова открываю его с какой-либо программой (Notepad, Notepad ++ и т. Д.), Все «новые строки» / «вводы» / разрывы строк удаляются - все кажется перемешанным в одну длинную строку.
Если я просто открою его и закрою в блокноте без сохранения, ничего не изменится, и разрывы строк окажутся там, где они должны быть. Открытие документа в Notepad ++ или другой программе и сохранение его не влияет на разрывы строк. Копирование содержимого в Notepad ++ и обратно в Блокнот также устраняет эту проблему - последующее сохранение в Блокноте не разрушает разрывы строк.
Что делает эту проблему еще более неловкой, так это то, что это поведение не относится ко ВСЕМ файлам .dat, которые создает мой графический интерфейс. Просто некоторые из них.
Есть хорошие идеи о том, что происходит и как это исправить?
Если решение этой проблемы состоит в том, чтобы изменить способ, которым мой GUI создает файлы, то это приемлемый ответ, поскольку GUI - это то, для чего я могу представить отчет об ошибке.
Однако ... это кажется маловероятным, поскольку я не думаю, что у моего босса когда-либо была такая проблема, и он использует одну и ту же версию графического интерфейса и блокнота, чтобы внести небольшие изменения в файлы. У меня также было это только недавно и противоречиво: файл, у которого была эта проблема ранее, НЕ теряет разрывы строк при сохранении с помощью Блокнота в этой текущей итерации файлов.
Редактировать: больше информации: я отправил файл своему боссу и заставил его открыть и сохранить с помощью Блокнота на своем компьютере, и ничего странного не произошло - все разрывы строк остались после сохранения, закрытия и повторного открытия. Либо процесс отправки исправил что-то в файле, либо это что-то смешное с моим компьютером.
Глядя на гекс сохраненных и несохраненных файлов: насколько я могу судить, несохраненная версия имеет 0D0A между строками, а в сохраненной версии отсутствуют все экземпляры 0D0A, за исключением одного экземпляра в самом конце (интересно, было ли это добавлено Notepad ++ при открытии / преобразовании файла).
Отредактируйте снова: шестнадцатеричная версия "несохраненного" файла после редактирования конфиденциальной информации:
Некоторый фон мог бы помочь. Блокнот требует, чтобы файл содержал оба <CR><LF>, чтобы определить, что это конец строки и выполнить разрыв строки. Если какой-либо из этих символов отсутствует, он пропустит их и отобразит все в одной строке. <CR><LF>является стандартной последовательностью разрыва строки на компьютерах с DOS / Windows, тогда как Unix / Linux и ее производные используют в <LF>качестве разрыва строки. Скорее всего, файл, который вы открываете, находится только <LF>в нем, поэтому блокнот не может отобразить его правильно.
Скорее всего, эти файлы были созданы программой, которая не соответствует соглашениям Windows / DOS для форматирования текста. Если это предназначено только для запуска в Windows, я думаю, что отчет об ошибках в порядке, особенно если файлы должны редактироваться в блокноте.
А пока я рекомендую открывать и редактировать файлы только в Notepad ++.
Если вы хотите отладить проблему, загрузите шестнадцатеричный редактор, чтобы увидеть, что содержится в конце строки. Для правильного форматирования окон он должен содержать шестнадцатеричные коды 0d 0a. Если или отсутствует, или в другом порядке, это создаст проблему. Попробуйте это для нового файла, который никогда не был сохранен из блокнота и который есть.
Windows - единственная платформа, на которой она когда-либо работала. Я считал плохое кодирование, но меня беспокоит несоответствие. Я сгенерировал тот же набор файлов несколько недель назад, и у «File1.dat» была эта проблема. Теперь я сгенерировал больше файлов сегодня, и «File2.dat» имеет эту проблему, а «File1.dat» нет. В это время не произошло никаких обновлений в моем графическом интерфейсе. Я использую тот же компьютер.
BunnyKnitter 7 лет назад
0
Кроме того, если есть проблема с кодировкой, не будет ли это показывать отсутствие разрывов строк с самого начала? Первоначально открытие файла работает нормально, его сохранение в блокноте приводит к путанице.
BunnyKnitter 7 лет назад
0
Добавил некоторую отладочную информацию в исходное сообщение
RayG 7 лет назад
0
Насколько я могу судить, несохраненная версия имеет 0d 0a между строками, а в сохраненной версии отсутствуют и 0d, и 0a. (используя некоторый онлайн-редактор hex и вставив мой текст - не могу установить случайные программы на мою рабочую композицию.)
BunnyKnitter 7 лет назад
0
Без фактического просмотра файла в шестнадцатеричном редакторе вы не можете быть уверены. Весь файл должен быть правильно отформатирован, если хотя бы одна строка неверна, блокнот может сделать что-то странное. Если вы можете получить файл на другой компьютер, который вы можете просмотреть в шестнадцатеричном формате, то это поможет.
RayG 7 лет назад
0
Ой. Блокнот ++ можно конвертировать в шестнадцатеричный формат. Повторная проверка: в сохраненной версии отсутствуют все экземпляры «0D0A», кроме одного экземпляра в самом конце файла. Несохраненная версия имеет много экземпляров 0D0A, предположительно соответствующих каждому переносу строки.
BunnyKnitter 7 лет назад
0
Насколько большой оригинальный файл?
RayG 7 лет назад
0
всего несколько кб. это небольшой текстовый файл. Я мог бы, вероятно, отредактировать всю конфиденциальную информацию, но ... я не знаю, как я мог бы сохранить ее для отправки "несохраненной" версии.
BunnyKnitter 7 лет назад
0
@SnyperBunny Если содержимое файла помещается на одном экране в шестнадцатеричном виде, возможно, вы можете просто отредактировать конфиденциальную информацию, а затем сделать снимок экрана шестнадцатеричного представления без сохранения. Сделайте это на только что созданном файле .dat, чтобы он не изменился, кроме изменений, которые вы сделали.
RayG 7 лет назад
0
Я добавил шестнадцатеричный код в основной пост с вопросом.
BunnyKnitter 7 лет назад
0
Этот шаблон может вызывать проблему: 0D0D0A
RayG 7 лет назад
0
Я считаю, что паттерн 0d0d0a - это проблема, и Блокнот их убирает. Два ``подряд не имеет смысла, он избыточен и не соответствует стандарту Windows. Обратите внимание, что есть правильное`в конце после сохранения, что является доказательством того, что Блокнот воспринимает весь исходный текст как одну длинную строку, пропуская и удаляя управляющие символы, как вы описали в исходном посте. Вам нужно исправить программу, которая генерирует текст с двумя CR подряд.
RayG 7 лет назад
1
@SnyperBunny Если у вас есть доступ к коду, ищите строки, которые выглядят следующим образом: `" Это строка текста \ r "` Обратная косая черта r не понадобится.
RayG 7 лет назад
0
У меня нет доступа к коду, который генерирует файлы, к сожалению. Чего я не могу понять, так это того, почему эта проблема будет противоречивой. Почему этот файл был сломан на этот раз, когда другой файл был сломан ранее, и когда «нормально», это не проблема с ЛЮБЫМИ файлами.
BunnyKnitter 7 лет назад
0
@SnyperBunny Я не могу ответить на этот вопрос, не увидев код, который генерирует файлы. Некоторые программы могут быть несовместимы в том, как они добавляют строки в файл. Блокнот не прощает плохо отформатированных строк, в то время как другие редакторы могут справиться с этим. К сожалению, это все, что я могу предложить по этой теме.
RayG 7 лет назад
0