Mewでメールを送るときに第3・第4水準漢字があったらUTF-8にする - yanok.net
電子メールはISO-2022-JPで符号化するというのが、インターネットで日本語をやり取りするようになってから長く続いてきた習慣でした。しかしISO-2022-JPでは使える文字が限られていて、問題があります。現代日本の文字にちゃんと対応するには、JIS X 0213の文字に対応する必要があるのです。 で、細かい背景や議論は拙著『プログラマのための文字コード技術入門』の第6章を参照していただきたいのですが、結論からいうと、ASCII + JIS X 0208の組み合わせで済む場合はISO-2022-JPで、それを超える範囲の文字(JIS第3・第4水準とか)を含む場合にはUTF-8を使う、というのが、最も受け入れられやすそうに考えられます。異論もあるかもしれませんが、ここではそういうことにしておきます。 この方針は、Emacs上のメーラのMewで実現できます。Emacsでは既にJIS X 0
IVSは文字コードではない - yanok.net
IVSを使うと、常用漢字体の「与」は以下の異なる符号化表現で表し得ます。 U+4E0E U+E0100 U+4E0E U+E0102 U+4E0E (※通常の日本語環境では上2つと同じように見える筈。中国語環境などでは異なる) これが何を意味するかというと、画面上で同じ「与」という漢字が見えていても、その背後にある符号化表現は上の3つのいずれでもあり得るわけです。これがどのような不都合をもたらすかはいうまでもないでしょう。 文字コードというものは、文字を一意に符号化するものです。しかしIVSでは一意に符号化することは最初から考えられていないようです。つまり、IVSは文字コードではありません。 文字コードでないものをUnicodeのレベルで扱うのが適切なのか、再考を要するかもしれません。たとえばルビタグや言語タグのような文字コードでないものがUnicodeにはあって、こういうのはXMLなどで
それをIVSと呼ぶのか - yanok.net
Unicodeの「IVS」というものの普及を目指す協議会が設立されたというニュースが出ていました。例えば、ITmedia Newsの「「書き手と読み手の字体の一致」を保証する「IVS」普及へ、MSやアドビなど協力」などの記事があります。 内容以前に気になったのが、IVS という用語の使い方。Ideographic Variation Sequenceという名のとおり、これはsequenceを表す言葉です。どういうsequenceなのかというと、UnicodeのCJK統合漢字の後ろにU+E0100のような符号位置 (variation selector) を付けたものです。これによって漢字の異体字 (とひとまず呼んでおくが、異体字というより活字のデザイン差程度のものが多い) を示すものです。 つまり例えば 「U+4E08 U+E0100」 のような列のことを本来はIVSと呼ぶわけです。 ただ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
yanok.net: 検索結果
