規格の読み方: 文字符号化blog
前の記事を書くために久しぶりに97JISを読んだのですが、ああ、やっぱりこれは1997年の規格なんだなということを感じました。 というのは、規格が書かれた当時の常識や技術的な背景というもの (それらの多くは現在でも通じるにしても) が、規格の文言の裏に透けて見えるわけです。 規格というのは、文面に書かれたものが全てであるかのように読み、それできちんと意味が通じるのが良いわけです。というのは、異なるベンダの実装者が別々に読んで実装したものが、きちんと相互運用できてほしいから。けれどもその一方で、書かれた文書はやはりその時代の産物であることは免れ得ない。してみると、深く理解しようとしたら、書かれた当時の事情を知るに如くはない。 時代背景や常識というものをまるっきり無視して、言葉尻だけをとらえてあげつらうのは、(規格の草案を練り直すときには有益かもしれないとしても) 現実世界への適用においてはあ
文字コード的に見たフォント設計の自由度: 文字符号化blog
JIS X 0208:1997の公開レビューがインターネットで行われていたのはご存じでしょうか。当時はFTPでレビュー資料をダウンロードする形態をとっていました。ネットニュース(fjニュースグループ)でお知らせが回っていたような覚えもあります。 レビュー資料のことはもうほとんど忘れてしまいましたが、FAQの中にイカした項目があったのは覚えています。たしか、低解像度のビットマップフォントなどで点画の省略をしても規格に適合するという話の後だったと思うのですが、 問: 1区1点から、区点位置をひとつずつずらして、「亜」の区点位置に「唖」の字形、「唖」の区点位置に「娃」、「娃」の位置に「阿」……として実装したフォントはこの規格に適合しますか? これなら、それぞれの文字は他のいかなる図形文字とも区別できますよ。 答:適合しません。区点位置に定義されている文字を想起できないからです。 なにぶん10年以
フォントの字体変更は文字コードの話題か?: 文字符号化blog
JIS X 0213:2004が (包摂の範囲内で) 例示字形を変更したために、この変更に追随して字体設計を変更するフォントがいくつかあるようです。「辻」のしんにょうが１点か2点か、というのはこのレベルの話です。さて、これは文字コードの話題でしょうか? 文字コードとは、文字とバイト表現との対応を規定するものです。あるバイト表現に対応する文字がどのような字体をとるかは、包摂の範囲内において、設計者の方針次第です。文字コードの問題ではありません。JIS X 0208/0213では、しんにょうの点が1点か2点かは、文字コードとして区別しないことが明記されています。 なので、「辻」のしんにょうの点の数の如き問題は、文字コードの話題ではありません。フォントの話です。文字コードについて雑誌記事などを書く人におかれては、是非こうした区別に敏感であってほしいと思います。 補足すると、字体変更が包摂規準の範
基本Unicodeか拡張Unicodeか、それが問題だ: 文字符号化blog
今はちょっと落ち着いたようですが、Windows VistaといわゆるJIS2004の対応で、いろいろと困った人もあったかも知れません。でも、困った事態になるのは、よく考えるとちょっと変な気がします。なぜなら、Windows はUnicodeに対応しているから世界中の文字を扱えるんだということになっていたはずなのに、JISで追加された文字を扱うのに何だって新たな対応が必要なのでしょうか? それを説明するためには「基本Unicode」と「拡張Unicode」という区分を導入し、これらを別の文字コードとして扱う必要があるように思います。 「基本Unicode」とは、当初計画された16ビットの範囲内のUnicodeです。Unicodeの基本多言語面(BMP)といってもいいですね。基本Unicodeの範囲内のUTF-8を「基本UTF-8」と称します。つまり最大3バイトの長さになります。同様に、「基
文字コードに対する3つのスタンス: 文字符号化blog
文字コードについての意見や議論は、その人の立場によって立脚点や基本的なものの見方がかなり異なっており、そのことが相互の理解を難しくしていると感じることがあります。 私が考える3つのスタンスを図に表してみました。それぞれのスタンスをステレオタイプ的に描画すると以下のようになります。 プログラミング系 文字コードをバイト値として扱うことに詳しい。文字コードがどのような特徴を持っていればプログラミングが楽になるかという観点が強い。一方、コード値に対応する文字そのものがどう定義されているかにはあまり興味がない。文字の定義は規格を決めた人がうまくやっているはずだと考えている。「Unicodeさえあれば良い」と考えがちなのもこのタイプ。 フォント・活字書体系 フォント設計の微細なところまで知りつくしている。文字コード規格の例示字形に詳しく、常人には区別のつかないわずかな違いも見逃さない。フォント技術に
Unicodeのうつわ: 文字符号化blog
画像のような文字列をUnicodeで符号化するとしたら、どのようなコードポイントの列になるでしょうか? JIS X 0213でいえば、1-20-79, 1-15-22 です。 日本人、あるいは日本向けのソフトウェアであれば、おそらく U+5668 U+FA38 というコードポイントを用いるでしょう。前者はJIS X 0208の20-79をソースとしており、後者はJIS X 0213で追加された字に相当するからです。ここには何も疑問がなさそうに思えます。 ところが、台湾の人、あるいは台湾向けのソフトウェアであれば、おそらく U+20F96 U+5668 というコードポイント列になるのではないかと思います。なぜか…って、だって、Unicodeの文字表を見ればそうなっているではないですか。ちなみにU+20F96は台湾ソースです。 おや、同じ文字列を同じUnicodeで符号化するのに、日本風のやり
UCSの包摂規準を明確化する試み: 文字符号化blog
漢字データベース計画の「UCSにおける包摂規準（α版）」が素晴しいです。JIS X 0213の包摂規準をベースにISO/IEC 10646 UCS (といわれてピンとこない人は、Unicodeのことだと思っていいです) の漢字集合の包摂規準に相当するものを作成しようという試みです。 これは、ISO/IEC 10646の規格の中に盛りこまれて然るべき内容であると思います。規格で規定されて、電子データの形でも入手できるようになれば、文字の入力や検索の際の役に立つことでしょう。こうしたデータが完備して初めてUnicodeは使いものになるのではないでしょうか。 それにしてもこれ、規格票を目で追って手作業で作っていたら死にそうになると思うのですが、どのように作業しているのかが興味深いところです。そこは "Kanji Database Project" だけに、きちんと作業インフラが整っているのでしょ
Unicode正規化の問題点(1): 文字符号化blog
「マイクロな話とオングストローム」の中で「正規化を行えば別ですが」と蛇足のように付け加えたのは私の勘違い、誤りでした。 というのは、Unicodeの正規化では実は、マイクロ記号はギリシャ文字μに正規化されないのでした。オングストローム記号は「上リング付きA」に正規化されるのに、です。 なぜこうなっているのかは不明ですが、邪推するに、ISO/IEC 8859-1を特別扱いしたかったからではないでしょうか。マイクロ記号が正規化でギリシャ文字μに変換されてしまうと、「8859-1 → Unicode → 正規化 → 8859-1」という変換を施したときに元に戻らなくなってしまうのです。それを避けるために、敢えて正規化対象から外したということではないでしょうか。 ちなみにJIS X 0208相当の文字では、上記のオングストローム記号が正規化の影響を受けるために、「JIS → Unicode → 正
MSゴシック・明朝v5.0の良いところ: 文字符号化blog
マイクロソフトのWebサイトでWindows XP向けにMSゴシックとMS明朝のv.5.0が配布されています。 このフォントの良いところは、U+301C (WAVE DASH)のグリフが普通の波ダッシュと同じ格好になっていることです。以前は、左端から右下に下がって右上に上りまた右下に下がって終わる形でしたが、v.5.0では、左端から右上に上がって右下に下がりまた右上に上がって終わる形に修正されています。別の言い方をすれば、Unicode仕様書のヘンな例示字形に沿った形でなく普通の形になったということです。 あとは、コード変換でJISの波ダッシュをU+FF5E (FULLWIDTH TILDE) に対応づけるWindowsのバグを修正してほしいですね。
カイダー字: 文字符号化blog
八重山諸島は竹富島で、「カイダー字 てぬぐい」なるものを買ってきました。 カイダー字というのは明治時代あたりまで使われていた象形文字 (?) で、取り引きや納税などに使われていたようです。買ってきた手ぬぐいは、そのカイダー字が染められているものです。 カイダー字がどういうものなのか、ウェブで調べても良い情報がありません。ざっと見た感じではUnicodeにも収録されていないようです。 竹富島の喜宝院というところにはカイダー字の資料があるそうですが、今回はそこまで訪問できませんでした。興味のある方は行ってみてください。
マイクロな話とオングストローム: 文字符号化blog
『JIS漢字辞典』増補改訂版の837ページにあるコラム「マイクロな話」は標準化の興味深い裏話です。 JIS X 0213ではISO/IEC 8859-1の文字を全部入れようとして、同規格にある「マイクロ記号」にも独立した区点位置を与えようとしました。それが公開レビューの結果、ギリシャ文字μと同一の文字ではないかという異論が出て、検討した結果「マイクロ記号」としての収録は見送られたという話です。 マイクロ記号としてμを書く際に特段の違いがあるわけではないので、賢明な判断といえるでしょう。UnicodeはISO/IEC 8859-1を特別扱いしてU+00A0からU+00FFにそのままコピーした結果、「マイクロ記号」とギリシャ文字μとが重複してしまっています。(このため、Unicodeを介してコード変換を行うと、8859-1のマイクロ記号がJISのギリシャ文字μと対応させられず、ある筈の文字が無
新しい符号化方式って何だろう: 文字符号化blog
「JIS X 0213の代表的な符号化方式」を更新しました。2004年改正に対応したときに2000年版の符号化方式名をすっぱり削ってしまったのを反省して、2000年版との対応を記しました。また、Unicodeを使う際の問題点を新たに付け加えました。 これを書いていて思ったこと。JIS X 0213対応を躊躇している人の言い分として、「いまさらUnicode以外の新たな符号化方式に対応するなんて…」ということを聞くことがあります。この「新たな符号化方式」という言葉には要注意だと思いました。 Shift_JIS-2004という「新たな符号化方式」に対応するには何が必要でしょう? 区点位置との計算が必要な場合には、確かに2面の分は新たな計算式を実装する必要があります。でも、それってそんなに難しいですか? EUC-JIS-2004への対応はどうか? 今までEUC-JPに対応していたのなら超楽勝です
機種依存文字やUnicodeに遠慮しなかったら日本語環境を改善できた: 文字符号化blog
Windows VistaのせいでにわかにJIS2004 (JIS X 0213) が注目を集めていますが、実のところ私は何年も前からEmacsやSKKなどでJIS X 0213の文字を自在に使っています。符号化方式には主にEUC-JISX0213、ときにはShift_JISX0213も使っています。これにより、「文字が足りない」といった不便を解消し、また便利な記号類を使うことで、日本語環境を改善できました。 世の中の大部分でJIS X 0213を使うことができなかった頃に、なぜそのようなことが可能だったのでしょうか。それは、機種依存文字やUnicodeに遠慮しなかったからにほかなりません。 JIS X 0213が制定された頃には、機種依存文字 (ベンダ定義の外字) との衝突が話題になっていました。批判者曰く、JIS X 0213は従来の「外字領域」 (本当はそんな領域は無い) を使ってい
「シフトJIS 2.0」でJIS2004を乗り切る: 文字符号化blog
Windows Vistaを契機に、Shift_JIS-2004の再評価が行われるのではないでしょうか。しない方がおかしい。 考えてもみてください。Unicodeでは、今まで漢字が2バイトで済んでいたのが、4バイトの漢字も出てくる。また、1文字を表すのに、結合文字を使って2つのコードポイントを使わなければならないケースも新たに出てくる。今までそんな想定はしていないから、困るわけです。 これがShift_JIS-2004だとどうか。全部「1文字 = 2バイト」で済むわけです。今までと変わりありません。どうみても、Shift_JIS-2004の方が扱いやすいわけです。 もちろん、今までの機種依存文字は文字化けします。ですが、忘れてはいけないのは、機種依存文字はこれまでも化けてきたし、いま現在も化けているし、たぶんこれからも化け続けるのです。いま現在も、というのは、Googleの検索結果やBlo
文字の同一性についてのはなし: 文字符号化blog
豊島先生の「コードのはなし: 追補」がいつのまにかウェブサイトから消えているようです。archive.orgに残っているので、今のうちにダウンロードしておかれると良いかと。 10年以上前の文章なので情報としては古いところがありますが、文字の同一性に関するくだりなどはいまだに古びていないことがうかがえます。洞察に富む文章です。
Unicodeの漢字の不整合: 文字符号化blog
Unicodeの漢字といえば、かつては「CJK統合漢字」が槍玉に上がったものです。統合すること自体を問題にする意見から、統合自体は是としながらもそのやり方に疑問を呈する意見まで様々でしたが、それらに確たる答えが提示されないまま、今や別の面からUnicodeの漢字は批判されています。 それは主に、似たような字が重複して入っている、あるいは同じと思われる文字、統合されるはずの文字が紛れ込んでいる、といったことです。 「PDFと文字（16) –漢字統合の破綻」では、実例を挙げて疑問を提示しています。ここで挙げている例を見て、あるいは「それは別の字だ」と主張される方があるかも知れませんが、同じなのか違う字なのか、判定する根拠 (JISの包接規準のような) が示されていないことがまさにUnicodeの問題だろうと私は思います。 「漢字データベースプロジェクト」では、上記のブログで提示されているような
文字符号化blog
このブログには今までASAHIネットのサービスを利用させていただいていましたが、こんど自分のサイトに引っ越すことにしました。今後は新サイトのブログに書いて、このブログは更新しない予定なので、RSSリーダ等でお読みの方はご注意ください。 新サイトでは文字コードの以外のことも含めた総合的な内容になるので、文字コードにしか興味のない方には少々申し訳ないのですが、いくつもブログを管理するのも手間だしひとつひとつのトピックにそれほど分量があるわけではないので、このさい統合したいと思った次第です。 どうぞ、新サイトもよろしくお願いします。 iPhone/iPod Touch用の「大辞林」などを販売している「物書堂」。ロゴを見ると、四角の中に「書」という字が入った格好をしています。 これは製作側の意図としてはたぶん「四角の中に『書』」なのでしょうが、「くにがまえに『書』」という1文字の漢字のようにも見え
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ISOが無料でダウンロードできるサイト: 文字符号化blog