articles of samekard

前回Swift2.0のStringの仕様を調べたが、編集系(append, insert, remove, replace)のメソッドの仕様は整理しきれていない、というくやしい終わり方をした。 Swift 2.0でStringはどうなったか - 特殊文字などの扱い 今回はまず、この編集系メソッドから見ていく。 編集系メソッドの引数に与えるものは主にCharacterとStringであるが 、そのほかにCharacterを要素にもつシーケンスというものがある。これは、名前がSとして <S : Sequence where S.Iterator.Element == Character> という性質を持つ。ここではこれを「Characterシーケンス」ということにする。 append(連結)系 Swift2.0ではメソッド名がバラバラだったものが、めでたくappendに統一された。 CharacterやStringの場合は引数ラベルなしで与える。 Characterシーケンスの場合はラベルにcontentOfが付けられる。 mutating func append(_ c: Character) mutating func append(_ other: String) mutating func append<S : Sequence where S.Iterator.Element == Character>(contentsOf newElements: S) このほかに土台のStringに変更を加えないで、与えられたものを追加したStringを返すメソッドがある。 func appending(_ aString: String) -> String これは土台のStringが変更されないので、mutatingが付けられていない。他の編集系メソッドにも語尾がingでこの性質のメソッドがある。 insert(挿入)系 これも名前がinsertに統一された。 appendと同じようにCharacterシーケンスの場合はラベルにcontentOfが付けられる。 Stringを受けるものはない？ mutating func insert(_ newElement: Character, at i: Stri...

Objective-CのNSStringの仕様は自然ではなかったので、Swiftには期待しています。 Swift2.0でStringの仕様がだいぶ変わったということで検証してみます。 昔は何が困ったか 今回のStringの仕様の検証は、昔の仕様で困っていた部分が動機になっているので、まずそれを書きます。NSStringでは文字を基本的に16ビットで扱っていますが、文字の中には16ビットで扱えないものがあり、そういうものは32ビットなど他の長さで使用します。そのごちゃごちゃはUnicodeの仕様上仕方ないのですが、NSStringではその32ビット文字を2文字としてカウントするなどUnicodeのごちゃごちゃをうまくさばききれていなくて扱いが雑な部分がありました。 欲しいものは、内部で何ビットだろうとどういうどういうデータ状態であろうと、人間が一文字と認識するものは一文字として扱うというポリシーに従ったAPIです。 Swiftが発表になったときにUnicodeとの親和性もアピールしていたので期待しています。 The Swift Programming Languageを読む まずはいつものThe Swift Programming Languageで基本をおさらい。 ・Stringはvalue typeである(reference typeではない)。 ・Stringの文字列に含まれている個々の文字へのアクセスにはStringのcharactersプロパティからアクセス出来る。 ・SwiftのStringは内部ではUnicode scalarをベースにしている。Unicode scalarとは文字や記号に対応する21ビットの数。U+0000からU+D7FFとU+E000からU+10FFFFがある。U+D800からU+DFFFは含まない。U+が何かというのは大変ややこしいので割愛。 ・人間が文字と認識する形式がExtended Grapheme Cluster。SwiftのCharacterは一つのExtended Grapheme Clusterに対応。 一つのExtended Grapheme Clusterは一つ以上のUnicode scalarで構成される 。 ・Stringの文字数カウントはcharactersプロパティのcountプロ...

参考記事 Over&Out その後 UIFontのfontName一覧 これのiOS8版を行います。 ""が付いているものと付いていないものがありますが、どちらも指定できます。 使用例 [UIFont fontWithName:@"Courier" size:512]; family:Marion ( "Marion-Italic", "Marion-Bold", "Marion-Regular" ) family:Copperplate ( "Copperplate-Light", Copperplate, "Copperplate-Bold" ) family:Heiti SC ( "STHeitiSC-Medium", "STHeitiSC-Light" ) family:Iowan Old Style ( "IowanOldStyle-Italic", "IowanOldStyle-Roman", "IowanOldStyle-BoldItalic", "IowanOldStyle-Bold" ) family:Courier New ( "CourierNewPS-BoldMT", "CourierNewPS-ItalicMT", CourierNewPSMT, "CourierNewPS-BoldItalicMT" ) family:Apple SD Gothic Neo ( "AppleSDGothicNeo-Bold", "AppleSDGothicNeo-Thin", "AppleSDGothicNeo-UltraLight", "AppleSDGothicNeo-Regular...

NSStringについてのいろいろ。 記事を書いた時のiOSバージョンはiOS6.1.3です。 初期化時の複数バイトエンコーディングの扱い - (id)initWithCString:(const char *)nullTerminatedCString encoding:(NSStringEncoding)encoding; は引数にencodingがあるが、複数バイトエンコーディングのものを指定すると、全て0となっているバイトで文字列末端とみなされるようだ。 例えば2バイトで 00000000 10101010 と表される文字があるとすると00000000のバイトを文字列末端とみなすらしい。 長い文字列のはずが、いきなり初めのほうで文字列が終わってしまう。 + (id)stringWithCString:(const char *)cString encoding:(NSStringEncoding)enc も同様。 上位８ビットが0の時だけでなく下位8ビットが0の時でも末端と見るようだ。 おそらく 8ビット毎に取り出して char selectedChar = 取り出し関数(); if(selectedChar == 0){ 末端処理 }else{ switch(エンコード)｛ 各エンコード別の処理 ｝ } のような処理だ。 そもそも8ビットの0を内部に含むエンコーディングはC言語文字列の定義から外れるという考え方なんだろう。 対策は – initWithBytes:length:encoding:(これはどのエンコードでもいけそう) - initWithCharacters:length:(UTF-16限定？) + stringWithCharacters:length:(UTF-16限定？) などを使う。 第３水準、第４水準の漢字に対応しているか まず、漢字の分類方法なのだが、第１、第２、第３、第４とあり、数字が大きいほうに使用頻度の低い漢字が割り当てられている。 第４水準の初めの文字は「毎」のカンムリだけを取り出したようなもの。読み方はわからず。このブログでは表示出来ない。 で、この漢字をiOSで扱えるのか？ Unicodeに含まれていれば対応しているんではないか？と思うかもしれ...

Unicodeで日本語が該当する箇所 Unicodeの中で日本語が該当する所を調べてみました。 漢字は基本的に、日本語で使われるか中国語で使われるかは区別されません。ですからこれらの範囲の中には中国でしか使われない漢字も含まれています。 ここでは割り当てられている領域を書いています。実際に文字が割り当てられている範囲が書かれている資料とは終わりの値が若干異なることがあります。 ひらがなU+3040～U+309F(ひらがな文字は U+3041～U+3096) カタカナU+30A0～U+30FF(カタカナ文字はU+30A1～U+30FA) 「CJK統合漢字」U+4E00～U+9FFFに、約20,000字 「CJK統合漢字拡張A」U+3400～U+4DBFに、6,500字強 「CJK統合漢字拡張B」U+20000～U+2A6DFに、約42,000字 「CJK統合漢字拡張C」U+2A700～U+2B73F(2009年10月制定のUnicode5.2.0) 「CJK統合漢字拡張D」U+2B740～U+2B81F(2010年10月制定のUnicode6.0) また、一覧の中から私が目視で日本語ぽいと判断したものに U+2E80-2EFF CJK部首補助 U+2F00-2FDF 康熙部首 U+3000-303F CJKの記号及び句読点 U+31F0-31FF 片仮名拡張 U+3200-32FF　囲みCJK文字・月 U+3300-33FF CJK互換用文字 U+FE30-FE4F CJK互換形（たてがき？） U+FE50-FE6F小字形（たてがき？） U+FF00-FFEF半角・全角形 があります。 漢字ではこれらの「CJK統合漢字」や「CJK統合漢字拡張A～D」とは別に、 U+F900～U+FAFFとU+2F800～U+2FA1Fに「互換漢字」 U+E0100〜U+E01EFにIVS用のバリエーション符号 があります。 Objective-CでのUnicode文字列の扱い iOSの文字列の文字コードはUnicodeです。Unicodeには表現方法がいくつかあって、おそらく、UTF-16という方法を用いていると思います。(はっきりした資料が見当たらず予想という前程) このUTF-16はほとんどの文字を2バイトで表現...