[ThinkIT] 第2回：Microsoft SQL Server 2005で必要な対処（前編） (1/3)
SQL Serverは早くからUnicodeに対応してきたデータベースの1つであり、SQL Server 2000ではUnicode 2.0に対応しているのでサロゲートペアを格納することができる。ただし前回も紹介したように「格納できる」のと「正しく扱える」のとでは意味合いが異なる。正しく扱えるのはUnicode 3.2をサポートしたSQL Server 2005からで、もちろんJIS X 0213:2004にも対応できる。 ところが対応できるというだけで、何もしなくて良いというのではない。これから何をしなければならないかを明らかにしていこう。 以前からSQL Serverを使ってきた方ならば承知していると思うが、SQL Serverには文字列を格納するためのデータ型が大きく2種類用意されている。1つはchar/varchar/textなど、先頭に「n」が付かないデータ型。もう1つはncha
)
Unicode エンコード体系間のデータ変換の管理
このトピックでは、サーバー側のデータ保存もデータのやりとりを行うクライアント アプリケーションも Unicode に対応する反面、使用する Unicode エンコード体系が異なる場合に、文字データの整合性を維持する方法について説明します。SQL Server では、UCS-2 エンコード体系で Unicode が格納されます。ただし、多くのクライアントでは、別のエンコード体系 (通常は UTF-8) で Unicode が処理されます。このシナリオは、Web ベースのアプリケーションで頻繁に発生します。 このような場合も、基本的にはあるエンコード体系から別のエンコード体系への変換であるため、「Unicode を使用するサーバーと Unicode 以外を使用するクライアント間のデータ変換の管理」および「クライアントとサーバーのコード ページ間のデータ変換の管理」で説明されているのと同じソリュ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
modernphp
