As reported here:
http://stackoverflow.com/questions/6588068/which-encoding-opens-csv-file...
There is no way to open a UTF-8 csv file correctly with Excel on UNIX and Windows.
Is there any way to provide an option in the display? I found a workaround that I implemented in several projects already, but an option itself would be great!
Workaround code - in views_data_export_plugin_display_export.inc:
protected function outputfile_create() {
$dir = 'temporary://views_plugin_display';
// Make sure the directory exists first.
if (!file_prepare_directory($dir, FILE_CREATE_DIRECTORY | FILE_MODIFY_PERMISSIONS)) {
$this->abort_export(t('Could not create temporary directory for result export (@dir). Check permissions.', array ('@dir' => $dir)));
}
$path = drupal_tempnam($dir, 'views_data_export');
//----hack - add UTF-8 BOM for MS Excel use----
file_put_contents($path, chr(0xEF).chr(0xBB).chr(0xBF));
//--------------------------------------------------------------
// Save the file into the DB.
$file = $this->file_save_file($path);
return $file->fid;
}
Comments
Comment #1
dropert commentedI had the exact same problem. Unfortunately, this hack didn't work out for me because of code changes in the version i recently downloaded (7.x-3.0-beta6). I tried to adjust the code, adding the BOM in front of the CSV string in the file_put_contents method. I tried several other solutions adding the BOM in front of the header in the template file but again with no success. My solution was (i had german characters in my csv file) selecting the "ASCII "encoding" in the display and changing the charset of the iconv function (views_data_export.theme.inc) to "ISO-8859-1". It does the job but why doesn't this module use php's own fputcsv function instead?
Comment #2
somersoft commentedHere is a patch file for 7.x-3.0-beta6 with the adding of the BOM conditional and also in a different place as I found this to work better.
Comment #3
somersoft commentedHere is the version of the patch file with the correct line endings.
Comment #5
somersoft commentedChanging the Version from 7.x-3.x-dev to 7.x-3.0-beta6 so that the automatic test will pass as the test are not a part of that release and the patch file does not patch the test files.
Comment #6
somersoft commented#3: views_data_export-set_utf8_bom-1701018-3.patch queued for re-testing.
Comment #8
bkonetzny commentedApplied the patch from #3 to my local 7.x-3.0-beta6 installation and export works now as expected on windows.
Comment #9
killua99 commentedNeeds reroll ... some code change.
Comment #10
jjcarrionApplied the patch from #3 and works ok on windows.
Comment #11
jide commentedRTBCing.
Comment #12
bkonetzny commentedRe-rolled patch against latest dev.
Comment #14
stockliasteroid commentedThis fix works, but this patch won't work if it's a batched export, which is going to be common with any large files. That's because views_data_export_plugin_display_export calls the render_header, render_body, and render_footer methods directly in a batch run, and skips the render() call where this change resides. My fix was to move this code into render_header() instead, since that gets called in both cases.
Comment #15
grimreaperHello,
Patch in comment #14 solved the problem for me.
Thank you very much.
Comment #16
alan d. commentedComment #18
nicolas bouteille commentedMy client reported encrypted characters on Windows with a CSV file. Patch fixes the issue thanks!
Comment #19
steven jones commentedTests are failing with this patch, sorry!
Comment #20
lazzyvn commentedi confirme patch #14 works fine
But i think we have to add option UTF8 with BOM in config
Comment #21
AhmadZain commentedAfter searching I managed to solve this issue inside the template it self.
Comment #22
colepacak commented#21 worked for me. Thanks, AhmadZain.
Comment #23
circuscowboy commentedThe template solution is great because I don't have to even wait for a commit or deal with a patch. It works as advertise and I would recommend that this gets added to the module. I would also argue that this is more of a bug then a feature. Thanks for your solution AhmadZain
Comment #26
dasha_v commentedRe-formatting patch #21 for testing.
Comment #27
davidhernandezComment #30
dasha_v commentedUpdated patch.
Made BOM optional and configurable per view.
By default it is disabled, this should resolve issue with existing tests.
Added new test for this BOM parameter.
Comment #31
weri commentedI applied and tested the patch #30. It works as expected but I've not done a code review (yet).
Comment #32
amme commentedConfirm patch #30 works
Comment #33
nwom commented#30 applied cleanly and worked as expected. Thank you. I think we can mark this as RTBC.
Comment #34
AhmadZain commentedHi sorry for being away
thanks @colepacak and @circuscowboy actually I am still confirming like you guys but I can not get the main reason that makes the patch fail to pass the test, so I reformated the patch and hope that can be confirmed from all sides.
#1701018: CSV export UTF-8 & windows - BOM Ref. About BOM fix in CSV views export.
@dasha_v I removed your patches from this one as you mentioned it in a separate comment and thanks for your support.
Best
Comment #37
nwom commentedComment #38
AhmadZain commentedHI @NWOM
can you just add a comment to this to make it clear ? is it the testing is not covered or what ?
Thanks in advance.
Zain
Comment #39
nwom commented@AhmadZain Hello, sorry about not commenting. I had meant to set it to "Needs Review", since a new patch was added that had not been reviewed yet. I was just trying to help with the normal patch submission workflow. Normally every patch that gets added needs to be tested by others before being set to "Reviewed & tested by the community", however I instead chose the wrong status as well :P
Comment #40
AhmadZain commented@NWOM no worries. ;)
thanks for your replay
Comment #41
AhmadZain commentedHi All,
Is there any person is looking after this project ?
Best
Comment #42
rosk0Patch from #30 applies cleanly and allows to fix an issue in proper way.
I would not recommend to go with approaches form other patches because they are not configurable and have some strange logic.
Comment #43
burshyn commentedPatch from #30 work for me! Thanks dasha_v!
Comment #44
hgoto commentedI also tested the patch #30 and it works well.
I'm confused. I don't understand why the patch #34 was proposed after the patch #30. The patch #30 has configuration and tests and looks better for me...
Anyway, thank you. +1 for RTBC :)
Comment #45
sangeetharaog commentedI tried patch #30 but it did not work for me. As analyzing the patch I found another way to print
print "\xEF\xBB\xBF";.This works for me.
Comment #46
sangeetharaog commentedComment #47
aschiwi commentedAdding my experience: the patch in #30 still works for me, thank you!
Comment #48
steven jones commentedSorry for the lack of attention to your issue, please accept my apologies.
Drupal 7 is going to be end-of-life'd by the community in approximately 1 month.
As such, I am closing all non-critical looking, non-PHP compatibility issues for Views Data Export to tidy up the issue queues and reduce the noise. You can read about this on #3492246: Close down Drupal 7 issues.
If you feel like this issue has been closed by mistake, please do comment about re-opening it.
If you feel like the ticket is still relevant for the 8.x-1.x version of the module, the please search for a duplicate issue first, and if there really isn't one (and you've looked properly) then change the version on the ticket and re-open.
Thanks to everyone involved in this issue: for reporting it, and moving it along, it is truly appreciated and the Drupal community wouldn't be what it is today without your involvement and effort, so I'm sorry that we couldn't get this issue resolved. Hopefully we'll work together in a future issue though, and get that one resolved :)