Elettracompany.com

Компьютерный справочник
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Lc all php

Локали и кодировки

Введение

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

Работа с локалями в PHP

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

Локали в Windows

Для того, чтобы узнать, какие локали доступны в Windows, нужно зайти в панель управления, «Язык и региональные стандарты».

На вкладке «Дополнительно», в разделе «Кодовые страницы таблиц преобразования» показан список всех возможных локалей для Windows, которые можно использовать в PHP.

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

В общем случае, использование выглядит по следующей схеме: Язык_Регион.Номер_кодовой_страницы

Для России это может выглядеть как Russian_Russia.1251 (cp1251) или Russian_Russia.20866 (KOI8-R).

Для Украины — Ukrainian_Ukraine.1251 (cp1251).

Вместо длинных названий можно использовать сокращённые russian , american , ukrainian и так далее. При этом кодовая страница выставится с учётом региональных настроек, для России и Украины — 1251, для Америки — 1252.

Единственная кодировка, с которой у меня возникли проблемы, как ни странно, оказалась UTF-8. При попытке выставить эту кодировку, выставляются все категории локалей, кроме основной. Вывод локализованных сообщений при этом идёт в cp1251.

Пока это можно списать на внутренний механизм PHP работы со строками. С шестой версии PHP вся обработка строк должна будет вестись в UTF-8, но до тех пор надо просто знать об этом и делать поправку.

Ещё одной странностью при работе с локалями в PHP на Windows является неправильная работа с категориями локалей. Так, например, я выставляю локаль на функции времени KOI8-R, setlocale(LC_TIME, ‘Russian_Russia.20866’) , но почему-то выставляется cp1251 на все категории. Суть проблемы я так и не понял, возможно, это просто баг (проверялось на PHP 5.2.3), а возможно, что внутренний механизм Windows просто не позволяет этого делать. Хотя по мне, так это чистой воды баг.

В общем-то, на этом можно и закончить разговор о локалях на Windows. Главное, запомнить, что локали, которые портированы из UNIX, под WIndows работают только для «галочки». Шаг влево, шаг вправо и результат будет непредсказуемым. Безопасно можно использовать только cp1251 (windows-1251) и KOI8-R, и только для LC_ALL .

Локали в UNIX

Выше я описал работу с локалями в Windows, теперь можно заострить внимание на UNIX-like системах. Для простоты, я буду их называть UNIX, а подразумевать FreeBSD :). В контексте данной статьи это не особо важно.

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

Так может выглядеть работа системной команды locale , которая выводит текущие настройки локали для пользователя. А так, обычно, выглядят настройки локали для пользователя, под которым работает PHP:

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

Хотя w является множеством знаков, из которых может состоять слово (алфавит, цифры и _), регулярное выражение не срабатывает. Причина как раз в том, что, работая с cp1251, мы не сказали об этом php. Чтобы исправить положение, достаточно воспользоваться функцией setlocale() и указать правильную локаль, например, так:

Здесь первый аргумент — это категория, на которую будет распространяться локаль (константа LC_*), второй — название локали. Начиная с версии 4.3.0 можно указывать несколько имён локалей в виде массива или в качестве дополнительных аргументов. После вызова функция установит первую подходящую локаль и вернёт её имя:

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

Если учесть, что koi8-r достаточно популярная кодировка для UNIX-севреров, а windows-1251 для русскоязычных сайтов, то подобное «необычное» поведение не такая уж и редкость. Когда-то я и сам столкнулся с этой проблемой при портировании проекта на реальный хостинг.

После установки правильной локали все примеры, которые не работали выше, будут работать как нужно!

По-русски заговорит и функция strftime(), которая корректно работает с локалями, а также и всё остальное, что зависит от локали.

Кодировки в MySQL

Напомню, что возможность задавать кодировки появилась только в MySQL 4.1.11 и выше.

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

Первое, чему необходимо научиться, смотреть текущие настройки соединения с mysql:

Критичными для пользователя являются character_set_client и character_set_results, которые отвечают за кодировку, в которой данные поступают в базу, и кодировку, в которой данные поступают из базы к пользователю. Если эти две кодировки отличаются от той, в которой работает клиент, в нашем случае php-скрипты, то неминуемо будут «странности», например, при сортировке выборки или внесении данных в базу.

Второе, что необходимо знать, как правильно сообщить mysql о кодировках. Самый простой и правильный способ, это использовать запрос set names:

После этого три переменные character_set_client, character_set_connection и character_set_results примут значение cp1251. Это будет означать — клиент работает в кодировке windows-1251 (cp1251).

Помимо этого можно устанавливать непосредственно серверные переменные:

Теперь данные поступают и извлекаются в разных кодировках.

Список доступных кодировок можно просмотреть так:

И третье, что необходимо знать, — правила создания таблиц для хранения данных в нужной кодировке. К слову, данные можно хранить в любой кодировке, а работать с ними в кодировке клиента. Однако, важно понимать, что кодировки носят национальный характер и должны соответствовать вносимым данным. Иначе будут потери. Для русского языка есть три национальных кодировки koi8r, cp866, cp1251, которые могут конвертироваться друг в друга без потерь. Также можно использовать интернациональную кодировку UTF8.

Кодировку можно выставить на базу данных, таблицу и поле таблицы. Так, например, можно создать базу данных в кодировке koi8r:

Читать еще:  Система защиты государственной тайны pdc

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

Следующим шагом я создам таблицу в cp1251 и одним полем в utf8:

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

Данные хранятся в разном виде, но поступают к пользователю именно так, как надо!

Подробнее с кодировками и проблемами их использования можно ознакомиться на http://dev.mysql.com/doc/refman/5.1/en/charset.html.

Кодировка HTML-страниц

Объявить кодировку html-страницы можно двумя способами: через заголовки и мета-тег в самой странице. Мета-тег используется только в статичных страницах.

Я не буду его разбирать, это проблемы html. Во всех остальных случаях предпочтительней использовать HTTP-заголовок Content-Type.

PHP позволяет работать с HTTP-заголовками посредством функции header():

Но браузер отобразит страницу корректно только в том случае, когда php-файлы сами были созданы в кодировке cp1251. Также нужно понимать, что заголовки должны быть отправлены до любого вывода на экран.

При необходимости перекодировать страницы «на лету», достаточно воспользоваться буферизацией и iconv:

Надпись «Привет, мир!» будет выведена в юникоде, при этом браузер получит информацию о кодировке через заголовки и правильно отобразит страницу. Но важно понимать, что внутри скрипта и при соединении с базой данных надо использовать windows-1251 (cp1251), поскольку страница должна быть сформирована в одной кодировке.

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

Заключение

Для безопасной разработки русскоязычных веб-проектов необходимо включать в файл с общими настройками следующие команды:

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

© 2020 Антон Прибора. При копировании материалов с сайта, пожалуйста, указывайте ссылку на источник.

setlocale

(PHP 4, PHP 5, PHP 7)

setlocale — Устанавливает настройки локали

Описание

Устанавливает настройки локали.

Информация о локали модифицируется во всем процессе, а не по каждому потоку отдельно. Если вы используете PHP на многопоточном сервере, таком как IIS, HHVM или Apache под Windows, вы можете обнаружить неожиданные изменения в настройках локали во время выполнения скриптов, никогда и не вызывавших setlocale() . Это происходит из-за того, что другие скрипты, запущенные в параллельных потоках данного процесса, в то же самое время поменяли настройки локали для всего процесса с помощью setlocale() .

Список параметров

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

  • LC_ALL — все нижеперечисленное
  • LC_COLLATE — функции сравнения строк, см. strcoll()
  • LC_CTYPE — функции преобразования и классификации строк, например strtoupper()
  • LC_MONETARY — для функции localeconv()
  • LC_NUMERIC — задает символ десятичного разделения (см. также localeconv() )
  • LC_TIME — форматирование даты/времени функцией strftime()
  • LC_MESSAGES — для системных сообщений (доступна, если PHP был скомпилирован с поддержкой libintl)

Если в качестве locale передана пустая строка «» или NULL , имена локалей будут взяты из одноименных переменных окружения или переменной с именем «LANG».

Если в качестве locale передан «0», локаль изменена не будет, а будет возвращено текущее значение.

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

(Необязательные аргументы в виде строк или массивов для установки настроек локали до первой успешной попытки.)

Замечание:

На Windows setlocale(LC_ALL, ») устанавливает имена локалей из системных региональных/языковых настроек (доступных через Панель Управления).

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

Возвращает имя вновь установленной локали или FALSE , если система не поддерживает установку локали, указанная локаль не существует или передано недопустимое имя категории.

Недопустимое имя категории также вызывает предупреждение. Имена локалей и категорий описаны в » RFC 1766 и » ISO 639. Разные системы имеют различные схемы именования локалей.

Замечание:

Возвращаемое функцией setlocale() значение зависит от системы, на которой запущен PHP. Она возвращает точно то же значение, что и системная функция setlocale.

Форум PHP программистов ► PHP основы ► Кодировки

Жадный квантификатор

Профиль
Группа: Эксперт

Сообщений: 6130
Пользователь №: 4795
На форуме: 11 лет, 11 месяцев, 27 дней
Карма: 118

На выходе получаем тоже что и на входе.

— выдает ru_RU.UTF-8, что говорит о том что локаль установленна корректно.

При этом даты через strftime выводятся на нормальном русском языке.

— работает на «ура», вот только у меня уже везде используются обычные строковые функции.

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

Если кто сталкивался с подобной несправедливостью по отношению к русскому языку, буду рад узнать вариант решения данной траблы!

twin, пока единственный рабочий вариант — использование mbstring модуля:

mb_internal_encoding ( ‘UTF-8’ ); // Устанавливаем кодировку строк
setlocale ( LC_ALL , ‘ru_RU.UTF-8’ ); // Устанавливаем нужную локаль (для дат, денег, запятых и пр.)

// Юзаем вместо обычных строчных функций mb_* (модуль mbstring)
echo mb_strtoupper ( ‘Hello World!’ ). ‘
‘ ; // Для английского
echo mb_strtoupper ( ‘СоТоНа’ ). ‘
‘ ; // Для русского
echo mb_strtoupper ( ‘Beiträge’ ). ‘
‘ ; // Для немецкого
echo mb_strtoupper ( ‘Zmień wygląd’ ); // Для польского

Просто изначально использовал в движке обычные строковые функции, не думал что будет такая проблема.
Сейчас все заменил на mb_, проблем нет!

Итак в продолжении темы напишу немного про дружбу регулярок и русских букв в utf8.

Написал я форум , сделал все красиво, в юникоде Потом думаю — «какой же форум без поиска?!» и прикрутил к нему поиск (тоже красивый — с подсветкой ). Играл с ним 3 дня и 3 ночи, нарадоваться не мог, пока случайно не создал топик на русском. И одолела меня злость на эти мультибайтовые кодировки, — русские буквы отказывались подсвечиваться (точнее подсвечивались, но регистрозависимо), и начал я гром и молнии метать по всему гуглу в поисках вакцины от неверных.

Первое что мне пришло в голову, — заглянуть на родной php .net. Там я прочитал, что mb_internal_encoding(‘UTF-8’); выставляется для текстовых функций. Надо сказать, что все обычные строковые функции я перезагрузил [по совету vasa_c] с помощью строчки php _value mbstring.func_overload «7» в .htaccess-е (Что значит 7-ка, можно прочитать тут). Но как оказалось мало установить кодировку символов, нужно установить кодировку самих регулярных выражений с помощью mb_regex_encoding(‘UTF-8’);. Все бы хорошо, но вот отказывалась eregi_replace() работать регистронезависимо. И с модификаторами и без — никак. Я уже подумывал на это дело забить, но что-то меня потянуло к гуглу опять. И нарыл я инфу, что PCRE и без всяких перезагрузок работают с НЕлатиницей! Нужно всего-навсего добавить модификатор u. Тоесть регулярка получится примерно такой —

Читать еще:  Www matlab ru

Может кому пригодится сей рассказ
Надеюсь моя эпопея с русскими буквами на этом закончится

Решение проблем современного интернет-магазина

Проблема отображения букв кириллицы при импорте из CSV файла

Если у вас проблема отображения букв кириллицы при импорте из CSV файла в ваш интренет-магазин с использованием нашего модуля экспорта и импорта данных, тогда это описание проблемы может помочь вам в его решении. Данная пробема проявляется в частичном отображении букв кириллицы. Связаная она с настройками локали на используемом хостинге. Для импорта данных из файла CSV необходима локаль ru_RU.cp1251, т.к. экспортный файл из программы обработки прайсов E-Trade PriceList Importer экспортируется в кодировке win-1251.

Почему функции работы со строками не работают с «русскими буквами», т.е. с кириллицей?
При обработке текстов, содержащих символы кирилицы («русские буквы»), с помощью функций: fgetcsv(), strToLower(), strToUpper(), preg_match() и т. п., в некоторых случаях может наблюдаться некорректная работа указанных функций. Собственно проблема возникает тогда, когда кодировка сайта отличается от кодировки, используемой PHP-интерпретатором по умолчанию.

На сегодняшний день наиболее популярной кодировкой является кодировка UTF-8, позволяющая в одном документе использовать символы различных языков, например сочетать символы кирилицы и китайские, греческие символы на одной странице. Однако для «старых» русскоязычных сайтов характерно использование кодировки windows-1251 (CP1251). В тех случаях когда сайт с кодировкой CP1251 запускается на web-сервере, использующем по умолчанию кодировку UTF-8, а вместе с web-сервером эту же кодировку по умолчанию будет использовать и PHP-интерпретатор, наблюдается некорректная работа некоторых функций PHP, используемых для обработки текста. Так же на хостинге может не работать, а на Windows Apache (localhost) дома все хорошо, если это так, то это явная проблема настроек локали хостинга.

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

Ниже приводится пример использования функции setlocale():

Описание функции setlocale из справки языка PHP.

setlocale — устанавливает локальную информацию.

Описание
string setlocale (mixed category, string locale)
Category это именованная константа (или строка), специфицирующая категорию функций, на которые действуют локальные установки:

* LC_ALL — все ниже указанные
* LC_COLLATE — сравнение строк, см. strcoll()
* LC_CTYPE — классификация и конвертация символов, например, strtoupper()
* LC_MONETARY — localeconv()
* LC_NUMERIC — десятичный сепаратор (см. также: localeconv())
* LC_TIME — форматирование даты и времени с помощью strftime()

Если locale это пустая строка «», название локализации будет установлено из значений переменных окружения с теми же именами, что и вышеуказанные категории, или из «LANG».
Если locale равен нулю или «0», локальные установки не меняются, только возвращаются текущие установки.
Setlocale возвращает новую текущую локализацию, или FALSE, если locale-функциональность не реализована на данной платформе, специфицированная locale не существует или имя категории неправильное. Неправильное имя категории вызывает также появление предупреждающего сообщения.

Пример 2. setlocale()

Пример 3. Простой пример кода с использованием функции fgetcsv() для разбора строк и колонок CSV файла. Как раз данная функция используется при работе нашего модуля импорта и экспорта данных.

Содержимое файла e-trade.csv:

При выводе на страницу в отладочном режиме PHP отображается в таком виде, (нет кириллицы):

Для проверки локализации которая используется для работы PHP используйте маленький код:

а на домашнем «денвере» (джентльменский набор Web-разработчика, «Д.н.w.р», читается «Денвер») возвращает:

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

Настройка локали в консоли в ОС Linux CentOS.

Довольно часто владельцы выделенных серверов получают свои сервера от хостинг провайдеров с неверно сконфигурированной локалью или не донастроенной для «старой» кодировки 1251. В следствии чего в консоли или при работе скриптов PHP не отображаются русские буквы или отображаются не корректно. Так как CentOS практически является клоном RedHat Enterprise Linux, то консоль по умолчанию использует кодировку UTF-8, то есть юникод. Постепенно кодировка юникод(UTF-8) вытесняет кучу «наших» кодировок, например KOI8-R, CP1251.

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

обычный вывод команды примерно такой:

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

Это сигнализирует что есть проблемы.

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

В выводе команды необходимо найти необходимую нам локаль. В случае с кодировкой UTF-8 необходимая локаль имеет вид ru_RU.utf8. Если такая строка есть в выводе команды, тогда необходимо сделать следующее действия:
Создаем файл /etc/sysconfig/i18n командой:

После чего в файл пишем следующие строки:

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

Если же при выводе команды

Данная команда, она берет из стандартной папки /usr/share/i18n/locales/файл ru_RU (это файл с описанием русской локали) и из папки /usr/share/i18n/charmaps файл UTF-8.gz (это символьная карта для описания юникода) и на основе этих файлов генерирует нужную нам локаль ru_RU.UTF-8.
После этого действия в системе появляется нужная локаль, а дальше необходимо сделать так как описано абзацом выше.

Если у вас нет файлов в папке /usr/share/i18n/, то необходимо разбираться с самим glibc-common, это отдельная статья, поэтому информацию об glibc-common попробуйте найти в сети интернет.

Что делает «LC_ALL = C»?

Что делает значение C для LC_ALL в Unix-подобных системах?

Я знаю, что он заставляет ту же локаль для всех аспектов, но что делает C ?

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

LC_ALL – это переменная среды, которая переопределяет все другие параметры локализации ( за исключением $LANGUAGE при некоторых обстоятельствах ).

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

Обычно вы fr_CH.UTF-8 $LANG своим предпочтениям со значением, которое идентифицирует ваш регион (например, fr_CH.UTF-8 если вы находитесь на франкоговорящей Швейцарии, используя UTF-8). Отдельные переменные LC_xxx переопределяют определенный аспект. LC_ALL переопределяет их все. Команда locale при вызове без аргумента дает сводку текущих настроек.

Читать еще:  Веб приложение на php

Например, в системе GNU я получаю:

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

Или переопределите все с помощью LC_ALL.

В сценарии, если вы хотите принудительно установить определенный параметр, так как вы не знаете, какие параметры принудительно принудительно (возможно, LC_ALL), ваш лучший, самый безопасный и обычно единственный вариант – заставить LC_ALL.

Локаль C – это особый язык, который должен быть простейшим языком. Вы могли бы также сказать, что, в то время как другие локали для людей, языковой стандарт C предназначен для компьютеров. В языке C символы являются одиночными байтами, кодировка – ASCII (ну, это не требуется, но на практике это будет в системах, которые большинство из нас когда-либо будет использовать), порядок сортировки основан на байтовых значениях, язык обычно является английским (хотя для сообщений приложений (в отличие от таких, как имена месяца или дня или сообщения из системных библиотек) это зависит от автора приложения), и такие вещи, как символы валюты, не определены.

В некоторых системах существует разница с языковой версией POSIX, где, например, порядок сортировки для символов, отличных от ASCII, не определен.

Обычно вы выполняете команду с LC_ALL = C, чтобы избежать того, чтобы настройки пользователя мешали вашему скрипту. Например, если вы хотите, чтобы [az] соответствовал 26 символам ASCII от a до z , вы должны установить LC_ALL=C

В системах GNU LC_ALL=C и LC_ALL=POSIX (или LC_MESSAGES=C|POSIX ) переопределяют $LANGUAGE , тогда как LC_ALL=anything-else не будет.

Несколько случаев, когда вам обычно нужно установить LC_ALL=C :

  • sort -u или sort . | uniq. sort . | uniq. Во многих локалях, отличных от C, в некоторых системах (особенно в GNU) некоторые символы имеют одинаковый порядок сортировки . sort -u не сообщает уникальные строки, а одну из каждой группы строк, которые имеют равный порядок сортировки. Поэтому, если вам нужны уникальные строки, вам нужна локаль, где символы являются байтами, а все символы имеют разный порядок сортировки (что гарантирует языковой стандарт C ).
  • то же самое относится к оператору = оператора POSIX-совместимого оператора expr или == совместимого с POSIX awk s ( mawk и gawk не являются POSIX в этом отношении), которые не проверяют, идентичны ли две строки, независимо от того, сортируются ли они одинаково.
  • Диапазоны символов, например, в grep . Если вы хотите LC_ALL букву на языке пользователя, используйте grep ‘[[:alpha:]]’ и не изменяйте LC_ALL . Но если вы хотите a-zA-Z символы a-zA-Z ASCII, вам нужно либо LC_ALL=C grep ‘[[:alpha:]]’ либо LC_ALL=C grep ‘[a-zA-Z]’ ¹. [az] соответствует символам, которые сортируются после a и до z (хотя со многими API-интерфейсами это сложнее, чем это). В других местах вы вообще не знаете, что это такое. Например, некоторые локали игнорируют регистр для сортировки, поэтому [az] в некоторых API, таких как шаблоны bash , могут включать [BZ] или [AY] . Во многих локалях UTF-8 (в том числе en_US.UTF-8 в большинстве систем), [az] будет включать латинские буквы от a до y с диакритикой, но не те из z (поскольку z сортирует перед ними), которые я не могу себе представить будет то, что вы хотите (зачем вы хотите включить é а не ź ?).

арифметика с плавающей запятой в ksh93 . ksh93 decimal_point значение decimal_point в LC_NUMERIC . Если вы пишете скрипт, содержащий a=$((1.2/7)) , он перестанет работать при запуске пользователем, чья локаль имеет запятую в качестве десятичного разделителя:

Тогда вам нужны такие вещи, как:

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

Каждый раз, когда вы обрабатываете входные данные или выходные данные, которые не предназначены для / для человека. Если вы разговариваете с пользователем, вы можете использовать их соглашение и язык, но, например, если вы генерируете некоторые цифры для подачи какого-либо другого приложения, которое ожидает десятичные точки английского стиля или английские месячные имена, вы захотите set LC_ALL = C:

Это также относится к таким ситуациям, как нечувствительность к регистру (например, в grep -i ) и преобразование case ( awk ‘s toupper() , dd conv=ucase …). Например:

не может совпадать с I в пользовательской локали. Например, в некоторых турецких локалях это не так, как верхний регистр i – это İ (обратите внимание на точку), а нижний регистр I – ı (обратите внимание на отсутствующую точку).

¹ В зависимости от кодировки текста это не всегда правильно. Это справедливо для UTF-8 или однобайтовых наборов символов (например, iso-8859-1), но не обязательно для многобайтовых наборов символов, отличных от UTF-8.

Например, если вы находитесь в zh_HK.big5hkscs locale (Гонконг, используя вариант Гонконга кодировки китайского символа BIG5), и вы хотите искать английские буквы в файле, закодированном в этих кодировках, либо выполните:

было бы неправильно, потому что в этой кодировке (и многие другие, но вряд ли использовались после выхода UTF-8), многие символы содержат байты, которые соответствуют кодировке ASCII символов A-Za-z. Например, все A䨝䰲丕乙乜你再劀劈呸哻唥唧噀噦嚳坽 (и многие другие) содержат кодировку A 䨝 – 0x96 0x41, а A – 0x41, как в ASCII. Таким образом, наш LC_ALL=C grep ‘[a-zA-Z]’ будет совпадать с теми строками, которые содержат эти символы, так как это неверно интерпретирует эти последовательности байтов.

будет работать, но только если LC_ALL в противном случае не задан (что бы переопределить LC_COLLATE ). Таким образом, вам может понадобиться сделать:

если вы хотите искать английские буквы в файле, закодированном в кодировке локали.

Насколько я могу судить, OS X использует порядок сортировки кодовой точки в локалях UTF-8, поэтому это исключение из некоторых пунктов, упомянутых в ответе Стефана Чазеласа.

Это отображает 26 в OS X и 310 в Ubuntu:

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

В приведенном ниже коде ничего не отображается в OS X, что указывает на отсутствие двух последовательных кодовых точек (по крайней мере, между U + 000B и U + D7FF), которые имеют один и тот же порядок сортировки.

(В приведенных выше примерах используется %b потому что printf \U25 приводит к ошибке в zsh.)

Некоторые символы и последовательности символов, которые имеют один и тот же порядок сортировки в системах GNU, не имеют того же порядка сортировки в OS X. Это печатает ① сначала в OS X (используя sort OS X или GNU), но ② сначала в Ubuntu:

Это печатает три строки в OS X (используя sort OS X или sort GNU), но одна строка в Ubuntu:

Похоже, что LC_COLLATE управляет «алфавитным порядком», используемым ls. Языковой стандарт США будет сортироваться следующим образом:

в основном игнорируя периоды. Вы можете предпочесть:

Конечно. Установка LC_COLLATE на C выполняет это. Обратите внимание, что он также будет сортировать строчные буквы после всех капиталов:

C является стандартным языком, «POSIX» является псевдонимом «C». Я думаю, что «C» происходит от ANSI-C. Возможно, ANSI-C определяет локаль POSIX.

Ссылка на основную публикацию
Adblock
detector