Zawsze myślałem, że problemy dotyczące kodowania polskich znaków nie dotyczą użytkowników Windows. W końcu to taki spójny i jednolity system, posiadający nawet swój własny ‘standard’ kodowania. Jakież było moje rozczarowanie, gdy prosty skrypt batchowy pozwalający na wczytanie skryptu SQL do bazy daanych zainstalowanej w MS SQL Server:

set OSQL="c:\\Program Files\\MS SQL Server\\80\\Tools\\Binn\\osql.exe"
%OSQL% -E -d moja_baza < skrypt.sql

…wczytał, i owszem, moje wypociny w SQL, ale… zupełnie zniekształcił polskie znaki. Dostałem w ich miejsce jakieś dziwaczne krzaki, przypominające czasy źle skonfigurowanych Linuksów ;)
Nie pomaga w tej sytuacji zmiana kodowania pliku wejściowego (skrypt.sql), ani cudaczne opcje, z którymi można uruchomić ‘osql’.
Okazuje się, że winą za ten stan rzeczy obarczać możemy… windowsowy wiersz poleceń. Otóż ‘cmd.exe’, w środowisku którego wykonywane są wszystkie skryptu batchowe w Windows, pracuje używając innego kodowania znaków niż reszta systemu. Dlaczego? Nie mam pojęcia, pewnie ze względu na kompatybilność z DOS’em.
Sposobem obejścia tego problemu jest rezygnacja z windowsowej możliwości przekierowania strumieni na wejścia/wyjścia programów (bo to właśnie tam powstaje nieszczęsna konwersja znaków do DOS’owych krzaków). Na szczęście znalazła się w opcjach ‘osql’ (czyli trochę jednak skłamałem pisząc kilka linijek wyżej, że ‘osql’ nie miał pomocnej w tej sytuacji opcji ;) ) możliwość wykonania polecenia z plikiem zadanym na wejściu.
Rozwiązaniem jest zapisanie skryptu w kodowaniu, którego używa MS SQL Server (u mnie UTF-8) i wykonanie poniższego poleconka (uprzednio oczywiście ustawiając zmienną OSQL):

%OSQL% -E -d moja_baza -i skrypt.sql

Od tej pory znaki ze skryptu wędrują nienaruszone prosto do mojej bazy :)