История
Первоначально компьютерные системы и языки системного программирования не делали различия между символами и байтами : для сегментных сценариев, используемых в большей части Африки, Америки, Южной и Юго-Восточной Азии, Ближнего Востока и Европы, для символа требуется всего один байт. , но два или более байта необходимы для идеографических наборов, используемых в остальном мире. Впоследствии это привело к большой путанице. Программное обеспечение и системы Microsoft, предшествующие линейке Windows NT, являются примерами этого, поскольку они используют кодовые страницы OEM и ANSI, которые не делают различий.
С конца 1990-х годов программное обеспечение и системы приняли Unicode в качестве предпочтительного формата хранения; эта тенденция была улучшена благодаря широкому распространению XML , который обеспечивает более адекватный механизм для маркировки используемой кодировки. Последние продукты Microsoft и интерфейсы прикладных программ используют Unicode внутри, но многие приложения и API продолжают использовать кодировку по умолчанию «локали» компьютера при чтении и записи текстовых данных в файлы или стандартный вывод. Таким образом, файлы могут быть разборчивыми и разборчивыми в одной части мира, а моджибаке — в другой — неразборчивыми .
UTF-8, UTF-16
Microsoft решила принять 16-битную (двухбайтовую) систему UTF-16 для всех своих операционных систем, начиная с Windows NT. Этот метод однозначно кодирует все символы Unicode в базовой многоязычной плоскости и 32-битный (четырехбайтовый) код для других, но остальная часть отрасли ( Unix-подобные системы и Интернет) выбрали UTF-8 (который использует один байт для 7-битный набор символов ASCII , два или три байта для других символов в BMP и четыре байта для остатка). Начиная с Windows 10 версии 1803 , компьютеры с Windows можно настроить так, чтобы разрешить UTF-8 в качестве кодовой страницы «ANSI» и OEM.
UTF-32
BOM – 00 00 FE FF (для BE) или FF FE 00 00 (для LE).
О кодировках и кодовых страницах
Вряд ли это сейчас сильно актуально, но может кому-то покажется интересным (или просто вспомнит былые годы).
Интересно, что примерно год назад проблема кодировок ненадолго всплыла при «наезде» ФАС на сотовых операторов, мол те дискриминируют русскоязычных пользователей, поскольку за передачу кириллицы берут больше. Это объясняется техническим решением, выбранным разработчиком протокола SMS связи. Если бы его россияне разработали, они бы, возможно, отдали приоритет кириллице. В указанной статье «начальник управления контроля транспорта и связи Дмитрий Рутенберг отметил, что существуют и восьмибитные кодировки для кириллицы, которые могли бы использовать операторы.» Во как — на улице 21-й век, Unicode шагает по миру, а господин Рутенберг тянет нас в начало 90-х, когда шла «война кодировок» и проблема перекодировок стояла во весь рост. Интересно, в какой кодировке должен получить СМС Вася Пупкин, пользующийся финским телефоном, находящийся в Турции на отдыхе, от жены с корейским телефоном, отправляющей СМС из Казахстана? А от своего французского компаньона (с японским телефоном), находящегося в Испании? Думаю, никакой начальник ответа на этот вопрос дать не сможет. К счастью, это «экономное» предложение не воплотилось в жизнь.
Юный читатель может спросить — а что помешало сразу использовать Unicode, зачем были придуманы эти заморочки с кодовыми страницами? Думаю, дело в финансовой стороне проблемы. Unicode требует в 2 раза больше памяти, а память стоит денег (и дисковая и ОЗУ). Стал бы американец покупать компьютер на 1-2 тыс дороже из-за того, что «теперь новая ОС требует больше памяти, но позволяет без проблем работать с русским, европейскими, арабскими языками»? Боюсь, простой англоязычный покупатель воспринял бы такой аргумент «неадекватно» (и обратился бы к другим производителям).
Как я могу определить кодировку / кодовую страницу текстового файла
В нашем приложении мы получаем текстовые файлы (.txt, .csv и т.д.) из разных источников. При чтении эти файлы иногда содержат мусор, потому что файлы, созданные в другой/неизвестной кодовой странице.
Есть ли способ (автоматически) определить кодовую страницу текстового файла?
detectEncodingFromByteOrderMarks, в конструкторе StreamReader работает для UTF8 и других отмеченных в Unicode файлов, но я ищу способ обнаружения кодовых страниц, например ibm850, windows1252.
Спасибо за ваши ответы, вот что я сделал.
Файлы, которые мы получаем, принадлежат конечным пользователям, они не имеют понятия о кодовых страницах. Приемники также являются конечными пользователями, и теперь это то, что они знают о кодовых страницах: Codepages существуют и раздражают.
- Откройте полученный файл в “Блокноте”, посмотрите на искаженный фрагмент текста. Если кого-то зовут Франсуа или что-то, с вашим человеческим интеллектом, вы можете догадаться об этом.
- Я создал небольшое приложение, которое пользователь может использовать для открытия файла, и введите текст, который пользователь знает, что он появится в файле, когда будет использована правильная кодовая страница.
- Прокрутите все кодовые страницы и отобразите те, которые дают решение с предоставленным пользователем текстом.
- Если по мере появления одной кодовой страницы попросите пользователя указать больше текста.
18 сен. 2008, в 08:49
Вы не можете обнаружить кодовую страницу, вам нужно сказать об этом. Вы можете анализировать байты и угадывать их, но это может дать некоторые странные (иногда забавные) результаты. Я не могу найти его сейчас, но я уверен, что Блокнот можно обмануть, показывая английский текст на китайском языке.
В любом случае, это то, что вам нужно прочитать:
Абсолютный минимум Каждый разработчик программного обеспечения Абсолютно, положительно должен знать о Unicode и наборах символов (нет оправданий!).
В частности, Джоэл говорит:
Самый важный факт о кодировании
Если вы полностью забудете все, что я только что объяснил, помните один чрезвычайно важный факт. Не имеет смысла иметь строку, не зная, какую кодировку она использует. Вы больше не можете засунуть голову в песок и притвориться, что “простой” текст – ASCII. Нет такой вещи, как обычный текст.
Если у вас есть строка, в памяти, в файле или в сообщении электронной почты, вы должны знать, в какой кодировке она находится, или вы не можете ее интерпретировать или правильно отобразить.
Вы пробовали порт С# для универсального детектора Charset Mozilla
Пример из http://code.google.com/p/ude/
Это явно неверно. Каждый веб-браузер имеет какой-то универсальный детектор штриховок для обработки страниц, которые не имеют никаких указаний на кодировку. У Firefox есть одно. Вы можете загрузить код и посмотреть, как он это делает. См. Документацию здесь. В принципе, это эвристика, но она работает очень хорошо.
Учитывая разумный объем текста, можно даже обнаружить язык.
Вот еще один, который я только что нашел с помощью Google:
Я знаю это очень поздно для этого вопроса, и это решение не понравится некоторым (из-за его предвзятости, ориентированной на английский язык, и его отсутствия статистического/эмпирического тестирования), но для меня это очень хорошо работало, особенно для обработки загруженных Данные CSV:
- Встроенное обнаружение спецификации
- Настройка по умолчанию/резервное кодирование настраивается
- довольно надежный (по моему опыту) для западноевропейских файлов, содержащих некоторые экзотические данные (например, французские имена) со смесью файлов UTF-8 и Latin-1 – в основном основная часть американской и западной европейской сред.
Примечание: Я тот, кто написал этот класс, поэтому, очевидно, возьмите его с солью!:)
В поисках другого решения я обнаружил, что
это решение очень тяжелое.
Мне нужно некоторое базовое определение кодировки, основанное на 4 первых байтах и, возможно, обнаружении charset-кода xml, поэтому я взял некоторый образец исходного кода из Интернета и добавил слегка измененную версию
написанный для Java.
Достаточно прочитать первые 1024 байта из файла, но я загружаю весь файл.
Notepad ++ имеет эту функцию из коробки. Он также поддерживает его изменение.
Если кто-то ищет решение на 93,9%. Это работает для меня:
Я сделал что-то подобное в Python. В принципе, вам нужно много выборочных данных из разных кодировок, которые разбиваются на скользящее двухбайтовое окно и хранятся в словаре (хэш), на основе байтовых пар, предоставляющих значения списков кодировок.
Учитывая этот словарь (хэш), вы берете текст ввода и:
- если он начинается с любого символа спецификации (‘ xfeÿ’ для UTF-16-BE, ‘ xffþ’ для UTF-16-LE, ‘ xef»¿’ для UTF-8 и т.д.), Я рассматриваю его как предложенный
- если нет, то возьмите достаточно большой образец текста, возьмите все байтовые пары образца и выберите кодировку, которая является наименее распространенной из словаря.
Если вы также выбрали UTF-кодированные тексты, которые не запускаются с какой-либо спецификацией, второй шаг будет охватывать те, которые проскальзывали с первого шага.
Пока это работает для меня (образцы данных и последующие входные данные являются субтитрами на разных языках) с уменьшением частоты ошибок.
Конструктор класса StreamReader принимает параметр “обнаружить кодирование”.
Инструмент “uchardet” делает это хорошо, используя модели распределения частоты символов для каждой кодировки. Большие файлы и более “типичные” файлы имеют большую уверенность (очевидно).
На ubuntu вы просто apt-get install uchardet.
В других системах получите источник, использование и документы здесь: https://github.com/BYVoid/uchardet
Если вы можете подключиться к библиотеке C, вы можете использовать libenca. См. http://cihar.com/software/enca/. На странице man:
Enca считывает заданные текстовые файлы или стандартный ввод, если ни один не указан, и использует знания об их языке (должен поддерживаться вами) и смесь парсинга, статистического анализа, угадывания и черной магии для определения их кодировок.
Это GPL v2.
Как аддон к сообщению ITmeze, я использовал эту функцию для преобразования вывода порта С# для универсального детектора Charset Mozilla
Итак, где я впервые делал:
Файл StreamReader = File.OpenText(fullfilename);
Мне пришлось изменить его на:
Файл StreamReader = новый StreamReader (fullfilename, System.Text.Encoding.UTF7);
вы также можете создать StreamReader, как это
новый StreamReader (fullfilename, true), второй параметр означает, что он должен попытаться обнаружить кодировку из byteordermark файла, но это не сработало в моем случае.
Поскольку он в основном сводится к эвристике, он может помочь использовать кодировку ранее полученных файлов из того же источника, что и первый подсказку.
Большинство людей (или приложений) делают вещи практически в одном и том же порядке каждый раз, часто на одной машине, поэтому вполне вероятно, что когда Боб создает файл .csv и отправляет его в Mary, он всегда будет использовать Windows -1252 или независимо от того, на что его машина по умолчанию.
По возможности немного тренировок клиентов никогда не повредит: -)
Получил ту же проблему, но не нашел хорошего решения, но обнаружил его автоматически.
Теперь я использую PsPad (www.pspad.com) для этого;) Хорошо работает
Я использую этот код для обнаружения Unicode и кодовой страницы ansi по умолчанию Windows при чтении файла. Для других кодировок необходима проверка содержимого, вручную или путем программирования. Это может использоваться для сохранения текста с той же кодировкой, что и при его открытии. (Я использую VB.NET)
‘Works for Default and unicode (auto detect)
Dim mystreamreader As New StreamReader(LocalFileName, Encoding.Default)
MyEditTextBox.Text = mystreamreader.ReadToEnd()
Debug.Print(mystreamreader.CurrentEncoding.CodePage) ‘Autodetected encoding
mystreamreader.Close()
Ещё вопросы
Наборы символов HP
Компания HP разработала серию наборов символов (каждый со своим соответствующим кодом набора символов) для кодирования либо собственных наборов символов, либо наборов символов других поставщиков. Обычно это 7-битные наборы символов, которые при перемещении в верхнюю часть и связанные с набором символов ASCII составляют 8-битные наборы символов.
Собственные наборы символов HP
В данной статье пойдёт речь о кодировках в Windows. Все в жизни хоть раз использовали и писали консольные приложения как таковые. Нету разницы для какой причины. Будь-то выбивание процесса или же просто написать «Привет. Я не могу сделать кодировку нормальной, поэтому я смотрю эту статью!».
Тем, кто ещё не понимает, о чём проблема, то вот Вам:
А тут было написано:
Но никто ничего не понял.
В любом случае в Windows до 10 кодировка BAT и других языков, не использует кодировку поддерживающую Ваш язык, поэтому все русские символы будут писаться неправильно.
1. Настройка консоли в батнике
Сразу для тех, кто пишет chcp 1251 лучше написать это:
Первый способ устранения проблемы, это Notepad++. Для этого Вам нужно открыть Ваш батник таким способом:
Не бойтесь, у Вас откроется код Вашего батника, а затем Вам нужно будет сделать следующие действия:
Если Вам ничего не помогло, то преобразуйте в UTF-8 без BOM.
2. Написание консольных программ Нередко люди пишут консольные программы(потому что на некоторых десктопные писать невозможно), а кодировка частая проблема.
Первый способ непосредственно Notepad++, но а если нужно сначала одну кодировку, а потом другую?
Сразу для использующих chcp 1251 пишите это:
Второй способ это написать десктопную программу, или же использовать Visual Studio. Если же не помогает, то есть первое: изменение кодировки вывода(Пример на C++).
Если же не сработает:
3. Изменение chcp 1251 Если же у Вас батник, то напишите в начало:
Теперь у Нас будет нормальный вывод в консоль. На других языках (С++):
4. Сделать жизнь мёдом При использовании данного способа Вы не сможете:
- Спасти мир от данной проблемы
- Думать о других людях
- Разрабатывать десктопные приложения, так как Вам жизнь покажется мёдом
Установить Windows 10. Там кодировка консоли специально подходит для языка страны, и Вам больше не нужно будет беспокоиться об этой проблеме. Но у Вас появится ещё 6 проблем, и вернуться к предыдущей лицензионной версии Windows Вы не сможете.
Кодовые страницы таблиц преобразования windows
Где в Windows 7 кодовые страницы таблиц преобразования находятся?
я имею ввиду окно со списком кодировок, в Windows XP — «Язык и региональные стандарты» вкладка «Дополнительно», в Windows 7 — там такого нет
как нет , есть кнопка «изменить язык системы»
Да вряд ли, ее много лет уже юзают, подобного рода проблема была года 4 назад, тогда у человека были сброшены (не были отмечены) кодовые страницы для кириллицы.
Номенклатура и стандартизация[править]
В отличие от кодировок символов вообще, которым присваиваются имена (нередко включающие числовые обозначения), поставщики компьютерной техники присваивают кодовым страницам номера, что приводит к обозначениям типа code page nnn (или, сокращённо, CPnnn).
В каталоге от IBM соответствие между (меняющимися от издания к издания) номерами страниц и (постоянными) номерами кодовых страниц было утрачено. Microsoft первоначально использовала IBM’овские номера, однако страницы от IBM и от Microsoft не совпадают в точности. Поддержание совместимости прекратилась в результате враждебных отношений между двумя корпорациями в 1990-х годах. Стандартное обозначение кодовых страниц от Microsoft включает слово «Windows-».
Фирма Oracle поддерживала свой, отдельный каталог кодовых страниц.
Фирма Hewlett Packard также использовала номерные наборы символов, идентичные описанным выше или похожие на них, но фирменная терминология отличалась от таковой от IBM и Microsoft и словосочетание «кодовая страница» в документации HP не фигурировало.
Интернет-организация IANA «узаконила» большинство документированных кодовых страниц в ходе «регистрации» (то есть, стандартизации) кодировок текста вообще.
Кодовые страницы IBM
Эти кодовые страницы используются IBM в наборах символов EBCDIC для мэйнфреймы.
Кодовые страницы DOS
Эти кодовые страницы используются IBM в своих ПК DOS Операционная система. Эти кодовые страницы изначально были встроены непосредственно в текстовый режим аппаратное обеспечение графических адаптеров, используемых с IBM PC и его клоны, включая оригинальные адаптеры MDA и CGA, наборы символов которых можно было изменить только путем физической замены микросхемы ПЗУ, содержащей шрифт. Интерфейс этих адаптеров (эмулируемый всеми более поздними адаптерами, такими как VGA) обычно ограничивался однобайтовыми наборами символов, содержащими всего 256 символов в каждом шрифте / кодировке (хотя VGA добавила частичную поддержку для немного больших наборов символов).
При работе со старым оборудованием, протоколами и форматами файлов часто бывает необходимо поддерживать эти кодовые страницы, но для новых проектов рекомендуется использовать новые системы кодирования, в частности Unicode.
Кодовые страницы IBM AIX
Эти кодовые страницы используются IBM в своих AIX Операционная система. Они эмулируют несколько наборов символов, а именно те, которые предназначены для использования в соответствии с ISO, например, в UNIX-подобных операционных системах.
Кодовая страница 819 идентична Latin-1, ИСО / МЭК 8859-1 и с немного измененными командами позволяет машинам MS-DOS использовать эту кодировку. Он использовался с миникомпьютерами IBM AS / 400.
Кодовые страницы IBM OS / 2
Эти кодовые страницы используются IBM в своих OS / 2 Операционная система.
Кодовые страницы эмуляции Windows
Эти кодовые страницы используются IBM при эмуляции Майкрософт Виндоус наборы символов. Большинство этих кодовых страниц имеют тот же номер, что и кодовые страницы Microsoft, хотя они не именно так идентичный. Однако некоторые кодовые страницы являются новинками IBM, а не Microsoft.
Кодовые страницы эмуляции Macintosh
Эти кодовые страницы используются IBM при эмуляции Apple Macintosh наборы символов.
Кодовые страницы эмуляции Adobe
Эти кодовые страницы используются IBM при эмуляции Adobe наборы символов.
Кодовые страницы эмуляции HP
Эти кодовые страницы используются IBM при эмуляции HP наборы символов.
- 1050 – Расширение HP Roman
- 1051 – HP Роман-8
- 1052 – HP Gothic Legal
- 1053 – HP Gothic-1 (почти такой же, как ISO 8859-1 )
- 1054 – HP ASCII
- 1055 – HP PC-Line
- 1056 – Рисование линий HP
- 1057 – HP PC-8 (почти такой же, как кодовая страница 437 )
- 1058 – HP PC-8DN (нет такой же как кодовая страница 865 )
- 1351 – Японский набор символов DBCS HP
- 5039 – Японский MIX (1041 + 1351 )
Кодовые страницы эмуляции DEC
Эти кодовые страницы используются IBM при эмуляции DEC наборы символов.
Кодовые страницы IBM Unicode
- 1445 – IBM AFP PUA № 1
- 1448 – UCS-BMP (Универсальный УДК)
- 1449 – IBM PUA по умолчанию
Внешняя ссылка
- Глоссарий IBM CDRA
- Кодовые страницы IBM на Wayback Machine (архивировано 05 февраля 2016 г.)
- Кодовые страницы IBM по схеме кодирования на Wayback Machine (Архивировано 06 сентября 2009 г.)
- Информация о кодировке IBM / ICU
- Идентификаторы кодовой страницы Microsoft (Список Microsoft содержит только кодовые страницы, активно используемые обычными приложениями в Windows. См. Также Список Торстена Мохрина для полного списка поддерживаемых кодовых страниц)
- Наборы символов и кодовые страницы одним нажатием кнопки
- Команда Microsoft Chcp: отображение и установка активной кодовой страницы консоли
Ничего из вышеперечисленного
Microsoft настоятельно рекомендует использовать Unicode в современных приложениях, но многие приложения или файлы данных по-прежнему зависят от устаревших кодовых страниц.
- Программы должны знать, какую кодовую страницу использовать, чтобы правильно отображать содержимое файлов (до Unicode). Если программа использует неправильную кодовую страницу, она может отображать текст как моджибаке .
- Используемая кодовая страница может отличаться на разных машинах, поэтому файлы (до Unicode), созданные на одной машине, могут быть нечитаемыми на другой.
- Данные часто неправильно помечены кодовой страницей или вообще не помечены, что затрудняет определение правильной кодовой страницы для чтения данных.
- Эти кодовые страницы Microsoft в разной степени отличаются от некоторых стандартов и реализаций других поставщиков. Это не проблема Microsoft как таковая , как это происходит со всеми поставщиками, но отсутствие согласованности делает взаимодействие с другими системами в некоторых случаях ненадежным.
- Использование кодовых страниц ограничивает набор символов, которые могут использоваться.
- Символы, выраженные в неподдерживаемой кодовой странице, могут быть преобразованы в вопросительные знаки (?) Или другие заменяющие символы или в более простую версию (например, удаление диакритических знаков из буквы). В любом случае исходный персонаж может быть утерян.
Использование в системах DOS[править]
Кодовые страницы ANSI (официально называемые «кодовыми страницами Windows» после того, как Microsoft приняла неправильное употребление первого термина) используются для приложений, не поддерживающих Unicode (скажем, ориентированных на байты ), использующих графический пользовательский интерфейс в системах Windows. «ANSI» — неправильное название, потому что поведение не совсем соответствует стандарту ANSI и потому, что в эти 8-битные кодовые страницы включены некоторые кодировки, отличные от стандарта ANSI.
Большинство устаревших кодовых страниц «ANSI» имеют номера кодовых страниц в шаблоне 125x. Тем не менее, 874 (тайский) и восточноазиатские многобайтовые кодовые страницы ANSI ( 932 , 936 , 949 , 950 ), все из которых также используются в качестве кодовых страниц OEM, пронумерованы для соответствия аналогичным (но не идентичным) кодовым страницам IBM. кодировки. Хотя кодовая страница 1258 также используется как кодовая страница OEM, она является оригинальной для Microsoft, а не расширением существующей кодировки. IBM присвоила свои собственные, разные номера вариантам Microsoft, они приведены для справки в приведенных ниже списках, где это применимо.
Все кодовые страницы Windows 125x, а также 874 и 936, помечены Internet Assigned Numbers Authority (IANA) как « номер Windows», хотя «Windows-936» рассматривается как синоним « GBK ». Кодовая страница Windows 932 вместо этого помечена как «Windows-31J».
Кодовые страницы ANSI Windows, и особенно кодовая страница 1252 , были так названы, поскольку они якобы основывались на черновиках, представленных или предназначенных для ANSI. Однако ANSI и ISO не стандартизировали ни одну из этих кодовых страниц. Вместо этого они либо:
- Надмножества стандартных наборов, таких как ISO 8859 и различных национальных стандартов (например, Windows-1252 и ISO-8859-1 ),
- Основные их модификации (делающие их несовместимыми в разной степени, например, Windows-1250 и ISO-8859-2 )
- Отсутствие параллельного кодирования (например, Windows-1257 против ISO-8859-4 ; ISO-8859-13 был введен намного позже). Кроме того, Windows-1251 не следует ни ISO-стандартизированному ISO-8859-5, ни преобладающему в то время KOI-8 .
Microsoft присвоила около двенадцати типографских и деловых символов (включая, в частности, знак евро , €) в CP1252 кодовые точки 0x80–0x9F, которые в ISO 8859 присвоены управляющим кодам C1 . Эти назначения также присутствуют во многих других кодовых страницах ANSI / Windows в тех же кодовых точках. Windows не использовала управляющие коды C1, поэтому это решение не имело прямого влияния на пользователей Windows. Однако при включении в файл, передаваемый на совместимую со стандартами платформу, такую как Unix или MacOS, информация была невидимой и потенциально опасной.
