سؤال

في مؤسستنا ، نتعامل مع محتوى نظم المعلومات الجغرافية بتنسيقات ملفات مختلفة. أحتاج إلى وضع هذه الملفات في قاعدة بيانات 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

علاوة على ذلك ، تساعدني هذه المناقشة:

https://gis.stackexchange.com/questions/218443/ogr2ogr-encoding-on-windows-using-os4geo-shell-with-census-data

على Windows

تعيين pgClientEncoding = latin1 ogr2ogr ...

لا تعطيني أي خطأ ، لكن Ogr2ogr لا يعمل ... أحتاج إلى تغيير متغير النظام (على سبيل المثال النظام-> إعدادات النظام المتقدمة-> متغيرات البيئة-> متغير النظام الجديد) إعادة تشغيل النظام ثم تشغيله

OGR2OGR ...

لقد حللت هذه المشكلة باستخدام هذا الأمر:

pg_restore --host localhost --port 5432 --username postgres --dbname {DBNAME} --schema public --verbose "{FILE_PATH to import}"

لا أعرف ما إذا كان هذا هو الحل الصحيح ، لكنه نجح بالنسبة لي.

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