حجة UTF-8: إنها بسيطة للغاية. التشفير و حدة فك الترميز في جافا سكريبت. مرة أخرى ، UTF-8 ليس Unicode .

حجة ضد UTF-8: إنها أكثر تعقيدًا قليلاً من الطول + البايت ، مما يؤدي إلى اختلافات محتملة في التنفيذ.

مرة أخرى ، UTF-8 ليس Unicode.

ماذا تقول حتى؟ هذه جملة هراء.

أعتقد أنك تحاول أن تقول أنه لا داعي للاندماج في مكتبة تدويل. هذا صحيح - إلزام السلاسل بترميز UTF-8 لا علاقة له بجميع الأجزاء الأكثر تعقيدًا في Unicode ، مثل تحديد العنوان المتعارف عليه. هذه أدوات مفيدة عندما تقوم بعمل سلسلة تتفاعل مع البشر ، ولكن بنفس الطريقة التي تكون بها مكتبة حساب المثلثات مفيدة للأشخاص الذين يقومون بالرياضيات ، وليست ذات صلة عند تحديد كيفية تشفير الأعداد الصحيحة.

لكن UTF-8 هو حرفياً ترميز Unicode ؛ بيانك لا معنى له كما هو مكتوب. ^ _ ^

لكن UTF-8 هو حرفياً ترميز Unicode ؛ بيانك لا معنى له كما هو مكتوب. ^ _ ^

نعم ، أنا أشير تحديدًا إلى ترميز نقطة التشفير الذي يصفه UTF-8 ، وليس معالجة نقاط التشفير المناسبة (لغرض هذا الاقتراح ، تعد نقطة التشفير عددًا صحيحًا معتمًا). عند وضع wasm-isms ، يكون UTF-8 مشابهًا لـ var [u] int ، ولكنه أكثر ملاءمة للأحرف. علاوة على ذلك ، لا يعتبر UTF-8 هو ترميز Unicode الوحيد ، ويمكن استخدامه لتشفير الأعداد الصحيحة غير Unicode. إذن ، UTF-8 ليس Unicode.

سوف ينظر اقتراح آخر في نقاط الرموز الفردية ويفعل شيئًا معهم. هذا ليس هذا الاقتراح.

ولن يكون هناك سبب لذلك. لم تجد أي واجهة برمجة تطبيقات للويب الحاجة إلى الاستبطان في نقاط التشفير بما يتجاوز المقارنة الصارمة بين المساواة والفرز ، إلا إذا كانت واجهة برمجة تطبيقات i18n حرفيًا.

خيار آخر هو طول البايت + UTF-8 لكل نقطة رمز ( jfbastien ما لم يكن هذا ما قصدته عندما قلت UTF-8 لكل بايت ، وهو ما أعترف أنه لم يكن منطقيًا بالنسبة لي). لا أعتقد أن هذا سيجعل الأمور أكثر صعوبة بالنسبة للمحلل اللغوي البدائي الذي لا يهتم حقًا ، مع السماح لمكتبة Unicode المتطورة بأخذ مصفوفة بايت وإزاحة وطول كمدخلات وإرجاع سلسلة.

أوافق على التعريف على أنه "نقاط رمز UTF-8" ، وهي مجرد أعداد صحيحة. يجب أن تترك المواصفات الثنائية عند هذا الحد. يمكن أن تحدد أدوات التضمين الفردية قواعد حول نقاط الرمز المسموح بها والتطبيع والفروق الدقيقة الأخرى. يمكن أن توفر أدوات التحليل تحذيرات لمشاكل التوافق المحتملة.

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

إليك محاولة لتلخيص القضايا الأساسية وأسبابها. التصحيحات والإضافات موضع ترحيب كبير.

هل يجب أن تكون wasm تتطلب معرفات استيراد / تصدير الوحدة النمطية صالحة UTF-8؟

ما أفهمه من الأسباب هو:

• تعد معالجة الواردات والصادرات على المسار الحرج لبدء تشغيل التطبيق ، وهناك رغبة في تجنب أي شيء قد يؤدي إلى إبطائه.
• الثابت الواسع "إن المواصفات الأساسية لا تفسر السلاسل". تفسير الأوتار معقد بشكل عام ، وهناك رغبة في تغليفه وله ثوابت وحدود واسعة يمكن للمرء التفكير فيها على مستوى عالٍ.
• غالبًا ما تكون وحدات فك ترميز WebAssembly حساسة للأمان ، لذلك هناك رغبة عامة في تقليل مقدار الكود المتضمن.
• قد يرغب بعض منتجي WebAssembly في تضمين بيانات عشوائية في هذه المعرفات ، ومن الملائم لهم ترميز البيانات كما يريدون بدلاً من تشويشها في شكل سلسلة.

هل يجب أن توصي منظمة UTF-8 في المناطق التي لا تتطلب ذلك؟

والسبب في ذلك هو أنه حتى لو لم نتمكن من طلب ذلك ، فإن ذكر UTF-8 قد يثبط حالات عدم التوافق التي لا داعي لها بين النظام البيئي.

ما أفهمه من السبب هو أنه حتى ذكر UTF-8 من شأنه أن يضر بالتغليف المفاهيمي لمخاوف تفسير السلسلة.

هل يجب على wasm تحديد UTF-8 لأسماء أقسام الاسم؟

والسبب هو: أن الغرض الكامل من هذه الأسماء هو تحويلها إلى سلاسل لعرضها ، وهو أمر غير ممكن بدون ترميز ، لذلك يجب علينا تحديد UTF-8 حتى لا تضطر الأدوات إلى التخمين.

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

توفر sunfishcode ملخصًا جيدًا ، لكني أريد إضافة ثلاث نقاط مهمة.

jfbastien ، سيكون من غير المجدي من بين جميع البدائل تقييد binary _syntax_ (ترميز) ولكن ليس _semantics_ (مجموعة أحرف) للسلاسل. لذلك لجميع الأغراض العملية ، UTF-8 يعني Unicode. ومرة أخرى ، لا يتعلق الأمر بالمحركات فقط. إذا قمت بتعريف الأسماء على أنها Unicode ، فأنت تفرض ذلك على جميع أنظمة Wasm البيئية في جميع البيئات. وهذا يعني إلى حد كبير أن جميع البيئات مطلوبة للحصول على بعض دعم Unicode.

tabatkins ، أعتقد أن هناك خطأ في المجال الكامن وراء حجتك. لا توجد أي من السلاسل التي نتحدث عنها _واجهه المستخدم_. إنها أسماء تواجه التنمية. العديد / معظم لغات البرمجة لا تدعم معرّفات Unicode ، ولا الأدوات. هل يمكن أن يتعامل gdb على سبيل المثال مع معرفات مصدر Unicode؟ لا أعتقد ذلك. لذلك من التفاؤل (أو بالأحرى غير الواقعي) افتراض أن جميع المستهلكين قد تقاربوا على Unicode _ في هذه المساحة_.

وأخيرًا ، الخلاف ليس _ما إذا كان _ يجب أن تفترض Wasm على الويب UTF-8 ، ولكن _حيث _ نحدد ذلك.

أعتقد أن هناك خطأ في المجال الكامن وراء حجتك. لا تكون أي من السلاسل التي نتحدث عنها مواجهة للمستخدم. هم أسماء مطورين. العديد / معظم لغات البرمجة لا تدعم معرّفات Unicode ، ولا الأدوات. هل يمكن أن يتعامل gdb على سبيل المثال مع معرفات مصدر Unicode؟ لا أعتقد ذلك. لذلك من التفاؤل (أو بالأحرى غير الواقعي) افتراض أن جميع المستهلكين قد تقاربوا على Unicode في هذا الفضاء.

تعني كلمة "dev-Facing" "مواجهة سلسلة الأدوات التعسفية" ، مما يعني أنك بحاجة إلى الموافقة على الترميز مقدمًا ، وإلا ستضطر الأدوات إلى إجراء "اكتشاف" تشفير (أي التخمين ، وهو أمر سيء بشكل خاص عند تنطبق على القيم القصيرة) أو معلومات خارج النطاق. المطورين ما زالوا مستخدمين. ^ _ ^

إذا كنت تعتقد أن الكثير من سلاسل الأدوات لن تفهم Unicode ، فأنا لست متأكدًا من سبب اعتقادك أنهم سيفهمون أي ترميز ثنائي عشوائي آخر. إذا كان هذا هو الحد الخاص بك ، فما عليك سوى تحديد وطلب ASCII ، وهو مدعوم بنسبة 100٪ في كل مكان. إذا كنت لا ترغب في تقييد نفسك بـ ASCII ، فأنت بحاجة إلى قبول أن هناك مخطط تشفير واحد غير ASCII مقبول - UTF-8.

إن قول "إيه ، معظم الأشياء تدعم ASCII فقط ، لكننا سنترك المطورين يضعون كل ما يريدون هناك فقط في حالة " هو أسوأ ما في العالمين.

إن قول "إيه ، معظم الأشياء تدعم ASCII فقط ، لكننا سنترك المطورين يضعون كل ما يريدون هناك فقط في حالة" هو أسوأ ما في العالمين.

tabatkins ، لا أحد يقترح ما ورد أعلاه. كما قلت ، ليس السؤال _ما إذا كان _ ولكن _ أين _ لتحديد مثل هذه الأمور الخاصة بالمنصة / البيئة. من المفترض أن يكون Wasm قابلاً للتضمين في أوسع نطاق من البيئات غير المتجانسة ، وبعضها أكثر ثراءً من غيرها (على سبيل المثال ، JS _ يفعل _ يدعم معرّفات Unicode). وبالتالي ، فأنت تريد السماح بالاختيار على أساس كل منصة. ومن ثم فهو ينتمي إلى مواصفات واجهة برمجة تطبيقات النظام الأساسي وليس المواصفات الأساسية.

ليس هناك خيار للقيام به ، مع ذلك! إذا كانت بيئة التضمين الخاصة بك لا تدعم ASCII ، فأنت فقط لا تستخدم غير ASCII في سلاسلك . (إذا كانت هذه هي الحالة ، فلا تزال بحاجة إلى ضمان التشفير - على سبيل المثال ، UTF-16 ليس متوافقًا مع ASCII!)

إذا كانت بيئتك تدعم غير ASCII ، فأنت بحاجة إلى معرفة الترميز الذي يجب استخدامه ، والاختيار الصحيح في جميع المواقف هو UTF-8.

ما هي البيئة التي تتخيلها حيث من المفيد ألا تعرف ترميز خيوطك؟

سيكون من غير المجدي من بين جميع البدائل تقييد بناء الجملة الثنائي (الترميز) ولكن ليس الدلالات (مجموعة الأحرف) للسلاسل. لذلك لجميع الأغراض العملية ، UTF-8 يعني Unicode.

لا ، بالتأكيد لا. على سبيل المثال ، من المعقول تمامًا (أ) تقييد سلسلة لأحرف ASCII في وقت واحد ، و (ب) إملاء أنها مشفرة في UTF-8. لا يعني استخدام أحرف ASCII وجود تشفير ، وإلا فستكون جميع الترميزات متوافقة مع ASCII! (على سبيل المثال ، UTF-16 ليس كذلك). لذلك لا يزال يتعين عليك تحديد شيء ما ؛ UTF-8 ، كونه "متوافقًا مع ASCII" ، جيد لهذا.

مرة أخرى ، إذا كنت موافقًا على قصر هذه الأسماء على ASCII فقط ، فمن المنطقي أن يكون الترميز US-ASCII. إذا كنت تريد أن يكون من الممكن تجاوز ASCII ، فمن المعقول أن يكون الترميز هو UTF-8. إن فرض أي شيء آخر ، أو عدم فرض أي شيء على الإطلاق (وإجبار جميع المستهلكين على تخمين أو استخدام معلومات خارج النطاق الترددي) ، هي الاحتمالات الوحيدة غير المعقولة.

ومرة أخرى ، لا يتعلق الأمر بالمحركات فقط. إذا قمت بتعريف الأسماء على أنها Unicode ، فأنت تفرض ذلك على جميع أنظمة Wasm البيئية في جميع البيئات. وهذا يعني إلى حد كبير أن جميع البيئات مطلوبة للحصول على بعض دعم Unicode.

مرة أخرى ، يبدو أنك تتحدث عن مكتبات التدويل. ما نناقشه هو فقط كيفية فك تشفير متواليات البايت إلى سلاسل ؛ يتطلب فقط معرفة كيفية فك تشفير UTF-8 ، وهو أمر تافه للغاية وسريع للغاية.

ما لم تكن تقوم بمعالجة سلسلة بطريقة صديقة للإنسان ، فكل ما تحتاجه هو القدرة على مقارنة السلاسل بنقطة الرمز ، وربما فرز السلاسل حسب نقطة الرمز ، ولا يتطلب أي منهما أي "دعم Unicode". هذا هو كل ما تستخدمه تقنية الويب الحالية ، على سبيل المثال ، ولا أرى أي سبب لأن بيئات Wasm تحتاج ، بشكل عام ، إلى القيام بأي شيء أكثر تعقيدًا من هذا.

أنا أؤيد تفويض utf8 في لعبة All The Strings. يبدو أن فك تشفير / تشفير utf8 النقي يمثل عبئًا ضمنيًا منخفضًا جدًا (مقارنة بكل شيء آخر) للبيئات غير المرتبطة بالويب. أيضًا ، مما رأيته ، فإن الوقت المستغرق في التحقق من صحة utf8 للواردات / الأسماء سيكون ضئيلًا مقارنة بالوقت الذي يتم قضاؤه على كل شيء آخر ، لذلك لا أعتقد أن هناك حجة أداء هنا.

من الناحية العملية ، حتى لو لم نطلب استخدام utf8 في مواصفات wasm الأساسية ، فستواجه وقتًا سيئًا في التعامل مع أي شيء إذا لم تستخدم سلسلة أدواتك المخصصة أيضًا utf8 ما لم تكن جزيرة كاملة ومن ثم ربما تقول فقط "المسمار" وتفعل الشيء الخاص بك non-utf8 على أي حال ... لأنه بعد ذلك الذي يهتم.

ما أود فعله حقًا هو الحل رقم 984 ، والذي يبدو أنه يحظر هذا ...

lukewagner لا أعتقد أن # 984 محظور على هذا. 😄

أظن أنك محق.

ما هي البيئة التي تتخيلها حيث من المفيد ألا تعرف ترميز خيوطك؟

tabatkins ، يبدو أنني ما زلت غير واضح بما فيه الكفاية. لا أتخيل مثل هذه البيئة. ومع ذلك ، أتخيل مجموعة واسعة من البيئات ذات المتطلبات غير المتوافقة. ليس كل شيء هو مجموعة فرعية من UTF-8 ، على سبيل المثال لاتينية 1 لا تزال شائعة الاستخدام إلى حد ما. قد لا تهتم ، لكن ليست مهمة مواصفات Wasm الأساسية هي وضع أحجار لا داعي لها في طريق التنوع البيئي.

سيكون لديك وقت سيئ في التعامل مع أي شيء إذا لم تستخدم سلسلة أدواتك المخصصة أيضًا utf8 إلا إذا كنت جزيرة كاملة

lukewagner ، أتوقع حقًا أنه سيتم استخدام Wasm عبر مجموعة متنوعة من "القارات" التي يحتمل أن يكون لها القليل من التداخل. وحيثما يفعلون ، يمكنك تحديد interop (عمليًا ، من المحتمل أن تكون ترميزات الأسماء هي أقل مشكلة لمشاركة الوحدات بين الأنظمة الأساسية المختلفة - إنها مكتبات مضيفة). حتى إجمالي الجزر ليست غير واقعية ، خاصةً الأنظمة المضمنة في wrt (والتي تميل أيضًا إلى القليل من استخدام Unicode).

من أصعب الأجزاء في تنفيذ محرك WebAssembly الذي لا يعتمد على المتصفح جعل الأشياء تعمل بالطريقة التي تعمل بها في المتصفح (بشكل أساسي أجزاء JS). أتوقع أنه إذا لم يتم توحيد الترميز ، فسننتهي بمعيار واقعي حيث ينسخ الجميع ما تم فعله لهدف الويب. سيؤدي هذا فقط إلى صعوبة العثور على معلومات حول كيفية فك تشفير هذه السلاسل.

قد تكون هناك قيمة في السماح لبعض البيئات بتقييد المحتوى المسموح به بشكل أكبر ، ولكن عدم طلب UTF-8 سيؤدي فقط إلى مزيد من الصعوبة.

@ MI3Guy ، اقتراح العداد هو تحديد ترميز UTF-8 كجزء من JS API. لذلك إذا كنت تقوم بإنشاء تضمين JS ، فسيتم تعريفه على أنه UTF-8 في كلتا الحالتين ولن يحدث أي فرق بالنسبة لك. (ومع ذلك ، نريد أيضًا السماح لواجهات برمجة تطبيقات التضمين الأخرى التي ليست ويب ولا جافا سكريبت.)

حق. وجهة نظري هي أنك إذا لم تكن تقوم بتضمين JS ، فأنت مجبر على محاكاة الكثير مما يفعله تضمين JS من أجل استخدام WebAssembly toolchain.

قم بإجراء تباين لعدد نقاط التشفير + UTF-8 لكل نقطة رمز.

أود فقط أن أتحدث ضد هذا الخيار. إنه يعقد الأمور ، ولا ينطبق ولا يمكن أن ينطبق على الأقسام الخاصة بالمستخدم ، ولا يقدم أي فائدة يمكنني رؤيتها - من أجل معرفة عدد نقاط الشفرة في سلسلة UTF-8 ، من الناحية العملية ، ينتهي بك الأمر دائمًا بمسح السلسلة بحثًا عن ترميزات غير صالحة ، لذلك يمكنك أيضًا حساب نقاط التشفير أثناء تواجدك بها.

ليس كل شيء هو مجموعة فرعية من UTF-8 ، على سبيل المثال لاتينية 1 لا تزال شائعة الاستخدام إلى حد ما. قد لا تهتم ، لكن ليست مهمة مواصفات Wasm الأساسية هي وضع أحجار لا داعي لها في طريق التنوع البيئي.

صيح؛ يختلف UTF-8 عن كل ترميز تقريبًا بمجرد مغادرة نطاق ASCII. أنا غير متأكد ما هي وجهة نظرك بشأن هذا ، مع ذلك. في الواقع ، يعد استخدام ترميز Latin-1 أمرًا سيئًا على

لست متأكدًا حقًا من نوع "التنوع" الذي تحاول حمايته هنا. لا توجد فائدة حرفيًا من استخدام أي ترميز آخر ، والعديد من الجوانب السلبية. كل حرف يمكنك ترميزه في ترميز آخر موجود في Unicode ويمكن ترميزه في UTF-8 ، لكن العكس لا يكون صحيحًا أبدًا. لا توجد أدوات ذات صلة اليوم لا يمكنها التعامل مع UTF-8 ؛ التكنولوجيا عمرها عقدين حرفيًا.

ما زلت أخبرك أن معايير الويب حسمت هذا السؤال منذ سنوات ، ليس لأن Wasm هو أحد مواصفات الويب التي تحتاج إلى اتباع قواعد الويب ، ولكن لأن ترميز النص هو مشكلة في النظام البيئي يواجه كل شخص تقريبًا نفس المشكلات معها ، وقد تم التعامل مع الويب بالفعل مع ألم فهم هذا الخطأ ، وتعلم كيفية القيام بذلك بشكل صحيح. ليس هناك فضل في الوقوع في الخطأ مرة أخرى في واسم ؛ كل بيئة يجب عليها تشفير النص إما أن تنتقل مباشرة إلى UTF-8 من البداية ، أو ترتكب نفس الأخطاء وتعاني من نفس الألم الذي يعاني منه أي شخص آخر ، ثم تستقر في النهاية على UTF-8. (أو ، في حالات نادرة ، يطور بيئة معزولة بما فيه الكفاية بحيث يمكنهم توحيدها على ترميز مختلف ، ونادراً ما يدفع ثمن التواصل مع البيئة الخارجية. لكنهم يوحدون على ترميز ، وهذا هو الهدف من كل هذا).

لذلك إذا كنت تقوم بإنشاء تضمين JS ، فسيتم تعريفه على أنه UTF-8 في كلتا الحالتين ولن يحدث أي فرق بالنسبة لك. (ومع ذلك ، نريد أيضًا السماح لواجهات برمجة تطبيقات التضمين الأخرى التي ليست ويب ولا جافا سكريبت.)

هذه المشكلة لا علاقة لها بالويب أو JS. يحتاج كل جزء من النظام البيئي إلى ترميز نصي معروف ومتسق ، وهناك واحد يتم الاتفاق عليه على نطاق واسع عبر بيئات البرمجة والبلدان واللغات: UTF-8.

أنا أصوت لـ "Do varuint for length (in bytes)) + UTF-8 لكل بايت". بافتراض أن هذا ليس خيارًا مثيرًا للجدل - فكل تنفيذ سلسلة تقريبًا يخزن السلاسل كـ "عدد وحدات الكود" بدلاً من "عدد نقاط الرمز" ، لأنه أبسط - إذن ليس السؤال الحقيقي "في حالة فشل التحقق من الصحة إذا لم تكن السلسلة كذلك UTF-8 صالح "؟

كما أشرت في # 970 ، يمكن تقريب UTF-8 غير الصحيح إلى UTF-16 ، لذلك إذا تم السماح بترميز UTF-8 غير صالح ، فلن تضطر البرامج التي لا تريد تخزين وحدات البايت الأصلية إلى ذلك. من ناحية أخرى ، فإن التحقق مما إذا كان UTF-8 صالحًا ليس بالأمر الصعب (على الرغم من أننا يجب أن نجيب - هل يجب قبول التسلسلات الطويلة؟ أحرف بديلة؟)

على العموم ، أنا أميل إلى القول دعونا نفوض UTF-8. في الحالة الغريبة التي يكون فيها شخص ما لديه بايت لا يمكنه ترجمته إلى UTF-8 (ربما لأن التشفير غير معروف) ، يمكن ترجمة البايت العشوائي إلى UTF-8.

لست متأكدًا حقًا من نوع "التنوع" الذي تحاول حمايته هنا.

tabatkins ، نعم ، يبدو أن هذا هو جوهر سوء التفاهم.

من المهم أن ندرك أن WebAssembly ، على الرغم من اسمه ، لا يقتصر على الويب. نحن حريصون جدًا على تحديدها في طبقات مناسبة ، بحيث تكون كل طبقة قابلة للاستخدام على نطاق واسع قدر الإمكان.

والجدير بالذكر أن _core_ ليس في الواقع تقنية ويب _على الإطلاق_. بدلاً من ذلك ، حاول التفكير في الأمر على أنه معيار ISA افتراضي. مثل هذا التجريد مفيد في مجموعة واسعة من البيئات المختلفة ، من غنية جدًا (الويب) إلى بدائية جدًا (أنظمة مدمجة) ، والتي ليس لها بالضرورة أي علاقة ببعضها البعض ، وقد تكون غير متوافقة إلى حد كبير ، ولها قيود متضاربة ( أن واسم ليس في وضع يسمح له بالتغيير).

على هذا النحو ، ليس من المنطقي فرض Unicode على _core_ Wasm من فرض Unicode على جميع النصوص الحرفية في لغة البرمجة C. ستُجبر بعض العملاء المحتملين فقط على انتهاك هذا الجزء من المعيار. ما هو المكسب؟

ومع ذلك ، ستكون هناك طبقات مواصفات إضافية أعلى هذه المواصفات الأساسية التي تحدد التضمين وواجهة برمجة التطبيقات في البيئات _concrete_ (مثل JavaScript). من المنطقي تمامًا إصلاح ترميزات السلسلة على هذا المستوى ، وبكل الوسائل ، يجب علينا ذلك.

ملاحظة: الشعار الذي يحدد نطاق Wasm هو أنه تجريد على الأجهزة الشائعة ، وليس تجريدًا عن لغات البرمجة الشائعة. والأجهزة لا تراعي اهتمامات البرامج مثل ترميزات السلسلة. هذا هو الغرض من ABIs.

@ روسبرغ الكروم

على هذا النحو ، ليس من المنطقي فرض Unicode على Core Wasm من فرض Unicode على جميع النصوص الحرفية في لغة البرمجة C. ستُجبر بعض العملاء المحتملين فقط على انتهاك هذا الجزء من المعيار. ما هو المكسب؟

أوافق 100٪. لا تتعلق هذه المشكلة بـ Unicode على الرغم من أنها تتعلق فقط بـ UTF-8 ، وهو ترميز للأعداد الصحيحة ، دون فرض تفسير الأعداد الصحيحة على أنها Unicode.

لا أفهم إذا اتفقنا على ذلك. هل يمكنك توضيح: هل أنت موافق على UTF-8 ، وإذا لم يكن الأمر كذلك ، فلماذا؟

jfbastien ، هل سيكون من الأكثر إنتاجية أن تطلب مطابقة UTF-8 لجميع حرفية سلسلة C؟

كما أشرت سابقًا ، ليس من المنطقي بالنسبة لي تقييد الترميز ولكن ليس مجموعة الأحرف. هذا مثل تعريف بناء الجملة بدون دلالات. لماذا من المحتمل أن تفعل ذلك؟ أنت تكسب صفرًا من حيث التشغيل المتداخل ولكنك لا تزال تضع عقبات اصطناعية للبيئات التي لا تستخدم UTF-8 (وهو ما تفعله بيئات Unicode فقط على أي حال).

jfbastien ، هل سيكون من الأكثر إنتاجية أن تطلب مطابقة UTF-8 لجميع حرفية سلسلة C؟

لا أفهم ، هل يمكنك التوضيح؟

كما أشرت سابقًا ، ليس من المنطقي بالنسبة لي تقييد الترميز ولكن ليس مجموعة الأحرف. هذا مثل تعريف بناء الجملة بدون دلالات. لماذا من المحتمل أن تفعل ذلك؟ أنت تكسب صفرًا من حيث التشغيل المتداخل ولكنك لا تزال تضع عقبات اصطناعية للبيئات التي لا تستخدم UTF-8 (وهو ما تفعله بيئات Unicode فقط على أي حال).

أعتقد أن جوهر المناقشة.

تطرق tabatkins إلى السوابق لهذا بالضبط:

مرة أخرى ، يبدو أنك تتحدث عن مكتبات التدويل. ما نناقشه هو فقط كيفية فك تشفير متواليات البايت إلى سلاسل ؛ يتطلب فقط معرفة كيفية فك تشفير UTF-8 ، وهو أمر تافه للغاية وسريع للغاية.

ما لم تكن تقوم بمعالجة سلسلة بطريقة صديقة للإنسان ، فكل ما تحتاجه هو القدرة على مقارنة السلاسل بنقطة الرمز ، وربما فرز السلاسل حسب نقطة الرمز ، ولا يتطلب أي منهما أي "دعم Unicode". هذا هو كل ما تستخدمه تقنية الويب الحالية ، على سبيل المثال ، ولا أرى أي سبب لأن بيئات Wasm تحتاج ، بشكل عام ، إلى القيام بأي شيء أكثر تعقيدًا من هذا.

لذلك أوافق: هذا الاقتراح ، على حد تعبيرك ، "تحديد بناء الجملة دون دلالات". هذا شيء شائع جدًا . في الواقع ، فإن مواصفات الطول + البايت الحالي لـ WebAssembly تفعل ذلك بالفعل!

أود أن أفهم ما هي العقبة. أنا حقا لا أرى واحدة.

من المهم أن ندرك أن WebAssembly ، على الرغم من اسمه ، لا يقتصر على الويب.

لقد ذكرت للتو في التعليق السابق مباشرة أن هذا لا علاقة له بالويب. أنت تستمر في محاولة استخدام هذه الحجة ، وهذا أمر محير حقًا لي. ما أقوله ليس له علاقة بالويب ؛ أنا أشير فقط إلى تجربة الويب كمثال مهم للدروس المستفادة.

على هذا النحو ، ليس من المنطقي فرض Unicode على Core Wasm من فرض Unicode على جميع النصوص الحرفية في لغة البرمجة C. ستُجبر بعض العملاء المحتملين فقط على انتهاك هذا الجزء من المعيار. ما هو المكسب؟

أنت لا توضح النقطة التي تعتقد أنك بصددها - يحتوي C بالفعل على ترميز مدمج ، حيث تستخدم النصوص الحرفية ترميز ASCII. (إذا كنت تريد أي شيء آخر ، فعليك القيام بذلك يدويًا عن طريق الهروب من تسلسل البايت المناسب.) في لغة C ++ الأكثر حداثة ، يمكنك الحصول على قيم حرفية لسلسلة UTF-16 و UTF-8 ، بينما لا يزال بإمكانك وضع وحدات بايت عشوائية في السلسلة باستخدام \x يهرب ، \u يهرب على الأقل التحقق من أن القيمة هي نقطة كود صالحة.

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

أنت تكسب صفرًا من حيث التشغيل المتداخل ولكنك لا تزال تضع عقبات اصطناعية للبيئات التي لا تستخدم UTF-8 (وهو ما تفعله بيئات Unicode فقط على أي حال).

هل يمكنك من فضلك الإشارة إلى بيئة موجودة تستخدم أحرفًا غير مضمنة في Unicode؟ تستمر في محاولة الدفاع عن هذا الموقف من وجهة نظر النقاء النظري / تنوع البيئة ، ولكن النقطة الكاملة في Unicode حرفيًا هي تضمين جميع الأحرف . إنها مجموعة الأحرف الوحيدة التي يمكنها تقديم حجة ذات مصداقية عن بُعد للقيام بذلك ، وعندما تستخدم مجموعة أحرف Unicode ، فإن UTF-8 هو الترميز العالمي المفضل.

ما هو التنوع الذي تحاول حمايته؟ سيكون من الرائع رؤية مثال واحد. : /

tabatkins :

من المهم أن ندرك أن WebAssembly ، على الرغم من اسمه ، ليس كذلك
يقتصر على الويب.

لقد ذكرت للتو في التعليق السابق مباشرة أن هذا لا يحتوي على شيء
على شبكة الإنترنت. تستمر في محاولة استخدام هذه الحجة ، وهي حقًا
يحيرني. ما أقوله ليس له علاقة بالويب ؛ أنا فقط
الإشارة إلى تجربة الويب كمثال مهم للدروس المستفادة.

ما أحاول التأكيد عليه هو أن Wasm يجب أن يكون قابلاً للتطبيق على أكبر عدد ممكن
منصات ممكنة ، حديثة أم لا. أنت تستمر في الجدال من النهاية السعيدة
من الطيف حيث يكون كل شيء Unicode و / أو UTF-8 وكل شيء
آخر هو مهمل للتو.

أنت لا توضح النقطة التي تعتقد أنك تطرحها - لدى C فعلاً

ترميز مدمج ، حيث تستخدم السلسلة الحرفية ترميز ASCII. (إن أردت
أي شيء آخر عليك القيام به يدويًا عن طريق الهروب من البايت المناسب
في لغة C ++ الحالية ، يمكنك الحصول على سلسلة UTF-16 و UTF-8
الحرفية ، وبينما لا يزال بإمكانك وضع وحدات بايت عشوائية في السلسلة باستخدام
\ x يهرب ، \ u يهرب على الأقل التحقق من أن القيمة صالحة
نقطة الشفرة.

لا ، هذا غير صحيح. لا تتطلب مواصفات C ASCII. لا حتى
تتطلب التوافق مع ASCII. يسمح بمصدر شبه تعسفي
مجموعات الأحرف "ويمكن أن تحتوي السلاسل الحرفية على أي حرف من الكامل
يضع. لا توجد قيود فيما يتعلق بالتشفير ، فهو كليًا
تنفيذ محدد. كانت هناك تطبيقات لـ C قيد التشغيل
منصات EBCDIC ، والتي لا تزال مدعومة بالمعيار الحالي. مجلس التعاون الخليجي
يمكن معالجة المصادر في أي ترميز iconv (يوجد منها حوالي 140
إلى جانب UTF-8) ، مثل UTF-16 المشهور في آسيا. C ++ لا يختلف.

(يجب أن يجيب هذا أيضًا على سؤال jfbastien .)

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

مرة أخرى: هذا _سوف يتم تحديده بشكل مناسب لكل بيئة. عندما شخص ما
يتلقى وحدة Wasm من شخص آخر يعمل في نفس النظام البيئي
فلا توجد مشكلة. لن يحتاج مطور JS إلى الاهتمام أبدًا.

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

أنت تكسب صفرًا من حيث التشغيل المتداخل ولكنك لا تزال تقيم حواجز مصطنعة من أجل

البيئات التي لا تستخدم UTF-8 (وهو ما تفعله بيئات Unicode فقط
على أي حال).

يمكنك إرضاء أشر إلى بيئة في وجود هذا الاستخدامات
الأحرف التي لم يتم تضمينها في Unicode؟ أنت تستمر في محاولة الدفاع عن هذا
الموقف من وجهة نظر النقاء النظري / التنوع البيئي ، ولكن
حرفيًا ، فإن النقطة الكاملة في Unicode هي تضمين كلالشخصيات . إنها مجموعة الأحرف الوحيدة التي يمكنها إنشاء ملف
حجة ذات مصداقية للقيام بذلك ، وعند استخدام حرف Unicode
مجموعة ، UTF-8 هو الترميز العالمي المفضل.

ما هو التنوع الذي تحاول حمايته؟ سيكون من الرائع أن نرى حتى
مثال واحد. : /

على سبيل المثال ، فيما يلي قائمة بأنظمة التشغيل المضمنة: https://en.wikipedia.org/wiki/
التصنيف: Embedded_operating_systems
من المحتمل أن يستخدم البعض منهم UTF-8 والبعض الآخر لا يستخدمه. قد يجد البعض استخدامًا لـ Wasm ،
على الأرجح لن تفعل ذلك. لكن لا فائدة لنا في تقليلها
مناسب لهم.

إدخال واحد من تلك القائمة ربما لا تزال مألوفًا لك هو DOS. كما
بقدر ما نحبها جميعًا أن تموت ، لا تزال أنظمة DOS نشطة ، وتستخدم
OEM.

jfbastien :

لذلك أوافق: هذا الاقتراح ، على حد تعبيرك ، "تعريف بناء الجملة بدون
دلالات ". هذا شيء شائع جدًا . في الواقع ، WebAssembly
الطول الحالي + مواصفات البايت يفعل هذا بالفعل!

إن التكرارات النادرة لشيء من هذا القبيل وأنا على دراية بها جميعًا لها علاقة بها
توفير فتحة هروب للسلوك الخاص بالتنفيذ. هذا
أيضًا حالة الاستخدام المعقول الوحيدة. هذا لا معنى له هنا ، رغم ذلك. اذا أنت
تريد توفير فتحة هروب للسلاسل ، فلماذا تهتم بالمطالبة
UTF-8 ، بدلاً من السماح لأي سلسلة بايت "بناء جملة"؟ هذا بناء الجملة بدون
الدلالات كعامل تعطيل وليس عامل تمكين.

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

اسمحوا لي أن أسأل العكس: ما هي الفائدة (في أنظمتهم البيئية)؟
أنا حقا لا أرى واحدة.

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

أهداف هذا ستكون:

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

أسئلة؟

• هل هناك أي خطر من أن يصبح هذا مطلبًا زاحفًا لمزيد من التحقق من الصحة؟ أعتقد أن قلقي الأساسي في هذا الفضاء سيكون دائمًا عبئًا غير معقول لابتلاع وحدة العناية المركزة على أنها تبعية.

• أفترض أن هذا يعني الهدف المتمثل في تشجيع الترميزات بنشاط مثل Latin1 التي تتعارض مع UTF-8؟ أي سلاسل الأدوات التي تنبعث منها ستكون غير متوافقة ، والتطبيقات التي تقبلها بالمثل.

• لقد واجهت الويب تاريخياً مشكلة في توحيد هذه المساحة بسبب الاستخدام المتداخل للبتات من المناطق التي كانت في السابق عبارة عن جزر مشفرة. من ناحية أخرى ، فإن انطباعي هو أن UTF-8 يُنشئ أشياء مثل أن تكاليف الانتقال يتحملها الأشخاص الذين لا يستخدمون ASCII بشكل غير متناسب ، وأن بعض المناطق لديها المزيد من الاهتمام. أتخيل أن انتقال unicode هو أمر حتمي عملي (وشبه مكتمل). هل هناك بعض المستندات / الكيانات المركزية التي يمكننا الإشارة إليها والتي تتناول كيفية حل بعض المشكلات السياسية والإقليمية المتعلقة بالشفرة الموحدة على الويب؟

@ روسبرغ الكروم

• أرى عدم الاتساق المنطقي في التحقق من صحة بعض جوانب الترميز دون غيرها. من ناحية أخرى ، فإن انطباعي هو أن utf8 منتشر في هذه المرحلة (وأن دفعًا صغيرًا في الأدوات + التحقق من الصحة له تكلفة منخفضة). هل الانزعاج الرئيسي الذي تشعر به عند إضافة التحقق من صحة UTF-8 إلى المواصفات هو التناقض أو أي شيء آخر؟

للتوضيح ، تقترح فقط تشفير utf-8 لنقاط الكود بغض النظر عما إذا كانت غير صالحة معًا (يمكن القيام بذلك في 10 أسطر من التعليمات البرمجية).

نعم ، لا أعتقد أن هناك أي مجموعات غير صالحة ؛ هناك فقط بعض نقاط الشفرة الفردية (تلك المحجوزة لبدائل UTF-16) غير الصالحة من الناحية الفنية للتشفير كـ UTF-8. ومع ذلك ، إذا كان التحكم الكامل في البايت مرغوبًا فيه ، فإن ترميز WTF-8 موجود بالفعل ، ولكن يجب أن نكون صريحين جدًا بشأن "نعم ، نريد السماح لهذه السلاسل باحتواء بيانات عشوائية غير سلسلة فيها أحيانًا" كهدف إذا نذهب بهذه الطريقة. الغرض من تنسيق WTF-8 (و WTF-16) فقط هو توفير مواصفات رسمية للبيئات التي لديها قيود متوافقة مع الإصدارات السابقة على فرض التنسيق الجيد UTF- *.

يمكن استخدام الأحرف الكبيرة الكبيرة على سبيل المثال في المواصفات للإشارة إلى: أنت تفعل شيئًا خاطئًا إذا كنت تعتقد أنك بحاجة إلى مكتبة تدويل لتطبيق Wasm؟

نعم ، i18n غير مطلوب بأي شكل أو شكل أو شكل. يتم تعيين CSS افتراضيًا على UTF-8 ، على سبيل المثال ، ويقوم فقط بإجراء مقارنة / فرز أولية لنقاط الكود عندما يسمح بأشياء خارج نطاق ASCII. لا يوجد سبب يدعو واسم للذهاب إلى أبعد من هذا أيضًا.

هل هناك أي خطر من أن يصبح هذا مطلبًا زاحفًا لمزيد من التحقق من الصحة؟ أعتقد أن قلقي الأساسي في هذا الفضاء سيكون دائمًا عبئًا غير معقول لابتلاع وحدة العناية المركزة على أنها تبعية.

لم تحتاج منصة الويب مطلقًا إلى فرض تحقق إضافي على الأسماء المجردة حتى الآن. تجربتي تشير إلى أنه لن يكون ضروريًا أبدًا.

أفترض أن هذا يعني هدف الترميزات النشطة [غير المشجعة] مثل Latin1 التي تتعارض مع UTF-8؟ أي سلاسل الأدوات التي تنبعث منها ستكون غير متوافقة ، والتطبيقات التي تقبلها بالمثل.

نعم ، مع التغيير إلى " عدم التشجيع" في كلماتك. ^ _ ^ بيت القصيد هو أنه يمكن للمنتجين والمستهلكين تشفير وفك تشفير السلاسل من / إلى متواليات البايت دون الحاجة إلى تخمين ما تفعله نقطة النهاية الأخرى. لقد كان هذا ألمًا رهيبًا لكل بيئة واجهته على الإطلاق ، وهناك حل معتمد على نطاق واسع له الآن.

لقد واجهت الويب تاريخياً مشكلة في توحيد هذه المساحة بسبب الاستخدام المتداخل للبتات من المناطق التي كانت في السابق عبارة عن جزر مشفرة. من ناحية أخرى ، فإن انطباعي هو أن UTF-8 يُنشئ أشياء مثل أن تكاليف الانتقال يتحملها الأشخاص الذين لا يستخدمون ASCII بشكل غير متناسب ، وأن بعض المناطق لديها المزيد من الاهتمام. أتخيل أن انتقال unicode هو أمر حتمي عملي (وشبه مكتمل). هل هناك بعض المستندات / الكيانات المركزية التي يمكننا الإشارة إليها والتي تتناول كيفية حل بعض المشكلات السياسية والإقليمية المتعلقة بالشفرة الموحدة على الويب؟

نعم ، كان لديها بالتأكيد مشاكل في عملية الانتقال ؛ لا يزال يلزم تعيين HTML افتراضيًا إلى Latin-1 بسبب التوافق الخلفي ، ولا تزال هناك بعض الجيوب الصغيرة من محتوى الويب التي تفضل ترميزًا خاصًا بلغة معينة (غالبًا Shift-JIS ، وهو ترميز باللغة اليابانية). لكن الغالبية العظمى من العالم تحولت خلال العقدين الماضيين ، ويعتبر الانتقال قد اكتمل إلى حد ما الآن.

كانت "أعباء UTF-8 غير المنتمين إلى ASCII" شائعة خبيثة ، ولكنها غير صحيحة تمامًا تقريبًا ، لفترة طويلة. تتضمن معظم اللغات الأوروبية غالبية أبجدية ASCII في المقام الأول ، لذا فإن معظم نصوصها عبارة عن تسلسلات أحادية البايت وينتهي بها الأمر أصغر من UTF-16. الأمر نفسه ينطبق على أنظمة الكتابة مثل Pinyin. تشغل CJK langs في الغالب منطقة UTF-8 ذات 3 بايت ، ولكنها تتضمن أيضًا كميات كبيرة من أحرف ASCII ، لا سيما في لغات الترميز أو لغات البرمجة ، لذلك أيضًا ، بشكل عام ، انظر إما أحجام تشفير أصغر أو مماثلة لـ UTF-8 كما هو الحال في UTF-16 أو ترميزاتها المتخصصة.

بالنسبة للكميات الكبيرة من النص الخام بأبجدية CJK أو غير ASCII مثل السيريلية ، نرى أن UTF-8 يشغل بالفعل مساحة أكبر من الترميز المتخصص. كانت هذه مخاوف ، مع ذلك ، في أوائل التسعينيات ، عندما تم قياس سعة القرص الصلب بالميغابايت وكان

كتبت إلى "انتقال Unicode" ، الذي حدث بالفعل على مستوى العالم. إن تنسيق النص الذي لا يتطلب ترميزه باستخدام UTF-8 هذه الأيام يرتكب خطأً فادحًا غير تاريخي.

لست متأكدًا من أي مستند محدد يوضح هذه الأشياء ، لكنني أراهن أنها موجودة في مكان ما. ^ _ ^

إذا كان الهدف هو الحفاظ على المواصفات الثنائية نقية قدر الإمكان ، فلنقم بإزالة الأسماء بالكامل. جميع مراجعها الداخلية تستند إلى الفهرس ، على أي حال.

بدلاً من ذلك ، أضف قسمًا مخصصًا إلزاميًا إلى مواصفات JavaScript التي تتطلب UTF-8. يمكن للبيئات الأخرى ، مثل الإطار المركزي للحقبة السوفيتية التي تشير إليها @ rossberg-chromium ، تحديد القسم المخصص الخاص بها. يمكن أن يدعم ملف WASM واحد كلا النظامين الأساسيين من خلال توفير كلا القسمين المخصصين. سيكون من السهل نسبيًا للأدوات المخصصة إنشاء قسم مفقود لمنصة غير معروفة عن طريق تحويل قسم أكثر شيوعًا.

إذا كان الهدف هو الحفاظ على المواصفات الثنائية نقية قدر الإمكان ، فلنقم بإزالة الأسماء بالكامل. جميع مراجعها الداخلية تستند إلى الفهرس ، على أي حال.

هذا إعادة صياغة لكيفية عمل الاستيراد / التصدير. إنه ليس مطروحًا على الطاولة ويجب اقتراحه في موضوع مختلف عن هذا.

bradnelson ، AFAICS ، يصف ترميزًا محددًا ولكن بدون تعيين أحرف
يجمع بين أسوأ ما في العالمين: إنه يفرض تكاليف من حيث
القيود والتعقيد والنفقات العامة مع عدم وجود فائدة فعلية من حيث
interop. أعتقد أنني ما زلت في حيرة من أمري ما ستكون النقطة.

@ rossberg-chromium الفائدة الأساسية التي يتم البحث عنها هنا هي تخفيف عبء التخمين عن الأدوات والمكتبات.

نظرًا لأن الفائدة الأساسية التي يتم البحث عنها هنا هي إعفاء الأدوات والمكتبات من عبء التخمين ، فإن أيًا من المتغيرات المذكورة أعلاه التي تتم مناقشتها (UTF-8 مقابل WTF-8 وما إلى ذلك) سيكون أفضل من لا شيء لأنه حتى في أسوأ الحالات ، "أنا متأكد من أنه لا يمكنني تحويل هذه البايتات حرفيًا" أفضل من "تبدو هذه البايتات وكأنها Windows-1252 ؛ ربما سأحاول ذلك". من المعروف أن التخمين عرضة للخطأ ، والفائدة الأساسية التي يتم البحث عنها هنا هي إعفاء الأدوات والمكتبات من عبء التخمين.

sunfishcode ، كيف؟ ما زلت ضائعة.

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

كلا هذين الترميزين 7 بت ، لذلك UTF-8 لا يدخل الصورة حتى.

إذن ما الذي سيجلبه UTF-8 إلى الطاولة؟ حسنًا ، يمكنني "فك تشفير" أي سلسلة غير معروفة أحصل عليها. ولكن بالنسبة إلى كل ما أعرفه ، فإن النتيجة هي _ مجرد كائن ثنائي معتم آخر _ من قيم 31 بت. لا تقدم أي معلومات. ليس لدي أي فكرة عن كيفية ربطها بخيوطي الخاصة.

إذن ، لماذا قد أزعج نفسي بفك تشفير سلسلة غير معروفة؟ حسنًا ، _أنا لا _! يمكنني أيضًا العمل مع النقطة الثنائية الأصلية ذات قيم 8 بت وتوفير المساحة والدورات. لا تزال المواصفات تتطلب مني قضاء دورات للتحقق من صحة الترميز بشكل فارغ.

بالنظر إلى كل ذلك ، ما الذي يمكن أن يكسبه Wasm (الأساسي) أو الأدوات من خلال تبني هذا الاقتراح المحدد؟

AFAICS يصف ترميزًا محددًا ولكن لا يوجد مجموعة أحرف
يجمع بين أسوأ ما في العالمين: إنه يفرض تكاليف من حيث
القيود والتعقيد والنفقات العامة مع عدم وجود فائدة فعلية من حيث
interop. أعتقد أنني ما زلت في حيرة من أمري ما ستكون النقطة.

نحن بالتأكيد نفرض مجموعة أحرف - مجموعة أحرف Unicode. كان JF يصيغ الأشياء بشكل مربك

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

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

مرت العديد من الأنظمة المختلفة بكل هذه الفوضى. لم تكن حروب التشفير ممتعة ؛ لقد أهدروا الكثير من المال والوقت وأسفروا عن الكثير من النصوص التالفة. لقد أنهينا تلك الحروب. تم إنشاء وإصدار Unicode ، وأصبح الشخصية المهيمنة في جميع أنحاء العالم ، لدرجة أن جميع مجموعات الأحرف الأخرى ليست أكثر من فضول تاريخي في هذه المرحلة. لا يزال لدينا معارك منخفضة المستوى حول استخدام UTF-16 مقابل UTF-8 ، ولكن على الأقل من السهل تمييز هذين الاثنين على الأقل (انظر إلى قائمة مكونات الصنف ، أو ابحث عن كثرة البايتات الفارغة) ، و UTF بشكل عام -8 يهيمن بسهولة.

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

@ روسبرغ الكروم

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

إذن ما الذي سيجلبه UTF-8 إلى الطاولة؟ حسنًا ، يمكنني "فك تشفير" أي سلسلة غير معروفة أحصل عليها. ولكن بالنسبة إلى كل ما أعرفه ، فإن النتيجة هي مجرد فقاعة ثنائية أخرى غير شفافة من قيم 31 بت. لا تقدم أي معلومات. ليس لدي أي فكرة عن كيفية ربطها بخيوطي الخاصة.

سيخبرك UTF-8 بالضبط بكيفية ربطه بسلاسلك الخاصة. هذه بالضبط هي المشكلة التي تحلها. (سيكون WTF-8 أيضًا عندما يكون ذلك ممكنًا ، وسيخبرك بشكل لا لبس فيه عندما لا يمكنه ذلك).

هل تقصد بنية بيانات عشوائية مشوهة في شكل سلسلة ثم تم ترميزها كـ UTF-8؟ صحيح أنك لن تكون قادرًا على فك تشابكه ، ولكن يمكنك على الأقل عرض الاسم المشوه بشكل لا لبس فيه كسلسلة ، وهو تحسن على عدم وجود أي شيء لبعض حالات الاستخدام.

هل تقصد المناقشة أعلاه حول استخدام UTF-8 كتشفير للأعداد الصحيحة المبهمة وليس Unicode؟ أعتقد أن المناقشة قد أصبحت مشوشة إلى حد ما. من المغري أن نطلق على الترميز "بناء الجملة" والتدويل "دلالات" ، ولكن هذا يحجب تمييزًا مفيدًا: لا يزال بإمكان UTF-8 أن يقول أن تسلسل بايت معين يعني "Ö" دون ذكر ما يجب أن يفعله المستهلكون بهذه المعلومات. عند استخدامه بهذه الطريقة ، يعد ترميزًا لـ Unicode ، ولكنه لا يتطلب نوع التكلفة التي تم استخدامها في اقتراح "دعم Unicode" أعلاه.

إذن ، لماذا قد أزعج نفسي بفك تشفير سلسلة غير معروفة؟ حسنًا ، لن أفعل! يمكنني أيضًا العمل مع النقطة الثنائية الأصلية ذات قيم 8 بت وتوفير المساحة والدورات. لا تزال المواصفات تتطلب مني قضاء دورات للتحقق من صحة الترميز بشكل فارغ.

لقد قمت الآن ببناء SpiderMonkey مع التحقق الكامل من UTF-8 لمعرفات استيراد / تصدير wasm ، بما في ذلك البدائل والبدائل. لم أتمكن من اكتشاف اختلاف في الأداء في WebAssembly.validate ، إما على AngryBots ، أو في حقيبة اختبار صغيرة مجمعة بواسطة emscripten ومع ذلك تحتوي على 30 عملية استيراد.

المواصفات هي حل وسط بين مخاوف متعددة. أنا أقدر الاهتمام بوقت بدء التشغيل ، لذلك أجريت الآن بعض التجارب وقمت بقياسه. أنا أشجع الآخرين على القيام بتجاربهم الخاصة.

علاوة على ذلك ، لا يعتبر UTF-8 هو ترميز Unicode الوحيد ، ويمكن استخدامه لتشفير الأعداد الصحيحة غير Unicode. إذن ، UTF-8 ليس Unicode.

ما هي الأعداد الصحيحة التي يمكن ترميز UTF-8 والتي ليست جزءًا من Unicode (أي خارج النطاق من U + 0000 إلى U + 10FFFF)؟ هذا البيان يبدو خاطئا.

إذا لم تتحقق من صحة الأحرف الخاصة بك ، يمكنك ترميز أي عدد صحيح 21 بت.

لست متأكدًا تمامًا من سبب عدم قيامنا بالتحقق من صحة ...

يصف flagxor https://encoding.spec.whatwg.org/ الترميزات المختلفة المعروضة على الويب. لاحظ أن أيا منها لا يخرج عن مجموعة أحرف Unicode ، لكن من الواضح أنها ليست كلها متوافقة مع بعضها البعض.

ماذا سيفعل "التحقق"؟ اجعل برنامج wasm الخاص بك غير صالح؟ لا أعتقد أن هناك أي عواقب فعلية يمكن فرضها بشكل معقول.

مثل ، استخدام هروب غير صالح في CSS يؤدي فقط إلى وضع U + FFFD في ورقة الأنماط الخاصة بك ، ولا يفعل أي شيء غريب.

annevk :

علاوة على ذلك ، لا يعتبر UTF-8 هو ترميز Unicode الوحيد ، ويمكن استخدامه لتشفير الأعداد الصحيحة غير Unicode. إذن ، UTF-8 ليس Unicode.

ما هي الأعداد الصحيحة التي يمكن ترميز UTF-8 والتي ليست جزءًا من Unicode (أي خارج النطاق من U + 0000 إلى U + 10FFFF)؟ هذا البيان يبدو خاطئا.

كحد أدنى: U + FFFE و U + FFFF غير أحرف في Unicode. لن يتم استخدام نقاط التشفير (قيم الأعداد الصحيحة) من قبل Unicode لتشفير الأحرف ، ولكن يمكن تشفيرها في UTF-8.

لا تزال نقاط رمز Unicode بالرغم من ذلك. لن أركز كثيرًا على "الشخصيات".

يعد فك تشفير أمرًا معقولاً ، لكن هذا يحد من عدد الأعداد الصحيحة التي يمكنك الحصول عليها.

على هذا النحو ، ليس من المنطقي فرض Unicode على Core Wasm من فرض Unicode على جميع النصوص الحرفية في لغة البرمجة C. ستُجبر بعض العملاء المحتملين فقط على انتهاك هذا الجزء من المعيار. ما هو المكسب؟

قد تلاحظ أن C11 أضاف نوعي char16_t و char32_t بالإضافة إلى بادئة u لسلسلة حرفية بترميز UTF-16 ، بادئة U لـ سلسلة حرفية بترميز UCS-4 ، وبادئة u8 لسلسلة حرفية بترميز UTF-8. لم أحفر بعمق كافٍ لإيجاد الأساس المنطقي لإضافتها ، لكنني أفترض أن "التعامل مع Unicode في C / C ++ القياسي هو كابوس" هو على الأقل جزء من الدافع.

tabatkins ، sunfishcode ، حسنًا ، لذلك أنت لا تتحدث عن نفس الشيء. لكن AFAICTjfbastien كان يصرح بوضوح وبشكل متكرر أن اقتراحه يتعلق بتحديد UTF-8 بدون مجموعة أحرف Unicode.

هذا أيضًا هو التفسير الوحيد الذي بموجبه تصمد المطالبة بالتكلفة المنخفضة.

لأنه إذا افترضنا فعلاً _do_ أن UTF-8 يتضمن Unicode ، فإن هذا المطلب بالتأكيد أغلى بكثير من مجرد تشفير / فك تشفير UTF-8 لأي أداة على أي نظام لم يحدث بعد التحدث (مجموعة فرعية من) Unicode - هم سوف تحتاج إلى تضمين طبقة تحويل كاملة.

tabatkins ، سيتم تضمين core Wasm في الأنظمة الموجودة مسبقًا - أحيانًا لأسباب أخرى غير قابلية النقل - بحيث لا تملك القدرة على تغيير أو فرض أي شيء عليها. إذا واجهوا المشاكل التي وصفتها ، فإن تلك المشاكل موجودة بشكل مستقل عن واسم. _ لا يمكننا إصلاح _ مشاكلهم.

النتيجة المحتملة لمحاولة فرض Unicode عليها جميعًا هي أن بعض العناصر المحتملة سوف تنتهك ببساطة هذا الجزء من المواصفات ، مما يجعلها موضع نقاش تمامًا (أو الأسوأ من ذلك ، أنها ستتجاهل Wasm تمامًا).

إذا حددناها OTOH في طبقة مناسبة ، فإننا لا نجازف بذلك - دون أن نفقد أي شيء في الممارسة العملية.

لأنه إذا افترضنا بالفعل أن UTF-8 يتضمن Unicode ، فإن هذا المطلب بالتأكيد أغلى بكثير من مجرد تشفير / فك تشفير UTF-8 لأي أداة على أي نظام لم يحدث بعد (مجموعة فرعية من) Unicode - هم سوف تحتاج إلى تضمين طبقة تحويل كاملة.

ما الأنظمة الأساسية الموجودة التي تستخدم مجموعة أحرف أصلية ليست Unicode ، وليس ASCII ، ولا تحتوي على تسهيلات لتحويل هذه الأحرف إلى / من Unicode ، وستحتاج إلى استخدام معرفات غير ASCII في Wasm؟ (أعني أنها موجودة بالفعل ، وليست منظمة روسية افتراضية قررت استخدام Wasm في DOS.)

rocallahan أعتقد أن @ rossberg-chromium مهتم (أو على الأقل سأكون) بأجهزة مثل الأنظمة المضمنة ، والتي لا تريد التكلفة الإضافية لمكتبة وحدة العناية المركزة الكاملة. سيُجبرون إما على قبول bloat ، أو عدم إجراء التحقق الكامل من الصحة ، أو عدم قبول ملفات wasm التي تحتوي على أحرف غير ascii (والتي قد لا يتحكمون فيها).

أيضًا ، بالمعنى الدقيق للكلمة ، غالبًا ما تشتمل هذه الأجهزة على أجهزة بها مجموعات أحرف غير قياسية مثل:
https://www.crystalfontz.com/product/cfah1602dyyhet-16x2-character-lcd؟kw=&origin=pla#datasheets
https://www.crystalfontz.com/products/document/1078/CFAH1602DYYHET_v2.1.pdf
(الذي يحتوي على مجموعة أحرف أسكي مختلطة + لاتينية 1 + مجموعة أحرف يابانية)
لكن القلق هو ما يجب عليك التحقق منه ، وهو أمر مهم بغض النظر.

tabatkins على الرغم من أنني اعتقدت أنها أشارت إلى أن القصد هو:

• تفويض UTF-8 + Unicode باعتباره التفسير الوحيد "الصحيح" للبايتات
• اذكر صراحة أن Unicode لا يلزمه التحقق من صحة الوحدة النمطية (لتوفير التكلفة)

أعتقد أن @ rossberg-chromium مهتمة (أو على الأقل سأكون كذلك) بأجهزة مثل الأنظمة المضمنة ، والتي لا تريد التكلفة الإضافية لمكتبة وحدة العناية المركزة الكاملة. سيُجبرون إما على قبول bloat ، أو عدم إجراء التحقق الكامل من الصحة ، أو عدم قبول ملفات wasm التي تحتوي على أحرف غير ascii (والتي قد لا يتحكمون فيها).

كما ذُكر مرارًا وتكرارًا ، هذا هو الرنجة الحمراء. ليست هناك حاجة لفعل أي شيء متعلق بوحدة العناية المركزة عن بعد ؛ الويب بالتأكيد لا يفعل ذلك. من فضلك توقف عن نشر هذه المعلومات غير الصحيحة.

"التحقق الكامل من الصحة" عملية تافهة للغاية ، ويتم إجراؤها تلقائيًا كجزء من عملية فك تشفير UTF-8 المطابقة.

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

لذا فإن مطلب فك تشفير UTF-8 بشكل صحيح ، محدد بشكل واضح ليكون شيئًا يمكنك القيام به في عدد قليل من أسطر التعليمات البرمجية ، وهي عملية دقيقة ، وتعادل أساسًا تحديد تفسير unicode + utf-8 للبايت.

نعم فعلا. تحليل UTF-8 تافه للغاية ؛ المضاعفات الوحيدة هي عدد نقاط الشفرة القليلة التي لا يُسمح لك بتشفيرها في UTF-8 ، والتي ستحللها وحدة فك التشفير المتوافقة بدلاً من ذلك على أنها حرف واحد أو أكثر من أحرف U + FFFD.

لكن هذه عملية يجب على نقطة النهاية القيام بها. لا يجب على واسم أن تهتم بأي من هذا ؛ يمكن لأجهزة فك التشفير المتوافقة التعامل مع أي نمط بت تعسفي ترميه عليهم. (سيقررون فقط أن معظم نمط بت القمامة هو أحرف U + FFFD.) كل ما كنت أطلبه ، طوال هذا الوقت ، هو متطلبات المطابقة على مستوى المؤلف بأن يتم تشفير هذه السلاسل باستخدام UTF-8. إذا انتهكت ذلك ، يمكن لسلسلة الأدوات الخاصة بك الإبلاغ عنها على أنها خطأ ، ولكن لا يوجد شيء يحتاج Wasm نفسه إلى القيام به.

هذا مشابه ، على سبيل المثال ، لتعريف CSS لقواعد لما يشكل ورقة أنماط صالحة ، ولكن لا يزال من الناحية الفنية يقبل أي نمط عشوائي من البتات.

أيضًا ، بالمعنى الدقيق للكلمة ، غالبًا ما تشتمل هذه الأجهزة على أجهزة بها مجموعات أحرف غير قياسية مثل:

إن وجود مجموعات الأحرف هذه لا علاقة له بـ Wasm إلا إذا كنت تتوقع أن يكتب الناس معرفات Wasm في (نطاقات غير ASCII).

صحيح ، جميع وسائل "استخدام UTF-8" هي https://encoding.spec.whatwg.org/#utf -8-decoder. وحدة العناية المركزة ليست قريبة حتى من المتطلبات.

في 25 فبراير 2017 الساعة 01:13 ، كتب Brad Nelson [email protected] :

في الدردشة مع tabatkins https://github.com/tabatkins ، شيء واحد
أعتقد أنه من المهم أن أكون واضحًا هنا:
مطلوب وحدة فك ترميز Unicode المطابقة للسماح بالتعسف
مجموعات من المعدلات نقاط رمز غير مخصصة إلخ. لذا فإن مزيجًا طائشًا من
المعدلات وما إلى ذلك ، حتى من خلالها لا تجعل شيئًا معقولًا ، هو
مطلوب للسماح به من قبل Unicode. وحدة فك ترميز رفضت الهراء
قد تكون التوليفات غير متوافقة.

لذا فإن شرط فك تشفير UTF-8 بشكل صحيح ، محدد بشكل واضح ليكون كذلك
شيء يمكنك القيام به في عدد قليل من أسطر التعليمات البرمجية ، هو عملية دقيقة ،
وهو مكافئ بشكل أساسي لتحديد Unicode + utf-8
تفسير البايت.

لتوضيح ما قلته. أنا لا أجادل في أن وحدة العناية المركزة الكاملة ربما لن تكون كذلك
ضروري (على سبيل المثال ، فرز الأسماء حسب نقاط الرمز يبدو سيئًا
سهولة الاستخدام).

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

>

أيضًا ، بالمعنى الدقيق للكلمة ، غالبًا ما تشتمل هذه الأجهزة على أجهزة بها
مجموعات الأحرف غير القياسية مثل:

إن وجود مجموعات الأحرف هذه لا علاقة له بواسم إلا إذا كنت أنت
توقع أن يكتب الناس معرفات Wasm في (نطاقات بخلاف ASCII).

rocallahan https://github.com/rocallahan ، لا يزال يتعين عليهم أن يكونوا قادرين على ذلك
تأخذ في Unicode التعسفي. لكن ماذا سيفعلون بها؟ إذا كان واسم
التنفيذ على مثل هذه المنصة يقتصر على ASCII ثم سيكون
انتهاك المواصفات المقترحة. (أنا أعتبر أيضًا أن هذا يعني ضمنيًا
الشخصيات غير ASCII لشخص ما ليست ذات صلة بداهة من الناحية الثقافية
مشكوك فيه. يجب أن يكون هذا قرارهم.)

علاوة على ذلك ، سيتعين عليهم التعامل مع مشكلة الأحرف التي لا يمكن تعيينها (في أي من الاتجاهين) ، لذلك ستظل تواجه مشكلات التوافق بشكل عام ، فقط قم بضرب العلبة على الطريق.

هل هذا قلق نظري؟

وإذا كان ذلك مصدر قلق معقول ، فيجب علينا مرة أخرى موازنة (الحدوث * التكلفة) للتعامل مع ذلك مقابل تكلفة كل مستخدم آخر لـ Wasm تقريبًا في العالم غير قادر على الاعتماد على ترميز ، والاضطرار إلى التعامل مع نفس التشفير ، كان على منصة الويب أن تنتقل من خلال ، وفي النهاية تم إصلاحها قدر الإمكان.

ستُجبر الأنظمة الأساسية التي لا تدعم Unicode على إجراء تحويل الترميز للتعامل مع سلاسلها فعليًا.

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

• تستورد وحدة Wasm معرّف النظام الأساسي
• تستورد المنصة معرّف Wasm
• يمكنك استخراج أسماء Wasm وطباعتها أو حفظها باستخدام سلاسل النظام الأساسي ، على سبيل المثال لتفريغ تتبع المكدس.

حق؟

بالنسبة للأنظمة الافتراضية التي لا تحتوي على Unicode ، في الحالتين الأوليين ، تكون النصيحة بسيطة: معرفات الحد التي تم استيرادها عبر حدود النظام الأساسي إلى ASCII ، ثم يكون تحويل الشفرة المطلوب تافهًا. لا يزال بإمكان وحدات Wasm استخدام أسماء Unicode كاملة داخليًا ولربط بعضها ببعض.

بالنسبة للإصدار الثالث - إذا كان لديك عالم مغلق من وحدات Wasm ، فيمكنك قصر معرفاتها على ASCII. إذا لم يكن الأمر كذلك ، فستصادف عمليًا معرفات UTF8 وستكون قادرًا بشكل أفضل على تحويلها ، وستكون سعيدًا بمواصفات UTF8 المطلوبة!

مما يعني أن الأحرف غير ASCII لشخص ما ليست ذات صلة بداهة

هذه حجة رجل قش. الموقف هنا هو "إذا كنت تريد معرفات غير ASCII ، فاستخدم Unicode أو تنفذ تحويل الترميز إلى / من Unicode" ، ولم يجتذب النقد باعتباره "مشكوكًا به ثقافيًا" في المواصفات الأخرى ، AFAIK.

>

وإذا كان ذلك مصدر قلق معقول ، فيجب علينا مرة أخرى تقييم (حدوث

• تكلفة) للتعامل مع ذلك مقابل تكلفة كل شخص آخر تقريبًامستخدم Wasm في العالم غير قادر على الاعتماد على ترميز ، و
  الاضطرار إلى التعامل مع نفس التشفير ، حيث كان على منصة الويب الانتقال من خلالها ،
  وأخيرًا تم إصلاحه قدر الإمكان.

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

أنتم مهندسو برمجيات. على هذا النحو أفترض أنك تفهم وتقدر
قيمة النمذجة والطبقات ، لفصل الاهتمامات وتعظيمها
إعادة استخدام. هذا ينطبق على المواصفات أيضًا.

>

ستضطر الأنظمة الأساسية التي لا تدعم Unicode إلى إجراء تحويل الترميز إلى الواقع
التعامل مع خيوطهم.

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

• تستورد وحدة Wasm معرّف النظام الأساسي
• تستورد المنصة معرّف Wasm
• يمكنك استخراج أسماء Wasm وطباعتها أو حفظها باستخدام النظام الأساسي
  السلاسل ، على سبيل المثال لتفريغ أثر المكدس.

حق؟

نعم فعلا. بمعنى آخر ، في كل مرة تحتاج فعليًا إلى _استخدام_ سلسلة نصية.

بالنسبة للأنظمة الافتراضية التي لا تدعم Unicode ، في الحالتين الأوليين ،
النصيحة بسيطة: معرفات الحدود التي يتم استيرادها عبر النظام الأساسي
حد ASCII ، فإن تحويل الشفرة المطلوب تافه. وحدات Wasm
لا يزال بإمكانه استخدام أسماء Unicode الكاملة داخليًا ولربط بعضها ببعض.

بالنسبة للإصدار الثالث - إذا كان لديك عالم مغلق من وحدات Wasm ، فأنت
يمكن أن تقصر معرفاتهم على ASCII. إذا لم يكن كذلك ، فعندئذ في الممارسة العملية
تواجه معرّفات UTF8 ومن الأفضل أن تكون قادرًا على تحويلها ، و
ستكون سعيدًا بمواصفات UTF8 المطلوبة!

بموجب الاقتراح لن يُسمح لك بقصر أي شيء على ASCII! إلى
تسمح بأن المواصفات الأساسية يجب أن تكون أكثر السماح. إذن أنت تصنع
وجهة نظري.

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

ماذا عن أدوات معالجة Wasm مثل المفككات؟ ألن يكون من المفيد أن تكون قادرًا على كتابة أداة تجميع تعمل مع أي وحدة Wasm بغض النظر عن متغيرات "تضمين المواصفات"؟

بموجب الاقتراح لن يُسمح لك بقصر أي شيء على ASCII!

بموجب الاقتراح ، لن تقتصر وحدات Wasm على ASCII ، ولكن إذا اختار المنفذ جعل جميع معرفاتهم محددة خارج وحدات Wasm النمطية ASCII (على سبيل المثال إلى حد كبير جميع مكتبات النظام في الواقع!) ، فسيكون ذلك خارج نطاق Wasm المواصفات.

إذا اختار المنفذ طباعة أحرف ASCII فقط في تتبع المكدس واستبدال جميع أحرف Unicode التي لا تنتمي إلى ASCII بـ ? أو ما شابه ذلك ، فيجب أن تسمح المواصفات بذلك ، لأنه عمليًا توجد دائمًا أحرف Unicode لا تستخدمها ليس لديها خط على أي حال.

بعد قولي هذا كله ، فإن تحديد مجموعة فرعية من Wasm تكون فيها جميع أسماء Wasm هي ASCII سيكون غير ضار إلى حد ما نظرًا لأن وحدات Wasm هذه ستتم معالجتها بشكل صحيح بواسطة أدوات تتعامل مع أسماء Wasm على أنها UTF8.

أنتم مهندسو برمجيات. على هذا النحو ، أفترض أنك تفهم وتقدر قيمة الوحدات النمطية والطبقات ، لفصل الاهتمامات وتعظيم إعادة الاستخدام. هذا ينطبق على المواصفات أيضًا.

نعم ، أنا مهندس برمجيات. أنا أيضًا مهندس مواصفات ، لذلك أفهم قيمة الاتساق ووضع المعايير التي تجعل النظام البيئي يعمل بشكل أفضل. تعد مجموعات الأحرف والتشفيرات أحد الموضوعات التي تفوق فيها قيمة الاتساق والقدرة على التنبؤ بشكل كبير قيمة السماح بالوحدة والاختيار. لدينا عقود حرفية من الأدلة على ذلك. هذا هو السبب في أنني أكرر نفسي باستمرار - فأنت تتجاهل التاريخ وتوصيات العديد من الخبراء ، وقد ظهر العديد منهم في هذا الموضوع بالذات ، والعديد من الأشخاص الآخرين الذين أمثل آراءهم ، عندما تصر على أننا بحاجة إلى السماح بالحرية في هذا الصدد.

بعد قراءة هذا الموضوع (الطويل) بالكامل ، أعتقد أن الطريقة الوحيدة لحل هذه المناقشة هي التحديد صراحةً أن قسم الأسماء الذي نصفه بالتنسيق الثنائي ونقوم بالتحسين في https://github.com/WebAssembly/design/pull / 984 هو ترميز UTF-8 ، وأقترح أن نطلق على هذا القسم ببساطة "أسماء utf8" . هذا يجعل الترميز واضحًا ، ومن المؤكد تقريبًا أن جميع الأدوات التي تريد التعامل مع ثنائيات WASM على جميع الأنظمة الأساسية ذات الصلة اليوم تريد التحدث UTF-8 على أي حال. يمكن أن يغفر لهم التحدث فقط UTF-8.

أنا حساس لمخاوف @ rossberg-chromium من الأنظمة الأساسية الأخرى ، وأوافق إلى حد ما. ومع ذلك ، هذا يمكن إصلاحه بسهولة. كما اقترح أحدهم في وقت سابق في الخيط ، فإن هذه الأنظمة مرحب بها كثيرًا لإضافة قسم "أسماء أسكي" غير قياسي أو أي ترميز آخر يستخدمه نظامهم البيئي. مع الأسماء الواضحة ، يصبح من الواضح الأدوات التي تعمل مع الأقسام. بالنسبة للوحدات النمطية التي تعمل فقط على DOS ، سيصبح ذلك واضحًا من وجود أقسام خاصة بـ DOS. IMO سيكون من الكارثة تفسير أسماء هذه الثنائيات على أنها تحتوي على ترميز مختلف.

(بالمناسبة ، هذا مستوحى من قصص الحرب حول نظام فقد بطريق الخطأ ترميز السلاسل الخاصة بالمحتوى الذي تم تحميله بواسطة المستخدم ، ولم يتمكن من استعادتها أبدًا. لقد مات النظام بموت مروع ومتقطع. فقد فقدت ملايين الدولارات حرفيًا .)

يمكننا حتى اعتماد معيار تسمية لأقسام الأسماء (هيه) ، بحيث تكون كلها "\

titzer نعم ، الأقسام المخصصة هي الحل هنا للمنصات الغريبة أو المتخصصة التي لا تريد أن تفعل شيئًا مع UTF8. سأكون مترددًا في وصف المواصفات ، على الرغم من ذلك: إذا كان النظام الأساسي محددًا جدًا في طريقة تشغيله بحيث لا يمكن حتى عناء تعيين نقاط رمز UTF-8 وفقًا لتفضيلاتهم الأصلية ، فقد يرغبون في القيام بذلك مع الأقسام المخصصة أكثر بكثير من مجرد توفير الأسماء بترميزهم المفضل.

أوصي بالتركيز بشكل أكبر على استخدام الأقسام المخصصة للحصول على تفاصيل خاصة بالمنصة في المواصفات ، والسماح لمواصفات النظام الأساسي الخاصة بتحديد تلك التفاصيل. يمكن أن تدعمها سلاسل أدوات WASM الشائعة عبر نوع من هندسة المكونات الإضافية.

titzer التبديل إلى utf8-names يبدو جيدًا. على سبيل المكافأة ، ستسهل عملية الانتقال نظرًا لأن المتصفحات يمكنها بسهولة دعم كل من "الأسماء" (بالتنسيق القديم) و "أسماء utf8" (بالتنسيق # 984) لإصدار أو اثنين قبل إسقاط "الأسماء" والتي بدورها يزيل الكثير من الإلحاح لنشر هذا.

عذرًا إذا كان هذا قد تم تحديده بالفعل أعلاه ولكن ، للتوضيح: هل هناك أي تغيير مقترح على أسماء الاستيراد / التصدير من الموجود في BinaryEncoding.md الآن؟

utf8-names جيدًا.

نفس سؤال lukewagner عند الاستيراد / التصدير.

lukewagnerjfbastien سؤال جيد. لم أر القرار أعلاه. أعتقد قبل كل شيء أننا لا نريد تغيير التنسيق الثنائي عما لدينا الآن. لذا فهي حقًا أيًا كانت التشوهات الذهنية التي يجب أن نمر بها لإقناع أنفسنا بأن ما فعلناه هو أمر منطقي :-)

AFAICT نفترض حاليًا أن السلاسل في الاستيراد / التصدير هي سلاسل غير مفسرة من البايت. هذا جيد. أعتقد أنه من المعقول اعتبار ترميز السلاسل المستخدمة للاستيراد / التصدير يتم تعريفه فقط بواسطة المضمن بطريقة لا يتم تعريفها في قسم الأسماء ؛ على سبيل المثال ، يستخدم JS دائمًا UTF-8. قسم الأسماء يأتي مع ترميز صريح في اسم قسم الأسماء.

الإصدار المختصر: يعد ترميز الأسماء في بيانات الاستيراد / التصدير خاصية لبيئة التضمين ، ويكون ترميز الأسماء في قسم الأسماء صريحًا بواسطة السلسلة المستخدمة لتعريف قسم المستخدم (على سبيل المثال ، "utf8-names").

WDYT؟

هذا جيد بالنسبة لي ويتطابق مع ما كان لدينا قبل دمج # 984 (modulo names => utf8-names ).

أعتقد أن قسم الأسماء ليس مهمًا مثل الاستيراد / التصدير ، حيث تحدث مشكلات التوافق الحقيقية:

• قم بتحميل قسم أسماء mojibaked وستحصل على Error.stack غير تقليدي وتصحيح الأخطاء.
• قم بتحميل استيراد / تصدير mojibaked ولا يعمل شيء.

لا أعتقد أن هذا هو تغيير تنسيق ثنائي حقًا لأن حفلات الزفاف التي ننفذها جميعًا تفترض ذلك بالفعل.

سأعتمد على توصية الأشخاص الذين يعرفون أفضل مني حول هذا الموضوع قبل الإغلاق.

ستحتاج إلى تحديد كيفية فك تشفير UTF-8. هل تستبدل التسلسلات الخاطئة بـ U + FFFD أم توقف عند الخطأ الأول؟ أي أنك تريد إما https://encoding.spec.whatwg.org/#utf -8-decode-without-bom أو https://encoding.spec.whatwg.org/#utf -8-decode-without- بوم أو فشل. في كلتا الحالتين من المحتمل أن يفشل التحميل ، ما لم يحدث أن يستخدم المورد U + FFFD في اسمه.

بالطريقة الموضحة حاليًا ، فإننا نطرح استثناءً إذا فشلت مصفوفة بايت اسم الاستيراد / التصدير في فك تشفير UTF-8 في سلسلة JS. بعد ذلك ، لديك سلسلة JS ويتم تعريف البحث عن الاستيراد من حيث Get .

للتحقق من فهمي ، إذا فعلنا https://encoding.spec.whatwg.org/#utf -8-decode-without-bom-or-failure ، فذلك يعني أنه بعد التحقق الناجح من صحة التحقق من مساواة تسلسل نقاط التشفير سيكون معادلاً للتحقق من المساواة في تسلسل البايت؟

نعم فعلا.

بعد المناقشة أعلاه ، أؤيد التحقق من صحة UTF-8 لأسماء الاستيراد / التصدير في المواصفات الأساسية.

على وجه التحديد ، سيكون هذا utf-8-decode-without-bom-or- failure ، والمساواة في تسلسل نقطة التشفير (بحيث يمكن للمحركات أن تفعل مساواة تسلسل البايت ) ، لذلك ستتجنب المحركات الأجزاء المخيفة والمكلفة من Unicode والتدويل. وهذا يتوافق مع تضمين الويب. لقد جربت هذا ووجدت أن النفقات العامة الرئيسية لا تذكر.

• إعادة: ISA للأجهزة غير مقيدة بالتشفير: الأجهزة التي نتحدث عنها هنا لا تحتوي على واردات / صادرات على هذا النحو ، لذا فإن القياس لا ينطبق بشكل مباشر. المكان الوحيد الذي أعرفه حيث تستخدم هذه الأجهزة معرّفات تسلسل البايت من أي نوع ، وحدة المعالجة المركزية x86 ، يحدد ترميز أحرف معينًا: UTF-8.

• إعادة: طبقات: بصفتنا مهندسي برمجيات ، نعلم أيضًا أن التصفيف والتكوين هي وسيلة وليست غاية في حد ذاتها. على سبيل المثال ، يمكننا بشكل واضح استبعاد 128 LEB من المواصفات الأساسية. من شأن ذلك أن يوفر طبقات ونمذجة أكبر. يمكن القول إن LEB128 متحيز تجاه حالات استخدام الويب.

• إعادة: "الأنظمة المضمنة": أحد الأمثلة المعطاة هو DOS ، ولكن ما هو مثال على شيء يتطلب UTF-8 لأسماء الاستيراد / التصدير نظام DOS للقيام بذلك سيكون مكلفًا أو غير عملي بالنسبة له؟

• Re: Islands: WebAssembly يحدد أيضًا endianness محددًا ، ويتطلب دعم النقطة العائمة ، ووحدات عناوين 8 بت ، ويقوم باختيارات أخرى ، على الرغم من وجود إعدادات حقيقية حيث ستكون هذه أعباء لا داعي لها. تتخذ WebAssembly اختيارات مثل تلك عندما تتوقع أنها ستعزز النظام الأساسي المشترك الذي يمكن للعديد من الأشخاص مشاركته.

• إعادة: هياكل البيانات التعسفية في أسماء الاستيراد / التصدير: هذا مفيد من الناحية النظرية ، ولكن يمكن القيام به أيضًا من خلال تحويل البيانات إلى سلاسل. التشويش أقل ملاءمة ، لكنه ليس صعبًا. لذلك هناك مقايضة هناك ، ولكنها ليست كبيرة (ويمكن القول ، إذا كانت هناك حاجة عامة لإرفاق البيانات الوصفية بالواردات / الصادرات ، فسيكون من الأجمل أن يكون لديك آلية واضحة من المعرّفات ذات الأغراض الإضافية.)

• إعادة: التوافق الثنائي: أتفق أيضًا مع JF على أن هذا التغيير لا يزال ممكنًا. utf-8-decode-without-bom-or-fail تعني عدم وجود تغييرات صامتة في السلوك ، وفي هذا الوقت ، يحافظ جميع منتجي الوسم المعروفين على إنتاجهم متوافقًا مع تضمين الويب (حتى لو كانوا يدعمون أيضًا حفلات الزفاف الأخرى) ، لذا فهم ' إعادة البقاء بالفعل داخل UTF-8.

تم نشر العلاقات العامة التي تقدم اقتراحًا محددًا لأسماء UTF-8 كـ https://github.com/WebAssembly/design/issues/1016.

مع # 1016 ، تم إصلاح هذا الآن.