| Word - 置換のワザ > 文字種の変換とフォントの罠(1)
コンピュータというのは、データを1と0の2進数で処理しています。画面に表示される文字や記号もすべて1と0の組み合わせで表現されているのです。
したがって、どの文字にどのような組み合わせを使うかを規格として決めておかなければ、異なるコンピュータ間で正しい情報のやり取りをすることができません。
こうして文字ひとつひとつに割り当てられる組み合わせが文字コードと呼ばれるものです。
POINT 1
コンピュータで扱う文字には、それぞれ固有の文字コードが割り当てられている |
文字コードにはいくつかの種類があり、英語の半角文字は1バイト（＝8ビット）で表現されています。ちょうど8つのマス目の各々に1か0のどちらかを入れてコード番号を表現するようなイメージです。
たとえば、わたしたちの日常生活で使われる10進数の数字を2進数で表現すると、1＝00000001、2＝00000010、3＝00000011、4＝00000100、5＝00000101、6＝00000110といった具合になります。こうして組み合わせを作っていくと、1バイトで表現できるのは最大256文字です。
半角文字のことを英語でsingle byte characterと呼ぶことからも分かるように、厳密な意味で半角だと言えるのは、このように1バイトで表現可能な範囲の文字だけだということになります。
POINT 2
英文で環境によるトラブルなく使用できる半角文字は1バイトで表現される範囲 |
英語なら256文字もあれば十分足りるのですが、日本語のように文字数の多い言語ではとても足りません。そこで、日本語では2バイト（＝16ビット）の文字コード体系を使用してきました。全角文字すなわちdouble byte characterで、これなら最大65536種類の文字を表現できます。
日本語に対応している文字コードは主にJIS、S-JIS（Shift-JIS）、EUCの3種類で、このうちMicrosoft Officeで使われてきたのはS-JISというコードです。なぜ「使われてきた」という言い回しをするかというと、西暦2000年あたりを境に文字コード体系がS-JISではなくなっているからです。
現在のMicrosoft OfficeではS-JISの代わりにUnicode（ユニコード）という体系が使われています。Unicodeとは、荒っぽい言い方をすれば世界中の言語をひとつの文字コード体系で表現しようとするものです。
このUnicodeを採用するにあたって、Microsoft Officeなどのアプリケーション側ではそれまでS-JISだったものをUnicodeに変更しなければなりません。かなりドラスティックな変更になるからか、切り替えの時期にあたるバージョンでは文字に関する諸々のトラブルが出ています。
Wordでいえば、Word 2000がUnicodeへの対応が不十分で一括置換や文字種の変換に伴う文字化けが比較的よく起こります。Word 2002以降は比較的安定し、最新のWordではこうしたUnicode対応に伴う問題は随分と少なくなっているようです。
Wordの[文字種の変換]機能
みなさんがお使いのWordには、「半角←→全角」や「ひらがな←→カタカナ」のように文字の種類を変換する機能があります（[書式]メニューの[文字種の変換]）。
この機能を使うと、選択した範囲の文字を一括して指定の文字種に変換してくれます。使い方次第では便利な機能ですが、この機能によって全角文字を半角に変換しても厳密な意味での半角にならないものがあることを知っておいてください。
もう少し詳しく説明すると、全角アルファベット「Ａ」と半角アルファベット「A」のように全角文字と半角文字との間で１：１の対応関係がある文字は、[文字種の変換]で問題なく変換されます。たとえば以下の表のような感じです。
| 全角文字 |
文字コード |
|
半角文字 |
文字コード |
| Ａ |
0x8260 |
←→ |
A |
0x41 |
| 0xFF21 |
0x0041 |
日本語文字コード上段はS-JIS、英語文字コード上段はいわゆる昔からの半角文字のコード（ASCIIコード）、下段はいずれもUnicodeです。文字コードの前についている0xは16進数であることを示す記号で、コード番号そのものではありません。コード番号はたとえば全角ＡのS-JISでは8260という読み方をします。
この表から分かるように、全角Ａと半角Aとの間の文字種の変換は実際に文字コードをFF21と0041との間で変更して行われています。
もともと256文字の範囲内で表現されていた半角(ASCII)文字では、Unicodeへの対応時に頭に0を付けて桁数を変えただけでコード番号自体は変わっていません。
言葉を変えると、この範囲内の半角文字に対応する全角文字については、全角半角間に１：１の関係ができていることになります。このような文字については、[文字種の変換]機能を問題なく利用することができます。
POINT 3
半角(ASCII)のコード体系に対応する文字がある全角文字には、[文字種の変換]を使っても差し支えない |
では、もともと256文字の範囲内に対応する文字がない全角文字を[文字種の変換]で半角に変えようとすると何が起こるのでしょうか。実は、Wordでは文字のフォントを変えることで見た目を変えて対応しています。このときの動きにはいくつかのパターンがあります。
例１ 「℃」の文字
| 全角文字 |
文字コード |
|
半角文字 |
文字コード |
| ℃ |
0x818E |
←→ |
A |
0x818E |
| 0x2103 |
0x2103 |
Word 97とWord 2002以降では[文字種の変換]をしても半角に変換されることなく全角のまま残ります。一方、Word 2000では全角℃の文字コードのままでフォントだけが英数字フォントに変わります。
このときに使われる英数字フォントは、[書式]メニューの[フォント]で[英数字用のフォント]が指定されていればそのフォント、「日本語用と同じフォント」になっているときはCenturyなどデフォルトの英数字用フォントです。
ここで、全角℃の文字コード（2バイト）には英数字用のフォントが割り当てられていませんので、文字コードを変えずにフォントだけが変わると表示できない状態すなわち「文字化け」が発生します。一般に文字化けといわれる現象のなかには、このように特定の文字コードを指定されたフォントで表示できない、あるいは他の文字が割り当てられていることが原因で起こるものが多々あります。
例２ ギリシャ文字
| 全角文字 |
文字コード |
|
半角文字 |
文字コード |
| a |
0x83BF |
←→ |
α |
0x83BF |
| 0x03B1 |
0x03B1 |
Word 97では全角のギリシャ文字を[文字種の変換]で半角にしようとしても全角のまま残り、Word 2000以降では全角aの文字コードのままでフォントだけが英数字フォントに変わります。このとき、見た目は半角のαとして表示されます。
ここで注意して欲しいのは、見た目は確かに半角でも文字コードは変わっていないということです。
これはデータを使う環境やアプリケーションによっては全角に戻ってしまう可能性があることを意味します。実際、秀丸エディタというアプリケーションを使って検証してみたところ、[文字種の変換]で全角から半角に変換したαをコピーして秀丸エディタにペーストすると、もとの全角aに戻りました。
また、作成した英文データを最終的に使用するパソコンに、[文字種の変換]で使った英数字用のフォントがない場合は、自動的に一番近い別のフォントで代用されます。結果として別の文字として表示されるといった問題が絶対に出てこないとは言えません。
このため、特に作成した英文データを海外で使用する可能性がある場合は、ギリシャ文字には従来から行われているように半角アルファベットのフォントをSymbolに変えて対応する方が無難です。
Symbolフォントでギリシャ文字を出すとデータ全体に対してフォントの変更をしたときに設定が落ちてしまうという議論があるようですが、これは[文字種の変換]で半角にしても同じことなのです。[文字種の変換]は一見便利な機能のように見えますが、翻訳文データの作成には極力使用しない方が無難でしょう。
POINT 4
ギリシャ文字を[文字種の変換]で半角にしても文字コードは全角のまま |
以上、やたらと小難しい話も混じりましたが、英文データを作成する際には日本語データからの[文字種の変換]をできるだけ使わないようにするとよいでしょう。 付記：
[記号と特殊文字]でフォントにSymbolを選択した上で、表示された一覧の中から該当するものを挿入するとどうなるでしょうか。 答えは、キーボードから入力した半角アルファベットを後からSymbolに変えた場合と全く同じ結果になります。 文字コードには半角アルファベットのコードが使われますので、どちらの方法で入力してもフォントを変えればギリシャ文字ではなくなりますし、テキストファイルとして保存すれば通常のアルファベットに戻ってしまいます。
Symbolフォントは純粋な英語環境のWordにもありますから、作成したデータを使用する相手がWordを使っていることが分かっているのであれば、Symbolのまま入れておいても特に問題ないと思います（全角から文字種の変換で見た目だけ変えて入れるよりは何倍もよいです）。 もし相手がWord以外のアプリケーションを使っているのであれば、何らかの記号の組み合わせで代替して入れておくか、綴れるところは綴りで入れておくなどの対応をするとよいかと思います。
文字の扱いはWordに限って言えばWord 2002あたりから安定してきているようですが、それでもバージョンによって少しずつ違いが見られます。かたや、他社アプリケーションでUnicodeをどのくらい正しく解釈できるのかは、現時点ではまったく分かりません。 このようなことを勘案すると、翻訳データの作成時には特殊文字の扱いに対するクライアントの意向を事前に聞くようにし、よく分からない場合はキーボードから入力できる文字（＋フォントの指定）の範囲でおさめておくのが無難でしょう。 |
用語
