bauxite:チラシの裏 - 文字コード/iconv/InnoTek

文字コード/iconv/InnoTek_LIBC

no archive mode

[[文字コード]]/[[iconv|文字コード/iconv]]/InnoTek_LIBC

!! Innotek LIBC における iconv*() の実装

ソースリポジトリ：((br))
branches/libc-0.6/src/emx/src/lib/locale/[iconv.c|http://svn.netlabs.org/libc/browser/branches/libc-0.6/src/emx/src/lib/locale/iconv.c]((br))
trunk/libc/src/libc/locale/os2/[iconv.c|http://svn.netlabs.org/libc/browser/trunk/libc/src/libc/locale/os2/iconv.c]

基本的に OS/2 標準の Unicode API (UCONV.DLL) におまかせ。

ちなみに _((null))_libc_TranslateCodepage は同じディレクトリの __convcp.c 内（[branches/libc06|http://svn.netlabs.org/libc/browser/branches/libc-0.6/src/emx/src/lib/locale/__convcp.c]/[trunk|http://svn.netlabs.org/libc/browser/trunk/libc/src/libc/locale/os2/__convcp.c]）] …ちょ、これって日本語エイリアスは EUC-JP しかねえの？ SHIFT-JIS は？
（UCONV 側でどうにかしてくれるんだっけ？ あとで確認しないと…）((br))
→ UCONV には SJIS-1, SJIS-2 のエイリアスがある（IBM-943）。しかし '''SJIS はない。'''

重要な注意： CVTTYPE_PATH が意図的に解除されているため、日本語コードページのディレクトリセパレータが（バックスラッシュでなく）円記号としてとして認識される。ディレクトリセパレータを含む文字列を CP932 からそれ以外のコードページに変換した場合（あるいはその逆も）、そのパス名は（日本語固有の文字が含まれていない場合でも）正しく扱えなくなる可能性が大きい。

// 重要な注意(2)：標準ライブラリ関数のマルチバイト文字列→ワイド文字（列）置換も iconv と同様、CVTTYPE_PATH を殺した状態で UniUconvToUcs するようだ（参考：[mb_libuni.c|http://svn.netlabs.org/libc/browser/trunk/libc/src/libc/locale/os2/mb_libuni.c]）。つまり wchar_t 系列の C 標準関数でも同様の問題が起こる。おーのー。（でもワイド文字→マルチバイトのほうは殺してないんだよね。やや不思議）
// さっき mbstowcs をためしてみた限りでは、日本語ロケール (ja_JP.IBM-932) でも \ のままだった。うーむ。

Attachment

New:

Edit

文字コード/iconv/InnoTek_LIBC

Attachment