Risposte:
Hai ragione, vedi 3.1.3. Stringhe Unicode .
È stata la sintassi da Python 2.0.
Python 3 li ha resi ridondanti, poiché il tipo di stringa predefinito è Unicode. Le versioni da 3.0 a 3.2 le hanno rimosse, ma sono state aggiunte nuovamente in 3.3+ per la compatibilità con Python 2 per favorire la transizione da 2 a 3.
ur"string"
) È valida in Python 2, ma purtroppo non è una sintassi non valida in Python 3.
L'U in u'Some String'
significa che la tua stringa è una stringa Unicode .
Q: Ho una fretta terribile e sono atterrato qui da Ricerca Google. Sto cercando di scrivere questi dati in un file, sto ricevendo un errore e ho bisogno della soluzione morta più semplice, probabilmente imperfetta, in questo secondo.
A: Dovresti davvero leggere il minimo assoluto di Joel. Ogni saggio di sviluppatori di software assolutamente, positivamente, deve conoscere il set di caratteri Unicode e set di caratteri (senza scuse!) .
Q: sry no time code pls
Una multa. prova str('Some String')
o 'Some String'.encode('ascii', 'ignore')
. Ma dovresti davvero leggere alcune delle risposte e discussioni sul Conversione di una stringa Unicode e su questo eccellente, eccellente, primer sulla codifica dei caratteri.
La mia ipotesi è che indica "Unicode", è corretto?
Sì.
In tal caso, da quando è disponibile?
Python 2.x.
In Python 3.x le stringhe usano Unicode per impostazione predefinita e non è necessario il u
prefisso. Nota: in Python 3.0-3.2, u è un errore di sintassi. In Python 3.3+ è di nuovo legale rendere più semplice la scrittura di app compatibili 2/3.
u
prefisso.
six.text_type()
ovunque per il numero (si spera minuscolo) delle persone che usano ancora 3. [012] - almeno le informazioni sono lì in modo che tu possa scegliere.
Sono venuto qui perché avevo la sindrome di char-char sulla mia requests
uscita. Pensavo response.text
che mi avrebbe dato una stringa decodificata correttamente, ma nell'output ho trovato divertenti doppi caratteri in cui le umlaut tedesche avrebbero dovuto essere.
Si scopre che response.encoding
era vuoto in qualche modo e quindi response
non sapeva come decodificare correttamente il contenuto e lo trattava semplicemente come ASCII (immagino).
La mia soluzione era quella di ottenere i byte grezzi con 'response.content' e applicarli manualmente decode('utf_8')
. Il risultato è stato Schöne Umlaute.
Decodificato correttamente
pelliccia
vs. impropriamente decodificato
für
Tutte le stringhe destinate agli umani dovrebbero usare "".
Ho scoperto che la seguente mentalità aiuta molto quando si tratta di stringhe Python: tutte le stringhe manifest di Python dovrebbero usare la u""
sintassi. La ""
sintassi è solo per array di byte.
Prima che inizi il bashing, lasciami spiegare. La maggior parte dei programmi Python inizia con l'utilizzo ""
di stringhe. Ma poi devono supportare la documentazione da Internet, quindi iniziano a usare "".decode
e all'improvviso ottengono eccezioni ovunque sulla decodifica di questo e quello - tutto a causa dell'uso di ""
stringhe. In questo caso, Unicode si comporta come un virus e causerà il caos.
Ma, se segui la mia regola, non avrai questa infezione (perché sarai già infetto).
bash -c "echo Shouldn\\'t you use b\\\"...\\\" for byte arrays?"
u""
.
È Unicode.
Basta inserire la variabile tra str()
e funzionerà bene.
Ma nel caso in cui tu abbia due elenchi come il seguente:
a = ['co32','co36']
b = [u'co32',u'co36']
Se controlli set(a)==set(b)
, verrà visualizzato come False, ma se fai come segue:
b = str(b)
set(a)==set(b)
Ora, il risultato sarà True.
str()
o u'€'.encode()
) senza passare una codifica. Se la stringa contiene non ASCII, l'utente riceverà un UnicodeEncodeException.
b = str(b)
fornisce solo la stringa repr()
dell'elenco, ad es b = "[u'co32', u'co36']"
. Quindiset(a)==set(b) = False