» Notepad++ (часть 2)

DmitryFedorov

Цитата:

Npp может открыть большие файлы

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

И да, отцы, чем кидаться друг в друга чем ни попадя, лучше б объясняли для тех кто не сильно шарит, как "делать правильно".
Я вот, положим, вообще не шарю и 9/10 из того что вы пишете во время "дружеских перепалок", для меня - китайская грамота.

DmitryFedorov

Цитата:

Автор CudaText бросил отполированную прогу и перешел на другой движок.
Это несколько лет работы. Значит намерения серьезные.
Движок дает кросс платформенность,

Посмотри в википедии, Scintilla тоже кроссплатформенный. Я даже ставил SciTE в Linux'е, но оболочка-надстройка слабая, чтобы назвать это удобным редактором.


Цитата:

Я лишь подсказал то, на чем можно спотыкнуться, можешь просто учесть чтоб не влипнуть.

Тут двояко можно рассуждать. Если мне пришлось восстанавливать файлы, то это порча, просто она другого вида, не преднамеренная и не в полной мере, но достаточная чтобы перечитывать весь файл. Это ещё хуже когда ты не можешь откатить, но не знаешь где погрешено, хуже нет. Если ты определил это быстро, это не значит что у других это произойдёт также быстро, до того как не испорчены все тексты.


Цитата:

Встретить в Винде реальные файлы с кодировкой Макинтош нереально. Их просто нет.

я тоже не думал что файлы винды не могут быть в линуксе, и вот они есть, а файлы линукса в винде. И вот я взял да и указал редактору в Linux'е, что если файл в ANSI, то применить к нему кодировку Windows-1251, и ура, теперь у меня между файлами нет конфликтов.


Цитата:

Почему?
Да потому что Npp работает как на Винде так и на Макинтоше.

Значит единственное что нам надо - это чтобы автор ввел уточнение:
На Винде, в которой для не Юникод-файлов стоит поддержка кирилицы, автообнаружение Макинтош считать равным 1251 и всё.

Вот поэтому я и говорю пиши сам чтобы я потом не выглядел... Доказательства нет, что автор применяет кодировку макинтош как наиболее вероятную, потому что N++ работает и в макинтош.




Добавлено:
DmitryFedorov

Цитата:

Почему я так говорю? - наплодив кодировок пришли к Юникоду. Потом трансформировали его в UTF (Unicode Transformation Format), где порядок символов совпадает с 1251. Поэтому в NPP этот формат до сих пор поясняется словами: ANSII как UTF-8

не уверен строка "ANSII как UTF-8" отображается для кодировки UTF-8 без BOM. А кодировки UTF-8 и "UTF-8 без BOM" отличаются только 3-мя символами в начале текста. Эти символы упрощают определении кодировки, с вероятностью 100% даже для пустого файла. А "UTF-8 без BOM" возможно применяется в случаях когда программе мешают эти первые 3 символа. К примеру в Autoit есть подключаемые библиотеки UDF, она как бы вставляется целиком внутрь кода в место где указано подключение и когда туда вставляются эти 3 символа то интерпретатор встаёт в ступор, ему нужно чистое содержимое, ну он так сделан. В HTML-файлах тоже "без BOM".

Цитата:

Но другие символы кидал куда угодно.
Хотя у всех народов есть алфавит. Так расположи его до конца таблицы.
В середине напихай еще символов, которые собственно и будут отличать твою кодировку от других.
Нет. Во всех кодировках номера символов у букв разные. Хотя буквы те же самые - Алфавит.
Надо быть полным идиотом чтобы так сделать.

Лучше не пиши про то, в чем не шариш. Ты возможно и решил что самый умный, но все-же были и есть кто поумней тебя.

Как ты собрался в 1 байте закодировать больше чем 256 символов, притом что кроме родных символов еще нужно и латиницу туда записать... и если нам нужно больше байта, то как определить что один символ должен байт занимать, а другой два например...


Наверное кто придумывал кодировки, все-же были не идиоты, да.


UPD:
Цитата:

Хотя у всех народов есть алфавит. Так расположи его до конца таблицы

Давай представим, что гдето-там существуют два народа - Матобо и Ктулху, у них в алфавитах одинаковое кол-во букв, и как твой универсальный метод тут поможет?..

Valery_Sh

Цитата:

И даже оччень большие

Вот именно Npp Может. А один чудак говорит что редактору это не надо.
Я считаю что надо. На кой ляд мне несколько редакторов.
Цитата:

лучше б объясняли для тех кто не сильно шарит, как "делать правильно"

Не могу назвать себя очень знающим - пока правильно делать так как нарисовано в шапке: есть проблемы с распознаванием - сними галку (если я правильно понял вопрос).


AZJIO2
Цитата:

Посмотри в википедии, Scintilla тоже кроссплатформенный

Я это знаю. Тоже автора спросил об этом, но хозяин-барин, он посчитал что ему нужен другой движок.
---
Про порчу я посоветовал не говорить потому что цель другая: получить результат, а так это вызовет "спор" и толку не будет.
---
Реальных файлов с кодировкой MAC в винде не может быть. Ты их можешь конечно скопировать, но их в ней быть не может. А вот кодировка 1251 может быть в Маке. Она повсюду. В инете, везде.

Цитата:

Вот поэтому я и говорю пиши сам чтобы я потом не выглядел... Доказательства нет, что автор применяет кодировку макинтош как наиболее вероятную, потому что N++ работает и в макинтош.

Ну знаешь. Я не вызывался. Мне это не настолько мешает. А то что я написал про макинтош это не доказательство. Это объяснение. То что на Маке Npp работает известно всем.

Цитата:

не уверен строка "ANSII как UTF-8" отображается для кодировки UTF-8 без BOM

Ну конечно когда заголовка нет - не грех и подсказать что речь идет о кодировке в которой точь такие же как в ANSII. Это речь о подсказке Npp.
О том в каком случае нужна запись BOM в каком нет - не берусь сказать. Твоя логика вроде вполне нормальна.

Добавлено:
Daniyar91
Мда. С тобой сложный случай. Ты хоть сам понял о чем написал? Ругнись уж лучше чем так отвечать. Мы все поймем.

Думаю, что можно обойтись простым патчем. Протестируйте, кому интересно.

Цитата:

Видимо стоит уточнить - DmitryFedorov != ру-борд

Как минимум, начиная с 13-10-2015 руборду насрать на его программу. Даже тебе.

DmitryFedorov

Цитата:

Реальных файлов с кодировкой MAC в винде не может быть. Ты их можешь конечно скопировать, но их в ней быть не может. А вот кодировка 1251 может быть в Маке. Она повсюду. В инете, везде.

У MAC-овцев нет интернета и они не выкладывают своих файлов? Почему то я в линуксе активно использую интернет и ось на это не влияет. Только в линуксе по умолчанию кодировка UTF-8, поэтому ты ни как не создашь проблем для других осей.

Цитата:

это не доказательство. Это объяснение

это не доказательство. Это предположение

Цитата:

Мда. С тобой сложный случай. Ты хоть сам понял о чем написал? Ругнись уж лучше чем так отвечать. Мы все поймем.

Ты начинаешь что-то путать, мой ответ никак не был связан с твоими предыдущими сообщениями про CudaText, NPP, или еще что-то там. Я писал про то что ни надо считать что вокруг одни дибилы, а ты самый умный, ведь это не так.

Давай я объясню, раз ты не понял.

Та херня что ты написал про юникод, UTF, и однобайтовые кодировки -- не более чем херня.

Поверь мне наслово, что в одном байте можно закодировать только 256 значений. И если каждую букву сопоставить этим значениям, то выходит, что однобайтовая кодировка может уместить в себе алфавит максимум из 256 символов.

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

И вот, если в россии в основном пишут на русском, то почему бы не сделать кодировку, в которой будут только русские и латинские буквы... и так будем делать для каждой письменности. Т.е. в итоге получаем много разных кодировок.

И если взять два файла с разными кодировками, то мы едвали сможем опридильть что там на самом деле.

Доходит дело до азиатский языков, и оказывается, что там больше чем 256 символов, т.е. если мы выкинем даже латинские буквы, то все равно не сможем уместить в такой кодировке все нужные символы, а значит нам надо больше байт, и вот уже получились многобайтовые кодировки.

И ты открываешь файл на каком-нибудь китайском, и что, как ты предлагаешь понять что эта многобайтовая кодировка, а не однобайтовая. Если прочитать первый байт, то можно предположить что там какая-то буква, а если прочитать два байта, то так-же можно предположить что это одна буква.


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

Daniyar91
Слушай. Неужели ты так безнадежен? Я тебе разжую.

С помощью 7бит можно задать 128 символов.
С помощью 8 бит можно задать 256 символов.
То что задается с помощью 7 бит всегда на одном и том же месте.
Это логично и правильно - это символы в таблице от 0 до 127.
Остается еще 128 символов.
В них описывается наш алфавит. Всего 66 символов.
Вопрос куда их запихнуть и в каком порядке.
После этого останутся еще 62 символа, которые можно варьировать.

Надо быть очень не логичным чтобы символы нашей азбуки все время размещать в разных местах. Этт надо постараться. И я описал как постарались.

Мелкософт разместил наш алфавит по порядку сначала Верхний регистр, потом Нижний и заканчивает ими таблицу.
В середине таблицы - "прочие символы и буквы ёЁ"
Этот порядок после этого повторяется в UTF8.
Т.е. сначала верхний, затем нижний регистр и не перемешивая и по порядку.
Вот это логично и правильно.

Если бы остальные кодировки сделали то же самое проблем с распознаванием кодировок бы не было. Особенно гавнистым оказался порядок размещения символов в кодировке MAC.

Между тем кодировки были бы разными, потому что предлагали бы разные "прочие символы", те же самые что предлагают и сейчас.
Теперь тебе понятно?
-------------
Я только вот не пойму, зачем ты на ровном месте устраиваешь "бурю в унитазе"? Исторически все понятно: IBM делала кодировку под себя, MAC под себя. Борьба за место под солнцем.

У кого там нет никаких проблем с автодетектом кодировок в NPP? Откройте эти файлы (кодировки Win 1251 и 866) в последней версии NPP.

Добавлено:

Цитата:

Думаю, что можно обойтись простым патчем. Протестируйте, кому интересно.

Что делает ваш патч? Никакой разницы не вижу.

DmitryFedorov

Цитата:

Этот порядок после этого повторяется в UTF8.

Прочти тут, порядок не совсем одно и тоже при учёте "Ёё", а порядок А-Я. а-я одинаков.
И ещё комментарий типа юникод является продолжением ANSI, он не является продолжением. Если ты применил ANSI, то ко всему документу применяется только ANSI, а если юникод, то ко всему документу применяется юникод, и ANSI там вообще не участвует, если у них совпадает начало 0-127 это понятно, но 128-255 у них не совпадает ни с русской кодировкой не ещё с какой либо, там просто набор всех языков и русский там не идёт первым после английского, с чего бы. юникод и так вмещает в себя все символы, и он не является продолжением какой то из кодировок ANSI

Цитата:

У кого там нет никаких проблем с автодетектом кодировок в NPP?

Во, спасибо. Посмотрел теперь и я на эту бодягу. Прикольно! Правда, кодировки редактор определяет не как МАС, а, например, для файла 1251.txt как ISO 8859-8. Такой гемморой сразу видно и понятно, что нужно выбрать другую кодировку. А здесь, как я понял, проблема в том, что кодировка 1251 определятся как МасCyr: буквы вроде как русские, но есть небольшие отличия, которые не сразу легко заметить особенно, если документ большой. Но честно, с таким поведением Notepad++ в своей работе c txt документами ещё не сталкивался.

Bannan

Цитата:

определяет не как МАС

Видимо там что-то еще доломали и теперь определяется так =)

DmitryFedorov

Цитата:

Фирма Мелкософт оказалась единственной, кто сделал что-то логически.

он воткнул ёЁ в случайном порядке, не считая их буквами алфавита. И тебе не всё ли равно кто сделал логичнее, ты же печатая не чувствуешь проблем в том, что таблица символов не по-порядку.

AZJIO2

Цитата:

И тебе не всё ли равно кто сделал логичнее, ты же печатая не чувствуешь проблем в том, что таблица символов не по-порядку.

Речь об опознавании. Когда ты печатаешь - кодировка известна. Когда опознаешь кодировка неизвестна. Для опознавания нужна логика.
А отдельная MAC кодировка есть только в русском насколько я понял и именно она гадит.
Буква Ё долгое время действительно не была в машинном алфавите. Даже орфография идет в двух вариантах - с Ё и без Ё.


Добавлено:

Цитата:

Прочти тут, порядок не совсем одно и тоже при учёте "Ёё", а порядок А-Я. а-я одинаков

У тебя что тоже сыр-бор в голове? Чего ты меня отсылаешь здесь к регулярным выражениям? когда речь совсем о другом.
В общем порядок в таблице UTF-8 (ты должен открыть именно эту таблицу) такой же.
Т.е. символы просто смещены.
Главное что нехорошо в разных кодировках - это одни и те же символы в ANSII таблицах имеют разный номер.
Но вот 1251 имеет для основного набора кириллицы такой же номер как в UTF8 только со смещением.
Если бы другие кодировки имели такую же логику - т.е. размещали основной набор символов кирилицы в конце ANSI таблицы, то проблем с опознаванием не было бы никогда. Опознавание было таким же жестким как опознавание основной латиницы, размещенной в первых 128 символах ANSI таблицы.

Добавлено:
thejustsoul
Твои примеры не предназначены для демонстрации проблем обнаружения кодировки.
В этих примерах практически нет текста и потому изначально известно что проблемы с обнаружением кодировки будут.
Слов "Проба пера" или "Гыгыгы" недостаточно. Некорректно на их основании говорить что, что-то не так.

Нужен текст (раньше были где-то такие примеры).
И вот тогда на примере реального текста видно что для русских текстов не всегда, но довольно часто кодировка определяется как MAC.

thejustsoul

Цитата:

У кого там нет никаких проблем с автодетектом кодировок в NPP? Откройте эти файлы (кодировки Win 1251 и 866) в последней версии NPP.

Посмотрел я еще раз этот "детектор" с помощью твоих файлов. М-дя...
У тебя 1251 как определилась? Хочу сравнить с тем, что получилось у меня.

PS: А все вижу. У меня то же, что и у банана. В общем, такой детектор, по-моему, можно просто выкинуть. Отключить то есть. Бесполезен он.


Цитата:

Видимо там что-то еще доломали и теперь определяется так =)

Нет, в детекторе ничего не менялось. Он с древнейших времен так работает, как только появился в npp. Уж фик знает, сколько лет.

Цитата:

Если бы другие кодировки имели такую же логику - т.е. размещали основной набор символов кирилицы в конце ANSI таблицы, то проблем с опознаванием не было бы никогда. Опознавание было таким же жестким как опознавание основной латиницы, размещенной в первых 128 символах ANSI таблицы.

Зачем херню пишешь?

Если бы кодировки были похоже, то зачем они вообще нужны с разными названиями...

А если они все-же чем-то да отличались, то тогда, такое "размещение" символов, наоборот бы значительно затруднило распознавание кодировок, т.к. они отличались бы незначительно. Т.е. было-бы примерно так как сейчас в NPP.


Видимо писать проще чем думать.

Daniyar91
Горбатого могила исправит.

Ты кстати когда на русском пишешь думай. Хер - это в германии уважаемый человек. А по-русски это та фигня что у тебя меж ногами болтается.
И пиши немного грамотней. Глаза режет. (я не имею ввиду описки).

Разные кодировки были сделаны только для того чтобы иметь разным набор дополнительных символов. (это их единственное отличие и причина по которой они были сделаны разными. О чем тебе скажет любая википедия). А делали их разные фирмы. Но вот логика размещения символов в таблице у фирм была разная, а не единая.

Всем
Вспомнил что есть вполне приемлемое решение для этого обнаружения кодировок, когда речь идет о русских буквах.
Это Штирлиц. Зашел к автору. Порылся - висит. Вот вам Ссылка
Вытаскиваете содержимое Зипа в папку plugins. Перезагружаете Npp. В меню Плагины будет пункт Shtirlitz.
В случае чего он преобразует. Отмена преобразования возможна.

DmitryFedorov

Цитата:

Твои примеры не предназначены для демонстрации проблем обнаружения кодировки.

Приведи свои.
Bred3 открыл оба файла правильно, ему значит достаточно, а NPP недостаточно. ОК.

Вот попробуйте такой вариант: скачать

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

Цитата:

Bred3 открыл оба файла правильно, ему значит достаточно, а NPP недостаточно. ОК.

Вполне возможно, что Брэдд выбирает только из трех сосен

Цитата:

наиболее распространенных кириллических кодировок (ANSI, KOI8, OEM, юникод)

так что у него простор для маневра небольшой. Npp же перебирает несколько больше кодировок, да и способ перебора у него статистический.

thejustsoul

Цитата:

Приведи свои.  

Вот пример, последний, только текста нет.
С твоего ответа на этот пример и началась вся эта буча. Спроси может текст пришлет.
Остальные примеры у меня куда-то затерялись.

Добавлено:
Вроде как в прошлой ветке были ссылки на другие примеры.

DmitryFedorov
Я уже давно тут писал про этот косяк и до меня писали и будут писать пока не пофиксят, даже пример текста приводил, искать лень.

Цитата:

что Брэдд выбирает только из трех сосен

Ну так, а что еще нужно, пусть выбирает из самых распространенных, остальная экзотика вручную если что.

Нашел в первой части темы пример текстовика для проверки автоопределения кодировки. Там правда ссылки все дохлые, хорошо что пример привели еще в тестовом варианте. Короче вот файлик: скачать

А архиве текстовый документ в кодировке windows-1251. Оригинальная версия сабжа его открывает в кодировке Macintosh. Исправленная версия (см. мое предыдущее сообщение) - корректно (ANSI). Конечно дать 100% гарантию дать не могу. Может есть другие примеры.

DmitryFedorov

Цитата:

Речь об опознавании. Когда ты печатаешь - кодировка известна. Когда опознаешь кодировка неизвестна. Для опознавания нужна логика.

и какая логика? Ты печатаешь алфавит всегда, поэтому тебя определяют что ты русский так как совпала последовательность? У тебя явно сыр-бор в голове, да ещё каша вдобавок. Разжую ещё чуток, представим что в наборе кодировки 128-255 имеется некие символы, а в другой кодировке такие же символы в другом порядке. Как ты определишь кодировку если в файле просто набор чисел, который просто в другой кодировке означает другой символ, не более. Теперь наконец то ты понял что тебе долдычат? Да и если они сдвинуты это всё равно не одно и тоже.


Цитата:

Если бы другие кодировки имели такую же логику - т.е. размещали основной набор символов кирилицы в конце ANSI таблицы, то проблем с опознаванием не было бы никогда

Не кажется ли тебе что это бы была одна и таже кодировка? если бы детородный орган бабушки был как у дедушки, то она была бы дедушкой...


Цитата:

У тебя что тоже сыр-бор в голове? Чего ты меня отсылаешь здесь к регулярным выражениям? когда речь совсем о другом.

речь о том же. В регулярных выражениях работает диапазон "Ё-ё", но в кодировке 1251 эти две буквы до последовательности алфавита, а в юникоде Ё - до последовательности алфавита, ё - после последовательности алфавита. Читаем книгу видим фигу? я не читатель я писатель?

ItsJustMe

Цитата:

Посмотрел я еще раз этот "детектор" с помощью твоих файлов. М-дя...
У тебя 1251 как определилась? Хочу сравнить с тем, что получилось у меня.

PS: А все вижу. У меня то же, что и у банана. В общем, такой детектор, по-моему, можно просто выкинуть. Отключить то есть. Бесполезен он.

У меня тоже была мысль что может этот детектор вообще ничего полезного не детектит, но слышал что, что то распознаёт, поэтому не утверждал свою идею твика опции на отключения как более разумную, чем перенаправлять мак на 1251.

AZJIO2

Цитата:

У меня тоже была мысль что может этот детектор вообще ничего полезного не детектит, но слышал что, что то распознаёт, поэтому не утверждал свою идею твика опции на отключения как более разумную, чем перенаправлять мак на 1251

Если кому вдруг захочется заняться этим, то надо этот детектор проверить на распространенных кодировках: UTF-16, UTF-16BE, UTF-8 (все без BOM), JIS, Shift JIS, GB2312, Big5, еще, что в голову придет. Ну, и конечно, наши родные 1252, 1251, 866, КОИ-8. Посмотреть и узнать, детектит он что-то или нет. Может, он и правда бесполезен.

AZJIO2
Что ты что Daniyar91, вы два сапога-пара, одного поля ягода.

Цитата:

Разжую ещё чуток, представим что в наборе кодировки 128-255 имеется некие символы, а в другой кодировке такие же символы в другом порядке. Как ты определишь кодировку если в файле просто набор чисел, который просто в другой кодировке означает другой символ, не более. Теперь наконец то ты понял что тебе долдычат?

Как же тебя отец наш родной понять, если ты ничего не говоришь!
Ну представил я что все до единого символа в двух кодировках имеют разный номер символа и что? Что это мне должно доказать? Что нельзя определить кодировку?!

Так ведь нет - именно на этом принципе и построено сегодняшнее обнаружение кодировки! Хай все до единого будут разными - тогда мы определим. И ничего умного в этом нет. Это изврат.

Цитата:

Не кажется ли тебе что это бы была одна и таже кодировка? если бы детородный орган бабушки был как у дедушки, то она была бы дедушкой...  

Если бы у двух кодировок отличались бы только дополнительные символы, то сказать Ху из Ху...й можно было бы на раз.

А пока алгоритм задачи, решаемый обнаружением выглядит так: Ссылка (ссылку не стал раскрывать потому что рисунок очень большой)
И поверь именно так и строят алгоритм. Если не веришь посмотри простой вариант выбора из трех кодировок: Ссылка. Тут важна логика выявления.
-----
Все остальные рассуждения вообще из другой области. Обратная задача: кодировка известна - как мне найти символ. Ну это другая задача.

DmitryFedorov
Ввёл в гугл "алгоритм определения кодировки", посмотри первую ссылку, в общем не сложно найти формализацию задачи определения кодировки. Как я и предполагал она основана на частоте встречаемости каких либо символов, например гласных меньше чем согласных, но они заканчивают каждую согласную почти всегда. Если ты откроешь ANSI и UTF-8, то увидишь что часто перед числом 2 нуля, типа "00 FF 00 DA".
В AutoIt есть библиотека "Encoding.au3", если тебе не сложно понять язык то ты разберёшься в точном алгоритме определения кодировки. Вот кусок кода, две функции, первая для определения кириллических кодировок ANSI, вторая UTF-8, 16, 32.
Пока сочинял тебе пост, ты уже отправил мне ту же картинку что я тебе советовал найти в гугле, она там же в первой ссылке.

Добавлено:
DmitryFedorov

Цитата:

Что ты что Daniyar91, вы два сапога-пара, одного поля ягода.

да нет (или да?), обычно я удерживаю себя от шуток, так как когда они применяются ко мне то я понимаю как будет чувствовать себя оппонент. Но к сожалению оппонент не видит себя в зеркале и даже его шуточки повторённые ему слово в слово он не видит напрочь. Остаётся признать что просто человек такой, вот только Daniyar91 этого не знает, а я то давно уж забил, не обращаю внимания, просто показал ему что ты один фиг себя в зеркале не увидишь.

Цитата:

Горбатого могила исправит.

вместо признания ошибки в ответ оскорбление, представь что я так начну писать и все мы.

AZJIO2

Цитата:

да нет (или да?)

Да-да. Вы одинаковы в упертости. Это вас объединяет. Ну и еще то что логика убеждения типа украинской: Главное сказать. Сказал, не доказал, сказал другое. Захочу скажу третье.
Отвечать на чужие аргументы -ни-ког-да.

Я тебе ответил. Плевать. Зачем дальше отвечать. Теперь аргумент это функции, которые ты нашел. И моя же картинка.
Ок.
Функции твои говорят о том же что и я: опознавание основано на символах которые не должны повторяться. Вот если есть такое условие для номеров символов - то такая кодировка, опять если .. другая, если .. третья. Ну как на картинке. Но основа этих условий - номер символа и то что он не повторяется в разных кодировках. (ты же говоришь о повторяемости в сочетаниях и прочем. - это не основа, это способ)
Вот чего я писал:

Цитата:

Так ведь нет - именно на этом принципе и построено сегодняшнее обнаружение кодировки! Хай все до единого будут разными - тогда мы определим.

А теперь представь, что этого изврата нет. И у тебя есть не одна, а две точки опоры. Основной набор символов латиницы (в таблице 0-127) и основной набор символов Кирилицы (в таблице 192-255). В этом случае этот основной набор всегда будет правильно показываться, а по оставшимся "прочим символам" ты без труда найдешь кодировку, которую и создали ради того чтобы эти прочие символы были разными.
------
Не буду все обсасывать но все что ты говорил до этого, мало того что само по себе не имеет логики, все это противоречит твоему новому аргументу.
И в итоге ты не доказываешь, не проясняешь свою позицию, а все время увиливаешь пытаясь оказаться правым.
Это не первый раз. Я усё помню.

И ВААЩЕ - ты хотел написать автору вот и пиши. Я за это время нашел ссылку на плагин Штирлица, он вполне решает задачу, если она решаема (хотя если бы он просто показал кодировку, а не преобразовал было бы наглядней), и покончим на этом.
Ты ведь понял уже весь сыр бор идет из-за того что я считаю все эти кодировки извратом. Ну дак так каждый второй считает. Правда, давай скажем стоп. Надоело.

Насчет Daniyar91 - он сам виноват как мне написал так я и ответил. Только более вежливо.

Добавлено:
Кстати посмотри что они сделали с греческим языком. Им как и нам подсунули эту кучу кодировок, только что MAC-кодировки у них нет. Умники. Бедная маленькая страна. Виновата лишь тем что у нее алфавит похож на наш.
Я не против кодировок с разным набором символов, но решение там такое же как и для нас.
Нет чтоб засунуть их алфавит в конец файла и определять кодировку по остатку символов.
Неа. Алфавит из 24 букв все время в разной позиции.

Собственно, вижу, что вас захватил сам процесс срача, так что просто оставлю это здесь. Если будут ещё примеры - кидайте в ПМ, в этой теме слишком много букв. Детект 866.bat починить не получиться.



notepad++-patch.rar

Bannan 20:50 14-03-2016
Цитата:

Нашел в первой части темы пример текстовика для проверки автоопределения кодировки.

Узнаю свой пример .

DmitryFedorov 01:53 15-03-2016
Цитата:

Я за это время нашел ссылку на плагин Штирлица, он вполне решает задачу

Если бы ещё этот плагин обновлялся, а то автор выложил одну бета версию по просьбам и заглохло. Его что после этого перестали просить?


Цитата:

Правда, давай скажем стоп. Надоело.

Остальным читателям темы тоже. А главное бессмысленность этого спора. Смысл спорить о том что и как бы было если бы кодировки придумывали по другому принципу. Они уже придуманы и надо жить дальше с тем, что есть. От того что здесь спорите эти кодировки не изменятся даже если докажете, что так было бы лучше. На эту фразу просьба не отвечать. Просто прекратите спор.

AZJIO2 20:53 14-03-2016
Цитата:

У меня тоже была мысль что может этот детектор вообще ничего полезного не детектит, но слышал что, что то распознаёт,

Да, помню когда он только появился, то обрадовались (искать в старой части темы). В частности OEM866 у меня в большинстве случаев стал правильно определять.