Кодировка Windows 1251 как установить

Обновлено: 21.11.2024

Выполняет преобразование набора символов в строке string из from_encoding в to_encoding .

Параметры

Вводная кодировка.

Выходная кодировка.

Если вы добавите строку //TRANSLIT к to_encoding, активируется транслитерация. Это означает, что когда символ не может быть представлен в целевой кодировке, он может быть аппроксимирован одним или несколькими похожими символами. Если вы добавляете строку //IGNORE , символы, которые не могут быть представлены в целевом наборе символов, автоматически отбрасываются. В противном случае генерируется E_NOTICE и функция возвращает false .

То, как работает //TRANSLIT, зависит от реализации iconv() в системе (см. ICONV_IMPL ). Известно, что некоторые реализации игнорируют //TRANSLIT , поэтому преобразование может завершиться ошибкой для символов, недопустимых для to_encoding .

Строка для преобразования.

Возвращаемые значения

В случае ошибки возвращает преобразованную строку или значение false.

Примеры

= "Это символ евро '€'." ;

echo 'Исходный:', $text, PHP_EOL;
echo 'ТРАНСЛИТ:', iconv("UTF-8", "ISO-8859-1//TRANSLIT", $text), PHP_EOL;< br />echo 'ИГНОРИРОВАТЬ:', iconv("UTF-8", "ISO-8859-1//IGNORE", $text), PHP_EOL;
echo 'Обычный:', iconv("UTF-8 ", "ISO-8859-1", $text), PHP_EOL;

Приведенный выше пример выведет что-то похожее на:

Примечания, внесенные пользователями 39 примечаний

Опция "//игнорировать" не работает с последними версиями библиотеки iconv. Так что если у вас возникли проблемы с этим вариантом, вы не одиноки.

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

Это известная ошибка с известным решением, по крайней мере, с 2009 года, но, похоже, никто не хочет ее исправлять (PHP должен передать параметр -c в iconv). В последнем выпуске 5.4.3 он все еще не работает.

[ОБНОВЛЕНИЕ 15 ИЮНЯ 2012 Г.]
Вот обходной путь.

ini_set('mbstring.substitute_character', "нет");
$text= mb_convert_encoding($text, 'UTF-8', 'UTF-8');

Это удалит недопустимые символы из строк UTF-8 (чтобы вы могли вставить их в базу данных и т. д.). Вместо «none» вы также можете использовать значение 32, если хотите, чтобы вместо недопустимых символов вставлялись пробелы.

Обратите внимание, что iconv('UTF-8', 'ASCII//TRANSLIT', . ) не работает должным образом, если для языкового стандарта LC_CTYPE установлено значение C или POSIX. Вы должны выбрать другую локаль, иначе все символы, отличные от ASCII, будут заменены вопросительными знаками. По крайней мере, это верно для glibc 2.5.

Пример:
( LC_CTYPE , 'POSIX' );
echo iconv ( 'UTF-8' , 'ASCII//TRANSLIT' , "Žluťoučký kůň\n" );
// ?lu?ou?k? к??

setlocale (LC_CTYPE, 'cs_CZ');
echo iconv ('UTF-8', 'ASCII//TRANSLIT', "Žluťoučký kůň\n");
// Злутоуцкий кун
?>

Интересно, что установка разных целевых языков приводит к разным, но подходящим транслитерациям. Например:

//немецкое
$utf8_sentence = 'Weiß, Goldmann, Göbel, Weiss, Göthe, Goethe und Götz' ;

//Великобритания
setlocale ( LC_ALL , 'en_GB' );

//транслитерация
$trans_sentence = iconv ('UTF-8', 'ASCII//TRANSLIT', $utf8_sentence);

//дает [Weiss, Goldmann, Gobel, Weiss, Gothe, Goethe und Gotz]
//это наша исходная строка, преобразованная в 7-битный ASCII, как
//человек, говорящий по-английски это (т.е. просто удалить умлауты)
echo $trans_sentence . PHP_EOL ;

//Германия
setlocale ( LC_ALL , 'de_DE' );

$trans_sentence = iconv ('UTF-8', 'ASCII//TRANSLIT', $utf8_sentence);

//дает [Weiss, Goldmann, Goebel, Weiss, Goethe, Goethe und Goetz]
//именно так немец транслитерирует эти
//умлаутированные символы, если вынужден использовать 7- бит ASCII!
//(потому что на самом деле ä = ​​ae, ö = oe и ü = ue)
echo $trans_sentence . PHP_EOL ;

для тестирования различных комбинаций преобразований между кодировками (когда мы не знаем исходную кодировку и удобную кодировку назначения) это пример:

= массив ("UTF-8", "ASCII", "Windows-1252", "ISO-8859-15", "ISO-8859-1", "ISO-8859-6", "CP1256") ;
$цепочка = "" ;
foreach ($tab as $i)
<
foreach ($tab as $j)
<
$chain .= "$i$j" . iconv($i, $j, "$my_string");
>
>

эхо $цепочка ;
?>

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

Как и многие другие люди, я столкнулся с серьезными проблемами при использовании iconv() для преобразования между кодировками (в моем случае из UTF-8 в ISO-8859-15), особенно для больших строк.

Основная проблема здесь заключается в том, что когда ваша строка содержит недопустимые символы UTF-8, нет действительно прямого способа справиться с ними. iconv() просто (и молча!) завершает строку при обнаружении проблемных символов (также при использовании //IGNORE), возвращая обрезанную строку.

= html_entity_decode(htmlentities($oldstring, ENT_QUOTES, 'UTF-8'), ENT_QUOTES, 'ISO-8859-15');

?>

Обходной путь, предложенный здесь и в других местах, также не работает при обнаружении недопустимых символов, по крайней мере, сбрасывая полезную заметку ("htmlentities(): Invalid multibyte sequence in arguments in.")

Я нашел много подсказок, предложений и альтернативных методов (это страшно и, на мой взгляд, не очень хороший знак того, сколько способов PHP изначально предоставляет для преобразования кодировки строк), но ни один из них не работал, кроме этого :

= mb_convert_encoding ($oldstring, 'ISO-8859-15', 'UTF-8');

Если при транслитерации вы получаете вопросительные знаки в выходных данных iconv, убедитесь, что для 'setlocale' установлено значение, поддерживаемое вашей системой.

Некоторые PHP CMS по умолчанию устанавливают для локали значение 'C', это может быть проблемой.

используйте команду "locale", чтобы узнать список..

(LC_CTYPE, 'en_AU.utf8');
$str = iconv ('UTF-8', 'ASCII//ТРАНСЛИТ', "Кот-д'Ивуар");
?>

Для тех, у кого возникают проблемы с отображением данных UCS-2 в браузере, вот простая функция, которая преобразует объекты ucs2 в html unicode:

Вот как преобразовать числа UCS-2 в числа UTF-8 в шестнадцатеричном формате:

функция ucs2toutf8 ($str)
<
for ( $i = 0 ; $i strlen ( $str ); $i += 4 )
<
$substring1 = $стр [$i]. $стр [$i + 1];
$substring2 = $str [ $i + 2 ]. $стр [ $i + 3 ];

if ( $substring1 == "00" )
<
$byte1 = "" ;
$byte2 = $substring2 ;
>
еще
<
$substring = $substring1 . $подстрока2 ;
$byte1 = dechex ( 192 + ( hexdec ( $ substring )/ 64 ));
$byte2 = dechex ( 128 + ( hexdec ( $ substring )% 64 ));
>
$utf8 .= $byte1 . $байт2 ;
>
возврат $utf8 ;
>

echo strtoupper ( ucs2toutf8 ("06450631062D0020" ));

?>

Ввод:
06450631062D
Выход:
D985D8B1D8AD

Если вы хотите преобразовать кодировку Unicode без метки порядка байтов (BOM), добавьте в кодировку порядок следования байтов, например вместо "UTF-16", который добавит спецификацию в начало строки, используйте "UTF-16BE", которая преобразует строку без добавления спецификации.

('CP1252', 'UTF-16', $text); // со спецификацией
icon('CP1252', 'UTF-16BE', $text); // без спецификации

Как сказал orrd101, в последних версиях PHP (мы используем 5.6.5) есть ошибка с //IGNORE, из-за которой мы не могли преобразовать некоторые строки (например, "∙" из UTF8 в CP1251 с помощью //IGNORE).
Но мы нашли обходной путь и теперь используем оба флага //TRANSLIT и //IGNORE:
$text="∙";
icon("UTF8", "CP1251//TRANSLIT //игнорировать", $text);

Только сегодня я узнал, что версии PHP для Windows и *NIX используют разные библиотеки iconv и не совсем совместимы друг с другом.

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

if (! function_exists ('utf8_to_ascii')) setlocale (LC_CTYPE, 'en_AU.utf8');
if (@ iconv («UTF-8», «ASCII//IGNORE//TRANSLIT», 'é') === false ) // PHP, вероятно, использует библиотеку glibc (*NIX)
функция utf8_to_ascii($text) return iconv("UTF-8", "ASCII//TRANSLIT", $text);
>
>
else // PHP, вероятно, использует библиотеку libiconv (Windows)
function utf8_to_ascii ( $text ) if ( is_string ( $text )) // Включает комбинации символы, представленные в виде одного глифа
$text = preg_replace_callback ('/\X/u', __FUNCTION__, $text);
>
elseif ( is_array ( $text ) && count ( $text ) == 1 && is_string ( $text [ 0 ])) // ИГНОРИРУЙТЕ символы, которые нельзя преобразовать в ASCII
$text = iconv("UTF-8", "ASCII//ИГНОРИРОВАТЬ//ТРАНСЛИТ" , $text[0]);
// В документации сказано, что iconv() возвращает false в случае ошибки, но возвращает ''
if ( $text === '' || ! is_string ( $text )) $text = '?' ;
>
elseif ( preg_match ( '/\w/' , $text )) < // Если текст содержит какие-либо буквы.
$text = preg_replace ('/\W+/', '', $text); // . затем удалите все небуквенные
>
>
else < // $text не является строкой
$text = '' ;
>
возврат $text ;
>
>
>

Могут возникнуть ситуации, когда новая версия веб-сайта, полностью в UTF-8, должна отображать некоторые старые данные, оставшиеся в базе данных, с акцентами ISO-8859-1. Проблема заключается в том, что iconv("ISO-8859-1", "UTF-8", $string) не следует применять, если $string уже имеет кодировку UTF-8.

Я использую эту функцию, которая не нуждается в расширении:

Я еще не тестировал его, надеюсь, он поможет.

Я использовал iconv для преобразования cp1251 в UTF-8. Я потратил день, чтобы выяснить, почему строка с русской заглавной "Р" (по звучанию похожа на "р") в конце не может быть вставлена ​​в базу данных.

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

Вот пример преобразования строки в кодировке Windows-1251 (Windows) или cp1251 (Linux/Unix) в кодировку UTF-8.

функция cp1251_utf8 ($sInput)
$sOutput = "";

for ( $i = 0 ; $i strlen ( $sInput ); $i ++ )
$iAscii = ord ( $sInput [ $i ] );

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

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

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

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

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

  • Microsoft.PowerShell.Management
    • Добавить контент
    • Получить содержание
    • Установить содержимое
    • Экспорт-Clixml
    • Экспорт-CSV
    • Экспорт-PSSession
    • Формат-шестнадцатеричный
    • Импорт-CSV
    • Из файла
    • Select-String
    • Отправить сообщение

    Знак порядка байтов

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

    В Windows PowerShell любая кодировка Unicode, кроме UTF7, всегда создает спецификацию. PowerShell (v6 и выше) по умолчанию использует utf8NoBOM для всего вывода текста.

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

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

    Создание сценариев PowerShell на Unix-подобной платформе или использование кроссплатформенного редактора в Windows, например Visual Studio Code, приводит к созданию файла, закодированного с использованием UTF8NoBOM . Эти файлы нормально работают в PowerShell, но могут не работать в 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 с прямым порядком байтов.
    • Байт Кодирует набор символов в последовательность байтов.
    • По умолчанию. Используется кодировка, соответствующая активной кодовой странице системы (обычно ANSI).
    • Oem Использует кодировку, соответствующую текущей кодовой странице OEM в системе.
    • Строка аналогична Unicode .
    • Юникод использует кодировку UTF-16 с прямым порядком байтов.
    • Неизвестно То же, что и Unicode .
    • UTF32 Использует UTF-32 с прямым порядком байтов.
    • UTF7 использует UTF-7.
    • UTF8 использует кодировку UTF-8 (со спецификацией).

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

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

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

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

    Командлет New-ModuleManifest и Export-CliXml также создают файлы UTF-16LE.

    Если целевой файл пуст или не существует, команды Set-Content и Add-Content используют кодировку по умолчанию. По умолчанию используется кодировка, указанная в устаревшей кодовой странице ANSI активной локали системы.

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

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

    New-Item -Type File -Value создает файл UTF-8 без спецификации.

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

    Start-Transcript создает файлы Utf8 со спецификацией.При использовании параметра Append кодировка может быть другой (см. ниже).

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

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

    При отсутствии явного параметра Encoding командлет Add-Content определяет существующую кодировку и автоматически применяет ее к новому содержимому. Если существующее содержимое не имеет спецификации, используется кодировка ANSI по умолчанию. Поведение Add-Content такое же, как и в PowerShell (v6 и выше), за исключением кодировки по умолчанию Utf8 .

    Export-Csv -Append соответствует существующей кодировке, если целевой файл содержит спецификацию. При отсутствии спецификации используется кодировка Utf8.

    Start-Transcript -Append соответствует существующей кодировке файлов, содержащих спецификацию. При отсутствии спецификации по умолчанию используется кодировка Ascii. Это кодирование может привести к потере данных или повреждению символов, если данные в расшифровке содержат многобайтовые символы.

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

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

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

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

    В PowerShell (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 по умолчанию использует utf8NoBOM для всех выходных данных.

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

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

    • $PSDefaultParameterValues
    • $OutputEncoding

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

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

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

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

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

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

    Есть несколько кодировок, и поэтому, иногда увидев непонятные символы, открыв книгу в мобильном приложении или написав статью на сайте, вы, изменив некоторые значения в настройках, увидите знакомый алфавит.< /p>

    Кодировка Windows-1251 — что это такое, какое значение она имеет при создании сайта, какие символы будут доступны и является ли это лучшим решением на сегодняшний день? Обо всем этом в сегодняшней статье. Как всегда, простым языком, максимально понятно и с минимальным количеством терминов.

    Немного теории

    Любой документ на компьютере или в Интернете, как я уже сказал, хранится в виде двоичного кода. Например, если использовать кодировку SCII, то буква «К» будет записываться как 10001010, а виндовс 1251 скрывает под этим номером символ — Љ.В результате, если браузер или программа обратится к другой таблице и прочитает коды windows 1251 вместо ASCII, читатель увидит совершенно непонятный символ.

    Логичный вопрос, зачем было придумывать кучу таблиц с кодами? Дело в том, что помимо русского алфавита есть еще английский, немецкий, китайский. По некоторым оценкам, около 200 000 символов. Хотя, я не очень доверяю этой статистике, вспоминая японцев.

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

    Чем больше символов в таблице, тем длиннее код каждого из них, а значит и вес документа становится больше.

    Представьте, если бы одна книга весила 4 ГБ! Очень долго загружалась, занимала все свободное место на компьютере. Решение о загрузке будет трудным.

    Если вспомнить сайты, то вообще страшно подумать, что будет. Каждая страница открывалась даже на высокоскоростном оптоволокне по часу и более! Я думаю, сотовые телефоны можно смело выбрасывать. Использовать их на улице, даже с 4G? Сомневаюсь.

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

    Microsoft, например, создала windows-1251 для российского сегмента. У него, безусловно, есть свои достоинства и недостатки. Как и любой другой продукт.

    Сейчас только 2% всех страниц в Интернете написаны с помощью 1251. Большинство веб-мастеров используют кодировку UTF-8. Почему так?

    Недостатки и преимущества

    UTF-8, в отличие от windows-1251, является универсальной кодировкой, в ней содержатся буквы различных алфавитов. Есть даже UTF-128, где вообще все языки - туле, суахили, лаосский, мальтийский и так далее.

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

    Эта кодировка является более продуманной, поэтому большинство приложений используют ее по умолчанию. То есть, если вы не скажете программе, какую кодировку вы используете, то в первую очередь она проверит UTF-8.

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

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

    Он содержит много - 256 уроков, затрагивающих javascript и xml. Помимо языков программирования, вы сможете понять, как монетизировать сайт, то есть получать прибыль все больше и больше. Один из немногих курсов, в котором все, что нужно, объяснялось бы так подробно.

    Я сам уже год учусь. в школе блогеров Александра Борисова. Это занимает гораздо больше времени, конца и края еще не видно, но не менее исчерпывающе и дисциплинированно. Мотивирует продолжать развитие.

    Ну а если есть вопросы, не надо искать в интернете. Всегда есть компетентный наставник.

    Что-то я от темы отошел. Вернемся к кодировкам.

    Основания для ванн

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

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

    Пока перенос не нужен, все работает и функционирует, хотя и не совсем корректно. Но после переезда начинаются неприятности. В идеале нужно использовать либо только UTP, либо Windows-1251, но на самом деле такие огрехи всегда есть у всех.

    Чтобы расшифровка была согласованной, необходимо ввести код mysql_query ("SET NAMES cp1251"). В этом случае преобразование будет осуществляться по другому протоколу - cp1251.

    Htaccess

    Если вы твердо решили использовать на сайте 1251, то вам следует найти или создать файл htaccess. Он отвечает за настройки конфигурации. Потребуется добавить еще три строки, чтобы все уместилось.

    Язык по умолчанию en; AddDefaultCharset windows-1251; php_value default_charset "cp1251"

    Я по-прежнему настоятельно рекомендую вам подумать об использовании UTF-8. Он более популярен, прост и насыщен. Какие бы решения вы ни приняли сейчас, важно, чтобы вы могли все исправить позже. Добавить англоязычную версию сайта в этой кодировке будет намного проще. Ничего исправлять не нужно.

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

    До новых встреч и удачи в начинаниях.

    На днях мне пришлось решать небольшую проблему с плохой восприимчивостью набора Denwer к кодировке UTF-8. Проблема, прямо скажем, оказалась тривиальной, и была решена за 15 минут, 10 из которых заняло использование гугла. В это время, исследуя различные форумы, я заметил, что у многих людей они не могли достаточно долго заниматься этой проблемой. Кроме того, я понял, что многих интересует, зачем вообще использовать UTF-8, если есть такая замечательная «русская» кодировка Windows-1251. Вот и решил написать пару постов на эту тему. Я начну с общего описания этих кодировок, а продолжу, непосредственно, описанием решения проблемы использования UTF-8 на пакете Denwer.

    • большинство современных веб-платформ по умолчанию работают на нем;
    • очень удобно использовать для создания многоязычных проектов;
    • набор символов, используемых в кодировке, составляет около 100 000;
    • универсальная кодировка, т.е. русские символы и в Никарагуа остаются русскими.

    Немного теории

    Основные отличия кодировок

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

    Символ UTF-8 может быть закодирован до 6 байтов (в настоящее время используются только 4 байта и больше не планируются). Для русского, например, символ занимает 2 байта. Все символы, которые есть в таблице символов, поддерживаются этой кодировкой. Например, если вам нужен знак копирайта (©), то вам не нужно искать специальный шрифт или изображать символы в графическом формате.

    • UTF-8 позволяет работать одновременно с несколькими языками, т. е. создавать тексты, в которых используются символы разных алфавитов и даже иероглифы. Использование кодировки 1251 невозможно;
    • использование UTF-8 позволяет отказаться от кодовых таблиц, трансляции символов и всех прочих извращений, которые раньше были с однобайтовыми кодировками;
    • Нет кучи кодировок для одного и того же языка, как это было раньше для русского: cp1251, cp866, koi8r, iso8859-5.

    У них вообще есть эта кодировка? Я только знаю разные мифы и легенды на эту тему, вот некоторые из них: «У UTF-8 проблемы со старыми браузерами» вряд ли. В любом случае если старый значит не Рысь и Мозаика _); «На сервере проблемы с UTF-8» — ну да, если сервер по умолчанию пытается определить другую кодировку. Но это точно не отрицательная кодировка.

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

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

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

    • Изменение кодировки существующего крупного сайта с Windows-1251 на UTF-8 может привести к серьезным дополнительным трудовым и финансовым затратам.
    • Русский и английский без проблем работают с Windows-1251, если точно не нужны другие языки, то и UTF-8 не нужна.
    • При работе сайта все функции работы со строками в файле mb_*. Это означает, что весь текст будет закодирован в кодировке сайта.
    • utf strlen зависит от длины строки, соответственно обычный strlen работает в 3 раза быстрее, чем многобайтный: 0,0004 против 0.0013 на тысячу итераций. По замерам это приводит к 10-15% разнице в скорости с реальным сайтом.

    Как перевести сайт с win1251 на UTF-8

    <р>1. Перекодируйте всю базу данных в UTF-8 (скорее всего, вам придется обратиться за помощью к администратору сервера).

    <р>2. Перекодируйте все файлы сайта в UTF-8 (это можно сделать самостоятельно).

    <р>3. Добавьте в файл /bitrix/php_interface/dbconn.php следующие строки:

    определить ("BX_UTF", true);

    <р>4. Добавьте следующие строки в файл /.htaccess:

    Php_value mbstring.func_overload 2 php_value mbstring.internal_encoding UTF-8

    Вы можете перекодировать все файлы сайта в UTF-8 (второй пункт), выполнив команду через SSH в корневой папке сайта:

    Найти. -name "*.php" -type f -exec iconv -fcp1251 -tutf8 -o /tmp/tmp_file()\; -exec mv /tmp/tmp_file()\;

    Кодировка Windows 1251 была создана в начале 90-х для русификации программных продуктов производства Microsoft:

    • 0xFF (25510) — это код, зарезервированный для символа «i». В программах, не поддерживающих чистый 8-й разряд, часто возникают непредсказуемые проблемы;
    • Нет псевдографики, присутствующей в KOI8, CP866.

    Ниже приведены символы из Code 1251 или сокращенно CP1251 ( числа под символами представляют собой шестнадцатеричный код того же символа в Unicode):

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

    Кодовая таблица не является универсальной, то есть для расшифровки текста необходимо использовать ту, которая соответствует кодировке символов:

    Для того, чтобы html-документ корректно отображался в браузере, необходимо указать используемую кодировку. Делается это следующим образом:

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

    Кодирование Windows 1251 в PHP

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

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

    22.3.1. Поддерживаемые наборы символов

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

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

    22.3.2. Установка набора символов

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

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

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

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

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

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

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

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

    22.3.3. Автоматическое преобразование набора символов между сервером и клиентом

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

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

    < td>BIG5 < td>EUC_CN , MULE_INTERNAL, UTF8< td>LATIN9 < /tr>
    Набор символов сервера Доступные наборы символов клиента
    не поддерживается в качестве серверной кодировки
    EUC_CN
    EUC_JP EUC_JP , MULE_INTERNAL, SJIS, UTF8
    EUC_JIS_2004 EUC_JIS_2004 , SHIFT_JIS_2004, UTF8
    EUC_KR EUC_KR , MULE_INTERNAL, UTF8
    EUC_TW EUC_TW , BIG5, MULE_INTERNAL, UTF8
    GB18030< /tt> не поддерживается в качестве серверной кодировки
    GBK не поддерживается в качестве серверной кодировка
    ISO_8859_5 ISO_8859_5 , KOI8R, MULE_INTERNAL, UTF8, WIN866, WIN1251
    ISO_8859_6 ISO_8859_6 , UTF8
    ISO_8859_7< /tt> ISO_8859_7 , UTF8
    ISO_8859_8 ISO_8859_8 , UTF8
    JOHAB не поддерживается в качестве серверной кодировки
    KOI8R KOI8R , ISO_8859_5, MULE_INTERNAL, UTF8, WIN866, WIN1251
    KOI8U KOI8U , UTF8
    LATIN1 LATIN1 , MULE_INTERNAL, UTF8
    LATIN2 LATIN2 , MULE_INTERNAL, UTF8 , WIN1250
    LATIN3 LATIN3 , MULE_INTERNAL, UTF8
    LATIN4 LATIN4 , MULE_INTERNAL , UTF8
    LATIN5 LATIN5 , UTF8
    LATIN6 LATI N6 , UTF8
    LATIN7 LATIN7 , UTF8< /td>
    LATIN8 LATIN8 , UTF8
    LATIN9 , UTF8
    LATIN10< /td> LATIN10, UTF8
    MULE_INTERNAL MULE_INTERNAL, BIG5, EUC_CN, EUC_JP, EUC_KR, EUC_TW, ISO_8859_5 , KOI8R, LATIN1 в LATIN4, SJIS, WIN866, WIN1250 , WIN1251
    SJIS не поддерживается в качестве серверной кодировки
    SHIFT_JIS_2004 не поддерживается в качестве серверной кодировки
    SQL_ASCII любой (преобразование выполняться не будет)
    UHC не поддерживается как серверная кодировка
    UTF8 все поддерживаемые кодировки
    WIN866< /tt> WIN866, ISO_8859_5, KOI8R, MULE_INTERNAL, UTF8, WIN1251
    WIN874 WIN874 , UTF8
    WIN1250 WIN1250, LATIN2, MULE_INTERNAL, UTF8
    WIN1251 WIN1251 , ISO_8859_5, KOI8R , MULE_INTERNAL, UTF8, WIN866
    WIN1252< /td> WIN1252, UTF8
    WIN1253 WIN1253, UTF8
    WIN1254 WIN1254 , UTF8
    WIN1255 WIN1255, UTF8
    WIN1256 WIN1256 , UTF8
    WIN1257 WIN1257, UTF8
    WIN1258 WIN1258, UTF8

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

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

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

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

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

    Чтобы запросить текущую кодировку клиента:

    Чтобы вернуться к кодировке по умолчанию:

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

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

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

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

    22.3.4. Дополнительная литература

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

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

    Читайте также: