Windows 1251 в utf 8: windows-1251 UTF-8 PHP incov

html — Отличие кодировки windows-1251 от utf-8

html — Отличие кодировки windows-1251 от utf-8 — Stack Overflow на русском

Stack Overflow на русском — это сайт вопросов и ответов для программистов. Присоединяйтесь! Регистрация займёт не больше минуты.

Присоединиться к сообществу

Любой может задать вопрос

Любой может ответить

Лучшие ответы получают голоса и поднимаются наверх

Вопрос задан
9 лет 8 месяцев назад

Просмотрен
25k раз

Чем отличается и когда и где лучше применять один или другой:

<meta http-equiv="Content-Type" content="text/html; charset=windows-1251">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

Mirdin

5,76111 золотой знак1919 серебряных знаков2929 бронзовых знаков

задан 28 окт ’11 в 17:11

ZowZow

2,4082020 золотых знаков4343 серебряных знака8989 бронзовых знаков

5

Разница в том, что на UTF-8 — два байта, а на windows-1251 — один байт. Поэтому текст в Юникоде больше места занимает. А вообще при прочих равных лучше всегда использовать UTF-8 это сильно облегчает разработку под разные языки.

ответ дан 28 окт ’11 в 18:24

stanislavstanislav

33.6k2222 золотых знака8888 серебряных знаков206206 бронзовых знаков

6

Highly active question. Earn 10 reputation (not counting the association bonus) in order to answer this question. The reputation requirement helps protect this question from spam and non-answer activity.

lang-html

Stack Overflow на русском лучше работает с включенным JavaScript

Ваша конфиденциальность

Нажимая «Принять все файлы cookie» вы соглашаетесь, что Stack Exchange может хранить файлы cookie на вашем устройстве и раскрывать информацию в соответствии с нашей [Политикой в отношении файлов cookie] (https://stackoverflow.com/legal/cookie-policy).

Принять все файлы cookie



Настроить параметры

Модуль ngx_http_charset_module

Модуль ngx_http_charset_module

Модуль ngx_http_charset_module добавляет указанную
кодировку в поле “Content-Type” заголовка ответа.
Кроме того, модуль может перекодировать данные из одной кодировки в другую
с некоторыми ограничениями:

• перекодирование осуществляется только в одну сторону — от сервера к клиенту,
• перекодироваться могут только однобайтные кодировки
• или однобайтные кодировки в UTF-8 и обратно.

Пример конфигурации

include        conf/koi-win;

charset        windows-1251;
source_charset koi8-r;

Директивы

charset off;

Добавляет указанную кодировку в поле “Content-Type”
заголовка ответа.
Если эта кодировка отличается от указанной в директиве
source_charset, то выполняется перекодирование.

Параметр off отменяет добавление кодировки
в поле “Content-Type” заголовка ответа.

Кодировка может быть задана с помощью переменной:

charset $charset;

В этом случае необходимо, чтобы все возможные значения переменной
присутствовали хотя бы один раз в любом месте конфигурации в виде
директив charset_map, charset или
source_charset.
Для кодировок utf-8, windows-1251
и koi8-r для этого достаточно включить в конфигурацию
файлы conf/koi-win, conf/koi-utf и
conf/win-utf.
Для других кодировок можно просто сделать фиктивную таблицу перекодировки,
например:

charset_map iso-8859-5 _ { }

Кроме того, кодировка может быть задана в поле “X-Accel-Charset”
заголовка ответа.
Эту возможность можно запретить с помощью директив
proxy_ignore_headers,
fastcgi_ignore_headers,
uwsgi_ignore_headers,
scgi_ignore_headers
и
grpc_ignore_headers.

Описывает таблицу перекодирования из одной кодировки в другую.
Таблица для обратного перекодирования строится на основании тех же данных.
Коды символов задаются в шестнадцатеричном виде.
Неописанные символы в пределах 80-FF заменяются на “?”.
При перекодировании из UTF-8 символы, отсутствующие в однобайтной кодировке,
заменяются на “&#XXXX;”.

Пример:

charset_map koi8-r windows-1251 {
    C0 FE ; # small yu
    C1 E0 ; # small a
    C2 E1 ; # small b
    C3 F6 ; # small ts
    ...
}

При описании таблицы перекодирования в UTF-8, коды кодировки UTF-8 должны
быть указаны во второй колонке, например:

charset_map koi8-r utf-8 {
    C0 D18E ; # small yu
    C1 D0B0 ; # small a
    C2 D0B1 ; # small b
    C3 D186 ; # small ts
    ...
}

Полные таблицы преобразования из koi8-r в
windows-1251 и из koi8-r и
windows-1251 в utf-8
входят в дистрибутив и находятся в файлах conf/koi-win,
conf/koi-utf и conf/win-utf.

charset_types text/html text/xml text/plain text/vnd.wap.wml
application/javascript application/rss+xml;

Эта директива появилась в версии 0.7.9.

Разрешает работу модуля в ответах с указанными MIME-типами
в дополнение к “text/html”.
Специальное значение “*” соответствует любому MIME-типу
(0.8.29).

До версии 1.5.4 по умолчанию вместо MIME-типа
“application/javascript” использовался
“application/x-javascript”.

override_charset off;

Определяет, выполнять ли перекодирование для ответов,
полученных от проксированного сервера или от FastCGI/uwsgi/SCGI/gRPC-сервера,
если в ответах уже указана кодировка в поле “Content-Type”
заголовка ответа.
Если перекодирование разрешено, то в качестве исходной кодировки
используется кодировка, указанная в полученном ответе.

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

Задаёт исходную кодировку ответа.
Если эта кодировка отличается от указанной в директиве
charset, то выполняется перекодирование.

PostgreSQL : Документация: 10: 23.3. Поддержка кодировок : Компания Postgres Professional

23.3. Поддержка кодировок

Поддержка кодировок в PostgreSQL позволяет хранить текст в различных кодировках, включая однобайтовые кодировки, такие как входящие в семейство ISO 8859 и многобайтовые кодировки, такие как EUC (Extended Unix Code), UTF-8 и внутренний код Mule. Все поддерживаемые кодировки могут прозрачно использоваться клиентами, но некоторые не поддерживаются сервером (в качестве серверной кодировки). Кодировка по умолчанию выбирается при инициализации кластера базы данных PostgreSQL при помощи initdb. Она может быть переопределена при создании базы данных, что позволяет иметь несколько баз данных с разными кодировками.

Важным ограничением, однако, является то, что кодировка каждой базы данных должна быть совместима с параметрами локали базы данных LC_CTYPE (классификация символов) и LC_COLLATE (порядок сортировки строк). Для локали C или POSIX подойдёт любой набор символов, но для других локалей, предоставляемых библиотекой libc, есть только один набор символов, который будет работать правильно. (Однако в среде Windows кодировка UTF-8 может использоваться с любой локалью.) Если у вас включена поддержка ICU, локали, предоставляемые библиотекой ICU, можно использовать с большинством (но не всеми) кодировками на стороне сервера.

23.3.1. Поддерживаемые кодировки

Таблица 23.1 показывает кодировки, доступные для использования в PostgreSQL.

Таблица 23.1. Кодировки PostgreSQL

Не все клиентские API поддерживают все перечисленные кодировки. Например, драйвер интерфейса JDBC PostgreSQL не поддерживает MULE_INTERNAL, LATIN6, LATIN8 и LATIN10.

Поведение кодировки SQL_ASCII существенно отличается от других. Когда набором символов сервера является SQL_ASCII, сервер интерпретирует значения от 0 до 127 байт согласно кодировке ASCII, тогда как значения от 128 до 255 воспринимаются как незначимые. Перекодировка не будет выполнена при выборе SQL_ASCII. Таким образом, этот вариант является не столько объявлением того, что используется определённая кодировка, сколько объявлением того, что кодировка игнорируется. В большинстве случаев, если вы работаете с любыми данными, отличными от ASCII, не стоит использовать SQL_ASCII, так как PostgreSQL не сможет преобразовать или проверить символы, отличные от ASCII.

23.3.2. Настройка кодировки

initdb определяет кодировку по умолчанию для кластера PostgreSQL. Например,

initdb -E EUC_JP

настраивает кодировку по умолчанию на EUC_JP (Расширенная система кодирования для японского языка). Можно использовать --encoding вместо -E в случае предпочтения более длинных имён параметров. Если параметр -E или --encoding не задан, initdb пытается определить подходящую кодировку в зависимости от указанной или заданной по умолчанию локали.

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

createdb -E EUC_KR -T template0 --lc-collate=ko_KR.euckr --lc-ctype=ko_KR.euckr korean

Это создаст базу данных с именем korean, которая использует кодировку EUC_KR и локаль ko_KR. Также, получить желаемый результат можно с помощью данной SQL-команды:

CREATE DATABASE korean WITH ENCODING 'EUC_KR' LC_COLLATE='ko_KR.euckr' LC_CTYPE='ko_KR.euckr' TEMPLATE=template0;

Заметьте, что приведённые выше команды задают копирование базы данных template0. При копировании любой другой базы данных, параметры локали и кодировку исходной базы изменить нельзя, так как это может привести к искажению данных. Более подробное описание приведено в Разделе 22.3.

Кодировка базы данных хранится в системном каталоге pg_database. Её можно увидеть при помощи параметра psql -l или команды \l.

$ psql -l
                                         List of databases
   Name    |  Owner   | Encoding  |  Collation  |    Ctype    |          Access Privileges          
-----------+----------+-----------+-------------+-------------+-------------------------------------
 clocaledb | hlinnaka | SQL_ASCII | C           | C           | 
 englishdb | hlinnaka | UTF8      | en_GB.UTF8  | en_GB.UTF8  | 
 japanese  | hlinnaka | UTF8      | ja_JP.UTF8  | ja_JP.UTF8  | 
 korean    | hlinnaka | EUC_KR    | ko_KR.euckr | ko_KR.euckr | 
 postgres  | hlinnaka | UTF8      | fi_FI.UTF8  | fi_FI.UTF8  | 
 template0 | hlinnaka | UTF8      | fi_FI.UTF8  | fi_FI.UTF8  | {=c/hlinnaka,hlinnaka=CTc/hlinnaka}
 template1 | hlinnaka | UTF8      | fi_FI.UTF8  | fi_FI.UTF8  | {=c/hlinnaka,hlinnaka=CTc/hlinnaka}
(7 rows)

Важно

На большинстве современных операционных систем PostgreSQL может определить, какая кодировка подразумевается параметром LC_CTYPE, что обеспечит использование только соответствующей кодировки базы данных. На более старых системах необходимо самостоятельно следить за тем, чтобы использовалась кодировка, соответствующая выбранной языковой среде. Ошибка в этой области, скорее всего, приведёт к странному поведению зависимых от локали операций, таких как сортировка.

PostgreSQL позволит суперпользователям создавать базы данных с кодировкой SQL_ASCII, даже когда значение LC_CTYPE не установлено в C или POSIX. Как было сказано выше, SQL_ASCII не гарантирует, что данные, хранящиеся в базе, имеют определённую кодировку, и таким образом, этот выбор чреват сбоями, связанными с локалью. Использование данной комбинации устарело и, возможно, будет полностью запрещено.

23.3.3. Автоматическая перекодировка между сервером и клиентом

PostgreSQL поддерживает автоматическую перекодировку между сервером и клиентом для определённых комбинаций кодировок. Информация, касающаяся перекодировки, хранится в системном каталоге pg_conversion. PostgreSQL включает в себя некоторые предопределённые кодировки, как показано в Таблице 23.2. Есть возможность создать новую перекодировку при помощи SQL-команды CREATE CONVERSION.

Таблица 23.2. Клиент-серверные перекодировки наборов символов

Чтобы включить автоматическую перекодировку символов, необходимо сообщить PostgreSQL кодировку, которую вы хотели бы использовать на стороне клиента. Это можно выполнить несколькими способами:

• Использование команды \encoding в psql. \encoding позволяет оперативно изменять клиентскую кодировку. Например, чтобы изменить кодировку на SJIS, введите:

  \encoding SJIS

• libpq (Раздел 33.10) имеет функции, для управления клиентской кодировкой.

• Использование SET client_encoding TO. Клиентская кодировка устанавливается следующей SQL-командой:

  SET CLIENT_ENCODING TO 'value';

  Также, для этой цели можно использовать стандартный синтаксис SQL SET NAMES:

  SET NAMES 'value';

  Получить текущую клиентскую кодировку:

  SHOW client_encoding;

  Вернуть кодировку по умолчанию:

  RESET client_encoding;

• Использование PGCLIENTENCODING. Если установлена переменная окружения PGCLIENTENCODING, то эта клиентская кодировка выбирается автоматически при подключении к серверу. (В дальнейшем это может быть переопределено при помощи любого из методов, указанных выше.)

• Использование переменной конфигурации client_encoding. Если задана переменная client_encoding, указанная клиентская кодировка выбирается автоматически при подключении к серверу. (В дальнейшем это может быть переопределено при помощи любого из методов, указанных выше.)

Если перекодировка определённого символа невозможна (предположим, выбраны EUC_JP для сервера и LATIN1 для клиента, и передаются некоторые японские иероглифы, не представленные в LATIN1), возникает ошибка.

Если клиентская кодировка определена как SQL_ASCII, перекодировка отключается вне зависимости от кодировки сервера. Что же касается сервера, не стоит использовать SQL_ASCII, если только вы не работаете с данными, которые полностью соответствуют ASCII.

23.3.4. Дополнительные источники информации

Рекомендуемые источники для начала изучения различных видов систем кодирования.

Обработка информации на китайском, японском, корейском & вьетнамском языках.

Содержит подробные объяснения по EUC_JP, EUC_CN, EUC_KR, EUC_TW.

http://www.unicode.org/

Сайт Unicode Consortium.

RFC 3629

UTF-8 (формат преобразования 8-битного UCS/Unicode) определён здесь.

Как изменить кодировку файла из Windows-1251 в UTF-8 на Golang

Всегда нужно быть готовым к тому, что кодировка входных данных из разных источников может различаться. Конечно, большинство используют операционную систему Windows, но не только. Go по умолчанию предполагает, что строки в программах будут в кодировке UTF-8. Если это не так, тогда их требуется декодировать, чтобы в дальнейшем можно было с ними работать. В данной инструкции показано, как читать и записывать файлы в других кодировках, помимо UTF-8.

Как использовать разные кодировками в Golang?

1. Создайте файл charset.go со следующим содержимым:

Премиум 👑 канал по Golang

Рекомендуем вам супер TELEGRAM канал по Golang где собраны все материалы для качественного изучения языка. Удивите всех своими знаниями на собеседовании! 😎

Подписаться на канал

Уроки, статьи и Видео

Мы публикуем в паблике ВК и Telegram качественные обучающие материалы для быстрого изучения Go. Подпишитесь на нас в ВК и в Telegram. Поддержите сообщество Go программистов.

Go в ВК

ЧАТ в Telegram

package main

import (
«fmt»
«io/ioutil»
«os»

«golang.org/x/text/encoding/charmap»
)

func main() {

// Запись строки в кодировке Windows-1252
encoder := charmap.Windows1252.NewEncoder()
s, e := encoder.String(«This is sample text with runes Š»)
if e != nil {
panic(e)
}
ioutil.WriteFile(«example.txt», []byte(s), os.ModePerm)

// Декодировка в UTF-8
f, e := os.Open(«example.txt»)
if e != nil {
panic(e)
}
defer f.Close()
decoder := charmap.Windows1252.NewDecoder()
reader := decoder.Reader(f)
b, err := ioutil.ReadAll(reader)
if err != nil {
panic(err)
}
fmt.Println(string(b))
}

2. Запустите код через go run charset.go;
3. Посмотрите на результат в терминале:

This is sample text with runes Š

Конвертирование кодировки Windows-1251 в UTF-8

Пакет golang.org/x/text/encoding/charmap содержит константы типа указателя Charmap, что представляют наиболее часто используемые кодировки. Тип Charmap предоставляет методы для создания кодера и декодера для определенного набора символов. Encoder создает Writer для кодировки, что кодирует записанные байты в выбранную кодировку. Также Decoder может создать Reader для декодировки, что декодирует все данные для чтения из выбранной кодировки.

Также можете ознакомиться с инструкцией для изменения кодировки строки, символы которой не относятся к Unicode.

Администрирую данный сайт с целью распространения как можно большего объема обучающего материала для языка программирования Go. В IT с 2008 года, с тех пор изучаю и применяю интересующие меня технологии. Проявляю огромный интерес к машинному обучению и анализу данных.

E-mail: [email protected]

Образование

Технический Университет Молдовы (utm.md), Факультет Вычислительной Техники, Информатики и Микроэлектроники

• 2014 — 2018 Universitatea Tehnică a Moldovei, ИТ-Инженер. Тема дипломной работы «Автоматизация покупки и продажи криптовалюты используя технический анализ»
• 2018 — 2020 Universitatea Tehnică a Moldovei, Магистр, Магистерская диссертация «Идентификация человека в киберпространстве по фотографии лица»

Уроки из раздела

Лучший канал по Golang в Telegram!

— Книги!

— Видеоуроки!

— Golang Новости!

👉 Go в Telegram

Таблица кодов символов Windows-1251

Windows-1251 — набор символов и кодировка, являющаяся стандартной 8-битной кодировкой для всех русских версий Microsoft Windows. Данная кодировка пользуется довольно большой популярностью в восточно-европейских странах. Windows-1251 выгодно отличается от других 8-битных кириллических кодировок (таких как CP866, KOI8-R и ISO 8859-5) наличием практически всех символов, использующихся в традиционной русской типографике для обычного текста (отсутствует только знак ударения). Кириллические символы идут в алфавитном порядке.
Windows-1251 также содержит все символы для близких к русскому языку языков: белорусского, украинского, сербского, македонского и болгарского.
На практике этого оказалось достаточно, чтобы кодировка Windows-1251 закрепилась в интернете вплоть до распространения UTF-8.

Описание специальных (управляющих) символов

Первоначально управляющие символы таблицы ASCII (диапазон 00-31, плюс 127) были разработаны для того, чтобы управлять устройствами аппаратных средств, таких как телетайп, ввод данных на перфоленту и др.
Управляющие символы (кроме горизонтальной табуляции, перевода строки и возврата каретки) не используются в HTML-документах.

Смотрите также:

URL коды символов ACSII

URL коды символов UTF-8 диапазон от U+0400 до U+04FF

HTML Кодирование URL

Таблица кодов символов кирилицы UTF-8

Кодировка текста ASCII (Windows 1251, CP866, KOI8-R) и Юникод (UTF 8, 16, 32) — как исправить проблему с кракозябрами

Сегодня мы поговорим о том, откуда берутся кракозябры на сайте и в программах, какие кодировки текста существуют и какие из них следует использовать. Подробно рассмотрим историю их развития, начиная с базовой ASCII, а также ее расширенных версий CP866, KOI8-R, Windows 1251 и заканчивая современными кодировками консорциума Юникод UTF 16 и 8.

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

ASCII — базовая кодировка текста для латиницы

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

Но все же отправной точкой для развития современных кодировок текстов стоит считать знаменитую ASCII (American Standard Code for Information Interchange, которая по-русски обычно произносится как «аски»). Она описывает первые 128 символов из наиболее часто используемых англоязычными пользователями — латинские буквы, арабские цифры и знаки препинания.

Еще в эти 128 знаков, описанных в ASCII, попадали некоторые служебные символы вроде скобок, решеток, звездочек и т.п. Собственно, вы сами можете увидеть их:
Именно эти 128 символов из первоначального варианта ASCII стали стандартом, и в любой другой кодировке вы их обязательно встретите и стоять они будут именно в таком порядке.

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

Тут, наверное, стоит еще немного сказать о системах счисления, которые используются при описании. Во-первых, как вы все знаете, компьютер работает только с числами в двоичной системе, а именно с нулями и единицами («булева алгебра», если кто проходил в институте или в школе). Один байт состоит из восьми бит, каждый из которых представляет собой двойку в степени, начиная с нулевой, и до двойки в седьмой:

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

В нашем примере это получается 1 (2 в степени ноль) плюс 8 (два в степени 3), плюс 32 (двойка в пятой степени), плюс 64 (в шестой), плюс 128 (в седьмой). Итого получается 233 в десятичной системе счисления. Как видите, все очень просто.

Но если вы присмотритесь к таблице с символами ASCII, то увидите, что они представлены в шестнадцатеричной кодировке. Например, «звездочка» соответствует в Аски шестнадцатеричному числу 2A. Наверное, вам известно, что в шестнадцатеричной системе счисления используются кроме арабских цифр еще и латинские буквы от A (означает десять) до F (означает пятнадцать).

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

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

Расширенные версии Аски — кодировки CP866 и KOI8-R с псевдографикой

Итак, мы с вами начали говорить про ASCII, которая являлась как бы отправной точкой для развития всех современных кодировок (Windows 1251, юникод, UTF 8).

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

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

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

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

Значит, чтобы закодировать любой нужный нам символ (например, из национального алфавита), нужно выполнить два условия: векторная форма этого знака должна быть в используемом шрифте, и этот символ можно было бы закодировать в расширенных кодировках ASCII в один байт. Поэтому таких вариантов существует целая куча. Только лишь для кодирования символов русского языка существует несколько разновидностей расширенной Аски.

Например, изначально появилась CP866, в которой была возможность использовать символы русского алфавита, и она являлась расширенной версией ASCII.

То есть, ее верхняя часть полностью совпадала с базовой версией Аски (128 символов латиницы, цифр и еще всякой лабуды), которая представлена на приведенном чуть выше скриншоте, а вот уже нижняя часть таблицы с кодировкой CP866 имела указанный на скриншоте чуть ниже вид и позволяла закодировать еще 128 знаков (русские буквы и всякая там псевдографика):

Видите, в правом столбце цифры начинаются с 8, т.к. числа с 0 до 7 относятся к базовой части ASCII (см. первый скриншот). Таким образом, у кириллической буквы «М» в CP866 будет код 9С (она находится на пересечении соответствующих строки с 9 и столбца с цифрой С в шестнадцатеричной системе счисления), который можно записать в одном байте информации, и при наличии подходящего шрифта с русскими символами эта буква без проблем отобразится в тексте.

Откуда взялось такое количество псевдографики в CP866? Тут все дело в том, что эта кодировка для русского текста разрабатывалась еще в те мохнатые года, когда графические операционные системы не были распространены как сейчас. А в Досе и подобных ей текстовых операционках псевдографика позволяла хоть как-то разнообразить оформление текстов и поэтому ею изобилует CP866 и все другие ее ровесницы из разряда расширенных версий Аски.

CP866 распространяла компания IBM, но кроме этого для символов русского языка были разработаны еще ряд кодировок, например, к этому же типу (расширенных ASCII) можно отнести KOI8-R:
Принцип ее работы остался тот же самый, что и у описанной чуть ранее CP866 — каждый символ текста кодируется одним единственным байтом. На скриншоте показана вторая половина таблицы KOI8-R, т.к. первая половина полностью соответствует базовой Аски, которая показана на первом скриншоте в этой статье.

Среди особенностей кодировки KOI8-R можно отметить то, что кириллические буквы в ее таблице идут не в алфавитном порядке, как это сделали в CP866.

Если посмотрите на самый первый скриншот (базовой части, которая входит во все расширенные кодировки), то заметите, что в KOI8-R русские буквы расположены в тех же ячейках таблицы, что и созвучные им буквы латинского алфавита из первой части таблицы. Это было сделано для удобства перехода с русских символов на латинские путем отбрасывания всего одного бита (два в седьмой степени или 128).

Windows 1251 — современная версия ASCII и почему вылезают кракозябры

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

Они относились к так называемым ANSI кодировкам, которые были разработаны американским институтом стандартизации. В просторечии еще использовалось название кириллица для варианта с поддержкой русского языка. Примером такой может служить Windows 1251.

Она выгодно отличалась от используемых ранее CP866 и KOI8-R тем, что место символов псевдографики в ней заняли недостающие символы русской типографики (окромя знака ударения), а также символы, используемые в близких к русскому славянских языках (украинскому, белорусскому и т.д.):
Из-за такого обилия кодировок русского языка, у производителей шрифтов и производителей программного обеспечения постоянно возникала головная боль, а у нас с вам, уважаемые читатели, зачастую вылезали те самые пресловутые кракозябры, когда происходила путаница с используемой в тексте версией.

Очень часто они вылезали при отправке и получении сообщений по электронной почте, что повлекло за собой создание очень сложных перекодировочных таблиц, которые, собственно, решить эту проблему в корне не смогли, и зачастую пользователи для переписки использовали транслит латинских букв, чтобы избежать пресловутых кракозябров при использовании русских кодировок подобных CP866, KOI8-R или Windows 1251.

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

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

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

Юникод (Unicode) — универсальные кодировки UTF 8, 16 и 32

Эти тысячи знаков языковой группы юго-восточной Азии никак невозможно было описать в одном байте информации, который выделялся для кодирования символов в расширенных версиях ASCII. В результате был создан консорциум под названием Юникод (Unicode — Unicode Consortium) при сотрудничестве многих лидеров IT индустрии (те, кто производит софт, кто кодирует железо, кто создает шрифты), которые были заинтересованы в появлении универсальной кодировки текста.

Первой вариацией, вышедшей под эгидой консорциума Юникод, была UTF 32. Цифра в названии кодировки означает количество бит, которое используется для кодирования одного символа. 32 бита составляют 4 байта информации, которые понадобятся для кодирования одного единственного знака в новой универсальной кодировке UTF.

В результате чего один и тот же файл с текстом, закодированный в расширенной версии ASCII и в UTF-32, в последнем случае будет иметь размер (весить) в четыре раза больше. Это плохо, но зато теперь у нас появилась возможность закодировать с помощью ЮТФ число знаков, равное двум в тридцать второй степени (миллиарды символов, которые покроют любое реально необходимое значение с колоссальным запасом).

Но многим странам с языками европейской группы такое огромное количество знаков использовать в кодировке вовсе и не было необходимости, однако при задействовании UTF-32 они ни за что ни про что получали четырехкратное увеличение веса текстовых документов, а в результате и увеличение объема интернет-трафика и объема хранимых данных. Это много, и такое расточительство себе никто не мог позволить.

В результате развития Юникода появилась UTF-16, которая получилась настолько удачной, что была принята по умолчанию как базовое пространство для всех символов, которые у нас используются. Она использует два байта для кодирования одного знака. Давайте посмотрим, как это дело выглядит.

В операционной системе Windows вы можете пройти по пути «Пуск» — «Программы» — «Стандартные» — «Служебные» — «Таблица символов». В результате откроется таблица с векторными формами всех установленных у вас в системе шрифтов. Если вы выберете в «Дополнительных параметрах» набор знаков Юникод, сможете увидеть для каждого шрифта в отдельности весь ассортимент входящих в него символов.

Кстати, щелкнув по любому из них, вы сможете увидеть его двухбайтовый код в формате UTF-16, состоящий из четырех шестнадцатеричных цифр:
Сколько символов можно закодировать в UTF-16 с помощью 16 бит? 65 536 (два в степени шестнадцать), и именно это число было принято за базовое пространство в Юникоде. Помимо этого существуют способы закодировать с помощью нее и около двух миллионов знаков, но ограничились расширенным пространством в миллион символов текста.

Но даже эта удачная версия кодировки Юникода не принесла особого удовлетворения тем, кто писал, допустим, программы только на английском языке, ибо у них после перехода от расширенной версии ASCII к UTF-16, вес документов увеличивался в два раза (один байт на один символ в Аски и два байта на тот же самый символ в ЮТФ-16).

Вот именно для удовлетворения всех и вся в консорциуме Unicode было решено придумать кодировку переменной длины. Ее назвали UTF-8. Несмотря на восьмерку в названии, она действительно имеет переменную длину, т.е. каждый символ текста может быть закодирован в последовательность длиной от одного до шести байт.

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

Что примечательно, в случае кодирования только латиницы, даже те программы, которые не понимают Юникод, все равно прочитают то, что закодировано в ЮТФ-8. То есть, базовая часть Аски просто перешла в это детище консорциума Unicode.

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

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

Кракозябры вместо русских букв — как исправить

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

Для редактирования и создания текстовых файлов лично я использую очень хороший, на мой взгляд, Html и PHP редактор Notepad++. Впрочем, он может подсвечивать синтаксис еще доброй сотни языков программирования и разметки, а также имеет возможность расширения с помощью плагинов. Читайте подробный обзор этой замечательной программы по приведенной ссылке.

В верхнем меню Notepad++ есть пункт «Кодировки», где у вас будет возможность преобразовать уже имеющийся вариант в тот, который используется на вашем сайте по умолчанию:
В случае сайта на Joomla 1.5 и выше, а также в случае блога на WordPress следует во избежании появления кракозябров выбирать вариант UTF 8 без BOM. А что такое приставка BOM?

Дело в том, что когда разрабатывали кодировку ЮТФ-16, зачем-то решили прикрутить к ней такую вещь, как возможность записывать код символа, как в прямой последовательности (например, 0A15), так и в обратной (150A). А для того, чтобы программы понимали, в какой именно последовательности читать коды, и был придуман BOM (Byte Order Mark или, другими словами, сигнатура), которая выражалась в добавлении трех дополнительных байтов в самое начало документов.

В кодировке UTF-8 никаких BOM предусмотрено в консорциуме Юникод не было и поэтому добавление сигнатуры (этих самых пресловутых дополнительных трех байтов в начало документа) некоторым программам просто-напросто мешает читать код. Поэтому мы всегда при сохранении файлов в ЮТФ должны выбирать вариант без BOM (без сигнатуры). Таким образом, вы заранее обезопасите себя от вылезания кракозябров.

Что примечательно, некоторые программы в Windows не умеют этого делать (не умеют сохранять текст в ЮТФ-8 без BOM), например, все тот же пресловутый Блокнот Windows. Он сохраняет документ в UTF-8, но все равно добавляет в его начало сигнатуру (три дополнительных байта). Причем эти байты будут всегда одни и те же — читать код в прямой последовательности. Но на серверах из-за этой мелочи может возникнуть проблема — вылезут кракозябры.

Поэтому ни в коем случае не пользуйтесь обычным блокнотом Windows для редактирования документов вашего сайта, если не хотите появления кракозябров. Лучшим и наиболее простым вариантом я считаю уже упомянутый редактор Notepad++, который практически не имеет недостатков и состоит из одних лишь достоинств.

В Notepad ++ при выборе кодировки у вас будет возможность преобразовать текст в кодировку UCS-2, которая по своей сути очень близка к стандарту Юникод. Также в Нотепаде можно будет закодировать текст в ANSI, т.е. применительно к русскому языку это будет уже описанная нами чуть выше Windows 1251. Откуда берется эта информация?

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

После того, как вы в Notepad++ сохраните документ в нужной вам кодировке или же откроете документ с сайта для редактирования, то в правом нижнем углу редактора сможете увидеть ее название:
Чтобы избежать кракозябров, кроме описанных выше действий, будет полезным прописать в его шапке исходного кода всех страниц сайта информацию об этой самой кодировке, чтобы на сервере или локальном хосте не возникло путаницы.

Вообще, во всех языках гипертекстовой разметки кроме Html используется специальное объявление xml, в котором указывается кодировка текста.

<?xml version="1.0" encoding="windows-1251"?>

Прежде, чем начать разбирать код, браузер узнает, какая версия используется и как именно нужно интерпретировать коды символов этого языка. Но что примечательно, если вы сохраняете документ в принятом по умолчанию юникоде, это объявление xml можно будет опустить (кодировка будет считаться UTF-8, если нет BOM или ЮТФ-16, если BOM есть).

В случае же документа языка Html для указания кодировки используется элемент Meta, который прописывается между открывающим и закрывающим тегом Head:

<head>
...
<meta charset="utf-8">
...
</head>

Эта запись довольно сильно отличается от принятой в стандарте в Html 4.01, но полностью соответствует стандарту Html 5, и она будет стопроцентно правильно понята любыми используемыми на текущий момент браузерами.

По идее элемент Meta с указание кодировки Html документа лучше будет ставить как можно выше в шапке документа, чтобы на момент встречи в тексте первого знака не из базовой ANSI (которые правильно прочитаются всегда и в любой вариации) браузер уже должен иметь информацию о том, как интерпретировать коды этих символов.

Ссылка на первоисточник: Кодировка текста ASCII (Windows 1251, CP866, KOI8-R) и Юникод (UTF 8, 16, 32) — как исправить проблему с кракозябрами

сведения о кодировке символов — PowerShell

• 
  10/21/2020
• Чтение занимает 5 мин

В этой статье

Краткое описание

Описывает, как PowerShell использует кодировку символов для ввода и вывода строковых данных.

Подробное описание

Юникод — это мировой стандарт кодировки символов. Система использует Юникод исключительно для обработки символов и строк. Подробное описание всех аспектов Юникода см. в стандарте Юникода.

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

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

Следующие командлеты имеют параметр Encoding :

• Microsoft.PowerShell.Management
  • Add-Content
  • Get-Content
  • Set-Content
• Microsoft.PowerShell.Utility
  • Export-Clixml
  • Export-Csv
  • Export-PSSession
  • Format-Hex
  • Import-Csv
  • Out-File
  • Select-String
  • Send-MailMessage

Пометка порядка байтов

Символ-пометка (BOM) — это сигнатура в Юникоде в первых нескольких байтах файла или текстового потока, указывающих, какая кодировка Юникода используется для данных. Дополнительные сведения см. в документации по метке порядка байтов .

В Windows PowerShell любая Кодировка Юникода, за исключением UTF7 , всегда создает спецификацию. По умолчанию PowerShell Core имеет значение utf8NoBOM для всех текстовых выходных данных.

Для обеспечения оптимальной совместимости Избегайте использования спецификаций в файлах UTF-8. Платформы UNIX и служебные программы Unix-Heritage, которые также используются на платформах Windows, не поддерживают спецификации.

Аналогичным образом UTF7 следует избегать кодирования. UTF-7 не является стандартной кодировкой Юникода и записывается без спецификации во всех версиях PowerShell.

Создание сценариев PowerShell на платформе, похожем на UNIX, или использовании кросс-платформенного редактора в Windows, например Visual Studio Code, приводит к созданию файла, закодированного с помощью UTF8NoBOM . Эти файлы прекрасно работают в PowerShell Core, но могут нарушить работу Windows PowerShell, если файл содержит символы, отличные от ASCII.

Если в скриптах необходимо использовать символы, отличные от ASCII, сохраните их как UTF-8 с помощью BOM. Без спецификации Windows PowerShell ошибочно интерпретирует скрипт как закодированный в устаревшей кодовой странице ANSI. И наоборот, файлы, имеющие СПЕЦИФИКАЦИю UTF-8, могут быть проблематичными для платформ, подобных Unix. Многие средства UNIX, такие как cat ,, sed awk и некоторые редакторы, например, gedit не узнают, как обрабатывать спецификацию.

Кодировка символов в Windows PowerShell

В PowerShell 5,1 параметр Encoding поддерживает следующие значения:

• Ascii Использует кодировку ASCII (7-разрядных).
• BigEndianUnicode Использует UTF-16 с обратным порядком байтов.
• BigEndianUTF32 Использует UTF-32 с обратным порядком байтов.
• Byte Кодирует набор символов в последовательность байтов.
• Default Использует кодировку, соответствующую активной кодовой странице системы (обычно ANSI).
• Oem Использует кодировку, соответствующую текущей кодовой странице OEM системы.
• String аналогичен Unicode.
• Unicode Использует UTF-16 с прямым порядком байтов.
• Unknown аналогичен Unicode.
• UTF32 Использует UTF-32 с прямым порядком байтов.
• UTF7 Использует UTF-7.
• UTF8 Использует UTF-8 (с BOM).

В общем случае Windows PowerShell по умолчанию использует кодировку Юникод UTF-16LE . Однако кодировка по умолчанию, используемая командлетами в Windows PowerShell, не согласуется.

Примечание

При использовании любой кодировки Юникода, за исключением UTF7 , всегда создает спецификацию.

Для командлетов, записывающих выходные данные в файлы:

• Out-File и операторы перенаправления > и >> создают UTF-16LE, который, в свою очередь, отличается от Set-Content и Add-Content .

• New-ModuleManifest а Export-CliXml также создавать файлы UTF-16LE.

• Если целевой файл пуст или не существует, Set-Content и Add-Content Используйте Default кодировку. Default — это кодировка, определяемая кодовой страницей устаревшей версии ANSI на языке активного системы.

• Export-Csv создает Ascii файлы, но использует другую кодировку при использовании параметра append (см. ниже).

• Export-PSSession по умолчанию создает файлы UTF-8 с BOM.

• New-Item -Type File -Value создает файл UTF-8 с кодировкой BOM.

• Send-MailMessage по Default умолчанию использует кодировку.

• Start-Transcript создает Utf8 файлы с помощью спецификации. При использовании параметра append кодировка может отличаться (см. ниже).

Для команд, которые добавляют к существующему файлу:

• Out-File -Append и >> оператор перенаправления не пытается сопоставить кодировку содержимого существующего целевого файла. Вместо этого они используют кодировку по умолчанию, если не используется параметр Encoding . При добавлении содержимого необходимо использовать исходную кодировку файлов.

• При отсутствии явного параметра кодировки Add-Content обнаруживает существующую кодировку и автоматически применяет ее к новому содержимому. Если имеющееся содержимое не имеет BOM, Default используется кодировка ANSI. Поведение аналогично Add-Content в PowerShell Core (V6 и более поздних версиях), кроме кодировки по умолчанию — Utf8 .

• Export-Csv -Append соответствует существующей кодировке, если целевой файл содержит СПЕЦИФИКАЦИю. В отсутствие спецификации используется Utf8 Кодировка.

• Start-Transcript -Append соответствует существующей кодировке файлов, включающих СПЕЦИФИКАЦИю. При отсутствии спецификации по умолчанию используется Ascii Кодировка. Такая кодировка может привести к утере данных или повреждению символов, если данные в записи содержат многобайтовые символы.

Для командлетов, считывающих строковые данные в отсутствие спецификации:

• Get-Content и Import-PowerShellDataFile использует Default кодировку ANSI. ANSI также используется механизмом PowerShell при чтении исходного кода из файлов.

• Import-Csv, Import-CliXml и Select-String предполагают Utf8 отсутствие спецификации.

Кодировка символов в PowerShell Core

В PowerShell Core (V6 и более поздних версий) параметр Encoding поддерживает следующие значения:

• ascii: Использует кодировку для набора символов ASCII (7-разрядных).
• bigendianunicode: Кодируется в формате UTF-16 с обратным порядком байтов.
• oem: Использует кодировку по умолчанию для программ MS-DOS и консолей.
• unicode: Кодируется в формате UTF-16 с прямым порядком байтов.
• utf7: Кодируется в формате UTF-7.
• utf8: Кодирует в формате UTF-8 (без спецификации).
• utf8BOM: Кодирует в формате UTF-8 с меткой порядка байтов (BOM)
• utf8NoBOM: Кодирует в формате UTF-8 без метки порядка байтов (BOM)
• utf32: Кодируется в формате UTF-32.

По умолчанию PowerShell Core имеет значение utf8NoBOM для всех выходных данных.

Начиная с PowerShell 6,2, параметр кодировки также разрешает числовые идентификаторы зарегистрированных кодовых страниц (например -Encoding 1251 ,) или строковых имен зарегистрированных кодовых страниц (например -Encoding "windows-1251" ,). Дополнительные сведения см. в документации .NET по кодированию. codepage.

Изменение кодировки по умолчанию

В PowerShell есть две переменные по умолчанию, которые можно использовать для изменения поведения кодировки по умолчанию.

• $PSDefaultParameterValues
• $OutputEncoding

Дополнительные сведения см. в разделе about_Preference_Variables.

Начиная с PowerShell 5,1, операторы перенаправления ( > и >> ) вызывают Out-File командлет. Таким образом, можно задать кодировку по умолчанию для них с помощью $PSDefaultParameterValues переменной предпочтений, как показано в следующем примере:

$PSDefaultParameterValues['Out-File:Encoding'] = 'utf8'

Используйте следующую инструкцию, чтобы изменить кодировку по умолчанию для всех командлетов, имеющих параметр Encoding .

$PSDefaultParameterValues['*:Encoding'] = 'utf8'

Важно!

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

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

Автоматическая переменная $OutputEncoding влияет на кодирование, используемое PowerShell для взаимодействия с внешними программами. Он не влияет на кодировку, которую операторы перенаправления вывода и командлеты PowerShell используют для сохранения в файлах.

См. также

Bash скрипт для рекурсивного преобразования файлов windows-1251 -> utf-8 · GitHub

Bash скрипт для рекурсивного преобразования файлов windows-1251 -> utf-8 · GitHub

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

Bash-скрипт для рекурсивного преобразования файлов windows-1251 -> utf-8

Вы не можете выполнить это действие в настоящее время.

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

Модуль ngx_http_charset_module

Модуль ngx_http_charset_module

Модуль ngx_http_charset_module добавляет указанный
charset в поле заголовка ответа Content-Type.
Кроме того, модуль может конвертировать данные из одной кодировки в другую,
с некоторыми ограничениями:

• конвертация осуществляется в одну сторону — от сервера к клиенту,
• могут быть преобразованы только однобайтовые кодировки
• или однобайтовые кодировки в / из UTF-8.

Пример конфигурации

включить conf / koi-win;

кодировка windows-1251;
source_charset koi8-r;
 

Директивы

 charset off; 

Добавляет указанную кодировку в Content-Type.
поле заголовка ответа.Если эта кодировка отличается от указанной
в директиве source_charset выполняется преобразование.

Параметр off отменяет добавление кодировки.
в поле заголовка ответа Content-Type.

Кодировку можно определить с помощью переменной:

charset $ charset;
 

В таком случае должны присутствовать все возможные значения переменной.
в конфигурации хотя бы один раз в виде
charset_map, charset или
source_charset директивы.Для utf-8 , windows-1251 и
koi8-r charsets, достаточно включить файлы
conf / koi-win , conf / koi-utf и
conf / win-utf в конфигурацию.
Для других наборов символов, просто создание фиктивной таблицы преобразования работает,
Например:

charset_map iso-8859-5 _ {}
 

Кроме того, кодировку можно установить в
Поле заголовка ответа «X-Accel-Charset».
Эту возможность можно отключить с помощью
proxy_ignore_headers,
fastcgi_ignore_headers,
uwsgi_ignore_headers,
scgi_ignore_headers,
а также
grpc_ignore_headers
директивы.

Описывает таблицу преобразования из одной кодировки в другую.Таблица обратного преобразования строится с использованием тех же данных.
Коды символов даны в шестнадцатеричном формате.
Отсутствующие символы в диапазоне 80-FF заменяются на «? ».
При преобразовании из UTF-8 символы отсутствуют в однобайтовой кодировке.
заменяются на « & # XXXX; ».

Пример:

charset_map koi8-r windows-1251 {
    C0 FE; # маленький ю
    C1 E0; # маленький а
    C2 E1; # маленький б
    C3 F6; # small ts
    ...
}
 

При описании таблицы преобразования в UTF-8 коды для кодировки UTF-8 должны
быть приведенным во втором столбце, например:

charset_map koi8-r utf-8 {
    C0 D18E; # маленький ю
    C1 D0B0; # маленький а
    C2 D0B1; # маленький б
    C3 D186; # small ts
    ...
}
 

Полные таблицы преобразования с koi8-r на
windows-1251 , а от koi8-r и
windows-1251 от до utf-8
представлены в файлах раздачи conf / koi-win ,
conf / koi-utf и conf / win-utf .

 charset_types текст / HTML-текст / XML-текст / простой текст / vnd.wap.wml
приложение / javascript приложение / rss + xml; 

Эта директива появилась в версии 0.7.9.

Включает обработку модуля в ответах с указанными типами MIME
в дополнение к « text / html ».
Специальное значение « * » соответствует любому типу MIME (0.8.29).

До версии 1.5.4 использовалось « application / x-javascript ».
в качестве типа MIME по умолчанию вместо « application / javascript ».

 override_charset выкл; 

Определяет, нужно ли выполнять преобразование ответов
получено от прокси-сервера или сервера FastCGI / uwsgi / SCGI / gRPC
когда ответы уже содержат кодировку в «Content-Type»
поле заголовка ответа.Если преобразование включено, кодировка указана в полученном
ответ используется как кодировка источника.

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

Определяет исходную кодировку ответа.Если эта кодировка отличается от указанной
в директиве charset выполняется преобразование.

Значения кодировки | Программируемая поисковая система | Разработчики Google

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

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

Вы можете определить кодировку либо в панели управления, либо в файле контекста. На вкладке Basics панели управления вы выбираете язык из раскрывающегося списка Search Engine encoding .В файле контекста вы определяете значение атрибута encoding элемента CustomSearchEngine , как в следующем примере:

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

Примечание: Если вы не укажете тип кодировки, программируемая поисковая система будет использовать UTF-8 в качестве значения по умолчанию.

Наверх

Поддерживаемые кодировки

java.io.InputStreamReader ,
java.io.OutputStreamWriter ,
java.lang.String классов, а классы в
java.nio.charset пакет может конвертировать между Unicode
и ряд других кодировок символов. Поддерживаемые кодировки
различаются между различными реализациями Java SE 8. Описание класса для
java.nio.charset.Charset
перечисляет кодировки, которые должна поддерживать любая реализация Java SE 8.

JDK 8 для всех платформ
(Solaris, Linux и Microsoft Windows) и JRE 8 для Solaris и Linux
поддерживают все кодировки, показанные на этой странице.JRE 8 для Microsoft Windows может быть
установлена ​​как полная международная версия или как европейская
языковая версия. По умолчанию установщик JRE 8 устанавливает
Версия на европейских языках, если она распознает, что хост, работающий
система поддерживает только европейские языки. Если установщик
признает, что нужен любой другой язык, или если пользователь
запрашивает поддержку неевропейских языков в индивидуальном
установка, устанавливается полная международная версия. В
Версия для европейских языков поддерживает только кодировки, указанные в
следующую таблицу базового набора кодировок.Международная версия
(который включает файл lib / charsets.jar) поддерживает все
кодировки, показанные на этой странице.

В следующих таблицах показаны наборы кодировок, поддерживаемые Java SE.
8. Канонические имена, используемые новыми API-интерфейсами java.nio .
во многих случаях не совпадают с теми, которые используются в
java.io и java.lang API.

для Solaris

Онлайн-калькулятор: Кодировка текстового файла

В предыдущей статье я уже касался темы кодирования текста, более подробно описал Unicode и его представление UTF-8 в виде последовательности символов переменной длины.
Этот калькулятор может преобразовывать текст в несколько устаревших кодировок. Я называю их устаревшими, потому что в современных приложениях можно использовать Unicode и его наиболее удобное представление UTF-8.
Однако старые кодировки также могут быть полезны, когда вам нужно компактно закодировать текст, например, для последующего сжатия и передачи, когда принимающая сторона точно знает, в какой кодировке передается текст. Например, русский текст, закодированный в Windows-1251, займет половину места, чем текст в UTF-8.
Итак, калькулятор ниже позволяет вам загрузить файл в выбранной кодировке или просмотреть шестнадцатеричный дамп закодированного текста.

Закодированный текст

Encoding Atari STCP 856 Hebrew DOS Arabic (CP864) DOS Baltic Rim (CP775) DOS Cyrillic (CP855) DOS Cyrillic Russian (CP866) DOS French Canada (CP863) DOS Greek (CP737) DOS Greek 2 (CP869) DOS Hebrew ( CP862) DOS Исландский (CP861) DOS Latin 1 (CP850) DOS Latin 2 (CP852) DOS Latin США (CP437) DOS Nordic (CP865) DOS Португальский (CP860) DOS Турецкий (CP857) EBCDIC 037 США / Канада EBCDIC 1026 Турецкий EBCDIC 424 Иврит EBCDIC 500 Международный EBCDIC 875 Греческий GSM 03.38ISO 8-битный урду (IBM CP1006) ISO 8859-5ISO 8859-6ISO 8859-7ISO 8859-8ISO 8859-9ISO-IR-68ISO / IEC 8859-1 (Latin-1) ISO / IEC 8859-10 (Latin-6) ISO / IEC 8859-11ISO / IEC 8859-13 (Latin-7) ISO / IEC 8859-14ISO / IEC 8859-15 (Latin-9) ISO / IEC 8859-16 (Latin-10) ISO / IEC 8859-2 ( Latin-2) ISO / IEC 8859-3ISO / IEC 8859-4 (Latin-4) KOI8-RKOI8-UKPS 9566KZ-1048Mac OS CelticMac OS Central EuropeanMac OS CroatianMac OS CyrillicMac OS DingbatsMac OS GaelicMac OS GreekMac OS IcelandicMac OS InuitMac OS Roman Румынский Mac OS ТурецкийUTF-8Windows-1250Windows-1251Windows-1252Windows-1253Windows-1254Windows-1255Windows-1256Windows-1257Windows-1258Windows-874Windows-932Windows-936Windows-949Windows-950To быть или не быть, это вопрос сохранения 6 Link

16 Сохранить расширение Виджет

Вы можете просмотреть созданный файл с помощью декодера текстовых файлов.

Калькулятор вернет ошибку, если выбрана несовместимая кодировка. В случае Unicode это невозможно — он содержит символы всех современных языков. Но устаревшие 8-битные кодировки содержат ограниченный набор символов. Для текста на нескольких языках необходимая кодировка может вообще не быть найдена.
За годы до Unicode было изобретено множество кодировок для разных языков и наборов символов, поэтому выбор правильной кодировки для вашего текста может быть сложной задачей.Следующий калькулятор находит все кодировки, совместимые с введенным текстом.

Выберите кодировку текста

Быть или не быть, Вот в чем вопрос Кодировка Atari STCP 856 Hebrew DOS Arabic (CP864) DOS Baltic Rim (CP775) DOS Cyrillic (CP855) DOS Cyrillic Russian (CP866) DOS French Canada (CP863) DOS Greek (CP737) DOS Греческий 2 (CP869) DOS Иврит (CP862) DOS Исландский (CP861) DOS Latin 1 (CP850) DOS Latin 2 (CP852) DOS Latin США (CP437) DOS Nordic (CP865) DOS Португальский (CP860) DOS Турецкий ( CP857) EBCDIC 037 США / Канада EBCDIC 1026 Турецкий EBCDIC 424 Иврит EBCDIC 500 Международный EBCDIC 875 Греческий GSM 03.38ISO 8-битный урду (IBM CP1006) ISO 8859-5ISO 8859-6ISO 8859-7ISO 8859-8ISO 8859-9ISO-IR-68ISO / IEC 8859-1 (Latin-1) ISO / IEC 8859-10 (Latin-6) ISO / IEC 8859-11ISO / IEC 8859-13 (Latin-7) ISO / IEC 8859-14ISO / IEC 8859-15 (Latin-9) ISO / IEC 8859-16 (Latin-10) ISO / IEC 8859-2 ( Latin-2) ISO / IEC 8859-3ISO / IEC 8859-4 (Latin-4) KOI8-RKOI8-UKPS 9566KZ-1048Mac OS CelticMac OS Central EuropeanMac OS CroatianMac OS CyrillicMac OS DingbatsMac OS GaelicMac OS GreekMac OS IcelandicMac OS InuitMac OS Roman Румынский Mac OS ТурецкийUTF-8Windows-1250Windows-1251Windows-1252Windows-1253Windows-1254Windows-1255Windows-1256Windows-1257Windows-1258Windows-874Windows-932Windows-936Windows-949Windows-950

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

Скачать
закрыть

content_copy Link save Save extension Widget

Калькуляторы поддерживают 70 различных кодировок:

IBM EBCDIC

EBCDIC — стандартная 8-битная кодировка, разработанная IBM для использования на мэйнфреймах IBM.

ISO 8859 кодировки

Семейство кодировок, совместимых с ASCII, разработанных Международной организацией по стандартизации (ISO) и Международной электротехнической комиссией (IEC)

Семейство кодировок KOI8

KOI8 — 8-битная ASCII-совместимая кодировка для представления букв кириллических алфавитов

Кодировки Mac OS

DOS Cod Pages

Кодировки для MS-DOS и аналогичных операционных систем.

Кодировки Windows

Прочие

.

Правила преобразования кодировок в Unicode были получены из Unicode.org ^сайт.

PostgreSQL: Документация: 9.3: Поддержка набора символов

Поддержка набора символов в PostgreSQL позволяет хранить текст в
множество наборов символов (также называемых кодировками), включая
однобайтовые наборы символов, такие как серия ISO 8859 и
многобайтовые наборы символов, такие как EUC (Extended Unix Code), UTF-8 и Mule
внутренний код. Можно использовать все поддерживаемые наборы символов.
прозрачно для клиентов, но некоторые из них не поддерживаются для использования
внутри сервера (то есть как кодирование на стороне сервера).По умолчанию
набор символов выбирается при инициализации кластера базы данных PostgreSQL с помощью initdb. Его можно переопределить при создании
база данных, поэтому у вас может быть несколько баз данных с разными
набор символов.

Однако важным ограничением является то, что каждая база данных
набор символов должен быть совместим с параметрами локали базы данных LC_CTYPE (классификация символов) и LC_COLLATE (порядок сортировки строк). Для
C или POSIX
языковой стандарт, разрешен любой набор символов, но для других языков есть
это только один набор символов, который будет работать правильно.(В Windows
однако кодировку UTF-8 можно использовать с любой локалью.)

Таблица 22-1 показывает
наборы символов, доступные для использования в PostgreSQL.

Таблица 22-1. PostgreSQL
Наборы символов

Не все клиентские API поддерживают
все перечисленные наборы символов.Например, драйвер PostgreSQL JDBC не поддерживает
MULE_INTERNAL, LATIN6, LATIN8 и
ЛАТИНСКИЙ 10.

Параметр SQL_ASCII ведет себя
значительно отличается от других настроек. Когда сервер
набор символов — SQL_ASCII, сервер
интерпретирует байтовые значения 0-127 в соответствии со стандартом ASCII, а
байтовые значения 128–255 считаются неинтерпретируемыми символами. Нет
преобразование кодировки будет выполнено, если установлено значение SQL_ASCII. Таким образом, этот параметр не так уж и хорош.
объявление, что используется определенная кодировка, как объявление
незнание кодировки.В большинстве случаев, если вы работаете
с любыми данными, отличными от ASCII, неразумно использовать параметр SQL_ASCII, потому что PostgreSQL не сможет вам помочь
преобразование или проверка символов, отличных от ASCII.

initdb определяет символ по умолчанию
установить (кодировку) для PostgreSQL
кластер. Например,

 initdb -E EUC_JP 

устанавливает набор символов по умолчанию на EUC_JP (расширенный код Unix для японского языка). Ты можешь
используйте —encoding вместо -E, если вы предпочитаете более длинные строки параметров. Если нет
-E или —encoding
задана опция, initdb пытается
определить подходящую кодировку для использования на основе указанного или
языковой стандарт по умолчанию.

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

createdb -E EUC_KR -T template0 --lc-collate = ko_KR.euckr --lc-ctype = ko_KR.euckr корейский 

Это создаст базу данных с именем korean, которая использует набор символов EUC_KR и локаль ko_KR.
Другой способ сделать это — использовать эту команду SQL:

СОЗДАТЬ БАЗУ ДАННЫХ корейский С КОДИРОВАНИЕМ 'EUC_KR' LC_COLLATE = 'ko_KR.euckr' LC_CTYPE = 'ko_KR.euckr 'TEMPLATE = template0; 

Обратите внимание, что приведенные выше команды определяют копирование базы данных template0. При копировании любой другой базы данных,
настройки кодировки и локали не могут быть изменены по сравнению с
исходной базы данных, поскольку это может привести к повреждению данных. Для
дополнительную информацию см. в разделе
21.3.

Кодировка для базы данных хранится в системном каталоге.
pg_database. Вы можете увидеть это, используя
параметр psql -l или
команда \ l.

 $  psql -l 
                                         Список баз данных
   Имя | Владелец | Кодирование | Сортировка | Ctype | Привилегии доступа
----------- + ---------- + ----------- + ------------- + - ------------ + -------------------------------------
 clocaledb | хлиннака | SQL_ASCII | C | C |
 englishdb | хлиннака | UTF8 | en_GB.UTF8 | en_GB.UTF8 |
 японский | хлиннака | UTF8 | ja_JP.UTF8 | ja_JP.UTF8 |
 корейский | хлиннака | EUC_KR | ko_KR.euckr | ko_KR.euckr |
 postgres | хлиннака | UTF8 | fi_FI.UTF8 | fi_FI.UTF8 |
 template0 | хлиннака | UTF8 | fi_FI.UTF8 | fi_FI.UTF8 | {= c / hlinnaka, hlinnaka = CTc / hlinnaka}
 template1 | хлиннака | UTF8 | fi_FI.UTF8 | fi_FI.UTF8 | {= c / hlinnaka, hlinnaka = CTc / hlinnaka}
(7 рядов) 

Важно: В большинстве современных операционных систем PostgreSQL может определить, какой набор символов
подразумевается настройкой LC_CTYPE, и это
заставит использовать только соответствующую кодировку базы данных.На
старые системы, вы несете ответственность за использование
кодировка, ожидаемая выбранной вами локалью. Ошибка в
эта область может привести к странному поведению зависящего от локали
такие операции, как сортировка.

PostgreSQL позволит
суперпользователи для создания баз данных с кодировкой SQL_ASCII, даже если LC_CTYPE не C или
POSIX. Как отмечалось выше, SQL_ASCII не требует, чтобы данные, хранящиеся в
база данных имеет какую-либо конкретную кодировку, поэтому этот выбор ставит
риски ненадлежащего поведения, зависящего от местных условий.Используя эту комбинацию
настройки устарели и когда-нибудь могут быть полностью запрещены.

PostgreSQL поддерживает автоматический
преобразование набора символов между сервером и клиентом наверняка
комбинации наборов символов. Информация о преобразовании хранится в
системный каталог pg_conversion.
PostgreSQL поставляется с некоторыми
предопределенные преобразования, как показано в Таблице 22-2. Ты
может создать новое преобразование с помощью команды SQL CREATE CONVERSION.

Таблица 22-2. Преобразование набора символов клиент / сервер

Чтобы включить автоматическое преобразование набора символов, вы должны указать
PostgreSQL набор символов
(кодировка), которую вы хотели бы использовать в клиенте.Есть несколько
способов добиться этого:

• Использование команды \ encoding в
  psql. \ encoding позволяет изменять кодировку клиента на
  муха. Например, чтобы изменить кодировку на SJIS, введите:

   \ кодировка SJIS 

• libpq (Раздел 31.10) имеет функции для управления
  клиентская кодировка.

• Использование SET client_encoding TO. Параметр
  кодирование клиента может быть выполнено с помощью этой команды SQL:

   SET CLIENT_ENCODING TO 'значение'; 

  Также вы можете использовать стандартный синтаксис SQL SET
  ИМЕНА для этого:

   УСТАНОВИТЬ ИМЕНА 'значение'; 

  Для запроса текущей клиентской кодировки:

   ПОКАЗАТЬ client_encoding; 

  Для возврата к кодировке по умолчанию:

   СБРОС client_encoding; 

• Использование PGCLIENTENCODING.Если
  переменная среды PGCLIENTENCODING равна
  определена в клиентской среде, эта клиентская кодировка
  автоматически выбирается при подключении к серверу.
  (Впоследствии это можно изменить, используя любой из других методов.
  упомянуто выше.)

• Использование переменной конфигурации client_encoding.
  Если установлена ​​переменная client_encoding,
  эта клиентская кодировка выбирается автоматически при подключении к
  сервер сделан. (Впоследствии это может быть отменено с помощью любого
  других методов, упомянутых выше.)

Если преобразование определенного символа невозможно —
предположим, вы выбрали EUC_JP для сервера
и LATIN1 для клиента, а некоторые
Возвращаются японские символы, которые не имеют представления
в LATIN1 — сообщается об ошибке.

Если набор символов клиента определен как SQL_ASCII, преобразование кодировки отключено,
независимо от набора символов сервера. Как и в случае с сервером,
использование SQL_ASCII неразумно, если вы не
работа с данными в формате ASCII.

Это хорошие источники для начала изучения различных видов
системы кодирования.

CJKV Обработка информации: китайский,
Японская, корейская и вьетнамская вычислительная техника

Содержит подробные объяснения EUC_JP, EUC_CN, EUC_KR, EUC_TW.

http://www.unicode.org/

Веб-сайт Консорциума Unicode.

RFC 3629

UTF-8 (8-битный UCS / Unicode
Формат преобразования) определяется здесь.

Инструмент кодирования / декодирования. Анализируйте проблемы и ошибки кодировки символов.

Что такое кодовая страница?

Кодовая страница — это еще одно название для кодировки символов. Он состоит из таблицы значений
который описывает набор символов для определенного языка.

Что такое кодировка символов?

Кодировка символов — это процесс кодирования набора символов в соответствии с системой кодирования.Этот процесс обычно объединяет числа с символами для кодирования информации, которая может использоваться компьютером.

Зачем нужно кодировать символы?

Поскольку компьютеры могут интерпретировать только необработанные нули и единицы (например, 01100110), слова и предложения необходимо кодировать при вводе информации в компьютер. Символы в этих словах и предложениях сгруппированы в набор символов, который компьютер может распознать.

Что такое кодировки символов?

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

Типы кодировок символов

Существует множество кодировок, которые можно использовать для кодирования или декодирования строки символов, включая UTF-8, ASCII и ISO 9959-1.

Примеры популярных кодировок символов:

• ASCII: Американский стандартный код для обмена информацией
• ANSI: Американский национальный институт стандартов
• Unicode (внутренние текстовые коды, используемые операционными системами)
• UTF -8 (формат преобразования Unicode, в котором для представления символов используется 1 байт)
• UTF-16 (формат преобразования Unicode, который использует 2 байта для представления символов)
• UTF-32 (формат преобразования Unicode, который использует 4 байта для представления символов)

Хотя это, безусловно, популярные кодировки, которые используются, бывают случаи, когда строки кода кодируются с помощью кодировок, которые не так широко используются, например x-IA5-Norgwegian или DOS-720.