第8回■主要言語の文字エンコーディングの対応状況を押さえる

文字コードの問題に正しく対応する前提として，アプリケーションが稼働する基盤ソフトウエアがマルチバイト文字列処理に対応している必要がある。特に問題となるのが，言語処理系とデータベース管理システム（DBMS）である。利用者の使い方が正しくない場合も，ぜい弱性が混入することがある。このため，今回は主要言語とデータベース（MySQLとMS SQL Server）のマルチバイト文字対応状況について説明する。 文字列の処理単位は文字単位かバイト単位か Webアプリケーション開発で人気のあるスクリプト言語の多くは，かつては文字列をバイト単位で扱っているものが多かった。以下のPerlスクリプトは“漢字”という文字列の長さを表示するものだが，ソースの文字エンコーディングによって結果が変わる。具体的には，Shift_JISやEUC-JPの場合は4，UTF-8の場合は6と表示される。原因は，このスクリプトが文字

[wacky]

文字コードのセキュリティ問題と対策（4/5）。主要言語（PHP、Perl、Ruby、Java、.NET）とデータベース（MySQL、MSSQL）のマルチバイト文字対応状況と望ましい文字エンコーディング。

[youhey]

開発言語とDBにおける文字コードのお話。UTF-8で開発しとくのが一番無難という

[ardarim]

「SQL Serverは内部的にはUCS-2というUTF-16に似た文字エンコーディングで情報を保持する」？？わかりにくいな

[matsutakegohan1]

これから作るものは、そうです。

[otchy210]

今どき新しく Web サービスを書くなら、UTF-8 にしない理由は見あたらない。ケータイをやる時も出力時のみ Shift_JIS にすべきと思う。が、時に EUC-JP とかで作られてたりするのは、やっぱり老害の一種なんだろうか。

[tegetegetege]

5C問題。PHPを含む、各種言語でのマルチバイトの扱い。DB接続時の扱いの説明もあり。

[nihen]

set namesは使っちゃだめなのです。http://www.geminium.com/chiba_blog/2009/02/05/129/