NSString

Overview 概要

The NSString class and its mutable subclass, NSMutableString, provide an extensive set of APIs for working with strings, including methods for comparing, searching, and modifying strings. NSString objects are used throughout Foundation and other Cocoa frameworks, serving as the basis for all textual and linguistic functionality on the platform. NSStringクラスとそれの可変のサブクラス、NSMutableStringは、文字列の比較、検索、そして修正のためのメソッドを含む、豊富なAPI一式を文字列を扱うために提供します。NSStringオブジェクトは、Foundationおよび他のCocoaフレームワークの至る所で使われて、プラットホーム上の全てのテキストそして言語学的機能性に対する基礎として役立っています。

NSString is toll-free bridged with its Core Foundation counterpart, CFString. See Toll-Free Bridging for more information. さらなる情報のためにToll-Free Bridgingを見てください。

String Objects 文字列オブジェクト

An NSString object encodes a Unicode-compliant text string, represented as a sequence of UTF–16 code units. All lengths, character indexes, and ranges are expressed in terms of 16-bit platform-endian values, with index values starting at 0. NSStringオブジェクトは、一連のUTF–16コード単位として表される、ユニコード対応文字列をエンコードします。長さ、文字インデックス、そして範囲は全て、16ビットプラットホームエンディアン値の観点から表されて、0で始まるインデックス値を持ちます。

An NSString object can be initialized from or written to a C buffer, an NSData object, or the contents of an NSURL. It can also be encoded and decoded to and from ASCII, UTF–8, UTF–16, UTF–32, or any other string encoding represented by NSStringEncoding. NSStringオブジェクトは、Cバッファ、NSDataオブジェクト、またはNSURLの内容からの初期化またはそれへの書き出しが可能です。それはまた、ASCII、UTF–8、UTF–16、UTF–32、またはNSStringEncodingによって表現される何らかの他の文字列エンコーディングへとそしてそれからエンコードそしてデコードされることができます。

The objects you create using NSString and NSMutableString are referred to as string objects (or, when no confusion will result, merely as strings). The term C string refers to the standard char * type. あなたがNSStringおよびNSMutableStringを使って作成するオブジェクトは、文字列オブジェクトと呼ばれます（または、混乱が生じない場合、単に文字列として）。用語C文字列は、標準char *型を表します。

Because of the nature of class clusters, string objects aren’t actual instances of the NSString or NSMutableString classes but of one of their private subclasses. Although a string object’s class is private, its interface is public, as declared by these abstract superclasses, NSString and NSMutableString. The string classes adopt the NSCopying and NSMutableCopying protocols, making it convenient to convert a string of one type to the other. クラスクラスタの本質のために、文字列オブジェクトはNSStringまたはNSMutableStringクラスの実インスタンスではありません、しかしそれらのプライベートサブクラスの１つのものです。文字列オブジェクトのクラスがプライベートであるにもかかわらず、そのインターフェイスはパブリックです、それらの抽象スーパークラス、NSStringとNSMutableStringによって宣言されるように。文字列クラスは、NSCopyingとNSMutableCopyingプロトコルを採用して、一方の型の文字列を他方に変換するのを便利にしています。

Understanding Characters 文字を理解する

A string object presents itself as a sequence of UTF–16 code units. You can determine how many UTF-16 code units a string object contains with the length method and can retrieve a specific UTF-16 code unit with the character(at:) method. These two “primitive” methods provide basic access to a string object. 文字列オブジェクトは、それ自身を一連のUTF-16コード単位として表します。あなたは、どのくらい多くのUTF-16コード単位をある文字列が含むかlengthメソッドで判定できます、そして特定のUTF-16コード単位をcharacter(at:)メソッドで回収できます。それら２つの “プライベート” メソッドは、文字列オブジェクトへの基本的なアクセスを提供します。

Most use of strings, however, is at a higher level, with the strings being treated as single entities: You compare strings against one another, search them for substrings, combine them into new strings, and so on. If you need to access string objects character by character, you must understand the Unicode character encoding, specifically issues related to composed character sequences. For details see The Unicode Standard, Version 4.0 (The Unicode Consortium, Boston: Addison-Wesley, 2003, ISBN 0-321-18578-1) and the Unicode Consortium web site: http://www.unicode.org/. See also Characters and Grapheme Clusters in String Programming Guide. 文字列のほとんどの利用法は、しかしながら、より高い水準で、その文字列を単一の存在として扱うことです；あなたは、文字列を他のものと比較します、それらを下位文字列について検索します、それらを新しい文字列へと結合します、などなど。あなたが文字列オブジェクトに文字ごとにアクセスする必要があるならば、あなたはユニコード文字エンコーディングを理解しなければなりません、とくわけ合成文字列に関する問題を。詳細としてThe Unicode Standard, Version 4.0 (The Unicode Consortium, Boston: Addison-Wesley, 2003, ISBN 0-321-18578-1) とUnicode Consortium ウェブサイト: http://www.unicode.org/を見てください。またCharacters and Grapheme ClustersをString Programming Guideで見てください。

Localized string comparisons are based on the Unicode Collation Algorithm, as tailored for different languages by CLDR (Common Locale Data Repository). Both are projects of the Unicode Consortium. Unicode is a registered trademark of Unicode, Inc. ローカライズされた文字列の比較は、「ユニコード照合アルゴリズム」に基づきます、CLDR (Common Locale Data Repository) によって異なる言語に合わせられる通りに。両方ともユニコードコンソーシアムの企画です。Unicodeは、Unicode, Inc. の登録商標です。

Interpreting UTF-16-Encoded Data UTF-16エンコードされたデータを解釈する

When creating an NSString object from a UTF-16-encoded string (or a byte stream interpreted as UTF-16), if the byte order is not otherwise specified, NSString assumes that the UTF-16 characters are big-endian, unless there is a BOM (byte-order mark), in which case the BOM dictates the byte order. When creating an NSString object from an array of unichar values, the returned string is always native-endian, since the array always contains UTF–16 code units in native byte order. NSStringオブジェクトをUTF-16エンコードされた文字列（またはUTF-16と解釈されるバイトストリーム）から作成している時、もしバイト順がそれ以外では指定されないならば、NSStringはUTF-16文字がビッグエンディアンであると仮定します、BOM（バイト順マーク）が存在しない限り、その場合にはBOMがバイト順を指図します。NSStringオブジェクトをunichar値から作成している時、返される文字列は常にネイティブエンディアンです、配列は常にUTF–16コード単位を特定機種用バイト順で含むことから。

Subclassing Notes サブクラス作成の注意

It is possible to subclass NSString (and NSMutableString), but doing so requires providing storage facilities for the string (which is not inherited by subclasses) and implementing two primitive methods. The abstract NSString and NSMutableString classes are the public interface of a class cluster consisting mostly of private, concrete classes that create and return a string object appropriate for a given situation. Making your own concrete subclass of this cluster imposes certain requirements (discussed in Methods to Override). NSString（そしてNSMutableString）のサブクラスを作成することは可能です、しかしそうすることはストレージ設備を文字列に対して提供すること（それはサブクラスによって継承されません）そして２つの基本的メソッドを実装することを必要とします。抽象NSStringおよびNSMutableStringクラスは、大部分がプライベートな、具象クラスそれらから成るクラスクラスタのパブリックインターフェイスです、それは文字列オブジェクトをある与えられた状況に適切に作成して返します。このクラスタのあなた自身の具象サブクラスを作ることは、特定の要件を課します（メソッドのオーバーライドで議論されます）。

Make sure your reasons for subclassing NSString are valid. Instances of your subclass should represent a string and not something else. Thus the only attributes the subclass should have are the length of the character buffer it’s managing and access to individual characters in the buffer. Valid reasons for making a subclass of NSString include providing a different backing store (perhaps for better performance) or implementing some aspect of object behavior differently, such as memory management. If your purpose is to add non-essential attributes or metadata to your subclass of NSString, a better alternative would be object composition (see Alternatives to Subclassing). Cocoa already provides an example of this with the NSAttributedString class. NSStringのサブクラスを作るあなたの理由が妥当であることを確実にしてください。あなたのサブクラスのインスタンスは、文字列を表すべきです、何か他のものでなく。従ってサブクラスが持つべき唯一の属性は、それが管理している文字バッファの長さそしてバッファにおける個々の文字へのアクセスです。NSStringのサブクラスを作る妥当な理由は、異なるバッキングストアを提供すること（おそらくはより良い性能のために）またはオブジェクト挙動のある面、例えばメモリ管理などを異なって実装することを含みます。あなたの目的が本質的でない属性またはメタデータをあなたのNSStringのサブクラスに加えるならば、より良い代替はオブジェクト合成です（サブクラス作成の代わりとなるものを見てください）。Cocoaは、すでにこの例をNSAttributedStringクラスで提供します。

Methods to Override メソッドのオーバーライド

Any subclass of NSString must override the primitive instance methods length and character(at:). These methods must operate on the backing store that you provide for the characters of the string. For this backing store you can use a static array, a dynamically allocated buffer, a standard NSString object, or some other data type or mechanism. You may also choose to override, partially or fully, any other NSString method for which you want to provide an alternative implementation. For example, for better performance it is recommended that you override getCharacters(_:range:) and give it a faster implementation. これらメソッドは、あなたが文字列の文字それらに提供するバッキングストア上で演算を行わなければいけません。このバッキングストアに対してあなたは静的配列、動的にアロケートされたバッファ、標準NSStringオブジェクト、または何か他のデータ型や仕組みを使うことができます。あなたはまた、それに対してあなたが代替の実装を提供したい何か他のNSStringメソッドを、部分的にまたは完全に、オーバーライドするのを選ぶかもしれません。例えば、より良い性能のためにあなたがgetCharacters(_:range:)をオーバーライドしてそれにより高速な実装を与えることは推奨されます。

You might want to implement an initializer for your subclass that is suited to the backing store that the subclass is managing. The NSString class does not have a designated initializer, so your initializer need only invoke the init() method of super. The NSString class adopts the NSCopying, NSMutableCopying, and NSCoding protocols; if you want instances of your own custom subclass created from copying or coding, override the methods in these protocols. あなたは、あなたのサブクラスに対して、そのサブクラスを管理しているバッキングストアに適したイニシャライザを実装したいかもしれません。NSStringクラスは指定イニシャライザを持ちません、それであなたのイニシャライザはsuperのinit()メソッドの発動だけが必要です。NSStringクラスは、NSCopying、NSMutableCopying、そしてNSCodingプロトコルを採用します；あなたがコピーまたはコード化から作成する独自のあつらえのサブクラスのインスタンスを望むならば、それらプロトコルにおけるメソッドをオーバーライドしてください。

Alternatives to Subclassing サブクラス作成の代わりとなるもの

Often a better and easier alternative to making a subclass of NSString—or of any other abstract, public class of a class cluster, for that matter—is object composition. This is especially the case when your intent is to add to the subclass metadata or some other attribute that is not essential to a string object. In object composition, you would have an NSString object as one instance variable of your custom class (typically a subclass of NSObject) and one or more instance variables that store the metadata that you want for the custom object. Then just design your subclass interface to include accessor methods for the embedded string object and the metadata. しばしばNSStringの — またはさらに言うならあるクラスクラスタの何か他の抽象的で、パブリックなクラスの — サブクラスを作ることのより良いそしてより簡単な代替は、オブジェクト合成です。これは、とりわけあなたの意図がサブクラスに加えて、文字列オブジェクトにとって本質的でないメタデータまたは他の属性である場合にそうです。オブジェクト合成では、あなたはあるNSStringオブジェクトをあなたのあつらえのクラス（概してNSObjectのサブクラス）の１つのインスタンス変数として、そしてあなたがあつらえのオブジェクトに望むメタデータを格納する１つ以上のインスタンス変数を持つでしょう。それから単にあなたのサブクラスインターフェイスを設計して、アクセッサメソッドをその埋め込まれた文字列オブジェクトとそのメタデータのために含めます。

If the behavior you want to add supplements that of the existing class, you could write a category on NSString. Keep in mind, however, that this category will be in effect for all instances of NSString that you use, and this might have unintended consequences. あなたが加えたい挙動が既存のクラスのそれを補うならば、あなたはあるカテゴリをNSString上で書くことができます。しかしながら、心に留めておいてください、このカテゴリはあなたが使うNSStringの全てのインスタンスに影響を及ぼします、そしてこれは予想もしない成り行きになるかもしれません。