Что сломается, если локаль C будет UTF-8 вместо ASCII?
Это работает с вашим образцом
awk '
NR==FNR {patt[$0]; next}
$0 in patt {getline; getline; getline; prev=$0; next}
{print prev; prev=$0}
END {print prev}
' fileA.txt fileB.txt
Вы должны хранить в памяти все файлы fileA, но только нужно запоминать по одной строке из файлаB
Локаль C не является локалью по умолчанию. Это локаль, которая гарантированно не вызовет «неожиданного» поведения. Ряд команд имеет гарантированный вывод (например, заголовки ps или df , формат date ) в C или ] Локаль POSIX . Для кодировок ( LC_CTYPE ) гарантируется, что [: alpha:] содержит только буквы ASCII и так далее. Если бы языковой стандарт C был изменен, это привело бы к неправильному поведению многих приложений. Например, они могут отклонить ввод, который является недопустимым UTF-8, вместо того, чтобы рассматривать его как двоичные данные.
Если вы хотите, чтобы все программы в вашей системе использовали UTF-8, установите локаль по умолчанию на UTF-8. Все программы, которые манипулируют одной кодировкой, то есть. Некоторые программы управляют только потоками байтов и не заботятся о кодировках. Некоторые программы манипулируют несколькими кодировками и не заботятся о локали (например, веб-сервер или веб-клиент устанавливает или считывает кодировку для каждого соединения в заголовке).
Думаю, вы немного запутались. «Язык C» - это такой же языковой стандарт, как и любой другой, который, как вы указываете, традиционно является синонимом 7-битного ASCII.
Он встроен в библиотеку C, я полагаю, поэтому у библиотеки есть какой-то запасной вариант - не может быть языкового стандарта.
Однако это не имеет ничего общего с тем, как программы, построенные из кода C, обрабатывают ввод. Локаль используется для преобразования ввода, который передается в исполняемый файл, который, если системный языковой стандарт - UTF-8, UTF-8 - это то, что получает программа, независимо от того, был ли ее исходный код написан на C или на чем-то еще. . Итак:
Я был бы удивлен, если бы увидел код, который может работать только с 7-битным чистым вводом и не может быть легко адаптирован для приема C с поддержкой UTF-8
На самом деле не имеет смысла.Минимальный кусок стандартного источника C, который читает из стандартного ввода, получает поток байтов от системы. Если система использует UTF-8 и генерирует поток из некоторого оборудования HID, то этот поток может содержать символы в кодировке UTF-8. Если он пришел откуда-то еще (например, из сети, из файла), он может содержать что угодно, что делает предположение о стандарте UTF-8 полезным.
Тот факт, что локаль C представляет собой гораздо более ограниченный набор символов, чем локаль UTF-8, не имеет отношения. Его просто называют «локалью C», но на самом деле он не имеет ничего общего с составлением кода C, чем любой другой.
Фактически, вы можете жестко закодировать символы UTF-8 в c-строки в исходном коде. Предполагая, что система использует кодировку UTF-8, эти строки будут выглядеть правильно при использовании результирующим исполняемым файлом.
Ссылка «Роджер Ли», которую вы разместили в комментарии, я считаю, относится к использованию расширенного набора (UTF-8) в качестве локали C в библиотеке C, предназначенной для встроенной среды, так что нет другая локаль должна быть загружена для системы для работы с UTF-8.
Итак, ответ на вопрос: «Что бы сломалось, если бы языковой стандарт C был UTF-8 вместо ASCII?» есть, я бы предположил , ничего, но за пределами встроенной среды и т. д. в этом нет особой необходимости. Но очень вероятно, что в какой-то момент это станет нормой для таких библиотек, как GNU C (я думаю, вполне может быть).