2015年11月

エクセルワンポイント Tips:ファイル名から日付を読み取る(関数で)

Microsoft Excel で資料を作る際、ファイル名に日付を入れている人は多いと思う。
仕様書_2015_11_28.xlsx
提案資料_20151128.xlsx

修正を行った際に別の日付のファイルが作成されることになるので、過去の資料も見ることができて便利だ。

せっかくファイル名に日付が入っているのであれば、エクセルのセルにも「更新日:2015/11/28」のようにその日付を表示したくなる。

エクセルの関数には、「最終更新日」を取得する関数が無い。「現在時刻(本日)」を取得する Now 関数や、マクロで最終更新日を取得する方法はあるが、ファイル名に日付を入れていれば、関数だけで更新日を取得できる。

yyyy_mm_dd 形式の場合

売上「売上_2015_09_01.xlsx」のように、yyyy_mm_dd 形式でファイル名を付けている場合は、セルに以下の式を入力すれば良い。

=REPLACE(REPLACE(MID(CELL("filename"),FIND(";",SUBSTITUTE(CELL("filename"),"_20",";",(LEN(CELL("filename"))-LEN(SUBSTITUTE(CELL("filename"),"_20","")))/LEN("_20")))+1, 10), 5, 1, "/"), 8, 1, "/")

右の写真のように、セルに日付が入る。

yyyymmdd 形式の場合

稼働率「稼働率_20151001.xlsx」のように、yyyymmdd 形式でファイル名を付けている場合は、セルに以下の式を入力すれば良い。

=TEXT(VALUE(MID(CELL("filename"),FIND(";",SUBSTITUTE(CELL("filename"),"_20",";",(LEN(CELL("filename"))-LEN(SUBSTITUTE(CELL("filename"),"_20","")))/LEN("_20")))+1, 8)), "0!/00!/00")

右の写真のように、セルに日付が入る。

注意点

日付の検索の目印として、年の先頭のアンダースコアを使用しているので、_2015 というように、ファイル名を付ける際、アンダースコアを忘れてはいけない。月および日は必ず 2 桁にする。8 月なら 08。

また、本関数が使えるのは 2099 年までである。





C# で SQLite を便利に使うサンプルコード(LINQ to SQLite)

.NET Framework C# で SQLite3 を使う方法について、すでにいくつか情報はあるものの、数が少なかったりするので、自分がハマった罠なども含めて、ここにまとめておく。合わせて、サンプルプログラムも公開する。

どの SQLite ライブラリを使うか?

C# で SQLite を使うための方法はいくつかあり、自分が把握している範囲では以下のようになる。
  • C 言語用 DLL を P/Invoke で使う……本家本元の DLL を使い、従来型の文字列によるクエリでプログラミング。最新のライブラリを使える(本稿執筆時点で 3.9.2)。しかし、C 言語レベルの生産性しかなく、労多くして功少なしなので、どうしても最新のバージョンを使いたい時以外はお薦めしない。
  • System.Data.SQLite……SQLite 本家による .NET 用ライブラリ。データベースを便利に使う ADO.NET に対応しており、生産性が向上。C 言語用 DLL よりは多少バージョンが古い(3.8.11.1 ベース)ものの、総合的に一番お薦め。
  • Mono.Data.SqliteClient…….NET のオープン・クロスプラットフォーム実装である Mono プロジェクトが作成したライブラリ。ADO.NET 対応。文字コードが Unicode(恐らく UTF-16)と記載があるのが気になる(本家は UTF-8)。別途本家 C 言語用 DLL が必要な模様。
  • csharp-sqlite……マネージドコードのみで作成されたライブラリ。ADO.NET 対応。2011 年で開発停止の模様。バージョンは 3.7.7.1。マネージドコードしか使えない制約がある場合に重宝しそう。
  • sqlite-net……コンパクトなライブラリ。ADO.NET 非対応。できる限り実行ファイルサイズを小さくしたい場合に活躍しそう。2012 年あたりで開発が停止しているようだ。
以降では、System.Data.SQLite を使う。

ADO.NET とは?

System.Data.SQLite は ADO.NET に対応しているが、そもそも ADO.NET とは何か。ADO.NET の詳しい解説は @IT の記事などに記載があるが、プログラマーから見たメリットを三行で書くとすれば、
  • エディタのコード補完で楽ちんかつ安全にクエリを書ける(LINQ)
  • 設計時からデータ構造をビジュアル化できる(Entity Framework)
  • 使うデータベース(SQLite/Oracle……)によらず同じコードを使い回せる
あたりになるのではと理解している。

これにより、C 言語で SQLite をいじるよりもはるかに効率的にデータベースプログラミングが行える。

なお、本稿では、LINQ は使うが Entity Framework は使わない。

System.Data.SQLite のインストール

NuGetインストールは非常に簡単である。ここでは、Visual Studio 2015 Community / .NET Framework 4.5 の環境で実行しているものとする。
  1. Visual Studio を起動し、SQLite を使いたいプロジェクトを開く
  2. メニューの[ツール|NuGet パッケージマネージャー|ソリューションの NuGet パッケージの管理]をクリック
  3. 検索窓に「SQLite」と入力して SQLite パッケージを検索
  4. 検索結果の System.Data.SQLite を選択して、インストールボタンをクリック。関連するライブラリも含めて自動でインストールが終わる
たったこれだけ。

以前は、NuGet をコマンドラインで使う必要があった時代もあったようだが、現在は GUI で使える。

NuGet の欠点は、プロジェクトごとにインストールの必要があるため(プロジェクトに最適なバージョンを選んでインストールしてくれる)、SQLite を使うプロジェクトが複数ある場合は、ディスクをどんどん消費していく。その場合は、ダミープロジェクトでインストールしたバイナリを使い回したり、手動でバイナリをダウンロードして共用するといいかもしれない。

System.Data.SQLite の基本

データベースファイル(*.db とか *.sqlite3 とか)を開くには、SQLiteConnection クラスを使う。

SQLiteConnection を new する際にパラメーターを文字列で渡すのだが、SQLiteConnectionStringBuilder というお助けクラスを使うと、パラメーター文字列をミスなく生成できる。

SQLiteConnectionStringBuilder aConnectionString = new SQLiteConnectionStringBuilder
{
    DataSource = @"R:\Test.db"
};
using (SQLiteConnection aConnection = new SQLiteConnection(aConnectionString.ToString()))
{
    aConnection.Open();

    // ここにデータベース処理コードを書く
}


従来型の文字列によるコマンドを発行したい場合は、SQLiteCommand クラスを使う。

using (SQLiteCommand aCmd = new SQLiteCommand(aConnection))
{
    aCmd.CommandText = "CREATE TABLE IF NOT EXISTS t_test (test_id INTEGER NOT NULL PRIMARY KEY, test_name NVARCHAR NOT NULL, test_height REAL);";
    aCmd.ExecuteNonQuery();
}


テーブル構造定義クラスの導入

データへのアクセスを簡単・分かりやすくするために、テーブル構造を定義するクラスを作成する。

簡易名簿テーブル「t_test」が以下のような構造になっているとする。
フィールド名NULL備考
test_idINTEGER不可連番
test_nameNVARCHAR不可氏名
test_heightREAL身長

この場合、テーブル構造定義クラスは以下のようになる。

[Table(Name = "t_test")]
public class TTestData
{
    // ID
    [Column(Name = "test_id", DbType = "INT", CanBeNull = false, IsPrimaryKey = true)]
    public Int32 Id { get; set; }

    // 氏名
    [Column(Name = "test_name", DbType = "NVARCHAR", CanBeNull = false, UpdateCheck = UpdateCheck.Never)]
    public String Name { get; set; }

    // 身長
    [Column(Name = "test_height", DbType = "REAL", CanBeNull = true)]
    public Double? Height { get; set; }
}


フィールドをプロパティーとして定義しているシンプルなクラスである。

CREATE TABLE で作成した際のテーブル情報に合わせて、クラスメンバーの属性を記述している。例えば ID フィールドであれば、Name = "test_id" でデータベース上のフィールド名、DbType = "INT" でデータ型、CanBeNull = false で NULL 不可であることを表している。

DbType の型について注意点が 2 つ。
  • 整数型は DbType = "INT" とする。INTEGER ではエラーになる。
  • 文字列型は DbType = "NVARCHAR" とする。TEXT ではエラーになる。
特に、文字列型を TEXT としてしまうと、原因が分かりづらいエラーが発生し、ハマることになる。

身長フィールドは、NULL を許可している。CanBeNull = true にすると共に、プロパティーの型を「Double?」というように「?」を付けて nullable にしている。

レコードの挿入

テーブル構造定義クラスを導入したことにより、データベースの取扱が非常に簡単になる。

レコードの挿入を行うコードは、以下のようになる。SQLiteCommand クラスを使わなくて済むので全然 SQL っぽくなく、普通のコードのように書ける。

using (DataContext aConText = new DataContext(aConnection))
{
    Table<TTestData> aTableTest = aConText.GetTable<TTestData>();
    aTableTest.InsertOnSubmit(new TTestData { Id = 1, Name = "Fukada Kyoko" });
    aTableTest.InsertOnSubmit(new TTestData { Id = 2, Name = "Eda Ha", Height = 180.0 });
    aTableTest.InsertOnSubmit(new TTestData { Id = 3, Name = "Dan Gerou", Height = 150.5 });
    aTableTest.InsertOnSubmit(new TTestData { Id = 4, Name = "Baba Takashi" });
    aTableTest.InsertOnSubmit(new TTestData { Id = 5, Name = "Aikawa Ai", Height = 145.6 });
    aConText.SubmitChanges();
}


ID 1 や 4 では身長を設定していないので、データベース上 NULL として格納される。

レコードの検索

レコードの検索は LINQ to SQLite と呼ばれる手法で行う。ちょっと変わった書き方だが、エディタのコード補完が効くのでミスが減る。

using (DataContext aConText = new DataContext(aConnection))
{

    Table<TTestData> aTableTest = aConText.GetTable<TTestData>();
    IQueryable<TTestData> aQueryResult =
            from x in aTableTest
            where x.Name == "Eda Ha" || x.Height < 150.0
            orderby x.Height
            select x;
    foreach(TTestData aData in aQueryResult)
    {
        Debug.WriteLine(aData.Name);
    }
}


from のところが SQL の発行に相当する部分。なんとなく SQL に似ているので、読めば理解はできると思う。

結果は foreach で回せるので、非常に簡単に扱える。

レコードの削除

レコードを削除する場合、削除したいレコードを検索し、それを削除する、という流れになる。

検索については前節と同じで、その結果を、DeleteAllOnSubmit() メソッドにぶち込むだけ、とこれまた簡単。

using (DataContext aConText = new DataContext(aConnection))
{
    Table<TTestData> aTableTest = aConText.GetTable<TTestData>();
    IQueryable<TTestData> aDelTargets =
            from x in aTableTest
            where 140 < x.Height && x.Height < 160
            select x;
    aTableTest.DeleteAllOnSubmit(aDelTargets);
    aConText.SubmitChanges();
}


サンプルコード

以上をまとめたものを、サンプルコードとしておいておく。

なお、CREATE TABLE や CREATE INDEX は少々コーディングが面倒くさいので、テーブル構造定義クラスの情報から自動的にテーブルを作成するための補助クラス(LinqUtils.cs)を入れてある。

Visual Studio 2015 Community で動作する。

参考資料











UTAU ust 配布 URL 再掲

以前から公開している UTAU の ust ファイルを Dropbox に移したので URL を公開。

白鐘ヒヨリ_おさとうノエル_313_07_04_04_07_サムネイル

La Noël Sucrée ~おさとうノエル~



実音とわの・ぱみゅ_恋の特急みらくるメッセンジャー_284_サムネイル

恋の特急みらくるメッセンジャー!




System.Data.Linq.dll で NotSupportedException(解決)

SQLite3 を C# で使いたくて、いろいろ試していたら、文字列の比較でエラーが発生。

やったことは、System.Data.SQLite(SQLite の公式 ADO.NET プロバイダー)をインストールし、LINQ to SQLite でデーターベースにアクセス。ソースコードはおよそ以下のような感じ。

    Table<TTestData> aTableTest = aConText.GetTable<TTestData>();
    IQueryable<TTestData> aQueryResult =
            from x in aTableTest
            where x.Name == "Eda Ha"
            select x;


ここで、aContext は DataContext 型のインスタンス。TTestData は以下の定義。

[Table(Name = "t_test")]
public class TTestData
{
    // ID
    [Column(Name = "test_id", DbType = "INT", CanBeNull = false, IsPrimaryKey = true)]
    public Int32 Id { get; set; }

    // 氏名
    [Column(Name = "test_name", DbType = "TEXT", CanBeNull = false, UpdateCheck = UpdateCheck.Never)]
    public String Name { get; set; }
}


NotSupportedExceptionこのようなコードを実行すると、IQueryable の結果を使う段階で、NotSupportedException が発生する。

    例外がスローされました: 'System.NotSupportedException' (System.Data.Linq.dll の中)
    追加情報:SQL Server では、NText、Text、Xml、または Image の各データ型の比較はハンドルされません。

where x.Name == "Eda Ha" の箇所が where x.ID == 1 のような数値型の比較だと例外は発生しない。

原因がわからずさんざん悩んだ。「SQL Server では~」のエラーメッセージで検索しても情報が見つからない。

結論としては、Name の DbType がまずかった。

DbType を NVARCHAR にして、CREATE TABLE する際の型も NVARCHAR にしたら、うまく動作するようになった。

どうやら、SQLite を .NET で使う場合は、文字列型は NVARCHAR にしないといけないようだ。

なお、エラーが発生した環境は、
  • Visual Studio Community 2015
  • .NET 4.5
  • System.Data.SQLite 1.0.98.0(sqlite-netFx45-setup-x86-2012-1.0.98.0.exe)
関連記事

簡易 ACF/ACB/AWB プレーヤー Ver 1.31 αを公開

EasyAcfPlayerメインウィンドウ簡易 ACF/ACB/AWB プレーヤーの新バージョン、Ver 1.31 α を公開しました。

簡易 ACF/ACB/AWB プレーヤーは、ACF/ACB/AWB 形式で圧縮されている音楽を簡易的に再生するツールです。

ACF/ACB/AWB 形式は、CRI 社の統合型サウンドミドルウェア(ライブラリ)である「ADX2」「ADX2 LE」で使用される楽曲形式です。

従って、ADX2/ADX2 LE を使って開発されているゲームやアプリ(例えば幻走スカイドリフト)の音楽データ・BGM・効果音などが、この形式になっている場合があります。

お気に入りのゲーム音楽のサウンドトラック(サントラ)代わりとして、また、ゲーム開発時の動作確認用としてなどに、利用できるかと思います。

更新内容

ACB ファイルのみで AWB ファイルが無いデータに対しても再生を試みるようにしました。

一部のデータにおいて、これまでよりも再生できるファイルが増えます。

更新・インストール方法

既に簡易 ACF/ACB/AWB プレーヤーをお使いの場合は、3 日以内に自動的に最新版にバージョンアップされます。

初めて使う場合、あるいは、すぐにバージョンアップしたい場合は、下記サイトからダウンロードしてください。

ダウンロード……簡易 ACF/ACB/AWB プレーヤー公式サイト





ウミネコロン RPG はじめました

UTAU キャラクターを主人公にした RPG「ウミネコロン RPG」の DL 販売が始まったので、早速ゲームスタート。

※ネタバレ注意

バールUTAU 関連 RPG ということで、ストーリーも UTAU にちなんでいる。突然バグに覆われた街の謎を解くべく、UTAU の仲間達と冒険の旅に出る。

ゲームスタート時、家から出られなくてどうにか脱出を試みるのだが、家の中に宝箱があって中にバールが入っているというのが、なんともシュールで良い。

しかも、バールでドアを開けようとすると、バールが壊れて開けられないというオチ。エクスカリバールという強そうなバールなのに……。

森のクマさん序盤の敵は何気に強い。というか自分が弱い。殴られるとすぐに HP が心許なくなる。が、無限使用回復アイテムがあるので大丈夫。戦闘が終わったらすぐに回復すれば、再び戦える。

敵のグラフィックがまた笑ってしまう。背景や自パーティーのキャラはハイクオリティに描きこまれているのに、敵キャラだけ 2 ちゃんねるのアスキーアート風なのだ。

忍音クノストーリーを進めていくと、仲間も増えていく。

それぞれ、ステータス的にも、キャラクター的にも個性ある楽しい仲間達だ。

どうやら、最大 4 人パーティーの模様。

まだ序盤のプレイだが、ストーリー展開・グラフィック・BGM ともに、期待できそうな内容になっている。操作性もなかなか(ゲームパッドも使える)。

とはいえ、もうちょっとこうだったら良かったのにな、という点もある。
  • 音量調整ができない
  • セーブデータは現在位置(街の名前等)が表示されると、ロードする時に分かりやすい
  • セーブデータが exe フォルダに置かれてしまう(UserData 配下が良い)
  • ボタン同時押しで高速移動できるが、逆にデフォルトが高速移動、同時押しで低速微調整の方が楽

ウミネコロンWinXP動作環境は、我が家の Windows 7 マシンで今のところ問題なく動いている。

試しに Windows XP や Windows 10 でも動かしてみたが、少しいじった限りでは、これらの OS でも動作した。

ウミネコロン RPG の他にも、もっといろいろ UTAU ゲームが増えるといいな。

現時点での UTAU ゲーム一覧は、UTAU ユーザー互助会 Wiki にまとめてある。

※ウミネコロン RPG……作者:ウミネコロン

マシンスペックまとめ(メインマシン:Core i7)

前回から本体は変わっていないが、周辺に少し変更があったので再度整理。

本体

パーツ型番購入価格(税込み)
名称Core i7 - P8 マシン(Rev. 2015-11-11)
※初出:2013-01-05
91,051 円
マザーボードASUS P8H77-V8,441 円
CPUIntel Core i7-3770S
※4 コア 8 スレッド、実クロック 3.1GHz(Turbo Boost 3.9GHz)、TDP 65W、22nm プロセス
26,300 円
CPU クーラーCPU 付属品
0 円
セラミックグリスCPU 付属品0 円
メモリ32GB、DDR3-1600(PC3-12800) DIMM 8GB×4
SMD-32G28NP-16K-Q
※SanMax 製、Elpida チップ、CL11、ヒートスプレッダ無し
14,780 円
SSD512GB、PLEXTOR M5 Pro
PX-512M5P (3C01140039)
※S-ATA 3 (6Gbps)、2.5 インチ、7mm 厚、BGA
36,800 円
マウンタSSD 付属品0 円
光学ドライブ
(DVD スーパーマルチ)
アイ・オー・データ機器 DVR-SN24GE
4,730 円
ビデオカードSAPPHIRE HD5570 1G DDR3 PCI-E HDMI/DVI-I/VGA
※RADEON HD 5570、DDR3 1GB、128bit、PCI-e x16、40nm プロセス
※Core i5 マシンからの使い回し
0 円
LANオンボード
※ギガビット
0 円
ケーススカイテック SKⅡ-201W
※Core Duo マシンからの使い回し
0 円
電源Owltech AU-500
※500W
※Core i5 マシンからの使い回し
0 円

周辺機器

パーツ型番購入価格(税込み)
RAID ユニットWestern Digital My Book Duo WDBLWE0080JCH-JESN
※8TB、RAID 1 の運用で実効 4TB
※USB 3.0 接続
65,640 円
サウンドカードCreative Sound Blaster Digital Music Premium HD (SB-DM-PHD)
※USB 接続
※Core i5 マシンからの使い回し
0 円
スピーカーONKYO WAVIO GX-70HD
※Core Duo マシンからの使い回し
0 円
オーディオレシーバーONKYO WR-BT300
※Bluetooth で音声を受信してスピーカーに流す
6,000 円位?
ディスプレイ21.5 インチワイド液晶、IO DATA LCD-MF223XS
※HDMI 接続
※Core i5 マシンからの使い回し
0 円
ゲームコントローラーLogicool F310r1,550 円

UTAU の文字コードを整理

定期的に UTAU の文字コード周りで問題が出る感があるので、備忘を兼ねて、分かる範囲でまとめておく。

Windows 版 UTAU

UTAUustWindows 版の UTAU が読み書きするファイルの文字コードは、すべてが Shift-JIS。
  • ust
  • oto.ini
  • prefix.map
  • character.txt
  • setting.ini
  • 音声合成時のバッチファイル
Shift-JIS は、Windows が伝統的に使用してきた文字コードだ。

Shift-JIS では、半角文字(半角カナ含む)は 1 バイト、全角文字は 2 バイトで表現される。例えば、「ABあ愛」は 1+1+2+2=6 バイトとなる。

Windows 版 UTAU の内部コード(メニュー・ダイアログ関連)

UTAUダイアログ※通常のユーザーはここを読み飛ばして構わない

UTAU のメニューバーやダイアログなどのリソース関連文字列は、UTAU.exe 内に Shift-JIS として埋め込まれているようだ(Ver 0.4.18 zip 版)。
  • ファイル→名前をつけて保存
  • プロジェクトの設定ダイアログ→プロジェクト名
なお、ダイアログが文字化けする場合は、末尾の参考リンクが解決策になるかもしれない。

Windows 版 UTAU の内部コード(メニュー・ダイアログ以外)

UTAU変更確認※通常のユーザーはここを読み飛ばして構わない

リソース関連以外については、UTAU.exe 内部コードは Unicode(UTF-16-LE)のようだ(Ver 0.4.18 zip 版)。例えば、「プロジェクトは変更されています。変更を保存しますか?」などのメッセージボックスで表示される文字列。

また、このことから、UTAU 実行中にメモリ上に格納される文字列も UTF-16-LE で格納されているものと思われる。

UTF-16 は、すべての文字を 2 バイトで表現する(ホントはすべてじゃないけど細かいことは気にしない)。半角文字も 2 バイトだ。なので、「ABあ愛」は 2+2+2+2=8 バイトとなる。

UTF-16 にも 2 種類あり、通常「Unicode 表」として表記されているのは UTF-16-BE(ビッグエンディアン)。で、UTF-16-BE の 1 バイト目と 2 バイト目を入れ替えたのが UTF-16-LE(リトルエンディアン)。例えば全角カタカナの「プ」は、ユニコード表(16 進数)では 30 D7 の 2 バイトで表されるが、UTAU.exe 内では逆順となり、D7 30 の 2 バイトで表される。

逆になるのは非常に分かりづらいが、これは UTAU の問題ではなく、Intel CPU の伝統なので受け入れるしかない。

UTF16とSJISUTF-16-LE は Shift-JIS との互換性は一切なく、両者で同じ文字コードをを使っている文字は無い。

しかし、バイト列レベルで見ると、半角英数については類似性があり、Shift-JIS のコードにゼロを付加した物が UTF-16-LE となる。例えば「ABC」は Shift-JIS だと 16 進数で 41 42 43 の 3 バイトとなるが、UTF-16-LE だと 41 00 42 00 43 00 の 6 バイトとなる。このため、半角英数を UTF-16-LE で保存して、Shift-JIS だと思って開くと、間延びしたように表示される(右の図をクリックして確認してほしい)。

また、プログラミングの視点で見ると、0x00 を文字列の終端と見なす C 言語などでは、何も考えずに UTF-16-LE の文字列を読み込むと、途中に出現する 0x00 のせいで、文字列が途切れてしまうことがあり、注意が必要となる。

Mac 版 UTAU(UTAU-Synth)

UTAU-Synth はよくわからないが、どうやら、oto.ini と prefix.map は UTF-8、それ以外のファイルは Shift-JIS で出力するようになっている模様。

oto.ini と prefix.map が用いる UTF-8 では、半角英数は 1 バイト、日本語はたいてい 3 バイトとなる。半角カナも 3 バイト。例えば、「ABあ愛」は 1+1+3+3=8 バイトとなる。

UTF-8 と Shift-JIS は、半角英数は同じコードを使っている。つまり、半角英数だけのファイルなら、UTF-8 として扱う UTAU-Synth でも、Shift-JIS として扱う UTAU でも、問題なく開ける。

oto.ini / prefix.map 以外は UTAU-Synth も Shift-JIS なので、UTAU とファイルを共用できることになる。ただし、Windows の Shift-JIS と Mac の Shift-JIS は方言のようなものが多少異なり、一部の文字に互換性が無い。通常使う範囲ではあまり問題にならないが、記号類は避けた方が良いだろう。

おまけ知識

※通常のユーザーはここを読み飛ばして構わない

この記事でも混同して使っているが、厳密には、文字コードを考える時には、「キャラクターセット」と「エンコーディング」の 2 つに分けて考える必要がある。

キャラクターセットは、「どんな文字を取り扱うか(文字集合)」で、例えば欧米ならアルファベットだけでいいよ、とか、日本なら漢字も入れたいね、という話になる。

エンコーディングは、キャラクターセットで扱う文字を、具体的にどんなバイト列で表現するかを決める。

Shift-JIS の場合は、キャラクターセットとエンコーディングがセットになっている感じなので、キャラクターセットやエンコーディングを意識しなくて良い。

UTF-16-LE と UTF-8 は両方とも、キャラクターセットとしては世界中の文字を扱う Unicode で同じある。同じ文字を、どのようにバイト列にするかの規則(エンコーディング)が違うにすぎない。

UTF-16-LE は「すべて 2 バイト」という処理しやすい規則になっている。一方 UTF-8 は、半角英数という最もよく使われる文字を 1 バイトにして、容量の節約を図っている。同じキャラクターセットを表現するにしても、用途によって適したエンコーディングが変わる、という話である。

参考リンク

今回の話、自分も全部をきちんと理解しているわけではないので、各自ググっていただきたい。誤りや追加情報があったら教えて下さい。


Windows Phone(Windows 10 Mobiel スマホ)13 機種比較

※更新記事を公開しました→Windows Phone(Windows 10 Mobile スマホ)12 機種比較

Windows 10 for phones and tablets や Windows Mobile 10 などとよばれていたモバイル用 Windows 10 の名称が「Windows 10 Mobile」となり、2015 年後半に提供開始される見込みとなった。

それにあわせ、続々と Windows 10 Phone が発表になっている(把握している限りでは 13 機種)。現時点で詳細な情報は少ないが、判明している部分を整理して比較表にまとめてみた。下の表は、クリックすると拡大する。

WindowsPhone13機種比較

開示されている情報の範囲では、お手頃価格のエントリー~ミドルレンジ製品が多そうだ。

Diginnos Mobile DG-W10M

ドスパラの DG-W10M は、クアッドコア CPU 搭載。CPU 型番は不明ながらも、プレスリリースに「お求めになりやすい価格」と書かれていることから、ハイクラスの CPU ではなさそう。価格を 2~3 万円程度に抑えるつもりなのだろう。

LTE のサポート状況も上々。docomo のトリプルバンドをサポートしているので、docomo 系 MVNO の SIM を使えば、全国どこでも繋がりやすい(docomo のバンドについてはこちらの記事を参照)。

KATANA 01/02

katana02FREETEL の KATANA 01/02 は、価格がきちんと示されている。

公開情報がドスパラと入りくりになっているが、感触としては、ドスパラ機と同程度のスペックであろう。

Liquid M330/M320

日本エイサー の Liquid M330/M320 は、CPU 型番が明確になっている。MSM 8909 と 8209 の違いがよく分からないが、統合モデムが LTE か 3G かというだけで、CPU コアは一緒かもしれない。

M330 の価格はユーロベースを単純に為替換算しているが、日本での正式価格は不明だ。

WPJ40-10

wpj40-10_img_00_p geanee の WPJ40-10 は、判明している中では最もディスプレイのサイズがコンパクト。スペックも全体的に低めなので、買いやすい価格になるのではないだろうか。

Lumia 550/950/950XL

Lumia-950-XL-hero-jpg Lumia 950 と 950XL は 2560×1460 ピクセルのディスプレイを備えるハイスペックスマホ。明示的には記載されていないものの、下位の 550 が LTE をサポートしていることから考えても、当然 LTE はサポートであろう。

最上位の 950XL が搭載する CPU は Snapdragon 810 で、発熱に問題のある CPU だが、水冷で対応するとのことなので、発熱問題もクリアしてくる可能性がある。

その他

その他の機種は、現時点では情報が無い。NuAns NEO については 11 月に詳細が公開されるようだ。

VAIO については機種名すら不明で、まったくの謎。ハイスペックな機種を出してきたりすると面白いのだが。

参考リンク

NTT docomo LTE の周波数帯(バンド)まとめ

SIM フリースマホと格安 SIM(MVNO)を使おうという時などに気になるのが、docomo の電波が使用している LTE バンド。簡単に整理してみた。

docomoのLTEバンド


docomo のバンドは、カバーエリア(繋がりやすさ)重視の band 1/19 と、通信速度重視の band 3/21 に大別される。

Xi のサービス全体としては 300Mbps などの高速通信が可能だが、これは複数のバンドを同時に利用する CA(キャリアアグリゲーション)で実現している。

band 1:下り 2110 MHz~2170 MHz、上り 1920MHz~1980MHz

LTE(サービス名は Xi(クロッシイ))開始時から使用されているバンド。下り周波数の 2100MHz 帯と呼ばれたり、ざっくり 2GHz 帯と呼ばれたりする。

都市部を中心として広いエリアで使える周波数帯だ。都市部でのスマホ利用を考えているなら、この band 1 をサポートしているスマホを選ぶと良いのではないか。

band 3:下り 1805 MHz~1880 MHz、上り 1710MHz~1785MHz

1800MHz 帯、あるいは 1.7GHz 帯とよばれるバンド。

東京・名古屋・大阪圏限定ながら、最高速で通信可能なバンド。これらの地域に住んでいるならば、band 3 対応のスマホで快適に通信が行える。

逆に、三大都市圏以外では、まったく役に立たない。

band 19:下り 875MHz~890MHz、上り 830MHz~845MHz

郊外を中心として広いエリアで使える周波数帯。

800MHz 帯はいわゆる「プラチナバンド」と呼ばれる周波数帯で、屋内や山間部でも電波が入りやすい。

田舎では band 19 のみ使用可の場合も多いので、田舎でスマホを使いたいなら、band 19 対応のスマホが必須となる。

最近は、都市部でも band 19 が使えるところが広がってきている。

band 21:下り 1495.9MHz~1510.9MHz、上り 1447.9MHz~1462.9MHz

1500MHz 帯、あるいは 1.5GHz 帯と呼ばれるバンド。

高速通信が可能。

以前は、東名阪のみ遅かったが、現在は解消され、全国的に 112.5Mbps での通信が可能となっている。とはいえ、比較的後発のバンドであり、実際のカバーエリアは、まださほど広くないと推測される。

band 28:下り 758 MHz~803MHz、上り 703 MHz~748MHz

将来的にサービス開始される予定だが、現在はまだ利用できない。

2015 年サービスインという話もあったが、後ろ倒しとなり、導入時期未定となっている。

参考リンク



カウンター


カンパのお願い
Amazon でお買い物の際は、下記で検索して頂けたら幸いです。
記事検索
最新コメント
  • ライブドアブログ