كجزء من Google Cloud ، تقدم Google واجهة برمجة تطبيقات Google للترجمة مع بنية تكلفة قائمة على الاستخدام. هناك أيضًا واجهة برمجة تطبيقات غير موثقة يمكن استخدامها بدون مفتاح ، ولكنها ترفض العمل بعد بضع طلبات فقط. عند استخدام وظيفة ترجمة مواقع الويب في Google Chrome ، يُلاحظ أنه يمكن ترجمة الصفحات بجودة عالية جدًا دون أي قيود ملحوظة.
يبدو أن نموذج nmt المتقدم مستخدم بالفعل هنا. ولكن ما هي واجهة برمجة التطبيقات التي يستخدمها Google Chrome داخليًا لترجمة المحتوى وهل يمكن أيضًا معالجة واجهة برمجة التطبيقات هذه مباشرةً - حتى على جانب الخادم؟ لتحليل حركة مرور الشبكة ، يوصى باستخدام أدوات مثل Wireshark أو Telerik Fiddler ، والتي يمكنها أيضًا تحليل حركة المرور المشفرة. لكن Chrome يسلم الطلبات التي يرسلها لترجمة الصفحة مجانًا: يمكن عرضها بسهولة باستخدام Chrome DevTools:
إذا أجريت ترجمة ، فقم بالقبض على طلب POST المهم إلى https://translate.googleapis.com عبر "نسخ> نسخ كـ cURL (bash)" وتنفيذه بأداة مثل Postman ، على سبيل المثال ، يمكنك إرسال الطلب مرة أخرى دون مشاكل:
معنى معلمات URL واضح أيضًا إلى حد كبير:
| مفتاح | قيمة المثال | المعنى |
| anno | 3 | وضع التعليقات التوضيحية (يؤثر على تنسيق الإرجاع) |
| عميل | te_lib | معلومات العميل (تختلف ، القيمة هي "webapp" عبر واجهة الويب الخاصة بخدمة Google Translate ، ولها تأثير على تنسيق الإرجاع وتحديد السعر) |
| شكل | لغة البرمجة | تنسيق السلسلة (مهم لترجمة علامات HTML) |
| الخامس | 1.0 | رقم إصدار ترجمة Google |
| مفتاح | AIzaSyBOti4mM-6x9WDnZIjIeyEU21OpBXqWBgw | مفتاح API (انظر أدناه) |
| logld | vTE_20200210_00 | نسخة البروتوكول |
| sl | دي | لغة المصدر |
| TL | en | لغة الهدف |
| ص | nmt | نموذج ML |
| ح | 1 | غير معروف |
| ريال سعودى | 1 | غير معروف |
| tk | 709408.812158 | رمز (انظر أدناه) |
| موضه | 1 | غير معروف |
يتم أيضًا تعيين بعض رؤوس الطلبات - ولكن يمكن تجاهلها في الغالب. بعد إلغاء تحديد جميع الرؤوس يدويًا ، بما في ذلك تلك الخاصة بوكيل المستخدم ، يتم اكتشاف مشكلة تشفير عند إدخال أحرف خاصة (هنا عند ترجمة " Hello World "):
إذا قمت بإعادة تنشيط وكيل المستخدم (والذي لا يسبب أي ضرر بشكل عام) ، فإن واجهة برمجة التطبيقات تقدم رموز UTF-8:
هل نحن موجودون بالفعل وهل لدينا جميع المعلومات لاستخدام واجهة برمجة التطبيقات هذه خارج Google Chrome؟ إذا قمت بتغيير السلسلة المراد ترجمتها (حقل البيانات q لطلب POST) من ، على سبيل المثال ، "Hello world" إلى "Hello world ! "، وصلتنا رسالة خطأ:
نترجم الآن هذا المعدل مرة أخرى داخل Google Chrome باستخدام وظيفة ترجمة موقع الويب ونجد أنه بالإضافة إلى المعلمة q ، تم تغيير المعلمة tk أيضًا (ظلت جميع المعلمات الأخرى كما هي):
يبدو أنه رمز يعتمد على السلسلة ، وليس من السهل رؤية هيكلها. عند بدء ترجمة موقع الويب ، يتم تحميل الملفات التالية:
- ملف CSS واحد: translateelement.css
- 4 رسومات: translate_24dp.png (2x)، gen204 (2x)
- 2 ملف JS: main_de.js ، element_main.js
يتم تشويش ملفي JavaScript وتصغيرهما. تساعدنا أدوات مثل JS Nice و de4js الآن في جعل هذه الملفات أكثر قابلية للقراءة. من أجل تصحيحها مباشرة ، نوصي بـ Chrome Extension Requestly ، الذي ينفق الملفات البعيدة محليًا أثناء التنقل:
الآن يمكننا تصحيح الكود (يجب تنشيط CORS أولاً على الخادم المحلي). يبدو أن قسم الكود ذي الصلة لإنشاء الرمز المميز مخفي في ملف element_main.js في هذا القسم:
b7739bf50b2edcf636c43a8f8910def9
هنا يتم تجزئة النص بمساعدة بعض التحولات الطفيفة . لكن لسوء الحظ ما زلنا نفتقد قطعة واحدة من اللغز: بالإضافة إلى الحجة a (وهو النص المراد ترجمته) ، يتم تمرير وسيطة أخرى b إلى الوظيفة Bp () - نوع من البذرة التي يبدو أنها تتغير من وقت لآخر وتتضمن أيضًا يتدفق إلى التجزئة. لكن من أين أتى؟ إذا انتقلنا إلى استدعاء وظيفة Bp () ، فسنجد قسم الكود التالي:
b7739bf50b2edcf636c43a8f8910def9
يتم الإعلان عن الوظيفة Hq مسبقًا على النحو التالي:
b7739bf50b2edcf636c43a8f8910def9
هنا ترك Deobfuscater بعض القمامة. بعد أن استبدلنا String.fromCharCode ('...') بسلاسل الأحرف ذات الصلة ، قم بإزالة a () القديمة وقم بتجميع استدعاءات الوظائف [c ()، c ()] ، تكون النتيجة هي:
b7739bf50b2edcf636c43a8f8910def9
أو حتى أسهل:
b7739bf50b2edcf636c43a8f8910def9
تم تعريف الوظيفة yq مسبقًا على أنها:
b7739bf50b2edcf636c43a8f8910def9
يبدو أن البذرة موجودة في الكائن العالمي google.translate._const._ctkk ، والذي يتوفر في وقت التشغيل. لكن أين تم تعيينه؟ في الملف الآخر ، وهو ملف JS الذي تم تحميله مسبقًا main_de.js ، على الأقل يكون متاحًا أيضًا في البداية. نضيف ما يلي في البداية:
b7739bf50b2edcf636c43a8f8910def9
في وحدة التحكم ، نحصل بالفعل على البذور الحالية:
هذا يترك Google Chrome نفسه ، والذي يبدو أنه يوفر البذور كخيار أخير. لحسن الحظ ، فإن كود المصدر الخاص به (Chromium ، بما في ذلك مكون الترجمة) مفتوح المصدر وبالتالي متاح للجمهور. نقوم بسحب المستودع محليًا والعثور على استدعاء وظيفة TranslateScript :: GetTranslateScriptURL في ملف translate_script.cc في مجلد المكونات / translate / core / browser:
b7739bf50b2edcf636c43a8f8910def9
المتغير الذي يحتوي على عنوان URL محدد بدقة في نفس الملف:
b7739bf50b2edcf636c43a8f8910def9
إذا قمنا الآن بفحص ملف element.js عن كثب (بعد فك التلاعب مرة أخرى) ، فسنجد الإدخال الثابت c._ctkk - يتم أيضًا تعيين كائن google.translate وفقًا لذلك ويتم تشغيل تحميل جميع الأصول ذات الصلة (التي اكتشفناها سابقًا):
b7739bf50b2edcf636c43a8f8910def9
الآن يبقى مفتاح المعلمة قيد الدراسة (مع القيمة AIzaSyBOti4mM-6x9WDnZIjIeyEU21OpBXqWBgw). يبدو أن هذا هو مفتاح واجهة برمجة تطبيقات عام للمتصفح (والذي يمكن العثور عليه أيضًا في بعض نتائج Google ). تم تعيينه في Chromium في ملف translate_url_util.cc في مكونات المجلد / ترجمة / كور / متصفح:
b7739bf50b2edcf636c43a8f8910def9
يتم إنشاء المفتاح في google_apis / google_api_keys.cc من قيمة وهمية:
b7739bf50b2edcf636c43a8f8910def9
ومع ذلك ، يُظهر الاختبار أن استدعاءات API تعمل بنفس الطريقة بدون معلمة المفتاح هذه. إذا قمت بتجربة API ، فستستعيد رمز الحالة 200 مرة أخرى إذا نجحت. إذا وصلت بعد ذلك إلى حد ، فستحصل على رمز الحالة 411 مرة أخرى بالرسالة " تتطلب طلبات POST رأسًا بطول المحتوى ". لذلك يُنصح بتضمين هذا العنوان (الذي يتم تعيينه تلقائيًا كرأس مؤقت في Postman).
يعتبر تنسيق الإرجاع للسلاسل المترجمة غير معتاد عند وجود عدة جمل في طلب واحد. يتم تضمين الجمل الفردية بواسطة علامات i- / b-HTML:
أيضًا ، لا يرسل Google Chrome شفرة HTML بالكامل إلى واجهة برمجة التطبيقات ، ولكنه يحفظ قيم السمات مثل href في الطلب (وبدلاً من ذلك يعيّن الفهارس بحيث يمكن تعيين العلامات لاحقًا من جانب العميل):
إذا قمت بتغيير قيمة عميل مفتاح POST من te_lib (Google Chrome) على webapp ( موقع ترجمة Google ) ، تحصل على السلسلة النهائية المترجمة:
تكمن المشكلة في أنه من المرجح أن تتعرض لحد من المعدل أكثر من ذلك عبر te_lib (للمقارنة: مع تطبيق الويب يتم الوصول إلى هذا بعد 40000 حرف ، مع te_lib لا يوجد حد للمعدل). لذلك نحن بحاجة إلى إلقاء نظرة فاحصة على كيفية تحليل Chrome للنتيجة. سنجده هنا في element_main.js:
b7739bf50b2edcf636c43a8f8910def9
إذا قمت بإرسال كود HTML بأكمله إلى API ، فإنه يترك السمات في الاستجابة المترجمة. لذلك لا يتعين علينا تقليد سلوك التحليل بأكمله ، ولكن فقط استخراج الجملة النهائية المترجمة من الاستجابة. للقيام بذلك ، نقوم بإنشاء محلل صغير لعلامات HTML يتجاهل العلامات <i> الخارجية بما في ذلك محتواها ويزيل العلامات <b> الخارجية. بهذه المعرفة (بعد تثبيت التبعيات مع الملحن يتطلب fzaninotto / faker vielhuber / stringhelper ) يمكننا الآن إنشاء نسخة من جانب الخادم من واجهة برمجة تطبيقات الترجمة:
b7739bf50b2edcf636c43a8f8910def9
فيما يلي نتائج اختبار أولي تم إجراؤه على خمسة أنظمة مختلفة ذات نطاقات ترددية وعناوين IP مختلفة:
| حرف | أحرف لكل طلب | المدة الزمنية | نسبة الخطأ | التكلفة عبر API الرسمية |
| 13.064.662 | ~250 | 03: 36: 17 ساعة | 0% | 237,78€ |
| 24.530.510 | ~250 | 11:09:13 | 0% | 446,46€ |
| 49.060.211 | ~250 | 20: 39: 10 ساعات | 0% | 892,90€ |
| 99.074.487 | ~1000 | 61:24: 37 ساعة | 0% | 1803,16€ |
| 99.072.896 | ~1000 | 62:22: 20 ساعة | 0% | 1803,13€ |
| 284.802.766 | ~ قطر 550 | Σ159: 11: 37 ساعة | 0% | Σ 5183.41 يورو |
ملاحظة: تم كتابة منشور المدونة هذا الذي يتضمن جميع البرامج النصية لأغراض الاختبار فقط. لا تستخدم البرامج النصية لاستخدامها في الإنتاج، بدلا من ذلك العمل مع الرسمي API ترجمة جوجل .