ISO 7064チェックディジット
MOD 11-2では、0794の検査文字は0で、完全な識別子は07940になります。数字や英数字のコードに検査文字を付けたり、完成したコードを検証して本来の文字を確認したりできます。ブラウザで無料で使えます。
- 無料
- ブラウザで動作
- 登録不要
- データは端末の外に出ません
無料で実行
計算例
- テキスト
- 0794
- 方式
- mod11-2
- 計算モード
- Compute
- 入力
- 0794
- チェック文字
- 0
- チェックディジット付き
- 07940
- 長さ
- 5
ISO/IEC 7064は、識別子を1文字の置換や多くの転置・シフト誤りから守る純粋な検査文字体系を定義します。MOD 11-2は純粋な数字列を対象とし、値10が必要なときに末尾のXを出力できます。MOD 37-2は大文字の英数字列を対象とし、値36が必要なときに末尾のアスタリスクを出力できます。両方式とも法と基数2を用い、左から右への1回の走査で、正しく形成された完全な文字列は剰余1で終わります。
ISO 7064のMOD 11-2とMOD 37-2が守るもの
検査文字が存在する理由は、人・スキャナ・キーボードが識別子を予測可能な形で損なうからです。ISO/IEC 7064は複数の純粋系とハイブリッド系を標準化し、業界が独自のチェックサムを発明する代わりに一つの数学的契約を共有できるようにします。ここで公開している1文字の純粋系はMOD 11-2とMOD 37-2です。
MOD 11-2は数字0から9を値0から9に写し、値10の補助検査文字Xを許します。ORCID識別子や、単純な法10の桁より強い保証が必要な多くの数値参照コードで使われます。MOD 37-2は数字と大文字AからZを値0から35に写し、値36の補助検査文字アスタリスクを許します。
両方式とも基数2を用います。エンジンは左から右へ進み、各文字値をpを2倍してから文字値を加えた結果を法11または法37で還元し、正しく形成された完全な文字列は常に剰余1で終わります。この代数的形は大きな検索表なしで、すべての単一置換と高い割合の隣接転置その他の局所誤りを検出します。
本ツールはこれら二つの純粋系のみを実装し、ハイブリッドのMOD 11,10やMOD 37,36の挙動は主張せず、応答にアルゴリズム名を付けて下流がどの方式で値を保護したかを記録できるようにします。
実システムにおけるISO 7064検査文字の置きどころ
ORCID形式の数値識別子を発行または受け付ける研究・学術プラットフォームは、プロフィールリンク保存前に末尾のMOD 11-2文字を再計算または検証し、フォーム境界で誤入力1桁を捉えられます。
英数字の資産・カートンコードを印刷する製造・物流チームはMOD 37-2を採用し、隣り合う2文字が入れ替わっても携帯スキャナやコールセンターが誤SKUへ黙って作業を回さないようにできます。複数文字の参照番号付き紙帳票をまだ扱う医療・教育・行政は、受付時に検証し、期待される検査文字を示して素早く修正でき、重複したカルテや案件の作成を避けられます。
統合テストとデータ品質ジョブはCSVエクスポートの各行について期待検査文字を再計算し、保存済みの完全文字列が一致しなくなった行を印付け、人手編集と生成器のオフバイワンの両方を捉えます。どの流れでも契約は同じです。ISO 7064検査の合格を認可や所有の証明と見なさないでください。
選んだ純粋系の下で文字列が正しく形成されていることだけを示すものであり、任意のチェックサムに適用するのと同じ誠実さの基準です。
活用例
エクスポートしたID列を監査する
取引先CSVや倉庫エクスポートの各識別子をMOD 11-2またはMOD 37-2で一括検証し、検査文字が再計算した期待値と一致しなくなった行を隔離します。
よくある質問
ISO 7064の検査文字とは何ですか?
ISO/IEC 7064で定義される末尾文字で、完全な識別子に対する純粋なモジュラー走査が剰余1で終わるようにし、単一置換と多くの転置誤りを検出します。
MOD 11-2とMOD 37-2はどう使い分けますか?
数字だけの識別子、たとえばORCID形式の番号にはMOD 11-2を使い、検査文字はXになることがあります。資産タグや製品コードのようにAからZの英字を含む場合はMOD 37-2を使い、検査文字はアスタリスクになることがあります。
検査文字がXやアスタリスクになるのはなぜですか?
通常の記号の範囲を1つ超える値が必要になることがあるためです。MOD 11-2では値十をX、数字と英字で零から三十五までを表すMOD 37-2では値三十六をアスタリスクで書きます。
ORCIDの確認にも使えますか?
はい、ORCIDの識別子はMOD 11-2を使っています。ハイフンや空白は先に取り除かれるので区切られた形のまま貼り付けられ、末尾の数字またはXが本来の検査文字と比べられます。
検査文字はどう計算しますか?
左から1文字ずつ、それまでの値を2倍して文字の値を足し、11または37で割った余りを取っていきます。検査文字は、完全な文字列の最後の余りが1になるように選ばれます。
関連ツール
開発者向け — APIアクセス
このページの機能はすべてAPIからも利用できます。自社システムに組み込みたいチーム向けのセクションです。それ以外の方は上のツールをそのままお使いください。
エンドポイント
Bearerトークンで認証し、POST1回でタスクをキューに登録します。結果はWebhookまたは署名付きリンクで受け取れます。
お使いのスタックから呼び出す
curl -X POST https://api.kit.forhosting.com/enc/iso7064 \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"text":"0794"}'const res = await fetch("https://api.kit.forhosting.com/enc/iso7064", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"text": "0794"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/enc/iso7064",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"text": "0794"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/enc/iso7064", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"text":"0794"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"text":"0794"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/enc/iso7064", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)リクエスト例
{
"text": "0794"
}レスポンス例
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "enc.iso7064",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}非同期APIです。task_idは即時に返ります。ポーリングは1秒あたり1リクエストまでです。
料金
単価はすべて公開しています。トークン換算や独自クレジットはありません。失敗したタスクは課金されません。
エラー
| HTTP | コード | 意味 |
|---|---|---|
401 | unauthorized | APIキーが無効か、指定されていません。Authorizationヘッダーを確認してください。 |
402 | insufficient_balance | 残高が不足しています。チャージ後に再度お試しください。 |
404 | unknown_type | 指定されたタスクタイプは存在しません。タイプ名を確認してください。 |
429 | rate_limited | リクエストが多すぎます。しばらく待ってから再度お試しください。 |
技術的な注記
本機能は、すでにお持ちのペイロードに対してその末尾文字を計算するか、すでに検査文字を含む完全な識別子を検証し、選んだアルファベット外の文字を黙って捨てず、明確なinvalid_inputエラーで拒否します。
ISO 7064のMOD 11-2とMOD 37-2が守るもの
誤った1記号、隣り合う2記号の入れ替え、桁の挿入・脱落、固定フィールドの短い巡回シフトなどです。文字がペイロードに含まれる商品コード、資産タグ、混在英数字系列に適します。
検査文字の計算と完全な識別子の検証の手順
ハイフンと空白は除去され、英字は大文字化されるため、ORCID形式の区切りや空白付きラベルも解析できます。残る各文字は選んだ体系のアルファベットに属している必要があります。数値用途ではsystemの既定はmod11-2です。modeの既定はcomputeです。空文字、欠落したtext、アルファベット外の文字、無効なmodeやsystemは、モジュラー走査が終わる前に失敗し、課金されません。新規IDを発行するときはcomputeを、ユーザー・取引先ファイル・スキャン済みラベルからIDを受け取り参照前に真偽ゲートが必要なときはvalidateを選んでください。識別子を入れたtextフィールドを送ってください。英数字のペイロードではsystemをmod37-2にしてください。エンジンはペイロードを走査し、1文字のcheck_characterと、ペイロードにその文字を付けたwith_checkを返し、1本の文字列として保存・印刷できます。mode validateは、ペイロードと末尾検査を含む少なくとも2文字の完全な文字列を期待します。完全走査が剰余1で終わるとvalidが真になり、観測されたcheck_character、ペイロードだけから再計算したexpected_check_character、末尾を除いたpayload部分文字列が常に含まれます。この形により、フォームで「入力はX、期待はY」を第二呼び出しなしで示せます。時計・乱数・ネットワークのない純粋なparse経路のため、同じ入力は無料ブラウザツールとAPIで常に同じJSONになります。成功リクエストあたり$0.002で、特別な階層交渉なしに一括取込み、登録フォーム、ラベル印刷を守れます。
実システムにおけるISO 7064検査文字の置きどころ
純粋な数字フィールドに既にLuhnやDammを使う製品チームでも、取引先契約が規格引用の方式を求める場合や、英数字ペイロードに1文字の末尾検査が必要な場合はISO 7064を導入できます。
連携の活用例
MOD 11-2で数値IDを発行する
連番または乱数の数字ペイロードを生成し、system mod11-2でcomputeを呼び、印刷やメール前に規格準拠の末尾検査文字を持つようwith_checkを保存します。
入力時に手入力・スキャンコードを検証する
ユーザーまたはスキャナが完全な識別子を送ったら、対応するsystemでvalidateを呼び、validが偽のときは検索を止め、expected_check_characterを示して1文字の打ち間違いを直せるようにします。
技術的な質問
MOD 11-2とMOD 37-2はいつ使い分けますか?
純粋な数字ペイロードにはmod11-2を使います(検査は0-9またはX)。大文字の英数字ペイロードにはmod37-2を使います(検査は0-9、A-Z、または*)。
このAPIで検査文字を計算するには?
textにペイロード、systemにmod11-2またはmod37-2、modeにcompute(またはmode省略)でPOSTします。応答にcheck_characterとwith_checkが含まれます。
すでに検査文字付きの識別子を検証するには?
完全な文字列、対応するsystem、mode validateでPOSTします。応答にvalid、check_character、expected_check_character、末尾を除いたpayloadが含まれます。
ISO 7064チェックディジットツールは無料ですか?
ブラウザツールは無料でローカル実行されます。API呼び出しは公開の基本料金$0.002でKIT前払い残高を使い、無効入力は課金されません。