ISO-8859

ISO/IEC 8859への対応を開始した。

今まで、これら符号はISO/IEC 2022的なエスケープシーケンスを併用するものと考えていたが、どうもそうではないらしい。
試験に使っている全てのWebブラウザは、これら符号に切り替えるエスケープシーケンスに対応していなかった。
つまり、日本人がシフトJISを使うような感覚で、0x00〜0xffがごく自然に使われている、ということになる。

確かに、古い実装を見たら、エスケープは吐いていなかった。どこかで勘違いと変な期待が混じり込んだのであろう。


それは良いとして、ではCES/CCSで分離していた管理を、どうしよう、ということになった。
実質的にCESとCCSが分離していない符号系である以上、CES/CCSを明確に分離するこの実装で、どう管理するかが課題だった。
結果として、ISO-8859-1というCESで、ISO-8859-1というCCSを符号化する、というような扱いにせざるを得ないな、という結論に至った。

従って、ISO-8859-? に、一つずつCES-IDと、CCS-IDを附番する方向で作業。
ISO-8859-1から9まではISO/IEC 2022のシーケンスがあるので、この派生という形でCCS-IDを振る方向とする。それ以外は今後検討。

また、基本的にCES-IDは言語ごとに番号が付くようになっているが、ISO-8859-1みたいのは多言語なので、これはラテン語の派生ということで言語コードLAから番号を付けることにした。
結果、ラテン系言語対応ということで、ISO-8859-1と、その派生符号Windows-1252の入出力に対応。

更に、ラテン系以外ということで、キリル文字のロシア語用符号とし、まずはISO-8859-5の入出力に対応した。
キリル文字は、専用のDLLを作って、そちらに処理を置いた。
ウクライナ語も対応予定で、これはロシア語と同じDLLで処理する予定。


今後も、アラビア語とかヘブライ語とかは、随時専用のDLLを作っていく予定である。
ただ、私はどちらの言語も知らないので、今のままだと現地人が満足するレベルには実装できないかもしれない。特にアラビア語処理。

ちなみに、以前の実装はベトナム語の処理が組めずに崩壊を遂げていたりする。
今後どうなるのであろうか。


なお、ISO/IEC 2022符号の対応の一つとして、エスケープ混じりの入力には今後、対応する予定である。
ただISO/IEC 2022対応としても、エスケープ混じりの文を吐き出す機能が必要なのかどうか、謎となった。吐いても対応する実装が殆どないわけである。