Comments 28
Вот и получается, если подать на вход программе enca строку “СТП” в кодировке CP1251, то она решит, что это строка “яро” в кодировке KOI8-r, о чём и сообщит. В обратную сторону также работает.
Ну так это любая библиотека с эвристикой так сделает. Потому что СТП — это непойми что, а «яро» таки похоже на слово.
Это и есть слово. Наречие от слова «ярый».
Я бы посоветовал взять идеи punto/kbninja — автор идеи объяснил двум программистам принцип: при встрече нереального буквосочетания считать, что клавиатура неверная. Конечно, после пришлось поставить кучу костылей для аббревиатур и целых IDE… Но таки.
Я бы посоветовал взять идеи punto/kbninja — автор идеи объяснил двум программистам принцип: при встрече нереального буквосочетания считать, что клавиатура неверная. Конечно, после пришлось поставить кучу костылей для аббревиатур и целых IDE… Но таки.
Да, punto работает, прямо скажем, очень прилично. Мне придётся сильно подумать, что такое реальное, а что нереальное буквосочетание. Сходу идеи не появляются.
Кроме того, задача у punto существенно сложнее. Ему надо на ходу определять кодировку. В моей задаче можно позволить себе проанализировать весь объём данных. Это существенно меняет дело.
Я подумаю над нереальными буквосочетаниями.
Кроме того, задача у punto существенно сложнее. Ему надо на ходу определять кодировку. В моей задаче можно позволить себе проанализировать весь объём данных. Это существенно меняет дело.
Я подумаю над нереальными буквосочетаниями.
Мне придётся сильно подумать, что такое реальное, а что нереальное буквосочетание. Сходу идеи не появляются.
Цепи Маркова же.
Берем массив текстов (в известной кодировке, иссессна). Читаем тексты побуквенно и считаем все буквосочетания, скажем, длиной 2-3 буквы. На выходе имеем «профиль» самых частых буквосочетаний. Все, что не входит в сей профиль — нереальные буквосочетания.
"Штирлиц"
Пользовался им в студенчестве довольно активно.
До 2001г. версия 4.01
После 2014 — плагин к Notepad++
Переваривал практически все
Всё верно, есть ещё Akelpad. Тоже хорошо определяет кодировки. Даже FAR manager вполне неплохо определяет. Это сейчас вообще не проблема.
Только это всё не помогает при опознавании кодировки в программе. И вот тут, оказалось, что для golang готового решения нет. Решения работающего по трём самым популярным кодировкам: 1251, 866 и KOI8-r точно нет.
Только это всё не помогает при опознавании кодировки в программе. И вот тут, оказалось, что для golang готового решения нет. Решения работающего по трём самым популярным кодировкам: 1251, 866 и KOI8-r точно нет.
Жаль только не всегда правильно определяет UTF-8 без BOM (думает, что видит Win1251).
Есть у меня несколько таких файлов, например вот этот (по ссылке исходник плагина в текстовом формате, в строках 11, 345 и 373 вместо 1 символа в кодироке UTF-8 получается 2-3 символа в Win1251).
Интересно, можно это как-то вылечить?
Есть у меня несколько таких файлов, например вот этот (по ссылке исходник плагина в текстовом формате, в строках 11, 345 и 373 вместо 1 символа в кодироке UTF-8 получается 2-3 символа в Win1251).
Интересно, можно это как-то вылечить?
Взглянул на исходники — навскидку несколько замечаний:
В тестах windows-пути прошиты с обратным слэшем и регистронезависимые — на Linux тесты падают. Например, «test_files\\utf8-wbom.txt»
C этой библиотечкой тесты будут выглядеть попроще.
Линтеры выдают несколько предупреждений — орфография, неиспользуемый код, необработанные ошибки.
Проверять на nil конкретно в том месте наверно вообще не стоит — в вашем случае nil можно рассматривать как нарушение контракта, пусть паникует, а проверка на nil возлагается на клиентов метода. Например, после проверки вы используете библиотечный метод bufio.NewReader( r ).Peek(ReadBufSize), который тоже не проверяет на nil и паникует.
В тестах windows-пути прошиты с обратным слэшем и регистронезависимые — на Linux тесты падают. Например, «test_files\\utf8-wbom.txt»
C этой библиотечкой тесты будут выглядеть попроще.
Линтеры выдают несколько предупреждений — орфография, неиспользуемый код, необработанные ошибки.
Проверять на nil конкретно в том месте наверно вообще не стоит — в вашем случае nil можно рассматривать как нарушение контракта, пусть паникует, а проверка на nil возлагается на клиентов метода. Например, после проверки вы используете библиотечный метод bufio.NewReader( r ).Peek(ReadBufSize), который тоже не проверяет на nil и паникует.
Вот, вот этого я ждал.
1. С тестами. Пожалуй я заставлю себя переделать тесты с файлов на вшитые строки.
Если не сложно, а какие пути должны быть в Linux?
2. Линтеры. Я так понимаю вы прогнали статический анализатор кода? По ссылке нет версии под Windows, а делать через go get они не рекомендуют. Я конечно попробую.
3. Проверка на nil. Конечно я посмотрел исходники стандартной библиотеки, проверки входного параметра там я не нашёл, удивился. Вообще я расчитывал именно из std lib взять методику проверки. Подумал, покурил и решил, нет, то есть да, короче, пусть проверка будет. У меня нет опыта глубокого проектирования, мне сложно определиться на каком уровне чья ответственность будет лежать. Если это нормально (а судя по std lib это действительно нормально), пожалуй уберу.
Только вопрос, а чем плохо оставлять reflect в одном месте для конкретной цели?
1. С тестами. Пожалуй я заставлю себя переделать тесты с файлов на вшитые строки.
Если не сложно, а какие пути должны быть в Linux?
2. Линтеры. Я так понимаю вы прогнали статический анализатор кода? По ссылке нет версии под Windows, а делать через go get они не рекомендуют. Я конечно попробую.
3. Проверка на nil. Конечно я посмотрел исходники стандартной библиотеки, проверки входного параметра там я не нашёл, удивился. Вообще я расчитывал именно из std lib взять методику проверки. Подумал, покурил и решил, нет, то есть да, короче, пусть проверка будет. У меня нет опыта глубокого проектирования, мне сложно определиться на каком уровне чья ответственность будет лежать. Если это нормально (а судя по std lib это действительно нормально), пожалуй уберу.
Только вопрос, а чем плохо оставлять reflect в одном месте для конкретной цели?
А чем не устроила проверка на nil? Зачем тащить reflect? Достаточно же if r == nil…
Вроде именно по этому play.golang.org/p/NoNN4SvIFkz
Если передаём явный nil, то проверка работает, а вот если раскоментировать строки 23 и 25, то получим ошибку выполнения.
И даже явно присвоив nil (раскоментировать ещё и строку 24) всё равно получим ошибку.
Кажется так.
Если передаём явный nil, то проверка работает, а вот если раскоментировать строки 23 и 25, то получим ошибку выполнения.
И даже явно присвоив nil (раскоментировать ещё и строку 24) всё равно получим ошибку.
Кажется так.
Вроде я разобрался с nil, io.Reader и bufio.NewReader…
Вы правы в главном, проверка на nil ВООБЩЕ не требуется поскольку это делает bufio.NewReader()
Вы правы в главном, проверка на nil ВООБЩЕ не требуется поскольку это делает bufio.NewReader()
1. Вместо обратного слэша должен быть прямой и имя файла в коде теста должно полностью совпадать с именем в файловой системе, т.е. например путь
Надо использовать функцию filepath.Join() — это решит проблему со слэшами.
Небольшие файлы для тестов можно затащить в исходники — большие (или например картинки) я бы не стал.
2. Наверно вы невнимательно посмотрели — golangci-lint-1.22.2-windows-amd64.zip
3. Я вообще не припомню, чтобы видел в чьем-то коде такую проверку на nil с помощью reflect — такая проверка меня бы как минимум насторожила, почему сделано так заморочено. Обычной проверки на nil было бы достаточно, тем более что на практике лично я вообще ни разу не сталкивался с этим «оттенком» Go. В Go принято по-возможности обрабатывать nil случаи без возврата ошибки — например, в вашем коде можно было бы вернуть кодировку ASCII без ошибки «input reader is nil», т.е трактовать nil ридер и ридер без данных одинаково. Проверку на EOF лучше писать как
test_files\utf8-wbom.txt должен быть test_files/utf8-wBOM.txt.Надо использовать функцию filepath.Join() — это решит проблему со слэшами.
Небольшие файлы для тестов можно затащить в исходники — большие (или например картинки) я бы не стал.
2. Наверно вы невнимательно посмотрели — golangci-lint-1.22.2-windows-amd64.zip
3. Я вообще не припомню, чтобы видел в чьем-то коде такую проверку на nil с помощью reflect — такая проверка меня бы как минимум насторожила, почему сделано так заморочено. Обычной проверки на nil было бы достаточно, тем более что на практике лично я вообще ни разу не сталкивался с этим «оттенком» Go. В Go принято по-возможности обрабатывать nil случаи без возврата ошибки — например, в вашем коде можно было бы вернуть кодировку ASCII без ошибки «input reader is nil», т.е трактовать nil ридер и ридер без данных одинаково. Проверку на EOF лучше писать как
err != io.EOF
Можно было пойти в исходники Far Manager и взять метод определения кодировки оттуда. Насколько я помню, там используется таблица частоты использования букв кириллицы.
Вспомнился этот пост
попробуйте https://github.com/google/compact_enc_det, у нас неплохо для ласов работает =).
А вообще эта задачка идеальна для нейросетей.
Во-первых nil это валидное значение для любого интерфейса, поэтому if r != nil правильная проверка перед вызовом метода Read
В моём случае проверка входного интерфеса на nil вообще не требуется, как оказалось это делает сама bufio.NewReader().
Что важно совсем не через reflection, но и не через if r != nil
Если действительно нужно проверить на существование пришедший интерфейс, то проверки на nil мало play.golang.org/p/NoNN4SvIFkz
Что важно совсем не через reflection, но и не через if r != nil
Если действительно нужно проверить на существование пришедший интерфейс, то проверки на nil мало play.golang.org/p/NoNN4SvIFkz
Похоже на то, что пример высосан из пальца. Строчка 24 это же выстрел в ногу, после этого просто не стоит вызывать функцию. А во всех остальных случаях достаточно проверять на nil внутри.
Все примеры высосаны из пальца.
Только вот без строчки b=nil проверка на nil не работает.
Мне кажется или объявить переменную, забыть инициировать, а потом передать в функцию это вполне нормальная ситуация? Это тоже высосано из пальца?
Только вот без строчки b=nil проверка на nil не работает.
Мне кажется или объявить переменную, забыть инициировать, а потом передать в функцию это вполне нормальная ситуация? Это тоже высосано из пальца?
Строка 24 это дичь, https://play.golang.org/p/kyGC0mVdkbI. Всё работает и так, не нужно просто путать область ответственности.
Хорошо, вы правы, вы добавили проверку в метод Get() и предотвратили ошибку. Признаю наверно можно обойтись только проверкой на nil. По совету falconandy уже переделал.
Только я не стану делать так:
проверять в каждом методе доступность владельца, это перебор.
Только я не стану делать так:
func (r *reader) Get() string {
if r == nil {
return ""
}
return r.data
}
проверять в каждом методе доступность владельца, это перебор.
А почему выбрали голанг, а не, скажем, Раст?
Если коротко, то синтаксис и отсутствие GC. Синтакс golang я считаю практически идеальным.
Когда-то на хабре была статья, я посмотрел, мне код rust не понравился.
Считаю rust сложным, мощным и правильным инструментом для профессионалов. Я любитель.
Когда-то на хабре была статья, я посмотрел, мне код rust не понравился.
Считаю rust сложным, мощным и правильным инструментом для профессионалов. Я любитель.
Sign up to leave a comment.
Автоопределение кодировки текста