'printf', к которому я обращаюсь, является стандартной "программой" (не встроенное): /usr/bin/printf
Я проверял printf как жизнеспособный метод преобразования Шестнадцатеричный литерал Кодовой точки Unicode в его символьное представление Unicoder,
Я выглядел хорошим, и казался безупречным.. (btw. встроенный printf не может сделать этого вообще (я думаю)...
Я затем думал для тестирования его в более низком экстремальном конце спектра кода, и это перестало работать с лавиной ошибок.. Все в диапазоне ASCII (= 7 битов)
Самая странная вещь состояла в том, что 3 значения обычно печатали; они:
Я хотел бы знать то, что продолжается здесь. Набор символов ASCII является совершенно определенно частью последовательности Кодовой точки Unicode....
Я озадачен, и все еще без хорошего способа колотить пишут сценарий этого конкретного converion.. Предложения приветствуются.
Чтобы быть развлеченными той же самой лавиной ошибок, вставьте следующий код в терминал...
# Here is one of the error messages
# /usr/bin/printf: invalid universal character name \u0041
# ...for them all, run the following script
(
for nib1 in {0..9} {A..F}; do
for nib0 in {0..9} {A..F}; do
[[ $nib1 < A ]] && nl="\n" || nl=" "
$(type -P printf) "\u00$nib1$nib0$nl"
done
done
echo
)
У команды printf есть причины не принимать заклинателей в этом диапазоне. Если вы посмотрите на код sounce для printf, вы увидите следующий комментарий:
Имя универсального символа не должно указывать короткий идентификатор символа в диапазоне от 00000000 до 00000020, от 0000007F до 0000009F или 0000D800 до 0000DFFF включительно. Универсальное имя символа не должно обозначать символ в требуемом наборе символов.
blockquote>Вы могли бы быть в состоянии перекомпилировать без этой проверки, но для меня это выглядит очень преднамеренно. Вместо этого попробуйте использовать команду без \ u, например:
( for nib1 in {0..9} {A..F}; do for nib0 in {0..9} {A..F}; do $(type -P printf) "\00$nib1$nib0" done done echo )
Три рабочих символа - это три печатных символа ASCII, которых нет в базовом наборе C . Причина, по которой эти символы запрещены в C, состоит в том, что это будет сложно для компиляторов: им потребуется выполнить интерполяцию \u
перед лексическим анализом, который, я думаю, сломается в нескольких угловых случаях, и будет непрактичным во многих компиляторах в любом случае (потому что символы вне базового набора должны быть разрешены только в нескольких местах).
Наличие одинаковых запрещенных символов не имеет смысла в утилите оболочки. Я подозреваю, что это ошибка, и $
, @
и `
также не должны работать. Причина, по которой они не поддерживаются, заключается в том, чтобы снова было легче разбирать строки. Например, если вы хотите определить, что в строке нет специального символа , который вы собираетесь поместить в запрос к базе данных , вы можете проверить, что строка не содержит '
, и не беспокойство об этом, содержащее \u002a
.
Подумайте об использовании перекодирования , как предложено в руководстве по GNU coreutils , или (на практике более переносимо) Perl или python.
(for nib1 in {0..9} {A..F}; do
for nib0 in {0..9} {A..F}; do
$(type -P printf) "\x$nib1$nib0"
done
done
echo )
печатает (отрегулировал формат руки)
! " # $ % & ' ( ) * + , - . / 0 1 2 3 4 5 6 7 8 9 : ; < = > ?
@ A B C D E F G H I J K L M N O P Q R S T U V W X Y Z [ \ ] ^ _
` a b c d e f g h i j k l m n o p q r s t u v w x y z { | } ~
� � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �
� � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �
� � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �
� � � � � � � � � � � � � � � � � � � � � � � � � � � � � �
Обратите внимание, что некоторые «символьные» управляющие коды «работали», т.е. HT, VT, LF. и т.д.