A script saved from SMSS into a .sql file is saved as UTF-16 (unicode) encoding by default. This is a similar issue to the one raised in another feedback entry where the output to CSV is saved as UTF-16. This behavior of SMSS is a departure from the way Query Analyzer (which I used for the last four years) handled these files and it has taken me quite some time to track down the reason things suddenly stopped working correctly.
Many version control systems (specifically CVS, SubVersion, SVN, and Perforce, which I have used) do not properly handle this encoding. This means that though the file looks fine on the original engineer's computer none of the other collaborators on the project can use the code.
The danger here is that the files appear fine on the original machine, but nowhere else. If anything happens to that machine then the code is lost. This problem completely undermines the purpose of source control systems and collaborative development.
I understand that it is possible to change the encoding at the time the file is saved. That option is not obvious and not well-documented. I have used SMSS for six months and I just found that option today. If the engineer forgets to explicitly chose this option (using that tiny arrow on the right had of the "Save" button that often looks like a speck on the monitor) and navigate through the resulting menu and drop list to the right encoding format then the result is still a file that version control cannot use, severely hampering the ability to do team collaboration.
The steps to save each file this way are tedious and easily forgotten when one is "In the Zone" of writing code on a project. In situations where this problem occurs then every file must be saved in this way.