絵文字を扱う上で知っておくと良いかもしれないことをまとめてみました。 Ruiさんの記事を見て、「EmojiはSurrogate Pair以外にも、色々とおもしろい技術があるんですよ〜」思って書いてみました。 なお、書いた人はAndroidの人間なので、特に表記していない場合は主にAndroid上での動作のことを書いてます。 またQiita初めてなので読みにくい部分等がありましてもご容赦ください。 サロゲートペア(Surrogate Pairs) このエントリーを書くきっかけにもなったサロゲートペア。なぜこれが導入されたかの経緯は、Ruiさんのブログエントリーに譲るとして、技術的な解説をします。 サロゲートペアは、U+0000..U+FFFFに収まりきらなかった範囲のUnicodeコードポイント(U+10000..U+10FFFF)を、なんとか16bitでエンコードしようとして導入されました
UnicodeのUTF-16エンコーディングではほとんどの文字（コードポイント）は2バイトで表現されるが、Unicodeに後から追加収録された文字の多くは4バイトで表現される。4バイト文字がうまく扱えないプログラムというのはわりとよくある。しかし世界中で広く使われるようになった絵文字がよりによって4バイト文字であるせいで、そのような文字が扱えない問題がよいペースで解決に向かいつつある。それについて少し説明してみようと思う。 Unicodeが80年代から90年代初頭にかけてデザインされたときの目標の一つは、Unicodeに含まれる文字数を65536個以内に収めることだった。現代の文章を実用的なレベルで表すためには、漢字などを含めてもそれだけの種類の文字があれば十分だと考えられたのだ。当然これは1文字を2バイトで表すことを念頭に置いていた。つまりコンピュータの揺籃期から当時に至るまで単純に英語
let w = "\u{65}\u{301}" // "é" == e + アクセントマーク let wcv = w.characters let wcv_endIndex = wcv.endIndex // 2 let wcv_a = Array(wcv) // ["é"] let wcv_a_endIndex = wcv_a.endIndex // 1 let wcv_c0 = wcv[wcv.index(wcv.startIndex, offsetBy: 0)] // "é" let wcv_c1 = wcv[wcv.index(wcv.startIndex, offsetBy: 1)] // fatal error: Can't form a Character from an empty String
世の中がほぼUnicode前提になってめでたしめでたし。とはいかなかった現実の話。 String型でできる文字列処理とか、ソースコード自体、特に識別子で使える文字とか。 軽くおさらい: Unicode まあいろんなところでいろんな人が書いてると思うのでさらっと概要だけ。 Unicodeは、元々、「65,536文字あれば十分だろ」とかいう幻想の元、2バイト固定長の文字コードとして作られていました。 もちろん足りなくて、ビット数を拡張。基本が2バイトのままでこの拡張した分を取り扱えるようにしたのが今のUTF-16で、拡張分は2文字分(4バイト)を使って表現。 この、2文字分使って1文字を表すやつのことをサロゲートペア(surrogate pair: 代理対)と呼びます。 あと、ASCII文字も2バイトになるのを欧米人が嫌って、ASCII文字はASCIIコードのまま、逆に漢字・ひらがな・カタカナ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? これは Swift Tweets の発表をまとめたものです。イベントのスポンサーとして Qiita に許可をいただいた上で、このような形（ツイートの引用）で投稿しています。 以下の内容は熟考した上での自分なりの見解でありますが、公式に記載されていないものが多く含まれています。もし誤りなど見つけたら指摘していただけると助かります。 それでは、「SwiftのString(文字列) APIとの付き合い方」の発表を始めます。 https://swift-tweets.github.io の発表概要に記載した通り、そこに挙げている3つの記事は理解
ユニコード（Unicode）です。ユニコードは文字コードの規格の1つで、使うOSなどに依存しない文字を提供出来るのが特長です。Swiftの文字列型で使用されているユニコード方式は、UTF-8、UTF-16、それとユニコードスカラー（UTF-ユニコード（Unicode）です。ユニコードは文字コードの規格の1つで、使うOSなどに依存しない文字を提供出来るのが特長です。Swiftの文字列型で使用されているユニコード方式は、UTF-8、UTF-16、それとユニコードスカラー（UTF-32）です。このページで詳しく見ていきますが、実は Character 型はユニコードスカラーが1つまたは複数集まった表現です。 ここではユニコードとは何か？から始めて、ユニコードスカラーと文字列リテラル中の特殊文字について簡単に説明し、拡張書記素クラスタ（extended grapheme cluster）を紹介しま
let message = "He said, \"I\'m going to be a king of pirates!\"" let atmark = "\u{40}" // @ let heart = "\u{2665}" // ♥︎ 文字列の操作 空文字 空文字は以下のようにして定義できます。 var name1 = "" var anme2 = String() また、空文字かどうかは、isEmptyプロパティで判定できます。 if name1.isEmpty { print("名前はまだない") } 長さを調べる 文字列の長さは、countElements関数で調べることができます。 var text = "Swiftの学習" print(countElements(text)) // 8 連結 文字列を連結するには、+または、+=演算子を使います。 let prefix =
はじめに Objective-C時代から絵文字の判定方法には 絵文字の文字コードを全部メモリーに持っておいて照合する という泥臭い方法を採っていたのですが、iOSのバージョンアップに伴う絵文字の追加に追従するのが面倒くさいので、もう少しスマートに判定できないか考えてみました。 2016/12/16 Xcode8.2 + iOS 10.2 頂いたコメント等を元に再編 考えたもの 仕組みは簡単、CoreTextを使ってAppleColorEmojiフォントに対し、文字コードを渡し、グリフ値（フォントの文字のインデックス値）へ変換できたら絵文字とみなす、というものです。 ただ、AppleColorEmojiフォントは何故か0,1,2,3...と言った文字のグリフも持っているため、その辺りだけ例外的に除外してあげる必要があります。 （スクショはmacのフォントですが） また、String.Char
Swift言語 では「文字」として抽象的に扱っているのでしょう。 Objective-C言語 では文字列を内部ではUTF16 の数値で扱うようになっていて、unichar型 ですぐに文字コードを扱えるようになっていましたが、よく考えると、文字コードが決まらないと文字をコードで扱えないのは自然な設計です。 文字を文字コードで取得する String型 の文字を文字コード で扱うためには、上記の方法を使って扱いたい文字コードのデータセットを取得して、それを扱う必要があります。 文字を Unicode 文字コードで取得する 文字をそのまま扱うという観点では Unicode がいちばん単純かもしれません。 Unicode は多国語対応の文字セットですが、文字を基本的に 2 バイトのコード (UCS-2 ) で扱います。ただ、世界中の文字を 2 バイトで扱うことができないため、一部 4 バイトのコード
Intro textarea などに入力された文字数を、JS で数えたい場合がある。 ここで .length を数えるだけではダメな理由は、文字コードや JS の内部表現の話を理解する必要がある。 多言語や絵文字対応なども踏まえた上で、どう処理するべきなのか。 それ自体は枯れた話題ではあるが、近年 ECMAScript に追加された機能などを交えて解説する。 なお、文字コードの仕組みを詳解すること自体が目的では無いため、BOM, UCS-2, Endian, 歴史的経緯など、この手の話題につき物な話の一部は省くこととする。 1 文字とは何か Unicode は全ての文字に ID を振ることを目的としている。 例えば 😭 (loudly crying face) なら 0x1F62D だ。 1 つの文字に 1 つの ID が割り当てられているのだから、文字の数を数える場合は、この ID の
(訳注：記事をご覧の環境によって文字列が正しく表示されない場合がございます。) 投稿が遅れたFriday Q&Aにようこそ。Swiftユーザの最大の不満の一つに、 String APIがあります。Swiftの文字列APIは難しく鈍いため、多くのユーザが他言語の文字列APIのようであればと感じているのではないでしょうか。今日はなぜSwiftの String APIがこのように設計されているのか（少なくとも私がなぜそう設計されていると思うのか）を説明します。そして、基本的設計の観点から見て、なぜこれが最高の文字列APIなのかを説明します。 文字列とは何か 説明に入る前に、まず基本的な概念を構築しましょう。文字列について、漠然とは理解しているものの、あまり深くは考えないものなのではないでしょうか。文字列をじっくり考えることで、どのようなことが起きているのか理解することができます。 概念としての文
9. 参考) 確かめかた (Windows の場合) • 確かめたい文字をコピーします。 • WordPad を起動し、コピーした文字を貼り付けます。 • 確かめたい文字を一文字選択し、ALT + X を押します。 • コード (UCS-4) が表示されます。 • U+301C が波ダッシュ • U+FF5E が全角チルダ 10. 基礎知識1) チルダとは何か？ • こういうやつらしい。 ÃÕÑ • 鼻音に関する音をあらわす、ダイアクリティカルマークの一種 • ダイアクリティカルマークってこんなやつら (よくしらない) À Á Â Ä Å Ă Ą Ā http://ja.wikipedia.org/wiki/%E3%83%80%E3%82%A4%E3%82%A2%E3%82%AF%E3%83%AA%E3%83 %86%E3%82%A3%E3%82%AB%E3%83%AB%E3%83%9E%
XMLやCSV等のデータをJavaで色々加工して出力したりといったことをしてると必ずハマるのが波線などの文字化け問題です。 文字化けが発覚するたびにググって場当たり的な対処を繰り返すのに疲れたのでよく問題になる文字と形が似た文字をリストアップして、更にそれをJavaで各種エンコーディングに変換したらどの文字になるかを頑張って纏めました。 ついでに文字化けしないよう上手いこと出力可能な文字に置換する関数も作ってみました。 Javaの変換テーブル 表中の U,S,W,E,J はそれぞれ、UTF-8、Shift_JIS、Windows-31J、EUC-JP、ISO-2022-JP で出力した際の文字です。 見た目で分からないくらい似た文字ばかりなので、各セルにマウスカーソルを乗せたらツールチップで確認できるようtitleにコードポイントを書いておきました。 分かりやすいよう、青は文字化けなし、黄
入力「×」のブラウザでは、「𠮷」が2文字とみなされるため、2文字目まで、つまり「𠮷野」までしか入力できません。 Mozillaの文書には、Unicode code pointsで数えると書いてあるので、そのうち改善されるのかもしれませんが、現時点ではTwitterのために「maxlength="140"」を使うことはできません。 pattern属性 Firefox 21とChrome 27、IE 10、Opera 12.15は、「pattern=".{0,3}"」（任意の文字からなる0から3文字）のような正規表現を使った検証にも対応していますが、やはり「𠮷野家」は4文字とみなされてしまいます。 JavaScript 追記：javascript – でBMP以外のUnicode文字をきちんと扱う（404 Blog Not Found） JavaScriptでは、文字列strの長さをst
この記事は「東京 Node 学園祭 2012 アドベントカレンダー」の 15 日目の記事です。 id:jovi0608 によるこのアドカレ 13日目のエントリ「Node API のクラス図を公開しました。」でも明らかなように、Node の重要なコンセプトの一つがストリームです。ストリームについては id:Jxck による東京 Node 学園の発表資料 「Node Academy 7 | ”Stream Stream Stream !!!”」も参考にどぞー。 そのストリームですが、大雑把には入力ストリーム (Readable Stream) と出力ストリーム (Writable Stream) があり、その両方でもあるフィルタストリーム (Filter Stream) や 双方向ストリーム (Duplex Stream) がある。。。 なんて話が上記の id:Jxck による資料には書いてあ
unicode.org に JIS で定義されている文字を Unicode に変換する為のテーブル(対応一覧情報)が書かれたテキストファイルがこちらに公開されています。 JIS X 0201 と Unicode の対応表 JIS X 0201 の内容はアルファベットや半角カナ。191字。 http://unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/JIS/JIS0201.TXT JIS X 0208 と Unicode の対応表 JIS X 0208 の内容はひらがな、カタカナ、漢字(第1水準漢字、第2水準漢字)、全角記号。6,879字(漢字6,355字、非漢字524字)。 http://unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/JIS/JIS0208.TXT JIS X 0212 と Unic
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
