stream=True એ પ્રોક્સી થ્રુ આવતા રિસ્પોન્સનું બોડી સંપૂર્ણ ડાઉનલોડ થાય તે પહેલાં પ્રોસેસિંગ શરૂ કરવા દે છે. CSV માટે csv.reader ને ટેક્સ્ટ-લાઇન ઇટરેટર આપો, જેથી અવતરણ ચિહ્નો વચ્ચેના ડેલિમિટર અને બહુ-લાઇન રેકોર્ડ CSV ડેટા તરીકે જ રહે.

અર્ધવિરામ વાપરતી ઉદાહરણરૂપ UTF-8 ફાઇલ માટે:

import csv
import requests

routes = {'https': 'http://proxy.example:8080'}
with requests.get(
    'https://data.example/observations.csv',
    proxies=routes,
    stream=True,
    timeout=(5, 30),
) as response:
    response.raise_for_status()
    response.encoding = 'utf-8'
    lines = (
        line + '\n'
        for line in response.iter_lines(
            chunk_size=65536, decode_unicode=True)
    )
    for record in csv.reader(lines, delimiter=';'):
        if record and record[0] == 'wanted':
            print(record)
            break

ફાઇલનું વાસ્તવિક એન્કોડિંગ અને ડાયલેક્ટ પસંદ કરો. માન્ય જાહેર-પ્રોક્સી માર્ગ પર જાહેર CSV ડાઉનલોડ માટે, HTTP પ્રોક્સી સૂચિ routes URL માટે ઉમેદવારો આપે છે. આ આવૃત્તિ ભૌતિક લાઇન-અંતોને LF માં સામાન્ય કરે છે: iter_lines તેમને દૂર કરે છે, અને જનરેટર CSV પાર્સર માટે નવી લાઇન પાછી ઉમેરે છે. જ્યારે અવતરણ ચિહ્નો વચ્ચેનું ક્ષેત્ર બીજી ભૌતિક લાઇન પર ચાલુ રહે ત્યારે તે મહત્ત્વનું છે.

એમ્બેડ થયેલા CRLF અક્ષરોના બાઇટ-ચોક્કસ સંરક્ષણની જરૂર હોય તેવા વર્કફ્લો માટે, તે લાઇન-અંતો જાળવતી સ્ટ્રીમિંગ ટેક્સ્ટ-રેપર ગોઠવણી વાપરો. ઉદાહરણનું જાણી જોઈને કરેલું સામાન્યીકરણ રેકોર્ડ-લક્ષી પ્રોસેસિંગ માટે યોગ્ય છે જ્યાં LF ઇચ્છિત રજૂઆત છે.

એક રિસ્પોન્સ, ઘણા વાંચન

ઇટરેટર એક HTTP રિસ્પોન્સમાંથી ટુકડાઓ વાપરે છે. તે દરેક લાઇન માટે નવી વિનંતી મોકલતું નથી. HTTP Range વિનંતીઓ અલગ પદ્ધતિ છે અને તે કુદરતી રીતે CSV રેકોર્ડની સીમાઓ ઓળખતી નથી.

response.text કૉલ કરવો અથવા બધી પંક્તિઓને સૂચિમાં એકત્ર કરવી એ આખું સામગ્રી પાછું મેમરીમાં લાવશે. સ્ટ્રીમિંગને હજી પણ ટ્રાન્સપોર્ટ બફર અને વર્તમાન રેકોર્ડ માટે જગ્યા જોઈએ, જે પોતે મોટું ક્ષેત્ર ધરાવી શકે છે.

રિસ્પોન્સ સંદર્ભ લૂપમાંથી બહાર નીકળતી વખતે બોડી બંધ કરે છે, વહેલા મેળ સહિત. વાંચન સમયમર્યાદા આવતા ડેટાની રાહને મર્યાદિત કરે છે, મોટી ફાઇલ ટ્રાન્સફરના કુલ આયુષ્યને નહીં.

સંબંધિત લેખો