アカウント名:
パスワード:
はい？なんのためのチェックデジットなんだろか、、、
必ず検知できるんだったら、単なる冗長化やん
> こうしてみると、結局のところOCR（パスポートの場合）、バーコード（牛個体番号）、マークシート（大学入試センター）といった光学的な機械読み取りが前提となっているコードにはチェックデジットが抵抗なく、かつ比較的「正しく」導入されてきたのに、事務処理上機械入力されることが前提になっておらず、人による手入力が前提になっている運転免許証などのコードにはチェックデジットが導入されないか、導入されるとしても深く考えられていないものが用いられている傾向が感じられます。
元記事は「確実に検知できないからゴミ」と言いたいわけではないらしい書類仕事が自動化される時には暗号学の素養が必要なアルゴリズム選択が雑になりがちということを嘆いているんだろうか
つまり、事務処理で用いられるコードに対してどのようなチェックデジットを与えるのが適切かという判断基準がなく、それが（人手の作業も含む）事務処理上の効率化において鍵になるという発想が共有されていないのが問題だろうと思うのです。...それと同様に、チェックデジットに限らずICT機器と人が連携して事務処理を行う際に、技術的な勘所に対して何らかの基準を満たすことを促すような仕組みが、国の機関のどこかに必要な気がするのです。
雑なのを嘆くとともに、そもそも必要性が認識されてない事も言いたいようだ。
思うに、人が介在するシステムの問題は、介在する人にも責任が分散してしまうから解決が後手になるんだと思う。なにごとにつけ。
チェックデジットの一般的な実装では、ナンバーの各桁を特定の数式で処理することで入力されたナンバーが間違っていないかどうかを検出できるのだが
実装によって若干の差はあるが、チェックデジットが１桁なら「入力ミスでも１／１０に近い確率で通ることはある」
いやまあ、たとえば「各桁の数字を足して下１桁をチェックディジットにする」みたいな原始的な方法なら「１桁の入力ミス」は確実に検知できるけど今度は「１２３４５６７８」と「１２３５４６７８」みたいな間違いを検知できない
チェックディジットは単純に「誤入力の確率を減らす」だけで「誤入力を確実に検知できる」ものではないんだよなぁ確実に検知したけりゃ親コメの言うように冗長化するしかない
これ読んでいないよね。
分かりやすくするため、個人番号を11桁の数字abcdefghijkxとしますと、検査用数字xはx = 11 – (6a + 5b + 4c + 3d + 2e + 7f + 6g + 5h + 4i + 3j + 2k) mod 11 ただしx≧10ならx=0です。これなら、まだしもわかりやすいでしょうか。
その分かりやすい説明で何がわかったと思ってるのかわかんないなぁ
まあ確かに、あのコメントで意味が分かるような人は、#3052845 [srad.jp]みたいなボケたことは最初っから書かないでしょうね。、#3052873 [srad.jp]の式が意味することは、「隣り合う桁に対して、異なる数を乗する」ことで、「隣り合う数値が入れ替わった時にはチェックデジットが変わる」ようになっているってことです。> 今度は「１２３４５６７８」と「１２３５４６７８」みたいな間違いを検知できないなんていう浅はかなチェックデジットなんて今時使ってるとこなんてありません。
ちなみに、製品バーコードとして広く使われているJANコードなんかは、「(a+3b+c+3d+e+…+k+3l+m) mod 10 = 0」を満たすようにチェックデジットmが設計されてます。こうすることで、隣り合う数字の入れ替わりは検出できます。(たとえば、コードの始まり2桁が「12」だったら、この部分のチェックデジット計算用の数値は1+3×2=7になりますが、この2桁が入れ替わって「21」になったらチェックデジット計算用の数値は2+3×1=5で、元の数値と変わるので誤り検出できます)ですが、この式だと二つ隣の入れ替わり(12345678が12543678になるなど)は検出できません。それでも、「各桁の数値を間違える」「隣り合う数値が入れ替わる」という「人間がやってしまいがちな入力ミス」に対抗するには、こういう式でも十分効果があると考えられており、これが実用に供されているわけです。
チェックデジットが数字1桁である以上、全部合わせれば確率10%で通ってしまうのは避けようがないけど、人間がやりがちな間違いに検知率を偏らせるように工夫がされてるってことですよね。平均すればデータ量の増加は避けようがないからといって可逆圧縮が不可能ではないように。
# しかし#3052845のようなボケたコメントがプラスモデされるのが今のスラドクォリティ
ちなみに、製品バーコードとして広く使われているJANコードなんかは、「(a+3b+c+3d+e+…+k+3l+m) mod 10 = 0」を満たすようにチェックデジットmが設計されてます。こうすることで、隣り合う数字の入れ替わりは検出できます。
49000083000194900003800019どちらも（下１桁のチェックデジットの「9」も含めて）正しいGTIN-13（JAN）コードです確率は低いですが「必ずしも桁の入れ替わり」は検知できるとは限りません
#1桁の入力ミスは確実に検知できたはずですが
本当にそれだけの意味でその数式書いたの？まぁあなたじゃないんだろうけど。
「検知できない場合があるのは問題だ」という（チェックディジットというものを理解していない）元コメに対してチェックディジットはそういうものではない、検知できない場合もあるという説明をしているって話の流れでしょう。
そこで「このチェックディジットなら数字の入れ替わりを検知できるもんね」って指摘する意味が全くわかんないよ。
上げ足とってチェックディジットのこと詳しい俺ＴＵＥＥＥＥしたいだけの人に何言っても無駄だよ
# しかもそれで「JANコードは入れ替わりも検出できます」とか言い切っちゃって反例あげられてるから凄い間抜けっぽい
1桁の入力ミスを検知できないことがあるチェックデジットなんてゴミでしょ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
一つのことを行い、またそれをうまくやるプログラムを書け -- Malcolm Douglas McIlroy
検知できない場合がある (スコア:0)
はい？なんのためのチェックデジットなんだろか、、、
Re:検知できない場合がある (スコア:0)
必ず検知できるんだったら、単なる冗長化やん
Re:検知できない場合がある (スコア:3, 興味深い)
> こうしてみると、結局のところOCR（パスポートの場合）、バーコード（牛個体番号）、マークシート（大学入試センター）といった光学的な機械読み取りが前提となっているコードにはチェックデジットが抵抗なく、かつ比較的「正しく」導入されてきたのに、事務処理上機械入力されることが前提になっておらず、人による手入力が前提になっている運転免許証などのコードにはチェックデジットが導入されないか、導入されるとしても深く考えられていないものが用いられている傾向が感じられます。
元記事は「確実に検知できないからゴミ」と言いたいわけではないらしい
書類仕事が自動化される時には暗号学の素養が必要なアルゴリズム選択が雑になりがちということを嘆いているんだろうか
Re:検知できない場合がある (スコア:1)
つまり、事務処理で用いられるコードに対してどのようなチェックデジットを与えるのが適切かという判断基準がなく、それが（人手の作業も含む）事務処理上の効率化において鍵になるという発想が共有されていないのが問題だろうと思うのです。
...
それと同様に、チェックデジットに限らずICT機器と人が連携して事務処理を行う際に、技術的な勘所に対して何らかの基準を満たすことを促すような仕組みが、国の機関のどこかに必要な気がするのです。
雑なのを嘆くとともに、そもそも必要性が認識されてない事も言いたいようだ。
思うに、人が介在するシステムの問題は、介在する人にも責任が分散してしまうから解決が後手になるんだと思う。なにごとにつけ。
Re:検知できない場合がある (スコア:1)
実装によって若干の差はあるが、チェックデジットが１桁なら「入力ミスでも１／１０に近い確率で通ることはある」
いやまあ、たとえば「各桁の数字を足して下１桁をチェックディジットにする」みたいな原始的な方法なら「１桁の入力ミス」は確実に検知できるけど
今度は「１２３４５６７８」と「１２３５４６７８」みたいな間違いを検知できない
チェックディジットは単純に「誤入力の確率を減らす」だけで「誤入力を確実に検知できる」ものではないんだよなぁ
確実に検知したけりゃ親コメの言うように冗長化するしかない
Re: (スコア:0)
これ読んでいないよね。
分かりやすくするため、個人番号を11桁の数字abcdefghijkxとしますと、
検査用数字xはx = 11 – (6a + 5b + 4c + 3d + 2e + 7f + 6g + 5h + 4i + 3j + 2k) mod 11 ただしx≧10ならx=0です。
これなら、まだしもわかりやすいでしょうか。
Re: (スコア:0)
その分かりやすい説明で何がわかったと思ってるのか
わかんないなぁ
Re:検知できない場合がある (スコア:5, 参考になる)
まあ確かに、あのコメントで意味が分かるような人は、#3052845 [srad.jp]みたいなボケたことは最初っから書かないでしょうね。、
#3052873 [srad.jp]の式が意味することは、「隣り合う桁に対して、異なる数を乗する」ことで、「隣り合う数値が入れ替わった時にはチェックデジットが変わる」ようになっているってことです。
> 今度は「１２３４５６７８」と「１２３５４６７８」みたいな間違いを検知できない
なんていう浅はかなチェックデジットなんて今時使ってるとこなんてありません。
ちなみに、製品バーコードとして広く使われているJANコードなんかは、「(a+3b+c+3d+e+…+k+3l+m) mod 10 = 0」を満たすようにチェックデジットmが設計されてます。こうすることで、隣り合う数字の入れ替わりは検出できます。
(たとえば、コードの始まり2桁が「12」だったら、この部分のチェックデジット計算用の数値は1+3×2=7になりますが、この2桁が入れ替わって「21」になったらチェックデジット計算用の数値は2+3×1=5で、元の数値と変わるので誤り検出できます)
ですが、この式だと二つ隣の入れ替わり(12345678が12543678になるなど)は検出できません。
それでも、「各桁の数値を間違える」「隣り合う数値が入れ替わる」という「人間がやってしまいがちな入力ミス」に対抗するには、こういう式でも十分効果があると考えられており、これが実用に供されているわけです。
Re: (スコア:0)
チェックデジットが数字1桁である以上、全部合わせれば確率10%で通ってしまうのは避けようがないけど、人間がやりがちな間違いに検知率を偏らせるように工夫がされてるってことですよね。平均すればデータ量の増加は避けようがないからといって可逆圧縮が不可能ではないように。
# しかし#3052845のようなボケたコメントがプラスモデされるのが今のスラドクォリティ
Re: (スコア:0)
4900008300019
4900003800019
どちらも（下１桁のチェックデジットの「9」も含めて）正しいGTIN-13（JAN）コードです
確率は低いですが「必ずしも桁の入れ替わり」は検知できるとは限りません
#1桁の入力ミスは確実に検知できたはずですが
Re: (スコア:0)
本当にそれだけの意味でその数式書いたの？まぁあなたじゃないんだろうけど。
「検知できない場合があるのは問題だ」という（チェックディジットというものを理解していない）元コメに対して
チェックディジットはそういうものではない、検知できない場合もあるという説明をしているって話の流れでしょう。
そこで「このチェックディジットなら数字の入れ替わりを検知できるもんね」って指摘する意味が全くわかんないよ。
Re: (スコア:0)
上げ足とってチェックディジットのこと詳しい俺ＴＵＥＥＥＥしたいだけの人に何言っても無駄だよ
# しかもそれで「JANコードは入れ替わりも検出できます」とか言い切っちゃって反例あげられてるから凄い間抜けっぽい
Re: (スコア:0)
1桁の入力ミスを検知できないことがあるチェックデジットなんてゴミでしょ