UTF-8かどうかの判定（C#）

別システムからのデータファイル取り込み処理で、文字コードが不明であった場合にどうするか、という話から、UTF-8かどうかのチェックができるのか？という話題になりました。

UTF-8の種類

UTF-8という文字コードには、BOM（Byte Order Mark）という情報があるバージョンと、無いバージョンがあります。BOMがある場合、UTF-8データの先頭を見てBOMに該当するデータパターンが入っていれば「BOM有りのUTF-8」ということで簡単に判断可能です。しかし、世の中の大半のUTF-8データはBOM無しなので、実はこの方法はたいていの場合使えません。

BOM無しUTF-8の判定

具体的な手法やロジックは追えてないのですが、stackoverflowの下記のスレッドから、CodePlexにライブラリが掲載されていることが判りました。

stackoverflow.com

こちらです。

archive.codeplex.com

CodePlexはすでにクローズされることが決まっているので、いずれはGitHubに移行されるのかもしれませんが、2019年2月時点では上記リンクからダウンロード可能です。

Utf8Checker

ファイルをダウンロードするといくつかフォルダが出てくるのですが、「sourceCode」というフォルダにソースが入っています。ファイルは古いVisual Studioなので、Visual Studio 2017などで開くとコンバーターが動きますが、そのまま変換して問題なさそうです。
ソースにはテストプロジェクト（Unicode.Tests）と、本体であるUnicodeプロジェクトがあります。実際に自分で使う場合はUnicodeプロジェクトのビルド結果（DLLファイル）を参照して、UTFCheckerクラスのインスタンスを生成して使うようです。
メソッドは大きく2つ。

• Checkメソッド …… ファイル名を指定してファイルがUTF-8かどうかを判定する。
• IsUtf8メソッド …… strem形式のデータを指定してUTF-8かどうかを判定する。

前者のCheckは、ファイルを開いてIsUtf8に判定を依頼するもので、実質的に動くロジックは同じです。

面白いのはテストに使っているデータ。https://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-demo.txt にあるものがテストプロジェクトに入っています。我々がテストをするとどうしても複雑な日本語に限定したテストをしがちですが、前述リンク先にあるファイルはいろんな言語や記号も含まれているので、他の文字コード関連テストにも使えるかもしれません。

とりあえず自分用メモということで。

[改訂新版]プログラマのための文字コード技術入門 (WEB+DB PRESS plusシリーズ)

GitLabのグループに既存プロジェクトを追加する

絶対忘れそうなのでメモ。

背景

GitLabで、複数プロジェクトをまとめられる、グループというものを作ることができます。グループは、参加するメンバーをプロジェクトごとではなくグループ単位で設定できるので、複数プロジェクトを複数メンバーで取り扱う場合などに便利な設定です。ですが、普通にグループを作成すると、そこに入れるプロジェクトは新規プロジェクトしか指定できません。新規作成プロジェクトでは事前にエクスポートしておいたプロジェクトも指定できるので、エキスポートしておけば既存プロジェクトも追加可能ですが、ちょっと面倒。というわけで、すでにあるプロジェクトをグループに入れる方法を記載しておきます。

既存プロジェクトの設定画面から実施できる

すでにあるプロジェクトをグループに入れるという作業は、GitLabでは「Transfer（トランスファー）」と呼んでいます。この作業は、既存プロジェクトのページから「Settings（設定）」→「General（一般）」で表示される一般設定の下の方、「Adanced」と書かれたところのExpandボタンを押すと出てきます。

GitLab、設定→一般→Advanced

Advanced設定の中でも下の方に「Transfer Project」という項目があります。

GitLab、Advanded設定→Transfer Project

「Select a new namespace」という項目がドロップダウンリストになっていて、すでにあるグループ、特に、自分が選べるグループなどが表示されるので、移動先のグループを選択して「Transfer Project」ボタンを押してください。

GitLab、Transfer Project確認

上図のようなメッセージが表示されます。「別のオーナーに委譲」という不安になるコメントが書かれていますが、グループもプロジェクトも自分が作成したものであれば特に問題ありません。ここでは、移動させるプロジェクトの名称を手打ちでテキスト入力欄に打ち込んでください。打ち終わると「Confirm」ボタンが使えるようになるので、ボタンを押しましょう。これで終わりです。

わかばちゃんと学ぶ Git使い方入門〈GitHub、Bitbucket、SourceTree〉

チームの自己組織化を妨げる13のパラダイムに2つ追加する

株式会社ソニックガーデンの代表が書かれているブログで、「チームの自己組織化」に向けてやっては行けないことが記載されています。参考になります。

kuranuki.sonicgarden.jp

これを見ていてちょっと思ったことがあるので2個くらい追加してみようかと思います。

14. 締め付けと管理を混同する

縛り付けてすべてを操る事を管理とするチームは、悪い意味での依存（締め付けてきたリーダーに対する依存）と責任転嫁（そこに至る理由や原因は自分になく、強い指示を出したリーダーのせい）、失敗するくらいならばやらない（失敗の可能性があり、そのことで叱責されるリスクを負うくらいならやらない＝技術領域では絶対成功という保証は常にないので、これをやられると何一つ新しいことをやらなくなる）という選択を採り、リーダーの能力を絶対に超えることがないチームになります。リーダーはリードするのが仕事であり、頂点に君臨することが仕事ではないという認識を持った方がいいです。

リーダーの能力を超えられないということは、その組織はその時点の上層部から進歩しないということ。何年たっても変わらない組織になります。リーダーは君臨が仕事ではない。これは鉄則だと思います。

15. やってはいけないことを列挙して指導する

アレはダメ、これはダメという指示で指導すると、ダメと言われたことをやらないだけの組織になります。危ない橋は渡らない、というか、危ないから歩かない、みたいな。これは子供に対する指導でも一緒。自立ということばのはき違えで放置したり、最初から千尋の谷に突き落とすリーダーが居ますが、やはり初学者には具体的な手順を明確に伝え、最初の一歩はしっかり手助けを。経験者には、次に進むべきコースや指針を提示して、危険回避だけではなく前に進むことを教えるべきです。

こういうことをやっていかないと、チームは何をやるにもビクビクしてしまい、冒険しなくなります。技術の世界なんてそもそもやってみなければ判らない、研究したり試さないと判らない事だらけ。なので、失敗を恐れていては何もできません。

まとめ

いかがでしたか？（←これ一度やってみたかった）。

管理ゼロで成果はあがる～「見直す・なくす・やめる」で組織を変えよう

自分の小さな「箱」から脱出する方法 ビジネス篇 管理しない会社がうまくいくワケ