アプリケーションの国際化対応の話題スレ

国際化対応の際の問題全般を扱うスレです。

ドイツとかフランスで、小数点区切りに . じゃなくて , 使うのは
マジでやめて欲しい。
地域設定をドイツにして Excel で =pi() って入れると、
3,1415 のように表示されるのを真似ろ、ってくらいなら難しくは
ないけど、Excel の CSV 形式入出力をミミックしろとか言われても
ヤヤコシクてやってられん(CSV 形式ってカンマ区切り形式って
覚えてたんだが、欧州ロケールじゃちっともカンマで区切って
ないじゃんかよぅ)

TSVに統一すればいいジャン

---------------------- 終了 -----------------

3/10が3月10日なのか10月3日なのかはっきりしてくれ

そこで10, Marですよ

XMLだろ。

当方洋物ソフトの日本語化をやってるんだが

8pt MS Sans Serif で定義したダイアログ テンプレート上で
無理やり日本語表示すると
・2000→文字化け
・XP→異常に汚い
韓国語版や中国語版の Windows ではハングルも漢字もちゃんと
表示できるんじゃん。なぜ日本語版だけ弱いんだろう…
OS X とかはサスガにそういう事ないんだろうなぁ、と隣の芝生を
青く見てみたり

国際化プログラミング 〜 I18N ハンドブック 〜
http://www.geocities.co.jp/SiliconValley-PaloAlto/8090/

Introduction to i18n
http://www.debian.org/doc/manuals/intro-i18n/

Debian:i18n
http://ukai.org/wiliki/wiliki.cgi?Debian%3ai18n&l=jp

Java Internationalization & Multilingualization
http://www.ingrid.org/java/i18n/

GNU gettext
http://www.gnu.org/software/gettext/

Pango
http://www.pango.org/

SIL Graphite
http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&cat_id=RenderingGraphite

The International Components for Unicode (ICU)
http://ibm.com/software/globalization/icu

Windows で同じ 0x005c が、日本語環境では￥マーク、韓国語環境では
ウォンマーク、それ以外(含む英語)ではバックスラッシュが表示される
のはどうかと思う。外人に日本語OSを見せると必ずたまげる
(文字化けしてると思うらしい)
っても、今さら変えられないか。

\マークはプログラムやTeXなどで頻繁に使うからね

Java ってよく知らないんだけど、文字列型が Unicode になってるから
国際化が楽、とか聞いた記憶があるんですが、本当の所どうなんでしょう?

文字型は 16 bit 幅? UTF-16 でサロゲートペアで BMP 外の文字を
扱うんだとしたら、Windows のMBCS 処理みたく文字列操作の関数とか
いろいろヤヤこしそうだけど、そういうのもスッキリしてるのかしらん?
どうせメモリなんて数 GB 積める時代だし、文字型 = 32 bit として、
内部表現 UTF-32 などにしたら CJK Extension-B 領域とかも楽に処理
できそうだなー、なんて思うんですが

知らないなら語るな。

半可通が跋扈するイソターネットはここでつね？

Win32APIにUTF-32版さえ加わってくれればUTF-32を使うんだがなぁ。

http://pc5.2ch.net/test/read.cgi/tech/1109171258/
のスレでやればいいじゃん

日付、通貨、文字の方向、文字のソート順
単に文字コードだけの問題じゃないんだよね・・・

>>17
外国語のソートで先頭のtheとかaとか冠詞を無視するやつがあるね。
ラテン語なんぞ性別無視してソートできるのかな。

>>17にあることなら
ほとんど解決できる問題だね。

Javaなら大抵国際化に対応してる感じだね。

Currencyクラスで通過を設定できる
Localeクラスで国や言語を設定できる。
Localeクラスのフィールドにはすでにいくつか素十ヶ国の言語、国を
表すオブジェクトが用意されており知られた国のロケールは即座に簡単に対応できる。
Dateクラス、CalendarクラスのコンストラクタにもLocaleクラスの
オブジェクトを設定することで国毎に異なる日付フォーマットを
簡単に設定できる。

ResourceBundleクラスで
プロパティファイルを言語毎にわけて管理できる。
config_ja.properties
config_ja_JP.properties
config_us.properties
みたいな感じで

あとは各国の言語に詳しい人間に任せれば済んでしまう問題だね。

> Javaなら大抵国際化に対応してる感じだね。

冗談キツい

言語・ロケールさえ決定してしまえばどうにかなると思っている英語圏に人間が多いのが痛い。
日本語でもShift_JIS、EUC-JP、JISなど複数の文字エンコーディングが混在していることまで
アタマが回ってないとしか思えない実装が多いな。

あと、何でもかんでも国際化すりゃいいってもんでもない。
本文が Shift JIS な出力データに、勝手にプログラムが勝手に UTF-8 な日本語で付加情報をつけたり･･･。

subversion、おまいだよ（ｗ

文字のソートって難しそうだけど、データベース関連とかどうやってるの？
日本語や中国語が混在したテキストで画数順とかに並べるのって簡単なの?
例えば読み順で並べ替えとか簡単にできるような仕組みがあるんですか？

Win32 ソフト開発しかやってないうちは Unicode コードポイント順に
ソートしてるんだけど、東欧のアクセント文字とか中国語とか、かなり
デタラメに並ぶので非常に評判が悪い

Unicodeの文字照合ってTRになってたろ。

TR って何?

Technical Reportsのことではないかと。
http://www.unicode.org/unicode/reports/

http://pc5.2ch.net/test/read.cgi/linux/1105419571/562-566

GB 18030 対応ってどうよ?

中国市場で売るには、GB 18030 エンコードをサポートしなきゃ
だめよん、って法律があるって聞いたんですが、実際に発売中止に
なったという話は Windows ME 以外には聞いたことない
ユニコードすら通らないアプリも多いんだから、今中国で売ってる
ソフトが全部対応済みとは思えんのだが…

このスレ意味わからん
簡単に説明してくれ

>>28
libcレベルの話ならwchar_tが4オクテットあるシステムならGB18030なlocale
を用意すればOK。wchar_tが2オクテットしかないWindowsについては知らん。

>>30
Windows は wchar に格納されるのは UTF-16 エンコードされてるんで
コード自体は問題なく格納される。サロゲート ペアの文字もエディット
コントロールなどでちゃんと1文字づつ編集できる

なのだが問題はOSのUIが標準で使ってるフォントに GB 18030 で拡張
された文字のグリフが入ってない事。データを渡しても□□□□
みたいに表示される(.NET Windows Form のデフォルト フォントもそうだ)

非Windows 系のOSの標準UIフォントってちゃんと多言語対応してんの？

GB18030サポートパッケージとそのSDK入れれ
簡体字中国語版Windowsには標準で入ってるんだろ

GB 18030 インストールすると SimSun-18030 ってゆーフォントが追加
されるんだけど、ダイアログとかにそのフォントを使ってやらないと
ダメじゃん。自動で Tahoma に Fontlink してくれたらいいのに

で、それなら、という事で UI のフォントを全部 SimSun-18030 固定で
作ると、小サイズの英文や日本語のビットマップが入ってないので、
今度は 8 - 9 pt の非中国語表示がガタガタになるという
(＋ Simsun (Founder Extended) だと表示できる非BMPのコードポイント
の表示もダメになっちゃう)
あちらを立てればこちらが立たず。Longhorn 待ちというのがFA？

メニューがOSによって英語になったり日本語になったりするソフトはどのようにすれば作れるのですか？

>>34
WindowsでもLinuxでもSunOSでもMacOSでも動くプログラムの作り方？

GetLang()="日本語"なら日本語のメニューを作成する
GetLang()="英語語"なら英語のメニューを作成する

>>34
.NET だと言語サブフォルダにUIだけ含めたサテライトDLL入れて実現可
フレームワークが勝手にOS言語拾って切り替えてくれる
EXE 置いてあるフォルダの下に ja-JP とか en とかあったらたぶんそれだ
MFC も同じような感じで言語DLLを拾ってくれる機能があったはず

Mac や Linux はどうやってんの？

C++Builderの場合はどうしたらよいのでしょうか？

>>37
gettext
英語の文字列を埋め込んどいて、それを元に引っ張ってくる感じ

>>33
あれ、リンクしてくれなかったっけ? と思ったらMingLiU-HKSCSとごっちゃにしてた
スマン

>>37
Win32にでも言語の数だけリソース入れとけばOSがテキトーに選んで拾ってくれる

そーいやぁ想像を超えるすごい国際化してるソフトを思い出した
値段を入れる欄に100と入れると自動的に\100と表示される
でもって同じソフトを英語OSにインストールしてそのデータファイルを
開くと、同じ物が$100と表示されるという

どうせ実はｴｸｾﾙというMSに対する皮肉と見た

テキストファイルでも100円が100ウォンに化ける罠

>>41
そういやーそうだった
しかし VS .NET 2003 になっても未だにフル Unicode でソース
やらリソース書いてすっきり国際化、ってわけにはいかんのは
ちと残念
.NET の .cs ファイルとかデフォルトで Unicode エンコーディング
にしちゃえばいいのに、とか素人は考えるのだが...

Visual SourceSafe 6.0 がUTF-8非対応っていう罠があったりするんだよね。

オープンソースで国際化の参考になるやつはありますか？
（OpenOfficeとかFirefoxとかではない、単純で理解しやすいものが希望です）

ワードプロセッサのような、言語ごとの記法(禁則処理とか、ハイフンとか、
縦書きとか双方向テキストとか)までは考えなくていい、単なるメッセージ
のみの置き換えのことなら、それこそgettext使ってるものならなんでも
よいでしょう。

おまいら、Unicode でデータ書くとき UTF-16 にする? それとも UTF-8？
あるいはまんま UTF-32?

UTF-8 にすると非ASCII 文字は3バイト以上になるから…と思ってると
案外ASCIIの割合が大きくてファイル サイズは大して変らないって
経験あり
Windows メモ帳の"Unicode"は UTF-16 LE (BOM付き)だから、なんとなく
それにあわせてるが、世の中一般ではやってるのは何？

UTF-32は聞いたことがないな

UTF-8。
UTF-16はもう死滅すべきものではないかと思うんだが。

UTF-8はBOM付ける派？ つけない派？

自分はブラ着けずに寝る派です

>>53
地味に面白い。
おまえのようなセンスの人間と仕事をしたい

>>50
つ【http://www.unicode.org/reports/tr19/tr19-9.html】

>>53
や・ら・な・い・か？

せっかくインターネットをしてるのに情報源はほとんど日本ばかり。
寂しい話だよな。ネットやマシンについて詳しいのに　だ。
インターネットでやり取りされる７０％以上は英語だ。
遊びで使うならともかく　最低限のこととして言語部の国際化くらいはしようぜ！

>56
日本語覚えてから言え。

>>56
同意　インターネットをすると日本はひょっこりひょうたん島って感じやな

>>56
お前が言っている国際化とソフトウェアにおける国際化は全くの別物なのだが。

WindowsでOSの言語を知りたい場合、どのようにすればよいのでしょうか？

マイコンピュータのところを見て、
我的電脳って書いてあったら中国語版。

WindowsでWindowsAPIを使ってOSの言語を知りたい場合、どのようにすればよいのでしょうか？ 

GetLocaleInfo

Windows OS の言語とは別にコンパネから「標準と形式」、「場所」の2箇所の
設定ができるけど、これを取得するにはどうすんの?
あとマルチリンガル ユーザ インタフェースってのが MSDN にあるけど
これ入れると GetLocaleInfo ってだまされるの？

Linuxの現在のOSの仕様言語を取得する方法を教えてください

仕様言語って？

犬板に帰れクズ

こまるのが日付の表示フォーマット
m/d/y
なのか
d/m/y
なのか表示だけでは判断できない事がある

>>68
そんな貴方にISO 8601。

>>65
localeのことなら、プロセスごとに指定できる。
分野(日付時刻・エラーメッセージ・通貨単位・文字照合規則etc.)
ごとに個別指定もできる。

C++のロケール（stl::locale）回りについて、詳しい参考文献かサイトがあれば教えてください。

12-04-03

mm/dd/yy
dd/mm/yy

多国語に対応する場合、どうやるのが定石ですか？
リソースDLLを各国語ごとに用意して起動時に読み込み？

UNICODEも一つの方言になりかねなさそうだな

yy/mm/ddもあるよ

>>72
dd/mm/yy は少数派な希ガス。

>>73
MFC開発関係のスレで聞いた方が良いと思うぞ。
ちなみに、先日、客にDLLを作成しますと言ったら、工数がかかるから止めてくれと言われてしまったよ。
とほほ。

C++Builderを使っています。

なら、C++ Builderのスレか、Windows開発のスレだ。

Delphiでの国際化対応の話はここでいいのでしょうか？

それではどうぞ

>>77
リソースをDLLに分けるのってアホらしくない？
UIかえたらそのつど整合性保たなきゃいけないし。

Unicodeでソース内部で保持しておいて
言語とID指定してmapから取り出すほうが簡単なんだけど...
ただ、リソースの編集とかはできなくなりますが...

別にexeに統合したってかまわないし

ＷｉｎｄｏｗｓＸＰで中国語にトライしています。
Ｗｉｎｄｏｗｓの国を判断し、フォントと文字を切り替えるようにしています。
日本語でコンパイルし、地域と言語オプションの地域オプションと詳細を中国語にし
て起動すると、
簡字体中国語が正しく表示されません。
中国語でＣＢｕｉｌｄerを起動し（文字がくちゃくちゃ）調べると、フォントプロパ
ティの文字セットのところが空白になっていました。
もともと日本語にしてあったので、当然かもしれませんが。
そこでフォントプロパティの文字セットを中国語にすると表示されました。
フォントプロパティの文字セットをソフトで切り替えたいのですが、
どなたかフォントプロパティの文字セットを設定する方法ご存じありませんか。

>>82

OSのバージョンによって、読み出されるリソースの優先順位が異なるからさ。
NT4.0とか、Win2kのインターナショナル版とか、ちゃんとサポートしろといわれたら
DLL決めうちでリソース選択するしかない。
英語+日本語ぐらいならあんまり変なことにならないけど、四カ国語ぐらいサポートする場合はさ。

が、確認してないけど最新のMFCでは問題ないという噂もあるけどさ。

http://www.codeproject.com/cpp/mult_lang_support.asp
(AfxSetResourceHandleを使って)上記通りにやると
ツールバーのツールチップ、ステータスバー
の文字列がおかしいな...とVC6で思ってて
VC7.1で試したらあっさりOKに...

>>83
たぶん文字(Unicode)リソースをexeに統合という意味だよね。
DLL統合してもメモリからロードできないみたいだし...orz
>>85
そんな事情があったのね。thx.
とにかく明示的にロードしろと、次のバージョンではすっきり記述できるようになってたらいいな...

scpとrsyncのファイル名に関するI18Nを目論んでいます。
とりあえずはcygwin(cp932)とLinux(EUC-JP設定/UTF-8設定どちらでも)とMacOSXで
cp932相当の文字セットが扱えることが目標です。で、以下のどっちでやるのが正義(ぉ)でしょう?
1) ローカル／リモート双方で、環境依存文字コード⇔UTF-8 NFC 変換する。
⇒ 正義っぽい。でもリモート側も対応バイナリをインストールしてないとNG。
2) ローカル側でローカル⇔リモート変換する。リモート側は単なるバイト列として扱う。
⇒リモート側が未対応でも動く。でもぶっちゃけ美しくない。

ガキ。随分安直な正義だな。あとそれのどこがI18Nなん? なんか違うような。

どうもNGワード使ってしまったみたいなんで、そこはスルーで。
(本気で「正義」と思ってるわけじゃないです。為念)
あと、一応多言語対応の枠組みが定められればI18Nになると思ってたんですが、
誤解があったらご指摘ください。
ttp://www.atmarkit.co.jp/icd/root/63/50872763.html
ここからはそれほど外れてないと理解してるのですが。

ﾎｯｼｭ　ﾎｯｼｭ

test

ほｓｙｒ

http://m17n.org/aboutus.ja.html

MinGWで作成されてるアプリケーションのメッセージカタログを翻訳したら、作者に
「MinGWは国際化でいろいろ問題あるから、どうにかしようと思っている。gettextかなぁと思うんだけど、どう？」
と軽く聞かれました。

といってもプログラミング上の国際化の手法とかよくわからないので、どなたか詳しい方、
教えてもらえませんか？

gettextでバッチリならそれでいいですし、他にもっと楽/現実的/今風なものがあれば、
それを知りたいのです。

Windowsってややこしいよ。
日本語版Windowsってコードページ932(Shift-JIS)だけど、この設定って具体的に
どこに影響してるの？？
この設定がShift-JISだから、RegsiterClassAで登録したウィンドウの文字絡みの
メッセージ(例えば、WM_CHAR)などでは、Shift-JISコードでやってくることになるの？
これを変えれるかわからんけど、日本語EUCに変えたら日本語EUCでメッセージやってくるのかな？
他にもSakuraエディタ？だけっかなで、フォントの情報みるとMSゴシックとかUnicodeフォントってなってるんだが、
これも意味わからん。どこでどんな変換されてるのか。

>>96だけど、
Sakuraエディタじゃない、フォントインストーラSakuraだった。
後、MSゴシックはShift-JISになってた。嘘だった。

>>96
簡体、日本語、韓国語、ドイツ語、英語、の共通アプリ開発したときに調べたが。
その程度でややこしいとか言ってたら、Windowsで国際化対応アプリは作れないぞ。

>>96
地域・言語の設定の影響がありそうなところををざっと考えて
WideCharToMultiByte/MultiByteToWideChar（CP_ACP/CP_THREAD_ACP）や
日付・時刻の書式関数、文字列比較、CharNext/CharPrevとかが思いついた。

>>96だけど。まじ、むずいよ。ググっても日本語の資料は余りない。英語読むしかないなら読むけど。
WindowsのMUI版あれば、色々実験できるけど。今は日本語版でGetLocaleInfoやらGetACP,GetOEMCPなどを
地域オプション変えたらどう変わるか調べてる。システムロケールからユーザーロケール、スレッドロケールなどややこしい。
DrawTextなどで文字列描画するときは、コードページ関係ないのかな？選択したフォントの文字コード次第かもね。

Windows2000以降OS内部はUnicodeになったらしいけど、まだ、MSゴシックなどのフォントの文字コードはShift-JIS
っぽいから、どのみち、コードページ変換テーブルは必要ってことか？

俺にはややこしすぎてギブアップ。

bcc32でコマンドラインプログラムを作成しているのですが、ソースコードをユニコードで書けば
できあがるソフトもユニコードになるのでしょうか？

gettext、特に PO ファイルの書き方について詳細に解説してる日本語のページとか書籍って無い？
GNU のマニュアルを読んでみたけど英語力に自信なくて…

>>101
否。

ソースコードの文字コードと実行時の文字コードは無関係。
wchar_tとか、あるいはWindows APIならTCHARとかのことを知れ。

>>102
http://www.ring.gr.jp/pub/doc/gnu-info-j/gettext/gettext-ja.html
かな？
http://www.amazon.co.jp/exec/obidos/ASIN/4797820209/
にも書かれている。

>>104
日本語訳なんてのがあったんﾃﾞｽｶ…　ありがとう

Windowsの現在の設定言語はどこで取得できますか？

GetSystemDefaultLangIDあるいはGetUserDefaultLangIDだろう。
なおLangIDではなくLCID版もある。

setlocale で利用可能なロケール文字列の一覧を取得する標準的な方法はありますか？
とりあえず Linux の locale コマンドの実装をみてみると
ロケール情報が入っているディレクトリの中のファイル名から一覧を取得しているようです。
できればもっとポータブルな方法を探しています。Windows でも使えるような。
また、ロケール文字列のフォーマットについては何か C/C++ の標準で決まっているのでしょうか？
ロケール文字列についてはプラットフォーム依存ですか？

C++Builderなのですが、メニューを2つの言語に対応させるには、どのようにするのは、標準的な方法なのでしょうか？

>>109
C++Builderスレできけ

サンプルで入っている方法（フォーム丸ごと切り替え）使うか、
コンポーネントやライブラリを使うか

下記の関西学院大学の国際交流・国際協力支援団体　クラブ ジョーディー（CLUB GEORDIE）
の裕福な医者の娘さんは、
日頃はブランド物を重装備してボルボを乗り回しておりますが、
貧困問題や難民問題に関する活動を行うときは きちんと地味な格好を装っている
たいへん良識ある女性です。
また、高橋の愛ちゃんらの陰口を言いふらして追い詰めていた　たいへん心優しい女性です。

★TPOに合わせてブランド物と地味な格好を使い分けているか、みんなで注目しましょう！
★人の陰口を言っているか、みんなで注目しましょう！！




>　関西学院大学　クラブ ジョーディー副代表：原田摩耶（病院勤務）

関西学院大学　クラブ ジョーディーHP　http://www.club-geordie.com/dantaigaiyou.html
原田整形外科HP　http://www.hh.iij4u.or.jp/~ryhara/

普通に妬みやんけ

最近はUTF-8で書くのがはやっているのですか？

うちの開発の害虫さんは、英語が出来ません。
で、保守は海外に出したいと思ってます。

ソースのコメントはどうすればよいでしょうか。

国内に出せばおｋ

予算がありません。

英語でFA
小学生じゃないんだからさ

コメントはつけない

i18n の話をしているところで
ソースの文字コードだの、コメントの言語だの
素っ頓狂な話を始める人が後を絶ちません。

ソースの文字コードは意外な盲点だと思うぜ
そりゃメッセージカタログ化するのが正道だけどさ

>>109
gettext for delphiと、TnTでいけるかも

>>121
>>109ではないのですけど、これですか？

GNU Gettext for Borland Delphi, C++ Builder and Kylix
http://dybdahl.dk/dxgettext/

よさそうですね。
つか、gettextってDelphiからも使えたのか・・・
GPL感染とかってないのかな？

>>122
LGPL版使うとか

国際化対応すれば、登録済みのデータも自動翻訳してくれると思っているアホ上司。
それ真に受けて顧客に説明してしまった馬鹿営業。

あのプロジェクトどうなったかな〜

プログラムをunicodeで書けば、unicode対応の環境ならどこでも書いたとおり出力できますか？

>>125
出力に使うライブラリの対応も必要でしょう。

どのWindowsにも必ず入っているフォントってありませんか？

SYSTEM_FONTやDEFAULT_GUI_FONTとか使えば？

Windows XP & VisualC++2005 & GDI+です。
T'\' をGDI+でDrawStringするとフォントによって '\' になったり '＼' になったりします。
T'男' をDrawStringしてもちゃんと表示されるフォントでも T'\' が '＼' になるのは解せないです。

これはやっぱり選べるフォントを制限したりするしかないのでしょうか？
それとも T'\' を T'￥' に変換？
日本語だけならこういう対策もいいのですけど、
サポートする全部の言語で何か対策しないといけないのでしょうか？

フォントの問題だろうな。
0x5Cを半角円記号として表示させたければ、
そういうフォントを選べばいいだけだろ。

> T'男' をDrawStringしてもちゃんと表示されるフォントでも T'\' が '＼' になる
欧文フォントを指定しているが、フォントリンクで日本語の文字も表示できている状態だと思う。

フォントも書かずに、質問とな！！

(Unicode的に)本来 U+005C は REVERSE SOLIDUS (バックスラッシュ)。
YEN SIGN に見えるのは、MSが過去の互換性とのかねあいで、あえてそういうフォントにしているだけ。
ちなみに本物の YEN SIGN は U+00A5。これは、Unicodeを扱う場合ならフォントを問わないはず。
(対応するフォントが無い可能性はあるかもしれんが)
CP932の範疇でやるなら「￥」が無難と思われ。

皆さんありがとうございます。

>>130
そういう理由だと思っているのですが、言語とフォントはユーザーが指定できるので、
その対策があるのかなと思った次第です。

>>132
現在通貨記号はlocaleconvで取得したlconvのcurrency_symbolで拾ってきています。
円記号を持ち出したのは一例で、本来やりたいのは、ロケールに応じた通貨記号を出したいということでした。
currency_symbolはcharですしUnicode的にはよくないのかもしれませんけど。
locale=jpnの場合はU+00A5が得られるような適切な取得方法って他にあるのでしょうか？

そうそう、全部のフォントで確実に表示されるというところまでは求めてないです。
表示の大半は半角数値なので欧文フォントを指定することが多いと思われます。
jpnの場合にMS明朝とMSゴシックの２つだけに縛られてしまうのはあまりに酷いと思ったので。
大半のフォントで\が出るならOKです。

Win32 APIのGetLocaleInfoWで日本語を指定するとU+A5を取得できた。
Aなら5Cになるし使えると思う。ただ、標準Cライブラリとの対応付けが面倒かもしれない。
#include <windows.h>
#include <iostream>
#include <locale>
int main()
{
std::wcout.imbue(std::locale("")); //VC++ 2005だとだめだったと思うけど
WCHAR c[6];
GetLocaleInfoW(LOCALE_USER_DEFAULT, LOCALE_SCURRENCY, c, sizeof c / sizeof c[0]);
std::wcout << std::hex << static_cast<UINT>(c[0]) << L'\n';

LCID lcidja = MAKELCID(MAKELANGID(LANG_JAPANESE, SUBLANG_DEFAULT), SORT_DEFAULT);
std::wcout << std::hex << lcidja << L'\n';
std::wcout << std::hex << GetUserDefaultLCID() << L'\n'; //日本ならlcidjaと同じ値になることの確認

GetLocaleInfoW(lcidja, LOCALE_SCURRENCY, c, sizeof c / sizeof c[0]);
std::wcout << std::hex << static_cast<UINT>(c[0]) << L'\n';
std::wcout << c << '\n';

CHAR mbs[6];
GetLocaleInfoA(lcidja, LOCALE_SCURRENCY, mbs, sizeof mbs);
std::wcout << mbs << '\n';
std::wcout << std::hex << static_cast<UINT>(mbs[0]) << std::endl;
}

MBCSのプログラミングってアホみたいに複雑でワロタ。
http://msdn.microsoft.com/ja-jp/library/zz3x65c7(VS.80).aspx

こんなバグ量産するような方式は使ってられない。
もうWin9xなんて切り捨てていい時代だから、
これからはUnicodeコンパイル一本でいくべきだと思った。

>>136
Unicodeが簡単だと思っているなら大間違いだ。
むしろUnicodeの方がたちが悪い。

>>137
Unicode + その他たくさんの野良コード扱うより
Unicode 一本に絞った方が簡単になるのは自明だろう。
本当にたちが悪くなると思ったんなら
是非ともその理由が知りたいところだ、書いてくれないか。

rubyがSJISを使える理由を考えてみたらどう？

アホだな。内部処理をUnicodeにするかMBCSにするかの話だろ。
１文字２バイト固定のUnicodeの方がバグが少なくなるのは自明だろうが。
I/FがUnicodeのCOMコンポーネントを使うならなおさらだ。

漢字の字形を区別する必要があるならSJISその他の日本語用文字コード、
それに目を瞑ってでも複数の言語を同時に使う必要があるならUnicode。
箸とスプーンは使い分ける。

>>140
Unicode(UTF-16)は2バイト固定じゃないぞ。
本来は21bitの文字コードだから、2バイトで足りない文字は4バイト使う。
複雑度はMBCSと変わらん。

>>141
いやだからー、外部表現と内部処理の話は別な。
内部Unicode処理でも出力や表示にSJIS使うこともできる。

>>136で言ってるのはUnicode/MBCSの両方でコンパイルできるように#ifdef切ってソース分けるのはもう嫌だということ。
なぜならMBCSではバイト単位の文字配列を文字境界を意識して複雑なプログラミングをしないといけないからだ。
Win9xに対応するためだけにそんなバクチを打ってられるかということだ。

>>142
いやそういう意味じゃなくて内部Unicodeなら文字配列が文字単位だから
１文字１要素として扱えるでしょという話。

>>143
なにを言ってるのか意味がわからん。
MBCSで1バイト単位の配列を使うのも、UTF-16で2バイト単位の配列を
使うのも一緒。1要素で1文字が表せるとは限らない。

>>143
外部のSJISを内部のUnicodeに変換する時点で字形を
区別できなくなるものがあるでしょ？
逆向きでも似たような問題が出るし。

>>144
Unicodeならwchar_tを使うから必ず１文字１要素。
MBCSならcharだから１文字は１要素か２要素か分からないので、
バイト配列の要素がリードバイトかどうかを_isleadbyte()などを使って調べる必要がある。

>>146
Unicodeは合成文字があるから１文字１要素ではない。可変長
文字区切りはステートマシンで判断する必要があるが、アルゴリズムは
MBCSより複雑

よってMBCSで十分。
UNICODE信者はカエレ。

そこでMBCSなUnicode符号化、UTF-8ですよ。

>>146
UTF-16は可変長コードだと何度言えば…
wchar_tでも1文字1要素ではない。1文字1〜2要素。

固定長と勘違いしてる人多いな。

>>150
> wchar_tでも1文字1要素ではない。1文字1〜2要素。
そんなこと決まってるのか？

元々 wchar_t は１文字１要素であるべきなんじゃないの？
Windows だと歴史的な理由で UTF-16 になっちゃってるだけで。

そんなこと決まっていないね。
151の言う通り。

もっとも、例えUTF-32でも結合文字列があるから、
場合によっては1文字1要素として扱えないこともあるはず。

WindowsでいうUnicodeはUCS-2の範囲だから2バイト固定と考えて良い。
だからwchar_tは１文字１要素。
他のOSは知らん。

>>153
残念でした。Windows 2000からUTF-16です。
少なくともDrawTextやWideCharToMultiByte、UniscribleあたりはUTF-16に対応している。

>>154
WindowsではUTF16といってもUCS2の範囲の文字しかサポートしてないということじゃないのか？
でなければUNICODEコンパイルではisleadbyte()が使えないのに、
もしwchar_t配列の中に2バイトと4バイトの文字が混ざっているとしたら
どうやって文字境界を判別できるというのか。

サロゲートペア入門
Vistaから増えたUnicode環境で使用できる日本語漢字の対応方法
http://codezine.jp/a/article/aid/1592.aspx

サロゲートペアよりも合成文字の方がやっかいだと思う。

ケンタッキーフライドチキンとか

サロゲートと結合文字の処理は.NETでも開発者まかせみたいだし、ある程度妥協が必要かも。

・サロゲートペア304文字はどうせマイナーな漢字だけだから入力の時点で強制削除。
・結合文字はJIS0213に規定されてる200種類ぐらいを等価の１文字に置換。その他は結合せず放置。
とした上でwchar_tの１要素１文字を実現するのはどうか？

どこかに真面目に処理してる実装例はないものかね。

Vistaのメモ帳（っていうかEditコントロール？）は真面目にやってるね。
「は」と「゜」の合成で「ぱ」にするとちゃんと1文字になって、BackSpaceで削ると
「は」になる。

windowsのwchar_t(UCS2)を素直に使おうかどうか迷ってます。
あまり問題にならないなら使いたいのですけど、
特定の言語では困るなんて事例があれば聞きたいです。

>>155
IS_SURROGATE_PAIRか何か

VisualStudioでは各国語のリソースDLLを作るのが普通なの？
gettext的な手段の方がユーザサイドで対応できる分、優れている気がする。

リソース追加だってユーザサイドで対応できるだろう。
俺が配布してた日本語・英語対応のツールでも、台湾人が勝手に
中国語リソース追加して再配布してたよ。

敷居が上がる上に色がつくけどな

WindowsのサテライトDLLは便利なんだが、ユーザー別で指定した言語
にしたい場合(例:日本語OSで一時的に英語表示で動かしたい等)には、
むしろ邪魔なんだが、サテライトDLLをロードしてくる挙動をMFCアプリ
ケーション内でオーバーライドしたい場合、なんかいい方法を知ら
ないか？

http://msdn.microsoft.com/ja-jp/library/8fkteez0.aspx

ユーザーのデフォルト言語を設定するSetUserDefaultUILanguage()なんて
APIは存在しないので、とりあえずCWinApp派生クラスのコンストラクタ
内で、

SetThreadLocale(MAKELCID(MAKELANGID(LANG_ENGLISH,SUBLANG_ENGLISH_US),SORT_DEFAULT));

とかやったみたが、ダメだった。

＞gettext的な手段
ってなに？

ttp://www.sepia.dti.ne.jp/inoue/memo/gettext.html

ｻﾝｸｽ

メッセージカタログってのもあるよ。

サロゲートペアや合成文字を処理するのに使う.NETのSystem.Globalization.StringInfoクラスみたいなのを
Win32で記述したものはないんですかね。

日本語化職人が見てるかもしれないから残しとく

gettextを使ってるソフトの日本語化(Win)

・.moファイルとは日本語翻訳ファイル（バイナリ形式）
・編集するのは.moを変換する前の.poファイル（テキスト形式）じゃないと出来ない。
・PoMoConverterを使うとGUIで分かりやすく.moと.poを相互変換できる。
・.poファイルの編集はPoedit（テキストエディッタで開いて直接弄っても出来る）
・Poeditで文字化けするときはリンク先http://wiki.livedoor.jp/lab1092/d/Tips011a
・.poから.moへの変換はPoeditでもPoMoConverterでも

まとめ乙

多言語対応の必要があって、gettextについて調べてみた。
ググってすぐ見つかる例では英語の文章をそのままキーにしてるみたいだけど、
例えばキーが動詞+目的語みたいな英文の場合、
GUIのボタンのラベルの場合 -> 多分直訳でOK
その他の表示メッセージの場合 -> 多分〜して下さいと訳す必要がある。
というような文脈による違いがあると思う。
そのへんはどうやって解決するのがスタンダードなやり方なんだろう。
メッセージのカテゴリを示すような複合キーがどうしても必要な気がする。

そりゃメッセージごとにキーを定義して文章本体はカタログに移すんでしょ。
キーはたとえば
MSG_HOGE_HOGE (普通のメッセージ), TIT_HOGE_HOGE (ウィンドウタイトル),
TT_HOGE_HOGE (ツールチップ)とか。

>>175
なんか違うツールの話をされてる気がする。

gettextでもソースに埋め込むリテラルを英文じゃなく、
抽象的なキー文字列にすれば、曖昧さはなくなるだろうけど、
そんな例はググってもでないので一般的じゃないんじゃないかと。

だったらそれは君の要求が一般的じゃないということでは。
何をもって一般的というかは人それぞれだけど、君の定義ではそうなんだろう。

プログラムをUnicodeかMBCSかどっちで作るか迷う
いまどきMBCSもないよな？

いまどき、MFCのサテライトDLLで多言語化を実装してるんですが、一つ問題が発生しました。
リソースの識別子の最大値が65535となってて、これを超える場合っていったいどうすればいいんでしょうか？

いまどき、MFCのサテライトDLLで多言語化を実装してるんですが、一つ問題が発生しました。
リソースの識別子の最大値が65535となってて、これを超える場合っていったいどうすればいいんでしょうか？

ちょｗ

Windows、Linux両方対応で
Unicodeを扱えるアプリを作ろうと思っているんですが、
文字型には何を使えば良いのでしょうか？

UTF-8を使ってchar。 Windows APIを呼び出すときは
W系APIを使う必要があるから、charからwchar_tに変換。

これでいいのでしょうか？

age

>>182
UTF-8 なら uint8_t だろ。
Windows API 呼び出すんなら UTF-16 だから uint16_t だろ。
単純に考えればな。

char や wchar_t 使ってると符号やサイズの違いで混乱しそうだ。

c++0xではchar/char16_tだな
VCは今後どうする気なんだろう

>>182
理想的には両プラットフォームで wchar_t かな。サイズが違うけど、そ
こは違ってもいいようにコードを組む。

現実的に考えると、Windows は wchar_t (UTF-16)にして、Linux では
wchar_t を使わずに uint16_t (UTF-16) にするとか。ICU がそんな感じ
で、双方に対して UChar という型を typedef している。

でもwchar_tは互換性が・・・

wchar_tで国際化といえば、
UTF-16かUTF-32になるとおもうけど。

そうすると、文字列のバイトの中に\0が含まれることになる。

なので、printfとかfopenとか、そういうなじみのある関数が全部使えない。
もちろんcharとwchar_tで型が違うから\0の問題以前にコンパイルエラーだけどね。

wprintfは標準にあるよ！

だけど、wfopenは標準にないよ。

だから日本語パスを使うときはいちいち変換しなきゃならない。

さらにいうのなら、Linuxなんかではシステムのエンコードが
UTF-8になっており、これならfopenでそのままファイルが開ける。
だからソースコードをほとんど変更することなくUNICODE化が可能。

そのせいで内部データ型としてcharのままなソフトが大半
1バイト文字圏の人にとっては何もする必要がなく、
そういうソフトが今も作られ維持されているので
日本語化という作業がいつまでたってもなくならない。
　　↑
※この日本語化というのは、文字を1バイトづつ処理したりとか
文字列の長さ＝バイトであつかうような間違った処理の修正

普通に書いたら、世界各国で何の問題も無く動いた。
むしろ問題起こす方が難しいって状況になるのはいつの日か

>190
西欧でも全部が1バイト範囲内にはならないんだから真面目に UTF-8 で書いていれば
※に書かれているような作業は必要ないんじゃない？

UNIXのファイル名にエンコーディングなんか決まってないが。
/と'\0'以外何でも使えるバイト列。

問題は、UTF16、UTF32の文字を1バイトづつ見たときに
\0 が含まれているってことなんだがな。

> 真面目に UTF-8 で書いていれば

それが大変な作業なんだろ。
システムのファイル名がUTF8だと保証されているわけじゃないし、
標準ライブラリに含まれてるわけじゃないし。

UTF-8でもOSXだとNFDになってるからまた面倒だったり

バカしかいないねこのスレ

>>196
それを書き込んだ時点でオマエのバカの一員になるわけだが。

文字コードがUTF8でもUTF16でもいいんだけど、
完璧に一文字ずつ操作する方法ってどうするの？
もちろんNFDもちゃんと考慮する。

イケメンしかいないねこのスレ

UTF32なら1文字32bitだから、コードが書きやすい！と
思っていたら、合成文字なんてのがあるのなorz

>>198
NFDでもNFCでも一文字ずつ操作する処理は同じ。
NFCでも合成文字やdecompositionは出て来るから文字は可変長、NFDの場合に比べて頻度が減るだけ。

> NFDでもNFCでも一文字ずつ操作する処理は同じ。

（苦笑）

同じってのはわかったから、そのやり方をどうやるかが
質問の内容だろう。

>>202
ステートマシン回すのは必要なんだけど、ここのスペースでは書けないでしょ。
OSに備わってる機能使っても良いし、ICUで言えばBreakIterator使ったりしても良い。
最適化したり、1から書いたりするのはその辺経験してからの話

>>203
ウザイなｗ

じゃあ俺が変わりにどうやるか教えてあげよう。

１．OSに備わっている機能を使う（それが何かは、誰かが説明してくれるだろうさｗ）
２．ICUを使う場合はBreakIteratorを使う。

これぐらい、小さなスペースでかけないものか？

これを参考にして、他の方法を書いてみな。

どちらかというと >>202=204 の方がウザい

なんでバカが上から目線なの?

自分のことか？

LinuxならUTF-8で書けばいいの？

Windowsでのプログラミングですが、unicodeでプログラムを書けば各国語版のWindowsで動くのでしょうか？

プログラムをunicodeで書くとはどのような状況のことでしょうか

動くだけなら動くでしょう
しかし実用に耐えうるかどうかは別問題
国際化は動けばいいというだけのものではありません

Windowsでタイムゾーンと夏時間が有効かどうかを調べる方法を教えてください。

GetTimeZoneInformation

typedef struct _TIME_ZONE_INFORMATION {
    LONG Bias;
    WCHAR StandardName[ 32 ];
    SYSTEMTIME StandardDate;
    LONG StandardBias;
    WCHAR DaylightName[ 32 ];
    SYSTEMTIME DaylightDate;
    LONG DaylightBias;
} TIME_ZONE_INFORMATION, *PTIME_ZONE_INFORMATION, *LPTIME_ZONE_INFORMATION;

国際化ねえ

internationalization hey

gencat

ログ復活

英語版Windowsを使っているのですが、メニューなどが文字化けするソフトと、きちんと日本語で表示されるソフトがあるのですが、
英語版Windowsでメニューなどが文字化けしないようにするにはどこに気をつければよいのでしょうか?

>>219
自分で国際化対応の機能を作らない。
日時の表示、金額の表示、フォント設定、単語の順番。
それらにOSやライブラリで提供されている機能を使う

ソースコードに日本語を書かない。
表示される文字をソースコードに書かない。
すべてプログラム外から取ってくる。
Unicodeを使う。Windows9x系は諦める。

UNICODEとか国際化のうちじゃ極一端しか役に立たないよな。
それよか順番を指定できる出力機能が重要だよね。

format("%2 %1") % "World" % "Hello";

とやって"Hello World"と出力されるとかね。
とりあえず外に吐き出した文字を出力させてるだけだと、
「"read"になる事ができませんでした」とか文法の狂ったとんでもないメッセージを吐く。

printfに引数の順番を
入れ替える機能がなかったことが悔やまれる。

>>222
printf("%2$s %1$s¥n","world!","Hello"); // --> "Hello world!"

>>223
あー、俺が言ってるのはC言語の本物のprintfね、ニセprintfの話はしてないから（ぷ

printf自体に実装すると、printfが重くなるから、
せめてC99とか規格改訂の際に順番指定できる補助用の
sprintf作って欲しかった。何で作らないんだろうな。

アメリカって乳児の死亡率、日本の2倍らしいな
医療技術うんぬんじゃなくて、お金がなくて病院に行けないらしい
TPPに参加してアメリカに乗っ取られたら
日本もやがてこうなるんじゃないか。

国際化とか言って、レベルの低いほうに合わせてどうするんだ…

ネトウヨ王に俺はなるまで読んだ

気になるか？
まあ、お前ごときどうせ株なんか知らんだろうし、どうにも出来んし説明してやろう。

崩壊してんのは、株取引のほうだ。
すでに年金すら韓銀砲で溶けてる。今なお溶かし続けてる。
後、多分だが金持ってる外国人や富裕層はとっくに韓国から亡命（まあ似たようなもん）してる
どこまで持ちこたえるか知らんが、ウォンは貧弱だから安くなりすぎても、高くなりすぎても死亡
すると紙クズと化したウォンを、ハゲタカファンドに捨て値でおもちゃにされてゲームオーバーだ


そしたらまず銀行が閉鎖されて、預金が降ろせなくなるだろうな。
そこからがパニックの引き金になるだろ、あとは想像に任せる。まあしたくもないくらい地獄だろうが

韓国がＩＭＦ入り以外で、自力で浮き上がろうとしたら、これら問題をどうにかする必要があるのだが
首脳陣がそこまで脳ミソ使ってるのかまでは、知らん。


あとそうなったらおそらく円持ってる在日強制召還。これはお前らの問題だな、日本人？復興にいそがしいからまた今度な
これくらいだな、まあ後は勝手に調べてくれ。

竹島って本当はどっちの国の領土なの？(´･ω･`)

>>229
もともとは韓国領だったが、
日本の植民地支配から、
日本が勝手に領有権を主張しだした。
現在は国際的にも韓国領と認識されている。

>>230
詳しい解説サンクス
これなら韓国が怒るのも当然の気がする(´･ω･`)

ID出る板でやらないとおもしろさ半減だぞ

>>230
こんにちは半白さん

FormatMessageとunicowsは使える。
FormatMessageは引数の順番が変わってもＯＫだし、
unicows使ったらUnicodeアプリをWin9xに移植できるもんね。