HTMLファイルで特殊記号を使う際、① は ①、© は © のように置き換えて書かないといけないものだと思いこんでいないでしょうか。 現代ではそれは誤解です。 UTF-8では特殊記号の文字参照は不要 そもそも環境依存文字とは、データを扱う機種・ソフトウェアなどの違い（文字コードの割り当ての違い）により表示に違いが出てしまう文字のことでした。 例えばShift_JISには © が含まれておらずそもそも保存できなかったり、 ① などの丸数字は含まれているものの、WindowsとMac OS（当時）の割り当ての違いにより正しく表示できなかったりしました。[1] しかし現在ではUnicodeによって文字コードは統一化されており、その問題はほとんど起きなくなっています。 近年では多くの場合 UTF-8 でファイルを記述すると思います。 HTMLファイルの文字エンコーディングが
文字コード再入門 ─ Unicodeでのサロゲートペア、結合文字、正規化、書記素クラスタを理解しよう！ 文字コードには、どのような種類があり、それぞれどのような意味を持つのか、といった、文字コードの基本的な概念、従来の文字コードを紹介し、現在のUnicodeの構成を概説し、プログラミングにおいて注意すべき箇所をいくつか取り上げます。 ソフトウェア開発に携わる方の多くは、何らかの形で文字コードに触れることがあるでしょう。文字や記号をコンピュータ上でデータとして扱うには、文字コードの知識が必要不可欠です。 本稿では、書籍『プログラマのための文字コード技術入門』の著者である矢野啓介さんが、知っておきたい基礎知識を分かりやすく解説します。 文字コードとは？ Unicode以前の文字コード Unicodeとその主な符号化形式 UTF-16 UTF-32 UTF-8 Webで文字コードを指定する仕組み
アプリの国際化は単に表示されるテキストの翻訳にとどまるものではありません。 このセッションでは、開発者とユーザーの双方の視点から、様々な地域で使われる iOS アプリの開発を通して得られた具体的な事例を踏まえ、アプリの国際化で必要となる技術的な知識、避けては通れない問題とその対策、そして今後のアプ…
はじめに 社内の勉強会で発表した文字コードの話の焼き直しです。ところどころ適当なので話半分に読んでもらえると助かります。 これ以上闇の深さを知りたくないと思って、深淵に辿り着く前に文字コードの勉強を打ち切っています。文字コードの専門家でもないので雑です。 調査が甘いので間違ってることも多々あるかもしれません。その場合はコメントください。修正します。 自信のないところは「らしい」とか「ようです」などのように伝聞調で書いています。あらかじめご了承ください。 また、前提知識として2進数と16進数の基礎的な知識を要求しています。 16進数の表現には特に断りがないかぎり 0xFFFF のような表現を使います。 2進数を使う場合には必ず断り書きを入れます。それ以外は10進数です。 本筋には関係のない、重要ではない情報は脚注にあります。気になったところだけご覧ください。 アジェンダ 今回の話に関係ある用
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として登録されてい
絵文字を扱う上で知っておくと良いかもしれないことをまとめてみました。 Ruiさんの記事を見て、「EmojiはSurrogate Pair以外にも、色々とおもしろい技術があるんですよ〜」思って書いてみました。 なお、書いた人はAndroidの人間なので、特に表記していない場合は主にAndroid上での動作のことを書いてます。 またQiita初めてなので読みにくい部分等がありましてもご容赦ください。 サロゲートペア(Surrogate Pairs) このエントリーを書くきっかけにもなったサロゲートペア。なぜこれが導入されたかの経緯は、Ruiさんのブログエントリーに譲るとして、技術的な解説をします。 サロゲートペアは、U+0000..U+FFFFに収まりきらなかった範囲のUnicodeコードポイント(U+10000..U+10FFFF)を、なんとか16bitでエンコードしようとして導入されました
稀に出くわす Unicode 文字のエスケープシーケンス。以下のようなヤツです。 var text = @"\u3053\u3093\u306b\u3061\u306f\u3001\u4e16\u754c\uff01"; その文字をプログラムで戻さなければならない場合があります。今回はそんな方法のメモ。 正規表現の置換を使う ストレートな方法としては、正規表現で '\u....'と入ってる場所を探し出して置換してしまうというのがあるでしょう。サンプルとしては以下のようになります。毎回書くのがダルいですが、メソッド化してしまえば良いですね。 var result = Regex.Replace ( text, @"\\[Uu]([0-9A-Fa-f]{4})", x => { var code = ushort.Parse(x.Groups[1].Value, NumberStyles.Al
4月にMySQLの日本語コレーションについて語り合う場に呼ばれていろいろ話を聞いてきました。すぐにブログを書こうと思ったんですが、はや2ヶ月経過…。 ときどき、自分がMySQLの文字コードに関して発表する際に、次のようなスライドをいれてるんですが、 MySQL 8.0 でとうとう日本語コレーションが入ることになったのに、なんか期待してたのと違いました。 で、その辺の話を聞きました（2ヶ月も経ってるのでうろ覚え）。 Q. わざわざ日本語ロケール作るんだったら日本人が扱いやすいロケールにしてほしい utf8mb4_ja_0900_as_csはMySQLが独自に考えたものではない。Unicode規格に従っている。過去にいろいろ独自にやって失敗してきてるので、もう独自にやるのは避けたい。 ai(accent insensitive)で「ハ」=「パ」=「バ」になるのも、ci(case insensi
自分の知らないCJK Ideographのバリエーションがまだあったことに戦慄している pic.twitter.com/kUlyRLDDTM— moriyoshit (@moriyoshit) March 9, 2017 などというツイートをしたところ、思ったより反響があったのでまとめておく。 上記ではあいまいに「バリエーション」などと書いたが、Unicodeとそれを扱う環境においては、バリエーションと一口に言っても次のような状況がある。 意味論的に等価な異なる字形の集合 同じ字形で異なるコードポイントの集合 aは結構なじみ深いと思う。 a-1. 異なるコードポイントにそれぞれ異なる字形が割り当てられているもの 例: 「東」(U+6771) ⇔「东」(U+4E1C) 「斉」(U+6589) ⇔「齊」(U+9F4A) 「高」(U+9AD8) ⇔「髙」(U+9AD9) a-2. 同じコードポイ
Intro textarea などに入力された文字数を、JS で数えたい場合がある。 ここで .length を数えるだけではダメな理由は、文字コードや JS の内部表現の話を理解する必要がある。 多言語や絵文字対応なども踏まえた上で、どう処理するべきなのか。 それ自体は枯れた話題ではあるが、近年 ECMAScript に追加された機能などを交えて解説する。 なお、文字コードの仕組みを詳解すること自体が目的では無いため、BOM, UCS-2, Endian, 歴史的経緯など、この手の話題につき物な話の一部は省くこととする。 1 文字とは何か Unicode は全ての文字に ID を振ることを目的としている。 例えば 😭 (loudly crying face) なら 0x1F62D だ。 1 つの文字に 1 つの ID が割り当てられているのだから、文字の数を数える場合は、この ID の
func coloredText(from str: String, target: String) -> NSAttributedString { // 対象単語の出現範囲( Range<String.Index> )を取得 let range: Range<String.Index> = str.range(of: target)! // Range<String.Index> を NSRange に変換 let nsRange = NSRange(location: str.distance(from: str.startIndex, to: range.lowerBound), length: target.characters.count ) // 対象単語に色をつけて返す let result = NSMutableAttributedString(string: str) r
自分の頭を整理するために書いておく。正しいかは知らない。 まず前提として、Javaの内部表現としての「文字」は16ビット長のUTF-16ということがある。そうすると、普通に長さを取得すると、UTF-16のサロゲートペアで表される文字は2文字と扱われる。 また、文字には合成済み文字という話がある。「か」の後に濁点を結合することで、「が」を表現するみたいなやつ。 これらから、どこまで考慮して文字列の長さを取得するかでやり方が違う。 UTF-16のサロゲートペアを考慮しない UTF-16のサロゲートペアを考慮する 合成済み文字を考慮する 以下試したサンプルコード。 import java.text.BreakIterator; public class UnicodeCharSample { public static void main(String[] args) { // 𪛀あが St
こんにちは、hachi8833です。 少し前に、babaさんから「Rubyの内部文字コードはUTF-8じゃないよ」とツッコミがありました。 （追記: 上は会話の途中から切り取りましたのでご了承ください） いきなりの展開にくらくらきましたが、babaさんはさらにたたみかけます。 こうしたことはとっくにご存じの方も多いと思いますが、「Rubyといえば2.0以来UTF-8完全対応なんじゃないの」と勝手に思い込んでた私は脳に掌底を食らったような思いです。ああ、でもこういうことがあるから面白い。 ⚓ プログラミング言語と内部文字コードの関係 まず最初に押さえておきたい点です。プログラミング言語で文字コードに関連する部分は、「文字列」「正規表現」「入出力」「コード中の文字リテラル（""の中など）」「コード中の文字リテラル以外の要素（変数名など）」「ファイル名」などが中心になります。そして文字列に関連し
世の中がほぼUnicode前提になってめでたしめでたし。とはいかなかった現実の話。 String型でできる文字列処理とか、ソースコード自体、特に識別子で使える文字とか。 軽くおさらい: Unicode まあいろんなところでいろんな人が書いてると思うのでさらっと概要だけ。 Unicodeは、元々、「65,536文字あれば十分だろ」とかいう幻想の元、2バイト固定長の文字コードとして作られていました。 もちろん足りなくて、ビット数を拡張。基本が2バイトのままでこの拡張した分を取り扱えるようにしたのが今のUTF-16で、拡張分は2文字分(4バイト)を使って表現。 この、2文字分使って1文字を表すやつのことをサロゲートペア(surrogate pair: 代理対)と呼びます。 あと、ASCII文字も2バイトになるのを欧米人が嫌って、ASCII文字はASCIIコードのまま、逆に漢字・ひらがな・カタカナ
こんにちは、Webアプリケーションエンジニアのid:nanto_viです。みなさんHTMLのフォーム検証機能は使っていますか? 近年は各Webブラウザの対応も進み、お手軽にフォームの利便性を高められるようになっています。 そんなフォーム検証機能のひとつがinput要素のpattern属性です。pattern属性の値にJavaScriptの正規表現パターンを指定することで、ユーザーの入力が意図しないものであった場合、フォーム送信ができなくなります。下図は5桁の数字の入力が求められるところに3桁しか入力せずフォーム送信しようとしたところです。ブラウザに組み込みのエラー表示が出現し、またそのメッセージにtitle属性の値が使われていることを確認できるでしょう。(pattern属性を指定する際には、title属性に書式の説明を記述することが推奨されています。) <input type="text"
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
mysqlでは、collate = utf8_unicode_ciを指定すると、大文字-小文字だけでなく、全角-半角を同一視できるそうですが、実際にどの文字が同一視されるのかを試してみました。 collateとは http://tetlist.info/2009/01/mysql ↑このエントリでも分かりやすく紹介されていますが、collate(照合順序)とは、文字を比較(一致/不一致や表示順)する際のルールです。 utf8_unicode_ciで大文字-小文字だけでなく、全角-半角を同一視 mysqlのデフォルトcollateであるutf8_general_ciでは、大文字-小文字を同一視しますが、utf8_unicode_ciでは、さらに半角-全角も同一視します。 ※ci とは Case Insensitive の略称のようです tableやcolumn自体にcollateを設定する
gcj 19. UTF-8 † さすがにいつまでもLatin1(ISO 8859-1)決め打ち（→gcj/15）はまずい。そろそろUTF-8をサポートするか。 ↑ Unicode † Unicodeは時代別に変遷がある。（注：いい加減な説明） UCS-2(16bit) UCS-4(32bit) UTF-32(U+000000〜U+10FFFF) ← 今ここ ↑ UCS-2 † 当初のUnicodeの規格。 文字コードを16bit化することにより主要な文字コードで使われる文字をフラットなコードに押し込めようとしたもの。 必ずしも多言語環境を優先したものではない。CJK漢字統合もその方針の産物。 初期の実装では、内部処理がUnicodeで行われていても、表示できる文字はロカールに縛られていたりした。 ex. Visual Basic 4〜6 この時代に実装された処理系が現在主流になっている。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
