piapia123
ja

番号チェック

早見表

処理はすべてブラウザ内で完結します。データは送信されません

入力
ファイルをここにドロップすると読み込めます
出力

カード番号・IBAN・ISBN・BTC / ETH アドレスには共通点があります:末尾の数桁は、それより前の桁を検証するために存在します。つまり「写し間違いがないか」は確定した答えのある問題で、ネットワークも、どこの銀行かという知識も要りません。 手計算はかなり大変です:Luhn は 1 桁おきに倍にして 2 桁になったら繰り下げ、IBAN は英字を数字に置き換えて 97 で割った余りを見ます。ビットコインのアドレスは SHA-256 を 2 回、イーサリアムのアドレスは Keccak-256(SHA3-256 ではありません —— パディングの先頭バイトだけが違い、結果はまったく異なります)を計算します。 ⚠️ チェックディジットの一致は、その番号が実在することを意味しません。 チェックディジットは入力ミス(桁の抜けや入れ替わり)を防ぐためのもので、真偽を確かめるものではありません —— 偽のカード番号を作る人も Luhn は正しく計算します。ここが答えるのは「写し間違いがないか」だけです。

機能

  • ⚠️ 最初の行に「チェックディジットの一致は番号の実在を意味しない」と明記し、各行の判定も「有効」ではなく「チェックディジット一致」と書きます
  • 銀行カード:Luhn と IIN 号段による発行会社の判定。号段と桁数が食い違う場合は別途指摘します
  • IBAN:ISO 7064 MOD 97-10。空白と小文字を許容し、国ごとに異なる桁数(ノルウェー 15 桁、マルタ 31 桁)にも対応
  • ISBN-10(末尾 X は 10)、ISBN-13 / EAN-13、UPC-A。978/979 の接頭辞は書籍として指摘します
  • ABA ルーティング番号(重み 3-7-1)。「一致はアルゴリズムを満たすだけで、実在の銀行を意味しない」と注記します
  • BIC / SWIFT:形式のみ検証できます —— チェックディジットがないためで、その旨を判定に明記します
  • ビットコインのアドレスを Legacy(`1` 始まり、P2PKH)・P2SH(`3` 始まり、マルチシグ / ネスト SegWit)・SegWit v0(`bc1q`)・Taproot(`bc1p`)の 4 種に判別し、形式が互換でない点も明示
  • Bech32 と Bech32m の両方の定数を試し、どちらで通ったかを表示。チェックサムが壊れた見た目だけ正しいアドレスは不一致と判定します
  • イーサリアム:Keccak-256 による EIP-55 の大文字小文字チェックサム。全小文字・全大文字は「検証不能」と表示し、失敗とはしません
  • ⚠️ 1 つの入力が複数の体系に該当し得る(9 桁も 13 桁もそうです)ため、断定ではなく一覧を返します
  • 複数行に対応し、行ごとにまとめます

使い方

  1. 検証したい番号を 1 行に 1 つ貼り付けます
  2. 「結論」の行を確認します:一致 / 不一致 / 形式のみ / 検証不能
  3. 「根拠」で、どのアルゴリズムで判定したかが分かります

よくある質問

一致すればカード番号は実在しますか?
しません。 チェックディジットは入力ミスを防ぐもので、桁の抜け・入れ替わり・打ち間違いのおよそ 9 割は Luhn で見つかります。しかし捏造には無力です —— 偽のカード番号を作る人も Luhn は正しく計算します(割り算 1 回の話です)。つまり「一致」は「明らかな写し間違いがない」だけを意味し、カードの実在・名義・利用可否とは関係ありません。
イーサリアムで SHA3-256 ではなく Keccak-256 を使うのはなぜですか?
イーサリアムが SHA-3 の標準化より前に生まれたからです。両者はパディングの先頭バイト(オリジナルの Keccak は `0x01`、NIST の SHA-3 は `0x06`)だけが違い、出力はまったく異なります。EIP-55 のチェックサムを SHA3-256 で計算すると、正しいアドレスがすべて検証に失敗します —— しかもどちらも「ハッシュ」に見えるのでエラーは出ません。テストでは EIP-55 仕様の 3 つの例アドレスでこの点を固定しています。
全小文字のイーサリアムアドレスが「検証不能」なのはなぜですか?
EIP-55 のチェックサムは大文字小文字そのものに乗っているからです:Keccak-256 を計算し、ハッシュの対応する桁が 8 以上ならその文字を大文字にします。つまり全小文字・全大文字のアドレスはチェックサムの情報を一切持っていません —— そしてどちらの表記も EIP-55 以前は正当で、今もそう出力するツールが多くあります。「不一致」と報告するとアドレスが間違っていると誤解させますが、「検証不能」が実情です。
BIC が「形式のみ」なのはなぜですか?
BIC にはチェックディジットがないからです。4 文字の金融機関コード、2 文字の国コード、2 文字の地域コード、任意の 3 文字の支店コードから成り、いずれも表引きの英数字で自己検証用のビットがありません。そのため桁数と国コードが英字かどうかまでは確認できますが、そのコードが実在するかは確認できません。判定にその旨を明記し、「形式は正しい」が「検証済み」と受け取られないようにしています。
ビットコインの `1`・`3`・`bc1q`・`bc1p` は何が違い、混用できますか?
4 世代の異なるアドレス形式で、署名方式が違い互換性はありません。`1` 始まりは Legacy(P2PKH) で最古の形式、`3` 始まりは P2SH(スクリプトハッシュ。マルチシグやネスト SegWit で一般的)、`bc1q` は SegWit v0(P2WPKH / P2WSH)、`bc1p` は Taproot(SegWit v1) です。いずれもそれぞれのチェックサムで検証されます —— Base58 の 2 種はバージョンバイト(`0x00` / `0x05`)と二重 SHA-256 の 4 バイト、bech32 の 2 種は Bech32 / Bech32m のチェックサム(最後に XOR する定数だけが異なります)。⚠️ 混用できません:`1` や `3` 始まりのアドレスを bech32 しか受け付けない取引所に渡すと無効と判定され、逆も同じです。受け取る側が対応する世代の形式を使ってください。

関連ツール