You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

起源 円記号問題の始まりは1960年代にまで遡ります。1967 年に文字コード最初の国際規格である ISO R 646 が制定されましたが、その規格では 0x5C をはじめとして一部の文字が置き換え可能になっていました。アメリカの制定した ASCII では 0x5C に対して REVERSE SOLIDUS を割り当てました。一方、日本版である JIS X 0201 では YEN SIGN を割り当てました。 問題の拡大 7bit では扱いきれない文字を扱うため、世界で ISO 646 系のコードを拡張した文字コードが生まれました。日本ではシフトJIS、日本語 EUC、いわゆる JIS コードの三種類の文字コードが現れ、それぞれに多くの亜種が生まれました。では、それぞれの文字コードの 7bit 領域は ASCII と JIS X 0201 のどちらだったのでしょうか。 日本語 EUC 日本

ユニコード正規化をすると、半角英数字や機種依存文字などの表記が統一できます。 表記ブレが吸収されることで検索性が高まったり、データの比較なども行いやすくなります。 正規化の手法にはNFD, NFC, NFKD, NFKCがありますが、その中でもNFKCという次のような正規化を行う方法をコードを交えて紹介します。 ウ゛ェ → ヴェ ＡＢＣ → ABC ① → 1 ㊤ → 上 Ⅲ → III ㌶ → ヘクタール ﾊﾝｶｸｶﾅ → ハンカクカナ ﹣ → - ※ 左辺はU+FE63 Small Hyphen-Minus: 小さいハイフンマイナス － → - ※ 左辺はU+FF0D Fullwidth Hyphen-Minus: 全角ハイフンマイナス 動作環境

C++標準化委員会、ついに文字とは何かを理解する: char8_tという記事が話題だってので、つらつらと書いてみました。 「グリフ」について グリフ（glyph）という言葉の定義をめぐって でも触れられていますが、「グリフ」という言葉が「字体」を指すのか「字形」を指すのかってのは議論がありますね。文字コードの文脈では普通「字形」の意味だとして話を進めることが多いように思います。 CJK統合漢字について Wikipediaの記事にまとまっていますが、実際に推進していたのは中国みたいですね。うまくやればあんまり問題なかったんでしょうが、あんまりうまく行かなかったんですが、それでも国ごとにその国の過去にあった文字コードとの互換性は取れているので、実際の所CJK統合漢字ってあんまり問題にはなってないと思うんですよね。中国語フォントと日本語フォントを切り替えないといけないって問題はありますけど、それ

mysql> use utf8mb4_sample_development; mysql> show variables like "chara%"; +--------------------------+------------------------------------------------------+ | Variable_name | Value | +--------------------------+------------------------------------------------------+ | character_set_client | utf8 | | character_set_connection | utf8 | | character_set_database | utf8mb4 | | character_set_filesyste

UnicodeのUTF-16エンコーディングではほとんどの文字（コードポイント）は2バイトで表現されるが、Unicodeに後から追加収録された文字の多くは4バイトで表現される。4バイト文字がうまく扱えないプログラムというのはわりとよくある。しかし世界中で広く使われるようになった絵文字がよりによって4バイト文字であるせいで、そのような文字が扱えない問題がよいペースで解決に向かいつつある。それについて少し説明してみようと思う。 Unicodeが80年代から90年代初頭にかけてデザインされたときの目標の一つは、Unicodeに含まれる文字数を65536個以内に収めることだった。現代の文章を実用的なレベルで表すためには、漢字などを含めてもそれだけの種類の文字があれば十分だと考えられたのだ。当然これは1文字を2バイトで表すことを念頭に置いていた。つまりコンピュータの揺籃期から当時に至るまで単純に英語

こんな記事がありました。 gihyo.jp これはMacユーザー用の書籍の宣伝記事らしいのですが、「Windowsを使ってる人のためにMac側がひと手間かけてあげよう」なんて殊勝なことをマカーが言うとは時代も変わったもんです。（[追記] はてブのコメントを見たらさすがマカーという意見が並んでて安心しました） まあ私はWindowsユーザーでもMacユーザーでもないのでどうでもいいのですが、文字化けなネタなので食いついてみます。 記事中に、「付物出稿.zip」というファイルを開いた時の画像が載ってます。 文字の並びからして、UTF-8文字列をシフトJIS(CP932)とみなして表示してしまった文字列でしょう（「繧ｫ繝上ｙ繝ｼ繝輔か繝ｫ繧ｿ繧･」の元の文字は「カバーフォルダ」で、「蟶ｯ繝輔か繝ｫ繧ｿ繧･」は「帯フォルダ」）。 つまり、Macはファイル名をUTF-8でZIPに書き込み、Wi

半角スペース「 」とタブ「 」と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

ローマ数字のⅠ,Ⅱ,Ⅲ... の他に囲み文字 ①,②,③... もそれぞれ異なるバイト列になります。 MacJapanese が使われているアプリケーション ほとんど見かけないのですが、絶滅しているわけではありません。Microsoft Excel のファイル *.xls または *.xlsx を Mac 版 Office で CSV 出力すると MacJapanese になります。Windows 版 Office で同じ操作をすると CP932 の CSV ファイルが出力されます。非常にややこしいですね。また、Mac 標準のメーラーも MacJapanese を使っているようです。 Ruby での取り扱い Ruby で Shift_JIS, CP932, MacJapanese のファイルを読み込むことを考えます。Shift_JIS や CP932 であれば、File.read("hog

これは NSEG Advent Calender の7日目の記事です(内容は NSEG とも長野とも関係ありませんが…)。 www.adventar.org メールの送信者(From)や件名(Subject)は本来ASCII(の一部の文字)しか書くことができないんですが、MIME(RFC2047)の登場によって日本語等の非ASCII文字を記述することができるようになりました。 とは言ってもメールアプリから見て日本語が表示できているだけで、内部的にはASCII文字にエンコードされています。MIMEヘッダエンコーディングと呼ばれています。 たとえば、「日本語」という文字列は =?utf-8?b?5pel5pys6Kqe?= や =?iso-2022-jp?b?GyRCRnxLXDhsGyhC?= に変換されています。 この処理が実は非常に複雑で、正しくエンコードされてない場合がかなりあります。

以前Nodeで作っていたものをElectronで作り直していて、同じ問題にまたハマったので書いておく。 所謂、UTF-8-MAC問題である。もう遥か昔にNodeでハマった時の記事がある。 node.jsでUTF-8-MACを扱う - joker1007の日記 Macのファイルシステムはファイル名に対してNFDとかいう正規化を行っていて、ファイルシステムにアクセスする時に勝手に変換しやがる仕組みになっている。 このせいで、濁点が入ると急に死ぬとか、本当辛い問題が起きる。何の嫌がらせなんだと……。この世界は文字が8ビットで済む様な国ばっかじゃねえんだよ！ とりあえずMac NFDでググると辛いのは俺だけじゃない気持ちになれる。 で、昔は上で貼ったブログに書いたような方法で解決していたのだが、正直、この解決策は2015年にもなって面倒過ぎるだろと思っていた。 (マジかよーってググって自分の記事が

序 「文字列を文字の列とみなす単純化」について議論がありますが、前提が抜け落ちてるように思うので書くことにします。 そもそもこの話はどのような文脈の上にあるかというと、テキスト処理 (wikipedia:en:Text_processing) の文脈になります。ここでいう「テキスト処理」とは plain text (wikipedia:プレーンテキスト) の検索・加工のことで、ここでは特に UNIX Text Processing の系譜が念頭に置かれています。つまり、複雑な装飾を含むリッチテキストではなく、処理の対象を ASCII 文字列といくつかの制御文字へと抽象化することで、正規表現のような強力な道具を用いた処理を可能とした世界です。UNIX でのお話ですから、ここでの具体的な処理の単位は char であり、全体としては char[] になります。この char の中身は上で述べたと

先日 @shyouhei さんのTweetに反応して文字列が文字の列かどうかが言語によって異なるという話をTweetしました。 shyouheiさんの投稿: PythonはどうかしらんがRubyの設計思想は「世の中はシンプルじゃない」だからな。文字列を文字の列とみなす発想その物がすでにRubyからすると過度に世界を単純化しすぎている。 https://twitter.com/shyouhei/status/528106973565165568 もうちょっと言っておくと数値計算で勝ち目のないRubyは文字列処理にめっちゃ注力してるんで。文字列処理こそがRubyの主戦場。そこでRubyが文字列をあえてカタマリで扱ってることにはそれなりの理由というものがある。つまり分解しようとするほうが困りごとが増える。IVSとか。 https://twitter.com/shyouhei/status/528

Mac版ExcelはBOM付きUTF-16LEでないと正常にインポートできません。 以下Railsのコントローラーからの抜粋。 ポイントは、BOMのバイト列を force_encoding("UTF-16LE") しているところです。 こうしないと、output（UTF-16LE）と連結する際にエラーが出ます（ソースコードがUTF-8だとBOMのバイト列も当然UTF-8文字列とみなされるので）。 format.csv { header = "ID,氏名,住所,年齢,電話番号\r\n" CSV.generate(output = header) do |csv| @users.each do |user| csv << [user.id, user.name, user.address, user.age, user.tel] end end bom = "\xFE\xFF".force_e

これは，こちらのサイトによると， Depending on your requirements, this may or may not be what you want, but it is certainly consistent with the overall design of the String type to abstract away as many Unicode details as possible. Rule of thumb: if two strings look equal to the user, they will be equal in your code. つまり，「Unicodeでの実装にかかわらず，ユーザ側からの見た目が同じであるからには，コード上でも同一として扱われるべきである」という原則に基づいているとのことです。 実際，この仕様はApple

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

Googleは本日、日本語を含む非アルファベット文字を使うメールアドレスとの送受信に対応させると発表しました。 Official Google Blog: A first step toward more global email http://googleblog.blogspot.jp/2014/08/a-first-step-toward-more-global-email.html 従来、メールアドレスに使える文字はAからZまでのラテン文字(アルファベット)だけで、非アルファベットを使用した場合、Gmailから認識することはできず、メールの送受信は不可能でした。この状況を改善して、Googleは日本語や中国語、アクセントつきのラテン特殊文字などをGmail側から認識できるようにしました。これにより、例えば、「武@メール.グーグル」というメールアドレスからのメールを受信でき、またこの