この記事について この記事は「わいわいswiftc #8」という勉強会で話した内容をまとめ直したものです。 UTF-8 UTF-8という文字エンコーディングがあります。これはUnicodeのコードポイントの列を、バイト列と相互変換する規則の1つです。これを使うことで我々は文字列をデータとして扱っています。Unicodeをバイト列へ変換することをエンコード、バイト列からUnicodeに復元することをデコードと呼びます。 オートマトン オートマトンという計算のモデルがあります。例えばこのような図で表されます。 https://ja.wikipedia.org/wiki/有限オートマトン オートマトンには状態と入力があります。入力を受け取ると現在の状態に応じて次の状態に変化します。最終的に入力を受理したり拒否したりします。上図でいえば、緑の丸が状態です。ここでは1から6まで6つの状態があります。
ユニコード正規化をすると、半角英数字や機種依存文字などの表記が統一できます。 表記ブレが吸収されることで検索性が高まったり、データの比較なども行いやすくなります。 正規化の手法にはNFD, NFC, NFKD, NFKCがありますが、その中でもNFKCという次のような正規化を行う方法をコードを交えて紹介します。 ウ゛ェ → ヴェ ＡＢＣ → ABC ① → 1 ㊤ → 上 Ⅲ → III ㌶ → ヘクタール ﾊﾝｶｸｶﾅ → ハンカクカナ ﹣ → - ※ 左辺はU+FE63 Small Hyphen-Minus: 小さいハイフンマイナス － → - ※ 左辺はU+FF0D Fullwidth Hyphen-Minus: 全角ハイフンマイナス 動作環境
はじめに おっと、またまた会いましたね。文字コードおじさんです。前回、Unicodeにおける結合文字列という話題を取り上げました。思わず「いやあ、結合文字列は強敵でしたね」と口走りそうになる代物でしたが、今回はそれに関連したUnicode正規化のお話をしてみようと思います。 ざっと前回のおさらい 詳しいことは前回の記事をご覧いただくとして、 最低限の用語についてざっくりおさらいしておきましょう 結合文字列 複数の文字を使って見かけ上の1文字を表現する仕組み 「て（U+3066）」 の後に、 「濁点（U+3099）」 を配置することによって 「で」 を表現する 合成済み文字 「で（U+3067）」などのあらかじめ合成されている文字 Unicode正規化 結合文字列を合成済みに統一したり、合成済み文字を結合文字列にしたりする処理 少々語弊がありますが、イメージがつかめればOKです。 正規化の4
郵便番号データを利用するサンプル を作っている最中に気になって、ひらがな、カタカナなどの文字種の Unicode の文字コードの範囲を調べました。 資料として http://www.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/JIS/SHIFTJIS.TXT を使います。 “OBSOLETE” となっていますが参考にはなります。これを表計算のシートに貼り付けて Unicode 順に並べ替えるとわかりやすいです。以下の説明には unicode.org の対応する “Code Charts” の URL も記しておきましたので、個別の字面とコード値の確認のためにご参照ください。
こんにちは、 株式会社ミクシィ で 家族アルバム みてね というアプリの開発に携わっている @_sobataro です。この記事では絵文字の標準とその扱いについてまとめます。 なお、この記事は mixiグループ Advent Calendar 2016 18日目の記事です。昨日は @radioboo さんの IGListKitでフィードUIをリファクタする でした。明日は @yusuke_tashiro さんの担当です。 TL; DR Part I. Unicode 絵文字の標準について。 暇人向け。読まなくてよい。 Part II. 実際にプログラムで絵文字を扱う上で問題となりうる点について。 Unicode 絵文字の文字数 (書記素クラスタの個数) を 厳密に正しく カウントするには、最新の Unicode (現時点では Unicode 9.0) 以降に対応したパーサが必要。 Acti
C++標準化委員会、ついに文字とは何かを理解する: char8_tという記事が話題だってので、つらつらと書いてみました。 「グリフ」について グリフ（glyph）という言葉の定義をめぐって でも触れられていますが、「グリフ」という言葉が「字体」を指すのか「字形」を指すのかってのは議論がありますね。文字コードの文脈では普通「字形」の意味だとして話を進めることが多いように思います。 CJK統合漢字について Wikipediaの記事にまとまっていますが、実際に推進していたのは中国みたいですね。うまくやればあんまり問題なかったんでしょうが、あんまりうまく行かなかったんですが、それでも国ごとにその国の過去にあった文字コードとの互換性は取れているので、実際の所CJK統合漢字ってあんまり問題にはなってないと思うんですよね。中国語フォントと日本語フォントを切り替えないといけないって問題はありますけど、それ
Javascriptとかいう変態は置いておいて少なくともC++でstringのlengthといったらこれですね。 code points 何コードポイントか、という数え方です。 U+0061, U+0928, U+093F, U+4E9C, U+10083 というのは5コードポイントですね。 ちなみにUTF-32のときのCode Unit数と同一です。 grapheme cluster 何書記素クラスタか、という数え方です。 (aनि亜𐂃) 人間が見たときに一文字と解釈するかという考え方です。 例えばनिはコードポイントで見るとU+0928(न), U+093F(ि)という2コードポイントで表されます。しかしこれを別々の文字とは人間は解釈せず、一文字と認識します。 他の例も見てみましょう。 प,ू,र,ी,त,ि 👩❤️💋👨 kiss: woman, manとして登録されてい
とある会員制掲示板からの文書の流出に困った運営者が、ユニコードの見えない文字「ゼロ幅文字(Zero-Width characters)」を使って流出させたユーザーを特定した、という話が出ていました。 数年前の話、Tom さんが所属していた競技ビデオゲームのチームでは、ログインが必要なプライベートの掲示板を使って連絡していました。その掲示板に書かれた秘密情報や戦術に関する重大アナウンスなどがしばしば掲示板外のウェブにコピペされ、チームにとって大きな問題となっていたそうです。 外部ユーザーの攻撃で中身が漏れたというよりは、メンバーの誰かがコピーしているのでは、と考えた Tom さんは、当時気になっていたユニコードのゼロ幅文字を使ったトリックを仕掛けたそうです。 ユーザーを特定する情報を、見えない文字に変換して埋め込む ログイン中のログインユーザーのユーザーIDを、一定のルールによってゼロ幅文字
Rob Pike explains how Ken Thompson invented UTF-8 in one evening and how they together built the first system-wide implementation in less than a week. Subject: UTF-8 history From: "Rob 'Commander' Pike" <r (at) google.com> Date: Wed, 30 Apr 2003 22:32:32 -0700 (Thu 06:32 BST) To: mkuhn (at) acm.org, henry (at) spsystems.net Cc: ken (at) entrisphere.com Looking around at some UTF-8 background, I se
絵文字を扱う上で知っておくと良いかもしれないことをまとめてみました。 Ruiさんの記事を見て、「EmojiはSurrogate Pair以外にも、色々とおもしろい技術があるんですよ〜」思って書いてみました。 なお、書いた人はAndroidの人間なので、特に表記していない場合は主にAndroid上での動作のことを書いてます。 またQiita初めてなので読みにくい部分等がありましてもご容赦ください。 サロゲートペア(Surrogate Pairs) このエントリーを書くきっかけにもなったサロゲートペア。なぜこれが導入されたかの経緯は、Ruiさんのブログエントリーに譲るとして、技術的な解説をします。 サロゲートペアは、U+0000..U+FFFFに収まりきらなかった範囲のUnicodeコードポイント(U+10000..U+10FFFF)を、なんとか16bitでエンコードしようとして導入されました
Unicodeのgrapheme cluster (書記素クラスタ) 2015/10/25 Unicodeテキストを1文字ずつ分割するアルゴリズムをUnicodeの仕様として定められており、grapheme cluster (書記素クラスタ)と呼ばれる。 普通はUnicodeのコードポイント1つずつ文字が割り当てられているので、ほとんどはコードポイント1つが1文字になるのだが、たまにコードポイント2つ以上で1文字になるものもあり、 1文字ずつテキストを分解するのは意外と複雑なルールになる。 Grapheme cluster について書かれている公式のドキュメントは以下にある。 Unicode® Standard Annex #29 UNICODE TEXT SEGMENTATION http://unicode.org/reports/tr29/ この記事は公式ドキュメントを読んで理解した
UnicodeのUTF-16エンコーディングではほとんどの文字（コードポイント）は2バイトで表現されるが、Unicodeに後から追加収録された文字の多くは4バイトで表現される。4バイト文字がうまく扱えないプログラムというのはわりとよくある。しかし世界中で広く使われるようになった絵文字がよりによって4バイト文字であるせいで、そのような文字が扱えない問題がよいペースで解決に向かいつつある。それについて少し説明してみようと思う。 Unicodeが80年代から90年代初頭にかけてデザインされたときの目標の一つは、Unicodeに含まれる文字数を65536個以内に収めることだった。現代の文章を実用的なレベルで表すためには、漢字などを含めてもそれだけの種類の文字があれば十分だと考えられたのだ。当然これは1文字を2バイトで表すことを念頭に置いていた。つまりコンピュータの揺籃期から当時に至るまで単純に英語
MySQL 8.0.1でutf8mb4_ja_0900_as_csが導入された
Sushi = Beer ?! An introduction of UTF8 support in MySQL 8.0 | MySQL Server Blog （ユーザーによる日本語訳: 寿司=ビール問題 : MySQL 8.0でのUTF8サポート入門 (MySQL Server Blogより) | Yakst）で言及されていた日本語用の照合順序 utf8mb4_ja_0900_as_cs 。 mysql80> SHOW COLLATION LIKE 'utf8%ja%'; +-----------------------+---------+-----+---------+----------+---------+ | Collation | Charset | Id | Default | Compiled | Sortlen | +-----------------------+-
半角スペース「 」とタブ「 」とU+3000 の全角スペース「 」だけでいいと思ってたけど、wikipediaの http://ja.wikipedia.org/wiki/スペース を見たらそれだけではない様子。 | U-Point | UTF-8 (in literal) | Name| |:---|--:|:--| --:| |U+0009 | \x09 | CHARACTER TABULATION | |U+0020 | \x20 | SPACE | |U+00A0 | \xc2\xa0 | NO-BREAK SPACE | |U+2002 | \xe2\x80\x82 | EN SPACE | |U+2003 | \xe2\x80\x83 | EM SPACE | |U+2004 | \xe2\x80\x84 | THREE-PER-EM SPACE | |U+2005 | \xe
const name1 = "\u0041\u006d\u00e9\u006c\u0069\u0065"; const name2 = "\u0041\u006d\u0065\u0301\u006c\u0069\u0065"; console.log(`${name1}, ${name2}`); // 予想される結果: "Amélie, Amélie" console.log(name1 === name2); // 予想される結果: false console.log(name1.length === name2.length); // 予想される結果: false const name1NFC = name1.normalize("NFC"); const name2NFC = name2.normalize("NFC"); console.log(`${name1NFC}, ${na
MySQL と Unicode Collation Algorithm (UCA) - かみぽわーる に関連するトピックで、 MySQL には寿司ビール問題というのがある。 寿司ビール問題どっかで詳しくお話を聞くべきだよなぁ。。。— RKajiyama (@RKajiyama) March 18, 2015 これはどういう問題かというと、 MySQL の Unicode では binary collation にしてコードポイントで比較しないと🍣と🍺に限らず絵文字が同値判定されるという問題です。 あれ？ MySQL の utf8mb4 charset って、4バイト文字同士を比較すると同じ文字扱いされる？ SELECT '🍣'='🍺' → 1 MySQL的には寿司とビールは同じ扱い。— とみたまさひろ (@tmtms) December 22, 2014 MySQLで select
utf8_unicode_ci に対する日本の開発者の見解 - かみぽわーる で、日本語が分かる人には utf8_unicode_ci のヤバさを感じてもらえたと思うんですけど、この挙動はドキュメントによると UCA というアルゴリズムによるものらしい。 MySQL implements the xxx_unicode_ci collations according to the Unicode Collation Algorithm (UCA) described at http://www.unicode.org/reports/tr10/. The collation uses the version-4.0.0 UCA weight keys: http://www.unicode.org/Public/UCA/4.0.0/allkeys-4.0.0.txt. Currently,
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
