K.Maebashi's BBS 削除ページ

>utf-8 なコードを　diksam　は受け付けない >ということですか？！ >utf な環境は、多いです！！ Diksamを作り始めた頃は、まだUTF-8が主流ではなかった、ような気がしているの ですが(私が遅れていただけかもしれません)、最近は確かにUTF-8な環境がかなり 多くなっていますね。 >＠~/Desktop/diksam_unix/main/test$ find . -exec nkf -w -overwrite {} \; >で utf-8 に変換し実行するとエラーになります。 ところでこれですが、この時、$LANGは何になっていたでしょうか? >Assertion failure (wc_format != NULL) file..error.c line..92 >wc_format is null. これを見る限り、error_message.c内の日本語文字列(UTF-8に変換されている)を ワイド文字列に変換しようとして失敗しているようです。 Diksamは、現在のデフォルトエンコーディングでマルチバイト文字列をワイド文字列に 変換しようとします(main.cに「setlocale(LC_CTYPE, "");」と書いてあります)。 よって、現在の$LANGがja_JP.EUC-JP等になっていれば、正しく変換できません。 >utf-8 なコードを　diksam　は受け付けない >ということですか？！ で、この件ですが、ソースを確認してみたところ、error_message.cをUTF-8に 変換してコンパイルされており、環境も正しくUTF-8になっていれば、UTF-8を 受け付けるのではないかと思います(まだ試せていません)。 先の投稿でUTF-8に未対応、ということを書きましたが、本来、普通に8bitを 通しさえすれば、UTF-8は文字列リテラル等に問題なく使えるはずです(UTF-8という のはそういうことを意図したエンコーディングです)。にも関わらず、crowbarで UTF-8対応がわざわざ必要になったのは、Shift-JIS対応のため特定のバイトの次の バイトを特別扱いする、という対応をしているためで、Diksamをよく見てみたら、 そもそもShift-JISの対応が入っていませんでした… というわけで、現在のWindows版のDiksamは、ソースがShift-JISであることを 期待しているにもかかわらず、「表」等の文字を文字列リテラルに入れると エラーになります(いわゆる0x5C問題)。Diksam on Windowsとか言っときながらこれは さすがにまずいので、早急に対応します。 >他　少し試しましたが　セグメンテーションエラーとか　いろいろ、、、 さすがの私もtest.shくらいは流してから出してますので、testディレクトリ以下の ものが動かないなら、何らかの環境に依存する問題かと思います。 できれば詳細を教えてください。