ルーマニアCNPチェックディジット
180010122114を入力するとチェックディジットは4で、CNP全体は1800101221144になります。13桁を貼り付ければ、最後の数字が公式の重み付けに合うかも確かめられます。人事や給与、顧客登録の確認に便利で、ブラウザで無料で使えます。
- 無料
- ブラウザで動作
- 登録不要
- データは端末の外に出ません
無料で実行
計算例
- Cnp
- 180010122114
- 計算モード
- Compute
- 入力
- 180010122114
- チェックディジット
- 4
- チェックディジット付き
- 1800101221144
- 整形済み
- 1-800101-22-114-4
ルーマニアの個人数値コード（CNP、Cod Numeric Personal）は、戸籍記録、雇用契約、税務申告、銀行KYC、行政フォームなどで使われる13桁の識別子です。最終桁は、CNPレイアウトの公式モジュラ規則に従い、先頭12桁の固定重み付けから導かれるチェックディジットです。1桁の打ち間違いや入れ替えでもチェックサムが崩れることが多く、人事記録の保存、顧客プロファイルの開設、パートナーファイルの受付の前にCNPを検証すると、多くの入力ミスを早期に検出できます。本機能は、12桁の本体（一般的なスペースやハイフンの有無を問わず）からルーマニアCNPのチェックディジットを計算するか、末尾桁を含む13桁の完全な番号を検証し、桁を黙って捏造するのではなく不正入力を報告します。どちらの経路もネットワーク照会や実在者の名簿なしに、同じ決定的な算術を実行します。
ルーマニアCNPチェックディジットとは何か、重みの仕組み
CNPは性別と世紀、生年月日、発行郡、通し番号を、ルーマニアの行政・税務・商用システムで使われる固定13桁レイアウトに符号化します。フォームでは読みやすさのためスペースやハイフンが入ることがありますが、本質的な値は常に13個の十進桁です。先頭12桁が本体で、第13桁は公開のチェックアルゴリズムによって完全に決まり、自由には選べません。
公式の重み付けは、左から右へ、これらの12桁に定数列2、7、9、1、4、6、3、5、8、2、7、9（重み文字列279146358279）を掛けます。積を合計し、その和を11で割った余りが候補のチェックディジットです。余りが0から9のとき、その値がチェックディジットとなり、整形式のCNP文字列を完成させます。
余りが10のときはチェックディジットは10ではなく1と定義されるため、すべての12桁本体は0から9の末尾桁ちょうど1つに対応します。決済カードのLuhn mod-10と比べ、CNP方式は左から右の固定重みベクトルと、余り10の特別規則付きの法11を使うため、ルーマニア個人ID欄にLuhn検証器を流用してはいけません。
ポーランドNIPの重みやノルウェーのfødselsnummerの二重mod-11桁と比べても、ルーマニアCNP規則はこの13桁レイアウトと12位置の重み文字列に固有です。どの方式が必要かを知っておけば、汎用チェックディジットツールが整形式CNPでない桁列を受け付けても、誤った安心を避けられます。
本ツールは、任意のスペースとハイフンを除去したのち、純粋な桁に標準重み付けを適用します。政府ポータルへの照会、人物の存在証明、性別や郡の復号、法的地位の付与は行わず、公開されたチェックアルゴリズムの下で桁列が整合していることだけを確認します。
人事・銀行・行政ワークフローでのCNPチェックディジットの位置づけ
人事・給与システムは、法的なルーマニア雇用書類ごとに従業員CNPを保存します。オンボーディング時の1桁の打ち間違いは、その後の社会保障や税務提出を失敗させ得ます。ルーマニア個人数値コードを収集する銀行・フィンテックのKYCは、外部台帳を呼ばずにチェックディジットを再計算でき、OCRノイズや部分キャプチャを早期に落とせます。
保険・医療・公共サービスポータルは、フォームやパートナーファイルからCNPを受け取りますが、末尾桁が誤っていると一括が丸ごと拒否されることがあります。一般的なLuhnやISO 7064ツールを既に公開しているプロダクトチームでも、ルーマニア個人ID欄では重み・長さ・余り10の扱いが領域に合うよう、このCNP専用機能を使うべきです。「
ルーマニアCNPチェックディジット」や「romania cnp validator」などの語句で順位を狙う教育・SEOランディングには、自動化と一致する無料のライブツールが必要で、チュートリアルの画面キャプチャが正確に保たれます。どのワークフローでも契約は同じです。
チェックが通ったCNPを、人物が正しく特定されている・生存している・権限がある・公式台帳にいることの証明と見なさないでください。それは桁列がルーマニアCNPチェックアルゴリズムの下で整合していることだけを示します。
活用例
パートナー・給与ファイルのCNP列を監査する
CSV取込の各CNPを一括検証し、チェックディジットが再計算した期待値と一致しなくなった行を隔離します。
よくある質問
ルーマニアCNPのチェックディジットはどう計算しますか？
先頭12桁に重み2、7、9、1、4、6、3、5、8、2、7、9（定数文字列279146358279）を掛け、積を合計し、11で割った余りを取ります。余りが0–9ならそれがチェックディジット、10ならチェックディジットは1です。
computeとvalidateモードの違いは何ですか？
computeは12桁を受け取り、チェックディジットと完全な13桁CNPを返します。validateは末尾桁を含む13桁を受け取り、再計算したチェックディジットと一致するかを返します。
チェックディジットが間違っているとどうなりますか？
validateモードでは応答に期待桁が含まれ、validはfalseになります。
重み付き合計の余りが10になった場合はどうなりますか？
その場合、チェックディジットは10ではなく1になります。この特別な規則により、12桁の本体には必ず0から9のどれか1つの末尾の数字が決まります。
スペースやハイフンを入れたまま入力できますか？
はい。読みやすさのために入れたスペースやハイフンは取り除いてから計算します。ただし、英字やそのほかの記号、二重のハイフン、先頭や末尾のハイフンは入力の誤りとして扱われます。
関連ツール
開発者向け — APIアクセス
このページの機能はすべてAPIからも利用できます。自社システムに組み込みたいチーム向けのセクションです。それ以外の方は上のツールをそのままお使いください。
エンドポイント
Bearerトークンで認証し、POST1回でタスクをキューに登録します。結果はWebhookまたは署名付きリンクで受け取れます。
お使いのスタックから呼び出す
curl -X POST https://api.kit.forhosting.com/enc/cnp-romania \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"cnp":"180010122114"}'const res = await fetch("https://api.kit.forhosting.com/enc/cnp-romania", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"cnp": "180010122114"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/enc/cnp-romania",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"cnp": "180010122114"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/enc/cnp-romania", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"cnp":"180010122114"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"cnp":"180010122114"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/enc/cnp-romania", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)リクエスト例
{
"cnp": "180010122114"
}レスポンス例
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "enc.cnp_romania",
"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 | リクエストが多すぎます。しばらく待ってから再度お試しください。 |
技術的な注記
ブラウザでは無料で、公開価格でKIT APIを呼び出すこともできます。
チェックディジットの計算方法と完全なCNPの検証方法
スペースやハイフンで区切っても構いません。既定のモードはcomputeです。validateモードは、末尾のチェックディジットを含む完全な13桁（例：1800101221144、またはハイフン付き13桁）を期待します。空文字、欠落したcnp、無効なmode、誤った長さは、重み付き和の前に失敗し、課金されません。既知の12桁本体からCNPを組み立てるときはcomputeを、ユーザー・パートナーファイル・スキャンラベルが完全番号を渡し、台帳やマスタ照会の前に真偽ゲートが必要なときはvalidateを優先してください。0から9の桁を含むcnpフィールドを送ります。文字、その他の句読点、二重ハイフン、先頭または末尾のハイフンは不正入力としてinvalid_inputで拒否され、黙って正規化された値を受け付けることはありません。チェックディジットなしのちょうど12桁（例：180010122114）を渡すと、エンジンは1文字の文字列としてcheck_digit、その桁を含む完全な13桁文字列としてwith_check、読みやすいS-YYMMDD-JJ-NNN-Cグループとしてformattedを返します。再計算したチェックディジットが末尾と一致するとvalidはtrueになり、常にcheck_digit、expected_check_digit、末尾を除くpayload、weighted_sum_mod11、formattedが一貫した表示のために含まれます。経路はクロック・乱数源・ネットワークなしの純粋なparseのため、同じ入力は無料ブラウザツールとAPIで常に同じJSONになります。成功リクエストあたり$0.002で、人事の一括取込、オンボーディングフォーム、ETLジョブを、個別ティア交渉なしにゲートできます。
人事・銀行・行政ワークフローでのCNPチェックディジットの位置づけ
入口のvalidateモードはvalidがfalseのとき保存を止め、expected_check_digitを示して、記録が書かれる前に係員がフォームを直せるようにします。validとwith_checkを返す決定的オラクルがあれば、本番前に行をフラグできます。
連携の活用例
人事・オンボーディングフォームのCNP欄をゲートする
ユーザーが完全なルーマニアCNPを送信したらvalidateモードを呼び、validがfalseのときは保存を止め、expected_check_digitを示して従業員記録を書く前に1桁の打ち間違いを直せるようにします。
ID完成時に末尾桁を計算する
12桁の本体からcomputeモードを呼び、with_checkまたはformattedを保存して、印刷・エクスポート・提出生成の前に新しいCNP文字列が正しい末尾桁を持つようにします。
技術的な質問
スペースとハイフンは使えますか？
はい。一般的な区切りは解析前に除去されます。文字、その他の句読点、壊れたハイフンパターンはinvalid_inputで拒否されます。
ルーマニアCNPチェックディジット計算の料金は？
ブラウザツールは無料です。APIリクエストは成功呼び出しあたり$0.002の前払いKIT残高を使い、不正入力は課金されません。