絵文字がある種のUnicodeバグを世界から一掃しつつある件について｜Rui Ueyama
UnicodeのUTF-16エンコーディングではほとんどの文字（コードポイント）は2バイトで表現されるが、Unicodeに後から追加収録された文字の多くは4バイトで表現される。4バイト文字がうまく扱えないプログラムというのはわりとよくある。しかし世界中で広く使われるようになった絵文字がよりによって4バイト文字であるせいで、そのような文字が扱えない問題がよいペースで解決に向かいつつある。それについて少し説明してみようと思う。 Unicodeが80年代から90年代初頭にかけてデザインされたときの目標の一つは、Unicodeに含まれる文字数を65536個以内に収めることだった。現代の文章を実用的なレベルで表すためには、漢字などを含めてもそれだけの種類の文字があれば十分だと考えられたのだ。当然これは1文字を2バイトで表すことを念頭に置いていた。つまりコンピュータの揺籃期から当時に至るまで単純に英語
C#で高精度なテキストファイル文字コード自動判別（2014年版） - hnx8のブログ
C#（.NET Framework）に限ったことではありませんが、汎用的にテキストファイルを扱うようなアプリケーションを作っていると、よく 特定の文字コードのファイルしか読み出せないのでは困る ⇒文字コードを自動判別し、テキストの内容を取り出したい 読み出したファイルと同じ文字コードでファイルを書き出したい ⇒読み出したファイルの文字コードを知りたい といった場面に出くわします。 ですが、C#（.NET Framework）標準のライブラリではそのような機能は提供されていないため、文字コードを判定するには、 自前で文字コード判定のロジックを実装する 出来合いの外部ライブラリ、Windows版NKF32.dll、ICU4Cなどを利用する IE用の文字コード判別ライブラリ（mlang.dll）を利用する ※COMコンポーネント呼び出し要 のいずれかの方法を取ることになります。 HNXgrepと
「文字列」について - 2014-11-07 - はてなるせだいあり
序 「文字列を文字の列とみなす単純化」について議論がありますが、前提が抜け落ちてるように思うので書くことにします。 そもそもこの話はどのような文脈の上にあるかというと、テキスト処理 (wikipedia:en:Text_processing) の文脈になります。ここでいう「テキスト処理」とは plain text (wikipedia:プレーンテキスト) の検索・加工のことで、ここでは特に UNIX Text Processing の系譜が念頭に置かれています。つまり、複雑な装飾を含むリッチテキストではなく、処理の対象を ASCII 文字列といくつかの制御文字へと抽象化することで、正規表現のような強力な道具を用いた処理を可能とした世界です。UNIX でのお話ですから、ここでの具体的な処理の単位は char であり、全体としては char[] になります。この char の中身は上で述べたと
UTF-8にもいろいろある - ザリガニが見ていた...。
前回からの続き。 改行コードの違いを体感してみる - ザリガニが見ていた...。 文字エンコードとロケールを体感する - ザリガニが見ていた...。 改行コードの違いも知った。文字コードとロケール、ターミナルの言語環境との関係も知った。これで文字にまつわる悩みとはおさらばできると思ったら、まだダメだった...。 実験環境 OSX 10.8 Mountain Lion以前((OSX 10.9 Mavericksでは、Mac仕様なNFDのUTF-8を表示しようとするとエラーになってしまったため、10.8以前の環境で実験した。Assertion failed: (width > 0), function conv_c, file /SourceCache/shell_cmds/shell_cmds-175/hexdump/conv.c, line 137. ** ** Abort trap: 6
Twitter時代の文字の数え方 | 配電盤
入力「×」のブラウザでは、「𠮷」が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
新作 Whisker を公開 – ものかの
Whisker 0.9.0 を公開！ → downloadのページ 新作ですよん。 テキストファイルのエンコーディングを推測するソフトです。 深沢さんのツイートで「BOMの検出」とか「テキストエンコーディングの推測」をざっとやるソフトがありそうでないことが分かりまして、作ってみました。 作ったばかりでベータ版扱いです。Helpもまだ書いてないので、ここで使い方を説明します。 使い方 テキストファイルを本体アイコンにドラッグ＆ドロップします（複数一括可）。 ウインドウが表示され、そこに結果が表示されます（ウインドウへのドラッグ＆ドロップも可） 結果表示のリストをダブルクリックするとコンテクストメニューが表示されます。該当するエンコーディングを選択すると Unicode へ変換してテキストエディットの新規ウインドウに文字をセットします。注：テキストエディットで開くわけではありません 「Gues
あかつき＠おばなのDTP稼業録 【文字入力と字形の保護】2.インプットメソッド
前エントリの続きです。 まずはインプットメソッドについてまとめてみました。 前のエントリで使用していたのはATOK 2009 for Macです。 ATOKはATOK 2007から「JIS X 0213:2004」に対応し、候補ウィンドウにJIS X 0213:2004で追加された文字が表示されるようになりました（参考：ATOK 2007 for Windows 商品情報。Macも2007から対応とのことです）。 これにより、Adobe-Japan1-5/1-6準拠のフォントに収録されている文字を変換候補から入力することが出来るようになったのですが、Adobe-Japan1-3（OpenTypeのStd）・1-4（モリサワ・フォントワークス・小塚のPro。ヒラギノのProは1-5）準拠のフォント使用している場合、収録外の文字を入力してしまうことになり、勝手にフォントが置き換わってしまいます
あかつき＠おばなのDTP稼業録 【文字入力と字形の保護】1.プロローグ
InDesignCS5でインライン入力で文字を入力していたところ、使用しているフォントに収録されていない文字を入力したらちょっと変な挙動に出会ったのでまとめてみました。 入力しようとしているテキストフレームはこんな感じ。 フォントはモリサワのA-OTF ゴシックMB101 Pro Rを使用しています。 このテキスト内に「齩」（ごう・Unicode：齩）という文字をテキストエディタで入力してコピー＆ペーストします。 文字が表示されません。 同じ文字をインプットメソッド（ATOK）から直接入力します。 すると、入力した文字だけ小塚明朝Pro Rになってしまいました。 ※実際に入力した様子をムービーにしました。リンクはこちら。 InDesign CS3で同じように「齩」を入力すると Adobe Ming Std Lなるフォントに変わってしまいました。 （20110122 追記）本来はCS3でも小
ThunderbirdとApple Mail間の添付ファイル名の文字化け - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
前回のエントリで述べたように、Thunderbird 3とApple Mail 4.2は、ともにRFC 2231をサポートしているが、その方法に若干の違いがある。 長いファイル名をRFC 2231でエンコードする際、Thunderbirdは複数行に分割し、Apple Mailは分割しない。下図は、「あいうえおあいうえおあいうえお.png」というファイルを添付して送信した例。Apple Mailがエンコードしたfilenameパラメータには、（図ではウインドウの幅の制限により折り返し表示されているが）改行コードは入っていない。 RFC 2231で複数行にする方法が規定されている以上、1行あたりの文字数の制限が存在するものと思われる。以下に引用するRFC 5322の一節がそれだろうか。 Each line of characters MUST be no more than 998 chara
日本語の添付ファイル名のエンコーディング - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
メールの添付ファイル名をめぐる問題について、Mac OS Xユーザの視点でまとめてみる。 添付ファイルを送信する際、その名前はどこに書かれるのか。RFC 2183では、添付ファイル名はContent-Dispositionフィールドのfilenameパラメータに記述することになっている。ただし今回調べたメーラーまたはメールサービスはすべて、filenameパラメータだけでなく、Content-Typeフィールドのnameパラメータにも添付ファイル名を記述する。後述するが、nameパラメータは互換用として機能している。 添付ファイルを送信する際、その名前はどのような方法でエンコードされるか。非ASCII文字列を添付ファイル名として扱う方法は、RFC 2231で定義されている。しかし、OutlookやWindows MailなどはRFC 2231をサポートしておらず、代わりにMIME Bエンコ
Mac OS X の「テキストエンコーディング」
Mac OS X でテキスト編集をしていると「テキストエンコーディング」という用語を目にします。「誰か説明してくれないかな〜」とずっと待っているのですが、誰もしてくれそうにないので自分で説明してみます。 ((「テキス...Mac OS X の「テキストエンコーディング」 Mac OS X でテキスト編集をしていると「テキストエンコーディング」という用語を目にします。「誰か説明してくれないかな〜」とずっと待っているのですが、誰もしてくれそうにないので自分で説明してみます。1) テキストエンコーディングは、符号化文字集合と文字符号化方式の組み合わせです。 大ざっぱな表にしてみます。こんな感じ。 もちろんこの他にもたくさんあるのですが、すべて組み合わせが異なります。「同じ組み合わせで異なるテキストエンコーディング」というのはありません。 テキストデータはかならずこのように「符号化文字集合」と「
「文字コード技術入門」制作で直面した文字コード問題 - yanok.net
本書 (「プログラマのための文字コード技術入門」)の原稿はコンピュータ上でテキストエディタを使って書いています。そうすると、文字コード値の羅列として文を表現することになります。 本書には、「ト゚」や「か゚」のようにUnicodeで合成の必要な文字や「𩸽」のようなBMP外の符号位置にある文字、あるいは「海」のようにUnicodeの正規化処理で別の符号位置に置き換わってしまう文字などがふんだんに盛り込まれています。 このため、本書の執筆・編集において、まさに文字コードの問題に直面することになりました。 私が執筆に使っているのはEmacs 22です。このエディタでは、テキストをEUC-JIS-2004 (Emacsのcoding system名としてはeuc-jisx0213)として保存している分にはいいのですが、UTF-8として保存しようとすると、「か゚」のように結合文字を使う文字については
ぼくの大好きな符号化文字 - もじのなまえ
ときどき私的な席で「どんな仕事をしてるんです？」と聞かれます。「フリーライターです」と答えるとたいていは納得してくれますが、なかには「で、どんなものを書いてるんです？」と突っ込んでくる人もおられる。 すると、はたと考え込んでしまいます。もちろん自分がどんなことを書いているかは分かっている。同時に、それがすごく面白いと思っているから原稿に書いているわけです。でも、その面白さを専門外の人にも分かりやすく説明するって、案外むずかしいものです。もっとも、それをすることは自分の足下を見つめ直すことになるのかもしれません。 1989年の印刷文字 ぼくの専門は符号化文字です。文字コードとかフォントとか、符号化文字に関わる全般。このブログでこのところ集中的に取り上げている常用漢字表の改定も、そうした視点から見ています。では、その符号化文字とはなにか？ もう20年以上も前、1989年だったと思います。手塚治
kumaryu日記(2009-02-22)
_ [Ruby] Test::Unitが変わってる Test::Unitで一つだけテスト動かす方法が全くわからなかったんだけど、ソースを見て分かった。 ruby test_foo.rb --name test_bar マニュアルには--name=test_barと書いてあるけど、1.9ではテスト用のライブラリが変わったとかで=を入れちゃだめになっていた。 _ [Ruby] utf8-macってなんだこりゃ 文字コードではまったのでメモっとく。MacPortsとか使わず自前で入れた1.9.1-p0でのおはなし。 ruby 1.9.1p0 (2009-01-30 revision 21907) [i386-darwin9.6.0] MacでRubyを動かすと、ファイルシステムの文字エンコーディングはUTF8-MACとかになるらしい。 FreeTypeに文字をUTF-8で渡す所でString#e
Apple Mailのテキストエンコーディング - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
Mac OS X 10.6 Snow Leopardでは、Apple Mail（Mail.app）のテキストエンコーディングに関する仕様が変更された。下図は、Tiger、Leopard、Snow Leopardの違いをまとめたもの。検証に用いたSnow LeopardのMailはバージョン4.1（1076）。 TigerおよびLeopardのMailはcharset=CP932のメールを送信することがあったが（図、黄色地）、Snow LeopardではISO-2022-JPの範囲外の文字を含むメールのテキストエンコーディングは、基本的にUTF-8に統一された。この変更は歓迎できる。 ただし、半角カタカナは例外。Leopardでは半角カタカナは（それ以外の文字がISO-2022-JPの範囲内であれば）全角に変換した上でcharset=ISO-2022-JPで送信する仕様だった。Snow Le
講習会「文字集合と文字エンコーディング」について - はてなるせだいあり
なかなか豪快な記事(講習会「文字集合と文字エンコーディング」を開催しました — ディノオープンラボラトリ)を見つけたので、ツッコミを書いてみることにしました。ツッコミどころはかなり多いんですが、まぁ世の中の文字コードがらみの記事なんて大半がこんなものです。 「文字コード」という語は「正しい」か スライドの5ページ目は、「文字コード」という言い方は間違いという趣旨に見えますが、そうでもありません。 というのも、文字コードの世界は難しい世界です。複数のレイヤー、複数の国、複数のベンダーにまたがっているものが簡単になるはずがありません。しかし必須要素であるために、十分な知識を持たないまま、または必要性に駆られて十分な知見が集まる前に実装を行ってしまうこともしばしばあります。このことがさらに「歴史的経緯」としてさらに文字コードを難しくしています。例えばHTTPのcharsetパラメータは、char
83pvと90pvの違い - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
83pvと90pvという用語についてのややこしい話は別の機会に譲ることとして、今回はとりあえず「どちらもMacのShift-JISのバリエーション」と大ざっぱに定義しておく。83pvと90pvでは、下図のように外字の割り当てが異なる。16進数はShift-JISの符号位置。 83pv外字は、PC98外字のサブセットである。0x86A2から0x879C（水色地）は漢字Talk 7.5以降に付属する細明朝体と中ゴシック体のスクリーン・フォントに含まれているもの。このうち0x8740から0x879CはCP932とほぼ共通（CP932では0x877Eに「平成」が追加されている）。0x8540から0x8690（ピンク地）の半角文字は、PostScriptプリンタで出力することが可能であるが細明朝体と中ゴシック体のスクリーン・フォントに含まれないもの。 アクセス・ログで「83pv 90pv 違い」とい
第4回 Ruby M17N 事始め：文字コード編 | gihyo.jp
はじめに 今回は文字列を扱う際には忘れてはならない文字コードについて、日本人が知っておくべきエンコーディングを中心に解説していきます。 US-ASCII ASCIIは、ASA（American Standards Association、のちにUSASIを経てANSI）によって、1963年6月17日にASA X3.4-1963として制定され、1967年7月7日にUSASI（United States of America Standards Institute、ASAから1966年8月24日に改組）によってUSAS X3.4-1967へと改訂されてほぼ現在の形となりました。 その後の多くの文字コードがASCIIのスーパーセットとして作られたため、ASCIIは共通のサブセットとして特別な位置に置かれるようになりました。RubyでもASCIIに含まれる文字のみで構成されるStringは、ASC
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
全角チルダ問題
バックスラッシュの表示テスト (UTF-8版) - CSSめも＠Palm84