Objective-C : NSString

文字コード

NSStringは、UnicodeのUTF16実装のラッパークラスである。NSStringクラスに、文字コード変換のためのメソッドが用意されている。

改行コード

NSStringの改行コードは酷く混乱している。

文字データのフォーマットがUnicodeであることから、NSStringには下記の5種類の改行コードを使用することが認められている。

• Carridge Return (CR)
• Line Feed (LF)
• Carridge Return & Line Feed (CR-LF)
• Unicode Line Separator (LS)
• Unicode Paragraph Separator (PS)

複数の改行コードに対応しているのはいいが、問題はこれらのコードがひとつのNSStringインスタンスに共存可能だということだ。

例えば、改行文字がCR-LFで記述されたテキストファイルをNSTextViewに読み込ませた場合、NSTextView所属のNSString(の派生クラス)の改行文字はCR-LFになる。この状態で、ユーザがリターンキーを押してTextViewに改行を入力すると、その改行はCRになる。また、任意のテキストをコピーしてTextViewに挿入すると、その部分だけは改行がLFになる。

調べてみると、改行コードはMacOSX上でかなり特殊な扱いを受けているようだ。簡単に纏めると下記のようになる。

• ユーザが直接入力する改行は「CR」
• クリップボード(ペーストボード)を介して入力する改行は「LF」
• ファイルからNSStringに読み込まれる改行コードは「元のまま」

元々、MacOSの改行文字は9.xまでCRで統一されていた。しかしBSDベースとなったMacOS Xでは、Unixの世界で標準的なLFを使用しなければならない。そこで、こういった複雑(怪奇)な対応を取ったものと思われる。

一般ユーザとして一番問題になるのは、MacOS X上で作成したテキストファイルに複数の改行コードが入り乱れてしまうことだろう。MacOS X上で新規に作成したテキストには、否応なくCRとLFが混合される。このテキストファイルは、Windowsでも、Unixでも、或いは旧MacOSでも正常に表示/編集することができない。また、MacOS X上でもスクリプトなどUnix系の用途では問題を生じることになる。

普通、改行コードはその環境に1種類しかない。Windows/DOSならCR-LF、Unix系ならLF、旧MacOSならCRといった具合だ。従って、改行コードの自動判別機能を持つテキストエディタも、ほとんどが「最初に出現する」改行文字でテキスト全体の改行コードを判定する。つまり、複数の改行コードが混在するMacOS X方式は非常にまずいと思うのだが…

開発者としても、これは混乱の元になる。改行コードの扱いはほとんど解説がなく、新規に保存する際のガイドラインもない。NSTextViewは、コードから改行を挿入すると既存の改行文字との絡みで表示が崩れることがある。

拙作のKEditでは、テキスト読み込み時に全ての改行をLFに変換し、ユーザによる入力も逐次LFに変換して対処している。方法については別記する予定である。