.NET の文字列比較でカルチャー未指定を検知する
先日の C# 配信で、 「これはブログに書いておくと助かる人がいるんじゃないか」と言われたものをブログ化。 背景: カルチャー依存問題再び うちのブログでも何回か書いてるんですが、 .NET の文字列比較は、カルチャー依存比較するものと Ordinal (文字コード通り)比較するものが混在していて、なかなかにやばいです。 .NET のカルチャー依存 API 問題 忘れがちなカルチャー依存問題 例えば以下のようなやつ。 using static System.Console; // 正規化すると同じ文字になる、文字コード的には別の文字。 var s1 = "a\u0301"; // á = a + ́ var s2 = "\u00e1"; // á // これは false。Ordinal 比較。 WriteLine(new Dictionary<string, int> { { s1,
C# で、同じソースコードから常に同じバイナリを生成する
昔、gist にだけ置いてて、そういえばブログに書いてなかったものを思い出したので書いておくことに。 (一応、部分的には言及したことがあるんですけど、ちゃんとした話はしたことがなかったはず。) 決定論的ビルド 3年くらい前まで、C# コードをコンパイルすると、ソースコードを一切書き換えていなくても、生成結果の exe/dll や pdb のバイナリが変化していました(決定性(deteminism)がない)。 原因は以下の2つです。 バイナリ中に埋め込まれる GUID にタイムスタンプと乱数から生成される値を使っていた デバッグ用のファイル情報がフルパスで埋め込まれていた GUID の方はタイムスタンプと乱数なので本当に致命的で、ローカルで再コンパイルしても毎回バイナリが変化していました。 フルパスの方は基本的には pdb (デバッグ用シンボル情報)だけの問題なんですが、 exe/dll で
新しい csproj 形式
Visual Studio 2017で、csproj 形式が新しくなりました。 背景としては、 一時期、脱msbuildをしようとしてた -脱msbuildのついでに、csprojを辞めて、project.json 形式にプロジェクト設定全部入れようとしてた時期があった 結局、msbuildに戻ったけども、既存のcsprojをもっとシンプルにしたいという要件だけが残った というものです。過渡期に関しては昔書いたブログ参照: .csproj + project.json 「project.json辞めます」の意味 最近、やっと新形式のcsprojの扱いに慣れてきたのでブログに書き残しておきます。 サンプル: https://github.com/ufcpp/UfcppSample/tree/master/Demo/2017/NewCsproj 新形式 これまで、Visual StudioでC
C# 8.0 の予告 | ++C++; // 未確認飛行 C ブログ
一昨日、C# 8.0 に関するブログが出たわけですが。 Building C# 8.0 個人的には「最近全然ブログ書かない C# チームが働いただと…」的な感想もあるんですが (C# 7.3 のときとか「半年前にリリースしてたわ」みたいなブログでした)。 近々プレビュー版が公開されるであろう C# 8.0 の予告記事です。 Visual Studio 15.9 正式リリースに続いて近々、Visual Studio 16.0 のプレビュー版も公開されて、 それと一緒に .NET Core 3.0 と C# 8.0 もプレビュー公開になると思われます。 .NET Framework 4.8 は未サポート？ で、「.NET Framework 4.8 は .NET Standard 2.1 に追従しないので、C# 8.0 に対応しない」みたいな感じのことが話題になっていますが。 これ、多少不正確
packages.config から project.json への移行
昨日、勉強会で少し話しましたが、Visual Studio 2015で、csproj/vbproj 中での NuGet パッケージ管理が少し楽になります。 正確には、7/20にリリースされた状態の Visual Studio 2015だけじゃなくて、その後Windows 10に合わせて出たVisual Studio Tools for Windowsが必要。(どうも、その後Visual Studio 2015のバイナリも更新されていて、最新のやつならVisual Studio 2015に含まれているっぽい(もしかしたらCommunityだけかも？))。 移行ツール書きました。 既存のプロジェクトを新しい仕組みに対応させるには、現状だと何の移行ツールも提供されていなくて、自前で色々と作業が必要になります。 個人的に試してみた結果、機械作業で、プログラムを使って自動化できそうだったので、作った
プログラミング言語における文字コードの話
世の中がほぼUnicode前提になってめでたしめでたし。とはいかなかった現実の話。 String型でできる文字列処理とか、ソースコード自体、特に識別子で使える文字とか。 軽くおさらい: Unicode まあいろんなところでいろんな人が書いてると思うのでさらっと概要だけ。 Unicodeは、元々、「65,536文字あれば十分だろ」とかいう幻想の元、2バイト固定長の文字コードとして作られていました。 もちろん足りなくて、ビット数を拡張。基本が2バイトのままでこの拡張した分を取り扱えるようにしたのが今のUTF-16で、拡張分は2文字分(4バイト)を使って表現。 この、2文字分使って1文字を表すやつのことをサロゲートペア(surrogate pair: 代理対)と呼びます。 あと、ASCII文字も2バイトになるのを欧米人が嫌って、ASCII文字はASCIIコードのまま、逆に漢字・ひらがな・カタカナ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
