رقم تحقق IMEI
تأخذ الأرقام الأربعة عشر 49015420323751 رقم التحقق 8، فيصبح رقم IMEI الكامل 490154203237518. أكمل رقم جهاز لملصق أو قاعدة بيانات، أو افحص رقم IMEI من 15 رقمًا وصلك من عميل قبل حفظه. مجاني في متصفحك.
- مجاني
- يعمل في متصفحك
- دون تسجيل
- بياناتك لا تغادر جهازك
شغّل الأداة مجانًا
مثال محلول
- العدد
- 49015420323751
- وضع الحساب
- Compute
- المُدخَل
- 49015420323751
- رقم التحقق
- 8
- مع رقم التحقق
- 490154203237518
يحمل كل هاتف محمول وكثير من وحدات الاتصال الخلوي هوية معدات دولية متنقلة من خمسة عشر رقماً. تحدد الأرقام الأربعة عشر الأولى رمز تخصيص النوع والرقم التسلسلي؛ والخامس عشر هو رقم تحقق Luhn يلتقط أخطاء الكتابة برقم واحد ومعظم التبديلات المتجاورة قبل أن يُخزَّن الرقم أو يُطبع على العلبة أو يُرسل إلى بوابة المشغّل.
كيف يُحسب رقم تحقق Luhn لـ IMEI
يكون IMEI دائماً خمسة عشر رقماً عشرياً وفق خطة ترقيم 3GPP المستخدمة لمعدات GSM وUMTS وLTE و5G. تشكّل الأرقام الثمانية الأولى رمز تخصيص النوع (TAC)، والستة التالية مسلسلاً للمصنّع ضمن ذلك TAC، والخامس عشر هو رقم التحقق. عندما يكون ضعف الرقم أكبر من تسعة اطرحوا تسعة (أو اجمعوا آحاد وعشرات الناتج).
اجمعوا القيم المرجّحة الأربع عشرة؛ ورقم التحقق هو (10 ناقص تلك المجموع modulo 10) modulo 10 بحيث يكون لرقم الخمسة عشر الكامل مجموع Luhn قابلاً للقسمة على عشرة. تعيد عملية التحقق حساب الرقم المتوقع من الأحرف الأربعة عشر الأولى وتقارنه بالخامس عشر، وهو نفس مجموع Luhn كامل على الخمسة عشر رقماً. الخوارزمية حتمية ومحلية: بلا استدعاء لسجل TAC وبلا ساعة وبلا عشوائية.
لا تفك هذه الأداة TAC إلى أسماء علامات، ولا تعالج صيغ MEID الست عشرية، ولا تثبت ملكية ولا حالة قائمة سوداء؛ إنما تثبت أن سلسلة الأرقام سليمة الشكل وفق قاعدة Luhn لـ IMEI. مقارنةً بمدققي Luhn العامة للبطاقات، نية البحث هنا ضيقة: من يحتاج حاسبة رقم تحقق IMEI لحمولات من أربعة عشر رقماً أو فاحص IMEI متنقل من خمسة عشر، لا أداة بطاقة دفع.
عقد الإدخال والأوضاع وسلوك الخطأ
أرسلوا حقل number يحتوي فقط الأحرف من صفر إلى تسعة. الطول الخاطئ خطأ صريح يسمّي الوضع والطول المُرسل —أربعة عشر لـ compute وخمسة عشر لـ validate— حتى تعرض نماذج العملاء «يلزم أربعة عشر رقماً» دون تخمين. تفشل السلاسل الفارغة وnumber المفقود وقيم mode غير الصالحة قبل أي مجموع Luhn ولا تُحاسب.
فضّلوا compute عند إنشاء أرقام أجهزة أو إكمالها للتسميات وقواعد البيانات؛ وفضّلوا validate عندما تربطون استعلاماً أو تبديلاً أو استيراداً بـ IMEI كامل من مستخدم أو ملف شريك أو ماسح. مهام التحقق التي ترفض شكلاً سيئاً لا تُحاسب؛ وسلسلة سليمة من خمسة عشر رقماً ذات رقم تحقق خاطئ فقط تعيد valid false دون رمي استثناء.
حالات الاستخدام
تدقيق أعمدة IMEI في مخزون الأجهزة
تحققوا دفعياً من كل IMEI من خمسة عشر رقماً في CSV لـ MDM أو ERP أو RMA واعزلوا الصفوف التي لم يعد رقم تحققها يطابق القيمة المتوقعة المعاد حسابها.
الأسئلة الشائعة
ما رقم تحقق IMEI؟
هو الرقم الخامس عشر من IMEI، يُحسب بخوارزمية Luhn على الأرقام الأربعة عشر الأولى حتى تُلتقط غالباً أخطاء الكتابة أو المسح برقم واحد قبل التخزين أو الطباعة.
ماذا تعني أرقام IMEI؟
الأرقام الثمانية الأولى هي رمز تخصيص النوع (TAC)، والستة التالية هي الرقم التسلسلي للمصنّع داخل هذا الرمز، والرقم الخامس عشر هو رقم التحقق المحسوب من الأرقام الأربعة عشر الأخرى.
كيف يُحسب رقم التحقق في IMEI؟
ابدأ من آخر الأرقام الأربعة عشر وضاعف كل رقم ثانٍ، بدءًا بالرقم الأخير نفسه، واطرح 9 من أي ناتج أكبر من 9. ثم اجمع الكل، فيكون رقم التحقق 10 ناقص باقي قسمة المجموع على 10، ويصبح 10 صفرًا.
هل يعني رقم IMEI الصحيح أن الهاتف مسجل أو غير مقفل؟
لا. يدل رقم التحقق الصحيح فقط على أن الأرقام الخمسة عشر كُتبت بشكل متسق. لا تُراجع أي قاعدة بيانات للمصنّعين، لذا لا يخبرك بشيء عن تسجيل الجهاز أو فك قفله.
ما الأخطاء التي يكشفها رقم التحقق؟
يكشف كل خطأ كتابة في رقم واحد ومعظم حالات تبديل رقمين متجاورين. وبذلك تُكتشف أخطاء كثيرة قبل حفظ الرقم أو طباعته على العلبة أو إرساله إلى بوابة شركة الاتصالات.
أدوات ذات صلة
للمطوّرين — الوصول عبر API
كل ما في هذه الصفحة متاح برمجيًا. هذا القسم موجّه للفرق التقنية التي تريد ربط الأداة بأنظمتها الخاصة؛ بقية المستخدمين يمكنهم استخدام الأداة أعلاه مباشرة دون الحاجة لقراءة ما يلي.
الـEndpoint
صادِق على طلبك بترويسة Bearer، وأرسل طلب POST واحدًا لتدخل مهمتك قائمة التنفيذ فورًا؛ ثم تستلم النتيجة عبر webhook أو رابط موقّع.
استدعِ الخدمة من بيئتك
curl -X POST https://api.kit.forhosting.com/enc/imei \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"number":"49015420323751"}'const res = await fetch("https://api.kit.forhosting.com/enc/imei", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"number": "49015420323751"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/enc/imei",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"number": "49015420323751"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/enc/imei", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"number":"49015420323751"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"number":"49015420323751"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/enc/imei", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)مثال على الطلب
{
"number": "49015420323751"
}مثال على الاستجابة
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "enc.imei",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}الواجهة غير متزامنة: تستلم task_id فور الإرسال، ويمكنك الاستعلام عن الحالة بمعدل طلب واحد في الثانية.
الأسعار
السعر معلن كما تراه: لا tokens ولا نظام نقاط؛ وإن فشلت المهمة فلن تُحاسَب عليها.
الأخطاء
| HTTP | الرمز | المعنى |
|---|---|---|
401 | unauthorized | مفتاح الوصول مفقود أو غير صالح؛ تحقق من ترويسة Bearer في طلبك. |
402 | insufficient_balance | رصيدك لا يكفي لتنفيذ هذه المهمة؛ أعد شحن الرصيد ثم أعد المحاولة. |
404 | unknown_type | نوع المهمة المطلوب غير موجود في الكتالوج — راجع الاسم المرسل في الطلب. |
429 | rate_limited | تجاوزت الحد المسموح من الطلبات؛ انتظر قليلًا ثم أعد المحاولة. |
ملاحظات تقنية
تنفّذ هذه القدرة قاعدة Luhn القياسية لـ IMEI فقط: يقبل وضع compute أربعة عشر رقماً بالضبط من الحمولة ويعيد رقم التحقق مع السلسلة الكاملة من خمسة عشر؛ ويقبل وضع validate IMEI كاملاً من خمسة عشر رقماً ويُبلغ ما إذا كان الرقم الأخير يطابق القيمة المتوقعة المعاد حسابها. تفشل المدخلات غير الرقمية والأطوال الخاطئة بـ invalid_input بدل التهذيب الصامت، حتى لا تُثبّتوا معرّفاً نصف منظّف. تعمل الحسابات النقية نفسها مجاناً في المتصفح وبسعر API المنشور، بلا استعلام شبكي لقواعد بيانات المصنّعين وبلا ادعاء أن مجموع تحقق صالح يعني أن الجهاز مسجّل أو مفتوح القفل.
كيف يُحسب رقم تحقق Luhn لـ IMEI
لحسابه خذوا حمولة الأربعة عشر رقماً وطبّقوا خوارزمية Luhn من اليمين: ضاعفوا كل رقم ثانٍ بدءاً بأقصى رقم يمين في الحمولة (لأن ذلك الرقم يقع في الموضع الثاني من السلسلة الكاملة ذات الخمسة عشر عندما يكون رقم التحقق في الموضع الأول من اليمين). لذلك يتفق ودجت المتصفح المجاني ومسار API دائماً على الرقم نفسه لنفس المدخل، وهذا يهم عند اختباركم الذهبي لماسحات المستودع ونماذج RMA ومسارات تسجيل الأجهزة.
عقد الإدخال والأوضاع وسلوك الخطأ
تُرفض المسافات والشرطات والحروف والنقاط العشرية كمدخل غير رقمي بـ invalid_input حتى لا يصل قيمة مقصوصة بصمت إلى التخزين. وضع compute هو الافتراضي: يطلب المحرك أربعة عشر رقماً بالضبط، ويعيد check_digit كسلسلة من حرف واحد، وwith_check كـ IMEI من خمسة عشر رقماً يمكنكم طباعته أو تثبيته. يطلب وضع validate خمسة عشر رقماً بالضبط؛ وتُبلغ الاستجابة valid true عندما يطابق الرقم الأخير expected_check_digit المعاد حسابه، وتشمل دائماً payload (الأرقام الأربعة عشر الأولى) وcheck_digit وexpected_check_digit وlength خمسة عشر. تُقبل أسماء بديلة مثل digits وimei وcode لنفس حقل الحمولة حتى لا تحتاج التكاملات التي تتحدث أصلاً بـ «imei» إلى إعادة تسمية. لأن المسار parse خالص بلا ساعة ولا مصدر عشوائي ولا شبكة، ينتج نفس جسم JSON دائماً نفس نتيجة JSON على أداة المتصفح المجانية وعلى API بسعر $0.002 لكل طلب ناجح.
أين يندرج رقم تحقق IMEI في سير العمل الحقيقي
يتلقى مصنّعو الأجهزة وODM مسلسلات داخلية من أربعة عشر رقماً ويجب أن يلحقوا رقم تحقق Luhn الرسمي قبل طباعة IMEI على العلبة أو درج SIM أو الملصق التنظيمي. تتحقق بوابات المشغّلين وMVNO من IMEI ذي الخمسة عشر رقماً عند التفعيل حتى لا ينشئ تبديل واحد جهازاً وهمياً ومهمة تزويد فاشلة. تسير أنظمة إدارة الأصول وMDM على كل عمود IMEI في تصدير CSV، وتستدعي وضع validate، وتعزل الصفوف حيث valid يساوي false — ممسكة بتعديلات بشرية وأخطاء مولّدات off-by-one. تعيد ورش الإصلاح ومكاتب RMA حساب expected_check_digit عندما يقرأ العميل الرقم هاتفياً، فتلتقط أخطاء الكتابة قبل فتح تذكرة ضد الجهاز الخطأ. تثبّت اختبارات التكامل with_check لتجهيزات معروفة مثل 490154203237518 حتى لا تنحرف مكتبات الرموز الشريطية وطابعات الملصقات وهذه API. في كل سير عمل العقد واحد: أرقام فقط، طول ثابت لكل وضع، JSON منظم يمكن اختباره ذهبياً، سلوك متطابق في المتصفح المجاني وAPI المدفوع مسبقاً، وinvalid_input صادق عندما لا تكون السلسلة تتابعاً رقمياً خالصاً بالطول الصحيح. لا تعاملوا اجتياز فحص IMEI كدليل على أصالة الجهاز أو فتح قفله أو خلوه من قائمة سوداء للمشغّل؛ إنما يثبت أن رقم Luhn متسق مع الحمولة تحت الأوزان القياسية لهوية المعدات المتنقلة.
حالات التكامل
إكمال رقم جهاز من 14 رقماً للملصقات
استدعوا وضع compute بحمولة الأربعة عشر رقماً، واحفظوا with_check، واطبعوا IMEI من خمسة عشر رقماً على التغليف أو أدراج SIM أو الملصقات التنظيمية.
التحقق من IMEI مكتوب أو ممسوح عند الإدخال
عندما يرسل نموذج أو ماسح أو ملف شريك خمسة عشر رقماً، استدعوا وضع validate وامنعوا الاستعلام إن كان valid يساوي false، مع عرض expected_check_digit لتصحيح خطأ رقم واحد.
أسئلة تقنية
كيف أحسب رقم تحقق IMEI بهذه API؟
أرسلوا POST مع number يساوي أربعة عشر رقماً بالضبط وmode compute (أو احذفوا mode). تشمل الاستجابة check_digit وwith_check (IMEI الكامل من خمسة عشر رقماً).
كيف أتحقق من IMEI كامل من خمسة عشر رقماً؟
أرسلوا POST مع سلسلة الخمسة عشر رقماً وmode validate. تشمل الاستجابة valid وcheck_digit وexpected_check_digit وpayload (الأرقام دون الأخير).
ماذا يحدث مع طول خاطئ أو حروف أو شرطات؟
تُرفض المدخلات غير الرقمية والأطوال غير الأربعة عشر (compute) أو الخمسة عشر (validate) بـ invalid_input. لا تُحاسب مهام التحقق الفاشلة.
هل أداة رقم تحقق IMEI مجانية؟
أداة المتصفح مجانية وتعمل محلياً. تستخدم استدعاءات API رصيد KIT المدفوع مسبقاً بالسعر الأساسي المنشور $0.002؛ والمدخل غير الصالح لا يُحاسب أبداً.