C 文字列処理

Cプログラミング言語には、標準ライブラリ内に文字列(文字列とバイト文字列)に対する操作を実装する一連の関数があります。コピー、連結、トークン化、検索などのさまざまな操作がサポートされています。文字列の場合、標準ライブラリは文字列がNULL で終了するという規則を使用します。つまり、 n文字の文字列はn + 1要素の配列として表され、最後の要素は数値 0 の 「 NUL文字」です。

プログラミング言語自体における文字列の唯一のサポートは、コンパイラが引用符で囲まれた文字列定数をnull で終了する文字列に変換することです。

文字列は、最初のゼロ コード単位 ( NULコード単位と呼ばれることが多い)で終了する連続したコード単位のシーケンスとして定義されます。 ^[1]つまり、最初のゼロ コード単位が文字列の終わりを示すため、文字列にはゼロ コード単位を含めることはできません。文字列の長さは、ゼロ コード単位の前のコード単位の数です。^[1]文字列が占有するメモリは、ゼロ終端文字を格納するためのスペースが必要なため、長さよりも常に 1 コード単位多くなります。

一般的に、文字列という用語は、コード単位が 型の文字列を意味しchar、これはすべての最新のマシンでちょうど 8 ビットです。C90は、型のコード単位を使用するワイド文字列^[1]を定義しています。これは最新のマシンでは 16 ビットまたは 32 ビットです。これはUnicodewchar_tを対象としていましたが、 Unicode の通常の文字列では代わりに UTF-8 を使用することがますます一般的になっています。

文字列は、最初のコード ユニットへのポインターを渡すことによって関数に渡されます。char *と はwchar_t *異なる型であるため、ワイド文字列を処理する関数は通常の文字列を処理する関数とは異なり、異なる名前を持ちます。

文字列リテラル（"text"Cソースコード内）は、コンパイル時に配列に変換されます。^[2]結果は、すべての文字と末尾のゼロコード単位を含むコード単位の配列です。C90ではL"text"ワイド文字列を生成します。文字列リテラルにはゼロコード単位を含めることができます（1つの方法は\0ソースに配置することです）が、これにより文字列はその時点で終了します。リテラルの残りの部分はメモリに配置されます（末尾に別のゼロコード単位が追加されます）が、それらのコード単位が文字列リテラルから変換されたことを知ることは不可能であるため、そのようなソースコードは文字列リテラルではありません。 ^[3]

各文字列は、適切な種類のゼロ コード単位 (charまたはwchar_t) の最初の出現で終了します。したがって、バイト文字列 ( ) には、 ASCIIまたは任意のASCII 拡張の非NUL文字char*を含めることができますが、 UTF-16などのエンコードの文字を含めることはできません(16 ビット コード単位がゼロでなくても、上位バイトまたは下位バイトがゼロの可能性があります)。ワイド文字列に格納できるエンコードは、 の幅によって定義されます。ほとんどの実装では、は少なくとも 16 ビットであるため、UCS-2などのすべての 16 ビット エンコードを格納できます。 が32 ビットの場合、UTF-32などの 32 ビット エンコードを格納できます。(標準では「任意のワイド文字を保持する型」が必要ですが、Windows では UCS-2 から UTF-16 への移行以降、これは当てはまりません。これは標準の欠陥として認識され、C++ で修正されました。) ^[4] C++11 と C11では、明示的な幅とを持つ 2 つの型が追加されています。^[5]wchar_twchar_twchar_tchar16_tchar32_t

可変幅エンコーディングは、バイト文字列とワイド文字列の両方で使用できます。文字列の長さとオフセットは、文字数wchar_tではなくバイト数または で測定されるため、初心者のプログラマーにはわかりにくい場合があります。UTF -8とShift JIS はC バイト文字列でよく使用され、 が 16 ビットの場合、UTF-16 はC ワイド文字列でよく使用されますwchar_t。 などの関数を使用して可変幅文字を含む文字列を切り捨てると、strncpy文字列の末尾に無効なシーケンスが生成されることがあります。切り捨てられた部分が、入力が有効であると想定するコードによって解釈される場合、これは安全でない可能性があります。

(UTF-8) や(UTF-16 または UTF-32、 に依存)などの Unicode リテラルのサポートは実装定義であり、 ^[6]ソースコードが同じエンコーディングであることが要求される場合があります。特に、コンパイラが引用符で囲まれた内容をコピーするだけの場合です。一部のコンパイラやエディタでは、UTF-8 の各バイト、および/または UTF-16 の各ワードに対して、すべての非 ASCII 文字をシーケンスとして入力する必要があります。C11 (および C++11) 以降では、のように、バイト文字列リテラルに対して UTF-8 を保証する新しいリテラル プレフィックスが使用できます。^[7] C++20およびC23以降では、UTF-8 文字を格納するための型が追加され、u8 プレフィックス付き文字リテラルと文字列リテラルの型はそれぞれ および に変更されました。 char foo[512] = "φωωβαρ";wchar_t foo[512] = L"φωωβαρ";wchar_tchar\xNN\uNNNNu8char foo[512] = u8"φωωβαρ";char8_tchar8_tchar8_t[]

過去のドキュメントでは、C 文字列に対して「バイト」ではなく「文字」という用語がよく使用されていたため、多くの人^{[誰? ]は、これらの関数が}UTF-8では動作しないと信じています。実際、すべての長さはバイト単位で定義されており、これはすべての実装に当てはまります。また、これらの関数は、UTF-8 でもシングルバイト エンコーディングと同様に動作します。BSD ドキュメントはこれを明確にするために修正されましたが、POSIX、Linux、および Windows ドキュメントでは、多くの場所で「バイト」または「wchar_t」が正しい用語であるにもかかわらず、依然として「文字」が使用されています。

メモリ バッファを処理する関数は、データの一部として null バイトを含むバイト シーケンスを処理できます。これらの関数の名前は通常、プレフィックスmemの反対として ,で始まりますstr。

C 文字列を操作する関数のほとんどはヘッダーstring.h( cstringC++ の場合) で宣言されていますが、C ワイド文字列を操作する関数はwchar.hヘッダー ( cwcharC++ の場合) で宣言されています。これらのヘッダーには、メモリ バッファーの処理に使用される関数の宣言も含まれているため、この名前はやや誤った名称です。

で宣言された関数は、 C 標準ライブラリstring.hの一部として、C をサポートするどのプラットフォームでも動作することが保証されているため、非常に人気があります。ただし、これらの関数には、注意深く適切に使用しないとバッファ オーバーフローが発生する可能性があるなど、セキュリティ上の問題があるため、プログラマーはより安全で、おそらく移植性が低いバリアントを好みます。そのうちの人気のあるものをいくつか以下に示します。これらの関数の一部は、文字列ポインタを受け入れて文字列内で非ポインタを返すことで、 const の正確性に違反しています。これを修正するために、一部の関数は、標準ライブラリの C++ バージョンで 2 つのオーバーロードされた関数に分離されています。 constconst

これらの機能はすべてmbstate_tオブジェクトは元々静的メモリに格納されており（関数はスレッドセーフではない）、後から追加されたものは呼び出し側が維持する必要がある。これは元々、mb従来のエンコーディングでは、UTF-8のような最近のエンコーディングではこれは必要ありません。しかし、これらの関数は、トイレエンコーディングは可変幅エンコーディングではないため、正確に1つの文字を処理するように設計されています。char_t 型一度に1つずつ、文字列ポインタではなく値で渡します。UTF-16は可変幅のエンコードなので、mbstate_tワイドエンコーディングのサロゲートペアを追跡するために再利用されているが、呼び出し側は依然として検出して呼び出す必要がある。mbtowc1文字につき2回です。^{[80] [81] [82]}標準へのその後の追加では、プログラマが関心を持つ唯一の変換はUTF-8とUTF-16の間であることが認められ、これを直接提供します。

C 標準ライブラリには、数値変換用の関数がいくつか含まれています。バイト文字列を処理する関数は、ヘッダーstdlib.h( C++ では header ) で定義されています。cstdlibワイド文字列を処理する関数は、wchar.hヘッダー ( cwcharC++ では header ) で定義されています。

関数strchr、、、、、およびそれらbsearchのワイド対応関数は、文字列ポインタを受け入れて文字列内の非ポインタを返すため、constが正しくありません。これはC23で修正されました。[ 95 ^]strpbrkstrrchrstrstrmemchrconstconst

また、規範修正第1版（C95）以降、atoxx関数は関数に包含されると考えられておりstrtoxxx、そのためC95もそれ以降の標準もこれらの関数のワイド文字バージョンを提供していない。反対論としてはatoxx、エラーとを区別していないという点が挙げられる0。^[96]

^[22]と^[18]をバッファオーバーフローを許さない関数に置き換える必要性は十分に認識されているにもかかわらず、受け入れられる標準は生まれていない。これは、多くのCプログラマが、とが望ましい動作をするだろうと誤って信じていることに一部起因している。しかし、どちらの関数もそのために設計されたものではない（これらは、最近のソフトウェアではあまり一般的に使用されていないデータ形式である、ヌルで埋められた固定サイズの文字列バッファを操作することを目的としていた）。また、その動作と引数は直感的ではなく、熟練したプログラマでさえも間違って記述することが多い。^[108]strcatstrcpystrncatstrncpy

最も人気のある^{[a] の}代替はstrlcat^[111]とstrlcpy^[112]の関数で、1998 年 12 月にOpenBSD 2.4 で登場しました。 ^[108]これらの関数は常に 1 つの NUL を宛先バッファに書き込み、必要に応じて結果を切り捨て、必要なバッファのサイズを返します。これにより、切り捨てを検出し、切り捨てられない新しいバッファを作成するためのサイズを提供できます。長い間、これらの関数は、非効率であるという理由で、GNU C ライブラリ(Linux 上のソフトウェアで使用) には含まれていませんでした。 ^[113] C 文字列の使用を推奨する (より優れた代替形式の文字列の代わりに)、^{[114] [115]}その他の潜在的なエラーを隠すためです。^{[116] [117]} glibcがサポートを追加していなかった間も、strlcatとstrlcpyはOpenBSD、FreeBSD、NetBSD、Solaris、OS X、QNXなどの他のCライブラリ、および2008年に導入されたlibbsd ^[118]や2011年に導入されたmusl ^{[119] [120]}などのLinux用の代替Cライブラリを含む多くの他のCライブラリに実装されており、ソースコードはSDL、GLib、ffmpeg、rsyncなどの他のプロジェクトに直接追加され、 Linuxカーネル内部にも追加されました。これは2024年に変更されました。glibc FAQでは、glibc 2.38の時点でコードがコミットされ^[121]追加されたと記載されています。^[122]これらの関数はPOSIX.1-2024の一部として標準化されました。^[123] Austin Group Defect Tracker ID 986は、POSIXのこのような計画に関するいくつかの議論を追跡しました。

memcpy^[53]やmemmove^[55]が使用されることもありますstrcpy。これは、NUL を繰り返しチェックしないため、より効率的である可能性があるためです (これは最近のプロセッサでは当てはまりません)。これらはバッファ長をパラメータとして必要とするため、このパラメータを正しく設定することでバッファオーバーフローを回避できます。

2004セキュリティ開発ライフサイクルの一環として、マイクロソフトはstrcpy_s、およびstrcat_s（その他多数の）を含む「セキュア」関数群を導入しました。 ^[124]これらの関数は、ISO/IEC WDTR 24731 で提案されたオプションのC11（付録 K）の一部として、若干の変更を加えて標準化されました。 ^[125]これらの関数は、文字列がバッファに収まらないほど長すぎないかどうかなど、さまざまなチェックを実行します。チェックが失敗した場合、ユーザー指定の「ランタイム制約ハンドラー」関数が呼び出され、^[126]通常はプログラムが中止されます。^{[127] [128]}これらの関数は、当初 Windows のみに実装され、同時にMicrosoft Visual C++によって標準関数ではなくこれらの関数の使用を推奨する警告メッセージが生成され始めたため、かなりの批判を集めました。これは、マイクロソフトが開発者を自社のプラットフォームに閉じ込めようとする試みではないかと推測する人もいます。^[129]これらの関数の使用経験から、その採用と使用上の誤りに重大な問題があることがわかったため、C標準の次の改訂では附属書Kを削除することが提案されている。^[130]memset_sコンパイラの不要な最適化を回避する方法としての使用が提案されている。 ^{[131] [132]}

• C 構文 § 文字列 – バックスラッシュエスケープシーケンスを含むソースコード構文
• 文字列関数
• Perl 互換正規表現(PCRE)

Wikibook Cプログラミングには、Cプログラミング/文字列に関するページがあります。

• C 言語での高速 memcpy、さまざまな種類の CPU 命令アーキテクチャをターゲットとする複数の C コーディング例