Обработка строк C - Википедия - C string handling

В C язык программирования имеет набор функций, реализующих операции над струны (строки символов и строки байтов) в своем стандартная библиотека. Различные операции, такие как копирование, конкатенация, токенизация и поиск поддерживаются. Для символьных строк стандартная библиотека использует соглашение о том, что строки оканчивающийся нулем: строка п символы представлены как множество из п + 1 элементы, последний из которых является символом NUL.

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

Определения

Строка определяется как непрерывная последовательность кодовые единицы заканчивается первой единицей нулевого кода (часто называемой NUL кодовый блок).^[1] Это означает, что строка не может содержать нулевую кодовую единицу, так как первая видимая отмечает конец строки. В длина строки - это количество кодовых единиц перед нулевой кодовой единицей.^[1] Память, занимаемая строкой, всегда на одну кодовую единицу больше, чем длина, так как пространство необходимо для хранения нулевого терминатора.

Обычно термин нить означает строку, в которой кодовая единица имеет тип char, что на всех современных машинах составляет ровно 8 бит. C90 определяет широкие струны^[1] которые используют кодовую единицу типа wchar_t, который на современных машинах составляет 16 или 32 бита. Это было предназначено для Unicode но все чаще используется UTF-8 вместо этого в обычных строках для Unicode.

Строки передаются функциям путем передачи указателя на первую единицу кода. С символ * и wchar_t * относятся к разным типам, функции, обрабатывающие широкие строки, отличаются от функций, обрабатывающих обычные строки, и имеют другие имена.

Строковые литералы ("текст" в исходном коде C) преобразуются в массивы во время компиляции.^[2] Результатом является массив кодовых единиц, содержащий все символы плюс завершающую нулевую кодовую единицу. В C90 L "текст" производит широкую строку. Строковый литерал может содержать блок нулевого кода (один из способов - поставить \0 в источник), но это приведет к тому, что строка закончится в этой точке. Остальная часть литерала будет помещена в память (с добавлением еще одной единицы нулевого кода в конец), но невозможно знать, что эти единицы кода были переведены из строкового литерала, поэтому такой исходный код нет строковый литерал.^[3]

Кодировки символов

Каждая строка заканчивается первым вхождением единицы нулевого кода соответствующего вида (char или же wchar_t). Следовательно, байтовая строка (символ *) может содержать не-NUL персонажи в ASCII или любой Расширение ASCII, но не символы в таких кодировках, как UTF-16 (даже если 16-битная кодовая единица может быть ненулевой, ее старший или младший байт может быть нулевым). Кодировки, которые могут храниться в широких строках, определяются шириной wchar_t. В большинстве реализаций wchar_t не менее 16 бит, поэтому все 16-битные кодировки, такие как UCS-2, можно хранить. Если wchar_t 32-битные, затем 32-битные кодировки, например UTF-32, можно хранить. (Стандарт требует наличия «типа, который содержит любой широкий символ», что в Windows больше не выполняется, так как сдвиг UCS-2 в UTF-16.) C ++ 11 и C11 добавляют два типа с явной шириной char16_t и char32_t.^[4]

Кодировки переменной ширины может использоваться как в байтовых, так и в широких строках. Длина строки и смещения измеряются в байтах или wchar_t, а не в «символах», что может сбить с толку начинающих программистов. UTF-8 и Shift JIS часто используются в байтовых строках C, а UTF-16 часто используется в широких строках C, когда wchar_t составляет 16 бит. Усечение строк символами переменной длины с использованием таких функций, как strncpy может создавать недопустимые последовательности в конце строки. Это может быть небезопасно, если усеченные части интерпретируются кодом, который предполагает, что ввод действителен.

Поддержка литералов Unicode, таких как char foo [512] = "φωωβαρ";(UTF-8) или wchar_t foo [512] = L "φωωβαρ"; (UTF-16 или UTF-32, зависит от wchar_t) определяется реализацией,^[5] и может потребовать, чтобы исходный код был в той же кодировке, особенно для char где компиляторы могут просто скопировать все, что находится между кавычками. Некоторые компиляторы или редакторы потребуют ввести все символы, отличные от ASCII, как xNN последовательности для каждого байта UTF-8 и / или uNNNN для каждого слова UTF-16. Начиная с C11 (и C ++ 11), новый char foo [512] = u8 "φωωβαρ"; Доступен синтаксис литерала, который гарантирует UTF-8 для литерала строки байтов.^[6]

Обзор функций

Большинство функций, которые работают со строками C, объявлены в string.h заголовок (cstring в C ++), а функции, которые работают со строками ширины C, объявлены в wchar.h заголовок (cwchar в C ++). Эти заголовки также содержат объявления функций, используемых для обработки буферов памяти; таким образом, название звучит неправильно.

Функции, заявленные в string.h чрезвычайно популярны, так как как часть Стандартная библиотека C, они гарантированно работают на любой платформе, поддерживающей C. Однако с этими функциями существуют некоторые проблемы безопасности, такие как потенциальные переполнение буфера при неправильном использовании, программисты предпочитают более безопасные и, возможно, менее переносимые варианты, некоторые из которых перечислены ниже. Некоторые из этих функций также нарушают const-правильность приняв const строковый указатель и возврат не-const указатель внутри строки. Чтобы исправить это, некоторые из них были разделены на два перегруженные функции в C ++ версии стандартной библиотеки.

В исторической документации термин «символ» часто использовался вместо «байт» для строк C, что приводит к тому, что многие^{[ВОЗ? ]} поверить, что эти функции как-то не работают для UTF-8. Фактически, все длины определены в байтах, и это верно во всех реализациях, и эти функции работают как с UTF-8, так и с однобайтовыми кодировками. Документация BSD была исправлена, чтобы прояснить это, но документация POSIX, Linux и Windows по-прежнему использует «символ» во многих местах, где «байт» или «wchar_t» являются правильным термином.

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

Константы и типы

Функции

Многобайтовые функции

Все эти функции принимают указатель на mbstate_t объект, который вызывающий должен поддерживать. Первоначально это было предназначено для отслеживания состояний сдвига в мб кодировки, но современные, такие как UTF-8, в этом не нуждаются. Однако эти функции были разработаны исходя из предположения, что Туалет кодировка не кодирование с переменной шириной и поэтому предназначены для работы только с одним wchar_t за один раз, передавая его по значению, а не используя указатель на строку. Поскольку UTF-16 - это кодировка переменной ширины, mbstate_t был повторно использован для отслеживания суррогатных пар в широкой кодировке, хотя вызывающий должен по-прежнему обнаруживать и вызывать mbtowc дважды для одного персонажа.^[65][66][67]

Числовые преобразования

Стандартная библиотека C содержит несколько функций для числовых преобразований. Функции, работающие с байтовыми строками, определены в stdlib.h заголовок (cstdlib заголовок в C ++). Функции, работающие с широкими строками, определены в wchar.h заголовок (cwchar заголовок в C ++).

В strtoxxx функции не const-правильно, поскольку они принимают const указатель на строку и вернуть не-const указатель внутри строки.

Кроме того, начиная с Нормативной поправки 1 (C95), атокс функции считаются включенными в strtoxxx функции, по этой причине ни C95, ни какой-либо более поздний стандарт не предоставляют версии этих функций для расширенных символов. Аргумент против атокс в том, что они не различают ошибку и 0.^[80]

Популярные расширения

Замены

Несмотря на устоявшаяся потребность заменить strcat^[13] и strcpy^[9] с функциями, не допускающими переполнения буфера, не возникло никакого принятого стандарта. Частично это связано с ошибочным мнением многих программистов на C, что strncat и strncpy иметь желаемое поведение; однако ни одна из функций не была разработана для этого (они были предназначены для управления строковыми буферами фиксированного размера, заполненными нулями, формат данных, менее часто используемый в современном программном обеспечении), а поведение и аргументы не интуитивно понятны и часто неправильно записываются даже экспертами программисты.^[91]

Самый популярный^[а] замена strlcat и strlcpy функции, появившиеся в OpenBSD 2.4 в декабре 1998 г.^[91] Эти функции всегда записывают один NUL в целевой буфер, при необходимости усекая результат, и возвращают размер буфера, который может потребоваться, что позволяет обнаруживать усечение и обеспечивает размер для создания нового буфера, который не будет усекаться. Их критиковали за якобы неэффективность,^[94] поощрение использования строк C (вместо какой-либо превосходной альтернативной формы строки),^[95][96] и сокрытие других потенциальных ошибок.^[97][98] Следовательно, они не были включены в Библиотека GNU C (используются программным обеспечением в Linux), хотя они реализованы в библиотеках C для OpenBSD, FreeBSD, NetBSD, Солярис, OS X, и QNX, а также в альтернативных библиотеках C для Linux, таких как мусл введен в 2011 году.^[99][100] Отсутствие поддержки библиотеки GNU C не помешало различным авторам программного обеспечения использовать ее и, среди прочего, собирать замену. SDL, GLib, ffmpeg, rsync, и даже внутри Ядро Linux. Доступны реализации с открытым исходным кодом для этих функций.^[101][102]

Иногда memcpy^[44] или же memmove^[46] используются, поскольку они могут быть более эффективными, чем strcpy поскольку они не проверяют повторно значение NUL (это менее верно для современных процессоров). Поскольку им в качестве параметра требуется длина буфера, правильная установка этого параметра может избежать переполнения буфера.

В рамках ее 2004 г. Жизненный цикл разработки безопасности, Microsoft представила семейство «безопасных» функций, включая strcpy_s и strcat_s (наряду со многими другими).^[103] Эти функции были стандартизированы с некоторыми незначительными изменениями как часть дополнительных C11 (Приложение K) предложен ISO / IEC WDTR 24731. Эти функции выполняют различные проверки, в том числе, является ли строка слишком длинной для размещения в буфере. Если проверки завершаются неудачно, вызывается заданная пользователем функция «обработчик ограничения времени выполнения»,^[104] который обычно прерывает программу.^[105][106] Некоторые функции выполняют деструктивные операции перед вызовом обработчика ограничения времени выполнения; Например, strcat_s устанавливает назначение в пустую строку,^[107] что может затруднить восстановление после ошибок или их отладку. Эти функции вызвали значительную критику, потому что изначально они были реализованы только в Windows, и в то же время предупреждающие сообщения начали выдавать Microsoft Visual C ++ предлагая программистам использовать эти функции вместо стандартных. Некоторые предполагают, что это попытка Microsoft заблокировать разработчиков своей платформой.^[108] Хотя реализации этих функций с открытым исходным кодом доступны, эти функции отсутствуют в общих библиотеках Unix C.^[109] Опыт использования этих функций показал значительные проблемы с их внедрением и ошибки в использовании, поэтому предлагается исключить Приложение K для следующей версии стандарта C.^[110] Использование memset_s также был предложен как способ избежать нежелательной оптимизации компилятора.^[111][112]

Смотрите также

• Синтаксис C § Строки - синтаксис исходного кода, включая escape-последовательности с обратной косой чертой
• Строковые функции

Примечания

Рекомендации

внешняя ссылка

• Быстрый memcpy на C, несколько примеров кодирования C для разных типов архитектур команд ЦП