سؤال

ها هي المشكلة:

في C# أحصل على معلومات من قاعدة بيانات ACCESS القديمة.يقوم .NET بتحويل محتوى قاعدة البيانات (سلسلة في حالة هذه المشكلة) إلى Unicode قبل تسليم المحتوى لي.

كيف يمكنني تحويل سلسلة Unicode هذه مرة أخرى إلى ما يعادلها من ASCII؟


يحرر
Unicode char 710 هو بالفعل MODIFIER LETTER CIRCUMFLEX ACCENT.إليك المشكلة بشكل أكثر دقة:

 -> (Extended) ASCII character ê (Extended ASCII 136) was inserted in the database.
 -> Either Access or the reading component in .NET converted this to U+02C6 U+0065
    (MODIFIER LETTER CIRCUMFLEX ACCENT + LATIN SMALL LETTER E)
 -> I need the (Extended) ASCII character 136 back.


إليك ما جربته (أرى الآن لماذا لم ينجح هذا ...):

string myInput = Convert.ToString(Convert.ToChar(710));
byte[] asBytes = Encoding.ASCII.GetBytes(myInput);

لكن هذا لا ينتج 94 بل بايت بقيمة 63...
إليك محاولة جديدة لكنها لا تزال غير فعالة:

byte[] bytes = Encoding.ASCII.GetBytes("ê");


الحل
بفضل كل من com.csgero و bzlm للإشارة في الاتجاه الصحيح أنا حل المشكلة هنا.

هل كانت مفيدة؟

المحلول

حسنًا ، دعنا نوضح ذلك.كلاهما com.csgero و bzlm وأشار في الاتجاه الصحيح.

بسبب رد blzm، بحثت في صفحة Windows-1252 على الويكي ووجدت أنها تسمى صفحة الرموز.مقالة ويكيبيديا عن صفحة التعليمات البرمجية والذي جاء فيه ما يلي:

لم يكن هناك معيار رسمي لهذهمجموعات الأحرف الموسعة';أشارت شركة IBM فقط إلى المتغيرات على أنها صفحات رموز، كما فعلت دائمًا مع متغيرات ترميزات EBCDIC.

قادني هذا إلى صفحة الرموز 437:

في صفحات الرموز المتوافقة مع ASCII، حافظت الأحرف الـ 128 السفلية على قيم US-ASCII القياسية الخاصة بها، ويمكن توفير صفحات مختلفة (أو مجموعات من الأحرف) في الأحرف الـ 128 العليا.على سبيل المثال، يتم استخدام أجهزة كمبيوتر DOS المصممة لسوق أمريكا الشمالية صفحة الكود 437, ، والتي تضمنت الأحرف المميزة المطلوبة للغة الفرنسية والألمانية وبعض اللغات الأوروبية الأخرى، بالإضافة إلى بعض أحرف رسم الخطوط الرسومية.

لذا، كانت صفحة الرموز 437 هي صفحة الرموز التي كنت أسميها "ASCII الممتد"، وكانت تحتوي على الحرف ê كحرف 136، لذا بحثت عن بعض الأحرف الأخرى أيضًا ويبدو أنها صحيحة.

جاء csgero مع تلميح Encoding.GetEncoding()، واستخدمته لإنشاء العبارة التالية التي تحل مشكلتي:

byte[] bytes = Encoding.GetEncoding(437).GetBytes("ê");

نصائح أخرى

لا يمكنك استخدام ترميز ASCII الافتراضي (Encoding.ASCII) هنا، ولكن يجب إنشاء الترميز باستخدام صفحة الرموز المناسبة باستخدام Encoding.GetEncoding(...).قد تحاول استخدام صفحة الرموز 1252، وهي مجموعة شاملة من ISO 8859-1.

ASCII لا يحدد ê؛يأتي الرقم 136 من الرقم الخاص بترميز 8 بت مثل Windows-1252.

هل يمكنك التحقق من أن حرف e الصغير الذي يحتوي على علامة محيطة (ê) هو في الواقع ما يُفترض تخزينه في قاعدة بيانات Access في هذه الحالة؟ربما يكون U+02C6 U+0065 نتيجة خطأ في التحويل، حيث يكون الإدخال في الواقع e تليها منعطف، أو أي شيء آخر تماما.ربما تحتوي قاعدة بيانات Access على بيانات تالفة، بمعنى أن الترميز المعين لا يتطابق مع المحتويات، وفي هذه الحالة قد يقوم عميل .NET بتحليل البيانات بشكل غير صحيح (باستخدام وحدة فك ترميز خاطئة).

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

في صفحة الكود 437, ، الحرف رقم 136 هو e مع محيط.

حسنًا... لست متأكدًا من الشخصية التي تقصدها.تحتوي علامة الإقحام ("^"، CIRCUMFLEX ACCENT) على نفس الرمز في ASCII وUnicode (U+005E).

/يحرر:اللعنة، خطأي.710 (U+02C6) هو في الواقع حرف التعديل CIRCUMFLEX ACCENT.لسوء الحظ، هذه الشخصية ليست جزءًا من ASCII على الإطلاق.قد تبدو مثل علامة الإقحام العادية ولكنها ذات طابع مختلف.التحويل البسيط لن يساعد هنا.لست متأكدًا مما إذا كان .NET يدعم تعيين الأحرف المتشابهة عند التحويل من Unicode.يستحق التحقيق، رغم ذلك.

القيمة 63 هي علامة الاستفهام، AKA "لا أستطيع عرض هذا الحرف في ASCII".

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top