Orz日記 by Akio Morita

_ [SAD]文字列Encodeの扱い

やはり、Encodeオプションのような形で、String処理時のEncodeを指定できる方がスマートな気がする…

その場合、サポートするEncode名とバックエンドの関係を定義するframeworkを実装すべきか？

現在の状況では、実用的なコードポイント集合はUnicode(UCS-4)になるので、CSI実装をする必要は無いと思われる

基本的なPrimitiveは、multibyte bufferからコードポイントを拾う・multibyte bufferへコードポイントを書き出す辺りか？

ISO-2022系のような状態遷移を持つ系はどうするのが良いのだろう… (一旦、UCS-4列にパックしてからiconvだと一時領域を割り当てる必要がある)

現時点での改修案

• String encodingを扱いFrameworkを実装する
  • 外部化するCode PointはUnicode(UCS-4)とし、CSI実装にはしない
  • iconv(3)による変換サポートを実装(UCS-4-INTERNALへ正規化後に変換するフロー)
  • 1-character単位の変換が可能なEncodingに関しては、put/get手続きを実装し、methodテーブルに登録する形にする
    • Encode名・1文字put・1文字get・1文字String生成(分かち書き用)・内部分類コード (backend routineの共用化用との識別符号)
• 現行実装済みのUTF-8サポートは、Encode/Unicode等の符号化サポートモジュールの形に再実装する
• API/StringUtilsからは、上記Frameworkを経由してEncodeサポートを行う
  • Encodeオプション付きのToUCS, FromUCSを汎用APIとして整備する
    • Default Encodeは、Unibyteとして ToCharacterCode, FromCharacterCodeと互換を取る
    • ToCharacterCode, FromCharacterCodeを別名化する余地あり
    • 派生する文字への分かち書き・文字数カウントAPIは、UCSs・UCSLength辺り？
      • もしくは、Characters及びStringLengthへEncodeオプションを持ち込む
  • ToUTF8, FromUTF8に関しては、特化APIとして残す？(外部との入出力の取扱いで頻度が多いはず)

_ [SAD]Stringのエンコード操作

現状の実装方針

• Code-point表現はUnicodeベースとし、CSI実装にはしない
  • 現用環境では、UCS-4でもメモリサイズ的に実用に耐える
  • 最近の外部のエンコードライブラリは、UCS-4実装が主なのでCSI化するメリットが薄い
• ToCharacterCode, FromCharacterCode, Characters, StringLengthを再実装し、エンコードオプションをサポートする
  • デフォルトエンコードは、Unibyteとする (0x00-0xff ⇆ U+0000-U+00FFを1対1にマッピング)
  • デフォルトエンコードをUTF-8化した変種を用意する
    • ToUCS, FromUTF8 (UTF-8 → UCS-4)
    • FromUCS, ToUTF8 (UCS-4 → UTF-8)
    • UTF8s (UTF-8文字列の分かち書き)
• エンコードモジュールが見つからない場合は、当面エラー扱いとする
  • 二次開発で、iconvバックエンドの実装を行う
    • 一旦、UCS-4-INTERNALバッファに貯めることで、ステートフルエンコードもサポート可能に(ISO-2022系とか)
  • StringEncode - Stringのエンコード変換の実装も二次開発項目
    • UCS-4経由であれば、FromCharacterCode[ToCharacterCode[s, Encoding->from], Encoding->to]相当