2015-12-08 11 views
8

Quindi ho un Raspberry Pi su cui è in esecuzione Debian e lo WebIOPi system. Il demone gira bene quando lo avvio usando un comando di avvio standard '$ sudo /etc/init.d/webiopi start' ma l'avvio automatico non funziona' $ sudo update-rc.d webiopi defaults '.Problemi di codifica di Python sullo script di avvio nel debian Raspberry Pi

Il log suggerisce che si tratta di un problema di codifica in Python, la mia ipotesi python utilizza ASCII ma il file di script utilizza utf8.

Perché funziona normalmente ma non in modalità di avvio automatico e quale è un buon modo per risolvere il problema?

+1

Qual è il messaggio di errore esatto ? – flo

+0

@flo Purtroppo non ho accesso costante al Pi ma era lungo questa linea. Il codec 'ascii' non può codificare il carattere **** nella posizione **: ordinale non nel range (128) ' –

risposta

2

Per confermare il registro e il sospetto, si tratta di un problema di codifica (byte più probabile che stringa). Anche se imposti la codifica del tuo file su UTF-8 con # -*- coding: utf-8 -*-, puoi ancora riscontrare problemi con il testo che è stato modificato da un modulo all'altro.

Le stringhe non sono realmente stringhe, ma rappresentazioni di byte in un ordine particolare. UTF-8 prevede la codifica di molti più caratteri che ASCII può gestire, quindi se provi a convertire un carattere che esiste in una stringa codificata UTF-8 in una stringa codificata ASCII, otterrai un errore perché non esiste alcuna codifica di questo tipo .

Non riesco a dare una risposta molto migliore senza ulteriori informazioni, come codice e/o origine dati.

Leggendo https://docs.python.org/2/howto/unicode.html#the-unicode-type impariamo studiando il seguente esempio (s):

>>> unicode('abcdef') 
u'abcdef' 
>>> s = unicode('abcdef') 
>>> type(s) 
<type 'unicode'> 
>>> unicode('abcdef' + chr(255))  
Traceback (most recent call last): 
... 
UnicodeDecodeError: 'ascii' codec can't decode byte 0xff in position 6: 
ordinal not in range(128) 

La documentazione menziona anche che è possibile scegliere di gestire queste eccezioni sia la sostituzione o ignorarli, in questo modo:

>>> unicode('\x80abc', errors='strict')  
Traceback (most recent call last): 
    ... 
UnicodeDecodeError: 'ascii' codec can't decode byte 0x80 in position 0: 
ordinal not in range(128) 
>>> unicode('\x80abc', errors='replace') 
u'\ufffdabc' 
>>> unicode('\x80abc', errors='ignore') 
u'abc' 

NOTA 1: In Python 3 le cose sono cambiate. per la scrittura del codice che è compatibile con Python 3, vi consiglio il seguente lettura:

https://docs.python.org/3.0/whatsnew/3.0.html#text-vs-data-instead-of-unicode-vs-8-bit

NOTA 2: E 'anche interessante notare che se il problema di codifica viene rilevato durante il tentativo di visualizzare la stringa sulla console quindi, python ha uno switch -u che può essere utilizzato in determinate situazioni, ad esempio quando si sta servendo un file binario tramite uno script CGI, che disattiverà il buffering delle stringhe, ma che apre un'altra lattina di worm. Ma, nondimeno, imitando questo comportamento senza invocare -u:

>>> print 'test' 
'test' 
>>> import os 
>>> import sys 
>>> sys.stdout = os.fdopen(sys.stdout.fileno(), 'w', 0) 
>>> print 'test' 
test 
0

Questo dipende veramente su quel programma.

Tuttavia, se esiste una differenza tra l'avvio manuale e come parte dell'avvio del sistema, la differenza principale deve essere nelle variabili di ambiente . Questo tipico per es. inittab.

due opzioni - sia il vostro impostazioni internazionali non è configurato, o uno script finisce con diversa versione di pitone.

Per prima, considerare l'aggiunta di LANG (preciso) o se necessario LC_ALL (un martello) a questo script o all'ambiente globale per tutte le attività di avvio.

Si può provare manualmente confrontando queste due invocazioni:

sudo LC_ALL=en_US.UTF-8 /etc/init.d/webiopi start 

vs.

sudo LC_ALL=C /etc/init.d/webiopi start 

Per quest'ultimo provare a cambiare PATH per includere solo alcuni dei /bin:/usr/bin:/usr/local/bin