Kctrans

開発の狙い

    中国や台湾、香港のウェブサイトからテキストファイルをダウンロードして、日本のパソコンで表示させると、アルファベットで書かれた部分を除いて、多くの場合、意味のない字(ゴミ)が表示されます。こうしたことが起きるのは日本、中国、台湾(と香港)で漢字のコード体系がそれぞれ異なっているためです。

図1 中国のGBコードで書かれたテキストファイル=『人民日報』1999-12-06より Original File(GB encoded) 図2 上記ファイルを日本のシステムで見た時の表示の一例 Original File(View from JP system)

    最近は約20,000字の漢字を取り扱えるUnicodeというコード体系が実用化され、一部ではこうした問題はなくなりつつありますが、漢字圏でこれまで蓄積された電子テキストの大半はそれぞれの地域の漢字コードにもとづいていることや、各地で流通するアプリケーションソフトもまだ各地の漢字コードの取り扱いが優先されている現状では、各地のテキストの漢字コードを別の地域の漢字コードに転換するコンバートソフトがなお必要と思われます

KCTRANSとその働き

    コンバートソフト「KCTRANS」(MS-DOS版、Macintosh版は「MacKctrans」、ソフトは「Kanji Code TRANSlator」の頭文字で、読みかたは「KCトランス」です)は、上のような需要にこたえるために作ったソフトです。日中、日台間相互の漢字コード変換に主眼をおき、それぞれの地域で代表的な文字コードを対象として以下の4種類のコード変換に対応します。

  • 日本→中国
    Shift-JIS → CN-GB(8bit GB)
  • 中国→日本
    CN-GB(8bit GB) → Shift-JIS
  • 日本→台湾
    Shift-JIS → Big-5
  • 台湾→日本
    Big-5 → Shift-JIS

    「KCTRANS」は中台間のコード変換には対応しません。また「新/旧JIS」「日本語EUC」(日本)、「HZ形式」(中国)、「CNS11643」(台湾)といったそれぞれの地域でよく使用される文字コードの処理や、行末コード(DOS=CR+LF、Maciontosh=CR、UNIX=LF)の相互変換もサポートしません。

    上の(図1)のテキストファイルをGB→JIS変換(正式にはCN-GB→Shift-JIS変換だが簡略化してこう呼ぶ)する例で説明すると、「KCTRANS」は以下のような作業を行います。

  • 入力ファイル1文字目の「本」(厳密にはその前に2文字の全角空白があるがここでは触れない)を読み込む
  • そのGBコードをJISコードに変換
  • JISコードを出力ファイルに書き込む
  • 入力ファイル第2字目の「報」(簡体字)を読み込む
  • そのGBコードをJISコードに変換
  • JISコードを出力ファイルに書き込む
  • ……………………………
  • ファイルの終わりが来たところで作業をおえる

    出力ファイルは全部JISコードで書かれているので、表示は(図2)のようではなく(図3)のようになります。

図3 上記ファイルをGB→JIS変換した結果 Converted File(S-JIS encoded)

変換辞書

    「KCTRANS」は漢字の変換にあたって、変換辞書(MS-DOS版ではパッケージ内の*.LEXファイル、Maciontosh版ではソフト内部に格納)を参照します。変換の種類に応じて4つある辞書のひとつが使われます。この際に変換元の漢字コードと変換先の漢字コードをどう対応付けるかが問題になりますが、「KCTRANS」では以下の4つを原則として対応付けを行っています。特に異体字と意味の関係を導入して変換率の向上を目指しています。

  • 字形が全く同一
    例:「一」=JIS:16区76点、GB:50区27位、Big-5:$A440
  • 字形がほとんど同一で、他の漢字との混同が起きない場合
    例:「骨」=JIS:25区92点、GB:25区39位、Big-5:$B0A9
    (GBでは上の四角のまん中が「┐」、他は「┌」となっている)
  • 字形の違いが一方、または両方の地域の字形の簡略化に起因していることが確実である場合
    例:「対」=JIS:34区48点、GB:22区52位、Big-5:$B9EF
  • 一方の字形に存在する異体字が他方の漢字と同一であり、対応づけても意味のまぎれが生じない場合
    例:GB:[衣庫](31区67位)=JIS:袴(24区51点)
    (中国語[衣庫]=衣へんに庫=には異体字として「袴」が存在する)
  • ただし元になる字が(イ)GB第一水準またはBig-5主要漢字の(ロ)助詞または代名詞で(ハ)文法的に標準的な形−−の場合は上記原則にも関わらず異体字を利用した対応を見合わせる(行き過ぎた統合をしないため取り入れました)
    例:[ロ阿](GB:16区01位、Big-5:$B0DA)≠JIS:呵(50区74点)
    例:[ロ巴](GB:16区41位、Big-5:$A761)≠JIS:罷(40区77点)
    例:[ロ尼](GB:36区56位、Big-5:$A94F)≠JIS:吶(50区69点)
    例:[女也](GB:43区93位、Big-5:$A66F)≠JIS:他(34区30点)

    漢字コードが「一対多」対応する場合、おかしな変換になることがあるのは、漢字が出現するときの前後関係を考慮しない「KCTRANS」の限界で、仕様と考えて下さい。ただその漢字を含む単語を調べることでこうした変換を減らすことは可能で、これについては姉妹ソフトである「KWTRANS」の説明文をお読み下さい。

  • 変換先の漢字がいずれも変換元の漢字の異体字である場合、原則としてJISの旧字体に当てる
    例:「广」(GB:25区67位)=「廣」(JIS:55区02点)、≠「広」「广」
    例:「气」(GB:38区88位)=「氣」(JIS:61区70点)、≠「気」「气」
  • 変換元の漢字に、簡体字政策などで2つ以上の漢字が当てられている場合、「変換後に意味のまぎれが最も少ない」ことを原則に対応コードをきめるが、場合によってはおかしな変換になる場合がある。
    例:「干」(GB:24区41位)=「干」(JIS:20区19点)、≠「乾」「幹」
        GB:「干渉」→JIS:「干渉」…○
        GB:「干燥」→JIS:「干燥」…△
        GB:「干部」→JIS:「干部」…△
    例:「斗」(GB:22区23位)=「斗」(JIS:37区45点)、≠「闘」
        GB:「漏斗」→JIS:「漏斗」…○
        GB:「斗争」→JIS:「斗争」…△
    例:[厂<力](「歴」の簡体字=GB:32区90位)=「歴」(JIS:46区82点)≠「暦」
        GB:「[厂<力]史」→JIS:「歴史」…○
        GB:「[厂<力]法」→JIS:「歴法」…×
    注:ここで○は正常、△はGB簡体字→JIS旧字体という変換原則からするとおかしいが理解は可能、×は誤変換

KCS形式

    以上のように同一性をかなり広めにとっても、GB、Big-5、JISのコード体系の相違はやはり埋まらず、変換できない漢字もかなりあります。例えばGB→JIS変換またはBig-5→JIS変換を考えるとGBまたはBig-5の[イ尓](人へんに尓)や[ロ那](口へんに那)、[ロ尼](口へんに尼)などはJIS漢字には変換できません。

図4 台湾のBig-5で書かれたテキストファイル Original File(Big-5 encoded) 図5 上記ファイルを日本のシステムで見た時の表示の一例 Original File(View from JP system) 図6 上記ファイルをBig-5→JIS変換した結果 Converted File(S-JIS encoded)

    例えば(図6)で出力ファイルの中の「?A741」「?ADFE」「?A94F」はそれぞれ入力ファイル(つまりBig-5コード)の「$A741」「$ADFE」「$A94F」、つまりBig-5:[イ尓]、[ロ那]、[ロ尼]だったということを意味します。

    反対に入力ファイル内にKCS形式を(図6)のように書き込んでおき、JIS→Big5変換を行うと、「KCTRANS」はKCS形式を出力先の漢字に変換して、(図4)のように出力ファイルに書き出します。

    漢字が変換不可能な場合、従来のコンバーターの多くが「 」(空白)や「〓」を出力するのと比べ、「KCTRANS」では変換に伴う情報量の欠失を最小限にとどめることが可能です。また変換先の漢字コード体系内の漢字はすべて表現できることから、文字数の少ないJISから、文字数の多いGB、Big-5への変換でも相手のコードさえ分かっていればちゃんとした漢字として出力できます。(**)

GAIJCONVとの連係

    「KCTRANS」でGB→JIS変換やBIG→JIS変換をした結果、KCS形式を含んだJISテキストファイルが出力されます。コード表が手もとにあればこの漢字が何かを知ることは可能ですが、かなり面倒な作業になります。そこでこの出力ファイルを姉妹ソフトである「GAIJCONV」で再変換すると、ファイル内の「KCS形式」が合成文字に変換され読みやすくなります。合成文字はJISの漢字1字で表せない中国語の漢字を、JIS漢字を部品として使って表現したもので、上記の[イ尓]や[ロ那]もその一例です。「KCTRANS」と「GAIJCONV」を使ったファイル変換の流れは以下のようになります。

図7 Big-5ファイルからJISファイル(合成文字)への変換 Original File(Big-5 encoded)(Big-5ファイル=すべて漢字)     ↓(「KCTRANS」のBig-5→JIS変換) Converted File(S-JIS encoded with KCS)(JISファイル=一部がKCS形式)     ↓(「GAIJCONV」のKCS→合成文字変換) Converted File(S-JIS encoded with Synthe-Kanji)(JISファイル=一部が合成文字)

    「GAIJCONV」の詳しい機能や使用方法についてはこちらを読んで下さい。

注(*)

    漢字の同一性の認定については「形」のみによるもの、「形」に漢字簡略化政策(日本や中国)を加味して考える立場、さらに意味や出現環境を考慮して異体字・ひろく行われている慣用字までを取り込む立場−−など各種がありえます。「KCTRANS」はもともと@Nifty外国語フォーラム(FLM)の「日中プロジェクト」という議論から生まれたもので、当時は「日本の(または中国の)メッセージボード(またはメール)の書き込みと読み出しが中国の(日本の)システムからできるようにする」という狙いでした。従って漢字変換の狙いは、コミュニケーションがとれる(相手のいっていることがわかる)ことに置かれており、個々の字形にこだわることなく、なるべく広く漢字の同一性の認定するというのが立場です。

    特にGB→JIS変換の変換不能文字数を、当時のDOS/Vの外字の登録制限1,880字以下に押さえるよう議論がかわされました。こうすると外字領域に全変換不能文字のデータを割り付けることができ、GBテキストを、一部は「KCTRANS」を通じJISで、変換のし残しはJIS外字コードで、全部変換することができるようになるというわけです。この間の事情はこちらをみてください。

注(**)

    その一例が「Uctrans」です。「KCTRANS」と「Uctrans」の比較については、「About Uctrans」の【変換性能比較】を参照して下さい。