CF25 Extension GArR Issue #04
先頭1バイト分の情報が失われるケースのバグを修正。
GArR rev1.0.6 TAPIOCA へアップデート。rev1.0.3 までに修正されたはずのバグについて再報告があったためそれを修正。
単純ミスが続く
GArR には未実装機能の「エスケープ処理」がある。
文字列をデリミタ使って分割する際にデリミタ自体を文字列中に含めたい場合に「エスケープ文字を使ってデリミタとして認識しないようにする処理」が必須。これが GArR には付いてない。
実装自体は簡単なのだけど検索効率の良い方法を考えながら「ああでもないこうでもない」と脳内試行錯誤がグルグルグルグル頭を巡り、夜眠れなくなる。
「何がなんでも実装しなければならない！」必然性が無い限り考えるのを止めようという結論に至った。
そして公開する頃には実装をすっかり忘れていた。
機能自体は未実装だが
設計段階では実装予定があったので、負荷テストも兼ねてエスケープ処理用の分岐条件は一応ソースコード中に挟んであった。
これは本来機能しちゃいけない if 条件、前回のバグ修正中にソースを弄ったのか中途半端なまま機能するようになってしまっていた。この辱めをどうしてくれるの！って感じだが、お前が自分でやったんやで？
今回のバグ報告はこの中途半端なエスケープ処理機能の残骸が引き起こしたバグだったのだ。
エスケープ処理を実装するべき時なのかもしれないが、その前に何度もバグ報告してもらって申し訳ないという気持ちもあり、まずデバッグをしっかり腰据えてやろうかという気持ちに切り替えた。
同じようなミスを何度も繰り返すのは不本意なので、すこし時間かけて今回はしっかりデバッグすることにした。
文字コードについて
Windows OS は NT シリーズ以降からシステムの標準文字コードとして UTF-16 を採用、現在は Windows 10 の途中からだが UTF-8 への対応を開始している。
日本語 MS-DOS や Windows 9x 系はシステムが ANSI （ Microsoftが独自拡張を加えた Shift_JIS ＝ CP932 ） だが、現在システムで利用されている UTF-16 も将来的に UTF-8 へ統合されると考えられている。
報告されていたバグでも UTF-16 の特徴が出ていたのだが、1バイト目や2バイト目が欠落した場合でも後続の文字列に影響が出ないのは UTF-16 の利点。Shift_JIS とかだと全部の文字列が影響を受けて文字化けするかもしれない可能性もあったが、UTF-16 だと欠落した場合に影響を受けるのは文字単位に限定されるため文字列全体に影響を与えることは無い。
サポートされている文字／漢字
現代の日本語はアルファベット・ひらがな・カタカナ・漢字で主に成り立っているが、言語表現に必要な文字数が異常に多くなるのは主として「漢字」に原因がある。
日本産業規格（ JIS ） で標準と定められた漢字コードは数度の拡張を経て、現在は 2004 年に第二次規格として制定された JIS X 0213:2004 が第1水準漢字〜第4水準漢字までを含めた 11,233 文字をカバーしている。
ゲームなどに利用可能なフリーフォントなどは漢字部位の対応がJIS第一水準常用漢字からJIS第二水準までが一般的、基本的には全文字で約 4000 以上に対応したフリーフォントはあまり見かけることも無い、と思う。フォントを作る作業量を考えればこれは妥当だが、日本語に利用される漢字込みの文字数としては JIS X 0213:2004 で定められた漢字総数の半分以下対応に留まっている。JIS が過剰でありゲーム用にはフリーフォントが対応している文字数、これくらいでいいとも言えるはず。
JIS X 0213:2004 のマッピングデータでエクステの動作検証してバグが出なければ「ユニコード全部は無理かもだけど日本語用として JIS には対応してます！」と言い張ることができるようになるので、やはりまず JIS マッピングデータを入手することから作業を開始。
お宝を手に入れろ！
JIS マッピングデータは Unicode Consortium の OBSOLETE/EASTASIA から一部を直接取ってきた。しかし JIS X 0213:2004 規格に沿ったマップデータはコンソーシアムの方にも無く、x0213.org の 「JIS X 0213:2004 漢字8ビット符号とUnicodeの対応表」 を活用させてもらった。
コンソーシアムにある最新のマッピングは Unicode 全体のアジア地域を見渡すものとしてデータが提供されており、その成果は Unihan.zip にまとめられている。その量たるや、単なるテキストファイルなのに約６メガ以上にも及ぶ膨大なマップである。
一方 JIS 規格は日本語用というローカルな基準なのでマップの内容が日本向けに特化してる。この規格に収録されてた文字はあくまでもユニコードのごく一部だ。
JIS X 0213 に沿ったマップデータは現在だと x0213.org から取得するのが手軽で良い、ということになります。
JIS X 0213 の全文字・漢字をリスト化
ユニコードコンソーシアム（ The Unicode Consortium ） と x0213.org から JIS 規格に沿ったマッピングデータを入手。
JIS ＝ ユニコードではないが JIS がサポートした文字を対象にテストクリアできれば日本では実用上の問題は無い、はず。JIS X 0208 は第1／第2水準漢字をカバー、JIS X 0213 は JIS X 0208 を拡張した規格なので更に第4水準までサポート。
実際に JIS X 0213 のマップを見てみると合成文字にも対応していた。
JIS X 0213 の合成文字
合成文字はマップで見ると COMBINING KATAKANA-HIRAGANA SEMI-VOICED SOUND MARK などと書かれていて、仮名と半濁点の組み合わせがマップには記載されている。これはどういうことかというと
U+304B+309Aこれが合成文字、この例だと「か」と「゜（ 半濁点 ） 」を組み合わせた文字を「か゚」という一文字として表現される。
日本語変換辞書を用いた半濁点への変換例：環境に依存する
実際の用例としては「通信用語の基礎知識」に載っていたサザエさんの例が分かりやすかった。
参考（ 通信用語の基礎知識 ）
：か゚
ガ行全体で見ると合成文字は以下のようになっていて
上記例は「か行の仮名」に「半濁点」を付したもので、日常で意識して利用されることはほぼ無い。
文字というより役割としては音符や発音記号に近く、五十音図にも含まれない「鼻濁音 （ びだくおん ） 」という特殊な文字。
こんなマイナーなものにもフォントが用意されていることに驚きつつ、濁音／半濁音を明確に区別し表現する職業（ 日本語のアナウンサーなど ） もあることを知る。
その他：アイヌ語カナ表記用
民族として固有の文字を持たなかった日本アイヌ民族の口伝をカナ表記で記載する場合に、アイヌ語カナ表記用の拡張カタカナという文字も Unicode 3.2 からサポートされていて、これらは JIS X 0213:2004 にも収められている。
アイヌ語カナ表記用の文字セットは利用している OS が直接変換を未サポートの場合もある。
その他：除外したコードポイント
JIS X 0213:2004 マップデータに記載があったコードポイントには reserved point が含まれており、これら未割当の領域をデバッグ用リストから予め除外。
Unicode3.1 で設定されたコードポイントの中に u+2000B＝𠀋 のようなサロゲートペアを利用する文字が JIS X 0213:2004 に含まれている。除外はしなかったがデバッグ用の文字リストを作成する場合 Python3 系で処理したほうが良かった。念の為これらコードポイントは一括してリスト後方に意図的に集めて配置してある。合成文字もリストの後方に配置したので、JIS マップデータの文字配置順と今回作成されたデバッグ用文字列のリストは順番が完全一致しない。
リストの要素数合計は 11,232 文字となった。
実際のデバッグ
CF25 に文字リストを取り込んで GArR を使って配列化、それをループ処理で全文字単位でリストオブジェクトへ渡す。リストオブジェクトへ配列を渡し終えたらリストオブジェクトの機能を使ってファイル出力する。このファイルと配列のソースファイルを diff で比較して完全な同一であると確認。
このような流れでデバッグを行っている。
JIS X 0213:2004 と JIS0201+JIS0208 をソースに使って全文字のリストを得ているので、これらを正常に表示できれば通常の日本語なら確実にサポートできていると言える。
デバッグの結果
ソースと CF25 から出力された結果を比較して完全な同一と判定された。これで恐らくダメ文字関連のバグは今後発生しない。
次へ