Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

100.0% Coverage
0.0% Duplication

✅ Build sakura 1.0.3629 completed (commit b35ceac218 by @berryzplus)

レビューありがとうございます。マージしちゃいます。

• 実装過程で 3件の不具合 を発見しましたが、あえて修正していません。

ちなみにこの3件の内訳は以下の通りです。

1. Shift-JISで変換できなかった文字がある場合に、変換結果が「正常」になる。
2. EUC-JPで補助漢字が正しく取り込みできない。
3. UTF32BEで7bit ASCII文字列の取り込みができない。

これらの不具合修正と CConvertMediator をテスト可能にする変更のどちらを優先するかで迷い中っす。

概要

• EUC-JPで補助漢字が正しく取り込みできない。

修正検討した結果、「補助漢字には対応しない仕様」のEUCが実装されてることが分かりました。
つまり、「森鷗外」を正しく取りこめないのはバグでなく「仕様」です。

詳細

EUCは Enhanced UNIX Code なんですが、複数のバージョンが存在します。

日本語コードの担い手がアメリカにある UNIX団体 ではなく、
日本の Linuxコミュニティ により行われてきた経緯が関係すると思われます。

EUCはそもそも、日本語のエンコーディングにJIS漢字コードを使用します。
JIS漢字コードは日本の工業規格団体JISが策定した日本語文字を2bytesで表現するコード体系です。
EUCはJIS漢字コードに「ある数値」を足し込むことにより日本語文字の最上位ビットが必ず立つように調整したものです。
ShirtJISもこのJIS漢字コードを利用していますが、先行バイトに制限があるShiftJisよりもEUCのほうが扱える値域が少し広いです。

ぼくが認識していた「本来のEUC」というのは、
JIS漢字コードが定める「補助漢字」に対応したEUCを指していました。
補助漢字に対応したEUCは、サクラエディタのEUCよりも少し新しいバージョンです。

現在のサクラエディタEUCは、
Unicode⇔ShiftJis⇔JIS⇔EUC
という前提に基づいて実装されています。

登場する文字セットで扱える文字数の関係は以下のようになっています。
Unicode　＞　JIS　≧　EUC　＞　ShiftJis

※Unicode は [0, 0x10FFFF] の範囲で、最大4bytes
※JISは2bytesで文字を定義するが、補助漢字表が別。今後増えない保証はない。
※EUCは半角カナと常用漢字を2bytesで表現するが、補助漢字は3bytesで表現する。
※ShiftJISは全角文字を2bytesで表現する。3bytes形式がないため最も値域が狭い。

課題

1. サクラエディタEUCは現状のままでよいか？
   現状の実装はおそらく、最初期のEUC実装。
   仕様として「誤り」ではないものの、これのために「普通（？）のEUC」が扱えないとするとマイナス。
2. 正しいEUCってなんだろう？
   現代のUNIXで日本語を扱いたい場合、UTF-8を使うことになっています。
   このため、「最新のEUCに合わせる」の対処がミビョーになります。

windowsでコードページ20932を使えば、EUCっぽいコード変換が可能ですが、これの位置づけも不明点があるので、どっかしら「えいやっ！」と決めてしまう部分が必要になると思っています。