ヌル終端文字列

コンピュータプログラミングにおいて、ヌル終端文字列は、文字を含む配列として格納され、ヌル文字（内部値がゼロの文字、この記事では「NUL」と呼びますが、グリフのゼロとは異なります）で終了する文字列です。別名は、 Cプログラミング言語を指すC文字列と、ASCIIZ ^{[1]です（ただし、Cは}ASCII以外のエンコードを使用することもできます）。

文字列の長さは、(最初の) NUL を検索することによって見つけられます。これは、文字列の長さに対して O( n ) (線形時間) かかるため、遅くなる可能性があります。また、文字列に NUL を含めることはできません (メモリ内に NUL はありますが、文字列内ではなく最後の文字の後にあります)。

ヌル終端文字列は、PDP-11アセンブリ言語.ASCIZのディレクティブと、PDP-10用のMACRO-10マクロ アセンブリ言語のディレクティブによって生成されました。これらは C プログラミング言語の開発より前のものですが、他の形式の文字列がよく使用されていました。 ASCIZ

C (およびそれが派生した言語) が開発された当時、メモリは極めて限られていたため、文字列の長さを格納するために 1 バイトのオーバーヘッドのみを使用するのは魅力的でした。当時、一般的に「Pascal 文字列」(より現代的な用語では「長さプレフィックス」) と呼ばれていた唯一の一般的な代替手段は、先頭のバイトを使用して文字列の長さを格納するものでした。これにより、文字列に NUL を含めることができ、長さの検出には 1 回のメモリ アクセス (O(1) (定数) 時間) のみが必要になりましたが、文字列の長さは 255 文字に制限されていました。C の設計者Dennis Ritchie は、文字列の長さの制限を回避するために、また、経験上、カウントを維持することはターミネータを使用するよりも不便であるように思われたため、ヌル終端の慣例に従うことを選択しました。^{[2] [3]}

これはCPUの命令セット設計にいくらか影響を与えた。1970年代と1980年代のCPUの中には、Zilog Z80やDEC VAXなど、長さプレフィックス付き文字列を処理するための専用命令を備えたものもあった。しかし、ヌル終端文字列が普及するにつれて、CPU設計者はそれを考慮に入れるようになり、例えばIBMは1992年にES/9000 520に「論理文字列アシスト」命令を追加し、 2015年にはIBM z13にベクトル文字列命令を追加した。 ^[4]

FreeBSD開発者のPoul-Henning Kampは、 ACM Queueに寄稿し、2バイト（1バイトではない）の長さよりもヌル終端文字列が勝利したことを「これまでで最も高価な1バイトの間違い」と呼んだ。^[5]

この表現は実装が簡単ですが、エラーやパフォーマンスの問題が発生しやすい傾向があります。

歴史的に、ヌル終端はセキュリティ上の問題を引き起こしてきました。^[6]文字列の途中に挿入されたヌル文字は、予期せず文字列を切り捨てます。^[7]よくあるバグは、ヌル文字用の追加スペースを割り当てないことで、隣接するメモリに書き込まれました。もう 1 つは、ヌル文字をまったく書き込まないことでしたが、メモリ ブロックにすでにゼロが含まれていたため、テスト中に検出されないことが多かったです。長さを見つけるコストが高いため、多くのプログラムでは、文字列を固定サイズのバッファにコピーする前に手間をかけず、長すぎるとバッファ オーバーフローを引き起こしていました。

ゼロを保存できないため、テキスト データとバイナリ データを区別し、別の関数で処理する必要があります (バイナリ データの場合は、データの長さも指定する必要があります)。これにより、間違った関数を使用すると、コードの冗長性やエラーが発生する可能性があります。

長さを見つける際の速度の問題は、通常、 などのO( n ) である別の操作と組み合わせることで軽減できます。ただし、これによって必ずしも直感的なAPIstrlcpyが実現されるわけではありません。

ヌル終端文字列では、エンコードがどこにもゼロバイト (0x00) を使用しないことが必要であるため、ASCIIまたはUTF-8文字列のすべてを格納できるわけではありません。^{[8] [9] [10]}ただし、ASCII または UTF-8 のサブセット (NUL 以外のすべての文字) をヌル終端文字列に格納するのは一般的です。一部のシステムでは、NUL を 2 つの非ゼロバイト (0xC0、0x80) としてエンコードする「修正 UTF-8 」を使用しており、すべての文字列を格納できます。これは長すぎるエンコードであり、セキュリティ上のリスクと見なされるため、UTF-8 標準では許可されていません。代わりに、UTF-8 では使用されていない 0xFE や 0xFF などの他のバイトを文字列の末尾として使用する場合があります。

UTF-16 は2 バイトの整数を使用し、いずれかのバイトがゼロになる可能性があるため (実際、 ASCII テキストを表す場合は他のすべてのバイトがゼロになります)、ヌル終端バイト文字列に格納することはできません。ただし、一部の言語では、16 ビットのNUL (0x0000) で終了する 16 ビットUTF-16文字の文字列を実装しています。

C 文字列処理のエラーを少なくするための多くの試みがなされてきました。 1 つの戦略は、strdupやなどのより安全な関数を追加しstrlcpy、などの安全でない関数の使用を非推奨にする getsことです。 もう 1 つは、安全な呼び出しのみが行えるように、C 文字列にオブジェクト指向のラッパーを追加することです。 ただし、安全でない関数をとにかく呼び出すことは可能です。

最近のライブラリの多くは、C 文字列を 32 ビット以上の長さの値 (長さプレフィックス付き文字列で考慮されていたものよりはるかに大きい) を含む構造体に置き換え、別のポインタ、参照カウント、さらには NUL を追加して、C 文字列への変換を高速化しています。メモリは現在でははるかに大きくなっているため、各文字列に 3 (または 16、あるいはそれ以上) バイトを追加することが実際に問題になる場合は、ソフトウェアが多数の小さな文字列を処理する必要があるため、他の保存方法でさらに多くのメモリを節約できます (たとえば、重複が非常に多い場合は、ハッシュ テーブルの方がメモリを節約できます)。例としては、C++ 標準テンプレート ライブラリ std::string、Qt QString、MFC CString、Core FoundationCFStringのC ベースの実装、 FoundationのObjective-C の兄弟などがあり、どちらも Apple 製です。ロープなどの文字列を格納するために、より複雑な構造体を使用することもできます。 NSString

• 空の文字列
• センチネル値