Определить кодировку текста: Как определить кодировку текста онлайн?

Содержание

Определение кодировки текстового файла, OEM или ANSI

← →
Michael K (2004-01-08 14:39) [0]

Здравствуйте!
Знает ли кто алгоритм определения кодировки текстового файла, DOS (OEM) или Windows (ANSI)?
Полагаю 100% надёжного метода нет, но хоть какой-нибудь должен же быть, скажем, Total Commander
по F3 открывая файл пытается определить кодировку, причём почти всегда верно.

← →
Романов Р.В. (2004-01-08 14:51) [1]

В этих кодировках некоторые символы русского языка не пересекаются. Т.е. на месте русских символов одной кодировки находится псевдографика или каракули в другой. Анализируй кусок текста в поисках таких символов.

← →
Anatoly Podgoretsky (

2004-01-08 14:56) [2]

Вопрос то не про русский, а про OEM-ANSI

← →
Romkin (2004-01-08 15:05) [3]

А по частоте употребления букв «О» и «о» как самый простой способ. Например, если часто встречается код 238 — то ANSI, иначе при присутствии множества символов больше 128 — скорее всего OEM

← →
sniknik (2004-01-08 15:13) [4]

очень простой способ, посчитать количество букв в куске кода, а если учесть что некоторые буквы встречаются в тексте чаше…
то например
Аа — в OEM 128-160, в ANSI 192-224
больше первых символов значит OEM вторых ANSI. (только наверное по «о» нужно ориентироваться более употребимая буква.)

или вообше посчитать обшую сумму ord символов в тексте и вычислить среднее значение, у ANSI это среднее будет больше (кодировка начинается с 192 а не 128).

← →
sniknik (2004-01-08 15:16) [5]

Anatoly Podgoretsky © (08. 01.04 14:56) [2]
а для для английского разве важно? и там и там теже места занимают.

← →
Anatoly Podgoretsky (2004-01-08 15:21) [6]

Если используются только буквы (первая половина таблицы) то не вахно, но если используются символы со второй половины таблицы. то очень важно, они или отсутствуют в ANSI или находятся на других местах и без знания языка по позиции не определить толи это OEM, толи ANSI — например символ §

← →
KSergey (2004-01-08 15:24) [7]

> [5] sniknik © (08.01.04 15:16)
> Anatoly Podgoretsky © (08.01.04 14:56) [2]
> а для для английского разве важно? и там и там теже места
> занимают.

Подозреваю, что Podgoretsky как всегда решил выпендриться и намекнуть, что в общем случае OEM (равно как и ANSI) может быть не только для русского. Их много, для разных языков.
Вот только неужели и ему необходимо напоминать, что телепаты в отпуске?

Простите за резкость тона к уважаемым согражданам (хотя какие они нам (мы им?) сограждане ;), но неужели нельзя свои мысли полностью излагать?
Чес. слово — больше на выпендреж похоже, чем на дружеское замечание умудренного опытом учителя. («Я тут ляпну, а вы понапрягайтесь. А я тут поухмыляюсь в бороду». Стыдно, товарищ. Стыдно.) (Тамбовский, говоришь? ;)

← →
KSergey (2004-01-08 15:28) [8]

> [6] Anatoly Podgoretsky © (08.01.04 15:21)

Ага, пока я тут свои излияния делал, был дан кое-какой ответ ;)

Но может все же внимательнее читать вопросы? (я просто ищу формальный повод прицепиться)
«Полагаю 100% надёжного метода нет, но хоть какой-нибудь должен же быть»
На хоть какой-нибудь, думаю, предложенные вполне тянут.

← →
KSergey (2004-01-08 15:32) [9]

И еще в дополнение к KSergey © (08.01.04 15:28) и о поводу Anatoly Podgoretsky © (08.01.04 15:21)
При чем тут §? Речь про определение кодировки текста (рискну так же предположить — осмысленного), на который § — ну явно не похож — то тогда нам, наверное, действительно не повезет…

← →
sniknik (2004-01-08 15:44) [10]

Anatoly Podgoretsky © (08.01.04 15:21) [6]
ну наверное когда куча псевдографики, в общей массе (и не поймеш толи буква из ANSI толи символ из OEM) то и Total Commander неверно определит.
кстати можно и проверить, если так, то вычисляет подобным же образом.

Распознаём 50 видов текста на C++ с Plywood | by Novikov Ivan | NOP::Nuances of Programming

Посмотрим на скромный текстовый файл:

Этот файл может содержать удивительное количество различных форматов. Текст может быть закодирован как ASCII, UTF-8, UTF-16 (с прямым или обратным порядком байтов), Windows-1252, Shift JIS или любой из десятков других кодировок. Файл может начинаться или не начинаться с метки порядка байтов (BOM). Строки текста могут заканчиваться символом конца строки \n, типичным для UNIX, последовательностью \r\n, типичной для Windows или, если файл создан в старой системе, какой-то другой последовательностью символов. Иногда невозможно определить кодировку в конкретном текстовом файле. Предположим, файл содержит такие байты:

A2 C2 A2 C2 A2 C2

Это может быть:

UTF-8, содержащий ¢¢¢;
UTF-16 с прямым порядком (или UCS-2) с символами ꋂꋂꋂ;
UTF-16 обратного порядка байтов с 슢슢슢;
Windows-1252 с Â¢Â¢Â¢.

Пример искусственный. Суть в том, что текстовые файлы в своей основе неоднозначны. Неясности создают проблему для программного обеспечения, загружающего текст. Она существует уже некоторое время. К счастью, ландшафт текстовых файлов со временем стал проще. UTF-8 одержал победу над другими кодировками. Более 95% Интернета использует UTF-8. Впечатляет скорость, с которой изменилась цифра: она составляла менее 10% в 2006 году.

Но UTF-8 ещё не захватил мир. Редактор реестра Windows по-прежнему сохраняет текстовые файлы в кодировке UTF-16. Когда же текстовый файл пишется в Python, кодировка по умолчанию зависит от платформы. На моей машине с Windows это Windows-1252. Говоря коротко, проблема неопределённости текста всё ещё актуальна. И даже если файл закодирован в UTF-8, всё равно есть вариации: он может начинаться или не начинаться с BOM; или может иметь разные стили окончания строк.

Plywood — это кросс-платформенный фреймворк с открытым исходным кодом, выпущенный мной два месяца назад. При открытии текстового файла с помощью Plywood у вас есть несколько вариантов:

Если вы знаете формат, вызывайте FileSystem::openTextForRead(), передавая ожидаемый формат в структуру TextFormat.
Если вы не знаете формат, вызывайте FileSystem::openTextForReadAutodetect(). Функция попытается определить формат и вернуть его.

Возвращаемый этими функциями входной поток никогда не начинается с BOM, всегда кодируется в UTF-8 и завершает каждую строку ввода одним символом возврата каретки \n, независимо от исходного формата входного файла. Преобразование выполняется налету, когда необходимо, позволяя приложениям Plywood работать с единственной внутренней кодировкой.

Вот так сейчас работает автоматическое определение формата текста в Plywood:

Plywood анализирует первые 4 КБ входного файла, чтобы предположить его формат. Двух начальных проверок достаточно подавляющему большинству текстовых файлов, с которыми я сталкивался. В UTF-8 есть много недопустимых последовательностей байтов, поэтому когда файл может быть декодирован как UTF-8 и не содержит никаких управляющих кодов, это почти наверняка UTF-8. Управляющий код — это код символа меньше 32, за исключением символов табуляции, перевода строки и возврата каретки.

Только при входе в нижнюю часть блок-схемы возникают некоторые догадки. Во-первых, Plywood решает, лучше ли интерпретировать файл как UTF-8 или как простые байты. Это делается, чтобы обработать, например, текст с ударениями в кодировке Windows-1252. В ней французское слово détail кодируется байтами 64 E9 74 61 69 6C, что вызывает ошибку декодирования UTF-8. UTF-8, в свою очередь, ожидает, что за байтом E9 следует байт в диапазоне от 80 до BF. После определённого количества ошибок Plywood делает выбор в пользу простого байта, а не UTF-8.

Фреймворк пытается декодировать одни и те же данные, применяя 8-битный формат, little-endian UTF-16 и big-endian UTF-16. Он вычисляет балл для каждой кодировки таким образом:

Каждый декодированный символ пробела добавляет 2,5 балла. Пробельные символы очень полезны для идентификации кодировок, поскольку пробелы UTF-8 не могут быть распознаны в UTF-16, а пробелы UTF-16 содержат управляющие коды при интерпретации в 8-битной кодировке.
ASCII символы, за исключением управляющих, добавляют по 1 баллу.
Ошибки декодирования влекут штраф в 100 баллов.
Управляющие коды наказываются штрафами в 50 баллов.
Коды символов, превышающие U+FFFF, стоят 5 баллов, так как шансы столкнуться с такими символами в случайных данных невелики вне зависимости от кодировки. Яркий пример — эмоджи.

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

Откуда взялись 2,5, 1 и прочие значения? Я их выдумал. Они, вероятно, ещё не оптимальны. У алгоритма есть и другие слабые места. Plywood ещё не знает, как распознавать произвольные 8-битные кодировки. В настоящее время он интерпретирует каждый 8-битный текстовый файл UTF-8 как Windows-1252. Фреймворк также не поддерживает Shift JIS в настоящее время. Хорошая новость заключается в том, что Plywood — проект с открытым исходным кодом. Это означает, что улучшения могут публиковаться сразу после разработки.

В репозитории вы найдете папку, содержащую 50 текстовых файлов различных форматов. Все эти файлы корректно определяются и загружаются функцией FileSystem::openTextForReadAutodetect().

Многие современные текстовые редакторы, как и Plywood, определяют формат автоматически. Из любопытства я открывал этот набор в нескольких редакторах:

Notepad++ корректно открывает 38 из 50 файлов. Он терпит неудачу на всех файлах UTF-16 без BOM, за исключением little-endian, состоящих в основном из символов ASCII.
Sublime Text понимает 42 файла. Когда текст содержит ASCII, редактор делает верное предположение независимо от кодировки.
Visual Studio Code видит 40 фалов. VSC близок к Sublime Text, но ошибается на Windows-1252 с ударениями.
И самое впечатляющее: Блокнот Windows верно отображает 42 файла! Он правильно распознаёт все UTF-16 с прямым порядком без BOM, но не работает с UTF-16 обратного порядка байтов и без BOM.

По общему признанию это было нечестное соревнование: весь тестовый набор создан вручную специально для Plywood. Больше всего ошибок происходило на файле UTF-16 без BOM. Кажется, это редкий формат. Ни один из редакторов не позволяет сохранить такой файл.

Редакторы из списка выше в первую очередь вдохновляли стратегию автоматического обнаружения в Plywood. В C++ работа с Unicode всегда вызывала трудности. Ситуация весьма печальная: комитет по стандартизации C++ только недавно сформировал исследовательскую группу для решения проблемы. Между тем, я всегда задавался вопросом о том, почему загрузка текста в C++ не может быть такой же простой, как в современном текстовом редакторе? Если вам нравится направление движения Plywood и вы хотите, чтобы так и продолжалось, ваша поддержка на Patreon была бы признанием фреймворка.

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

NLP — кодирование текста: руководство для начинающих | Бишал Бозе | Analytics Vidhya

— В этом блоге мы разберемся, ЧТО такое кодирование текста ? КАК это сделать? А точнее ЗАЧЕМ его выполнять?

Источник: Google

Давайте сначала попробуем понять несколько основных правил…

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

ЗАЧЕМ кодировать текст?

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

ЧТО такое кодировка текста?

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

КАК кодировать текст для любой задачи НЛП?

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

— Кодирование на основе индексов
— Сумка слов (BOW)
— Кодирование Word2Vector
— Кодирование BERT

Поскольку это базовое объяснение кодирования текста НЛП, мы пропустим последние 2 метода, то есть Word2Vector и BERT, поскольку они являются довольно сложными и мощными реализациями Deep. Метод обучения на основе встраивания текста для преобразования текста в векторное кодирование.

Вы можете найти подробную информацию о Word2Vector в другом моем блоге, указанном здесь: НЛП — кодировка текста: Word2Vec

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

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

Пример: У нас есть 5 предложений, а именно: [“это хороший телефон», «это плохой мобильный», «она хорошая кошка», «у него плохой характер», «этот мобильный телефон плохой»]

Корпус данных: Это набор уникальных слов в нашем корпусе документов, т.е. в нашем случае это выглядит так:

[«а», «плохой», «кот», «хороший», «имеет», » он», «есть», «мобильный», «не», «телефон», «она», «нрав», «это»]

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

Это облегчит понимание и понимание интуиции, стоящей за этими методами.

Итак, давайте попробуем разобраться в каждом из них по порядку:

1. Кодирование на основе индекса:
Как следует из названия, на основе индекса нам обязательно нужно дать всем уникальным словам индекс, как мы отделили наш корпус данных, теперь мы можем индексировать их по отдельности, например …
a : 1
bad : 2
…
this : 13
Теперь, когда мы присвоили всем словам уникальный индекс, чтобы на основе индекса мы могли их однозначно идентифицировать, мы можем преобразовать наши предложения используя этот метод на основе индекса.
Очень просто понять, что мы просто заменяем слова в каждом предложении их соответствующими индексами.
Наш корпус документов становится следующим:
[13 7 1 4 10], [13 7 1 2 8], [11 7 1 4 3], [6 5 1 2 12], [13 8 10 7 9 4]
Теперь мы закодировали все слова порядковыми номерами, и это можно использовать в качестве входных данных для любой машины, поскольку машина понимает числа.
Но есть небольшая проблема, которую необходимо решить в первую очередь, а именно непротиворечивость ввода. Наши входные данные должны иметь ту же длину, что и наша модель, они не могут меняться. В реальном мире он может отличаться, но о нем нужно позаботиться, когда мы используем его в качестве входных данных для нашей модели.
Теперь, когда мы видим, что в первом предложении 5 слов, а в последнем предложении 6 слов, это вызовет дисбаланс в нашей модели.
Итак, чтобы решить эту проблему, мы делаем максимальное дополнение, что означает, что мы берем самое длинное предложение из нашего корпуса документов и дополняем другое предложение, чтобы оно было таким же длинным. Это означает, что если все мои предложения состоят из 5 слов, а одно предложение состоит из 6 слов, я составлю все предложения из 6 слов.
Как теперь добавить сюда это лишнее слово? Как в нашем случае добавить сюда этот дополнительный индекс?
Если вы заметили, мы не использовали 0 в качестве индекса, и желательно, чтобы он нигде не использовался, даже если у нас есть корпус данных длиной 100000 слов, поэтому мы используем 0 в качестве индекса заполнения. Это также означает, что мы ничего не добавляем к нашему фактическому предложению, поскольку 0 не представляет какое-либо конкретное слово, поэтому целостность наших предложений не нарушена.
Итак, наконец, наши кодировки на основе индекса выглядят следующим образом:
[13 7 1 4 10 0],
[13 7 1 2 8 0],
[11 7 1 4 3 0],
[ 6 5 1 2 12 0 ] ,
[ 13 8 10 7 9 4 ]
Таким образом мы сохраняем целостность нашего ввода и не нарушаем контекст наших предложений.
Кодирование на основе индекса учитывает информацию о последовательности в текстовом кодировании.
2. Пакет слов (BOW):
Пакет слов или BoW — это еще одна форма кодирования, при которой мы используем весь корпус данных для кодирования наших предложений. Это будет иметь смысл, когда мы на самом деле увидим, как это сделать.
Корпус данных:
[«а», «плохой», «кошка», «хороший», «имеет», «он», «есть», «мобильный», «не», «телефон», «она». », «temper», «this»]
Поскольку мы знаем, что наш корпус данных никогда не изменится, поэтому, если мы будем использовать это в качестве основы для создания кодировок для наших предложений, тогда мы будем иметь преимущество, чтобы не дополнять лишние слова.
Итак, первое предложение, которое у нас есть, звучит так: «это хороший телефон»
Как мы можем использовать весь корпус для представления этого предложения?
Таким образом, наше первое предложение становится комбинацией всех слов, которые у нас есть, и тех, которых у нас нет.
[1,0,0,1,0,0,1,0,0,1,0,0,1]
Вот как представлено наше первое предложение.
Теперь есть 2 вида ЛУК:
1. Бинарный ЛУК.
2. BOW
Разница между ними в том, что в Binary BOW мы кодируем 1 или 0 для каждого слова, появляющегося или не появляющегося в предложении. Мы не учитываем частоту появления слова в этом предложении.
В BOW мы также учитываем частоту появления каждого слова в этом предложении.
Допустим, наше текстовое предложение звучит так: «Это хороший телефон, это хороший мобильный телефон» (к вашему сведению, просто для справки)
Если вы посмотрите внимательно, мы посчитали, сколько раз слова «этот», «а», « есть» и «хорошо».
Это единственная разница между Binary BOW и BOW.
BOW полностью отбрасывает информацию о последовательности наших предложений.
3. Кодировка TF-IDF:
Частота термина — обратная частота документа
Как следует из названия, здесь мы даем каждому слову относительную частотность кодирования по отношению к текущему предложению и всему документу.
Частота термина: Встречаемость текущего слова в текущем предложении по отношению к общему количеству слов в текущем предложении.
Обратная частота данных: логарифм общего количества слов во всем корпусе данных по отношению к общему количеству предложений, содержащих текущее слово.
TF:
Term-Frequency
IDF:
Inverse-Data-Frequency
Здесь следует отметить одну вещь: мы должны рассчитать частотность каждого слова для этого конкретного предложения, потому что в зависимости от того, сколько раз слово встречается в предложение, значение TF может измениться, тогда как значение IDF остается постоянным до тех пор, пока не будут добавлены новые предложения.
Попробуем разобраться, экспериментируя:
Корпус данных: [«а», «плохой», «кот», «хороший», «имеет», «он», «есть», «мобильный», » не», «телефон», «она», «характер», «это»]
TF-IDF: «это» в предложении1: количество слов «это» в предложении1 / общее количество слов в предложении1
IDF: log(общее количество слов во всем корпусе данных/общее количество предложений, содержащих «это» слово)
TF : 1/5 = 0,2
IDF : loge(13/3) = 1,4663
TF-IDF : 0,2 * 1,4663 = 0,3226
Итак, мы связываем «это»: 0,3226; аналогичным образом мы можем найти TF-IDF для каждого слова в этом предложении, а затем остальная часть процесса остается такой же, как и BOW, здесь мы заменяем слово не частотой его появления, а скорее значением TF-IDF для этого слова.
Итак, давайте попробуем закодировать наше первое предложение: «это хороший телефон»
Как мы видим, мы заменили все слова, встречающиеся в этом предложении, на их соответствующие значения tf-idf, здесь следует отметить одну вещь: у нас есть аналогичные значения tf-idf для нескольких слов. Это редкий случай, который произошел с нами, так как у нас было мало документов, и почти все слова имели примерно одинаковые частоты.
И вот как мы достигаем кодирования текста TF-IDF.
Теперь попробуем реализовать их самостоятельно:
Это наш корпус документов, о котором говорилось выше. Я подправил данные, чтобы сделать их более понятными, это даст больше смысла в кодировках.
Вот как мы создаем наш корпус данных на основе любого имеющегося у нас корпуса документов.
Сначала мы узнаем максимальную длину предложения, а затем, используя наш корпус данных, мы кодируем весь наш текст с помощью схемы на основе индекса.
Внедрение бинарного BoW, где мы ставим 1 для каждого слова, встречающегося в предложении в корпусе данных, и 0 для остальных.
Реализуя BoW, здесь мы должны закодировать количество каждого вхождения слова в этом конкретном предложении в корпус данных и 0 для остальных.
Первое вычисление частоты каждого элемента в предложениях.
Создание функции для расчета tf-idf для каждого слова в конкретном предложении, которая использует ссылку на созданные выше частоты.
Наконец-то созданы векторы tf-idf для нашего модуля.
CountVectorizer из модуля Scikit-Learn дает нам представление текста BoW. Мы можем использовать различные параметры для расчета бинарного BoW или BoW и многих других настроек.
TfidfVectorizer из модуля Scikit-Learn дает нам представления TF-IDF кодировки текста, подобно CountVectorizer, мы можем установить множество параметров для преобразования.
Значения будут немного отличаться, так как мы реализовали базовую версию TF-IDF. В библиотеке Scikit-learn они реализуют TF-IDF разными методами, поэтому мы видим такие различия, в остальном более-менее одно и то же.
Итак, вот оно: основные реализации кодирования текста НЛП.
Вы можете найти код по моей ссылке на GitHub здесь .
Следующий раздел: НЛП — Кодировка текста: Word2Vec
Спасибо за прочтение!
Если вы хотите узнать больше по похожим темам или посмотреть, что еще я могу предложить, обязательно посетите мой веб-сайт: Все о вещах
Готовы перейти на новый уровень обучения? Ознакомьтесь с курсами, которые я могу предложить: Курсы
Стресс в жизни и на работе? Найдите минутку, чтобы расслабиться и отдохнуть с моими успокаивающими и расслабляющими видео! Зайдите на мой канал прямо сейчас и начните свое путешествие к внутреннему миру и спокойствию с «Транквилизатором души»
Что такое кодировка символов
Кодировка символов
Кодировка символов сообщает компьютеру, как интерпретировать необработанные нули и единицы в реальные символы. Обычно он делает это, соединяя числа с символами. Слова и предложения в тексте создаются из символов, и эти символы группируются в набор символов. В настоящее время существует множество различных типов кодировок символов, но наиболее часто мы имеем дело с кодировками ASCII, 8-битными кодировками и кодировками на основе Unicode.
ASCII-код
Американский стандартный код для обмена информацией (ASCII) — это схема кодирования символов, и это был первый стандарт кодирования символов. Это код для представления английских символов в виде чисел, где каждой букве присвоен номер от 0 до 127. Большинство современных схем кодирования символов основаны на ASCII, хотя они поддерживают множество дополнительных символов. Это однобайтовая кодировка, использующая только нижние 7 бит. В файле ASCII каждый буквенный, числовой или специальный символ представлен 7-битным двоичным числом 9.0009
АНСИ
Коды

ANSI (Американский национальный институт стандартов) представляют собой стандартизированные числовые или буквенные коды, выпущенные Американским национальным институтом стандартов для обеспечения единообразной идентификации географических объектов во всех федеральных государственных учреждениях. Более 90 лет она выступала в качестве координатора системы добровольной стандартизации частного сектора США. По сути, это расширение набора символов ASCII, поскольку оно включает все символы ASCII с дополнительными 128 кодами символов. ASCII просто определяет 7-битную кодовую страницу со 128 символами. ANSI расширяет это до 8 бит, и существует несколько разных кодовых страниц для символов от 128 до 255.

Юникод
Unicode — это стандарт, определяющий внутреннюю систему кодирования текста почти во всех операционных системах, используемых в компьютерах в настоящее время, будь то Windows, Unix, Macintosh, Linux или что-то еще, потому что Unicode может обрабатывать символы почти всех современных языков и даже некоторых древних. языков одновременно, если у клиента есть шрифты для конкретного языка, установленные в его системе.
УТФ
Unicode присваивает каждому символу уникальный номер или кодовую точку. Он определяет два метода сопоставления: кодировку UTF (формат преобразования Unicode) и кодировку UCS (универсальный набор символов).