انظر كمرجع لمجموعة البيانات هذه: https://zenodo.org/record/2539424
يبدو أن Zenodo يقوم بضغط الملفات المضغوطة بصيغة gzip مرتين دون سابق إنذار. لذلك فهي "مضغوطة مزدوجة" (!). لذلك ، عند تنزيلها ، يجب تسميتها:
eswiki.wikilink_graph.2006-03-01.csv.gz.gz
الشيء المربك للغاية هو أن MD5 المعروض يشير إلى الملف الأصلي (مضغوط مرة واحدة):
eswiki.wikilink_graph.2006-03-01.csv.gz
md5:2036a75ed53acdcc81f53061057fe343
لذلك لا يتطابق هذا مع الملف بمجرد تنزيله ، لكنه يتطابق مع الملف الأصلي (مضغوط مرة واحدة فقط).
هذا ما أحصل عليه (أحفظ الملف الذي تم تنزيله كـ .gz.gz
):
$ md5sum eswiki.wikilink_graph.2006-03-01.csv.gz.gz
b32c3b896be22c32bb17b9fe887bda51 eswiki.wikilink_graph.2006-03-01.csv.gz.gz
$ gunzip eswiki.wikilink_graph.2006-03-01.csv.gz.gz
$ md5sum eswiki.wikilink_graph.2006-03-01.csv.gz
2036a75ed53acdcc81f53061057fe343 eswiki.wikilink_graph.2006-03-01.csv.gz
$ sha512sum eswiki.wikilink_graph.2006-03-01.csv.gz
56a48b0f82922fee20c07b0a2480bca1872c5e4aa8521a86e178dc00aea5dd2e4cda4ae05eb1b1950da7447dae70d47d8daa8d7a3c62d6989aaad09bd1fbcc71
eswiki.wikilink_graph.2006-03-01.csv.gz
$ zcat eswiki.wikilink_graph.2006-03-01.csv.gz | head -n10
page_id_from page_title_from page_id_to page_title_to
10 Argentina 3037 10 de enero
10 Argentina 3326 12 de octubre
10 Argentina 6301 13 de abril
10 Argentina 7874 1492
10 Argentina 6302 14 de abril
10 Argentina 14485 1502
10 Argentina 14471 1516
10 Argentina 14450 1536
10 Argentina 14434 1553
كما ترى ، لا يتطابق الملف الذي تم تنزيله مع الملف MD5 وإذا قمت بإلغاء ضغط الملف مرة واحدة ، فإن MD5 يطابق. بمجرد فك ضغطه ، فإنه يتطابق أيضًا مع مبالغ SHA512 التي أقدمها بشكل منفصل في نفس مجموعة البيانات في الملف eswiki.wikilink_graph.sha512sums.txt
:
$ grep '2006-03-01' eswiki.wikilink_graph.sha512sums.txt
56a48b0f82922fee20c07b0a2480bca1872c5e4aa8521a86e178dc00aea5dd2e4cda4ae05eb1b1950da7447dae70d47d8daa8d7a3c62d6989aaad09bd1fbcc71
eswiki.wikilink_graph.2006-03-01.csv.gz
إنه أمر غريب للغاية لأن Zenodo لا يقوم بضغط الملفات النصية (ملفات README وملفات التجزئة) ولا يوجد إشعار في أي مكان بهذا السلوك.
تحرير: في حال كنت تتساءل (منذ أن سأل كل من أخبرته عن هذه المشكلة) أنا متأكد من أن الملفات التي قمت بتحميلها تم ضغطها مرة واحدة فقط ، ولديها على القرص الخاص بي ، ولا تزال موجودة ويتم ضغطها مرة واحدة .
شكرا للإبلاغ عن هذه المسألة.
لقد أعدت إنتاج المشكلة المتعلقة برأس Accept-Encoding: gzip
الذي يرسله المتصفح.
$ curl -H "Accept-Encoding: gzip" -o eswiki.wikilink_graph.2006-03-01.csv.gz https://zenodo.org/record/2539424/files/eswiki.wikilink_graph.2006-03-01.csv.gz?download=1
$ md5sum eswiki.wikilink_graph.2006-03-01.csv.gz
b32c3b896be22c32bb17b9fe887bda51 eswiki.wikilink_graph.2006-03-01.csv.gz
ضد.
$ curl -o eswiki.wikilink_graph.2006-03-01.csv.gz https://zenodo.org/record/2539424/files/eswiki.wikilink_graph.2006-03-01.csv.gz?download=1
$ md5sum eswiki.wikilink_graph.2006-03-01.csv.gz
2036a75ed53acdcc81f53061057fe343 eswiki.wikilink_graph.2006-03-01.csv.gz
إنني أتطلع إلى مزيد من هذا ولكن إما أنه مرتبط بتكوين NGINX الخاص بنا أو بطريقة ما نوع MIME الذي يتم تسليمه بواسطة خادم التطبيق الخاص بنا.
حسنًا ، أعتقد أنني اكتشفت ما يحدث. إنه مزيج من خطأ في التطبيق والتهيئة الخاطئة.
يتم تخمين نوع MIME بواسطة خادم التطبيق على غرار هذا:
>>> import mimetypes
>>> mimetypes.guess_type('eswiki.wikilink_graph.2006-03-01.csv.gz')
('text/csv', 'gzip')
ومع ذلك ، فهو يستخدم الجزء الأول فقط text/csv
(الخطأ). كإجراء أمني (لأننا نقبل أي ملف يتم تحميله بواسطة المستخدم) ، يتم تطهير mimetype قبل إرساله إلى المتصفح مما يؤدي إلى تحويل text/csv
إلى text/plain
. يرى NGINX بعد ذلك محتوى رأس text/plain
، والذي تم تكوينه للضغط قبل إرساله إلى العميل لحفظ النطاق الترددي (التهيئة الخاطئة).
باهر! اسمحوا لي أن أعرف إذا (وكيف) يمكنني المساعدة.
لسوء الحظ ، لم تنجح إعادة تكوين NGINX في حل المشكلة ، لذلك سيستغرق الأمر وقتًا أطول قليلاً لإصلاحها ، حيث نحتاج أيضًا إلى إصلاح الخطأ في التطبيق. أنا