漢字1文字が最大8バイト、Unicodeの「IVS」とは？
「漢字1文字は2バイト」という常識が、大きく変わろうとしている。現在改正中の「常用漢字表」に対応するためには、Unicodeの4バイト文字を使用する必要があるが、それだけでは済まない恐れがある。今後、戸籍や住民基本台帳で使われている文字がUnicodeに追加されると、漢字1文字が最大8バイトになるかもしれない。文字コードに詳しい京都大学人文科学研究所附属東アジア人文情報学研究センターの安岡孝一准教授が、問題の核心を解説する。（日経コンピュータ） 先日公開した『新常用漢字表が迫るUnicode移行、「シフトJIS」では対応不可能』の読者から、「今後のシステムでは漢字1文字を最大4バイトで処理すればいいのか」という質問を頂いた。実は、UTF-8あるいはUTF-16で漢字を表す場合、最新のUnicodeにおけるIVS（Ideographic Variation Sequence）を考慮すると、漢
新常用漢字表が迫るUnicode移行、「シフトJIS」では対応不可能 | 日経 xTECH（クロステック）
普段使用する漢字の指針となる「常用漢字表」が、2010年度にも改正される。新たに追加される196文字の中に、文字コード「シフトJIS」にない漢字が含まれているため、情報システムに大きな影響を与えそうだ。最新のJIS規格「JIS X 0213:2004」の改正に委員としてかかわった京都大学人文科学研究所附属東アジア人文情報学研究センターの安岡孝一准教授が、問題の核心を解説する。 （日経コンピュータ） 2009年11月10日、文部科学省の「文化審議会国語分科会」において、常用漢字表の改正案が承認された。現行の常用漢字表にある1945字から「銑」「錘」「勺」「匁」「脹」の5字を削除し、新たに196字を追加する改正案で、2010年度の内閣告示を目指している。 新しい常用漢字表が告示されると、「シフトJIS」や「EUC-JP」といった従来からある文字コードを使用するシステムで大きな問題が生じ
第8回 Unicodeからの多対一の変換［後編］ | gihyo.jp
前回は、WindowsにおいてWideCharToMultiByte APIを使用してUnicodeからShift_JISやISO-8859-1へ変換した場合に、WC_NO_BEST_FIT_CHARSというフラグを指定しなかった場合は「似ている文字への変換」が発生するため、セキュリティ上の問題が発生する可能性がある、という説明をしました。 今回は、実際にUnicodeから他の文字コードへの変換が、具体的に脆弱性を引き起こした例をいくつか紹介します。 電子メールの添付ファイル 電子メールの添付ファイル名には自由にUnicodeの文字が指定できますが、いくつかのメールクライアントにおいては添付ファイル名をUnicodeではなくShift_JISとして扱うために、問題が発生していました。 JVN#89344424: 複数のメールクライアントソフトにおける、添付ファイルによりメールクライアントソ
絵文字が開いてしまった「パンドラの箱」第3回--Unicode提案の限界とメリット
前回までを振り返る--Unicodeコンソーシアムの影響力 前回はどこまでお話ししましたっけ。世界中の文字の収録を目的とした文字コード規格、Unicodeは、米国のIT企業を中心に結成されたUnicodeコンソーシアムが制定するデファクト規格に過ぎないこと。しかし公的な国際機関が定めるデジュール規格ISO/IEC 10646と同期することで、WTO/TBT協定にもとづき世界中の国々に普及させられるメリットを得たこと。 また、Unicodeコンソーシアム自体はオープンな組織だけれど、意志決定を行うUTC（Unicode Technical Committee/Unicode技術委員会）で一票を投じる権利を持つのは一握りの団体に限られること。そしてUTCはISO/IEC 10646のアメリカ・ナショナルボディであるL2委員会と合同でしか開催されておらず、同時にL2委員会とUnicodeコンソー
なぜ呪文のような文字が表示されるのか？
インターネットでホームページを閲覧していたり，送られてきたメールを見ると文字化けしていることがある。このようなことが起こる原因はどこにあるのだろうか。 コンピュータを使っていると，必ずと言っていいほど「文字化け」という現象に遭遇する。インターネットでWebを閲覧している際に，呪文のような文字が並ぶ読めないページが表示されたり，同様に送られてきたメールが読めなかったりする経験が1度や2度はあるはずだ。これがいわゆる「文字化け」と呼ばれる現象である（図1）。 文字化けの原因の多くは，送信されてくる文字コードをソフトが正しく判別できていないところにある。ブラウザがページを文字化けして表示しても，ほとんどの場合は文字コードを正しく指定すればきちんと表示される。つまり，文字化けの主な原因は文字コードのとり違えと考えられる。 ところが，実際にはもっとたくさんの原因が存在している。なんとインターネット上
[ThinkIT] 第4回：Oracle Database 10gやMySQLで必要な対処 (1/4)
自社製品としてもERPを有し、世界の拠点で共通の基幹系にも使われるOracle Databaseは、Unicodeへの対応も早かった。今回話題のJIS X 0213:2004に対応するために必要なUnicode 3.2については、Oracle Database 10g以降での対応となっている。したがって、Vista環境で利用する際には、それ以降のバージョンを使う必要がある。 SQL Serverにもデータ型の先頭に「n」がつくものと、そうでないものがあったように、Oracle Databaseにもnvarchar2やncharといったデータ型が用意される。しかし「JIS X 0213:2004に対応する」という意味では、これらのデータ型を使う必要はない。 それは一般に用いられているcharやvarchar2といった「n」の付かないデータ型でも、Oracle Databaseの場合にはサロゲ
[ThinkIT] 第2回：Microsoft SQL Server 2005で必要な対処（前編） (1/3)
SQL Serverは早くからUnicodeに対応してきたデータベースの1つであり、SQL Server 2000ではUnicode 2.0に対応しているのでサロゲートペアを格納することができる。ただし前回も紹介したように「格納できる」のと「正しく扱える」のとでは意味合いが異なる。正しく扱えるのはUnicode 3.2をサポートしたSQL Server 2005からで、もちろんJIS X 0213:2004にも対応できる。 ところが対応できるというだけで、何もしなくて良いというのではない。これから何をしなければならないかを明らかにしていこう。 以前からSQL Serverを使ってきた方ならば承知していると思うが、SQL Serverには文字列を格納するためのデータ型が大きく2種類用意されている。1つはchar/varchar/textなど、先頭に「n」が付かないデータ型。もう1つはncha
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[ThinkIT] 第3回：Microsoft SQL Server 2005で必要な対処（後編） (1/3)