Notepad зависает при открытии больших файлов
вчера Notepad++ был доступен для запуска, сегодня-нет. Несмотря на notepad++.exe (с его 13 процесса) присутствие диспетчер задач, Блокнот++ окно не запускается.
Я попытался удалить и переустановить программное обеспечение (и первый запуск работает), Блокнот.exe присутствует в C:Windows и C:WindowsSytem32 папки.
Что я могу сделать, пожалуйста ?
Попробуйте удалить файл из C:\Users\\AppData\Roaming\Notepad++\session.xml которая открывает файл при запуске программы.
Если это не работает, может быть, вы должны попробовать полное удаление / переустановка, если вы еще не сделали.
EDIT: найдено решение (спасибо sgmoore): установить автономную версию Notepad++ ( notepad++ портативный).
я столкнулся с той же проблемой, что и вы. Сделайте следующее:
- на C:\Program Files\Notepad++\plugins
- движение LightExplorer.dll до C:\Program Files\Notepad++\plugins\disabled .
если вы не можете найти LightExplorer.dll затем перейти Explorer.dll to C:\Program Files\Notepad++\plugins\disabled
проблема должна быть решена с помощью этого метода.
Я иногда получаю эту проблему тоже, все, что я делаю:
- используйте диспетчер задач, чтобы убить эти процессы np++
- найти NP++ ярлык в меню Пуск, щелкните правой кнопкой мыши и выберите "Запуск от имени администратора" (окно появилось)
- закройте это окно np++, затем откройте его нормально (без администратора) и он работает.
Я предполагаю, что это что-то вроде файла сеанса или плагина, который блокируется или отказывается от доступа и работает как администратор устраняет эту проблему, но я могу ошибаться.
надеюсь, что мое решение работает для вас, и тех, кто испытывает эту проблему.
несмотря на notepad++.ехе (с 13 процесс) присутствие диспетчер задач.
Простите меня, если я не понимаю это утверждение, но вы говорите, что запущено 13 процессов notepad++?
Если это так, я бы сказал, что один из них (вероятно, первый/оригинал) застрял/не отвечает/иначе занят.
убейте все процессы notepad++ и перезапустите приложение. Перезагрузка компьютера должна иметь то же самое эффект.
Не могу открыть файл размером >650М. Это принципиальное ограничение или существуют какие-то пути обойти его?
Не могли бы вы разместить здесь вывод отладочной информации?
Это в последнем меню, в ? меню.
Could you post the output of debug info here?
It is located in the last menu, the ? menu.
@Ekopalypse
Notepad++ v7.9.1 (32-bit)
Build time : Nov 2 2020 - 01:03:56
Path : C:\Program Files (x86)\Notepad++\notepad++.exe
Admin mode : OFF
Local Conf mode : OFF
OS Name : Windows 10 Enterprise (64-bit)
OS Version : 2009
OS Build : 19042.867
Current ANSI codepage : 1251
Plugins : none
You might try the 64-bit version of N++ as it is known to be able to handle larger files.
В 32-битной версии процесс ограничивается лимитом в 4 ГБ, который опять же уменьшается вдвое, так как система резервирует 2 ГБ на процесс.
Но это не означает, что вы можете открывать 2GB файлы, потому что Scintilla выделяет информацию о стиле для каждого байта текста. По моим тестам это примерно 3x размер файла.
Как сказал Алан, 64-битная версия может открывать файлы большего размера.
Я смог открыть файл размером 1.8 ГБ без проблем, но работа с ним может быть затруднена/медлена.
With the 32bit version the process is limited to a 4GB limit which is halved again because the system reserves 2GB per process.
But this does not mean that you can open 2GB files, because Scintilla allocates style information for each byte of text. According to my tests this is about 3x file size.
As Alan said, the 64bit version can open larger files.
I was able to open a 1.8 GB file without any problems, but working with it may be difficult/slow.
use big files plugin to open big files
use big files plugin to open big files
That plugin is available through the Plugins Admin interface. Notice the caveat in the about-the-plugin box in the Plugins Admin (emphasis added)
Especially note: there is no option to save. So that plugin means the file is read-only, and cannot save edits made to the large files. If you want to save changes to the large files, that plugin will not help you.
Я попытался открыть файл размером 800 МБ в Notepad ++. Но я не знаю, почему Notepad ++ показал только 269117242 символа, 271450112 байт . Ни один из них не показал никаких предупреждений о том, что он не может открыть такой большой файл. Затем я использовал WordPad, чтобы открыть тот же файл, он работал как шарм.
Но почему Notepad ++ не может открыть файл 800MB? Я предполагаю, что должна быть какая-то настройка, которая говорит показать только этот текст.
PS Пожалуйста, не предлагайте никаких других программ, которые могут открывать большие файлы. Я знаю, что они существуют.
В общем, не стоит говорить что-то вроде того, что вы упомянули в постскриптуме. «PS Пожалуйста, не предлагайте никаких других программ, которые могут открывать большие файлы. Я знаю, что они существуют».
Notepad ++ не поддерживает большие файлы, в соответствии с этой вики-документацией проблема сохраняется, если компонент (Scintilla) остается ядром Notepad ++:
- Разделите огромный файл на управляемые куски и оставьте только один из них в редакторе;
- Используйте другой инструмент, предназначенный для обработки больших текстовых файлов.
- Плагины, которые анализируют и сканируют текст, замедляют работу NP ++, по возможности отключите их
- Разбор кликабельных ссылок при загрузке документа выполняется медленно, если документ большой; Отключение кликабельных ссылок, как сообщается, значительно поможет.
Другая страница на sourceforge также предполагает, что эта проблема сохраняется на протяжении всей жизни Notepad ++, поскольку сообщество попросило решить эту проблему :
Почему бы вам не попробовать другие программы, такие как gVim ? Есть ли причина?
Если Wordpad сможет открыть файл, который также позволяет редактировать расширенный текст, я бы сказал, что это ошибка в Scintilla. Кроме того, gVim выглядит как оконная оболочка вокруг консольного редактора. Я бы не посчитал его сравнимым с NotePad ++, который является полнофункциональным редактором с собственным окном
Я бы посмотрел в EditPad Lite. Хотя даже это поддерживает только до 2 ГБ файлов. Pro версия поддерживает более крупные. Очень хорошо. Мгновенно открывает большие файлы.
@ lamwaiman1988: официальный установщик gvim для Windows® является 32-разрядным и не обрабатывает большие файлы.
Подсветка синтаксиса является одним из основных источников низкой производительности в Notepad ++.
Если вы открываете массивный файл HTML, PHP и т. Д. В Notepad ++, вы, вероятно, захотите отключить подсветку синтаксиса для этого файла, выбрав « Язык > N > Нормальный текст» .
В стандартном блокноте для всех версий Windows, начиная примерно с 2001 года, имеется ошибка, про которую практически все знают, но никто не собирается её исправлять. И это понятно, ведь это не критическая уязвимость, ничьей безопасности она не угрожает. Да и пользуется ли кто блокнотом вообще?
Тем не менее, сам факт довольно странный, поэтому мы попробуем найти эту ошибку в коде 64-битного и 32-битного notepad.exe от windows 7, исправим её, и выясним наконец, почему же она возникла. Заключается ошибка в следующем:
Если в блокноте включена опция «перенос по словам» (word wrap), то после сохранения файла начинаются всевозможные глюки: строки начинают разъезжаться, курсор улетает, текст вводится не туда, куда вы ожидаете, и так далее.
Для начала попытаемся поточнее выяснить, что же происходит. Откроем или введём какой-нибудь текст с длинными строками, чтобы они переносились. Сохраним файл. Если теперь попытаться его редактировать, например, добавив слово «синими», строки будут переноситься неправильно, ломая форматирование:
Если уменьшать окно блокнота, строки разрезаются (это видно на заглавной картинке), а при растягивании остаются на месте, не заполняя увеличивающееся окно. Как будто в каждой строке появился жесткий «перевод строки» в том месте, где она заканчивалась в момент сохранения. Видимо текст каким-то образом портится в памяти:
Если же теперь снова сохранить файл, станет ещё хуже. Все строки переформатируются, но окно не обновится. Поэтому курсор может переместиться в другое место, а если начать вводить текст, окажется, что вы вводите его не в то место, где находится курсор, а совсем в другое. Программисты, которые писали notepad, рассуждали логично: при сохранении файла ничего в окне не должно поменяться, поэтому и нет смысла его обновлять. Но в нашем случае с учётом этой ошибки весь текст меняется. Воспроизвести ситуацию может каждый пользователь windows, потому что последняя версия, где этой ошибки не было — Windows'98, и вряд ли у кого она ещё осталась.
Итак, по всей видимости, при сохранении файла что-то идёт не так и текст портится. Как найти это место в коде? Откроем notepad.exe в каком-нибудь отладчике. Как известно, в 64-битной системе для совместимости имеется два блокнота: 32- и 64-битный, надо не перепутать их.
Введём текст, на котором легко будет увидеть, как он портится при переносе строк. Наберём в одну строку «first text line second text line», а затем уменьшим окно так, чтобы она разрезалась посередине.
Резонно будет предположить, что запись делается с помощью функции WriteFile. Оказывается, она вызывается в коде целых 6 раз. Недолго думая, поставим точки останова на все 6 вызовов. Запускаем блокнот и нажимаем «сохранить». Выполнение останавливается здесь:
Посмотрим все регистры, где содержатся параметры вызова. В rcx у нас 104, это непонятно что. A rdx = 002D45E0, это похоже на адрес в памяти. Посмотрим, что там.
Отлично. Отсюда у нас идёт запись. Попробуем выполнить код дальше, чтобы посмотреть, где он портится. Однако почти сразу данные затираются, а это значит, что это всего лишь временный буфер, а сам текст хранится где-то ещё. Посмотрим выше по программе.
Ага, перед сохранением текст видимо преобразовывается из многобайтовой кодировки в однобайтовую. Точно так же, как в прошлый раз, посмотрим параметры. rax = 002D45E0, здесь у нас пока нули. Это как раз то место, куда попадёт результат. esi = 20, это длина текста. есх = 4еЗ, без комментариев. edx = 400, то же самое. А вот r8 = 002D6780:
Снова продолжим выполнение, наблюдая за содержимым этого участка памяти. Через несколько десятков команд мы выходим из подпрограммы, выполняются какие-то переходы, вызовы, но мы, не обращая на это внимания, продолжаем давить на «step over», выполняя код по шагам, и следя только за окном с текстом. И вот в какой-то момент он изменяется. Как видим, между 1 и 2 строкой появились коды 0d, 0d, 0a:
Как обычно бывает, мы проскочили нужную команду, постоянно давя на кнопку, поэтому придётся повторить всё ещё раз, запомнив, где примерно это произошло. Теперь по мере приближения к нужному месту в коде, замедляемся, и точно определяем, что текст испортился вот на этом вызове:
Можно попробовать, что будет, если не делать этот вызов. Снова доходим до этого места, и прямо тут, в отладке, изменяем RIP (регистр, где хранится адрес выполняемого в данный момент кода) на 00000000FFA38EE1, как будто мы пропустили этот call, который нам всё испортил. Удивительно, всё работает, текст не ломается!
Тут надо сказать, что в таких случаях обычно не разбираются, что это за подпрограмма, что она делает и зачем, а просто выкидывают её из EXE-файла. Это можно сделать разными способами, например, забить её всю NOP'ами, или изменить условный переход по равенству «je», который так кстати имеется сразу перед ней, на безусловный «jmp».
Параметр wParam: true — вставить символы, false — удалить их.
Где же здесь параметр, равный 1? Всё очень просто — он в регистре r8. Для сокращения кода компилятор никогда не использует прямую пересылку нуля в регистры. Такая команда занимает б байтов: 2 байта код операции, 4 байта — 32-битный ноль. Вместо этого регистр XOR-ится сам с собой, в итоге получается ноль, и это занимает всего 3 байта. После этого r9, который равен нулю, пересылается в r8 с добавлением единицы (выделена зеленым). Эта операция тоже занимает всего 4 байта. Вот эту зеленую 1 нам и надо поменять на 0, и тогда текст не будет портиться.
А теперь найдём эту же процедуру в 32-битной версии блокнота. Если не хочется повторять все те же манипуляции с отладкой, её можно найти простым поиском числа 0C8h.
64-битный notepad.exe (193536 байт) поменять байт по адресу [80FC] с 1 на 0
32-битный notepad.exe (179712 байт) поменять байт по адресу [6FC8] с 1 на 0
Не сомневаюсь, где-то в недрах майкрософтовского кода еще много таких мест, где спят древние баги, которые, скорее всего, никто никогда не исправит. Нам остаётся только надеяться, что все они такие же безобидные как этот, и ничего страшного не случится, когда они будут перенесены в следующую операционную систему, которую с удовольствием установят себе пользователи по всему миру.
Как открыть хвост 8 ГБ файлов журнала С помощью Notepad++ в Windows?
Я использовал Notepad Document Monitor, но не совсем понимаю, как его использовать. Я начинаю мониторинг и что потом? Как выбрать большой файл?
Я не могу просто открыть файл, потому что он 8 ГБ. Поэтому я получил этот большой файл журнала 8GB. Я только хочу увидеть хвост. Как и последние 100k строк, для образец.
говорит, что я должен открыть файл.
весь смысл вижу только хвост, потому что файл слишком большой. Я только хочу увидеть хвост.
можно использовать команду PowerShell 3: Get-Content yourfile.log -Tail 100
Я признаюсь, что иногда использовал 7Zip для работы с огромными файлами. Вот как это делается:
есть некоторые минусы:
- первая строка первого файла будет иметь некоторый мусор, связанный с tar.
- файлы, как правило, не старт/стоп на строку границ.
- не будет работать, если файл активно добавляется.
вы можете использовать функцию Total Commander file lister (горячая клавиша F3) или автономную версию, которая доступна здесь: Lister standalon
встроенный файловый Листер позволяет просматривать файлы практически любого размера (до 2^63 байт) в текстовом, Unicode, HTML, двоичном или шестнадцатеричном формате, растровой графике (bmp, jpg, gif, png), мультимедийных файлах, а теперь и RTF файлах. Он хранит в памяти лишь небольшую часть файла (за исключением растровых изображений), остальное загружается автоматически при прокрутка текста.
используйте шестнадцатеричный редактор, такой как HxD, они обычно потоковое жесткий диск вместо чтения всего файла.
выберите все сверху вниз, затем начните отменять выбор вверх все, что вы хотите сохранить.
удалить все, что вы не хотите (это может занять некоторое время и может появиться панель загрузки, но не должны висеть или перегружены, как Notepad++ будет).
затем, вы можете открыть его в Notepad++, в случае, если вам не требуется более автоматический решение.
вы можете использовать специальную верстак данных, это называется Анхор схема.
- установите пакет "отображать и фильтровать большие тексты"
- импортировать библиотеку LargeTextReader.flsx
- укажите путь к вашему файлу
- вы GTextOpen открыть его
- соедините его с GTextView
- подключите его к приборной панели
- получайте удовольствие прокрутки через файл !
есть много операторы для фильтрации, соединения или извлечения необходимых строк.
самое лучшее, что вам не нужно 8 ГБ оперативной памяти, чтобы получить файл в представлении, данные будут передаваться через небольшие куски с почти без задержки.
Я сам уже смог заглянуть в файл данных OSM с 43 ГБ и более 600 миллионами строк.
Community Edition приложения является бесплатным и должно подходить даже для таких задач.
Читайте также: