تشفير مشاكل مع قاعدة بيانات OGR2OGR و postgis/postgresql
-
21-09-2019 - |
سؤال
في مؤسستنا ، نتعامل مع محتوى نظم المعلومات الجغرافية بتنسيقات ملفات مختلفة. أحتاج إلى وضع هذه الملفات في قاعدة بيانات postGIS ، ويتم ذلك باستخدام OGR2OGR. المشكلة هي أن قاعدة البيانات مشفرة UTF8 ، وقد يكون للملفات ترميز مختلف.
لقد وجدت أوصافًا لكيفية تحديد الترميز عن طريق إضافة معلمة خيارات إلى Org2ogr ، ولكن على المظهر أنه ليس له تأثير.
ogr2ogr -f PostgreSQL PG:"host=localhost user=username dbname=dbname \
password=password options='-c client_encoding=latin1'" sourcefile;
الخطأ الذي أستلمه هو:
ERROR 1: ALTER TABLE "soer_vd" ADD COLUMN "målsætning" CHAR(10) ERROR: invalid byte sequence for encoding "UTF8": 0xe56c73 HINT: This error can also happen if the byte sequence does not match the encoding expected by the server, which is controlled by "client_encoding". ERROR 1: ALTER TABLE "soer_vd" ADD COLUMN "påvirkning" CHAR(10) ERROR: invalid byte sequence for encoding "UTF8": 0xe57669 HINT: This error can also happen if the byte sequence does not match the encoding expected by the server, which is controlled by "client_encoding". ERROR 1: INSERT command for new feature failed. ERROR: invalid byte sequence for encoding "UTF8": 0xf8 HINT: This error can also happen if the byte sequence does not match the encoding expected by the server, which is controlled by "client_encoding".
حاليًا ، ملف المصدر الخاص بي عبارة عن ملف شكل وأنا متأكد تمامًا من أنه مشفر Latin1.
ما الخطأ الذي أفعله هنا وهل يمكنك مساعدتي؟
تحيات طيبة ، كاسبر
المحلول
هذا يبدو كما لو أنه من شأنه تعيين العميل الترميز على Latin1. ما هو الخطأ الذي تحصل عليه بالضبط؟
فقط في حالة عدم مرور Ogr2ogr بشكل صحيح ، يمكنك أيضًا محاولة تعيين متغير البيئة PGCLIENTENCODING
ل latin1
.
أقترح عليك التحقق المزدوج من أنهم في الواقع لاتيني 1. ببساطة الجري file
على ذلك سوف يمنحك فكرة جيدة ، على افتراض أنها متسقة بالفعل داخل الملف. يمكنك أيضًا محاولة إرساله من خلال iconv
لتحويله إلى لاتيني 1 أو UTF8.
نصائح أخرى
ماغنوس على حق وسوف أناقش الحل هنا.
لقد رأيت خيار إبلاغ PostgreSQL حول تشفير الأحرف ، options=’-c client_encoding=xxx’
, ، استخدم العديد من الأماكن ، ولكن لا يبدو أن لها أي تأثير. إذا كان شخص ما يعرف كيف يعمل هذا الجزء ، فلا تتردد في توضيح.
اقترح Magnus تعيين PGClientEncoding متغير البيئة إلى LATIN1. يمكن أن يتم ذلك ، وفقًا لقائمة بريدية استمعت إليها ، عن طريق تعديل المكالمة إلى OGR2OGR:
ogr2ogr -–config PGCLIENTENCODING LATIN1 –f PostgreSQL
PG:”host=hostname user=username dbname=databasename password=password” inputfile
هذا لم يفعل أي شيء من أجلي. ما نجح بالنسبة لي هو ، قبل الدعوة إلى Ogr2ogr ، إلى:
SET PGCLIENTENCODING=LATIN1
سيكون من الرائع سماع المزيد من التفاصيل من المستخدمين ذوي الخبرة وآمل أن يساعد الآخرين :)
حالياً، OGR من عند gdal لا يؤدي أي إعادة ترميز لبيانات الأحرف أثناء الترجمة بين تنسيقات المتجهات. أعدد الفريق RFC 23.1: دعم Unicode في OGR وثيقة تناقش دعم إعادة ترميز برامج تشغيل OGR. ال تم تبني RFC 23 وتم إصدار الوظيفة الأساسية بالفعل في GDAL 1.6.0. ومع ذلك ، لم يتم تحديث معظم برامج تشغيل OGR ، بما في ذلك سائق الشكل.
في الوقت الحالي ، أود أن أصف OGR على أنه ترميز لاأدري وجاهل. هذا يعني أن OGR يأخذ ما يحصل عليه ويرسله دون أي معالجة. يستخدم OGR نوع char لمعالجة البيانات النصية. هذا جيد للتعامل مع السلاسل المشفرة متعددة البايت (مثل UTF-8)-إنه مجرد دفق عادي من البايتات المخزنة كمجموعة من عناصر char.
يُنصح أن يقوم مطورو برامج تشغيل OGR بإعادة سلاسل UTF-8 المشفرة لقيم السمات ، ومع ذلك لم يتم اعتماد هذه القاعدة على نطاق واسع عبر برامج تشغيل OGR ، مما يجعل هذه الوظيفة ليست جاهزة المستخدم النهائي حتى الآن.
تحتاج إلى كتابة سطر الأوامر الخاص بك مثل هذا:
PGCLIENTENCODING=LATIN1 ogr2ogr -f PostgreSQL PG:"dbname=...
على Windows أمر
تعيين pgclientencoding = latin1
على Linux
تصدير pgclientencoding = latin1
أو
pgClientEncoding = latin1
علاوة على ذلك ، تساعدني هذه المناقشة:
على Windows
تعيين pgClientEncoding = latin1 ogr2ogr ...
لا تعطيني أي خطأ ، لكن Ogr2ogr لا يعمل ... أحتاج إلى تغيير متغير النظام (على سبيل المثال النظام-> إعدادات النظام المتقدمة-> متغيرات البيئة-> متغير النظام الجديد) إعادة تشغيل النظام ثم تشغيله
OGR2OGR ...
لقد حللت هذه المشكلة باستخدام هذا الأمر:
pg_restore --host localhost --port 5432 --username postgres --dbname {DBNAME} --schema public --verbose "{FILE_PATH to import}"
لا أعرف ما إذا كان هذا هو الحل الصحيح ، لكنه نجح بالنسبة لي.