Где имеет мой 'uniq' или 'вид-u' строка, которую уводят с некоторыми unicode символами
Поскольку те приложения то место конфигурационные файлы в $HOME игнорируют Спецификацию Базового каталога XDG, особенно:
Существует единственный базовый каталог, относительно которого должны быть записаны определенные для пользователя конфигурационные файлы. Этот каталог определяется $XDG_CONFIG_HOME переменной среды...
Если $XDG_CONFIG_HOME или не установлен или не пуст, значение по умолчанию, равное $HOME/.config, должно использоваться.
Короткая версия: сопоставление действительно не работает в утилитах командной строки.
Более длительная версия: базовая функция для сравнения двух строк strcoll. Описание не очень полезно, но концептуальный принцип действия состоит в том, чтобы преобразовать обе строки в каноническую форму и затем сравнить эти две канонических формы. Функция strxfrm конструкции эта каноническая форма.
Давайте наблюдать канонические формы нескольких строк (с GNU libc, под Debian сжимают):
$ export LC_ALL=en_US.UTF-8
$ perl -C255 -MPOSIX -le 'print "$_ ", unpack("h*", strxfrm($_)) foreach @ARGV' b a A à 〼 〇
b d010801020
a c010801020
A c010801090
à 101010102c6b
〼 101010102c6b102c6b102c6b
〇 101010102c6b102c6b102c6b
Как Вы видите, 〼, и 〇 имеют ту же каноническую форму. Я думаю поэтому, что эти символы не упоминаются в таблицах сопоставления en_US.UTF-8 локаль. Они, однако, присутствуют в японской локали.
$ export LC_ALL=ja_JP.UTF-8
$ perl -C255 -MPOSIX -le 'print "$_ ", unpack("h*", strxfrm($_)) foreach @ARGV' 〼 〇
〼 303030
〇 3c9b
Исходный код для данных локали (в Debian сжимают) находится в /usr/share/i18n/locales/en_US, который включает /usr/share/i18n/locales/iso14651_t1_common. Этот файл не имеет записи для U3007 или U303C, и при этом они не включены ни в какой диапазон, который я могу найти.
Я не знаком с правилами создать порядок сопоставления, но от того, что я понимаю, соответствующая формулировка
НЕОПРЕДЕЛЕННЫЙ символ должен интерпретироваться как включая все значения кодированного набора символов, не указанные явно или через символ замещающего знака. (…), Если никакой НЕОПРЕДЕЛЕННЫЙ символ не указан, и текущий кодированный набор символов содержит символы, не указанные в этом разделе, утилита должна выпустить предупреждающее сообщение и поместить такие символы в конце символьного порядка сопоставления.
Похоже, что Glibc вместо этого игнорирует символы, которые не указаны. Я не знаю, существует ли дефект моего понимания спецификации POSIX, если я пропустил что-то в определении локали Glibc, или если существует ошибка в компиляторе локали Glibc.
К "безопасно" sort Строки Unicode, возможно, взгляните на msort:
[...] Msort обеспечивает большую гибкость в выборе полей ключа, большего количества типов сравнения, способность использовать правила сопоставления от различных локалей на различных ключах, способность обработать числа в незападных системах счисления и множество других опций, недостающих вида GNU и вида BSD. Принимая во внимание, что msort понимает, что Unicode, вид GNU и вид BSD не делают. [...]
-
1@til: Спасибо за то, что сделали меня знающий
msort. Дополнительный GUI представляется немного легче получить ощущение того, что предлагается. Способность скопировать сгенерированную команду очень удобна... И да, это действительно сортирует unicode символы, но (не делайте Вас, просто любят те "buts" :)... но это не имеет уникальной опции :(..., как упомянуто на ссылке, которую Вы отправили:Capabilities of GNU sort and BSD sort lacking in msort are the ability to merge files without sorting them (the --merge option) and the ability to emit only the first of an equal run (the --unique option)... Вид работает, хотя :) – Peter.O 23.07.2011, 03:55
charmaps/UTF-8не говорит ничто о сопоставлении, этоlocales/en_USэто имеет значение. Первое правилоLC_COLLATE: не использоватьLC_COLLATE. В C (= POSIX) локаль, сопоставление разумно (базирующийся строго на значениях числового символа). – Gilles 'SO- stop being evil' 22.07.2011, 22:10LC_COLLATE=C...спасибо... – Peter.O 23.07.2011, 07:09