CodeMapping

仕様検討＞CodeMapping

---

最終更新日：　2007.11.03

文責：　Rastiv

ここは UTF-16 LE を内部編集文字コードと仮定する場合の、他の文字コード（SJIS, JIS, EUCJP, UTF-8, UTF-7）間の適切な変換方法と変換失敗時の例外処理問題について扱う場所です。

概要

テキストエディタとは、文字のみのファイル(テキストファイル)を作成・編集するためのアプリケーションソフト（IT用語辞典より）でありますので、字形が一致すればコードポイントが違っていても同一視するのが基本です。複数の文字コードが入り混じったファイルの編集、一つの字形に対応する複数の文字コード値の中から一つ指定する必要のあるファイルの編集、ワード文書ファイルの単語検索、EXE ファイルのメッセージ部分の編集といった用途で使用する人がいらっしゃるらしいですけれども、それらは少なくともテキストエディタの域を超えた使用法であるという認識を前提に、コード間の変換方法について気まぐれに検討します（汗）

問題点
1. 他コードから UTF-16 への変換に失敗した文字をそのまま読み込むため、ユーザーから見てそれと認識不能な状態で文字化けを起こす。
1. CP932 コード系（SJIS, JIS, EUCJP）から UTF-16 へ変換すると、暗黙のうちに重複コード解消フィルターにかけられるため、文字コード間の 1 対 1 対応が取れなくなる。

解決方法の概要：
1. 文字化けを起こした箇所をそのままにせず、ソレと認識できるように加工して読み込む。ただし、JIS と UTF-7 に限っては、フォーマットエラーが見つかれば置換文字を使い、呼び出し側にエラーを報告する措置をとる。
1. 既定コードポイントを定め、それ以外のコードポイントからの一方向変換を抑制するオプションを新設することで対応する（細かいことはユーザーに任せる）。ただし JIS の読み込みではメールセーフデータであることを前提に、できる限り変換する。

整理事項

既定コードポイントの選択

既定値コードポイントの提案：

• JIS X 0208-1997 で規定されている 2区の記号文字に対しては、2区のコードポイントを既定とする。（CP932 と同じ）
• NEC 特殊文字領域 13区にあり、すでに 2区で定義されているものを除く文字に対しては、13区のコードポイントを既定とする。（CP932 と同じ）
• IBM 拡張文字領域 115区から 119区にあり、2区および 13区で定義済みのものを除く文字に対しては、それと等価な NEC選定 IBM拡張文字領域 89区から 92区に広がるコードポイントを既定とする。ただし、Windows の CP932 では、2区および13区で定義済みのものを除く、115区から 119区にある IBM拡張文字領域のコードポイントが既定となっている．

SJIS の既定値が変更になりそうなコードポイント

0x81ca, // ￢  (0xeef9 から変更)
0x81e6, // ∵  (0x879a から変更)

(Last Update: 2007.04.30)

Unicode 組み合わせ文字列

''勝手ながらこの項目は一時的に却下させて頂きます''

言い訳：１）bregonig.dll との整合性が取れない。２）実現する見込みが非常に薄い。

Unicode のコードポイント値の組み合わせクラス値 (Combinating Class) を確認し、クラス値 0 の Unicode 文字から始まりクラス値 1 以上の文字が 0 個以上続く文字列を１文字分と捕らえる。この規則に当てはまらない例外文字も数文字あるが無視できる範囲とする。

(Last Update: 2007.11.03)

変換エラー（入力エラー）の定義

SJIS(CP932)

1. 重複コード解消フィルタにかけると値が変わった。（オプションにより選択）

2. MultiByteToWideChar での変換に失敗した。

EUCJP(CP51932)

1. 第1バイトと第2バイトの8ビット目を0にしたものを _mbcjistojms の入力に与えて変換した結果、失敗した。

2. SJIS に変換した後重複コード解消フィルタにかけると値が変わった。（オプションにより選択）

UTF-8

UTF-8 フォーマット検査でエラーが出た。

UTF-16

UTF-16 のフォーマット検査でエラーが出た。

JIS(CP5022x)

1. _mbcjistojms での変換に失敗した。

2. 不明な JIS エスケープシーケンスが発見された。

UTF-7

UTF-7 フォーマット検査でエラーが出た。

(Last Update: 2007.09.22)

参考資料　（敬称省略）

1. Windows-31J の文字セット，森山 将之
2. 拡張文字コード変換マクロ，すい
3. <PRB> SHIFT - JIS と Unicode 間の変換問題，Microsoft
4. JIS記号の UCS BMP へのマッピングの問題および MS漢字とシフトJISの違い massangeana
5. 文字コードに関する覚え書きと実験, noocyte
6. JIS 基本漢字，Cyber Librarian
7. 使いこなそうユニコード，貞廣知行
8. Unicode Standard Annex !#15 - UNICODE NORMALIZATION FORMS, Unicode Inc.
9. _mbcjistojms, _mbcjistojms_l, _mbcjmstojis, _mbcjmstojis_l, MSDN C Run-Time Library Reference

実装案

コード変換

既定コードポイントに従った SJIS コードを 便宜上 NecSJIS と呼ぶことにする。

値の埋め込み方法：

 0x00 →  -1 '0' '0'
 0x01 →  -1 '0' '1'
 0x02 →  -1 '0' '2'
  :           :
 0xFF →  -1 'F' 'F'

変換ルート：

1. ( SJIS(CP932), EUCJP(CP51932) ) → NecSJIS → UTF-16 LE
2. ( UTF-8, UTF-16 BE )                       → UTF-16 LE
3. ( JIS(CP5022x), UTF-7 )                    → UTF-16 LE

ルート 1. と 2. では、各段階で変換できなかった文字が埋め込み値として結果データに蓄積される。ルート 3. の変換エラーでは、符号化シーケンスの崩れを防ぐため、以下の通りに処理する：

• JISからUTF-16LEへの変換エラー　JIS X 0208 ＋ MS拡張セット区間に対しては全角の中点「・」を、JIS X 0201 半角カタカナ記号セット区間に対しては、半角の中点「･」を、7ビットASCII区間に対しては、半角のピリオド「.」を置換文字として使用し、それ以外の文字セット区間がエスケープシーケンス検出器により発見された場合は、半角のクエスチョンマーク「?」をその区間全域に使用する。
• UTF-7からUTF-16LEへの変換エラー　セットB区間のBase64デコード処理に失敗した場合はその区間全域を半角のクエスチョンマーク「?」で埋める。セットDまたはセットO区間に対しては半角のピリオド「.」を置換文字として使用する。

出力時は、この 3 つのルートの逆を辿り蓄積された埋め込み値を順次復元させるが、文字コード解釈がJISまたはUTF-7の場合は、この限りではない。

(Last Update: 2007.11.3)

正規表現検索

この項目については未定です

入力される正規表現を外部ライブラリに渡すときは、埋め込み値を除いて検索するように正規表現を加工する。

(Last Update: 2007.09.22)