簡単なのにひどく面倒な「者」という字について - 楷書活字
正月明けからもう３週間、どうにも更新ができなかったのは、「者」が難しすぎたため。 小学校３年で習うこの字が、なぜにそんなに難しいのか。意味は皆さんよくご存知の筈。 音は「シャ」、訓は「もの」。どちらにしても言葉の後ろについて、「（〇〇のような、〇〇をする）人」を示す。 『千字文』では996番目の字で「謂語助者焉哉乎也」（語助と謂ふ者、焉哉乎也）、「ものは」乃至単に「は」と訓ずる。 この字を草書からさらに崩して、「は」という仮名（変体仮名）ができた。 現代の感覚では「物」に対して「者」は、「もの」と訓ずるうちの「人」の方を表すというイメージで捉えられる。 ところが、もう一つ「人」そのものと比べた場合、少々変わってくる。 悪者と悪人、これはほとんど同じか。医者とは言うが医人とは言わない。易者も。各者と各人、後の方がよく使う。学者、人は付かないが、大学者と大学人だと意味が違う。芸者と芸人では職種
改行を含むTSVファイルを使ってデータ結合を行う方法(UTF-16出力、串刺し印刷対応版) - 文書遊戯
昨日アップしたPerlスクリプト、UTF-16出力での文字化けを回避する方法を「ひらくん」に教えていただきました。 感謝！感謝！です。 UTF-16出力の修正を加えたついでに、串刺し印刷対応のための機能拡張を行いました。データ結合で１ページに複数レコードを割り付ける場合、串刺し印刷になるようレコードを並べ替えたいことがしばしばあります。下記のスクリプトを使えば、-mオプションで面付け数を指定することにより、串刺し印刷のためにレコードを並べ替えてくれます。 【入力ファイル】 Excelで作った下記のようなレコード形式のデータを、Unicodeテキストで保存したもの 表ヘッダ1 表ヘッダ2 表ヘッダ3 行1列1データ 行1列2データ 行1列3データ 行2列1データ 行2列2データ 行2列3データ 行3列1データ 行3列2データ 行3列3データ 注意：１行目は必ずヘッダ行にしてください。 【実行
それを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と呼ぶわけです。 ただ
絵文字が開いてしまった「パンドラの箱」第3回--Unicode提案の限界とメリット
前回までを振り返る--Unicodeコンソーシアムの影響力 前回はどこまでお話ししましたっけ。世界中の文字の収録を目的とした文字コード規格、Unicodeは、米国のIT企業を中心に結成されたUnicodeコンソーシアムが制定するデファクト規格に過ぎないこと。しかし公的な国際機関が定めるデジュール規格ISO/IEC 10646と同期することで、WTO/TBT協定にもとづき世界中の国々に普及させられるメリットを得たこと。 また、Unicodeコンソーシアム自体はオープンな組織だけれど、意志決定を行うUTC（Unicode Technical Committee/Unicode技術委員会）で一票を投じる権利を持つのは一握りの団体に限られること。そしてUTCはISO/IEC 10646のアメリカ・ナショナルボディであるL2委員会と合同でしか開催されておらず、同時にL2委員会とUnicodeコンソー
ディザInDesignブログ: 漢数字は漢字と別コードがあったほうが便利？
漢数字は漢字と別コードがあったほうが便利？ 漢数字の定義とは何ぞや？ と聞かれても明確な定義があるのだろうか。「漢数字とは」とGoogleで検索するとWikipediaその他で解説があるが、印刷業界ではちょっと違うような気がする。 一般に言われる漢数字 数を表す漢字その1：一、二、三、十、百、千、万、億、兆、京、など 数を表す漢字その2：零、壱、弐、参、伍、拾、仟、萬、など 数を表す漢字その3：廿、卅、など？ 数を表す漢字？：〇 一方、印刷・出版業界では、というのは言い過ぎか。ともかく、このブログのエントリで使っている「漢数字」とは（ややこしいので以降【漢数字】と表記します）、Wikipediaでは「位取り記数法」と記述されているものに近い。それは、アラビア数字を主体とした数値の表記方法を縦書きで表記するために、「0123456789,.」と一対一で対応する文字の集合である。 それ
MySQLの"UTF-8"にご用心 - yanok.net
拙著『プログラマのための文字コード技術入門』にも一言だけ書いたのですが、オープンソースのデータベース管理システムとして有名なMySQLのバージョン5.0とか5.1とかは、UTF-8として3バイトまでしか対応していません。 これは今どき考えられないくらい古い仕様です。3バイトのUTF-8というのは、Unicodeの基本多言語面(BMP) という、16ビット固定で世界中の文字を符号化するんだと(誤って)言い張っていた、古き良き時代のUnicodeの範囲しか扱えません。 MySQLの5.5.3というバージョンではようやく4バイトのUTF-8への対応が図られたようです。5.5.3の変更点を記したページに記されています。 これを使えば、魚の名前の𩸽(ほっけ、U+29E3D)だとか、偏旁の𧾷(足偏、U+27FB7)だとか、あるいは日本の地名として𣖔木作(ほうのきざく、福島県)の「𣖔」(U+23
文字コードはなぜ複雑になるのか – ものかの
プログラマのための文字コード技術入門 の第１章に「文字コードはなぜ複雑になるのか」という節があります。そこには「過去の経験の積み重ね」「文字そのものの難しさ」の２つが挙げられています。もちろんその通りなのですが、私が常々感じている「もうひとつの文字コードの複雑さ」があるのでメモしておきます。 ここに２種類のＡとＢいう特殊な考え方があるとします。この２つには以下の性質があります。 ・Ａを理解するには、前もって別の特殊な考え方Ｂを知っていなければいけない。 ・Ｂを理解するには、前もって別の特殊な考え方Ａを知っていなければいけない。 文字コードは人間が考えた特殊な考え方の集まりです。しかしそれは整然とした重層的な体系ではなく、このように各々の考え方がお互いにその前提になっていたりします。(1 (2 相互に依存したＡとＢを同時に知ることはできません。はじめは「なんとなくＡのようなもの」に触れるしか
Unicode正規化
正しい並び替えでは、表示は(A)のままですが、間違った並び替えでは、正規結合クラスが互いに等しいMACRONとACUTEを並び替えたため、表示は(B)のように、eの上のアクセント記号の位置が入れ替わってしまいます。 正規分解・互換分解 ある文字列の正規分解 (Canonical Decomposition) を得るには、まず、それぞれの文字を正規マッピングによって再帰的に、可能な限り、分解します。すなわち、1回分解した後に現れた文字がなおも分解可能であればさらに分解します。分解マッピングがその文字自身である場合は、分解不可能なので、そのままです。 しかし、分解しただけでは必ずしも正しい結果が得られません。つまり、結合文字の順序の一意性を保証するため、分解後の文字列に対して正規順序アルゴリズムを適用しなければなりません。このように、正規マッピングによる再帰的分解と、正規順序アルゴリズムによ
“情報化時代”に追いつけるか？ 審議が進む「新常用漢字表（仮）」： 第2部 新常用漢字表と文字コード規格第5回 なぜUnicode正規化は生まれたか
● 互換用文字は、存在するはずのなかった文字 前回までは互換漢字が追加提案しにくくなっている現状について述べた。規格の上から互換用文字／互換漢字といった文字がどのように考えられているかは、次のUnicode規格書の一文に明らかだ。 Conceptually, compatibility characters are those that would not have been encoded except for compatibility and round-trip convertibility with other standards.（概念上からは、互換用文字とは他の規格との互換性及び往復の保全性の目的以外には、符号化されるはずのなかった文字である。） 『Unicode Standard 5.0』2.3 Compatibility Characters（http://www.uni
InDesign CS3にCJK互換漢字をペーストしたときの文字化け - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
InDesign CSには、「エディタなどからクリップボード経由で標準テキストをペーストすると、互換漢字が統合漢字に化けてしまう」というバグ（またはタコな仕様）があった。これは、InDesign CS2で修正された。 ところがInDesign CS3では、以前の仕様にもどってしまっている。下図は、左上のウインドウ（Jedit Xの標準テキスト・モード）のCJK互換漢字をコピーし、右下のウインドウ（InDesign CS3）にペーストしたもの。 これらの互換漢字と統合漢字はUnicode的には正規等価（canonical equivalent）であるから正規化（統合漢字に統一）されても仕方がないという理屈も世の中にはないではないのだが、日本語ユーザにとって互換漢字は数多くの人名用漢字を含むものであり、それを無言で「正規化」するような振る舞いが（特にDTP用のアプリケーションでは）危険であるこ
漢字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刑事〔デカ〕リターンズ
InD-Boardで出ていた「複数行にまたがる括弧」の話が興味深かったので、ちょっと調べてみた。皆さんの指摘に付け加えるような知見はないのだけれど、以下、文字コード的な雑談として。 Unicodeには、複数行にまたがる丸括弧、角括弧、波括弧がある（下図）。このうち2文字で作る波括弧は、左上と右下、左下と右上のパーツが共通なので、文字数としては、ここまでで16文字。 これらの括弧には、拡張用の直線パーツ（下図、グレー地）が用意されている。丸括弧用と角括弧用はそれぞれ左右別々、波括弧用のみ左右共通で、文字数としては5文字。しかしAdobe-Japan1では、これら5文字がすべてCID+12167に集約されており、区別してデザインすることができない。 下図は小塚明朝。角括弧の拡張はうまくいっているが、丸括弧と波括弧は直線部分がズレている。また、2文字分の波括弧のパーツは、おそらく左右共用ではなく
なぜUnicodeには分数の「0/3」が入っているのか - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
Adobe-Japan1の分数は（特にUnicodeとの関係において）けっこうぐしゃぐしゃなので、ちょっと整理してみよう。下図は、横棒を使う分数のリスト*1。Proフォントでは「分数（afrc）」フィーチャで用いられる。分母が2から12までの約分できない真分数と「0/3」と「1/100」。 上図と同じ字種について、数字を斜めに配置するグリフも用意されている（下図）。これらはProフォントでは「スラッシュを用いる分数（frac）」フィーチャで用いられる*2。 上図のグリフはすべて全角だが、斜めに配置する分数の一部には、プロポーショナル・グリフも用意されている（下図）。 下図は、Unicodeに含まれる分数を、Mac OS Xの文字ビューアからInDesignに入力したもの。Adobe-Japan1ではプロポーショナル（黄色地）優先のマッピングであるため、「2/5」などの全角グリフ（グレー地）
なぜ全角ダッシュは欧文約物形状になったのか - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
あさうすさん（実験る〜む）の「和文としてのダーシが変」を読んで、Adobe-Japan1フォントの全角ダッシュが和文約物形状ではなく欧文約物形状で表示される理由について考えてみた。このエントリでは、JIS X 0208の1区29点「ダッシュ（全角）」を「全角ダッシュ」と呼ぶこととする。 昔は、全角ダッシュの実装グリフは和文約物形状だった。今ではたいていの場合、欧文約物形状。どちらになるかは、「文字コードがUnicodeか否か」による。たとえば小塚明朝Pr6Nのような新しいフォントでも、Shift-JISアプリでは全角ダッシュは和文約物となる。また、（試していないけれど）CIDフォントでもUnicodeアプリでは全角ダッシュは欧文約物となるはず。 Shift-JISとUnicodeでグリフが変わるのは、全角ダッシュだけではない。たとえば、セント記号について見てみよう。JIS X 0208は、
InDesign CS4におけるIVSとOpenTypeタグのあやしい関係 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
InDesign CS4はUnicodeのIVS（異体字シーケンス）をサポートしている。IVSは、親字に続けてU+E0100などの特殊な文字（異体字セレクタ）を入力することで、たとえば下図のようにグリフを指定するメカニズムである。 同様のグリフ指定は、もちろんOpenTypeタグでも可能である（下図）。 では、1つの文字にIVSとOpenTypeタグで競合する指定を行ったらどうなるのだろう。U+990C「餌」を例として試してみた結果が、下図。横軸がIVS、縦軸がOpenTypeタグ。IVSの指定が顕在化しているものを青地、OpenTypeタグの指定が顕在化しているものを緑地で示した。白地は両者の指定が一致しているもの。 この例では、異体字セレクタがU+E0101またはU+E0102ならIVS優先、そうでなければOpenTypeタグ優先、というように見える。しかしInDesign CS4は、
ダブルミニュートにご注意 - なんでやねんDTP・新館
※文字そのもののユニコード位置は正確には情報パレットのモノを参照する必要があるが、この記事の一部のユニコード表記は字形パレットを参照したため正確さに欠ける。（100320追記） タテ組の本文をテキストデータで支給される場合、最終的にはダブルミニュート（いわゆる「ちょんちょん」）にしなければならない部分にUnicodeの201C（Shift-JISの8167）/201D（8168）を入力してある場合と301D（8854/8780）/301F（8855/8781）を入力してある場合がある。 ご存知の方も多いと思うが、これがちょっとややこしいことになっている。 これらを入力したものを並べてみた。 3つめはShift-JISの8780と8781である（これも301D/301Fになる）。 ご覧のようにモリサワのPro書体やマティスなどUnicode3.0準拠の比較的古い書体は201C/201Dもダブ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
人名などの異体字もデータ交換可能に、MSなどが「IVS技術促進協議会」発足 
サービス終了のお知らせ
Adobe Community