SwiftでのUnicode正規化問題 続編：HFS+との整合性 - Qiita
前回の記事の続編です。 HFS+ における Modified NFD Apple が OS X でファイルシステムとして採用しているHFS+では，ファイル名を原則としてNFDで分解して保持するようになっています。 2種類の「が」は分解形で統一される たとえば，ユーザが が.txt（「が」はU+304Cの1文字）というファイル名でファイルを保存しても，ファイルシステム上は が.txt（「が」は U+304B U+3099 の合成文字）として保存されます。 実際，が.txt（「が」はU+304Cの1文字）としてファイルを保存した後，Finderでファイル名変更モードに入り，「が」という文字をコピーすると，U+304C ではなく，U+304B U+3099 という2文字がコピーされるのが確認できます。 → か(U+304B) + 結合用濁点(U+3099) がコピーされる CJK互換漢字を置き
Swiftでの文字列比較におけるUnicode正規化を巡る注意点 - Qiita
Stringの比較は正規化をかけた上で行われる Swiftの文字列比較は，Unicode正規化をかけた上で行われます。 たとえば，次の例をご覧ください。 let gaC = "\u{304C}" // 「が」の結合形 let gaD = "\u{304B}\u{3099}" // 「が」の分解形 // NSString としての文字数（UTF16での文字数）は異なる (gaC as NSString).length // => 1 (gaD as NSString).length // => 2 // String としての比較 gaC == gaD // => true (!!) これは，こちらのサイトによると， Depending on your requirements, this may or may not be what you want, but it is certainl
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
