ラベル 文字化け の投稿を表示しています。 すべての投稿を表示
ラベル 文字化け の投稿を表示しています。 すべての投稿を表示

2012/12/29

文系のための「調査データの構造」(2)

どのような調査でも、調査の段階は大きく分けて二つの段階に分けることができる。
第一段階は情報収集の段階であり、第二段階は情報構築の段階である。
研究段階の分析と解釈は、再構築された情報を用いて行うのが常である。

紙媒体が中心であった時代には、主として分析と解釈に焦点を当てられてきたが、
その背景には、紙媒体の物理的な限界があると考えられる。
全データを記載しても、必要な情報を得難いにも関わらず、紙面をかなり圧迫する。

しかしながら、デジタルデータを用いるようになるとこの状況は大きく変わる
記録媒体の大容量化、検索システムの高度化、情報通信速度の高速化
こうした技術革新は、紙媒体の持つ物理的限界を簡単に克服してしまった。

問題は、こうした技術革新に多くの人がついて行けていない現状...。

一般的に研究「資料」は費やした人的、金銭的、時間的コストに価値があるが、
一方、構築された「情報」は認知度と共有性に価値がある。
情報は、公開し、共有することで価値が産まれるこれ超基本

珍しいデータや貴重なデータをハードディスクに放置しても意味が無い
著作権個人情報が関係しないデータであれば、積極的に公開した方が良い
もちろん、きちんと整理された状態で公開しないといけないが。

このように言うと、多くの人は納得してくれるのであるが、残念なことに
自分が他人のデータを使うことには何の抵抗も感じないが、
自分が他人のためにデータを公開することを拒否する人は非常に多い

近年、欧米を中心に過去の資料のデジタル化と公開化が進められていて、
それに伴って、歴史的な資料の再発見が相次いでいるが、日本では少ない
デジタル化と情報公開は、一緒に考える必要があるのだが...色々と中途半端。

さて、最初から話が逸れそうになったが、要するに、分析と解釈だけの時代は終わり
現在は、分析と解釈に至るまでに、どのような資料が収集され、情報が構築されたかが、
重要視されつつあるということ。この問題は改めて考える必要がある。

情報を体系的に管理することは、研究データの消失の危険性を低減し、
また、データ改ざんの問題を未然に防ぐこともできる。
第三者が後に研究過程を復元できるような試みは必須条件になりつつある。

本ブログで紹介する方法は、データ公開の要請に迅速に対応できる方法にもなる。
前回の話では、第一段階として、一次取得データの管理方針について述べたが、
今回の話では、第二段階として、二次加工データの管理方針について述べる。

一次取得データの話でも述べたように、取得した生データは直接加工しない。
これはオリジナルの状態で保存する。再度、取り直しができるとは限らない。
二次加工データは、一次取得データから必要な物のみをコピーして編集したデータ

まずは、データの構造を考えてみる。以下は、その模式図。
二次加工データは、「調査成果というまとまりで管理され、
さらに調査成果のまとまりを「」としたサブディレクトリを複数持つ。
版は、調査次数(年度)に対応するかもしれないが、対応する必要は無い

各「」の中には、各々の「作業」に応じたサブディレクトリが作られる。
例えば、図面、文章、集計表、測量図、写真、動画、音声...など。
要するに、日付毎で取得されたデータを種別毎に再割り振りする感じ。

ここで重要なポイントは、元データは、一次取得データから「コピー」すること
間違っても「移動」してはいけない。データの重複が生じても構わない。
一次取得データは、何があっても直接には触らないこと。

コンピュータのデータは、見た目が変わらなくても、
ちょっとした操作で、メタデータが書き換えられることがある
データを得た時の情報を可能な限り維持することが重要。

あとは、フォルダ名とファイル名の付け方。何を注意するのだったか?
確か、半角英数スペースと記号は使わないのだった。
そうそう、使って良いのは「_」の記号だけだった。

さてさて、これで、調査データの管理方法の初歩的な方針は理解できたはず。
ただし、このブログで示した方針は、あくまで全体的な概要であって、
より厳密に情報管理を行うためには検討すべき問題が山積している。

ファイル名やフォルダ名の付け方について、あまり詳しく述べていないが、
具体的に、どのような名称を付けるべきか?という問題や、
各フォルダには、メタデータが必要かもしれないという問題もある。

また、二次加工データに関しては、作業記録のログの記録方法や、
編集で行われた個別操作の記録の取得方法なども必要かもしれない。
では、ソフトウェアに依存するような操作の場合はどうするべきか?

実は、こうした内容こそ、各分野における情報標準の問題として議論すべきなのだが...。
まぁ、愚痴を言った所で、現状が変わる気配は全く無いので、
このままデファクトで標準を作ってしまうのは有りかもしれない。

ところで、前回の話と今回の話を合わせて見てみると、
全体的に複雑に見えたかもしれない。
これをもっと簡単にするには?という要望があるかもしれない。

本ブログでは、入門編からPython というプログラミング言語を使っているが、
要するに、前回と今回の記事で述べた方針を、Pythonで実装してしまおう、
というちょっとした意図があってのこと。

まだまだ、先は長いけれど、「えっ、パイソン?それって蛇?」って人には、
一応、文系のための「情報管理」の話を最初から読み進めることを推奨。
これから、少しずつ、難しくなっていく。

2012/12/28

文系のための「調査データの構造」(1)

Windows95 が発売されて以降、パソコンは急激に普及し、
それに伴い、あらゆる作業が電子化されるようになった。
この変化は、フィールド調査においても同様である。

パソコンと連携できる電子機器も多く登場してきた。

デジタルカメラ、デジタルビデオ、ICレコーダ、電子地図、そしてGPS
最近では、これらの機能が一体化したような電子機器もある。
スマートフォン。ある意味、最強の調査デバイス

さて、ここまで電子化が進んでいるにも関わらず、
何故か、デジタルデータの整理方法の標準化は進んでいない。
どの機器を使うべきか、何を記録するべきかとか、無意味な議論はされているようだが...。

はっきり言って、そのような問題を時間をかけて議論する意味は無い
非常に短い期間で、様々な電子機器が開発される昨今、状況はすぐに変化する
重要なことは、様々なデジタルデータを円滑に共有するための方法を整理すること。

特に、調査チームを組織して調査する場合、
調査メンバー同士が後にデータを容易に統合できるような工夫は不可欠
また、長期の調査の場合には、異なる調査年次のデータを統合する必要もあり得る

この問題は極めて重要。私自身、以下のような経験がある。

  • 前任者のデータを受け取ったものの必要なデータが見つからない...。
  • あるいは、数年前の調査データを探しても中々見つからない...。
  • データが散在していてコピーをし忘れてそのまま消去してしまった...。

似たような経験をしている人は少なくはないハズ。具体的な対策は?
デジタルデータは、ある意味、紙媒体の情報よりも消失しやすい
それゆえに、紙媒体の資料以上にデータ管理には注意しなくてはならないのである。

ということで、ファイル管理の方法について色々と考えてみる。

そもそも、調査データには、一次取得データ二次加工データの二種類があり、
今回の話では、一次取得データに焦点を絞ることにする。
二次加工データについては、次回の話で。

さて、最初に考慮するべき問題は、調査データの構造である。
そもそも、調査プロジェクトの情報はどのような構造を持っているのか?
まずは、これを整理するところから始める。

ディレクトリの話で述べたように、コンピュータは階層構造によってデータを管理する。
したがって、様々な種類の調査データはこの階層構造に写像する必要がある
これを可能にするソフトウェアを作るという手もあるが、今は手作業な方法で。

まずは、調査の階層構造について考えてみる。
概念的に解り易くするために図化したものが下の図。
あるプロジェクトがあったとして、
そのプロジェクト年度区切りあるいは複数の調査次数から成る。
たとえ、一回限りだったとしても、プロジェクトは調査次数がある

ある調査次数あるいは調査年度においては、複数の担当者が参加し、
各メンバーが、それぞれの仕事の中でデータを作成する。
通常、仕事は「」単位で行われるため日付で管理される。

日付で管理される情報は、写真、メモ、動画、音声、日誌、などなど...
要するに、デジタル化され得る全ての情報が、
データの種類毎に分けて管理される。

データの種類については、拡張子によって分類する方法と、
取得したデータの性質によって分類する方法が考えられるが、
今は、この点には踏み込まないことにする。

本当は、この部分こそ標準化する必要があるのだが。
この部分を明確化すれば、フィールドデータのメタデータを規定できる
ちなみに、私の場合は拡張子方式を採用している。

さて、このように、階層的に調査プロジェクトを整理し、
この階層に従って、フォルダを作成すると、
複数のメンバー間のデータを効率的に統合できる

ここで、重要なポイントは、例外無くこの階層に従うこと。
例外規則を作ると、後の処理が複雑になってしまう
こういった所で、論理的な思考が出来る人と出来ない人が見えてくる。

単なる理屈上の話なので、文系と理系の違いは無いハズ。
実際、工学系の人の中にも、この辺りのことが苦手な人は多い。
まぁ、そんなことはどうでも良いのであるが。

とにかく、

今回の調査の一回限りだから、調査次数のフォルダを作らなくても良い。」とか、
調査メンバーは、一人だけだから、担当者フォルダを作らなくても良い。」とか、
そういった、その場の思いつきや手抜きは絶対にダメ!!!!!

次に考慮すべきは、フォルダ名とファイル名の付け方。これは半角英数が基本
フォルダ名やファイル名に日本語の名前を付けたがる人は多いが、
日本語は、異なるOS間でのデータ交換の際に文字化けする可能性がある。

この問題は、特に、圧縮ファイルを扱う場合に生じる。
Windowsでは、圧縮する際にファイル名をShift-JISに変換し、解凍時にUnicode に戻す
ところが、Mac やLinux 上では、Shift-JISのまま解凍されるため文字化けしてしまう。

文字コードの話については、すでにしている。

Windowsしか使わないから、とか、そういった考えは良くない。
一次データを作成する段階で回避できる問題は、可能な限り回避することが重要
半角英数の部分は、Shift-JISとUnicodeのいずれもASCIIコードに従うのでこの問題は生じない。

また、フォルダ名ファイル名に関しては、スペース(空白)を入れたり、
「.」「,」「;」「:」「<」「>」「-」「+」「=」「\」「/」「|」「?」「!」...。
といった記号類も使ってはいけない

使って良い記号は「_(アンダースコア)」のみ。と覚えておくと良いかもしれない。

以上が、一次取得データの管理方法の一例である。
基本的に一次取得データは、データ取得時の状態のまま触らない
間違っても、上書き保存は絶対にしてはいけない

このデータをコピーしたものを別の場所に移動し、二次加工データとして編集する
一取得データは、調査の段階に戻る為のデータであり、
調査のバックアップであるとの認識が必要。

ところで、一つのファイルを何日もかけて処理する場合はどうするか?方法は二つある。
一つ目の方法は、前回のデータを新しくコピーしてから再編集する方法であり、
もう一つの方法は、二次加工データとして扱う方法である。

一つ目の方法は、中間データのバックアップにもなるため、
途中で大きなミスが生じた場合、編集前の段階に戻ることができるという利点がある。
しかしながら、データ容量が非常に大きい場合、ディスク容量を圧迫する可能性がある。

二つ目の方法は、あくまで二次加工データとして扱い、
今回の話で述べてきた体系とは異なる体系で管理する方法である。
次回の話では、この辺りを整理してみる。

2012/09/23

文系のための「デジタルデータ」(2)

どうやら、コンピュータは「1」と「0」の信号で動いている、ということは解った。
では、実際にはどのように信号のやり取りをしているのか?

まずは、「色の情報」をどのようにして扱っているかを整理する。
実際には、様々な方法があるのだけれど、
話を簡単にするために、「RGB」による指定方法を例に解説する。

おそらく、「色の三原色」という言葉を聞いたことの無い人は居まい。
そうそう。「赤(Red)」と「緑(Green)」と「青(Blue)」の三色で、
あらゆる色を表現できるという「アレ」。聞いたことくらいはあるだろう。

コンピュータの中でも、この三原色を使って色を表現する。
一般的には、の色の強さを、それぞれ、「0〜255」の256段階で指定し、
この3つの色を合成して、色を表現する

うん?なぜ、256段階なのか?実は、これが重要なポイント

実は、この値こそが、「1」と「0」の世界を象徴しているのである。
とりあえず、下の表を見てみる。これは、の値が取り得る範囲を示している。

三原色 2進数 16進数 10進数
赤: 0000 0000 〜1111 1111 ⇒ 00〜FF  ⇒ 0〜255
緑: 0000 0000 〜1111 1111 ⇒ 00〜FF ⇒ 0〜255
青: 0000 0000 〜1111 1111 ⇒ 00〜FF ⇒ 0〜255

まずは、2進数の場合:
例えば、赤色を表示したい場合には、「1111 1111 0000 0000 0000 0000」となる。
例えば、灰色を表示したい場合には、「1001 1001 1001 0001 1001 0001」となる。

次に、16進数の場合:
例えば、赤色を表示したい場合には、「FF 00 00」となる。
例えば、灰色を表示したい場合には、「99 99 99」となる。

ちなみに、10進数の場合
例えば、赤色を表示したい場合には、「RGB(255, 0, 0)」となる。
例えば、灰色を表示したい場合には、「RGB(153, 153, 153)」となる。

はて?2進数...16進数...10進数...何のことやら?

我々は、「10を一つの単位をし、9まで数えたら桁を繰り上げる数を使うことが多い。
これを一般的に「10進数」と呼ぶ。これも聞いたことくらいはあるハズ。
ちなみに、時計は60を単位としているので、60進数と呼ぶ。これは、常識

数学の世界では、数を数える方法には、いくつかの方法が存在している。
2進数というのは、つまりは、0と1で表す方法
1を単位とし、1まで数えたら次に「10」となるような数え方

一般的に、この2進数1桁分ビット(bit)と呼ぶ。
上の例だと、がそれぞれ8bitで表されていて、
それらを組み合わせた色は、24bitで表現できる。

24bitでそんなに多くの色を表現できるハズが無い!」と言う人がいるかもしれないが、
実際に、どの程度の色が表現できるのかというと、
なんと、「2の24乗」で「16,777,216 色」もの組み合わせが出来るのである。

さて、上の表では、16進数というのも併記してある。これは何か?

16進数というのは、9まで数えると、A⇒B⇒C⇒D⇒E⇒Fと上がっていき、
「15」まで変えぜたら次に位が一つ上がって「10」になるような数値である。
10進数と区別できないので、「0x10」のように前に「0x」を付けるのが慣例。

実を言うと、コンピュータの世界では「2進数の代わり」に、
16進数を用いることが多い。2進数だと、桁を数えるのが大変であるし、
10進数だと2進数に変換するのが面倒。だから、16進数で表す。

うん?なぜ、16進数だと変換が楽なのか?
とりあえず、下の図を見てみる。

実は、2進数16進数には「面白い関係」があって、
2進数を「4桁」ずつに区切って「16進数」に置き換えることができるので、
0000〜1111までに対応する16進数さえ覚えておけば、それ以上を覚える必要はない。

最近では、すっかり、2進数16進数でデータを扱うことは少なくなったが、
現在でもエラーメッセージなどでは、16進数がコッソリと表示されているし、
マイコン開発などでは、今でも2進数や16進数でプログラムを書くことがある。

まぁ、マニアックな話なので、この話はいずれ...。
さて、話を元に戻して...。

コンピュータでは、多くの機器がこの方法で色を表現していて、
ディスプレイの表示も、結果的には、2進数の信号として扱われているのである。

なるほど。とりあえず、色のことは解った。

では文字はどのように表すのか?
意欲的な人は、そんな疑問を持つことであろう。
ということで、ここからが「本題」。

実は、文字の場合も同じ。結果的には2進数で表すことができる。
ただし、文字の場合は、2進数に変換可能な対応表のようなものを用意し、
この対応表を参照することで、文字を表示する。これが重要!

実際には、その対応表を参照する方法は様々で、
本格的なシステムを構築するためには、かなり詳しいことを知っておく必要があるのだが、
今回は、基本的な話だけ。

さてさて、コンピュータの世界では、「文字化け」という現象が生じるが、
実は、この原因は、要するに文字の対応表にある。
以下の話を知っておけば、回避できることも増えるハズ。

とりあえず、最も基本的な対応表を見てみる。
これは、「American Standard Code for Information Interchange」の略で、
ASCII(アスキー)」と呼ばれている文字コード。歴史は長いが、「超」基本


0 1 2 3 4 5 6 7 8 9 +A +B +C +D +E +F
0x00 NUL SOH STX ETX EOT ENQ ACK BEL BS HT LF VT FF CR SO SI
0x10 DLE CD1 DC2 EC3 DC4 NAK SYN ETB CAN EM SUB ESC FS GS RS US
0x20 ! " # $ % & ' ( ) * + , - . /
0x30 0 1 2 3 4 5 6 7 8 9 : ; < = > ?
0x40 @ A B C D E F G H I J K L M N O
0x50 P Q R S T U V W X Y Z [ \ ] ^ _
0x60 ` a b c d e f g h i j k l m n o
0x70 p q r s t u v w x y z { | } ~ DEL

この文字コード表は、1960年代に標準化され、現在でも広く使われている。
アルファベットを含む128文字が定義されていて、その内、33文字は「制御文字」。
制御文字は、モニタやプリンタの制御に使うもので、今回は詳しい説明はしない

さて、試しに、「Hello」というのをこの文字コード表を使って表現してみる。

16進数:0x48 0x65 0x6C 0x6C 0x6F
2進数 :0100 1000 0110 0101 0110 1100  0110 1100 0110 1111

このように、コンピュータが扱える2進数に変換されている。中々、面白い。

ここで、注意しないといけないのが、大文字小文字区別が存在していること。
つまり、「Hello」と「hello」と「HELLO」は、それぞれ「全く異なる」信号となる。

紙の世界に慣れていると、この辺りの認識がちゃんとできないのであるが、
コンピュータの世界においては極めて重要な問題なのである。

さて、ここには、アルファベットしか存在していない日本語は?

実は、日本語はASCIIコードには含まれていないのである。
日本語を扱うための文字コード表は「」に存在している。
最も有名な文字コード表が「Shift_JISコード」と呼ばれる文字コード。以下は、その一部。


0 1 2 3 4 5 6 7 8 9 +A +B +C +D +E +F
0x00 NUL SOH STX ETX EOT ENQ ACK BEL BS HT LF VT FF CR SO SI
0x10 DLE CD1 DC2 EC3 DC4 NAK SYN ETB CAN EM SUB ESC FS GS RS US
0x20 ! " # $ % & ' ( ) * + , - . /
0x30 0 1 2 3 4 5 6 7 8 9 : ; < = > ?
0x40 @ A B C D E F G H I J K L M N O
0x50 P Q R S T U V W X Y Z [ \ ] ^ _
0x60 ` a b c d e f g h i j k l m n o
0x70 p q r s t u v w x y z { | } ~ DEL
0x80 IND NEL SSA ESA HTS HTJ VTS PLD PLU RI SS2 SS3
0x90 DCS PU1 PU2 STS CCH MW SPA ESP CSI ST OSC PM APC
以下の英数字は「JIS漢字」に含まれる
0x8240  
0x8250
0x8260
0x8270
0x8280
0x8290  
文字化けの原因となる使用禁止の文字
0xA0  
0xB0 ソ
0xC0
0xD0 °




0x8740
0x8750
0x8760
0x8770  
0x8780
0x8790

実は、Shift_JISでは、最初の部分がASCIIコードと同じで、
後ろの部分に、日本語特有の文字を加えている

まず、注意してもらいたいのが、「JIS漢字」と呼ばれる部分に定義されている文字。
この部分には、全角の数字とアルファベットが含まれる。実は、「漢字扱い」なのである。
半角」と「全角」の英数は似て非なるもの全角英数は、日本が独自

次に、「文字化け」の原因となる部分。無意識に使っていないだろうか?
この部分は、機種依存文字と呼ばれる文字が定義されている部分。
正式に標準化されているのではなく、メーカーが勝手に定義している部分

以前は「機種依存文字」と呼ばれていたもので、
現在では、「環境依存文字」と呼ばれているもの。
文系理系を問わず、常識として知っておいた方が良い。

見た目に惑わされて、この部分の文字を好んで使う人は非常に多いが、
日本製のソフトウェア以外は、対応していないことが多い。

データベースを構築したり、ホームページを作るときにもエラーの原因となる。
ましてや、この部分の文字を組み合わせた」などは、言語道断!
文字化け」が発生した場合に、元に戻せない。

この問題の「おかげ」で、私は、一体どれほどの無駄な時間を費やしたことか...。
注意しても、誰も聞いてくれない...文書化までしたのに...。そんな人とは仕事をしない...。
ましてや、ボランティアで対応できるような問題じゃない!

っと、まぁ、開発者に、そういったことを言わせないための知識と対策は必要かと。

さて、Shift_JIS の場合、「0x8540~ 0x889e」は、環境依存文字であり、
0xeb40~ 0xeffc」は、MacWindows との互換が無い部分。
そして「0xf040〜」は「外字」を定義する部分なので使ってはいけない。

そういえば、考古学文献学の人は、存在しない漢字を勝手に作ってしまう傾向にあるが、
そのような行為は、データを交換する上で大きな問題となってしまい、
システム技術者に非常に大きな負担をかけることになる。モラルとして...ね。

さて、日本語を扱える文字コード表は、Shift_JIS コードだけかというと、そうでは無い。
LinuxMac では、UTF-8 と呼ばれる文字コードを使っている。
これは、Unicode(ユニコード)と呼ばれる文字の一覧参照する方式

UTF-8 は、Shift_JIS と異なり、最初から国際化を前提としていて、
様々な国の文字を扱うことができるアラビア語ギリシア文字キリル文字なども。
実は、「文字化け」の問題を最小限に抑えるには、UTF-8 の方が無難

ところで、文字コードが間違って指定されたら何が起きるか?
Windows で作成したテキストが、Mac Linux で「文字化け」。よくある話。

以下は、簡単な例。

この例は、Windows の「メモ帳」でテキストファイルを作成し、保存したものを、
Mac で開いた例日本語のメッセージが完全に文字化けしている。
Windows ではShift JIS を使い、Mac ではUTF-8 を使っているのが原因。

あれ?と思った人もいるかもしれない。半角英数の部分は文字化けしていない

実は、Shift_JISUTF-8半角英数の部分に関しては、ASCII コードと互換があるので、
ASCII コードで定義された文字に関しては、文字化けが起きないのである。

フォルダやファイル名は、半角英数で書くのが基本中の基本」と言われるが、
実は、この問題を回避するため。日本語のファイル名は避けた方が良いのである。

とはいえ、ASCIIコードで定義されている領域であっても、記号類は避けた方が良い
記号類には、システム上で特殊な役割を担っている場合があるため。
安全なのは「_(アンダースコア)」だけ。コレ以外は、使わないのがマナー。

さて、Windows のメモ帳の場合であれば、実は、ファイルを保存するときに、
文字コードの指定というのができる。意外に知らない人が多いのだが。
とりあえず、以下のようにしておけば、Mac と Linux を使っている人には有難い

もちろん、ここで挙げた問題は、ホームページでも起こり得る話
実は、自治体のホームページに有りがち...。部署ごとにページを作っているのか、
ページによって、文字コードの指定が異なっていることもある。

こっちに合わすと、あっちで文字化け。あっちに合わすとこっちで文字化け...。

ふむふむ。不安な人は、LinuxMacホームページアクセスして確認を。
そうそう。そういったページは、iPad から見ても文字化けするのであった。どうだろう?

もちろん、Excel などでも、文字コードの気遣いが必要で、
特に、CSV形式などのテキスト形式で保存する時には、指定するべきである。
とは言うものの、私は、Excel での対処方法を知らない。そもそも、できるのか?

さて、本日のまとめ。

コンピュータは「1」と「0」で情報を扱う。
文字の場合は、文字コード表を参照し、そのコードを「1」と「0」に変換する。
文字コードを間違えて指定すると文字化けする

指定を間違える可能性は、大きく分けて二つ。
一つ目は、環境依存文字など、正式では無い文字コードを使った場合。
二つ目は、そもそも、異なる文字コード表を用いた場合(Shift-JIS とUTF-8など)

対策としては、環境依存文字を使わないように気を付けること。
また、他のシステムで見れるように、明示的に文字コードを指定すること。
おそらく、Shift-JIS よりも UTF-8 の方が無難である。半角英数は、もっと安全