  |
はてなキーワード: チェックディジットとは
最近調べる機会があったのでまとめておく。
書いてる人は郵便局ともMicrosoftとも無関係なので情報が間違っててもなんの責任も負わないことをご了承ください。
あと勢いで書いてるので口が悪かったらすみません。
宛先（返信用封筒なら返信先）の郵便番号の情報のみ含まれている。
これが印刷してあると区内特別の送料が更に安くなる。（詳細は公式サイトを見てくれ）
宛先の郵便番号・番地・アパート等の部屋番号の情報が含まれている。これを機械で読み込んで仕分けるらしい。
3本の縦線（スタートとストップは2本）で1つの数字等を表す。
参考：https://www.post.japanpost.jp/zipcode/zipmanual/p11.html
スタート・郵便番号・番地・アパート等の部屋番号・（CC4繰り返し）・チェックディジット・ストップ
全体の桁数が決まっているので、余ればC4繰り返しで埋める。足りなければ途中でおしまい。
印刷する際の大きさや角度が決まっているので注意すること。
参考：https://www.post.japanpost.jp/zipcode/zipmanual/p13.html
まず受取人払いの申請が必要だけど割愛する。最寄りの郵便局に聞いてください。
申請が受理されると、専用の郵便番号が付与される。これをバーコード化する。申請受理された通知の紙にバーコードが印刷されてるけどデータで作りたいよね。
まず、公式サイトで作ることができる。
参考：https://www.post.japanpost.jp/send/fee/how_to_pay/uke_cyaku/barcode/
ただしここでできる画像は1つの画像になってない。1桁ずつバラバラ。これを画像編集ソフトでつなげるとかすればまあ作れる。
もう一つの手段は、ネット上で誰かが公開しているバーコードメーカーみたいなのを使う。各自ググってくれ。
そんでバーコードが完成したら、見本を作って郵便局へ提出する。その辺も郵便局によって違うと思うので聞いてください。
公式サイトでは作れない。
上記①に書いてあるような非公式のバーコードメーカー的なものでも作れるし、Wordの差し込み印刷機能でも作れる（印刷データをWordで作る前提だが）。大量に作るならWordが断然便利。やり方はググればすぐ出てくる。
以下に注意
・○番×号みたいな住所の場合、○と×の間にハイフンが必要となる。参照元データが「○番×号」なら「○‐×」のバーコードが作成されるが、「○」と「×」のセルを参照する形だと間にハイフンは入れてくれない。
・参照元データの字名（※市町村名と番地の間のナントカ一丁目みたいな部分）の先頭に「大字」が入っていると郵便番号部分のデータがおかしくなる。私の場合、「123-4567」が「123-4500」みたいになった。
・マンション等の部屋番号も自動で抽出してくれるため、マンション等の名前に数字やアルファベットが入っているとそこも拾うかもしれない。私は該当がなかったからわからない。
この辺に気を付けつつ特殊な住所は1件ずつチェックするしかないのかな。
Excel上でも作れるらしいけど詳細は知らん。ググってくれ。
なるほど、システムは採番された番号もわからないし、個人情報も持ってないのでしたか。
事前に、採番番号の仕様としてチェックディジットを定めておくとか(技術的には)出来るかも。
例えば、
A: 採番番号の上X桁
B: 生年月日8桁
として
自治体は、AとBを連結したものをY桁にハッシュ化して、その結果をAと連結させることで、採番番号(X +Y桁)とする。採番番号を利用者に通知する。
利用者は、システムに採番番号(X +Y桁)と生年月日を入力する。
システムは、入力された採番番号の上X桁と生年月日を連結してY桁にハッシュ化して、その結果が入力された採番番号の下Y桁と一致するかをチェックする。
とか
色々情報が出てきたので答え合わせ。
前提として、
その通達では、券番号として、自治体内で一意であることしか定められていなかった。
したがって早期にシステムが稼働していることが求められ、期間的に全国2000ある自治体のシステムと連携させるとか、自治体にデータ入力させるとかいった手立てはとれない。
また、本システム側から発番済みの番号がわからない以上、仮パスワードを登録すること自体が困難。
システム設計レイヤーの問題と、実装レイヤーの問題があって、その2つは分けて考えないといけない。
SQLインジェクション可能とか、無茶苦茶な生年月日を登録できるとか。
特にSQLインジェクション可能が事実なら論外で、自治体と連携させなくてむしろよかったなぁという感想。
でも、5chのデマらしいけど。
誰でも予約可能みたいなのは、このシステム会社からはどうしようもなかった。
むしろ全国横断のシステムにするのではなく、パッケージにして、自治体に配布するほうが良かったんではと思うが、それはそれで、自治体側に運用コストが発生するし、結局データを自治体側に入力させることになるし、早期の稼働には間に合わなかっただろう。
本システムには、開発会社に起因する、稚拙な不具合が含まれている一方で、認証まわりの誰でもログイン問題は、開発会社の責任ではない。
去年の早い時期、ワクチン交渉の段階で、官邸や厚労省はすでに設計を開始しておくべきだった。
「誰でも予約」の問題は、直接には官邸の思いつきの大規模接種のブッコミが原因だけど、そもそも大規模接種や予約の問題は、厚労省が接種番号の仕様設計の段階で考慮しておくべきことだった。QRコードもな。
「この日に来てください、嫌なら希望の日の当日整理券を受け取って、別レーンに並んでください、接種券と本人確認書類を持ってきてね」ってはがきを送りつければよかった。
追記ここまで
=============
この件ね
https://b.hatena.ne.jp/entry/s/dot.asahi.com/dot/2021051700045.html
いや俺も、最初はこの会社クソやなと思ったんだけどさ。冷静に考えると、取れる手立ては少ないんでは。
このシステム、まともに作るなら、ワクチン接種番号の他に仮パスワードをつけてログインさせ、初回ログイン時にパスワード変更させるかたちになるだろう。
年寄りにそれができると思えないし、問い合わせは今の10倍以上くるだろう。
それに、日本中からアクセスしても落ちない認証システムを、このためだけに急遽立てろというのは酷だよ。
認証させないなら、それはそれで他人の番号で勝手に予約して、本人に摂取させない嫌がらせができてしまう。
そもそもワクチン接種券の仕様を決めたのは、竹中の会社じゃない。仮パスワード印刷をして各家庭に配布するのも、竹中の会社じゃむりだし、自衛隊側も嫌がるだろう。
詰んでんだよね。
そもそも番号と個人の紐づけ情報を参照できたのかも不明なんだけど。
