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
「Common Lisp で日本語処理」のシリーズをはじめます : セマンティックウェブ・ダイアリー
Common Lisp で日本語処理ができないということはありません．ただ Common Lisp の規格には多言語処理が含まれていないこと，また，マシンが決まれば処理系が事実上一つしかない Perl や Python と異なって数多くある Common Lisp 処理系から日本語処理に適したものを選ばなければならないということがあります．それは日本語処理機能がベンダーや処理系によってちょっとづつ異なるからです． 日本語処理のためのコードとしては，unicode とすることに異論はないでしょう．すでにほとんどの Linux と Common Lisp 処理系は unicode を前提としています．そしてセマンティックウェブの世界でもunicodeが文字コードの条件になっています． Common Lisp の日本語処理については，「実践Common Lisp」の付録に訳者らによって書かれたも
Camomile : A Unicode library for OCaml
This document summarizes Camomile, a Unicode library for OCaml. It provides a Unicode character type, supports UTF-8, UTF-16 and UTF-32 encodings, and allows conversion between 200+ encodings. It also supports case mapping, collation, and Unicode normal forms to handle equivalent string representations. The library uses functors and lazy evaluation. Modules provide Unicode normalization and canoni
本の虫: ㄘんㄘん
常の如くGoogleReaderを見ていた所、不思議な文字列が目に入った。曰く、「ㄘんㄘん」と。 ちんちんがどうした。下品なことの好まるるは、世の常ではないか。いまさら目くじらを立てるには及ばぬ、という人もいるだろう。しかし、問題はそこではない。よく見て欲しい。 ㄘんㄘん ちんちん 何と見た目が違うではないか。これは一体どういうことだろう。フォントを変えているのか？ しかし、こんなフォントをインストールした覚えはない。WOFF(Web Open Font Format)という、web上でフォントを提供する規格が制定されつつあると聞く、しかし、私はFirefoxを使っていないし、第一、その様な最先端の規格を使っているようにも見えない。あるいは、CSSでウエイトや傾きを変えているのか？ そうではない。これは、実は、違う文字なのだ。 ㄘ 'BOPOMOFO LETTER C' (U+3118)
Text Encodings in VFS
Q: Mac OS X 用にファイルシステム（VFS）プラグインを書いています。テキストコードを正しく処理するにはどうすればよいでしょうか？ A: Mac OS X では、VFS API のファイル名は、定義上、正規分解による Unicode 文字で、UTF-8 を使ってエンコードされています。このことが、いくつかの興味深い問題を引き起こしています。 合成済み文字と分解された文字 この Q&A は、「合成済み Unicode 文字」および「分解された Unicode 文字」という用語を熟知していることを前提としています。これらの用語をよく知らない場合は、DTS Q&A 1235 Converting to Precomposed Unicode（合成済み Unicode への変換）に簡単な説明が掲載されています。 重要： この Q&A で使われている「分解された」および「合成済み
Converting to Precomposed Unicode
Q: Unicode 文字列を合成済みの文字の形式に変換する方法はありますか？ A: Mac OS X 10.2 で導入された API を使用して、文字列を合成済みの Unicode に変換できます。以下に、合成済みの Unicode と分解された Unicode の違い、なぜ合成済みの Unicode に変換する必要があるのか、および変換方法について説明します。 合成済みの文字と分解された文字 特定の Unicode 文字は、複数の方法でエンコードできます。たとえば、Á（A アキュート）は、U+00C1 (LATIN CAPITAL LETTER A WITH ACUTE) のような合成済みの文字、または U+0041 U+0301（LATIN CAPITAL LETTER A に続く COMBINING ACUTE ACCENT）のような分解された文字のいずれかをエンコードできます。W
ウノウラボ Unoh Labs: Mac OS X上のUnicode
Firefoxは内部的に変換処理を行うようになっているようです。 問題はSafariとOperaですね。 選択されたファイルのパスからJavaScriptで ファイル名を抜き出してタイトルに設定する部分で、 正しく扱えるような文字コードに変換することにしたいと思います。 基本的な流れとしては、UTF-8-MAC特有の「U+3099」（COMBINING KATAKANA-HIRAGANA VOICED SOUND MARK）、 「U+309A」（COMBINING KATAKANA-HIRAGANA SEMI-VOICED SOUND MARK）がファイル名に含まれている場合は、 その前の文字と結合して濁音・半濁音の文字にしてあげればいいでしょう （ひらがな・カタカナのみの暫定的な対処に過ぎませんが）。 変換用の文字テーブルを用意して、逐一変換していくかたちにしたいと思います。 というわけ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CamomileでUnicode