文字コード【超】研究
おたよりコーナー 2
ホームに戻る [0]
おことわり
「おたよりコーナー」の増設ぶんです。以下は同じ断り書きです。
本コーナーではメールで寄せられた質問に可能な限りお答えします。
ただし、メールで直接答えた方がいい場合や、
明らかに単純なこちらのミスで正誤表で対応した方がいい場合はそのようにします。
また、必ずしもお答えを約束することもできませんのでご了承ください。
また、質問ではなくこちらの知らないことをご教示いただいた場合で、
本書の内容を越えるなどの理由で正誤表で対応しないものも、以下に掲載します。
ご教示くださった方には、この場を借りてお礼申し上げます。
2003/11/3 追記
直接メールでいただいたご質問／ご意見の他に、別の Web サイトで本書の記述に何らかのご意見をいただいた場合も、下記に掲載いたします。これもこの場を借りてお礼申し上げます。
目次
2003/08/27 MI さんからのお便り
フランス語とスペイン語のファイルがまぜこぜになっていっぱいあります。
これを見比べる方法はないでしょうか。
これはこれは筆者の同僚の I 君からのおたよりですね。
新婚生活はいかがでしょうか。（大きなお世話・・・）
要は、各国語で使用する特殊記号が違うので、
その国でのみ使用する特殊記号を数えれば類推できないでしょうか。
とすると、下のページが参考になります。
フランス語・ドイツ語・スペイン語ホームページの書き方（Yoshi Mikami さん）
実体参照を使っている場合は、
¿ や ¿ が入っていれば逆疑問符だからスペイン語、
とわかるんですが、
文字コードを直値で入れている場合は、
10進の191は16進ではBFなので、
（Perl で）\xBF が入っていればスペイン語、と思えばいいんじゃないでしょうか。
同様に、セディーユ（文字の下のヒゲ）つきの c は
実体参照では ç または ç、
文字直値では（Perl で）\xe7 ですので、これがみつかればフランス語。
以上の原理を元にというスクリプトを作ってみました。
使い方は
% sorf 対象ファイル
です。
#! perl -w
# sorf -- スペイン語かフランス語か？
undef $/;
$_ = <>;
$french = $spanish = 0;
++$french while s|\à\;||;
++$french while s|\â\;||;
++$french while s|\ë\;||;
++$french while s|\ç\;||;
++$french while s|\&\#224\;||;
++$french while s|\&\#226\;||;
++$french while s|\&\#235\;||;
++$french while s|\&\#231\;||;
++$french while s|\xe0||;
++$french while s|\xe1||;
++$french while s|\xe2||;
++$french while s|\xeb||;
++$french while s|\xe7||;
++$spanish while s|\Ñ\;||;
++$spanish while s|\ñ\;||;
++$spanish while s|\&Eaccute\;||;
++$spanish while s|\ü\;||;
++$spanish while s|\¿||;
++$spanish while s|\¡\;||;
++$spanish while s|\&\#209\;||;
++$spanish while s|\&\#241\;||;
++$spanish while s|\&\#201\;||;
++$spanish while s|\&\#252\;||;
++$spanish while s|\&\#191\;||;
++$spanish while s|\&\#161\;||;
++$spanish while s|\xd1||;
++$spanish while s|\xf1||;
++$spanish while s|\xe1||;
++$spanish while s|\xc9||;
++$spanish while s|\xfc||;
++$spanish while s|\xbf||;
++$spanish while s|\xa1||;
print "$ARGV contains $french french characters and $spanish spanish characters\n"
みるからにしょうもないスクリプトですが解説します。
このスクリプトは
% sorf ファイル名
のように引数にファイルを得ます。
undef $/;
$_ = <>;
のようにすると行区切り文字 $/ が無効になりますので、
規定のスカラー $_ にファイル全体の内容がどばーんと入ります。
$french = $spanish = 0;
はフランス、スペインの固有文字を数えるエリアをクリアします。
++$french while s|\à\;||;
はよくあるテです。
ここでは＆agrave；という文字列を「無」に置換しながら（つまり削除しながら）
１回置換するごとに $french をインクリメントしています。
s|〜|〜|g; では検索の開始位置によってうまくいかない場合があるんですが、
これだと徹底的に置換できます。
print "$ARGV contains $french french characters and $spanish spanish characters\n"
では回答を表示しています。
たとえば merci というファイルに 10 個のフランス固有文字と
0 個のスペイン固有文字があるとすれば、
merci contains 10 french characters and 0 spanish characters.
と表示します。ここで $ARGV は引数として渡されたファイル名を保持します。
大量のファイルにいかに適用するかなどの課題はおまかせします。
実運用に耐えたかどうか連絡ください。
2003/09/05 NA さんからのお便り
use Encode::Guess qw/euc-jp euc-kr/;
としたら、EUC コードどうしで、文字コードの判定が
可能なのだろうか？ と疑問に思いました。
で、perldoc でドキュメントを読んでいたら、
UTF-8 に変換できるかどうかを一つ一つ試している、とあったので、
一つ実験してみました。
単純にハングルだけのeuc-krファイルだと、
当然ながら euc-kr か euc-jp か判定できません。
実際、Encode::Guess でも判定できません。
しかし、ωψ(ギリシア文字の小文字のオメガとプシー)を
euc-krで保存したファイルだと、ちゃんとeuc-krだと
判定してくれました。
これは、
ω...0xa5f8(つまり5区88点)
ψ...0xa5f7(つまり5区87点)
がeuc-kr(ksx1001)にあってeuc-jp(jisx0208)にないコードポイント
だから、utf-8への変換に成功するかどうか、で判定できるようです。
おもしろいご報告ありがとうございます。
ちなみに半角カナが入っていると一発で EUC-JP と分かります ;;;
2003/10/25 NN さんからのお便り
「区点」の英語表記についてP338のJIS X 0208の説明では (ward, cell)、P458では (row, cell)と書かれていますが、使い分けはあるのでしょうか？
執筆時の経緯としては、wardはLunde著、オライリー『CJKV』に習ったもので、rowはUnicode規格票に習ったものですが、その後自分でもJIS X 0208規格票を紐解いて見ますと、なんとそちらでも「区」はrowとなっていました。（芝野編著、日本規格協会刊『改定増補 JIS漢字字典』）
ちなみに英語の辞書を引くとwardは「区」、rowは「列」またはコンピューター用語での「行」となっています。
わたしとしてはExcel（これもたぶん、Extended Cellという意味とexcellentという意味のしゃれですよね）などの表計算ソフトや、その元になった行列理論から、cellとはrowとcolumnの交わるところである、という認識があったのですが、一方「row」の訳語は「行」であるという認識も強くあり、なるべく多くの用語／概念を盛り込むという本書の意図として「ward」という言葉を紹介したいという気持ちもあったので、どっちつかずになってしまいました。
いま、改めて『CJKV』を当たると（会社には原書しかないのですが）「Row-Cell is the translated form of the Japanese word 区点（kuten）, which literally means "ward [and] point" (or, more intuitively, "row [and] cell").」（深沢摂訳：Row-Cellは日本語の述語「区点」（くてん）の翻訳で、直訳の意味としては"ward[および]point"（もっと直感的には「row[および]cell」）である。）と書かれています。これはLundeさんが欧米の読者向けに日本ではcellのことをwardという意味の区という文字を使っているよ、と説明しているということですね。（ちなみに同じ箇所の脚注に「中国語では区位（クウェイ）、韓国語では行列（행렬、ヘンヨル）と言っている」と書かれています。）
ということで、rowに統一すべきだと思い、正誤表で対応しました。ご指摘ありがとうございます。
（ちなみにハングルは<span lang="ko">행렬</span>と書いています）
安岡孝一先生のWebでご指摘をいただきました。
おことわり：
本項はここまでと違い、筆者に直接お便りをいただいたわけではなく、Webサイトで本書の記述に言及してくださったのに対してお返事をするものです。当該ページは安岡孝一先生のWebサイト内の記事「ASCIIの誕生」です。
(追記6) 『文字コード「超」研究』は、初版第1刷[18]において
歴史上最初にASCIIが使われたのはコンピューターではなく、テレタイプ(teletype)と呼ばれる文字通信においてでした。 …(中略)… テレタイプはキーボードで押された文字を符号化して送信し、復号化して印字する仕組みです。当然可能な限り少ないビット数で1文字を送りたくなります。当時の劣悪で低速な通信回線を考えるとなおさらです。最初に考え出されたコード系は1文字5ビットだったそうですが、紆余曲折の末、現在の7ビットのASCIIに落ち着きます。
とする(pp.234-235)が、この記述は不正確である。確かに『Teletype Model 11』から『Teletype Model 32』に至るテレタイプは、Donald Murray由来の5ビットコード(「テレックスの誕生とITA2」参照)を搭載していた[19,20]が、そのこととX3.2委員会における文字コード開発に、直接の関係はない。また、1963年5月発表の『Teletype Model 33』に搭載されていたのは、1963年時点でのASCIIであり、英小文字も含まれておらず、現在のASCIIとは異なる[3,20,21]。その意味では、テレタイプがほぼ「現在の7ビットのASCIIに落ち着」いたのは、1967年8月発表の『Teletype Model 37』ということになる[13,22]。しかしながら、1964年4月発表のIBM SYSTEM/360 [23]は、英小文字入りASCII(正確にはISO/TC97の7ビットコード第3次案[9])を入出力用の文字コードの1つとして採用しており[24]、これは『Teletype Model 37』の3年も前である。
執筆時の意図としては以下の通りです。
- ASCIIはコンピューターの開発よりも前にテレタイプで使われた
- テレタイプは現在の7ビットASCIIより前に5ビットコードを使っていた
これに対する安岡先生のご指摘は以下の通りです。
- テレタイプで使われていた5ビットコードはASCIIの先祖ではない
- テレタイプが最初に使ったASCIIは英小文字がないなど、現在のASCIIとは異なる
- 現在と同じ英小文字入りASCIIは、テレタイプで使われるよりも前に、コンピューター（IBM SYSTEM/360）で使われている
ということで、著者としては本書の記述が不正確であったことを認め、以下のようにp.234からのASCIIの項を以下のように改めます。
ASCII
文字コードの歴史をどこまでさかのぼるかは難しい問題です。なんならモールス信号（SOSはトトトツーツーツートトト）や手旗信号にルーツを求めることもできるでしょう。このように、文字を符号化して伝え、受信した符号を文字に復号化するというアイディアは、コンピューター以前に通信用にすでに存在していました。
文字コードを使った通信の仕組みとして、現在のコンピューターや文字コードの成立にも非常に寄与したものとしてテレタイプ（teletype）があります。テレタイプはプリンターつきのキーボード、つまり電気タイプライターのようなもので、ただキーボードとプリンターの間にアメリカ大陸を横断する電線が挟まっている仕組みです。これによってアメリカの新聞記者やビジネスマンは文書をパチパチ送りました。アメリカではテレタイプがあったためファクシミリの普及が日本より遅れたそうです。
（「NOTE」を略）
テレタイプはキーボードで押された文字を符号化して送信し、受信側で復号化して印字する仕組みです。当然可能な限り少ないビット数で1文字を送りたくなります。当時の劣悪で低速な通信回線を考えるとなおさらです。ということでテレタイプ用に最初に考え出されたコード系は1文字5ビットだったそうです。
しかし、現在のコンピューターにつながる流れでいうと、やはりそのルーツはASCII（アスキー）ということになります。これはAmerican Standard Code for Information Interchange（アメリカの情報交換用符号）ということで、最初から情報交換のためのコード、つまり外部コードとして考えられたことが分かります。しかしながら、IBM System 360のような汎用コンピューターや、Apple、コモドールC-64、IBM-PCなどの初期のパソコンで内部コードとして爆発的に使われ、標準の文字コードの地位を確立しました。
（「メモ」を略）
ASCIIはアメリカの文字コード標準化委員会X3.2が策定したものです。最初は6ビットコードも構想されたそうですが、結局は7ビットコードとして1963年にまとまりました。ただし当時のASCIIは英小文字がないなど、今のASCIIとは大きく異なります。その後1967年に改訂が行われ、その後は現在まで同じ形で使われつづけています。
メモ：本項の記述について、安岡孝一先生のWebコンテンツ「ASCIIの誕生（http://kanji.zinbun.kyoto-u.ac.jp/~yasuoka/publications/ASCII.html）」から本書第1刷に対するご指摘をいただき、サイトの内容に沿って書き直しを行いました。より詳細な内容は当該ページをご参照ください。
ASCIIは7ビットということで、128のコードを符号化できますが、このうちの32文字ぶんを制御文字用、96文字ぶんを図形文字コード用にしています。この制御文字は上記のテレタイプ装置を制御するためのものが数多く規定され、現在は有名無実になっているものも多くあります（第8章を参照）。また、図形文字96文字のうち1文字は空白、1文字は削除（いまはあまり使いません）ということで、実際には94文字を図形文字に割り当てています。
アメリカ用の文字なので、英語を書くことを目的に考えられています。また$記号はありますが、￥記号はありません。しかしながら、ASCIIは今もあらゆるコンピューターの基本となる文字コード系で、ほとんどすべてのコンピューター／OSがASCIIだけは表示を保証するように作られています。
以下はお礼です。ここにこのように書くのが適切かわかりませんが、文字コード研究の泰斗として私淑し、その著書を通じて拙著「文字コード【超】研究」の成立にも多大なご教示をいただいた安岡先生が拙著をご笑覧くださり、不正確な記述にご指摘をいただいたことは、汗顔の至りであると共に光栄の至りです。この場を借りて深くお礼申し上げます。誠にありがとうございました。
2004/01/08 DS さんからのお便り
こんにちは。
「文字コード超研究」大変に活用させていただいております。
ありがとうございます。
さて、表題の件ですが、Shift_JIS の n バイト目を渡された場合に、その種別を判別するロジックが 406 ページ（初版第 1 刷の場合です）に記載されています。そのうち箇条書きの 2 つ目以降について質問があります。
- 2 項めの「n バイト目が 0x81〜」ですが、この中には 2 バイト文字の 1 バイト目にも 2 バイト目にもなれる値が含まれているので、2 項めの条件は成り立たないのではないでしょうか？
- 3 項めの「n バイト目が 0xa0〜」についても、2 バイト文字の 2 バイト目にもなりうるので、半角カナとはすぐには判断できないのではないでしょうか。
- 3 項め、「n バイト目が 0x20〜」ですが、図 17.2 では 0x20〜0x3f は 2 バイト目としては未使用とのことですので、これは常に ASCII とみなせ、判断が必要となるのは 0x40 以降の値ではないでしょうか。
- 図 17.2 において、C0 制御文字が 2 バイトめであってもそのまま C0 制御文字として機能するように読めますが、そうなのでしょうか。未使用ではないのでしょうか。
以上、こちらの読解不足であさっての方向を向いた指摘かもしれませんが、確認をお願いしたくメールを差し上げた次第です。よろしくお願いします。
お便りありがとうございます。すべてご指摘のとおりです。以下、インラインコメントをお読みください。
- 2 項めの「n バイト目が 0x81〜」ですが、この中には 2 バイト文字の 1 バイト目にも 2 バイト目にもなれる値が含まれているので、2 項めの条件は成り立たないのではないでしょうか？
原文を要約して引きます。
（Shift_JIS ファイル中の任意の n バイト目をポンと渡された場合、）
- n バイト目が 0x81〜0x9f、0xe0〜0xef だったら、n、n＋1 バイト目で JIS 基本漢字
これなんですが、おっしゃるとおり、この範囲は Shift_JIS 2 バイト文字の 1 バイト目にも 2 バイト目にもなれるので判別できません。勘違いです。申し訳ありません。
しかもこの場合、１バイト前を見ても後ろを見てもダメですね。
具体的に言うと、いわゆる「全角ローマ字」の a を 3 つならべたもの、
ａａａ
は 0x8281 8281 8281 ですが、それに対して、いわゆる「全角」の「ノットイコール」記号を同様に並べると、
≠≠≠
となり、これは 0x8182 8182 8182 ですね。
とすると、n バイト目が 0x81 で、その前後が両方 0x82 だった場合、n バイト目は ａ の後半か、≠ の前半かこのロジックでは判断不能です。
やはり途中のあるバイトがどうこう、というのは無理筋で、Shift_JIS の利点はあくまで１バイト目で文字種を即座に判定できるところなので、ファイルの先頭からなめていってここで JIS 漢字に変わった、ここでアスキーに変わった、という処理を行なうのが正しいようです。
このページの改訂版をあとにお載せします。
- 3 項めの「n バイト目が 0xa0〜」についても、2 バイト文字の 2 バイト目にもなりうるので、半角カナとはすぐには判断できないのではないでしょうか。
同様で、おっしゃるとおりです。
- 3 項め、「n バイト目が 0x20〜」ですが、図 17.2 では 0x20〜0x3f は 2 バイト目としては未使用とのことですので、これは常に ASCII とみなせ、判断が必要となるのは 0x40 以降の値ではないでしょうか。
これもその通りです。多くの文字コードで ASCII 部分は聖域になっていますね。これは UTF-8 でも同様です。
図 17.2 において、C0 制御文字が 2 バイトめであってもそのまま C0 制御文字として機能するように読めますが、そうなのでしょうか。未使用ではないのでしょうか。
その通りです。えっと、Shift_JIS 2 バイト文字の 2 バイト目にあたる位置に C0 制御文字が何らかの事情で来てしまっていても、それは C0 制御文字として働きますが、そのような字は Shift_JIS 2 バイト文字ではないので（文字化けすると思われる）、ここはやはりおっしゃるように未使用（不使用）が正解です。
ということで、406 ページ「Shift_JIS は非モード式で・・・」以降を改稿したものをここにお届けします。ありがとうございました。
Shift_JIS は非モード式で各文字が 1 バイト／2 バイトの可変長ですが、先頭からデータを 1 バイトずつなめていくと次のようにして文字種を判定できます。
- 0x00〜0x1f だったらそのバイトだけで C0 制御文字
- 0x20〜0x7f が出てきたらそのバイトだけで半角英数字
- 0x81〜0x9f、0xe0〜0xef が出てきたらそのバイトと次のバイトで JIS 基本漢字
- 0xa0〜0xdf が出てきたらそのバイトだけで半角カナ
このようにシフトコードやエスケープシーケンスを使うことなしに文字種の判別ができます。
Shift_JIS の制限としては、JIS X 0212 拡張漢字をサポートしていないこと、C1 制御文字がないことがあります。もっとも、C1 制御文字は ESC + 0x40〜0x5f の 2 バイトで使えますし、JIS X 0212 は Shift_JIS ができたときにはまだなかったのでしょうがないですね。
ただし、ASCII と JIS 漢字の 2 バイト目が使用するコード領域がダブっているのは問題があります。本章の第 3 項で研究します。
なお、p.404 図 17.2 は以下のように改訂します。
2004/01/18 MS さんからのお便り
471ページの表に「0x00200000〜0x03ffffff」として「JIS X 0213の追加漢字の一部、他」という記述があります。
また、505 ページのなかほどに「ここまでがUTF-8では4バイトの文字です。これ以降はすべて 5 バイトで表現されます。」なる記述があります。
残念ながら、これは間違いです。
同じ 505 ページには、「CJK 統合漢字拡張 B」のコード範囲として「20000..2A6DF」という記述があります。これはあっています。これと、471ページの表を比べていただくと、わかりますが、「一桁ずれています」。
つまり、「CJK 統合漢字拡張 B」の領域は、471ページと似せて書くと
0x00020000 〜 0x0002a6df
なので、
0x00200000 〜 0x03ffffff
に対応する「UTF-8で5バイトのところ」ではなく、
0x00010000 〜 0x001fffff
に対応する「UTF-8で4バイトのところ」にあたります。
（実際、UTF-16で表せる範囲というのは、すべて、UTF-8で4バイト以内に納まります。そして、Unicode Consortium は、UTF-16の利用を推進しているため、UTF-16で表せない領域を利用することを、絶対に許しません。）
471ページは、正しくは、
0x00010000〜0x001fffff が「古いイタリック」から「JIS X 0213 の追加漢字の一部」までの全部を含んで「UTF-8で4バイト」になり、
0x00200000〜0x03ffffff と 0x04000000〜0x7fffffff は、UTF-8のバイト数は異なりますが、内容は「(現状で割り当てなし)」になります。
（Unicode Consortium の人ならば、最後の部分の説明は「(未来永劫決して使わない)」にしたがるでしょうが。:-(
505 ページは、どう直せばいいのか、よくわかりません。それは「ここまでが 4 バイト」というメッセージを入れる場所がない (5バイトになるのは、まだずーっと後の方) のですが、何かかいておかないと、ここまでのUTF-8のバイト数の説明と整合しませんし、「僕が生きているうちに云々」という名文の行き場がなくなってしまいますから。
うわー痛恨ですね。ご教示ありがとうございます。まとめると、
- 本書では「CJK 統合漢字拡張 B」の開始位置 U+20000（ゼロ 5 個）を U+200000（ゼロ 6 個）と勘違いしている
- U+20000 であれば UTF-8 では 4 バイトにゆうゆう入るので、「CJK 統合漢字拡張 B」が 5 バイトというのはおかしい
- Unicord Consortium はあらゆる文字の範囲を UTF-16（サロゲートペアを含む）の範囲に入れる方針を立てている。
- これは UTF-8 では 4 バイトにあたり、5 バイトの UTF-8 はありえない。
ということですね。大変申し訳ありません。以下のように改訂します。
p.471 の表
（訂正前）
使用／私用などの微妙な誤植も訂正しました。
（訂正後）
なお、p.471 の末尾に次のようなメモを入れます。
UTF-8 で 4 バイトに入るまでのコード範囲は、サロゲートペアを含む UTF-16 で表現できるコード範囲に相当します。Unicode Consortium は UTF-16 の使用を推進し、UTF-16 の範囲に入らない文字を許さないだろうということなので、UTF-8 も将来に渡って 4 バイトと考えられます。
p.504 末尾のメモ
（訂正前）
ここまでが UTF-8 では 3 バイトの文字です。また、ここまでが UTF-16 で 2 バイトの文字です。（以降はサロゲートペアを使って表現します。）
（訂正後）
ここまでが UTF-8 では 3 バイトの文字です。また、ここまでが UTF-16 で 2 バイトの文字です。（以降はサロゲートペアを使って表現します。）なお、これ以降の文字はすべて UTF-8 で 4 バイトで表現されます。UTF-8 で 5 バイト以上の文字は、当面は存在しません。
p.505 下の方のメモ
（訂正前）
ここまでが UTF-8 では 4 バイトの文字です。これ以降はすべて 5 バイトで表現されます。ぼくが生きているうちに UTF-8 で 6 バイトが必要な字は現れないと思います。
（訂正後）
（削除します）
なお、p.461 の図の下に、次の説明を追加します。
（メモ）Unicode Consortium は UTF-16 の使用を推進しており、UTF-16 収録可能範囲の UCS-4 0 群 16 面までの収録しか許さないだろうとのことです。
以上です。MS さんへのご挨拶はこの下の下にて。
2004/01/18 MS さんからのお便り
技術論ではありませんが、
491ページの上の方に、骨の字の形として「実際に台湾の人に聞いたのですが〜」という文がありますが、少なくとも私が話をした「台湾の人」の中に、お説のような形（深沢中：上の部分を「回」とする）で書くのが普通であるという主張をした人はいません。
回答は人によって違いますが、MS 明朝や Batang のように（深沢：言うところの右ホネ）書くと断定的に言う人と、MS 明朝や Batang のように書いたり SimSun のように書いたり（深沢：言うところの左ホネ）すると主張する人がいて、後者の場合に「どういうときにどっちで書くのか」の説明のしかたがばらばら、という感じです。
ちなみに、念のため、仕事で面識のある台湾の人 (アカデミアシニカという政府系の組織で、漢字コードの標準化を仕事としてやっている人なので、専門家と思っていいと思いますが) に聞いてみたところ、やはり、骨の上部を「回」のように書くのが普通ということはない、とのことでした。
まぁ、491ページに書いてあるのは、深沢さんがある「台湾の人」に質問したら、カクカクの返事をした、ということで、それは真実なのでしょうが、でも、この文脈でこれだけ書かれると、台湾では一般的にそういう書き方をするのだ、という印象を与えてしまいます。
私は、今のところ、それが絶対に間違いだという証拠を示すことはできませんが、たぶん間違いだろうと信じています。
そうですね。私の主意は「日本だけでなく台湾にも異体字はある」ということでした。というか、SimSun が簡体字（中華人民共和国の字。Sim は simplified の意味か）で MingLiU が繁体時（台湾の字）であるとされているが（ちなみに Batang は韓国の字）、本当かどうかホネを題材に台湾の人に聞いてみたら、全然違う字を言われてたまげたのが実情です。以下にホネのいろいろを整理します。
いま、社内に別の台湾の人が出張で来てたので聞いてきたんですが ;;; 彼女は MingLiU / Batang の字（右ホネ）しか使わない。回の方は昔どっかで見たかもしれないけど普通の若い人使わないと思う、とのことでした。ということで、やはりメモがちょっと穏当ではなく、余談で混乱をもたらすのはよくないので削除します。地球のどこかで回のついた骨を発見された方はお便りいただけると幸甚です。
2004/01/18 MS さんからのお便り
最後は、ご本ではなく、暫定サポートページの「おたよりコーナー2」についてのコメント (というか、「トリビアネタ」?) ですが、
「区点」の「区」の英語は ward なの row なの？
について。
JIS の規格書が、古くは C6226、その後 X0208、X0212、X0213 などの規格で使う“区”という術語に英語を併記するようになったのは X 0208 の 1997 年版からだと思いますが（深沢注：上の項で書いた通り、この規格書に併記されている英語は row）、実はもっと前に (やや) 非公式なものがあります。
それは、1987年に作成された「JIS X 0208 English Version」というモノです。JIS の規格票の出版を担当する日本規格協会が作って、1990年にX 0208が改正されるまでの数年間にわたって販売されたようです。そこでは“区”に相当する術語として ward を用いています。
現物を見るとわかりますが (といいつつ、現在では入手困難なので、見ることはほとんど無理でしょうが) これは「とてつもなくヒドい翻訳」です。噂によると、翻訳会社に丸投げして、文字コードなどの技術的内容を全く解さない(ヘタをすると英語力もわりと低い) 担当者が、和英事典を引きながら適当に訳したもので、ここから規格の内容を理解するのはほとんど無理という代物。
Lunde さんは X 0208 の English Version と、本来の日本語の規格票と、両方とも持っていて、しかも日本語が (もちろん英語も :-) 堪能ですから、「JIS は “区”を ward と訳している」ということを知って、しかし ward では英語として意味が通らないし、他の部分の英語を見れば英語がぜんぜんできない人物が適当に訳したものであることは明白であったので、あの本のような表現になったのではないか、と、想像しています。
へぇ〜（ｘ２０）。規格書にも歴史ありですね。（なにその納得のしかた・・・）
ぼくが言うのもナンですが、翻訳が契機となってヘンな言葉が誕生してしまうことはままあることですね。余談ですが、科学でものを乗せて見る皿のことを時計皿といいますが、あれは watch dish の誤訳で、当然「観察皿」というのが正解だそうです（へぇ〜）。
オライリーのハリセン本の翻訳者の方も、ご覧になっておられましたら ward という言葉はなくした方がいいかもしれませんね。
MS さんは、お察しの方も多いかとは思いますが、本書の参考文献の 1 冊の監修もしておられる斯界の権威でおられる方です。間違ったことを書いていてなんですが、そのような方が拙著をお読みくださり、ご指導をいただいて感激のいたりです。この場を借りてお礼させていただきます。ありがとうございました。
2004/05/10 DS さんからのお便り
UTF-32 のバイトオーダーについての記述が p.476 に記載されています。そのうち箇条書きの 2 つめについて質問です。
UTF-32LEの場合に U+AAAABBBB がワード単位で反転し U+BBBBAAAA となるとのことですが、http://www.unicode.org/unicode/reports/tr19/tr19-8.html をみるとバイト単位で反転すると読めます。つまり U+AABBCCDD が DD CC BB AA のバイト列に変形される……云々の記述の誤りではないでしょうか？
何度もお便りいただきありがとうございます。ご指摘の通りです。
バイト、ワードという言葉はアーキテクチャ依存なので（8 ビットのバイトは特に Unicode ではオクテットと言われますね）全部ビットで言うことにしましょう。
で、引用してくださった仕様書を見ると、
In UTF-32BE, <U+004D, U+0061, U+10000> is serialized as <00 00 00 4D 00 00 00 61 00 01 00 00>
In UTF-32LE, <U+004D, U+0061, U+10000> is serialized as <4D 00 00 00 61 00 00 00 00 00 01 00>
ケタを補って見やすくすると、
In UTF-32BE, <U+0000 004D, U+0000 0061, U+0001 0000> is serialized as <00 00 00 4D | 00 00 00 61 | 00 01 00 00>
In UTF-32LE, <U+0000 004D, U+0000 0061, U+0001 0000> is serialized as <4D 00 00 00 | 61 00 00 00 | 00 00 01 00>
8 ビット単位で反転した 16 ビットがさらに反転する。つまり、U+AAAABBBB という書き方だけではダメで、もっと刻みを細かくして、U+AABBCCDD が U+DDCCBBAA になる、と書かなければならないようですね。
ていうか、32ビットのビット列の場合 U+ という書き方はしないようなので（U+ は Unicode スカラー値＝文字の背番号にだけ使う）0xAABBCCDD が 0xDDCCBBAA になる、と書くべきですね。
検算すると、
U+004D の場合、LE に換算すると、
AA = 00
BB = 00
CC = 00
DD = 4D
ゆえに 4D 00 00 00（合ってる）
U+1000 の場合、LE に換算すると、
AA = 00
BB = 01
CC = 00
DD = 00
ゆえに 00 00 01 00（合ってる）
ちなみに、BOM = ZWNBS、U+FEFF を LE に換算すると、
AA = 00
BB = 00
CC = FE
DD = FF
ゆえに FF FE 00 00 になります。これはなぜか同じページの箇条書き 3 に正しく書かれてますね ;;;
どうもありがとうございます。
メモ：ちなみに DS さんからは、Alpha というエディタが UTF-32 を実装している、という情報もいただきました。
© 2003
Chihiro Fukazawa,
all rights reserved.
ホームに戻る [0]
