56
48

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

OSSTechAdvent Calendar 2018

Day 22

IC運転免許証に格納されたデータを紹介してみる

Last updated at Posted at 2018-12-21

はじめに

唐突ですが、持ってますか? 運転免許証

警察庁の運転免許証のサンプル画像

警察庁が公開している運転免許統計を見る限り、だいたい3人に2人が有効な免許証を保有しているのではないかと思います。
実際あると便利ですよね。自動車等を運転できるようになるのは勿論のこと、身分証明書としても便利に使えるので、身分証目的で取得したという人もいるかもしれません。

そんな便利な免許証ですが、その中にどんなデータが格納されているのか知っている人は、果たしてどれだけいるでしょうか?
券面に書かれている内容からある程度の予想はできると思いますが、仕様書まで読んだことがある人はほとんどいないのではないでしょうか?

と言うことで、この記事では運転免許証のICチップの中にはいったいどんなデータが格納されているのか、2018/12/21現在における仕様書の内容をベースにふわっと紹介します。

なお、ICチップを搭載していない古い運転免許証に関しては、全く考慮していません。
また、運転免許証から各種論理ファイルの内容を読み出すまでに関しても一切触れないので、あらかじめご了承ください。

(ちなみに上記の画像は警察庁のページから拝借してきた画像を加工したものです。)

仕様書はどこにあるのか

警察庁によって、普通にネット上に公開されています。「運転免許証 仕様」とでもググればすぐに見つかるかと思います。

2018/12/21現在では、「運転免許証及び運転免許証作成システム等の仕様の改正について」というPDFファイルが見つかり、その中に「運転免許証及び運転免許証作成システム等仕様書」が含まれています。
ちなみに仕様書のバージョンは007となっていました。

上記の仕様書を含む諸々の通知が掲載されているのは、警察庁ホームページの警察庁の施策を示す通達(交通局)です。運転免許証に関連する通知は運転免許課にあります。

※追記
2019/04/03にバージョン008の仕様書が公開されたのにあわせ、上記はリンク切れとなったようです。
最新版の仕様書は以下となります。
運転免許証及び運転免許証作成システム等の仕様の改正について (V8)

※追記2(2020/12/03)
旧姓併記に伴い、2019/11/28に仕様の一部改正が行われたようです。
運転免許証及び運転免許証作成システム等の仕様の一部改正について

※追記3(2021/08/03)
2021/06/30にバージョン009の仕様書が公開されたのにあわせ、008の仕様書と「一部改正について」へのリンクは無効になってしまったようです。
最新の009の仕様書は以下となります。
運転免許証及び運転免許証作成システム等の仕様の改正について (V9)

なお、2019/11/28の一部改正に記載されていた旧姓併記に関する記述は009の仕様書に取り込まれていました。別紙2の10ページ目の「チ 旧姓を使用した氏名の取り扱い」からページの終わりまでが一部改正から取り込まれた内容です。他に008からの大きな変更はありませんでした。

ファイルの構成

IC運転免許証の中には、以下のような構成の論理ファイルが入っています。
「:」以降にはファイルの内容を記載しています。

MF
├── DF1
│   ├── EF01: 記載事項(本籍除く)
│   ├── EF02: 記載事項(本籍)
│   ├── EF03: 外字
│   ├── EF04: 記載事項変更等(本籍除く)
│   ├── EF05: 記載事項変更(外字)
│   ├── EF06: 記載事項変更(本籍)
│   └── EF07: 電子署名
├── DF2
│   └── EF01: 写真
├── DF3
│   └── EF01: RFU (reserved for future use)
├── EF01: 共通データ要素
├── EF02: PIN設定
├── IEF01: 暗証番号1(PIN 1)
└── IEF02: 暗証番号2(PIN 2)

MFDFは、Windowsのファイルシステムで例えると、それぞれ「ルートフォルダ」と「フォルダ」、EFおよびIEFは「ファイル」のようなものだと思ってください(Linux界隈の人は「フォルダ」を「ディレクトリ」に読み替えてください)。
そのため、上記のようにMFやDFの下にEFやIEFがあるような構成を取ることができます。

ファイルのデータ構造

EF01やEF02といった各ファイルの中には、タグフィールド(T)長さフィールド(L)値フィールド(V)の3つで構成される基本符号化TLV(BER-TLV)フォーマットのデータ(以降「TLVデータ」)が1つ以上並んでいます。

TLVデータ1 TLVデータ2 TLVデータ3 ・・・
T L V T L V T L V ・・・

各フィールドに関しては後述しますが、値フィールドの長さに応じて各フィールドの長さは以下のように変化します。

(A) 値フィールドの長さが0~127バイトである場合

タグフィールド 長さフィールド 値フィールド
1バイト 1バイト 0~127バイト

(B) 値フィールドの長さが128~65535バイトである場合

タグフィールド 長さフィールド 値フィールド
1または2バイト 3バイト 128~65535バイト

タグフィールドとは

タグフィールドには、対応する値フィールドにどういったデータが格納されているのかを知るための値が入っています。要はラベルのようなものだと考えてください。
基本的には16進数で"01"~"FE"となる1バイトの値が入っていますが、MF/DF2/EF01(写真)の場合のみ"5F40"という2バイトの値が入っています。

例えば、「記載事項(本籍除く)」のデータが入っているMF/DF1/EF01で、あるTLVデータのタグフィールドの値が"12"であれば、対応する値フィールドには氏名が入っていると判断できます。

タグフィールドと値フィールドの内容の対応関係に関しては、仕様書に記載されています。

長さフィールドとは

長さフィールドは、後述の値フィールドの長さを示します。
仕様書では、上述の(A)のように値フィールドが0~127バイトの場合、b8(最上位ビット)を0とし、続くb7~b1で0~127の整数を符号化(上位先順)するよう定められています。

b8 b7 b6 b5 b4 b3 b2 b1
0 0 or 1 0 or 1 0 or 1 0 or 1 0 or 1 0 or 1 0 or 1

例えば、値フィールドの長さが100のとき、長さフィールドは16進数で"64"となる1バイトの値になります。

また(B)のように値フィールドが128~65535バイトの場合、長さフィールドは3バイトとなり、この内の第1バイトを16進数で"82"とし、残りの2バイトで65535までの値を表現します。

第1バイト  第2バイト  第3バイト
"82"(固定値) 16ビットで65535までの値を表現

例えば、値フィールドの長さが256のとき、16進数で"820100"となる3バイトの値になります。

長さフィールドの最上位ビットを見ることで、(A)と(B)のどちらのパターンか判別することができます。

値フィールドとは

値フィールドは、名前の通り値が入ったフィールドです。
長さフィールドの値が"00"、すなわち値フィールドの長さが0の時、値フィールドは存在せず、長さフィールドのすぐ後に、次のTLVデータのタグフィールドが来ることになります。

値フィールドに何のデータが格納されているかは、タグフィールドの値を見ればわかります。

値がどのように符号化されているかは値フィールドによって異なります。各値フィールドの符号化方式に関しては仕様書をご参照ください。

各ファイルの内容

各ファイルにどのような情報がどのように格納されているのか紹介します。
「記載事項(本籍除く)」や「JIS X 0208 制定年番号」のようなファイルやデータの内容を示す単語は、仕様書そのままの表現としていますのでご理解ください。

分かりやすくするため、タグフィールドを青色、長さフィールドを赤色、値フィールドを緑色とした、16進数で表現することとします。また、「"」で囲まれた数値は16進数表記とします。

なお、以降で登場するTLVデータの具体例のうち、氏名や生年月日のような個人情報に関連するものは実際のデータを参考に作成した架空のデータとなっています。

記載事項(本籍除く)

MF/DF1/EF01には**記載事項(本籍除く)**が格納されています。
具体的には、氏名や生年月日、住所と言った一般的な個人情報や、「免許証の色区分(優良・新規・その他)」や「免許の条件1」、「免許の年月日(普通)」と言った運転免許証ならではの情報が格納されています。

タグフィールド値フィールドの対応関係は以下の通りです。"34"~"3F"はRFUとなっています。

タグ データ内容 タグ データ内容
"11" JIS X 0208 制定年番号 "22" 免許の年月日(二・小・原)
"12" 氏名 "23" 免許の年月日(他)
"13" 呼び名(カナ) "24" 免許の年月日(二種)
"14" 通称名 "25" 免許の年月日(大型)
"15" 統一氏名(カナ) "26" 免許の年月日(普通)
"16" 生年月日 "27" 免許の年月日(大特)
"17" 住所 "28" 免許の年月日(大自二)
"18" 交付年月日 "29" 免許の年月日(普自二)
"19" 照会番号 "2A" 免許の年月日(小特)
"1A" 免許証の色区分(優良・新規・その他) "2B" 免許の年月日(原付)
"1B" 有効期間の末日 "2C" 免許の年月日(け引)
"1C" 免許の条件1 "2D" 免許の年月日(大二)
"1D" 免許の条件2 "2E" 免許の年月日(普二)
"1E" 免許の条件3 "2F" 免許の年月日(大特二)
"1F" 免許の条件4 "30" 免許の年月日(け引二)
"20" 公安委員会名 "31" 免許の年月日(中型)
"21" 免許証の番号 "32" 免許の年月日(中二)
"33" 免許の年月日(準中型)

実際にどう言った値が格納されているのか、TLVデータの具体例を交えていくつか紹介します。

JIS X 0208 制定年番号

110178

"11"JIS X 0208 制定年番号であることを、"01"は値フィールドの長さが1であることを示しています。

値フィールドは符号化時に参照したJIS X 0208の制定年下2桁を示しています。例えば1983年の場合、"83"となります。
なお、仕様書には以下のようにあります。

  • ただし、JIS C 6226は、“78”とする。

以上のことから、例のように"78"とある場合は、MF/DF1/EF01の他のデータでJIS X 0208で符号化されたと仕様書にあるものは、厳密には1978年に制定されたJIS C 6226を参照して符号化されたもの判断することができます。

ただし、以降ではJIS C 6226を参照して符号化されたと判断できる場合でも単に「JIS X 0208」と記載しますのでご了承ください。

氏名

120A3B33FFF1212142404F3A

"12"氏名であることを、"0A"は値フィールドの長さが10であることを示しています。

値フィールドをJIS X 0208に基づいて変換していくと、以下のようになります。

"3B33" "FFF1" "2121" "4240" "4F3A"
JIS X 0208には存在しない 全角スペース

表にもあるように、"FFF1"はJIS X 0208に存在しません。
これは"FFF1"がJIS X 0208の文字コードではなく、外字が使用されていることを示す値であるためです。(外字に関しては後述をご参照ください。)
"FFF1"を正しく変換して表示するためには、MF/DF1/EF03に格納されている外字1のデータを画像にデコードして表示する必要がありますが、ここでは「(外字1)」とすることにします。

結果、このTLVデータからは「山(外字1) 太郎」という氏名を得ることができます。

生年月日

160733353030363031

"16"生年月日であることを、"07"は値フィールドの長さが7であることを示しています。

値フィールドをJIS X 0201に基づいて変換していくと、以下のようになります。

"33" "35" "30" "30" "36" "30" "31"
3 5 0 0 6 0 1

これらの数値は順に元号1桁、年2桁、月2桁、日2桁を表しています。
元号の数値は明治=1、大正=2、昭和=3、平成=4と定められています。

結果、「昭和50年06月01日」という生年月日を得ることができます。

(2019/12/13追記)
バージョン008の仕様書によるとで令和=5と定められたようです。

免許の条件1

1C06346336404579

"1C"免許の条件1であることを、"06"は値フィールドの長さが6であることを示しています。
(「免許の条件」は運転免許証表面の「免許の条件等」の右に書いてあるアレです。IC運転免許証には、「免許の条件1」~「免許の条件4」の4つまで記入できるようになっているようです。)

値フィールドをJIS X 0208に基づいて変換していくと、以下のようになります。

"3463" "3640" "4579"

結果、「眼鏡等」という免許の条件1を読み取ることができます。

免許の年月日(普通)

260734323030343031

"26"は**免許の年月日(普通)**であることを、"07"は値フィールドの長さが7であることを示しています。

値フィールドをJIS X 0201に基づいて変換していくと、以下のようになります。

"34" "32" "30" "30" "34" "30" "31"
4 2 0 0 4 0 1

冒頭の4は平成を意味するので、「平成20年04月01日」という普通自動車免許の取得年月日を得ることができます。

免許の年月日(大特)

270734303030303030

"27"は**免許の年月日(大特)**であることを、"07"は値フィールドの長さが7であることを示しています。

値フィールドをJIS X 0201に基づいて変換していくと、以下のようになります。

"34" "30" "30" "30" "30" "30" "30"
4 0 0 0 0 0 0

冒頭の4は平成を意味するので、「平成00年00月00日」という大型特殊自動車免許の取得年月日を得ることができます。この値は大型特殊自動車免許を保有していないことを意味します。

記載事項(本籍)

MF/DF1/EF02には**記載事項(本籍)**が格納されています。
具体的には、本籍のみが格納されています。

タグフィールド値フィールドの対応関係は以下の通りです。

タグ データ内容
"41" 本籍

実際にどう言った値が格納されているのか、TLVデータの具体例を交えて紹介します。

本籍

411E456C357E455440694265454436683262242C34582332215D2331215D2332

"41"本籍であることを、"1E"は値フィールドの長さが30であることを示しています。

値フィールドをJIS X 0208に基づいて変換していくと、以下のようになります。

"456C" "357E" "4554" "4069" "4265" "4544" "3668" "3262" "242C" "3458" "2332" "215D" "2331" "215D" "2332"

結果、「東京都千代田区霞が関2-1-2」という本籍を得ることができます。ちなみにこの住所は警察庁も入居している中央合同庁舎第2号館のものです。

外字

MF/DF1/EF03には外字が格納されています。
具体的には、JIS X 0208で規定されていない文字のBitMapデータをエンコードしたものが格納されています。外字1と外字2の、最大2つのデータを格納できるようです。

タグフィールド値フィールドの対応関係は以下の通りです。

タグ データ内容
"48" 「文字構成」+「外字1」
"49" 「文字構成」+「外字2」

「文字構成」は外字のドット数を示す1バイトの値です。"50"であれば外字の大きさは50x50となります。80x80ではないのでご注意ください。
この1バイトの値と外字のBitMapデータをエンコードしたものが連結された値が値フィールドに格納されています。

どういった文字が外字として免許証に格納されるのかについては、後述をご参照ください。
エンコード方法等の詳細に関しては、仕様書をご参照ください。

ちょうど私の運転免許証でも外字が使用されていたため、そのTLVデータを具体例として記載しておきます。

外字1

485E509133D7939FAA3CB5A7F4FE1793828983CD9FFC75D1E4487FED3D756BFEE17F6D05FDBA38BFF84FFBD27FCB8657FFF9117FFFFFCC67AFFDA7FF887FFAFFCD8BFFD7FFFFFFFFFFFFF88FFF1FFF32336788D3F11FFFE4505BC3C1E3001001

"48"外字1であることを、"5E"は値フィールドの長さが94であることを示しています。

これを頑張ってデコードすれば「﨑(たつさき)」のビットマップデータを取得できるはずです。(私は自力でデコードしたことありませんが。)

単純にどういった画像がエンコードされているか確認するだけであれば、私が上記の値フィールドをチマチマ加工してTIFFファイルとし、それを更に適当なツールでPNGに変換したものを以下に用意したのでご利用ください。

ちなみに、変換前のTIFFファイルは以下になります。
TIFFファイルに対応した画像ビューア等であれば画像を表示できるはずです。

TIFFファイル

記載事項変更等(本籍除く)

MF/DF1/EF04には**記載事項変更等(本籍除く)**が格納されています。
具体的には、「新住所」や「新氏名」といった運転免許証裏面の備考欄に書かれている情報が記載されています。
(ファイルには格納されているが、備考欄には記載されてない情報もあるかもしれません。)

タグフィールド値フィールドの対応関係は以下の通りです。

タグ データ内容
"50" 追記の有無
"51"~"5F" 「JIS X 0208 制定年番号」+「(元号)YYMMDD」+「住所地公安委員会名」
"60"~"67" 「JIS X 0208 制定年番号」+「(元号)YYMMDD」+「新氏名」+「住所地公安委員会名」
"68"~"6F" 「JIS X 0208 制定年番号」+「(元号)YYMMDD」+「新呼び名」+「住所地公安委員会名」
"70"~"77" 「JIS X 0208 制定年番号」+「(元号)YYMMDD」+「新住所」+「住所地公安委員会名」
"78"~"7F" 「JIS X 0208 制定年番号」+「(元号)YYMMDD」+「新条件」+「住所地公安委員会名」
"80"~"87" 「JIS X 0208 制定年番号」+「(元号)YYMMDD」+「条件解除」+「住所地公安委員会名」
"88"~"8F" 「JIS X 0208 制定年番号」+「(元号)YYMMDD」+「備考」+「住所地公安委員会名」
"90"~"97" 「JIS X 0208 制定年番号」+「(元号)YYMMDD」+「予備」+「住所地公安委員会名」

実際にどう言った値が格納されているのか、TLVデータの具体例を交えていくつか紹介します。

追記の有無

500111

これは追記の有無を表すデータです。
値フィールドの値が"11"である場合、MF/DF1/EF04には「新氏名」や「新住所」といった何らかの情報が追記されているものと判断できます。

新住所

7037782334233323302330233123302331456C357E455440694265454436683262242C34582332215D2331215D2332456C357E455438783042

"70"新住所であることを、"37"は値フィールドの長さが55であることを示しています。

値フィールドですが、最初の1バイトは記載事項(本籍除く)のJIS X 0208 制定年番号と同様に、符号化する際に参照したJIS X 0208制定年下2桁を示しているため、具体的な新住所の情報は2バイト目から記載されています。

値フィールドの第2バイト以降の内容をJIS X 0208に基づいて変換すると以下のようになります。

4300101東京都千代田区霞が関2-1-2東京都公安

内容としては、順に変更年月日(7字)、新住所、公安委員会名(5字)となっています。

変更年月日は記載事項(本籍除く)の生年月日同様のルールとなっており、この例の場合は平成30年01月01日となります。

公安委員会名はデータの追記を行った公安委員会の名前を5字で表したもので、例えば東京都公安委員会であれば「東京都公安」となる模様です。
(「神奈川県」のように4字の都道府県の場合にどうなるかは把握していません。)

知人の運転免許証裏面の備考欄を拝見したところ「東京都公安」と印字される代わりに、「東京公委」とスタンプを押されていました。

記載事項変更(外字)

MF/DF1/EF05には**記載事項変更(外字)**が格納されています。
具体的には、MF/DF1/EF03(外字)と同様に外字データが格納されています。

MF/DF1/EF03には最大2つの外字データを格納できるようになっていますが、それでは足りない場合にこのファイルに外字データを格納するようです(外字3~外字7の最大5つ)。

タグフィールド値フィールドの対応関係は以下の通りです。

タグ データ内容
"A0" 追記の有無
"A1" 「文字構成」+「外字3」
"A2" 「文字構成」+「外字4」
"A3" 「文字構成」+「外字5」
"A4" 「文字構成」+「外字6」
"A5" 「文字構成」+「外字7」

記載事項変更(本籍)

MF/DF1/EF06には**記載事項変更等(本籍)**が格納されています。
具体的には、新本籍が記載されています。

タグフィールド値フィールドの対応関係は以下の通りです。

タグ データ内容
"AA" 追記の有無
"AB"~"AF" 「JIS X 0208 制定年番号」+「(元号)YYMMDD」+「本籍」+「住所地公安委員会名」

実際にどう言った値が格納されているのか、TLVデータの具体例を交えて紹介します。

追記の有無

AA0111

これは追記の有無を表すデータです。
値フィールドの値が"11"である場合、MF/DF1/EF06には「新本籍」が追記されているものと判断できます。

新本籍

AB37782334233323302330233123302331456C357E455440694265454436683262242C34582332215D2331215D2332456C357E455438783042

"AB"新本籍であることを、"37"は値フィールドの長さが55であることを示しています。

値フィールドの第2バイト以降の内容をJIS X 0208に基づいて変換すると以下のようになります。

4300101東京都千代田区霞が関2-1-2東京都公安

電子署名

MF/DF1/EF07には電子署名が格納されています。
具体的には、電子署名、シリアル番号、発行者名、主体者名、主体者鍵識別子が記載されています。

タグフィールド値フィールドの対応関係は以下の通りです。

タグ データ内容
"B1" 電子署名
"B2" シリアル番号
"B3" (RFU)
"B4" 発行者名
"B5" 主体者名
"B6" 主体者鍵識別子

実際にどう言った値が格納されているのか、TLVデータの具体例を交えていくつか紹介します。

発行者名

B4486F753D4E5041204943444C20526F6F742043412C6F753D4E6174696F6E616C20506F6C696365204167656E63792C6F3D4A6170616E65736520476F7665726E6D656E742C633D4A50

"B4"発行者名であることを、"48"は値フィールドの長さが72であることを示しています。

値フィールドの内容をJIS X 0201に基づいて変換すると以下のようになります。

ou=NPA ICDL Root CA,ou=National Police Agency,o=Japanese Government,c=JP

主体者名

B574636E3D546F6B796F204D5053432C6F753D507265666563747572616C205075626C69632053616665747920436F6D6D697373696F6E7320666F72204943444C2C6F753D4E6174696F6E616C20506F6C696365204167656E63792C6F3D4A6170616E65736520476F7665726E6D656E742C633D4A50

"B5"主体者名であることを、"74"は値フィールドの長さが116であることを示しています。

値フィールドの内容をJIS X 0201に基づいて変換すると以下のようになります。

cn=Tokyo MPSC,ou=Prefectural Public Safety Commissions for ICDL,ou=National Police Agency,o=Japanese Government,c=JP

ちなみに、石川県で取得した免許証の場合は以下のような文字列が格納されていました。

cn=Ishikawa PPSC,ou=Prefectural Public Safety Commissions for ICDL,ou=National Police Agency,o=Japanese Government,c=JP

写真

MF/DF2/EF01には写真が格納されています。
具体的には運転免許証表面に印刷されている顔写真が、JPEG2000のフォーマットで格納されています。
ただし、運転免許証の顔写真がカラー写真であるのに対し、格納されている画像は色が着いていないモノクロの画像となっているようです。

タグフィールド値フィールドの対応関係は以下の通りです。

タグ データ内容
"5F40" 写真

このファイルのみ、TLVデータのタグフィールドが"5F40"という2バイトの値になります。

共通データ要素

MF/EF01には共通データ要素が格納されています。
具体的には、カード発行者データと発効前データが格納されています。

タグフィールド値フィールドの対応関係は以下の通りです。

タグ データ内容
"45" カード発行者データ
"46" 発行前データ

実際にどう言った値が格納されているのか、TLVデータの具体例を交えて紹介します。

カード発行者データ

450B3030362016060120210701

"45"カード発行者データであることを、"0B"は値フィールドの長さが11であることを示しています。

値フィールドの内容は、順に仕様書バージョン番号(3バイト)、交付年月日(4バイト)、有効期限の末日(4バイト)となっています。

仕様書バージョン番号はJIS X 0201で符号化されています。

交付年月日および有効期限の末日は4バイトで西暦を表したもので、例えば"20181220"の場合、2018年12月20日となります。

以上のことから、例の場合は仕様書バージョンが006、交付年月日が2016年06月01日、有効期限の末日が2021年07月01日とわかります。

暗証番号(PIN)設定

MF/EF02には以下のような暗証番号(PIN)設定が格納されています。

050101

"05"は暗証番号(PIN)設定であることを、"01"は値フィールドの長さが1であることを示しています。

値フィールドの値が上記の例のように"01"であれば暗証番号(PIN)が設定されていることを、"00"であれば暗証番号(PIN)が設定されていないことを示します。

噂によると、免許の発行時に暗証番号の登録を行わないという選択肢が取れるようなので、その設定を記録するためのファイルと思われます。

暗証番号1(PIN 1)

MF/IEF01には**暗証番号1(PIN 1)**が格納されています。
PIN 1は4桁の数字です。
運転免許証の交付を受けた後に変更することはできません。
(暗証番号を忘れた場合、警察署へ行けば暗証番号を教えて貰えますが、暗証番号をリセットすることはできないようです。)

補足

暗証番号(PIN)設定に暗証番号を設定しない旨が記載された免許証の場合、任意の暗証番号の代わりにデフォルトPINの「****」が記録されているようです。

手元に暗証番号が未設定の免許証がないので実際に試したわけではないのですが、このような免許証の場合、暗証番号として「****」が使える旨が仕様書には記載されています。

そのため、公的機関以外ではまともにデータを読み出せないような免許証を発行して欲しい場合は、暗証番号の設定を行わないのではなく、その場で適当な乱数でも設定し、すぐに忘れるのが良いのではないかと思います。

暗証番号2(PIN 2)

MF/IEF02には**暗証番号2(PIN 2)**が格納されています。
詳細は暗証番号1(PIN 1)と同じです。

外字とは

仕様書において、外字は以下のように定義されています。

  • JIS X 0208に規定されていない文字であり、かつ、DF1/EF03 又は DF1/EF05 において定義された文字

例えば、名前や住所等に「﨑(たつさき)」のようなJIS X 0208で規定されていない文字が含まれていて、その文字の画像データがMF/DF1/EF03またはMF/DF1/EF05に格納されていれば、その文字は外字です。

氏名等の文字列を構成する各文字は、基本的にJIS X 0208で符号化された形で格納されていますが、外字が含まれる場合は代わりにどの外字画像データに対応しているかを示す値("FFF1"~"FFF7")が格納されます。(例: MF/DF1/EF01の氏名)
このような外字を含んだ文字列を正しく表示する場合、"FFF1"のような値の箇所で対応する外字画像データをデコードした画像を表示する必要があります。

イメージとしては以下のような感じです。(「﨑(たつさき)」は画像です。)

"3B33" "FFF1" "2121" "4240" "4F3A"
全角スペース

なお、格納できるのはMF/DF1/EF03MF/DF1/EF05で合わせて最大7字のため、氏名や住所等に多くのJIS X 0208規定外の文字が使われている場合は、JIS X 0208規定外の文字であっても運転免許証に画像データが格納されていない可能性があります。
この場合、その文字は画像の存在しない欠字として扱われ、"FFFA"が使用されるようです。

文字の符号化

これまでしれっと登場していたJIS X 0201JIS X 0208ですが、一応説明しておきます。

JIS X 0201

JIS X 0201は規格名称を「7ビット及び8ビットの情報交換用符号化文字集合」と言います。
この規格の中には、0~9の数字やa~z及びA~Zのアルファベット、「*」や「?」のような記号と8ビット(1バイト)の値との対応関係が含まれます。
運転免許証内のデータのうち数字やアルファベット、記号のみで表現されるようなデータは、この対応関係を用いて各文字に一対一で対応する1バイトの値を並べたものを格納しています。

JIS X 0208

JIS X 0208は規格名称を「7ビット及び8ビットの2バイト情報交換用符号化漢字集合」と言います。
この規格の中には、規定された漢字集合(漢字以外に平仮名やカタカナ、数字等を含みます)と2バイトの値との対応関係が含まれます。
運転免許証内のデータのうち、JIS X 0208で規定された漢字集合に含まれる文字で表現されるようなデータは、この対応関係を用いて各文字に一対一で対応する2バイトの値を並べたものを格納しています。
(この漢字集合に含まれない文字は外字や欠字として扱われます。)

所感

個人情報に﨑(たつさき)が含まれていることが役に立つ日が来ようとは、思ってもみませんでした。

参考文献

https://www.npa.go.jp/policies/application/license_renewal/index.html
https://www.npa.go.jp/pdc/notification/koutuu/menkyo/menkyo20160715.pdf (リンク切れ)
https://www.npa.go.jp/laws/notification/koutuu/menkyo/menkyo20190403_070.pdf (リンク切れ)
https://www.npa.go.jp/laws/notification/koutuu/menkyo/menkyo20210630_150.pdf
http://eternalwindows.jp/security/scard/scard08.html
https://ja.wikipedia.org/wiki/JIS_X_0201
https://ja.wikipedia.org/wiki/JIS_X_0208
https://ja.wikipedia.org/wiki/JIS%E6%BC%A2%E5%AD%97%E3%82%B3%E3%83%BC%E3%83%89
http://www.asahi-net.or.jp/~EK5Y-NSMR/ref-ascii.htm
http://www.asahi-net.or.jp/~ax2s-kmtn/ref/jisx0208.html#level1
http://www.snap-tck.com/room03/c02/cg/cg05_01.html

似たような記事

良ければこちらもどうぞ。

56
48
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
56
48

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?