VBS: Где в Windows взять имена текущей Windows и Dos кодировки ?

2 smaharbA> ну что-то совсем далеко от мысли , читайте внимательно -  "для егоиспользования в свойстве Charset объекта ADODB.Stream "

ну не надо издеваться, GetLocale() дает в моей системе число 1049,
а мне надо имя "Windows-1251", а если моя Windows не русская , то ее charset
кроме того нужно получить charset по умолчанию для DosПодWindows.
Конечно. если Вы знаете способ перехода от того, чтоВы предлагаете к тому, что просится, то - пожалуйста покажите, а пока это издевательство.

2 YMP > Ну, коли все так, то  - сенька бери мяч
Правда, хотел бы уточнить - правильно ли для любой локализации Windows добавлять соответсвующие приставки "Windows-" и "cp", как описано в примере 1 поста ?

есть еще и  iso и koi и много чего
и они так же могут быть локалью для виндуз

http://forum.script-coding.com/viewtopi … 607#p11607

Ага, понятно. Тогда, например, взяв из «HKLM\SYSTEM\CurrentControlSet\Control\Nls\CodePage» значение «ACP» («OEMCP») перебирать все разделы «HKCR\MIME\Database\Charset\*», пока не попадётся подходящее значение в параметре «InternetEncoding» этого раздела (напишу на PoSH, хоть и криво ):

Get-ItemProperty -Path "Registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage" -Name "ACP" | `
    Select-Object -ExpandProperty "ACP" -OutVariable sACP | Out-Null

Get-ItemProperty -Path "Registry::HKEY_CLASSES_ROOT\MIME\Database\Charset\*\" | `
    Where-Object {$_.InternetEncoding -eq $sACP[0]} | `
    Select-Object -ExpandProperty PSChildName

На VBScript:

Option Explicit

Const HKEY_CLASSES_ROOT  = &H80000000
Const HKEY_LOCAL_MACHINE = &H80000002

Dim objSWbemServicesEx
Dim objSWbemObjectEx

Dim arrSubKeys
Dim elem
Dim strValue, lngValue


Set objSWbemServicesEx = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\default")
Set objSWbemObjectEx = objSWbemServicesEx.Get("StdRegProv")

If objSWbemObjectEx.GetStringValue(HKEY_LOCAL_MACHINE, "SYSTEM\CurrentControlSet\Control\Nls\CodePage", "OEMCP", strValue) = 0 Then
    WScript.Echo "OEMCP:", strValue
    
    If objSWbemObjectEx.EnumKey(HKEY_CLASSES_ROOT, "MIME\Database\Charset", arrSubKeys) = 0 Then
        For Each elem In arrSubKeys
            If objSWbemObjectEx.GetDWORDValue(HKEY_CLASSES_ROOT, "MIME\Database\Charset\" & elem, "InternetEncoding", lngValue) = 0 Then
                If CStr(lngValue) = strValue Then
                    WScript.Echo "Charset:", elem
                End If
            End If
        Next
    End If
End If

Set objSWbemObjectEx   = Nothing
Set objSWbemServicesEx = Nothing

WScript.Quit 0

Чистое шаманство . Уверенности в правильности самого подхода у меня нет.

По поводу приведенного подхода : а ведь там еще в веточках MIME\Database\Charset\ есть такие , где нет ключа InternetEncoding . Вот не знаю только , если нет этого ключа , то обязателено ли дожен быть ключ AliasForCharset и как-то можно или вообще нужно ли его использовать ?
Т.е. например :
HKEY_CLASSES_ROOT\Mime\Database\Charset\iso_8859-1:1987 \AliasForCharset = iso-8859-1
Что является алиасом, а что именем charset :  iso_8859-1:1987 или iso-8859-1 имя, которое можно использовать  в  Stream.Charset ?

И еще : я так понимаю - все же GetLocale() (например, =1049 ) - нельзя использовать для нахождения требующегося ?

2 Poltergeyst > а причем тут эта лиса ?

И так в приведенных выше примерах используется таблица - прямиком из реестра, зачем в программу жестко зашивать ее клона ?
И еще : я так понимаю - все же GetLocale() (например, =1049 ) - нельзя использовать для нахождения требующегося ?

Я попробовал слепить простой код с WinAPI GetACP(), GetOEMCP() и посмотреть, дёргают ли они реестр, но увы — не дёргают; очевидно сие происходит только при загрузке системы. Впрочем, описание функций GetCPInfo()/GetCPInfoEx() уж настолько явно выглядит как вышеозвученные параметры реестра, что меня почти убедило:

Лучше пользуйтесь цитированием .

У меня сие занимает не более полусекунды. Реестр, правда, на свежеустановленной ОС пока практически пустой:

wmic.exe registry get CurrentSize

И даже пока не фрагментированный (во всяком случае, «C:\WINDOWS\system32\config\system»), судя по «PageDefrag».

Незачем считать. Достаточно добавить:

WScript.Echo Timer

до и после, затем сравнить. Запустил на машине с давно установленной и весьма потрудившейся ОС:

67252.17
OEMCP: 866
Charset: ibm866
67252.45

Чему там тормозить-то? У Вас случайно KAV/KIS не стоит?!

В каком цикле? В таком?

Option Explicit

Dim elem

WScript.Echo Timer

WScript.Echo GetCharsetNameOnNlsCP(Array("OEMCP", "ACP"))

WScript.Echo Timer

WScript.Quit 0

Function GetCharsetNameOnNlsCP(arrCodePages)
    Const HKEY_CLASSES_ROOT  = &H80000000
    Const HKEY_LOCAL_MACHINE = &H80000002
    
    Dim objSWbemServicesEx
    Dim objSWbemObjectEx
    
    Dim arrSubKeys
    Dim elem, elem2
    Dim strValue, lngValue
    Dim strOut
    
    Set objSWbemServicesEx = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\default")
    Set objSWbemObjectEx = objSWbemServicesEx.Get("StdRegProv")
    
    strOut = ""
    
    For Each elem In arrCodePages
        If objSWbemObjectEx.GetStringValue(HKEY_LOCAL_MACHINE, "SYSTEM\CurrentControlSet\Control\Nls\CodePage", elem, strValue) = 0 Then
            'WScript.Echo elem, strValue
            
            If objSWbemObjectEx.EnumKey(HKEY_CLASSES_ROOT, "MIME\Database\Charset", arrSubKeys) = 0 Then
                For Each elem2 In arrSubKeys
                    If objSWbemObjectEx.GetDWORDValue(HKEY_CLASSES_ROOT, "MIME\Database\Charset\" & elem2, "InternetEncoding", lngValue) = 0 Then
                        If CStr(lngValue) = strValue Then
                            'WScript.Echo "Charset:", elem2
                            strOut = strOut & elem2 & vbCrLf
                        End If
                    End If
                Next
            End If
        End If
    Next
    
    Set objSWbemObjectEx   = Nothing
    Set objSWbemServicesEx = Nothing
    
    GetCharsetNameOnNlsCP = strOut
End Function

Опять-таки, не вижу тормозов:

Сила привычки, оставшаяся от C. В основном, предпочитаю заботиться об этом сам. Отчасти ещё и потому, что любой код может стать частью какого-либо другого, более объёмного кода.

OFF: Завидую Вашим глазам .

Исключительно, чтобы окончательно все запутать - "тысячи их".
Там же выше упоминается ключик HKEY_CURRENT_USER\Control Panel\International\Locale (="00000409" -> 16-чное 0x409 = 10-чное 1049), изменение значения которого в реестре мгновенно отзывается на результате GetLocale. Но, повторяюсь, это путь великого реестрового запутывания.

А вот чтобы разобраться, начинаем с основ, смотрим стандарты, а также читаем мнение MS по этому поводу.

Что-то видимо не там читали, раз непонятно. Вот, например, в статье Языковые стандарты и кодовые страницы все ясно английским/русским языком написано (рекомендую зайти в Предпочтения сверху-справа и выбрать классический стиль отображения, чтобы видеть en/ru).
Таким образом, набор символов (charset) это просто набор буковок безотносительно языка и кодов (ABCD...), кодовая страница (code page) - сопоставление некоторых буковок с некоторыми кодами (Я-239, ...), а языковой стандарт или локаль (locale) - это сочетание языка, кодовой страницы и местных настроек сортировки, представления даты-времени, валют и пр.

С другой стороны, грань между charset и codepage "вдали от теории", в дебрях документации вечно спешащих разработчиков - она там часто просто отсутствует.

[Лирическая страничка маньяка-исследователя]

Да-да, я тоже возмущен! И почему никто на этом форуме (несомненно являющемся негласным отделением Microsoft) не берется ответить на такие простые вопросы как, например:
- за что отвечает вот этот вот конкретный ключ в реестре?
- почему это в ветке кодовых наборов находятся названия стандартов кодирования, а в разделе кодовых страниц - какие-то циферки?! Ведь это же совершенно непонятно и нелогично!

(И под влиянием нездоровых эмоций бросаюсь на амбразуру отвечать на дурацкие вопросы со всей серьезностью. )

Еще раз, другими словами: "Это реестр, детка". MS не обязаны сообщать в деталях о внутренностях своей ОС. А все что они-таки сочли нужным сообщить, можно узнать используя магическое сочетание STFW. Или проводить собственные исследования.

Часто логика и назначение значений известна лишь разработчикам. Соответственно, utf-7 и utf-8 в реестре это такие подключи (привет от кэпа). А в мире это ни наборы символов, ни кодовые страницы, а подвиды unicode, у которого кодовых страниц нет в принципе, ну или, если так можно выразиться, есть одна единственная, но не суть... Может не стоит искать логику там, где ее может и не быть?

Капитан Очевидность также сообщает, что InternetEncoding - это идентификатор метода определения кодировки интернет-контента, а судя по наличию его в ключах типа charset\_autodetect, сей метод вероятно завязан на логику некоего конкретного приложения (а не браузер IE ли это, предположит внимательный читатель), что ставит под сомнение целесообразность использования данного идентификатора для определения характеристик какой либо из локалей ОС.

Чего еще не ответил?.. Ах, да! 1200 - думаю, это просто такое красивое круглое число. Вот! По мнению MS оно как-то связано с unicode, а по мнению Руслана Петренко из Украины, оно связано с IE, который уже в свою очередь связан с MS, которые, как мы уже знаем, известно что думают. Как ни странно, я склоняюсь ко мнению последнего, не пренебрегая впрочем мнением первых. А с учетом того, что это число также связано с InternetEncoding, для нас оно интереса скорей всего не представляет.

Все не так уж важно (с) Мумий Тролль о значении внутренних значений реестра Windows, предположительно.

[/Лирическая страничка маньяка-исследователя]

alexii упоминал про функции WinAPI32, но не сообщил о возвращаемых значениях. Для полноты картины восполняю пробел примером на jscript с использованием DynamicWrapperX

var DX = new ActiveXObject("DynamicWrapperX");
DX.Register("Kernel32.dll", "GetACP", "r=u");
WScript.Echo(DX.GetACP()); //возвращает 1251
//UINT GetOEMCP(void);
DX.Register("Kernel32.dll", "GetOEMCP", "r=u");
WScript.Echo(DX.GetOEMCP()); //возвращает 866