Terminal: Windows 10 1809 / 19H1 / 20H1 يكسر إعدادات وحدة تحكم Powershell. يستمر في الفتح باستخدام الخطوط النقطية.

يحدث الشيء نفسه لي فقط عند استخدام الخط Consolas. إذا استخدمت أي شيء آخر - Courier New ، Lucida Console ، إلخ - يتم الاحتفاظ بالإعدادات.

@ 50Wliu أستطيع أن أؤكد هذا السلوك. يعيد Consolas إلى الخط النقطي. وحدة تحكم Lucida تبقى Lucida Console.

أنا على يقين من أن هذا له علاقة بحقيقة أن الإصدار الجديد من PSReadline يستخدم صفحة الرموز UTF8 لعرضه الفوري ، وعندما يفعل ذلك ، تحاول وحدة التحكم إعادة حساب الخط.

اعتقدت أن لدينا بعض المشكلات في تتبع ذلك سابقًا ، لكن لا يمكنني العثور عليها. bitcrazed هل تتذكر أين كانوا؟ أم أنه موضوع بريد داخلي مع lzybkr و @ SteveL-MSFT؟

هل يمكن لشخص ما تقديم نسخة دقيقة؟ مثل الخط الذي تقوم بتعيينه على الاختصار. ما الخط الذي يتم تعيينه عليه؟

• Win-R وتشغيل powershell .
• يبدأ بالخط النقطي.
• انتقل إلى الإعدادات واضبط الخط على Consolas. انقر فوق موافق.
• يتم تطبيق Consolas.
• أغلق Powershell.
• إعادة فتح بوويرشيل كما كان من قبل.
• الخط هو خط نقطي مرة أخرى.
• انتقل إلى الإعدادات الافتراضية واضبط الخط على Consolas. انقر فوق موافق.
• أغلق Powershell.
• إعادة فتح بوويرشيل كما كان من قبل.
• الخط هو خط نقطي مرة أخرى.

لا أعتقد أن هذا كان خطأ Powershell. لدي ملاحظة جالسة هنا في مكان ما مفادها أن أحد أحدث .NET Frameworks (4.7 شيء) قرر فجأة استخدام 65001 كصفحة التعليمات البرمجية الافتراضية لجميع التطبيقات وعندما ينقلب ذلك ذهابًا وإيابًا مع الأدوات وصفحات التعليمات البرمجية الأخرى عند بدء و الخروج ، نقوم بإعادة حساب الخط.

لدي خطأ في محاولة جعل ذلك أقل إيلامًا ، لكن التقليب المفاجئ بين صفحات الترميز هو ما يجعل هذه مشكلة.

لا يمكنني إعادة إنتاج هذا هنا. يبدأ كل من Windows PowerShell و Powershell في الخط الذي قمت بتعيينه.

Borkason هل جربت concfg clean
https://github.com/lukesampson/concfg

borakson - ما هي اللغة التي تم تكوين Windows لاستخدامها؟

bitcrazed أنا لست Borkason ولكن بما أنني أعاني من هذه المشكلة سأجيب أيضًا.

لغة العرض الخاصة بي هي الإسبانية (إسبانيا) ، وكذلك التنسيق الإقليمي لدي. لغة البرامج التي لا تدعم Unicode هي الإنجليزية (الولايات المتحدة) ، وقد تم تحديد خانة الاختيار التجريبية لـ UTF-8 Unicode. (أتمنى أن يكون هذا ما تبحث عنه ... أعلمني إذا كنت تطلب شيئًا آخر)

bitcrazed الألمانية. وقمت بالترقية من عام 1803. نسيت أن أقصد ذلك.

doctordns أي خط؟

doctordns أي خط؟

أستخدم Lucida Console (18 نقطة). لكنني اختبرت آخرين وهم يعملون أيضًا بعد إعادة تشغيل Windows PowerShell.

يحدث الشيء نفسه لي فقط عند استخدام الخط Consolas. إذا استخدمت أي شيء آخر - Courier New ، Lucida Console ، إلخ - يتم الاحتفاظ بالإعدادات.

تم إصلاح هذا على الأرجح من خلال عمل lzybkr الأخير: https://github.com/lzybkr/PSReadLine/issues/542

Borkason & doctordns - هل يمكنك من فضلك التأكيد

شكر.

bitcrazed ، يبدو أن المشكلة التي تشير إليها قد تم إصلاحها مرة أخرى في عام 2017 وبقدر ما أستطيع أن أقول أنها مدرجة في إصدار PSReadLine الذي يأتي معه 1809. بالإضافة إلى ذلك ، لا تزال هذه المشكلة تحدث بالنسبة لي اعتبارًا من إصدار Windows Insiders 18277.

bitcrazed هذا أقدم بسنة واحدة من إصدار 1809. لن أسمي ذلك "حديثًا".

وبالنسبة لي لم يتغير شيء. أنا على إصدار Windows 10 17763.107

> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      5.1.17763.1
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.17763.1
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

ولكن كما قال @ 50Wliu بالفعل ، لم يتم إصلاحه في المعاينة الحالية.

هنا رابط للتعليقات: https://aka.ms/AA37kk1

ربط bitcrazed بالمشكلة التي تسببت في المشكلة.

الإصلاح في هذا العلاقات العامة: https://github.com/lzybkr/PSReadLine/pull/771

عادل بما يكفي. هل هو معروف ببناء الإصلاح الذي سيشحنه؟

سأحاول إصدار نسخة تجريبية أخرى إلى معرض PowerShell قبل نهاية العام ، لكنني لا أعرف شيئًا عن Windows (لا أعمل على Windows).

@ يمتلك SteveL-MSFT البتات التي يتم شحنها في Windows ، لذا ربما يمكنه التعليق.

قيمة الاسم
---- -----
الإصدار 5.1.17763.134
سطح المكتب PSEdition
PSComp CompatibleVersions {1.0، 2.0، 3.0، 4.0 ...}
الإصدار 10.0.17763.134
CLR الإصدار 4.0.30319.42000
الإصدار 3.0 من WSManStack
PSRemotingProtocolVersion 2.3.1
الإصدار 1.1.0.1

نفس هنا ... جاهز لإعادة تثبيت النوافذ ، مؤلم حقًا!

يبدو أن هذه المشكلة روابط للخطوط. حصلت على مشكلة في Powershell مع windows (لا توجد هذه المشكلة في cmd و Powershell core) عندما قمت بتعيين الخط على أنه "Console" ، ولكن عندما أقوم بتغيير الخط إلى "Sarasa Mono SC" ، تعمل جميعها بشكل مثالي. أستخدم "Sarasa Mono SC" لإظهار حرف UTF-8 ، ولا يحتوي Windows 10 على خط افتراضي يمكنه عرض أحرف UTF-8 كافية.

كذلك هنا. كل من جهاز Surface وجهاز كمبيوتر سطح المكتب.

من الغريب أنني أواجه نفس المشكلة ولكن بطريقة مختلفة. عندما يتم فتح عملية فرعية لتشغيل powerhell.exe ، يتغير خط وحدة التحكم إلى خطوط نقطية من Consolas.

مثال 1: لدي vim يعمل (WSL) ويقوم بتشغيل أمر فرعي بوويرشيل للحصول على حافظة النظام. في كل مرة أقوم بتشغيل هذا الأمر ، فإنه يعيد تعيين خط وحدة التحكم إلى الخطوط النقطية.

مثال 2: لدي برنامج نصي شل يقوم بتشغيل بوويرشيل كعملية فرعية للحصول على خوادم أسماء النظام. يتسبب في حدوث نفس الشيء لوحدة التحكم ، التبديل إلى الخطوط النقطية. لا شيء هو الإخراج إلى وحدة التحكم. كل شيء يحدث في العملية الفرعية.

الجزء الغريب حقًا هو أنه إذا قمت بتشغيل بوويرشيل يدويًا من وحدة التحكم (WSL) ، فلا بأس بذلك ولن يتغير الخط.

bitcrazed ، @ SteveL-MSFT ، lzybkr : لديّ نموذج جيد. بدأ هذا يحدث مباشرة بعد أن قمت بترقية الجهاز إلى Windows 1809. لقد قمت بتعيين الخط ووحدة التحكم CP من قبل ، على النحو التالي ، على Consolas و 65001 على التوالي ، وعمل كل شيء على ما يرام. أنا أعمل مع ملفات UTF-8 ، لذلك كان CP 65001 ضروريًا بالنسبة لي. لغتي المحلية هي en-US القديمة ، واللغة الإنجليزية Windows 10 x64 Pro ، و OEM CP هو الافتراضي 437.

1. قم بتعيين مفاتيح التسجيل التالية (حفظ باسم .reg والاستيراد). لسبب ما ، من المهم تغيير FontFamily ، حيث قد يكون الإعداد الافتراضي مختلفًا ، ولن يتم تطبيق الخط.

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Console]
"FaceName"="Consolas"
"FontFamily"=dword:00000036
"FontSize"=dword:000f0000
"FontWeight"=dword:00000190
"CodePage"=dword:0000fde9

1. win + R cmd.exe ENTER . تبدأ وحدة التحكم بالخط الصحيح وصفحة التعليمات البرمجية. اكتب chcp ؛ تطبع 65001 (إذا لم يتم ذلك ، فقم بتشغيل chcp 65001 ).
2. في وحدة التحكم ، اكتب powershell -noprof ("-noprof" لتأكيد أن المشكلة لا تتعلق بأي شيء أقوم بتحميله في ملف التعريف الخاص بي).

عند بدء تشغيل PowerShell ، يتغير خط وحدة التحكم على الفور إلى خط نقطي ، ويتم تغيير حجم النافذة لتلائم. الخط النقطي المحدد هو Terminal ، ولا يحتوي حتى على أحرف WGL4 (بدون سيريلية أو يونانية). لذلك هذا بالتأكيد خطأ.

يتكرر السلوك حتى في حالة تشغيل أمر غير تفاعلي ، لذلك من المشكوك فيه أن الخطأ مرتبط بـ PSReadLine:

powershell -noprof -nonint -command "echo foo"

أيضًا ، يتغير خط وحدة التحكم بشكل مشابه (بشكل أساسي ، يتم فتح وحدة التحكم بخط نقطي) إذا تم تشغيل PowerShell عبر اختصار ، أو من مربع الحوار Win + R ، أو بالنقر المزدوج في Explorer.

أيضا ، بعض السلبيات. لا يتم تغيير الخط إذا:

• قمت بتشغيل chcp 437 قبل استدعاء powershell من cmd.
• يتم تعيين خط وحدة التحكم في التسجيل على "Lucida Console" (كل شيء آخر يبقى كما هو مذكور أعلاه). وقد لوحظ بالفعل أن هذا الخط "خاص" إلى حد ما في التعليقات في هذه التذكرة.

كان الموضوع المشترك في التعليقات حول هذا الموضوع ، على ما أعتقد ، لغة أوروبية غير أمريكية (تم ذكر اللغة الألمانية والإسبانية). لذلك حاولت ما يلي:

1. ابدأ تشغيل cmd.exe
2. قم بتعيين صفحة رموز وحدة التحكم باستخدام chcp NNN (انظر أدناه):
3. تشغيل powershell -noprof .

• مع NNN = 437 ، 1252 ، 1251 ، 1253 ، 850 ، 852 ، 869 ، 857 ، 737 - لا يوجد تغيير في الخط
• باستخدام NNN = 65001 ، و 858 ، والعبرية 862 بدون WGL4 ، والعربية 864 - يتغير الخط.

ما الذي يميز CP 858؟ تخميني هو أن هذا قد يكون المفتاح. اسم CP هو "OEM Multilingual Latin 1 + Euro الرمز".

وتجدر الإشارة أيضًا إلى أن chcp 1255 و chcp 1266 (العبرية والعربية) قاموا بتغيير الخط إلى "Courier New" حتى في cmd.exe . لذلك قد يكون PowerShell أكثر عرضة للإصابة بطريقة ما ، وليس الجاني الرئيسي؟

معلومات الإصدار الإلزامي:

C:\Users\kkm> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      5.1.17763.134
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.17763.134
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

أيضًا ، يجب أن أذكر ، على الرغم من أن هذا على الأرجح غير ذي صلة: لدي شاشة عرض DPI عالية مع ضبط مقياس العرض على 150 ٪.

@ kkm000 تم إصلاح هذا في PSReadLine (https://github.com/lzybkr/PSReadLine/pull/771) ، ولكنه ليس في إصدار Windows الذي تستخدمه ، على الرغم من أن الإصلاح تم التحقق منه في إصدار أحدث من Windows. أعتقد أن أحدث إصدار بيتا عام من PSReadLine يحتوي على الإصلاح ، لذا يمكنك تثبيته في Windows PowerShell باستخدام:

install-module psreadline -AllowPrerelease -Repository PSGallery -Force
# restart PowerShell to load the new one

إذا كانت تشتكي من عدم العثور على -AllowPrerelease ، فسيتعين عليك تحديث PowerShellGet:

install-module powershellget -Scope CurrentUser -Repository psgallery -Force -AllowClobber
# restart PowerShell to load the new one

على الرغم من التحقق من الإصلاح في إصدار أحدث من Windows.

هل هذا يعني أن الإصلاح سيأتي في المستقبل (19H1) إصدار Insider؟

@ 50Wliu نعم

@ SteveL-MSFT لدي نفس الإصدار مثل @ kkm000 ، قمت بتشغيل الأوامر ولم أعمل من أجلي ، أفتقد شيئًا؟

@ SteveL-MSFT أجد أنه من المحبط للغاية أنه لا يمكن شحن هذا مع تحديث Windows منتظم. إذا كسرت Microsoft شيئًا ما بتحديث ، فمن مسؤوليتها إصلاحه بتحديث وعدم تأجيله لأكثر من ستة أشهر والتخطيط لشحنه مع إصدار Windows التالي ، أو جعل الأشخاص يقفزون عبر الأطواق للحصول على إصلاح عاجل من قبل الإفراج عن المستودع (الذي لا يعمل حتى مع الجميع).

لذلك .... اضطررت لتشغيل هذا الأمر أكثر من مرة

تثبيت وحدة بوويرشيلجيت -سكوب الحالي المستخدم-مستودع psgallery -قوة -AllowClobber

مع تشغيل بوويرشيل كمسؤول ، يقوم Taskmgr بقتل بوويرشيل ثم القيام بذلك مرة أخرى لأنه فشل مرتين أو ثلاث مرات. و… يبدو وكأنه يعمل! تعمل إعدادات العرض المخصصة في ملف التعريف $ الخاص بي الآن كما كانت قبل الترقية.

لقد بدأ هذا للتو في الحدوث لي بعد الترقية إلى أحدث إصدار 1809 17763.292 من التحديث التراكمي السابق 1809 . لقد اتبعت الإرشادات لتثبيت PSReadLine الجديد ويبدو أنه موجود:

Script 2.0.0 PSReadLine {Get-PSReadLineKeyHandler, Set-PSReadLineKeyHandler, Remov
عندي

PSVersion 5.1.17763.134

يتم استبدال خط Consolas بخطوط نقطية.

تحديث

يبدو أن هذا عن طريق الإصلاح غير المستقر. الآن بعد إعادة التشغيل ، الإصلاح مستمر / يعمل ، بغض النظر عن مستوى التشغيل.

أراه الآن سلوكًا مثيرًا للاهتمام. بعد تشغيل "الإصلاح" على جهاز الكمبيوتر المحمول
قيمة الاسم
---- -----
الإصدار 5.1.17763.134
سطح المكتب PSEdition
PSComp CompatibleVersions {1.0، 2.0، 3.0، 4.0 ...}
الإصدار 10.0.17763.134
CLR الإصدار 4.0.30319.42000
الإصدار 3.0 من WSManStack
PSRemotingProtocolVersion 2.3.1
الإصدار 1.1.0.1

عند تشغيل PS في وضع المستخدم ، يكون الإصلاح جيدًا ؛ عند تشغيل PS كمسؤول ، لا يعمل الإصلاح.

لا يعمل معي حتى في وضع المستخدم.

@ SteveL-MSFT ، يبدو أن الإصلاح لا يعمل بالنسبة لي. أيضًا ، لا يبدو أن وحدة التثبيت قد غيرت أي شيء. لدي بالفعل أحدث إصدار من PowerShellGet ( -AllowPrerelease يعمل بالتأكيد ؛ تعتمد ارتباطات المفاتيح الخاصة بي على PSReadLine الأخير). لقد قمت في البداية بتثبيت PSReadLine قبل بضعة أشهر (قبل ترقية Windows!) ، لذلك توقعت أن أحصل على ترقية اليوم باستخدام الأمر الذي اقترحته ، لكن ليس لدي أي فكرة عن كيفية تأكيد ما إذا كان أي شيء قد تغير بالفعل. هل باستطاعتك رجاءا المساعدة؟ أخذت إصدار PSReadLine قبل محاولة الترقية:

C:\WINDOWS\system32> date

Saturday, February 2, 2019 13:46:02

C:\WINDOWS\system32> Get-Module PSReadline | fl Version

Version : 2.0.0

C:\WINDOWS\system32> Get-Module PSReadline | fl *

LogPipelineExecutionDetails : False
Name                        : PSReadline
Path                        : C:\Program Files\WindowsPowerShell\Modules\PSReadline\2.0.0\PSReadLine.psm1
ImplementingAssembly        :
Definition                  : function PSConsoleHostReadLine
                              {
                                  Microsoft.PowerShell.Core\Set-StrictMode -Off
                                  [Microsoft.PowerShell.PSConsoleReadLine]::ReadLine($host.Runspace, $ExecutionContext)
                              }

Description                 : Great command line editing in the PowerShell console host
Guid                        : 5714753b-2afd-4492-a5fd-01d9e2cff8b5
HelpInfoUri                 : https://go.microsoft.com/fwlink/?LinkId=528806
ModuleBase                  : C:\Program Files\WindowsPowerShell\Modules\PSReadline\2.0.0
PrivateData                 : {PSData}
Tags                        : {}
ProjectUri                  :
IconUri                     :
LicenseUri                  :
ReleaseNotes                :
RepositorySourceLocation    : https://www.powershellgallery.com/api/v2/
Version                     : 2.0.0
ModuleType                  : Script
Author                      : Microsoft Corporation
AccessMode                  : ReadWrite
ClrVersion                  : 4.0.0
CompanyName                 : Microsoft Corporation
Copyright                   : (c) Microsoft Corporation. All rights reserved.
DotNetFrameworkVersion      : 4.6.1
ExportedFunctions           : {[PSConsoleHostReadLine, PSConsoleHostReadLine]}
Prefix                      :
ExportedCmdlets             : {[Get-PSReadLineKeyHandler, Get-PSReadLineKeyHandler], [Get-PSReadLineOption,
                              Get-PSReadLineOption], [Remove-PSReadLineKeyHandler, Remove-PSReadLineKeyHandler],
                              [Set-PSReadLineKeyHandler, Set-PSReadLineKeyHandler]...}
ExportedCommands            : {[Get-PSReadLineKeyHandler, Get-PSReadLineKeyHandler], [Get-PSReadLineOption,
                              Get-PSReadLineOption], [Remove-PSReadLineKeyHandler, Remove-PSReadLineKeyHandler],
                              [Set-PSReadLineKeyHandler, Set-PSReadLineKeyHandler]...}
FileList                    : {}
CompatiblePSEditions        : {}
ModuleList                  : {}
NestedModules               : {Microsoft.PowerShell.PSReadLine}
PowerShellHostName          :
PowerShellHostVersion       :
PowerShellVersion           : 5.0
ProcessorArchitecture       : None
Scripts                     : {}
RequiredAssemblies          : {}
RequiredModules             : {}
RootModule                  : PSReadLine.psm1
ExportedVariables           : {}
ExportedAliases             : {}
ExportedWorkflows           : {}
ExportedDscResources        : {}
SessionState                : System.Management.Automation.SessionState
OnRemove                    :
ExportedFormatFiles         : {C:\Program Files\WindowsPowerShell\Modules\PSReadline\2.0.0\PSReadLine.format.ps1xml}
ExportedTypeFiles           : {}

ثم قمت بالترقية ، كما اقترحت:

C:\WINDOWS\system32> install-module psreadline -AllowPrerelease -Repository PSGallery -Force
C:\WINDOWS\system32> exit

يتأرجح Install-Module لبعض الوقت ، وشريط تقدم مع لسعة 'o's مخططة في الجزء العلوي من الشاشة. لا أعتقد أن هذا يعني أي شيء ، ولكن تكرار وحدة التثبيت يؤدي أيضًا إلى ظهور شريط التقدم للحظة وجيزة. لكن وحدة التحكم الجديدة لا تزال تعاني من المشكلة الأصلية. أيضًا ، لا أرى أي تغييرات هنا ، فربما يمكنك اكتشاف شيء ما؟ يمكنني بالتأكيد إلقاء نظرة على إصدارات الملفات وما إلى ذلك التي لدي ، ولا أعرف ما الذي أبحث عنه.

هذا لم يفعل أي شيء أيضًا:

C:\WINDOWS\system32> Update-Module PSReadLine -AllowPrerelease
C:\WINDOWS\system32>

في وحدة التحكم الجديدة ، يبدو PSReadLine الجديد (؟) هو نفسه:

C:\WINDOWS\system32> Get-Module PSReadline | fl *

LogPipelineExecutionDetails : False
Name                        : PSReadline
Path                        : C:\Program Files\WindowsPowerShell\Modules\PSReadline\2.0.0\PSReadLine.psm1
ImplementingAssembly        :
Definition                  : function PSConsoleHostReadLine
                              {
                                  Microsoft.PowerShell.Core\Set-StrictMode -Off
                                  [Microsoft.PowerShell.PSConsoleReadLine]::ReadLine($host.Runspace, $ExecutionContext)
                              }

Description                 : Great command line editing in the PowerShell console host
Guid                        : 5714753b-2afd-4492-a5fd-01d9e2cff8b5
HelpInfoUri                 : https://go.microsoft.com/fwlink/?LinkId=528806
ModuleBase                  : C:\Program Files\WindowsPowerShell\Modules\PSReadline\2.0.0
PrivateData                 : {PSData}
Tags                        : {}
ProjectUri                  :
IconUri                     :
LicenseUri                  :
ReleaseNotes                :
RepositorySourceLocation    : https://www.powershellgallery.com/api/v2/
Version                     : 2.0.0
ModuleType                  : Script
Author                      : Microsoft Corporation
AccessMode                  : ReadWrite
ClrVersion                  : 4.0.0
CompanyName                 : Microsoft Corporation
Copyright                   : (c) Microsoft Corporation. All rights reserved.
DotNetFrameworkVersion      : 4.6.1
ExportedFunctions           : {[PSConsoleHostReadLine, PSConsoleHostReadLine]}
Prefix                      :
ExportedCmdlets             : {[Get-PSReadLineKeyHandler, Get-PSReadLineKeyHandler], [Get-PSReadLineOption,
                              Get-PSReadLineOption], [Remove-PSReadLineKeyHandler, Remove-PSReadLineKeyHandler],
                              [Set-PSReadLineKeyHandler, Set-PSReadLineKeyHandler]...}
ExportedCommands            : {[Get-PSReadLineKeyHandler, Get-PSReadLineKeyHandler], [Get-PSReadLineOption,
                              Get-PSReadLineOption], [Remove-PSReadLineKeyHandler, Remove-PSReadLineKeyHandler],
                              [Set-PSReadLineKeyHandler, Set-PSReadLineKeyHandler]...}
FileList                    : {}
CompatiblePSEditions        : {}
ModuleList                  : {}
NestedModules               : {Microsoft.PowerShell.PSReadLine}
PowerShellHostName          :
PowerShellHostVersion       :
PowerShellVersion           : 5.0
ProcessorArchitecture       : None
Scripts                     : {}
RequiredAssemblies          : {}
RequiredModules             : {}
RootModule                  : PSReadLine.psm1
ExportedVariables           : {}
ExportedAliases             : {}
ExportedWorkflows           : {}
ExportedDscResources        : {}
SessionState                : System.Management.Automation.SessionState
OnRemove                    :
ExportedFormatFiles         : {C:\Program Files\WindowsPowerShell\Modules\PSReadline\2.0.0\PSReadLine.format.ps1xml}
ExportedTypeFiles           : {}

أيضا، نظرا ل @mjoyce6500 وwigster التعليقات الواردة أعلاه، راجعت (غير المشرف) وحدة التحكم المستخدم، وهذا واضح أيضا علة كما فعلت من قبل.

من فضلك ، سأقدر أي مساعدة / أفكار قد تشاركها!

@ SteveL-MSFT ، lzybkr ، لا أعتقد أن هناك تحديثًا في PSGallery. تم نشر أحدث إصدار تجريبي قبل شهر من دمج إصدار lzybkr / PSReadLine # 771:

C:\WINDOWS\system32> Find-Module PSReadline -Repository PSGallery -AllVersions -AllowPrerelease | ft name,ver*,pub*

Name       Version     PublishedDate
----       -------     -------------
PSReadLine 2.0.0-beta3 2018-09-04 21:59:13
PSReadLine 2.0.0-beta2 2018-06-04 20:28:42
PSReadLine 2.0.0-beta1 2017-12-06 07:22:16
PSReadLine 1.2         2016-01-25 20:43:22
PSReadLine 1.0.0.13    2015-02-18 00:28:18
PSReadLine 1.0.0.12    2014-08-26 19:04:26
PSReadLine 1.0.0.11    2014-06-13 21:15:30
PSReadLine 1.0.0.10    2014-06-13 02:21:13
PSReadLine 1.0.0.9     2014-06-11 21:20:46
PSReadLine 1.0.0.8     2014-05-07 22:20:52

لسوء الحظ ، لم يعد يتضمن ReleaseNotes بعد الآن ، مثل beta2. لكن التوقيت يستبعد بالتأكيد هذا الاحتمال.

ملاحظة غير ذات صلة ، يبدو أنه تم تبديل المؤلف والشركة:

C:\WINDOWS\system32> Find-Module PSReadline -req 2.0.0-beta3 -Repository PSGallery -AllowPrerelease | fl author,compan*

Author      : Microsoft Corporation
CompanyName : lzybkr

"الإصلاح" لا يزال له نتائج مختلطة بالنسبة لي. يعمل Powershell في وضع المستخدم بشكل جيد ، ولا يوجد تغيير في الألوان / الخطوط المخصصة لدي بعد تشغيل الأمر المذكور أعلاه. على الرغم من أن Powershell في وضع المسؤول لم يتم إصلاحه ، إلا أنه يظهر السلوك المذكور في هذا الخطأ.

@ mjoyce6500 هل يمكن أن تعطيني خطوات

@ SteveL-MSFT ، هل يمكنك إلقاء نظرة على تعليقي أعلاه ؟ لا يمكنني حتى العثور على الإصدار المحدّث من PSReadLine في PSGallery ، بينما يبلغ الآخرون عن "نتائج مختلطة". اعتبارًا من الآن ، لا يزال الإصدار الأعلى المتاح هو PSReadLine 2.0.0-beta3 18-09-04 21:59:13 ، وقد تم نشره قبل شهر من دمج الإصلاح.

أيضًا ، كيف يمكنني معرفة الإصدار الذي أستخدمه؟ على جهاز آخر ، حيث لم أحاول أبدًا اقتراح التحديث الخاص بك ، تحقق من السطر الأول من الملف Changes.txt من الحزمة المثبتة:

C:\WINDOWS\system32> Get-Module PSReadline | fl version,modulebase

Version    : 2.0.0
ModuleBase : C:\Program Files\WindowsPowerShell\Modules\PSReadline\2.0.0

C:\WINDOWS\system32> gc "C:\Program Files\WindowsPowerShell\Modules\PSReadline\2.0.0\Changes.txt" | select -first 1
### Version 2.0.0-beta2

بعد ذلك ، يحاول Install-Module بالفعل تثبيت 2.0.0-beta3 ، وقم بالتأكيد بالتشغيل بدون -force :

C:\WINDOWS\system32> install-module psreadline -AllowPrerelease -Repository PSGallery
WARNING: Version '2.0.0-beta2' of module 'PSReadline' is already installed at 'C:\Program
Files\WindowsPowerShell\Modules\PSReadline\2.0.0'. To install version '2.0.0-beta3', run Install-Module and add the -Force parameter, this command will install version '2.0.0-beta3' side-by-side with version '2.0.0-beta2'.

هل من الممكن أن أتلقى التحديث ليس من مكان ما يفعله الآخرون؟

بعد التحديث ، يحتوي ملف Changes.txt على رأس 2.0.0-beta3 كسطر أول:

C:\WINDOWS\system32> gc "C:\Program Files\WindowsPowerShell\Modules\PSReadline\2.0.0\Changes.txt" | select -first 1
### Version 2.0.0-beta3

ونفس الاستنساخ كما كان من قبل ، وحدة تحكم المشرف أم لا. من وحدة التحكم cmd.exe بخط Consolas:

C:\WINDOWS\system32>chcp 65001
Active code page: 65001

C:\WINDOWS\system32>powershell -noprof -nonint
==== BOOM! font changes ===
Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.

PS C:\WINDOWS\system32>

بالطبع ، لا أتوقع أن يعمل ، لأنني لا أمتلك DLL المحدث. سؤالي هو ، كيف يمكن أن يكون لدى الآخرين.

وجود نفس المشكلة هنا ، والإصلاح أعلاه ليس له أي تأثير.

لا يزال الأمر محيرًا للعقل حول كيفية عمل الإصلاح (جزئيًا على الأقل) للأقلية من الناس ، نظرًا لأنه لم يتم إصداره مطلقًا ، بالنظر من خلف هذه العيون. أن أقول إنني في حيرة هو عدم قول أي شيء. تفكيري الحالي هو أن هناك معرضين لـ PS ، وقد تم نشر الإصلاح لأحدهما الذي لا يصل إليه سوى عدد قليل من الأشخاص.

@ kkm000 هناك

@ SteveL-MSFT
لقد قمت بتثبيت beta3 ولم يتم حل
كلاهما يعمل بنظام Windows 1809 و 1903 (النسخة 18334.1)

Borkason الإصلاح لعدم تغيير الخط إذا لم يتم استخدام خط نقطي يجب أن يكون بالفعل في هذا

أنا أستخدم Consolas. يعود مرة أخرى بعد كل إعادة تشغيل بوويرشيل.

Borkason ما هو الموقع الذي تستخدمه؟ ar أو أي شيء آخر؟

دي- DE

فجأة تعمل الآن. أخذني 10 مرات لإغلاق وفتح powerhell ، ولكن يبدو الآن أنه عالق.

كسر مرة أخرى. لذلك من الواضح أنه يقرر بشكل عشوائي كسر مرة أخرى ، أو العمل. 💢

لقد حدث ذلك مع 18334 - بشكل عشوائي تمامًا. لم يحدث مرة أخرى.

حسنًا ، الفرق هو أنه عند تشغيل بوويرشيل عبر ALT-R ، يظل الخط كما هو. عندما أقوم بتشغيله من قائمة البداية ، فإنه يعيد تعيين الخط إلى خطوط المسح ، حتى عندما قمت بتغييره إلى لوحة المفاتيح في الجلسة السابقة التي قمت بتشغيلها من قائمة البداية.

(وأعني بقائمة البدء أني أضغط على مفتاح Windows على لوحة المفاتيح ثم اكتب "بوويرشيل" واضغط على إدخال.)

@ SteveL-MSFT - لم أنشر إصدارًا به إصلاح الخط في معرض PowerShell. الإصلاح متاح في PSReadLine repo على الرغم من ذلك ، بحيث يمكنك بنائه بنفسك أو الحصول على تصميم من AppVeyor.

Borkason - إذا كنت تستخدم Consolas ، فأعتقد أنك لا يجب أن ترى خطأ الخط.

يظل من الصعب ضبط الإعدادات الافتراضية لوحدة التحكم بسبب التوافق مع الإصدارات السابقة. يمكن تعيين الإعدادات الافتراضية في التسجيل (لكل تطبيق وحدة تحكم) أو في الاختصار المستخدم لبدء تطبيق وحدة التحكم. أعلم أن فريق وحدة التحكم يريد حل هذه المشكلة ، ولكن يبدو أنها مشكلة صعبة.

إذا كنت تستخدم Consolas ، فأعتقد أنه لا يجب أن ترى خطأ الخط.

ثم لم يتم حل هذا الخطأ ، لأنني أستخدم وحدة التحكم والاختصار يعمل أيضًا.

يظل من الصعب ضبط الإعدادات الافتراضية لوحدة التحكم بسبب التوافق مع الإصدارات السابقة.

ثم يجب على Microsoft توفير برنامج نصي / أداة FixIt لأولئك الذين يريدون فقط أن تعمل وحدة التحكم الخاصة بهم مرة أخرى ، بغض النظر عن التوافق مع الإصدارات السابقة ...

أعلم أن فريق وحدة التحكم يريد حل هذه المشكلة ، ولكن يبدو أنها مشكلة صعبة.

على ما يبدو. كما أنه من الصعب للغاية وضع نصف الإصلاح اللعين PowerShell في عام 1809 ، ناهيك عن عام 1903 ...

😠

لقد قمت للتو بالتحديث إلى 18342 ويبدو أن المشكلة قد تم إصلاحها (لا يزال 18334 يُعاد تعيينه إلى الخطوط النقطية في كل مرة).

ما زلت أوافق على أنه يجب إرسال الإصلاح إلى 1809.

تحرير: مشكلة التكوين الخاطئ عند الترقية (راجع https://github.com/Microsoft/console/issues/280#issuecomment-474917761). لم يتم إصلاح الخلل.

لقد أجريت تثبيتًا جديدًا لـ 20H1. لا تزال المشكلة قائمة. 🤣 هذه مزحة ، أليس كذلك؟

يمكن إصلاح ذلك عن طريق تثبيت أدوات 1809 windows 10 Rsat.
لا يمكنك تثبيت RSAT على أجهزة الكمبيوتر التي تعمل بإصدارات Home أو Standard من Windows.
يمكنك تثبيت RSAT فقط على إصدارات Windows 10 Professional أو Enterprise.

الطريقة الأولى - استخدام إضافة ميزة قم بتثبيت أدوات RSAT على Windows 10 الإصدار 1809

لتثبيت أدوات RSAT على Windows 10 الإصدار 1809 ، انقر فوق ابدأ. انقر فوق الإعدادات ومن صفحة الإعدادات ، انقر فوق التطبيقات.
في الجزء الأيسر ، ضمن التطبيقات والميزات ، انقر فوق إدارة الميزات الاختيارية.
الآن انقر فوق + إضافة ميزة وانتظر حتى يتم ملء قائمة الميزات.
قم بالتمرير لأسفل حتى ترى ميزات RSAT.
حدد الآن أيًا من ميزة RSAT التي ترغب في تثبيتها. في هذه الحالة ، أقوم بتحديد RSAT: ميزة أدوات إدارة نهج المجموعة.
انقر فوق تثبيت.
انقر فوق رمز الرجوع وانتظر حتى يتم تثبيت الميزة.
الآن يجب أن تجد أدوات إدارة نهج المجموعة ضمن ابدأ> أدوات Windows الإدارية.

يعمل الموقع .... قم بتثبيت أدوات RSAT على Windows 10 الإصدار 1809 والإصدارات الأحدث
بقلم Prajwal Desai آخر تحديث في 31 كانون الثاني (يناير) 2019

أتمنى أن يساعدك هذا....

RobRoberson أنت تفهم حقًا ما تقوله ، أليس كذلك؟

لدي نفس المشكلة على windows 1809 17763.316.
zh_Hans_CN مع تمكين خيار UTF-8.

هل ستحل إصدارات المعاينة المشكلة؟

هل ستحل إصدارات المعاينة المشكلة؟

لا.

أسترجع ما قلته في https://github.com/Microsoft/console/issues/280#issuecomment -465837677. ما حدث بالفعل هو أنه تمت إعادة ضبط جميع إعدادات اللغة الخاصة بي ، مما أدى إلى إيقاف تشغيل صفحة الشفرة 65001. لقد أدركت للتو أنه اليوم ، أعدت تشغيله ، و ... مرحبًا بالخطوط النقطية.

@ SteveL-MSFT يبدو أن هذا التعليق الخاص بك غير صحيح من خلال عدد الأشخاص الذين ما زالوا يقولون إن هذه المشكلة لم يتم حلها ، حتى في أحدث إصدارات Insider (أنا في 18361 الآن ، على سبيل المثال).

أحب إصلاح هذا. حقا مثل Consolas للتطوير تحت Windows.

يمكن أن يؤكد استخدام إصدار Microsoft 1903 الداخلي أن هذا الخطأ لا يزال موجودًا في Consolas و UFT8. يعمل خط Lucida Console على الرغم من أنه سيكون الحل البديل

نحن نعمل على تحديث جديد لـ PSReadLine ، ثم سنرى كيفية إدخاله إلى Windows

في pwsh 6.2.0 ، يبدو أن هذه المشكلة قد تم حلها ، لكنها عادت بعد أن استخدمت msbuild 2017 لإنشاء أي شيء (كان إصدار 2015 جيدًا). لست متأكدًا من مكان حدوث ذلك بالضبط لأنه يبدأ من node-gyp ، ولكن إذا احتاجت الوحدات الأصلية إلى إعادة بنائها ، فستعود وحدة التحكم الخاصة بي إلى الخطوط النقطية.

لحسن الحظ ، لم أعد بحاجة إلى إعادة تعيين الخطوط في كل مرة أقوم فيها بفتح الجهاز ، فقط عند تشغيل node-gyp.

تم نشر PSReadLine 2.0.0-beta4 الذي يجب أن يعالج العديد من المشكلات (على الرغم من أنه يحتوي على عدد قليل من المشكلات الجديدة). https://www.powershellgallery.com/packages/PSReadLine/2.0.0-beta4

@ SteveL-MSFT 2.0.0-beta4 لم يصلح هذا الخطأ.

أستخدم محطة CMD عادية مع git's bash.exe + phpunit = نفس المشكلة. يظهر بعد ثوان قليلة من بدء تشغيل البرنامج النصي.
لست متأكدًا من السبب في PowerShell ...

@ SteveL-MSFT 2.0.0-beta4 لا يصلح الخطأ بالنسبة لي أيضًا.

sebgod شكرًا

سآخذ شخص ما ينظر في هذا مرة أخرى

@ SteveL-MSFT لتكرار هذا ، افتح موجه الأوامر ، واضبط الخط على Consolas ،
ثم قم بتشغيل cmd /c chcp 65001 >NUL && powershell

حسنًا ، أعتقد أنني حددت المشكلة الفعلية وليس لها أي علاقة بـ PSReadLine. يوجد فحص في Windows PowerShell لمعرفة ما إذا كانت صفحة الرموز مدعومة بواسطة خط Consolas. القائمة هنا . UTF-8 65001 ليس مدرجًا في تلك القائمة ، لذلك عندما يحدد Windows PowerShell صفحة الرموز التي لا تدعمها Consolas ، فإنه يغير الخط إلى Terminal . لم يعد PowerShell Core 6.x يحتوي على هذا الرمز بعد الآن لذلك لا ترى هذا السلوك. أنا متردد في تغيير هذا الرمز لأنه قد يكسر شيئًا آخر. لملاحظاتي الخاصة ، هذا موجود في سطر ConsoleControl.cs 2648.

حسنًا ، أعتقد أنني حددت المشكلة الفعلية وليس لها أي علاقة بـ PSReadLine. يوجد فحص في Windows PowerShell لمعرفة ما إذا كانت صفحة الرموز مدعومة بواسطة خط Consolas. القائمة هنا . UTF-8 65001 ليس مدرجًا في تلك القائمة ، لذلك عندما يحدد Windows PowerShell صفحة الرموز التي لا تدعمها Consolas ، فإنه يغير الخط إلى Terminal . لم يعد PowerShell Core 6.x يحتوي على هذا الرمز بعد الآن لذلك لا ترى هذا السلوك. أنا متردد في تغيير هذا الرمز لأنه قد يكسر شيئًا آخر. لملاحظاتي الخاصة ، هذا موجود في سطر ConsoleControl.cs 2648.

لست متأكدًا من كيفية كسر هذا شيئًا ما ، حيث لم يكن UTF-8 مدعومًا قبل أحدث إصدارات Windows 10.

sebgod كسر شيء ما هنا يعني عرض غير صحيح لأنني متأكد من أن Consolas لا يحتوي على جميع الصور الرمزية التي يحتاجها UTF-8

@ SteveL-MSFT Lucida Console و Courier New وجميع الخطوط الأخرى المتاحة التي لا تتأثر بهذه المشكلة على الرغم من أنها أيضًا لا تدعم صفحة الشفرة 65001 أيضًا. من قبيل الصدفة ، تدعم Consolas صفحات تشفير أكثر من Lucida Console. فلماذا يحدث هذا مع Consolas فقط؟

ولكن بشكل عام ، يجب أن يكون قرار المستخدمين بشأن الخط المستخدم للعرض. في حالة عدم وجود الصور الرمزية ، يتم عرضها على أنها � ويمكن للمستخدم اتخاذ قرار بتغيير الخط.

Borkason أعتقد أنها قضية واضحة للغاية من منظور متحدث اللغة الإنجليزية الأصلي ، ولكن لا شك في أن هناك خوفًا من التسبب في مشاكل للمستخدمين الدوليين لا يمكننا توقعها.

على سبيل المثال ، عندما قدمbitcrazed (عضو آخر في فريق Microsoft Terminal) العلاقات العامة لـ cURL التي من شأنها تنفيذ دعم Windows VT https://github.com/curl/curl/pull/3011 (والذي تضمن تغيير صفحة الرموز إلى 65001) ، انتهى به الأمر إلى التسبب في مشكلة للمستخدمين الدوليين: https://github.com/curl/curl/issues/3211

استلزم هذا تصحيحًا يكتب UTF-8 في صفحة التعليمات البرمجية الحالية باستخدام واجهات برمجة تطبيقات سلسلة عريضة بدلاً من ذلك: https://github.com/mattn/curl/commit/1d394188c5ecd7fb31e21f17a907aa1e7f525eb9

لا يفاجئني أن فريق Microsoft Terminal يريد التعامل مع هذا بحذر شديد بعد ذلك.

sebgod كسر شيء ما هنا يعني عرض غير صحيح لأنني متأكد من أن Consolas لا يحتوي على جميع الصور الرمزية التي يحتاجها UTF-8

حسنًا ، لا يوجد خط واحد يوفره Windows يغطي كل الحروف الرسومية المحددة في UTF-8. يعتمد Cmd.exe على تقنية تسمى ربط الخط لتوفير عرض لكافة الصور الرمزية.
قبل إدراج إعداد UTF-8 كصفحة رموز للنظام ، كان على المرء استخدام chcp 65001 يدويًا ، لكنه كان يعمل بشكل صحيح. يجب عمل بت ربط الخط يدويًا في التسجيل لجعله يعمل في أي حال.

ImportTaste لا أعتقد أن هذا له علاقة به. لا يسري الإجراء الاحتياطي إلا إذا تم استخدام Consolas. إذا تم استخدام أي خط آخر مثل Lucida Console أو Courier New ، فلن يحدث هذا. تمتلك Lucida Consolas على الأقل نفس دعم صفحة الشفرة مثل Consolas ، لذلك من الصعب فهم سبب القيام بذلك بهذه الطريقة. إذا كانت هناك مشكلة للمستخدمين الدوليين (وبالمناسبة ، أنا لست متحدثًا أصليًا للغة الإنجليزية كما تفترض) ، فستظل تؤثر على جميع المستخدمين الذين لا يستخدمون Consolas.

بالطريقة التي أراها ، لا ينبغي أن يكون الاحتياطي موجودًا في المقام الأول (انظر PWSH 6 + 7) أو تم تنفيذه بطريقة قذرة (لماذا فقط Consolas؟).

@ SteveL-MSFT وأعتقد أن إصلاحه ليس مخاطرة على الإطلاق ، لأنه تم تقديم الخطأ فقط مع الإصدار 1809 من Windows ويبدو أنه تغيير غير موثق ويعرف أيضًا باسم لا أحد يعرف سبب تغييره على وجه التحديد.

Borkason كما قلت ، كان مثالًا يمكن الاعتماد عليه

أنا مندهش لسماع أنه من المفترض أنه مجرد تغيير عام 1809 ، فقد واجهت مشكلات في تغيير خط وحدة التحكم إلى خطوط نقطية في الماضي.

تم اكتشافه فقط في عام 1809 لأن الخط الافتراضي لوحدة التحكم كان Consolas. قبل ذلك ، أعتقد أنها كانت Lucida Console؟ وعمل الكود بنفس الطريقة لهذا الخط. ما أفهمه من هذا الرمز (الذي كان موجودًا منذ ذلك الحين إلى الأبد وقبل فريقي في فريق PowerShell) هو أنه في مصادر Windows ، لدينا اختصار واحد فقط يستخدم لـ PowerShell وهذا الاختصار يحدد الخط الافتراضي. لذلك عندما تم تغيير الخط الافتراضي ، اشتكى مستخدمو شرق آسيا من أن الحروف الرسومية الخاصة بهم لم يتم عرضها لأن الخط لا يدعمها. لذلك يكتشف هذا الرمز أن الخط والإعدادات المحلية غير متوافقين ويحولهما إلى أحدهما الذي سيعرض.

أنا متردد في إجراء أي تغييرات في Windows PowerShell حتى التغييرات الصغيرة على ما يبدو مثل هذا تؤدي إلى تراجع غير متوقع.

sebgod & all: بعض الأشياء هنا:

توضيحات

1. لا يوجد خط واحد على أي نظام أساسي يتضمن كل حرف رسومي لكل نقطة رمز يمكن تمثيلها في UTF-8.
2. Cmd.exe لا يعرف شيئًا عن الخطوط - Cmd.exe عبارة عن غلاف
3. توفر وحدة التحكم (ConHost.exe) واجهة مستخدم سطر أوامر تقليدية "تشبه المحطة الطرفية" في نظام التشغيل Windows
4. محرك عرض النص الحالي لوحدة التحكم لا يدعم الخطوط الاحتياطية ولا يمكنه عرض معظم الرموز التعبيرية - جربها وسترى الحرف غير القابل للعرض (علامة استفهام في مربع)

المحطة الطرفية ووحدة التحكم

Windows Terminal هو الجيل الجديد من Terminal UX. تشترك في العديد من المكونات الشائعة مع وحدة التحكم في العلبة ، بالإضافة إلى أنها تضيف العديد من الميزات الجديدة بما في ذلك المخزن المؤقت للنص وعارض النص الذي يمكنه / سيقوم بتخزين وعرض جميع صور Unicode تقريبًا.

في النهاية ، سيتم إعادة استيعاب هذه المكونات في وحدة التحكم داخل العلبة ، ولكن ليس إلا بعد أن أصدرنا Terminal v1.0 ولديهم الوقت ليتم اختبارهم جيدًا في الاستخدام الفعلي.

بوويرشيل

كما يشير @ SteveL-MSFT ، لا يعرض PowerShell Core (PSCore) هذه المشكلة وبما أن PSCore هي مستقبل PowerShell ، فنحن نشجعك على استخدامها حيثما أمكن ذلك.

من المحتمل أن يكون تغيير سلوك PowerShell لنظام التشغيل Windows (PS) أمرًا صعبًا لأنه كما نعلم من محاولة إصلاح / تغيير سلوك Cmd ، يمكن أن تؤدي التغييرات الصغيرة التي تبدو غير ضارة إلى حدوث كسر مفاجئ في العالم الحقيقي.

ومع ذلك ، سأناقش مع Steve & Team وسنستكشف ما إذا كان يمكن تعديل PS لاختيار خط غير نقطي (مثل Consolas / Lucida / إلخ) لصفحة الشفرة 65001.

sebgod & all: بعض الأشياء هنا:

توضيحات

1. لا يوجد خط واحد على أي نظام أساسي يتضمن كل حرف رسومي لكل نقطة رمز يمكن تمثيلها في UTF-8.

نعم ، هذا هو السبب في أنني قلت "لا يوجد خط واحد يوفره Windows يغطي جميع الحروف الرسومية المحددة في UTF-8"

1. Cmd.exe لا يعرف شيئًا عن الخطوط - Cmd.exe عبارة عن غلاف

نعم ، آسف لكوني كسولًا ، قصدت فقط الإشارة إلى ما يحدث إذا كتبت "cmd.exe" في مربع بحث Windows

1. توفر وحدة التحكم (ConHost.exe) واجهة مستخدم سطر أوامر تقليدية "تشبه المحطة الطرفية" في نظام التشغيل Windows
2. محرك عرض النص الحالي لوحدة التحكم لا يدعم الخطوط الاحتياطية ولا يمكنه عرض معظم الرموز التعبيرية - جربها وسترى الحرف غير القابل للعرض (علامة استفهام في مربع)

كما فهمت ، لا يمكن للمحرك الحالي عرض أي أحرف من مستويات Unicode الأعلى ، والتي تتضمن (معظم) أحرف الرموز التعبيرية.

الآن يجب أن أكون صعب الإرضاء ، كنت أتحدث عن Font Linking ، المدعوم أو على الأقل يعمل:

بإضافة القيمة Lucida Console تحت المفتاح HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink
بنوع REG_MULTI_SZ والبيانات التالية (أو ما شابه ذلك ، يجب أن تكون خطوط أحادية المسافة):

MSGOTHIC.TTC,MS UI Gothic
MINGLIU.TTC,PMingLiU
SIMSUN.TTC,SimSun
GULIM.TTC,Gulim
YUGOTHM.TTC,Yu Gothic UI
MSJH.TTC,Microsoft JhengHei UI
MSYH.TTC,Microsoft YaHei UI
MALGUN.TTF,Malgun Gothic
SEGUISYM.TTF,Segoe UI Symbol

من الممكن إظهار معظم رموز المستوى الأساسية لـ Unicode عند استخدام chcp 65001 أو منذ عام 1803 عن طريق تعيين صفحة رموز النظام إلى UTF-8 (تجريبي ولكن العمل حتى الآن) ، والذي أفضل شخصيًا استخدام صفحات الرموز المحددة لكل اللغة حيث أستخدم لغات متعددة.

الآن أفضل استخدام Consolas الذي لم يكن يعمل منذ عام 1903 بسبب تحوله إلى الخطوط النقطية.

المحطة الطرفية ووحدة التحكم

Windows Terminal هو الجيل الجديد من Terminal UX. تشترك في العديد من المكونات الشائعة مع وحدة التحكم في العلبة ، بالإضافة إلى أنها تضيف العديد من الميزات الجديدة بما في ذلك المخزن المؤقت للنص وعارض النص الذي يمكنه / سيقوم بتخزين وعرض جميع صور Unicode تقريبًا.

في النهاية ، سيتم إعادة استيعاب هذه المكونات في وحدة التحكم داخل العلبة ، ولكن ليس إلا بعد أن أصدرنا Terminal v1.0 ولديهم الوقت ليتم اختبارهم جيدًا في الاستخدام الفعلي.

نعم لقد استخدمت Terminal UX الجديد بالفعل وهو بالطبع ممتع للغاية للاستخدام ، لكنه لا يسمح بإدخال الأحرف الصينية في الوقت الحالي (آمل أن يتم إصلاح ذلك في النهاية)

بوويرشيل

كما يشير @ SteveL-MSFT ، لا يعرض PowerShell Core (PSCore) هذه المشكلة وبما أن PSCore هي مستقبل PowerShell ، فنحن نشجعك على استخدامها حيثما أمكن ذلك.

من المحتمل أن يكون تغيير سلوك PowerShell لنظام التشغيل Windows (PS) أمرًا صعبًا لأنه كما نعلم من محاولة إصلاح / تغيير سلوك Cmd ، يمكن أن تؤدي التغييرات الصغيرة التي تبدو غير ضارة إلى حدوث كسر مفاجئ في العالم الحقيقي.

ومع ذلك ، سأناقش مع Steve & Team وسنستكشف ما إذا كان يمكن تعديل PS لاختيار خط غير نقطي (مثل Consolas / Lucida / إلخ) لصفحة الشفرة 65001.

إذا كان من الممكن أن تؤدي التغييرات إلى كسر شيء ما وحتى لا يمكننا معرفة ما هو بالضبط ، فلا يمكن تغيير أي شيء في الجهاز مرة أخرى؟

"أصلحت" المشكلة باستخدام Powershell Core. لقد لاحظت أولاً أن أياً من إعدادات Powershell لا تفعل أي شيء (لكنها غيرت الإعدادات على cmd.exe). بعد بضع ساعات من تجربة أشياء مختلفة ، تعثرت على Powershell Core وبمجرد أن قمت بتنزيله ، أصبحت الإعدادات التي حفظتها من قبل سارية بمجرد فتح معاينة Powershell الأساسية.

حصلت على نفس المشكلة أثناء تشغيل بعض الأوامر (بما في ذلك السبق الصحفي) من مدير FAR - هذا التأثير يدمر فقط كيفية عرض FAR. يحدث فقط مع تمكين خيار خط Consolas و beta لاستخدام صفحة الرموز UTF-8 (65001) في وحدة التحكم. لغتي هي الروسية.

كمستخدم نهائي - إنه أمر مزعج حقًا عندما يحاول البرنامج أن يكون أكثر ذكاءً مني. يمكنني التعايش مع علامات الاستفهام بدلاً من بعض رموز UTF-8 ، لكن تغيير هذا الخط يفسد فقط عرض البرامج التي لا ينبغي أن تتأثر على الإطلاق ، مثل FAR manger. هذا ألم.

في الوقت الحالي ، كان علي العودة إلى اللغة الروسية لوحدة التحكم (مرة أخرى من UTF-8) ، ولكن هذا يحد من العمل مع الملفات المسماة باستخدام رموز المواقع الأخرى. آمل أن تتمكن من إزالة علاج Consolas الخاص.

لدي نفس المشكلة ولكن فقط إذا حاولت استخدام وحدة التحكم. ربما @ SteveL-MSFT على حق.
لقد جربت Lucida Console وهذا يعمل بشكل جيد. لذا أعتقد أن Consolas يفتقد بعض الحروف الرسومية لـ UTF-8 (صفحة الشفرة الخاصة بي) ؟!
يعمل Powershell Core 7 بشكل جيد مع جميع الخطوط.

أمر لا يصدق ، لقد اشتريت جهاز كمبيوتر محمول يعمل بنظام Windows في عام 2020 (xps15) ولدي نفس المشكلة. ربما مئات تحديثات Windows في وقت لاحق ، ولا تزال المشكلة قائمة. إذا كان PS Core هو المستقبل في عام 2019 ، فلماذا لم يتم تثبيته في عام 2020؟ قد يكون PS Core افتراضيًا ، وربما يمكن تثبيت PS القديم كخلف في حالة احتياج البعض لمشكلة التوافق. على أي حال ، قمت بتثبيت Windows Terminal ودعونا نجربها.

marcelomgarcia FWIW ،

Rember: يعد Windows PowerShell مكونًا أساسيًا لنظام التشغيل Windows 10 ويضيفه المثبت الافتراضي إلى جهاز الكمبيوتر المحمول لديك. وهو مكون مدعوم بالكامل FWIW. إذا كنت تريد PowerShell 7 ، فهذه عملية تثبيت منفصلة وغير متكاملة.

ما هي لغة جهاز الكمبيوتر الخاص بك؟

شكرا على الشرحdoctordns. إنها مجرد مشكلة محبطة إلى حد ما ، ويبدو أن مشكلة شخص ما بالخارج "بسيطة". أقوم بتثبيت PowerShell 7.

أنا أستخدم اللغة الإنجليزية الأمريكية.