C 文字列操作 新しいページはコチラ
提供: yonewiki
(→文字列文字コード変換) |
(→文字列文字コード変換) |
||
| 2,597行: | 2,597行: | ||
=='''文字列文字コード変換'''== | =='''文字列文字コード変換'''== | ||
| − | 文字コード変換は、標準関数だけでは実現できない変換になっています。自分で変換関数を作るのもありですが、既にきちんと作られた変換ライブラリが無償で配布されています。変換処理自体を作成するには、文字コードの体系の理解やエンコーディングの理解が必要です。そして、それに対応する変換処理を作るわけです。ShiftJIS CP932とUnicode UTF-16はマルチバイトとワイド文字の変換によって実現できますので、UTF- | + | 文字コード変換は、標準関数だけでは実現できない変換になっています。自分で変換関数を作るのもありですが、既にきちんと作られた変換ライブラリが無償で配布されています。変換処理自体を作成するには、文字コードの体系の理解やエンコーディングの理解が必要です。そして、それに対応する変換処理を作るわけです。ShiftJIS CP932とUnicode UTF-16はマルチバイトとワイド文字の変換によって実現できますので、UTF-8やEUCあるいはJISといった変換には変換処理の作成が必要になってきます。更に同じUnicodeでもUTF-16やUTF-32ではリトルエンディアン方式、ビッグエンディアン方式さらにはBOM(ByteOrderMark)の付加といった変換を考慮する必要もあります。UTF-16やUTF-32では常に複数Byteで一文字が表現され、その複数バイト塊のメモリアドレスの番地の小さい方から文字コードの上位バイトの情報をいれるビッグエンディアンと番地の小さい方に下位バイトの情報をいれていくリトルエンディアンがあり、その文字コードファイルの先頭2ByteにBOMという符号で、どっちの方式が使われているのかを示すものです。先頭アドレスからFF FE と格納されていればビッグエンディアン、FE FF と格納されていればリトルエンディアンであることを示します。あえてBOMを付与しないで、プログラムがどっちの文字コードが使われているか解析する方法や文書を閲覧する都度、ユーザが選択する方法もあります。UTF-8では、複数バイト使われるときには徐々にバイト数が大きくなる可変長の方式をとっていて、リトルエンディアンとかビッグエンディアンという概念がないため、BOMは不要ですが、付与するパターンもゆるされており、BOMありで統一してテキストを作成している人もいることから無意味なBOM付きファイルも存在します。また、このBOMが原因でファイルの読み取りに失敗してしまうUTF-8採用のプログラムも多いようです。どっちのファイルも読み取れるプログラムを作るのが良いですが、BOMありでは動作しないものと割りきって、BOM付きUTF-8を切り捨てていくプログラム作成者もいるように思います。こうすることでBOM付きUTF-8を撲滅することになっているのかもしれません。自分もUTF-8にはBOMは不要だと感じています。あえてBOMを付けれる出力のサポートも必要だと思うし、読み取れるようにもしときたいものですね。そんなプログラム作ったことないですけど…。 |
| + | |||
| + | |||
| + | ちなみにVisualStudioのコード編集エディタはデフォルトでは、ShiftJIS CP932が利用されます。変更するには、メニューのファイル(F)-保存オプションの詳細設定のエンコード欄の値を変えることで実現できます。行の終わり欄で改行コードも変更できます。特別にテキストの中で特定の文字コードセットのリテラルを使う必要がある以外は基本はShiftJIS CP932でいいのではないでしょうか？L""リテラルでUnicodeも使えますし。 | ||
| + | |||
| + | |||
| + | こういった文字コードの変換は、自分のプログラムだけで動作するのではなく、外部におかれた情報を読み込む、あるいは書き換えるといった動作をする場合に必要になってきます。固定の外部ファイルとのやりとりであれば、変換が発生しないように構築すると必要ないし、変換が必要であっても1種類の変換で済みます。ありとあらゆる場所からテキストを読むこむようなプログラムになると、この文字コード変換を網羅しないと利便性が損なわれる結果になります。文字コードの掃出し処理が間違っていると、文字コード破壊プログラムになってしまう可能性もありますので、自分で変換処理を作って、書き出すプログラムを作るのはかなりの知識を必要とします。実績のある変換処理ライブラリを使った方が安全です。速度改善の必要があるような人は自分で変換処理作りに挑むのもよいのかもしれません。ここでは、既存の変換処理ライブラリを使う方法を示し、時間があれば具体的な変換処理の作成について触れたいと思います。 | ||
| 2,607行: | 2,613行: | ||
ICUのWebSite<br /> | ICUのWebSite<br /> | ||
| − | http://site.icu-project.org/ | + | http://site.icu-project.org/<br /> |
| + | まずここから最新のソースファイルをダウンロードします。<br /> | ||
| + | VisualStudio2012を使っている分には、現在のICU4CのソースはCygwinも必要とせずにビルドができます。但し、Win32プロジェクトの設定ではuconv.exeがうまく作られないみたいで、[保存ディレクトリ]\icu\binの中にBinaryで配布されているuconv.exeを配置しないとビルドできなかったりというのがありました。なんでだろ。X64は問題ありませんでした。ビルド後VisualStudioの設定も以下のとおり実施する必要があります。 | ||
| + | |||
| + | |||
| + | ソースを見ることができるのですが、とにかく巨大なプロジェクトで、あらゆる文字コードの変換だけでなく、大文字小文字相互変換、全角半角相互変換、ひらがなカタカナ相互変換、他にもひらがなやカタカナからのローマ字相互変換といった複雑な変換も提供しています。そのほかにも通貨フォーマットや時間表記変換といった面白い変換も組み込まれています。ここでは文字コード変換のみを取り上げます。文字コードをファイルに出力するのはもっとあとで説明する予定なので、ここでは、サンプルとなる文字列をその文字コード体系に合わせて16進数で表現した配列として扱い、それを基に変換後の文字コード配列が生成されるのを確かめます。変換後の文字コードがUNICODEやShiftJIS以外になる場合も同じく16進数で表現される配列で示します、逆に異なる文字コードから基に戻す変換も確認します。 | ||
=='''文字列大文字小文字変換'''== | =='''文字列大文字小文字変換'''== | ||
