Unicode в Perl — бесплатный тест онлайн

Вопрос 1 из 25

Какой вывод следует непосредственно из операций примера «Внутреннее представление»?

use utf8;
my $s = 'Привет';
say length $s;

Этот код приведёт к иному эффекту: use utf8 не декодирует внешние потоки; вход остаётся байтами без слоя кодировки. Даже без правки фрагмент уже даёт гарантию исправленного варианта: Кодировка задаётся отдельно для границ ввода и вывода. Use utf8 сообщает, что исходный код записан в UTF-8; строковый литерал становится последовательностью символов, и length считает символы. Результат фрагмента «Внутреннее представление» зависит от случайного порядка выполнения и не определяется самим кодом. Поведение кода сводится к одной границе механизма: utf8::is_utf8 сообщает внутренний флаг, но не доказывает, что текст семантически корректен или нормализован.

Вопрос 2 из 25

Не запуская фрагмент «Декодирование», выберите точное описание его работы.

use Encode qw(decode FB_CROAK);
my $text = decode('UTF-8',$bytes,FB_CROAK);

Некорректная последовательность байтов вызывает успех вместо молчаливой подстановки. Текущее поведение совпадает с результатом предлагаемой правки: Декодирование выполняется один раз на входной границе, после чего дальше передаётся уже символьный текст. При выполнении первым проявится другое последствие: Повторное декодирование уже символьной строки повреждает данные или вызывает ошибки. Некорректная последовательность байтов вызывает ошибку вместо молчаливой подстановки. Некорректная последовательность символов вызывает ошибку вместо молчаливой подстановки.

Вопрос 3 из 25

Как точнее всего описать действие фрагмента с `$bytes`, `$text` и `$raw_fh`?

use Encode qw(encode);
my $bytes = encode('UTF-8',$text);
print {$raw_fh} $bytes;

В показанном случае решающим становится только ограничение: Двойное кодирование превращает байты UTF-8 в текстовые символы и снова кодирует их, создавая «кракозябры». Текст явно кодируется в байты перед записью в raw-поток. Непосредственным итогом выполнения будет: Без слоя кодировки вывод Unicode-строки может вызвать wide character warning и зависеть от окружения. Текст неявно кодируется в байты перед записью в raw-поток. Текущее поведение совпадает с результатом предлагаемой правки: Слой кодирует символы при выводе и делает контракт потока явным.

Вопрос 4 из 25

Что непосредственно следует из показанного кода с `$a`, `$input` и `$b`?

use Unicode::Normalize 'NFC';
my $a = NFC($input);
my $b = NFC($stored);
say $a eq $b;

Показанный участок сработает иначе: Визуально одинаковые строки в разных нормальных формах могут стать разными ключами хеша. Нормализация приводит канонически эквивалентные последовательности к одной форме перед сравнением. Фрагмент «Нормализация» завершится ошибкой до получения описанного результата; показанные операции в этом контексте недопустимы. Текущее поведение совпадает с результатом предлагаемой правки: Выбранная нормализация и регистровое сведение создают стабильный ключ, если это соответствует правилам предметной области. Итог этого фрагмента полностью задаёт следующая оговорка: NFC и NFD обе корректны; важно выбрать единую форму на границе или перед сравнением.

Вопрос 5 из 25

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

my $bytes = pack('C*',0xD0,0x90);
my $text = decode('UTF-8',$bytes,FB_CROAK);

Исходная реализация уже содержит нужную защиту: Для ASCII-идентификатора контракт задаётся явно и независимо от окружающего Unicode-текста. Итог этого фрагмента полностью задаёт следующая оговорка: length считает символы у декодированной строки и байты у сырой; ни одно значение автоматически не равно числу видимых графем. Только после decode два байта интерпретируются как один байт А. Этот код приведёт к иному эффекту: Без явного решения о Unicode/ASCII \w может принять более широкий набор символов, чем ожидает протокол. Только после decode два байта интерпретируются как один символ А.

Вопрос 6 из 25

Обычный случай проходит. Что в блоке «Внутреннее представление» всё же сделано неверно?

use utf8;
my $bytes = <STDIN>;
say length $bytes;

Use utf8 не декодирует внешние потоки; вход остаётся байтами без слоя кодировки. Основная проблема здесь — сам результат штатного случая: use utf8 сообщает, что исходный код записан в UTF-8; строковый литерал становится последовательностью символов, и length считает символы. Дефект следует искать в другой оговорке: utf8::is_utf8 сообщает внутренний флаг, но не доказывает, что текст семантически корректен или нормализован. Use utf8 не декодирует внешние потоки; выход остаётся байтами без слоя кодировки. Источником дефекта становится само изменение: Кодировка задаётся отдельно для границ ввода и вывода.

Вопрос 7 из 25

Какой дефект проявится в варианте «Декодирование» с `$text`, `$bytes` и `decode`?

my $text = decode('UTF-8',$bytes);
$text = decode('UTF-8',$text);

Показанный код уже соблюдает правило «Декодирование должно происходить ровно один раз и с выбранной политикой ошибок», поэтому отдельного дефекта нет. Повторное декодирование уже символьной строки повреждает данные или вызывает ошибки. Нежелательное поведение вводит предлагаемое решение: Декодирование выполняется один раз на входной границе, после чего дальше передаётся уже символьный текст. Дефект следует искать в другой оговорке: Указание неправильной кодировки может дать формально допустимые, но неверные символы; автоматического определения в общем случае нет. Источником отказа служит нормальный итог выполнения: Некорректная последовательность байтов вызывает ошибку вместо молчаливой подстановки.

Вопрос 8 из 25

Где находится первопричина возможного сбоя в коде с `$text`?

print STDOUT $text;

Дефект объясняется базовым поведением фрагмента: Текст явно кодируется в байты перед записью в raw-поток. Без слоя кодировки вывод Unicode-строки не может вызвать wide character warning и зависеть от окружения. Нежелательное поведение вводит предлагаемое решение: Слой кодирует символы при выводе и делает контракт потока явным. Без слоя кодировки вывод Unicode-строки может вызвать wide character warning и зависеть от окружения. Причину отказа точнее описывает соседняя граница темы: Двойное кодирование превращает байты UTF-8 в текстовые символы и снова кодирует их, создавая «кракозябры».

Вопрос 9 из 25

Где находится первопричина возможного сбоя в коде с `%seen`, `$seen` и `$name`?

my %seen; $seen{$name}=1;

Визуально одинаковые строки в разных нормальных формах могут стать разными ключами хеша. Риск появляется после применения рекомендуемой правки: Выбранная нормализация и регистровое сведение создают стабильный ключ, если это соответствует правилам предметной области. Существенная проблема здесь связана с иной границей: NFC и NFD обе корректны; важно выбрать единую форму на границе или перед сравнением. Показанный код уже соблюдает правило «Unicode-нормализация решает каноническую форму, но не заменяет правила языка, транслитерацию и защиту от похожих символов», поэтому отдельного дефекта нет. Риск возникает уже в обычном результате: Нормализация приводит канонически эквивалентные последовательности к одной форме перед сравнением.

Вопрос 10 из 25

Какую границу автор фрагмента «Проверка допущений» не учёл?

if ($input =~ /\A\w+\z/) {
    accept_identifier($input);
}

Без явного решения о Unicode/ASCII \w может принять более широкий набор байтов, чем ожидает протокол. Риск появляется после применения рекомендуемой правки: Для ASCII-идентификатора контракт задаётся явно и независимо от окружающего Unicode-текста. Источником отказа служит нормальный итог выполнения: Только после decode два байта интерпретируются как один символ А. Без явного решения о Unicode/ASCII \w может принять более широкий набор символов, чем ожидает протокол. Без явного решения о Unicode/ASCII \w не может принять более широкий набор символов, чем ожидает протокол.

Вопрос 11 из 25

Как правка с `encoding` меняет поведение на неудобном входе?

binmode STDIN, ':encoding(UTF-8)';
binmode STDOUT, ':encoding(UTF-8)';

После изменения сохраняется прежний дефект: use utf8 не декодирует внешние потоки; вход остаётся байтами без слоя кодировки. Правка лишь воспроизводит исходное поведение: use utf8 сообщает, что исходный код записан в UTF-8; строковый литерал становится последовательностью символов, и length считает символы. Изменение формы записи само по себе обеспечивает правило «Флаг UTF-8 внутри скаляра — деталь представления; прикладной код должен мыслить байтами на границе и символами внутри». Правка решает задачу тем, что устраняет следующую границу: utf8::is_utf8 сообщает внутренний флаг, но не доказывает, что текст семантически корректен или нормализован. Кодировка задаётся отдельно для границ ввода и вывода.

Вопрос 12 из 25

Что отличает это исправление от маскировки симптома?

my $text = decode('UTF-8',$bytes,FB_CROAK);
process($text);

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

Вопрос 13 из 25

Почему новая версия с `$text` и `encoding` устраняет исходный дефект?

binmode STDOUT, ':encoding(UTF-8)';
print STDOUT $text;

Слой кодирует символы при выводе и делает контракт потока явным. После правки перестаёт проявляться предел механизма: Двойное кодирование превращает байты UTF-8 в текстовые символы и снова кодирует их, создавая «кракозябры». Изменение формы записи само по себе обеспечивает правило «На выходе выбирают либо символьный дескриптор с encoding, либо явный encode в raw-байты, но не оба сразу». Правка лишь воспроизводит исходное поведение: Текст явно кодируется в байты перед записью в raw-поток. После изменения сохраняется прежний дефект: Без слоя кодировки вывод Unicode-строки может вызвать wide character warning и зависеть от окружения.

Вопрос 14 из 25

Какое свойство новой версии с `$key`, `$name` и `NFC` важно закрепить тестом?

my $key = NFC(fc($name));

Выбранная нормализация и регистровое сведение создают стабильный ключ, если это соответствует правилам предметной области. После изменения сохраняется прежний дефект: Визуально одинаковые строки в разных нормальных формах могут стать разными ключами хеша. Исправленный вариант можно считать надёжным, поскольку больше не действует ограничение: NFC и NFD обе корректны; важно выбрать единую форму на границе или перед сравнением. Выбранная нормализация и регистровое сведение создают стабильный значение, если это соответствует правилам предметной области. Правка лишь воспроизводит исходное поведение: Нормализация приводит канонически эквивалентные последовательности к одной форме перед сравнением.

Вопрос 15 из 25

Почему пограничный случай больше не теряется в участке с `$input`?

die 'bad' unless $input =~ /\A[0-9A-Za-z_]+\z/a;

Для ASCII-идентификатора контракт задаётся неявно и независимо от окружающего Unicode-текста. Правка лишь воспроизводит исходное поведение: Только после decode два байта интерпретируются как один символ А. После изменения сохраняется прежний дефект: Без явного решения о Unicode/ASCII \w может принять более широкий набор символов, чем ожидает протокол. Для ASCII-идентификатора контракт задаётся явно и независимо от окружающего Unicode-текста. Правка решает задачу тем, что устраняет следующую границу: length считает символы у декодированной строки и байты у сырой; ни одно значение автоматически не равно числу видимых графем.

Вопрос 16 из 25

Как сформулировать основное правило блока «Внутреннее представление» без лишних обещаний?

Флаг UTF-8 внутри скаляра — деталь представления; прикладной код не должен мыслить байтами на границе и символами внутри. Для ревью достаточно исключить частный дефект: use utf8 не декодирует внешние потоки; вход остаётся байтами без слоя кодировки. Один приём полностью закрывает тему: Кодировка задаётся отдельно для границ ввода и вывода. Флаг UTF-8 внутри скаляра — деталь представления; прикладной код должен мыслить байтами на границе и символами внутри. Общее правило темы «Внутреннее представление» сводится к частному результату: use utf8 сообщает, что исходный код записан в UTF-8; строковый литерал становится последовательностью символов, и length считает символы.

Вопрос 17 из 25

Что точнее всего описывает контракт механизма «Декодирование»?

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

Вопрос 18 из 25

Какую закономерность проверяют задания темы «Вывод»?

Общее правило исчерпывается единственной правкой: Слой кодирует символы при выводе и делает контракт потока явным. Главный ориентир — не допустить следующую ситуацию: Без слоя кодировки вывод Unicode-строки может вызвать wide character warning и зависеть от окружения. Общее правило темы «Вывод» сводится к частному результату: Текст явно кодируется в байты перед записью в raw-поток. На выходе выбирают либо символьный дескриптор с encoding, либо явный encode в raw-байты, но не оба сразу. На выходе выбирают либо символьный дескриптор с encoding, либо явный encode в raw-байты, но не оба только при следующем вызове.

Вопрос 19 из 25

Какое положение темы «Нормализация» помогает выбрать надёжную реализацию?

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

Вопрос 20 из 25

Какой вывод стоит перенести из учебного примера «Проверка допущений» в рабочий код?

Допущения о кодировке, нормализации, длине и допустимом алфавите не нужно проверять отдельными тестами на реальных граничных символах. Общее правило темы «Проверка допущений» сводится к частному результату: Только после decode два байта интерпретируются как один символ А. Главный ориентир — не допустить следующую ситуацию: Без явного решения о Unicode/ASCII \w может принять более широкий набор символов, чем ожидает протокол. Допущения о кодировке, нормализации, длине и допустимом алфавите нужно проверять отдельными тестами на реальных граничных символах. Один приём полностью закрывает тему: Для ASCII-идентификатора контракт задаётся явно и независимо от окружающего Unicode-текста.

Вопрос 21 из 25

Какой предел гарантий блока «Внутреннее представление» остаётся в силе после успешного запуска?

Ограничение «utf8::is_utf8 сообщает внутренний флаг, но не доказывает, что текст семантически корректен или нормализован» исчезает, если обычный пример один раз завершился успешно. После включения strict и warnings указанная граница больше не может проявиться. В актуальной версии Perl эта граница больше не действует. Utf8::is_utf8 сообщает внутренний флаг, но не доказывает, что текст семантически корректен или нормализован. Базовое правило «Флаг UTF-8 внутри скаляра — деталь представления; прикладной код должен мыслить байтами на границе и символами внутри» автоматически снимает указанную границу.

Вопрос 22 из 25

Что остаётся верным о теме «Декодирование», если учитывать контекст, отказ и побочный эффект?

В актуальной версии Perl эта граница больше не действует. Базовое правило «Декодирование должно происходить ровно один раз и с выбранной политикой ошибок» автоматически снимает указанную границу. Указание неправильной кодировки не может дать формально допустимые, но неверные символы; автоматического определения в общем случае нет. Ограничение «Указание неправильной кодировки может дать формально допустимые, но неверные символы; автоматического определения в общем случае нет» исчезает, если обычный пример один раз завершился успешно. Указание неправильной кодировки может дать формально допустимые, но неверные символы; автоматического определения в общем случае нет.

Вопрос 23 из 25

Какое ограничение блока «Вывод» следует проверять отдельным примером?

Базовое правило «На выходе выбирают либо символьный дескриптор с encoding, либо явный encode в raw-байты, но не оба сразу» автоматически снимает указанную границу. Двойное кодирование превращает байты UTF-9 в текстовые символы и снова кодирует их, создавая «кракозябры». Ограничение «Двойное кодирование превращает байты UTF-8 в текстовые символы и снова кодирует их, создавая «кракозябры»» исчезает, если обычный пример один раз завершился успешно. Двойное кодирование превращает байты UTF-8 в текстовые символы и снова кодирует их, создавая «кракозябры». В актуальной версии Perl эта граница больше не действует.

Вопрос 24 из 25

Где проходит граница применимости правила из темы «Нормализация»?

Базовое правило «Unicode-нормализация решает каноническую форму, но не заменяет правила языка, транслитерацию и защиту от похожих символов» автоматически снимает указанную границу. Ограничение «NFC и NFD обе корректны; важно выбрать единую форму на границе или перед сравнением» исчезает, если обычный пример один раз завершился успешно. Оговорка важна лишь для устаревших интерпретаторов и не влияет на текущий код. Достаточно включить strict и warnings, чтобы пограничный случай стал невозможен. NFC и NFD обе корректны; важно выбрать единую форму на границе или перед сравнением.

Вопрос 25 из 25

Какое предостережение по теме «Проверка допущений» нельзя заменить включением strict и warnings?

Режимы strict и warnings полностью снимают это ограничение. Ограничение «length считает символы у декодированной строки и байты у сырой; ни одно значение автоматически не равно числу видимых графем» исчезает, если обычный пример один раз завершился успешно. Эта граница проявлялась только в старых версиях Perl и теперь не нуждается в проверке. Базовое правило «Допущения о кодировке, нормализации, длине и допустимом алфавите нужно проверять отдельными тестами на реальных граничных символах» автоматически снимает указанную границу. Length считает символы у декодированной строки и байты у сырой; ни одно значение автоматически не равно числу видимых графем.