[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debian-devel:10352] Re: [japo:00021] Re: textutils

久保田です。

# Cc: がたくさんあるのは、とりあえず消しました。必要ならば
# いくらでも引用して頂いて結構です (って、この ML は Web で
# 公開されてるのだから、こんな許可を書くこと自体に意味がない)。


> 岡＠奈良先端です。

> 一方で、本当に国際化するのは結構大変で、仮りにワイドキャラク
> タに変換したとします。そうすると、文字ごとののカラム数を正確
> に処理するための知識が足りないような気がしています(2カラムと
> 1カラムの文字を、コードセット非依存に区別できるような標準化
> されたAPIを知らないので)。

こんな API が存在すれば、その API は うそ ですね。
カラム数にはそもそも標準など存在しないのですから。


   --- * --- * --- * ---


すみません、いま気がついたんですが、gettext での行の折り畳みは、
ソース中に長い文字列リテラルが存在する場合に起こるのですよね。
.po ファイル中の msgstr が長い場合に行が折り畳まれてしまうような
場面って存在するのでしょうか？

というのは、.po ファイルには msgid と msgstr が共存します。
msgstr はどんなコードセットでも許容しないといけないので、
msgid は ASCII を使うべきです。それでも、msgstr に使われる
コードセットに、ASCII と共存できるものでなければならない
という制限を加えることになりますが、その制限を取り去れば
.po ファイル自体が存在できなくなってしまうので、最小限の
制限として、これは必要です。

というわけで、msgid に来る文字列、すなわちソースコード中の
文字列リテラルは、ASCII の範囲で書かれなければなりません。
そうすると、ASCII で書かれた文字列リテラルは、どこで改行
しようと破壊されることはありえない。

したがって、EUC-JP が行の折り畳み処理によって壊れてしまう、
という問題は、ソースコードに ASCII 以外のコードセットを
使うことによって生じたものであるので、解決法としては
ソースコードを書き換えるのが正しく、gettext に EUC-JP パッチ
が必要となるような状況そのものがおかしいのだ、という結論になります。


   --- * --- * --- * ---


これ、間違ってますか？

たぶん、どこか私の知らないところで、msgstr が強制的に
行の折り畳み処理を受けてしまう場面があるのでしょうね。
というわけで、上記の内容は誤りで、話題になっているのは 
msgid ではなく msgstr の折り畳みだ、というふうに考える
ことにして、続きを書きます。


   --- * --- * --- * ---


> さっきからずっとソースを眺め直していたのですが、いい考えが出
> てきませんでした。逆にマルチバイトで処理する方法も考えてみた
> のですが、未知のコードセットとグリフに対して勝手な仮定を置く
> ことになってしまい、あまりにも信用がおけないのでやめました。
> 
> その他、日本語は単語の途中で改行が入っても許されますが、英語
> やヨーロッパの言語はそうではありません。これをどう機械的に判
> 断するかも悩み所です。

エンドユーザーには触れないプログラムだから、単語の途中で切って
しまってもかまわない、というのは、なしでしょうか？

やっぱり、一定のカラム数で改行するような動作はしないように
する、というのがいちばんの解決法だと思います。そうすれば、
未知の文字コードに対する仮定とか一切なしにできます。

途中で改行を加える、というのは、EUC ならともかく、シフト状態を
持つ ISO-2022-* のようなコードだと、wchar_t などを使わない
かぎり、大変な作業になりますよ。


   --- * --- * --- * ---


でも、やっぱり変だなあ...

msgstr を、行の折り畳み処理を受けてしまうほど (つまり、約 80 
バイト以上) に長くいてしまうほうが悪い、と考えることも
できますよね。そんな場合は msgstr を書いた時に手動で改行
しておかなくちゃ。ただし、カラム数/バイト数 の値が非常に小さく
なるようなコードセット (があったとして) に対しては、
このことを強く要求できないですが...

でも、きれいな解決法がもしないのなら、これもありですよね。


/***********************************************************
 * 久保田智広  Tomohiro KUBOTA
 * tkubota@xxxxxxxxxxx / kubota@debian.or.jp
 ***********************************************************/