2008-04-01から1ヶ月間の記事一覧

Re: g++でwcharが使えない

http://d.hatena.ne.jp/gpuppur/20080429 Cygwinのg++ 4.3.0でconfigureを試してみました。 ログを見ると、 conftest.cc:40: error: '::fgetwc' has not been declared conftest.cc:41: error: '::fgetws' has not been declared conftest.cc:42: error: '::…

続 PNGの表示

え〜、あんまり進んでません。 昨日のコードはアルファ値を使ってなかった(透過のみだった)ので、修正しました。 差分 アルファテスティングをアルファブレンディングに変えただけです。 #PNGを8ビットから32ビットのものに置き換えたらなぜかサイズが減り…

PNGの表示

wpath対応が落ち着いたので、またOpenGL&GTK+の作業に戻ります。 前に書いたPNG読み出しコードをコピペして、GTK+のウィンドウにOpenGLで描いてみました。 png_test.cpp 少し手直しが必要でしたが、Linuxでも動きました。 png_reader.cpp Linuxだと、png.hよ…

Unicode対応完了

今度こそHamigaki.ArchiversのUnicode対応が終わったので、ドキュメントにもフォーマット毎の対応状況を追記しました。 http://hamigaki.sourceforge.jp/doc/html/archivers/format.html cpio書庫は仕様で「ISO/IEC 646:1991 standard IRV」(=ASCII)を使うよ…

tarのUTF-8対応 その2

wpath版paxフォーマットのテストを追加しました。 tar_pax_wide_test.cpp で、シンボリックリンクがUTF-8になってなかったので修正しました。 tar_file_sink_impl.hppの差分 あと、pax拡張ヘッダのcharsetレコードに対応しました。 差分 このレコード、「ヘ…

paxでShift-JISのまま格納される件

Cygwinのtarで tar --format=pax -cf out.tar こんにちは.txt とすると、ファイル名がpaxヘッダにShift-JISのまま格納されてしまいます。 ところが、 tar --format=pax -cf out.tar あ.txt だと、ちゃんとUTF-8に変換されます。 コード(utf8.c)を見ると、UTF…

tarのUTF-8対応

POSIXの仕様を眺めていたら、tarのpax形式は文字列にUTF-8を使うことに気が付いて、tarもwpath版を用意しました。 wtar_file_sinkの差分 wtar_file_sourceの差分 ustar_file_{sink,source}はUnicodeと関係ないのでナロー版しかありません。

続 utf8.hpp

アルゴリズムはほとんど弄れてないんですが、エラーチェックを強化しました。 utf8.hppの差分 テストコード差分 最新の仕様では、 Unicode外のコードはUCSでも使用しない 必然的にUTF-8は1〜4バイト となっているらしいので、これに反する場合は例外を投げる…

utf8.hpp

Hamigaki.ArchiversのUnicode対応は大体終わったので、書いていて気になった箇所をちょこちょこ弄っていきます。 今日はUTF-8のエンコーダ/デコーダを書きました。 コードページ65001でUTF-8に変換するコードは分かりにくいので、専用のコードを用意しただけ…

ISOイメージのUnicode対応 その2

ISOイメージのUnicodeファイル名の読み込みに対応しました。 差分 コンパイル通らないところに片っ端からテンプレート引数を足してるだけなんで、かなり無駄な部分があると思います。 あれ?シンボリックリンクはRockRidgeしか使わないので、wpathにならない…

ISOイメージのUnicode対応 その1

今度は、ISOイメージのUnicode対応です。 ISO 9660の拡張として、文字列にUCS-2を使うMicrosoftのJoliet拡張があります。 今回はこれでwpathの値をそのまま格納することになります。 例によって、まず書き出しのみ実装しました。 差分 読み込みは実装中です。…

ZIPのUnicode対応 その3

今日はZIPのドキュメント更新しただけです。 http://hamigaki.sourceforge.jp/doc/html/archivers/format.html#archivers.format.zip ZIPのwpath対応も一応終了です。 TODO: UTF-8環境ならナロー版でもLanguage encoding flagを立てる ISOイメージのwpath対…

ZIPのUnicode対応 その2

「Info-ZIP Unicode Path Extra Field」に対応しているアーカイバが見当たらなかったので、昨日の方針を変更して、PKZIP方式を採用しました。 差分 さらにMac OS Xだと、PKZIP方式のフラグを立てずにUTF-8で格納するようで、ShiftJIS環境で展開するとファイ…

ZIPのUnicode対応

LHAが済んだので今度はZIPです。 ざっと調べた限り、ZIPのファイル名には次の四種類があるようです。 既定のIBMコードページ437 UTF-8(General Purpose Bit Flagの11ビット目が立っている場合) 同じくUTF-8(Info-ZIP Unicode Path Extra Fieldを使う) ネイテ…

Unicodeファイル名 その4

Unicodeファイル名の読み込みに対応しました。 差分 読み書きの動作確認が出来たところで、Hamigaki.Charsetで実装したコードページの変換処理も組み込みました。 差分 UNLHA32.DLLのドキュメントを見ると、レベル1ヘッダはUnicodeとコードページに対応して…

from_utf16le()

UTF-16からワイド文字列への変換も実装しました。 差分 テストも追加です。 utf16_test.cpp 今度はsizeof(wchar_t)==4でも動作確認済みです。

Fail-Safe C

C

「Fail-Safe C」を試してみました。 テストコードはZDNetの「C/C++のポインタの機能--変数の場所(アドレス)」から拝借しました。 % cat > zdnet.c int main( void ) { int *n; *n = 5; /* ポインタ変数nに値5を代入 */ printf( "%d\n", *n ); /* ポインタ…

Unicodeファイル名 その3

LHAのファイル名出力をHamigaki.Charsetを使って書き直しました。 差分 まだコードページはCP_ACPのままで、ヘッダに入っている値は使ってません。要修正。 UTF-16出力部分がsizeof(wchar_t)==4の環境でバグっていた(というかUCS-2を想定していた)ので別途作…

utf16.hpp

速攻でワイド文字列をUTF-16に変換する関数を用意しました。 <hamigaki/charset/utf16.hpp> sizeof(wchar_t)==4の環境のために作ったのに、その環境で試してません、、、。</hamigaki/charset/utf16.hpp>

static_widen

wpath対応作業でテンプレート中から文字型に応じた文字リテラルが必要になることが多く、static_widenというメタ関数っぽい構造体を作りました。 <hamigaki/static_widen.hpp> こんな感じで使えます。 #include <hamigaki/static_widen.hpp> #include <string> template<class CharT> bool has_root(const std::basic_string<CharT>& s) { // val</chart></class></string></hamigaki/static_widen.hpp></hamigaki/static_widen.hpp>…

LHAの絶対パス

LHA書庫内の絶対パスの扱いがバグっていたので修正しました。 差分 Boost.Filesystemだと、「C:\foo」が「C:」-「/」-「foo」に分解されるので、そのまま繋いで「C:\/\foo」みたいにしていました。 テストコードにも絶対パスのテストを追加しています。

国際文字名とサロゲートペア

C++

Hamigaki.Charsetのcode_page_test.cppで「L"\U00029E3D"」という国際文字名(Universal Character Name)を使っているんですが、これがsizeof(wchar_t)==2のVC++8/9やg++では「67 D8 3D DE 00 00」(リトルエンディアン)というバイト列になります。 (VC++7.1で…

Boost1.34.1対応復活

Boost1.35.0が出た時点で1.34.1のサポートを切るつもりだったのですが、次のリリースまでFedoraのBoostが1.34.1のままなので、ビルド済みBoostのテスト環境として、もうしばらくサポートを続けることにします。 差分 ついでに、Hamigaki.FilesystemのPOSIX版…

CP_ACP

アクティブコードページが使えないと何かと不便なので、POSIX版実装でもロケールからコードページを推測する処理を追加しました。 差分 glibcのiconvならエンコーディングに空文字を指定すればOKです。 Darwinに入っているのもGNUのiconvで、これも同じ仕様…

code_page.hpp

いろいろ利用できそうだったので、コードページの変換処理をHamigaki.Charsetとして独立したライブラリにまとめました。 今日の成果物 とはいえ、実際の処理はWindows APIやiconvが行う他人任せ実装です。 CP〜以外によく使うであろう、「ISO-2022-JP」、「E…

Unicodeファイル名 その2

Unicodeファイル名の出力がバグってたので修正しました。 差分 動作確認用にUnicode版の簡易アーカイバも作りました。 wlha.cpp LHMeltで確認した限り、うまくいっているようです。 とりあえずWindowsでは動いてますが、それ以外では問題ありです。 Windows…

Unicodeファイル名 その1

Unicodeファイル名の書き出しを実装してみました。 差分 古いテスト(ナロー版)は通っていますが、ワイド版はまだコンパイル通しただけです。 ヘッダの構造体はlha::basic_header<Path>に変わっていて、headerとwheaderのtypedefを追加しています。 あと、ワイド版</path>…

Unicodeヘッダメモ

LHA

Unicode ファイル名ヘッダ(0x44)を使う場合も、ファイル名ヘッダ(0x01)は必須 UNLHA32.DLLは変換できない文字はアンダーバーに置換する 結果、ファイル名が重複することがあり、Unicodeヘッダ未対応のアーカイバだと上書きされることがある

Unicodeファイル名対応考察

今日からHamigaki.Archiversのwpath対応に移ります。 まずはUnicodeに対応しているのが分かっているLHAから考えます。 UNLHA32.DLLのドキュメントを読む限り、Unicodeファイル名を出力する方法は次の3つのようです。 マルチバイト文字列で表現できない場合…

wpath対応(やり残し分)

昨日の変更でHamigaki.Archiversのサンプルプログラムがコンパイルできなくなっていたので、今日はその対応をしつつ、ドキュメント等のやり残し分を片付けました。 Boost.Systemを依存ライブラリのusage-requirementsに追加するように変更 一部オーバーロー…