[Info]2011年7月の窓口休業予定(Premier/Pro) : 7/5 ALL,7/12 PM, 7/18 ALL

平素より弊社サポート サービスをご愛顧くださいましてありがとうございます。本日は 7 月の弊社指定休業日のお知らせです。 7/5 終日と、12 日の午後、そして海の日の 18 日(祝日)は休業となります。 お急ぎの皆様にはご迷惑をお掛けし恐縮でございますが、何卒ご理解の程お願い申し上げます。 お問い合わせ窓口休業のお知らせ http://support.microsoft.com/gp/holiday/ja [指定休業日] 2011 年 07 月 05 日 (火) 終日 2011 年 07 月 12 日 (火) 午後 2011 年 07 月 18 日 (月) 海の日 [対象のサービス] プレミア サポート サービス プロフェッショナル サポート サービス (※) 上記期間内もプレミアサポート、プロフェッショナルサポートの緊急案件 (Severity A) につきましては対応させていただきます。 (ILM/FIM/WMI/PowerShell/ADSI Support Team – Jul 01,…

0

[閑話休題] Relocation Notice – UikoU ありがとうございました!

今日は、私事ですがひとつご報告させていただきます。 本日 7 月 1 日より、ILM / WMI / ADSI とか色々担当チームというかユニットから、SQL Server サポートチームに新たなチャレンジをする運びになりました。 これまで、私が担当させていただいたお客様、当ブログをご覧いただいていらした皆様、本当にお世話になりました。 思えば、2008 年、Windows Media / DirectX サポートからいきなりまったく触ったことがなかった ADSI、ILM の世界に飛び込んだときはさっぱりとっかかりもなく、こりゃまずい…私首になっちゃうわよとどきどきしたのを今でも鮮やかに思い出します。ところがそこに、ぴろとくんや、おとうさんという卓越した才能を持つ人材がそろって、ここまでくることが出来たとしみじみ思っています。そして何より、サポートをご利用いただいていらっしゃる皆様の声が、私たちにとってどれだけ励みになるか。あの長々としたアンケートに答えてくださっただけでもありがたいのに、おかげさまで本当によい評価をいただくことが出来、まただめな対応の際は、建設的なフィードバックをチームで何度も検討し、方針を修正するなどして進めてきました。本当に、ありがとうございます。 今後は、ILM (など) の担当は、ぴろとくんとおとうさんの二人になります。 このブログはどうするのかと多数お尋ねをいただいていますが、基本ぴろとくんか、お父さんが担当になりますので、消されたりはしません。私も、少し書くと約束したコンテンツがまだあるので、しばらく私も書き込むことになります。それが終わったら、私は次のチャレンジに完全に移行することになるのだと思います。なので、今しばらくお付き合いいただければ幸いです。なお、次のチームもブログは持っていますが、今のところ私が書くというような予定はありません。 今日は、久々に技術的な話がまったくないつまらない、完全に私事の記事で恐縮です。このまま書かないでおくことも考えました。ですが、小さなプロダクトの割りに、たくさんのページビューもおかげさまでいただくなど、私たちにとって、とても励みにさせていただいた皆様に一言お礼を申し上げたく、書かせていただきました。 つたない文章を面白いといってくださった方、Tech Fielders の集いで実際に face to face でお会いできた方、かけがえのない大切な、大切な思い出です! ぴろとくんとお父さんの今後の ILM プロジェクトを、皆さんどうぞ今後ともよろしくお願いいたします。 皆様のますますのご清栄を心より願っております。 ありがとうございました。 Appendix / サイトの PageView コメント : アクセス解析を導入したのは2009年でした。教えてくださった安納さんありがとうございます。 コメント : やっぱりいっぱい書いてた月は強いです。 コメント : 今年です。やっぱりきっちり書いていないと、伸びもちょっとイマイチですね。 ページビューランキング (URL 別)…

0

[LDAP] LDAP v2 ではデータを Shift-JIS で扱うためサーバからの UTF-16 日本語データが文字化けする(Ver2.0)

皆さんごきげんよう。ういこうです。今日は先日作成したコンテンツを上げようと思ったときに公開ボタンを押すのを忘れていたコンテンツを発見しましたので、今日は豪華二本立てです。本当は九月分だったのに…。さて、今日はダブルバイトを使う民族がコンピュータ史上ずっと血涙を流し続ける問題…そう、「文字化け」についてお送りします。 【今日のお題】 LDAP サーバにアクセスしてダブルバイト文字を取ってこようとしたらなぜか文字化けが発生するときとしないときがある。 接続先も接続元もサーバから帰ってくるパケットデータも毎回バイナリレベルで同じなのになぜ故? 【詳細】 LDAP v3 ではなく、何らかの問題により、LDAP v2 で接続がなされた場合、クライアントサイドでは、クライアント端末内部でサーバから受け取ったデータを取り扱う際 ANSI (日本の場合は一般的に SHIFT-JIS) で文字を扱うことになります。しかしながら、実際にサーバから来る値は、UTF-16 となるため、ANSI:Shift-JIS – Unicode:UTF-16 の文字コード変換が発生し、結果的に文字化けが発生します。この際にネットワーク パケットのデータを見ても、文字化け発生時と正常時でサーバからのデータはバイナリ レベルで一切違いがありません。あくまでも問題は接続時に LDAP v2 としてバインドされることによって、クライアントがサーバから受け取ったデータを扱う際に余計な文字コード変換が発生することとなります。 こうした場合は、ネットワーク パケットでバインド状況を確認し、LDAP バージョンが v2 になっていないかを確かめてみてください。 現象発生時 : “Version  : 2” となっている 正常時 : “Version : 3” となっている 【まとめ】 ・サーバからのデータはネットワークパケットのバイナリレベルで正常時、異常時も変わらない ・LDAP v2 で接続されている ・LDAP v3 で接続されている場合は発生しない なかなか不思議な事象ですね。サーバからのデータ自体は変わりが無いのに、接続 LDAP プロトコルのバージョンが違うだけで文字化けするなんて…。ちなみに現象発生時は、正常時と比較して MultiByteToWideChar() がデータを扱うたびに呼ばれまくっていました。ANSI:Shift-JIS -…

0