اختبار: هل يمكنك الاعتماد على JavaScript؟

تتجاهل الدالة parseInt المسافات وتقوم بتحليل التسلسل الأولي من الأرقام كعدد صحيح. هنا، تتوقف عند النقطة العشرية، لذا يتم إرجاع 123456 فقط.

بشكل عام، يتوقف parseInt عن التحليل عندما يواجه حرفًا غير رقمي. هنا، يتوقف عند الفاصلة، لذلك يتم إرجاع 123 فقط.

بسبب أخطاء الدقة في النقاط العائمة، فإن 0.1 + 0.2 لا يساوي تمامًا 0.3. نظرًا للطريقة التي تُخزَّن بها الأعداد العشرية العائمة في الذاكرة، تكون النتيجة 0.30000000000000004. معيار IEEE 754 للتعامل مع الحسابات العشرية العائمة هو السبب، فهو لا يستطيع تمثيل بعض الأعداد بدقة. هذه مشكلة شائعة في جميع لغات البرمجة. في النهاية، ستصادف عددًا عشريًا لا نهائيًا، وبغض النظر عن اللغة، يجب على الكمبيوتر ببساطة التوقف عن مطاردة الأرقام اللانهائية.

بعض اللغات مثل Python وJava تحتوي على Decimal أو BigDecimal للتعامل مع هذا، لكنها غير مدمجة في JavaScript. يمكنك استخدام مكتبات مثل big.js أو decimal.js لمعالجة هذه الحالات.

(ملاحظة: بعض اللغات مصممة للتعامل مع الكسور والأعداد التخيلية وما إلى ذلك على مستوى منطقي أعلى، مع الحفاظ على التعبيرات الحرفية. لكنها لا تزال تواجه نفس مشكلات الدقة في النقاط العائمة على مستوى العتاد.)

بما أن Number.MAX_VALUE هو أكبر رقم قابل للتمثيل عادي في JavaScript، فإن تجاوز حده سيؤدي إلى فيضان سريع - بشكل أساسي قد ترى نتائج غير ذات معنى. ضربه في 2 ينتج Infinity.

أتعلم، JavaScript هكذا أحيانًا.

.toFixed(2) تُرجع تمثيلًا نصيًا للرقم 5 بمنزلتين عشريتين، لذا تكون النتيجة "5.00".

النقطة المزدوجة (5..toFixed(2)) هي ‘حيلة’ للوصول إلى نموذج الكائن الخاص بـ Number Literals.

في JavaScript، كل من parseInt و parseFloat سيفسران السلسلة "42" كالرقم 42. لذلك، فإن المقارنة parseInt(\"42\") === parseFloat(\"42\") تُقيّم إلى true. بينما يتوقف parseInt عن التحليل عند أول حرف غير رقمي، يستمر parseFloat في التحليل حتى يواجه حرفًا ليس جزءًا من رقم عشري. ومع ذلك، نظرًا لعدم وجود نقاط عشرية أو أحرف غير رقمية أخرى في "42"، فإن كلا الدالتين تُرجعان نفس القيمة.

BigInt هو نوع مختلف عن number، لذا فإن parseInt("42") (رقم عادي) لا يساوي تمامًا BigInt("42"). للمقارنة، يجب تحويل كليهما إلى نفس النوع: BigInt(parseInt("42")) === BigInt("42").

أي سلسلة إدخال تبدأ بـ 0x تُعامل تلقائيًا كعدد ست عشري (أساس 16). لذلك فهي مكافئة لتمرير أساس 16. لذا، parseInt("0x2A") هو نفسه parseInt("2a", 16). (لا يفرق بين الأحرف الكبيرة والصغيرة.)

يقوم parseInt بقاعدة سداسية عشرية (16) بتحويل "FF" إلى 255 في النظام العشري. ربما رأيت هذا في رموز الألوان CSS RGB/Hex.

الوسيط الثاني لـ parseInt (الراديكس) يتوافق مع وسيط index في دوال المصفوفات. يؤدي هذا إلى نتائج غير متوقعة، حيث أن parseInt(\"One\", 1) يُرجع NaN بسبب الإدخال غير الصحيح.

العنصر الأول، 24، يتم تحليله كـ 24 في الأساس 0 (اكتشاف تلقائي)، لذا يبقى 24. العنصر الثاني، 'One'، يتم تحليله كـ NaN في الأساس 1. العنصر الثالث، 42، يتم تحليله باستخدام الأساس 2. في الأساس 2، '42' هو NaN، لذا تكون النتيجة [24, NaN, NaN].

هذا خطأ شائع مع parseInt و map. إذا كنت تريد تحليل مصفوفة من السلاسل إلى أرقام، فإن الطريقة الآمنة الوحيدة “المضمنة” هي .map(Number) أو إضافة رد اتصال/إغلاق .map(x => parseInt(x, 10)).

Number يقوم بتحويل القيم إلى نوع رقمي بشكل أكثر صرامة من parseInt. هنا، 'Twenty1' يصبح NaN، بينما يتم التعرف على 0o42 كحرف ثماني وتحويله إلى 34.

parseInt يحول الإدخال إلى سلسلة نصية، لذا يصبح null هو "null". وبما أن "null" لا يحتوي على أرقام صالحة في الأساس 10 (الأرقام العادية)، فإنه سيعيد NaN.

Number(null) يعيد 0. لأن JS تحب أن تبقيك في حالة تأهب. لماذا؟ حسنًا، قد أتعمق أكثر إذا كان هناك اهتمام.

بما أن parseInt دائمًا يحول الإدخال إلى سلسلة نصية، فإن null يصبح السلسلة "null".

في الأساس 36 (سداسي عشري ثلاثي، إذا كنت تتابع)، السلسلة "null" تمثل 1112745.

القيم المتتالية لـ nulk و null و nulm هي على التوالي 1112744 و 1112745 و 1112746 في الأساس 36.