基于目标网站开发翻译API：urllib请求返回内容与浏览器不一致问题

Hey, let's break down why your Python urllib request is returning different translation results than the browser—this is a super common issue when reverse-engineering API calls, so let's walk through the likely fixes:

1. Double-check your salt/sigh generation logic #

It's easy to miss tiny details when replicating JS encryption logic. Ask yourself:

• Did you capture the full signing formula from the JS? Many sites combine the input text, salt, and a hidden fixed key (hardcoded in the JS) before hashing (often MD5 or SHA-1). For example, if the JS does something like md5(input + salt + "secret_key_123"), your Python code must replicate that exact string concatenation and encoding (stick to utf-8 consistently—JS uses UTF-16 in some edge cases, but most modern sites default to UTF-8).
• Is your salt generation matching the JS? Often salt is a timestamp (like Date.now() in JS, which is milliseconds since epoch), but some sites add a random suffix or use a different time offset.
• Are you matching the hash output format? Some sites expect uppercase hex strings, others lowercase—make sure your Python hash result matches what the browser sends.

Here's a quick example of replicating a typical salt/sigh setup:

import hashlib
import time

def generate_sign_params(input_text):
    # Replicate JS's Date.now() for salt
    salt = str(int(time.time() * 1000))
    # Replace this with the fixed key you found in the JS source
    fixed_secret = "your_extracted_secret_key"
    # Build the exact string the JS hashes
    sign_input = f"{input_text}{salt}{fixed_secret}"
    # Generate the sigh (match the hash algorithm used in JS)
    sigh = hashlib.md5(sign_input.encode("utf-8")).hexdigest()
    return salt, sigh

2. Match all request headers exactly #

Browsers send a ton of headers that many sites use for validation—urllib uses minimal default headers, which can trigger different responses. Make sure you include:

• User-Agent: Copy the exact string from your browser's request (e.g., Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36...).
• Referer: Set this to the URL of the translation page (sites often check this to prevent hotlinking).
• Cookie: If the site sets cookies when you load the page, include them in your request (you can copy them from the browser's Network tab).
• Content-Type: For POST requests, this is usually application/x-www-form-urlencoded; charset=UTF-8 or application/json—match what the browser sends.

3. Verify all request parameters #

It's not just salt and sigh—double-check every parameter in the browser's request:

• Language codes (from, to): Are you using the exact values the browser sends (e.g., en vs eng, zh-CN vs zh)?
• Client identifier (client): Many translation APIs include a client parameter (like webapp or fanyideskweb) that changes how the server processes the request.
• Timestamp (ts): Some sites include a timestamp parameter tied to the salt—make sure this matches if present.

4. Debug with request comparison #

The best way to spot differences is to compare your Python request to the browser's request:

1. In Chrome's Network tab, right-click the translation request and select Copy > Copy as cURL.
2. Convert that cURL command to Python urllib code manually (this helps you understand each part better than auto-converters).
3. Use a proxy tool like Charles or Fiddler to capture your Python request, then compare it side-by-side with the browser's request—look for differences in parameters, headers, or encoding.

5. Watch for dynamic JS logic #

If the site uses obfuscated or dynamically loaded JS (common with webpack/bundled code), your initial analysis might have missed parts of the signing logic:

• Use Chrome's debugger to set a breakpoint where the salt/sigh is generated. Step through the code line by line to see if there are hidden steps (like modifying the input text before signing, or pulling a dynamic key from another part of the page).
• Some sites rotate their secret keys periodically—make sure you're using the current key from the live JS, not an old one from a cached page.

The key takeaway here is that every part of your request must mirror the browser's request exactly. Even a tiny difference (like a missing header, wrong encoding, or off-by-one in the salt) can make the server return a different result.

内容的提问来源于stack exchange，提问作者Rowan