You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've recently tried to use in2csv in a GIS dBase IV dbf file and was unable to do so until I amended (in a very ugly way) in2csv.py to get an additional --encoding-dbf command-line argument (which mirrors --encoding-xls in passing an encoding argument to agata.Table).
Since probably this is not a very promising solution (I imagine in the future an --encoding-xxx for each possible data file), wouldn't it be better to just have an --input-encoding parameter? Would that break anything else?
The text was updated successfully, but these errors were encountered:
I've recently tried to use in2csv in a GIS dBase IV dbf file and was unable to do so until I amended (in a very ugly way) in2csv.py to get an additional --encoding-dbf command-line argument (which mirrors --encoding-xls in passing an encoding argument to agata.Table).
Since probably this is not a very promising solution (I imagine in the future an --encoding-xxx for each possible data file), wouldn't it be better to just have an --input-encoding parameter? Would that break anything else?
The text was updated successfully, but these errors were encountered: