コンピューターで全漢字使用可に ６万字コード化 | NHKニュース
日本語の漢字は、戸籍などに使われているものも含めると６万字あるのに対し、コンピューターは、実は１万字しか扱うことができません。これに対し、このほど１５年越しの作業の末、６万字すべてが統一の規格にまとめられて、コンピューターがすべての漢字を扱えるようになり、ビッグデータの活用をはじめさまざまな効果が期待されています。 中には、メーカーなどが独自に対応した外字もありますが、コードが無いために、メーカーごとの互換性が無く、データを受け渡してもコンピューターが認識できずに「文字化け」してしまったり、ある人の名前に本名の外字を充てたものと略字を充てたものの２つのデータがあった場合、コンピューター上では、別の人と認識されてしまったりするなどの問題が起きていました。 このためＩＰＡ＝情報処理推進機構は平成１４年から、経済産業省とともに外字を含めたおよそ６万字の漢字１つ１つに、コードを割りつける作業を進め
『日本・中国・台湾・香港・韓国の常用漢字と漢字コード』と『文字コードの世界』 | yasuokaの日記 | スラド
本日付で、私たち(安岡孝一・安岡素子)の『日本・中国・台湾・香港・韓国の常用漢字と漢字コード』(京都大学未踏科学研究ユニット・学知創生ユニット・人文科学研究所、2017年3月)が、無事に発行された。まずは、めでたい。 実は、この本は、私たちの『文字コードの世界』(東京電機大学出版局、1999年9月)の第5章「常用漢字と漢字コード」を、最新のものにアップデートしたい、という意図のもとに書かれた。なので、元々は「日本・中国・台湾・韓国」を予定していた。その後、執筆中に、香港を入れる必要性を感じたことから、いったんは「日本・中国・台湾・韓国・香港」としたのだが、どうも坐りが悪く、最終的に「日本・中国・台湾・香港・韓国」としたものである。表組も、最初は日中台韓だったものを、いったん日中台韓香にして、最後は日中台香韓に組み直した。 はずだったのだが、まだp.81に日中台韓香が残っている、との御指摘を
MySQL と寿司ビール問題 - かみぽわーる
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
「iPhoneのMailから送ったメッセージ全体が文字化け」のまとめ - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
（2013年10月追記1）iOS 7の登場以来、このエントリへのアクセスが増えているので、情報を追加。iSO 7では、以前はauのiPhoneなどでしか発生しなかった「送信したcharset=CP932のメールが、Android端末で化ける」現象が、SoftBank iPhoneでも発生するようになった。詳しくは「iOS 7にしたら送信したメッセージが化けるようになった」を参照。 （2013年10月追記2）実際に確認できてはいないのだが、iOS 7の仕様変更により、iPhoneのメールアプリからSoftBankのケータイに絵文字を含むメールを送った場合、メッセージ全体が化けるのではないかと思われる（これに該当する経験をお持ちの方、コメント欄などで情報をいただけるとありがたいです）。 （2013年10月追記3）iOS 7がらみで（メッセージ全体が化けるのではなく）絵文字が表示されない問題につ
Nokogiriが文字化けするのの対策 - hitode909の日記
そこらへんで拾ってきたHTMLをNokogiriに渡すと，文字化けすることがあって，困ってた． Nokogiriに文字コードを渡せるので，HTMLから正規表現でcharsetを取り出して，一番多く出現するcharsetをそのページのcharsetとして採用すると，うまくいった． ヒューリスティックにやってるだけだけど，だいたいうまくいく． こんな感じ． charset = io.scan(/charset="?([^\s"]*)/i).flatten.inject(Hash.new{0}){|a, b| a[b]+=1 a }.to_a.sort_by{|a| a[1] }.reverse.first[0] before "〓\u0082«〓\u0083¼〓\u0083\u0089〓\u0083\u0095〓\u0082〓〓\u0082〓〓\u0083\u0088!! 〓\u0083´〓\
「鄧小平」のcharsetとエンコーディング - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
この項追記。このエントリで言及している「iPhoneから送信したメール」は、@me.comや@gmail.comなどの「プロバイダメール」。件名と本文のエンコーディングは、このエントリを書いた時点で参照可能だったサンプルのものだが、実際には同じメーラーであっても、テキストを構成する文字種によってエンコーディングは変化する。また、iPhoneから送信したメールをApple Mailで受信した場合の文字化けに関しては、エンコーディングの違いは関係なさそう（「iPhoneからMacに送ったメールの文字化け（まとめ）」を参照）。したがって、このエントリには、たぶんもう意味はない。エンコーディングが何によって決まるのかといった話については、後日新たなエントリで触れることができるかもしれない。 iPhoneから送信したメールの文字化け検証中。暫定的なまとめとして、iPhone Mailを含む各種のメー
講習会「文字集合と文字エンコーディング」について - はてなるせだいあり
なかなか豪快な記事(講習会「文字集合と文字エンコーディング」を開催しました — ディノオープンラボラトリ)を見つけたので、ツッコミを書いてみることにしました。ツッコミどころはかなり多いんですが、まぁ世の中の文字コードがらみの記事なんて大半がこんなものです。 「文字コード」という語は「正しい」か スライドの5ページ目は、「文字コード」という言い方は間違いという趣旨に見えますが、そうでもありません。 というのも、文字コードの世界は難しい世界です。複数のレイヤー、複数の国、複数のベンダーにまたがっているものが簡単になるはずがありません。しかし必須要素であるために、十分な知識を持たないまま、または必要性に駆られて十分な知見が集まる前に実装を行ってしまうこともしばしばあります。このことがさらに「歴史的経緯」としてさらに文字コードを難しくしています。例えばHTTPのcharsetパラメータは、char
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
