ヌル終端文字列
ヌル終端文字列では、文字配列中において値が0の要素が番兵として使われるため、値が0となる文字を含まないエンコード方式が必要である。1バイト単位でエンコードする場合は、値が0となるバイトを含んではいけない。
ASCIIでは0x00を、UnicodeではU+0000をヌル文字NULとして定義しているため、ヌル終端文字列にヌル文字をそのまま含むことはできない。そこで、ヌル文字を含まない、あるいはヌル文字を別の文字または文字シーケンスで代替した、ASCIIやUnicodeのサブセットを使用することがある。いくつかのシステムではUTF-8の代わりに「修正UTF-8」(Modified UTF-8) を使用している。これは、ヌル文字を2つの0でないバイト (0xC0, 0x80) で表現し、ヌル終端文字列に格納できるようにしたものである。これはセキュリティ上のリスクがあるため標準のUTF-8の規格外である。C0 80 NUL はセキュリティ確認では文字列終端として、実際の使用時は文字としてみなされるかもしれない。
C文字列の処理における誤りを減らすために、多くの試みがなされた。その一つの方法が、標準Cライブラリでgetsやstrcpyのような危険な関数を廃止するために導入された、より安全で使いやすいgets_sやstrlcpy/strcpy_s、strdupなどの関数の追加である。他に、安全な呼び出ししか行われないように、C文字列にオブジェクト指向のラッパーを追加する方法もある。
最新のシステムではメモリの使用は懸念がより少ないので、多バイトの文字列長も許容された。文字列長の保持のために使用される領域によるメモリオーバーヘッドが懸念されるような、多くの小さな文字列が多数ある場合でも、ハッシュテーブルを使用することでより少ないメモリで管理できるようになっている。C文字列の後継は、文字列長を格納するための32ビットあるいはそれ以上のサイズの値フィールドを持っている。例えばC++のStandard Template Library (STL) のstd::string、QtのQString、Active Template Library/Microsoft Foundation Class (ATL/MFC) のCString、Core FoundationのCFString、Foundation Kit(英語版)のNSStringなどである。このような、文字列を格納するためのより複雑な構造を、string(ひも)に対してrope(ロープ(英語版))と言う。