خطاهای رمزگذاری نویسه در jsoup پس از دانلود از طریق پروکسی

صفحه از طریق پروکسی بارگذاری می‌شود، اما حروف دارای اعراب به‌هم‌ریخته برمی‌گردند. پیش از تغییر پروکسی، نخستین جایی را بیابید که بایت‌های پاسخ به Java String تبدیل می‌شوند. یک InputStreamReader بدون charset صریح می‌تواند این تصمیم را پیش از آنکه jsoup سند را ببیند بگیرد.

وقتی jsoup واکشی را بر عهده دارد، پاسخ را تا زمان تجزیه یکپارچه نگه دارید:

Connection.Response response = Jsoup
    .connect("https://www.example.com/catalog")
    .proxy("proxy.example", 8080)
    .execute();
Document page = response.parse();

API پاسخ اطلاعات charset برگرفته از Content-Type را آشکار می‌کند. همچنین می‌تواند بازنویسی صریح charset را بپذیرد، زمانی که احراز کرده‌اید اعلام سرور نادرست است. نشانی پروکسی به‌تنهایی نمی‌گوید سند از کدام رمزگذاری نویسه استفاده می‌کند. اگر به مقایسه مجاز یک صفحه عمومی بدون حساب پروکسی نیاز دارید، میزبان و درگاه HTTP مثال را با نامزدی از فهرست پروکسی HTTP جایگزین کنید و همان بررسی‌های رمزگذاری را نگه دارید.

اگر کارخواه HTTP دیگری یک InputStream فراهم کند، نسخه تجزیه جریان jsoup یک نام charset و یک URI پایه می‌پذیرد. charset تهی رفتار شناسایی و جایگزین مستندشده را ممکن می‌کند؛ charset شناخته‌شده و درست HTTP باید آگاهانه منتقل شود. URI پایه زمینه را برای پیوندهای نسبی فراهم می‌کند.

پس از آنکه بایت‌ها نادرست رمزگشایی شدند، تجزیه String حاصل با charset دیگر متن اصلی را بازیابی نمی‌کند. به بایت‌ها و فراداده‌های پاسخ بازگردید. همچنین دریافت‌شده را مقایسه کنید: صفحه ورود یا رد پروکسی می‌تواند سندی کاملاً متفاوت از صفحه درخواستی باشد، نه شکست رمزگشایی در آن.