更新：与Alt Gr结合使用时，所有数字都会发生相同的情况。

你知道，这可能在我身上。 当我们得到KeyDown事件时，我们可能没有在TermControl.cpp中的AltGR组合中正确获得vkey。

Kinda无关，但是您使用什么软件通过gif @patriksvensson中的按键获取录音？

@watermelonpizza我使用Carnac显示按键，并使用ScreenToGif捕获窗口。

卡纳克，谢谢！ 我会将其添加到我的好东西列表中：）

我认为这是＃487的副本。

糟糕，看来左手不知道右手在做什么，而我只是创建了一个循环重复链接。

可以使用匈牙利语键盘布局在Windows版本10.0.18362.30上确认此问题。 行为有所不同，具体取决于我使用的控制台：

• cmd：它只写字符，但大写
• Powershell：什么都不做
• git bash：不写任何东西，但是播放默认的提示音

@ zadjii-msft我在terminalInput.cpp找到了与（AltGr）相关的评论。
在我的德语键盘上，控制键状态为LEFT_CTRL_PRESSED | LEFT_ALT_PRESSED而不是看似预期的LEFT_CTRL_PRESSED | RIGHT_ALT_PRESSED 。
此外，所按下的虚拟键例如是“ Q”，而不是某些已经变换的Unicode字符。

因此，我更换了...
https://github.com/microsoft/Terminal/blob/660d31ac522186e615ec243de2a434c273464828/src/terminal/input/terminalInput.cpp#L415 -L419
与...

if (keyEvent.IsAltPressed() && keyEvent.IsCtrlPressed())
{
    return false;
}

...而且有效！ 目前。 😅它将把处理委托给WM_CHAR / _CharacterHandler，根据Google的说法，它对AltGr处理更健壮。 （？）（我还不太熟悉Windows编程。）
你觉得这怎么样？ 我应该提交公关吗？

@lhecker太棒了！ 现在这实际上是可用的🎉

@lhecker是的，请提交PR。 在德语键盘上，我现在无法输入管道，这使终端有点难以使用。

我觉得我的更改不正确。 一定有一个原因为什么不是所有字符都由WM_CHAR对吗？
因此，我想先等待@ zadjii-msft或@ DHowett-MSFT的反馈。 我认为？ 😅

实际原因在Terminal.cpp中

DWORD modifiers = 0
                      | (ctrlPressed? LEFT_CTRL_PRESSED : 0)
                      | (altPressed? LEFT_ALT_PRESSED : 0)
                      | (shiftPressed? SHIFT_PRESSED : 0);

您可以看到这里从未正确检测到RIGHT_ALT_PRESSED，这会导致TerminalInput :: HandleKey中的keyEvent.IsAltGrPressed返回false。

顺便说一句，修饰符状态由TermControl :: _ KeyDownHandler（）中的_GetPressedModifierKeys（）获取。 可以将修饰符状态直接传递到SendKeyEvent中，而不是布尔值，然后确定是否稍后按下了向左/向右Ctrl，向左/向右alt，向左/向右移位。

并且VirtualKey中已经定义如下，可以在TermControl :: __ GetPressedModifierKeys（）中使用。

        LeftShift = 160,
        RightShift = 161,
        LeftControl = 162,
        RightControl = 163,
        LeftMenu = 164,
        RightMenu = 165,

不错，赶上@sagood！
不幸的是，据我所知，解决此问题还远远不够...
TerminalInput::HandleKey显然假设按下AltGr时，操作系统已经“将UnicodeChar预转换为适当的替代值”，例如德语键盘上的AltGr + Q（= @）则不是这种情况。
这意味着当前围绕IsAltGrPressed()逻辑已经有点缺陷了。

@lhecker我尝试使用RIGHT_ALT_PRESSED来初始化DWORD修饰符。 我测试了AltGr +'+'（=〜），它将正确显示在控制台中。
AltGr + <（= |）也可以。

但是AltGr + Q似乎并没有起作用。 奇怪的。
AltGr + E（=€）也不起作用。

通过设置新的c＃UWP，我观察到使用AltGr时的键序列如下所示：

Menu
Control
Q

（以AltGr + Q为例）

进一步的调试显示，如果您强迫程序运行来自terminalInput.cpp的TerminalInput :: HandleKey的第一个条件分支，如下所示，

if (!fKeyHandled)
            {               
                if ((keyEvent.GetVirtualKeyCode() < '0' || keyEvent.GetVirtualKeyCode() > 'Z') &&
                    keyEvent.GetVirtualKeyCode() != VK_CANCEL)
                {
                     // !!!force the AltGr+'Q/E' case to run here, not the one below
                    fKeyHandled = _TranslateDefaultMapping(keyEvent, GetKeyMapping(keyEvent), GetKeyMappingLength(keyEvent));  
                }
                else
                {
                    ...
                }
            }

AltGr + Q将起作用。

德语键盘上的\的AltGr +ß怎么样？那个有相同的问题

所有AltGr键盘组合都受到相同问题的影响。

有什么进展吗？ 我能够复制的行为，但我不知道，怎么的AltGr情况下，实际上应该处理。 如果有帮助，请看以下内容：

• 我验证了在德语键盘上，AltGr确实已转换为Left_CTRL && LEFT_ALT ，并针对CMD，PS和WSL进行了测试
• 该错误似乎与不及格的测试有关。 切换到德语键盘时，以下测试对我而言失败，但通过了英语键盘：
  
  
  
  • InputEngingeTest:C0
  
  
  • InputTest::TerminalInputModifierKeyTests#metadataSet3以内，包括set10
  
  

@lhecker出于好奇，我采用了您的第一个想法，将isAltGrPressed()替换isAltPressed() && isCtrlPressed() ，并验证了它：

• 适用于CMD，包括@和€，但不适用于PS或WSL
• 实际上无法修复不及格的测试
• 但是反而会破坏英语键盘的MouseInputTest::SgrModeTests#metadataSet20 。

即使我在进一步缩小问题范围方面做得还不够，我仍然认为这些信息可能有用。

@MattKuhr非常有趣。 @和€实际上在PowerShell和WSL中都对我有用。 🤔
（请确保100％确信-这是我与当前主控67f68eb的区别。）

的确，我已更新到当前的主机并再次对其进行了测试。 现在，除了PS中的€以外，其他特殊字符都可以使用。

我不确定是什么原因导致了我之前观察到的行为，使用了完全相同的代码更改。 我开始认为，尽管我进行了多次测试，或者在此期间安装了某些Windows更新，但我在测试时可能会对部署有些混乱。

这是在当前主机上进行测试时使用德语键盘设置的屏幕截图：

我在Win 10.0.18362.116的Debug和Release（x64）上都对其进行了测试。 我还尝试更改系统语言，但没有效果。 似乎有点奇怪，只有在这种特定情况下，€才能正确翻译。

说，如果您先Remove-Module PSReadline ，它会在PowerShell中开始工作吗？ （不用担心：它只会影响您当前的会话。）如果是这样，我们有一些想法！

@ DHowett-MSFT我使用昨天的主结帐版本进行了测试，在18362.113中德语键盘布局没有变化（语言设置为英语）

Alt Gr + q => Q ，预期@
Alt Gr + < => < ，预期|
Alt Gr + + => + ，预期~
Alt Gr + ß => ß ，预期\
Alt Gr + 2 => 2 ，预期²
Alt Gr + 3 => 3 ，预期³
Alt Gr + e => E ，预期€

对于常规字符，Alt Gr的作用类似于shift。 没有修饰符的值将保留任何其他字符。

@ DHowett-MSFT实际上确实😃

其他键继续工作。 另外，以前的小号3会被写为普通的3，现在正确显示了，如下面的屏幕快照所示。

你好

只是在这里说明这也会影响芬兰QWERTY布局，使所有AltGr组合（如@，|，{}，[]，〜，\等）均无法使用。

所有这些似乎都可以与WSL，cmd和powershell中@lhecker的补丁一起正常工作。 谢谢@lhecker ！

您好，它也适用于French Azerty键盘布局。 谢谢@lhecker

瑞士德语键盘上的Alt Gr组合出现问题，例如“ Alt Gr + <”（反斜杠，但导致“ <”）。

我已经更新了此问题的标题，以使路人对其跟踪的内容更加明显。

@ zadjii-msft我在terminalInput.cpp中找到了与（AltGr）相关的注释。
因此，我更换了...
https://github.com/microsoft/Terminal/blob/660d31ac522186e615ec243de2a434c273464828/src/terminal/input/terminalInput.cpp#L415 -L419
与...
如果（keyEvent.IsAltPressed（）&& keyEvent.IsCtrlPressed（））
{
返回false；
}
...而且有效！ 目前。 😅

此更改还使我在法语键盘上可以使用AltGr。 到目前为止，已使用CMD，Windows PowerShell 5.1，PowerShell Core 6.2.1（都需要在VScode中工作的非官方PSReadline 2.0.0beta4）进行了测试。

此更改还使我在法语键盘上可以使用AltGr。 到目前为止，已使用CMD，Windows PowerShell 5.1，PowerShell Core 6.2.1（都需要在VScode中工作的非官方PSReadline 2.0.0beta4）进行了测试。

我检查了我的PSReadline版本，并从2.0.0升级到2.0.0-beta4，确实成功了，现在€和³在5.1和6.2.1的PS中也能正常工作。 😄

尽管我确实找到了另一个似乎也与PSReadline相关的错误，但与AltGr或键盘布局无关。 如下所示，在终端机中， CTRL 2转换为"和CTRL 7 （在GER布局上，在美国为CTRL / ）到^_

对于第一种情况，删除PSReadline可以解决问题，对于第二种情况则不能。 我尝试了其他数字和特殊的char键，但是这两个是到目前为止我只能找到的两个实例。 对于5.1和6.2.1，其行为相同。 PSReadline是2.0.0beta4。

我们是否应该为此单独提出一个问题？

我还可以在葡萄牙语（葡萄牙）键盘上看到相关问题。
预期：Alt Gr + 2/3/4/7/8/9/0应该输出@£§{[]}，Alt Gr + e应该得到€

Windows终端：
-PS核心：Alt Gr +数字触发PSReadline DigitFunction，除了7个输出^ _
-PS核心：Alt Gr +€不执行任何操作
-Windows Powershell：与PS Core相同
-CMD：Alt Gr +数字输出数字，除了7个输出^ _
-CMD：Alt Gr + e输出E

内置控制台：
PS核心：Alt Gr + 2/3/4/7/8/9/0输出@£§{[]}，Alt Gr + E不执行任何操作
Windows PowerShell：与PS Core相同
CMD-所有作品

Windows 10 1903年18362.116
PS核心6.2
Windows终端0.1.1431.0
PSReadline 2.0.0

当“ Alt Gr”键组合不起作用时，一种经过尝试的真正解决方法是使用Alt + NumPad Code 。

但是，这也不起作用！

657“ Alt +数字键不起作用”

我建议无论谁解决这个问题，也要解决这个密切相关的问题。

我也可以用冰岛语键盘验证这一点。 我们使用AltGr编写这些代码：
@ |€{[]} \ µ〜`^

附带说明：此问题几乎出现在所有Microsoft命令行技术中。 它已经在OpenSSH中出现，在PSReadline中也出现了类似的问题，在这里再次出现，所有AltGr组合都不起作用。

每当我尝试使用命令行时，总是会出现输入问题。 我仍然无法在远程会话中使用PowerShell，因为Home-End无法使用，并且它们仍然无法通过SSH使用。

不知何故，这个终端-SSH-PSReadline三角形被诅咒了。

在这里，我正在使用PT-BR键盘布局。

要获得/ ，请使用Alt Gr + Q

在终端机中使用时，其作用类似于撤消命令。 它只是重新输入我的最后一个命令/字母/单词

@MathiasMagnus

所有AltGr组合都不起作用的地方。

您的意思是说所有AltGr组合都不起作用？

说，如果您先Remove-Module PSReadline ，它会在PowerShell中开始工作吗？ （不用担心：它只会影响您当前的会话。）如果是这样，我们有一些想法！

对我不起作用（法语“ AZERTY”布局）

所以.....有什么新想法吗？ 因为修复...

C ++
如果（keyEvent.IsAltPressed（）&& keyEvent.IsCtrlPressed（））
{
返回false；
}
...

没有为我工作<。<

编辑：

检测计算机上定义的主要键盘语言，然后执行rebind-stuff @microsoft ，不是更聪明吗？

@Hedrauta很奇怪，代码更改对您不起作用。 您使用的是哪种键盘布局？ 对于与AltGr结合使用的xxx值，在常规CMD中， Ctrl+Alt+xxx对您有什么作用？ 据我所记得， Ctrl+Alt应该总是等于AltGr ...

因此，要收集一些测试数据：对我来说， @ lhecker的补丁似乎运行良好。 这是德语键盘布局：

码头| Alt Gr + ß？\ | Strg + Alt + ß？\
-|-|-
旧版cmd.exe | \ | \
旧版pwsh.exe | \ | \
Windows Terminal， master ， cmd.exe | ß | ß
Windows Terminal， master ， pwsh.exe | _（无）_ | _（没有）_
Windows终端， master + @lhecker修补程序， cmd.exe | \ | \
Windows终端， master + @lhecker修补程序， pwsh.exe | \ | \

与https://github.com/microsoft/terminal/issues/521#issuecomment -501148984中的结果相同
@lhecker的

但是在pwsh ，€-符号在德国布局中仍然无效。

命令：
C:\Users\jkann>2² 3³ 7{ 8[ 9] 0} ß\ +~ <| Q@ E€
密码：
PS C:\Users\jkann> 2² 33 7{ 8[ 9] 0} ß\ +~ <| Q@ E

@Hedrauta很奇怪，代码更改对您不起作用。 您使用的是哪种键盘布局？ 对于与AltGr结合使用的xxx值，在常规CMD中， Ctrl+Alt+xxx对您有什么作用？ 据我所记得， Ctrl+Alt应该总是等于AltGr ...

它也没有帮助我...
我什至尝试根据该代码制定自己的解决方法，但到目前为止还没有运气...

我正在使用PT-BR键盘布局，请尝试以下组合：

CMD，Powershell和WSL.exe
AltGr + Q = /

使用Windows Terminal时
WSL： AltGr + Q =就像撤消命令一样，它重写了我最后键入的字符。
Powershell，CMD： AltGr + Q =产生像^_这样的奇怪字符打印

编辑：
为了帮助可视化：

正确的输入应该是
AltGr + Q = /
AltGr + W = ?
AltGr + [ = ª
AltGr + ] = º

@ renatop7使用CtrlAlt代替AltGr会得到什么？

@ renatop7使用CtrlAlt代替AltGr会得到什么？

相同的结果

在终端之外，即在标准CMD或Windows Powershell或Powershell Core中？ CtrlAlt是否始终像AltGr一样运行？

在终端之外，即在标准CMD或Windows Powershell或Powershell Core中？ CtrlAlt是否始终像AltGr一样运行？

是的，在航站楼外面，它运行良好。
与AltGr或Ctrl + Alt一起使用，我得到了预期的结果。

15分钟前提取：根本没有工作
好吧，Microsoft甚至致力于解决与此问题相关的解决方案吗？

@Hedrauta很奇怪，代码更改对您不起作用。 您使用的是哪种键盘布局？ 对于与AltGr结合使用的xxx值，在常规CMD中， Ctrl+Alt+xxx对您有什么作用？ 据我所记得， Ctrl+Alt应该总是等于AltGr ...

嗯，标准德文一个？ 这里是它的外观屏幕： https :
我将尝试通过宏键入密钥。

就像，我的左Alt键是Shift键，而不是Alt键...
尝试结果
Ctrl + Q ^ Q
CTRL + Alt + QQ
只是Q q
Alt + QQ

将尝试gif，然后更新评论
编辑：当尝试gif时，我意识到，我的Alt键被识别为错误...。 也会研究它;），但是我对c ++或....没有任何经验；）

仅作为我的cpp菜鸟，我检查了几个文件，然后发现了
C：\ Program Files（x86）\ Windows Kits \ 10 \ Include \ 10.0.17763.0 \ um \ WinUser.h
所以....对于德国布局，VK_Menu不存在，对吧？ 我们只是拥有VK_LMENU，对吧？
我将尝试一些更改并进行一些测试...稍后将在结果中进行编辑
编辑1：建造需要很长时间，就像我重建整个系统一样
编辑2：在构建完整个东西之后，它不起作用了……但是我意识到，VK_RMENU是AltGr，而VK_LMENU是我们希望按下以获取@或\的键。
但是VK_MENU看起来也可以，但是可能分配有误
这有点让我感到困惑，在干净地获取，重建和小睡之后会检查这一点

对于德语键盘布局，情况更糟，因为应该只输出@ Alt Gr + Q会删除当前行输入。
wsl不会发生这种情况，我也不会看到它为WT配置-那么这是怎么发生的？

仍然是一个问题：
键盘：比利时（点）AZERTY，可在普通外壳中使用
温维尔：18362.175
终端版本：0.2.1715.0

_我想请大家避免发表评论，说他们也在处理这个问题。

到现在为止，每个人都应该清楚，此问题会影响大量的按键组合，并且可能会导致同样大量的意外副作用，同时使用多种语言，Windows版本，键盘等。
一半以上的评论是#metoo风格的，完全无法解决此问题，
仅使有用的评论不那么明显。
实际上，对于一个博学多才的Windows开发人员来说，要解决此问题并提交PR，这实际上是所缺少的，并且将提供很大的帮助。

同时，每个能够编译此项目的人都可以随意替换这段代码： https :

通过我的这个实验性修复：

if (keyEvent.IsAltPressed() && keyEvent.IsCtrlPressed())
{
    return false;
}

这应该可以修复大多数键盘语言的大多数键组合，例如，德语（或类似）键盘上的字符如@{}[] 。

PS：我不以任何形式与微软有任何关系，而写这篇文章是因为我个人认为这些“ #metoo”注释过于嘈杂/无用。 🙂
PPS：我敢肯定有些人想知道为什么我自己不提交PR。 引用我自己的话：“虽然我觉得自己的更改不正确。一定有理由为什么不是所有字符都由WM_CHAR吗？” 这意味着我实际上不知道上述修复程序的弊端是什么以及如何正确执行。

PPS：我敢肯定有些人想知道为什么我自己不提交PR。 引用我自己的话：“虽然我觉得自己的更改不正确。一定有一个原因，为什么不是所有字符都由WM_CHAR处理对吗？” 这意味着我实际上不知道上述修复程序的弊端是什么以及如何正确执行。

知道的一种方法是提交PR，并由团队纠正。 这有点矫kill过正，但我​​认为这会使事情进展得更快。

11436

请注意，在使用示例应用程序（例如VtPipeTerm）时，alt-gr键可在其中使用。

@HBelusca VtPipeTerm不基于新的UWP终端，因此不会出现此问题。
您可以阅读＃1436，以获得对潜在问题的一种可能解释。

@lhecker它不是基于Cascadia的，但是它使用相同的底层伪

谢谢@HBelusca

特殊键在终端和Windows应用程序中已经使用了多年。 为什么现在在2019年出现这个问题？ 您是否为终端程序完全重新实现了输入系统？ 我希望有必要这样做，并重新引入几年前修复的错误：s。 由于代码页，语言键盘映射和特定于Windows的键，此问题在Linux中很常见，但是此关键错误在应用程序的预览版中提供，该版本可在商店中购买并在任何地方公开

@ifilgud由于预览原因，这是商店中提供的预览版本。 该问题已被分类，也有提交的PR，因此无需抱怨就此问题发表评论。

@patriksvensson我知道我主要是在抱怨，这不是“礼貌”，但也要求提供技术原因来解释此类错误的原因。 我预计会有一些小错误可以修正到即将完成的版本（预览版）中，但不是一个应该在终端的演变中出现的错误，除非从头开始编写并且仅以英语进行测试（我想这是原因无法在第一个Alpha版本中检测到此错误）。 我打开终端并尝试将“ cd \”作为第二个命令（第一个是“ dir”），但它没有用。 作为软件开发人员，这对我影响很大。

在应用实验性修复后， @ lhecker到目前为止非常好。 非常感谢！！

非常感谢所有指出并已解决此问题的人。 🌷

MS Store应用程序多久更新一次？
那么，我们什么时候可以期望在store应用中修复问题？

很想与终端一起使用，但是使用德语键盘，即使没有altgr，您甚至无法编写{ } 。 😅

挪威语Bokmål（nb-NO）键盘布局也遇到了同样的问题。 无法创建[]或{}或$。 没有这些功能，PowerShell基本上就被打破了。
在Windows 10 1903 18362.175上使用UWP / Microsoft Store版本0.2.1715.0。

通过AltGr的hu_HU布局： \ | & @ $ ; # <> {} []我的意思是我经常打开括号，尖括号或方括号，反斜杠，管道，美元符号，井号，“ at”，“ and”，分号...哦等待，每一行？？ :)

_我想请大家避免发表评论，说他们也在处理这个问题。

到现在为止，每个人都应该清楚，此问题会影响大量的按键组合，并且可能会导致同样大量的意外副作用，同时使用多种语言，Windows版本，键盘等。
一半以上的评论是#metoo风格的，完全无法解决此问题，
_仅会使有用的注释不可见_。

更新：与Alt Gr结合使用时，所有数字都会发生相同的情况。

您是如何进行gif记录的？

@ Karl-WE在线程中向下看。

@ DHowett-MSFT可能是一个好方法，请在底部显示一条消息来锁定此线程

虽然此问题仍然存在，但是该终端对于Powershell来说非常不可用
对于那些无法修复的人，我想提出Windows 10 1903的解决方法。

解决方法：
使用Windows键+。
转到特殊字符选项卡选择您的字符
切换到终端并插入字符

将其保持解锁状态可以使人们有空间报告每个无效的密钥，从而使他们不再针对每个无效的密钥提交单独的_issues_。 我好疼

可能会有更多情况下特殊字符无法正常工作。 如果要在丹麦语键盘上输入@字符，可以使用3种方法：Alt Gr + 2，向左Ctrl +向左Alt + 2或向左Alt +数字键64
前两个选项给出报告的结果OP。
最后一个选项在powershell中起作用：
Onpres左Alt +数字键64 digit-argument: 64
Onrelease左Alt：64个@字符
在cmd中
Onpres左Alt +数字键64： 64
Onrelease左Alt： @导致64@
在wsl
Onpres Left Alt + Numpad 64： (arg: 64)
Onrelease左Alt：64个@字符

好点@saadanerdetbare！

您的Alt + Numpad问题似乎源于以下事实：新的终端（Cascadia）在您输入这些代码时会将适当的转义代码发送到外壳。 但是同时，应用程序的另一部分是处理这种情况，将Alt + Numpad代码转换为适当的字符并将其插入到外壳中。 这导致您的@字符重复出现64次的有趣副作用（由于已将以下字节发送到shell： \x1b6\x1b4@ ）。

您可以通过在这两行之间添加以下附加代码来进行尝试：

if (!inEventsToWrite.empty() && static_cast<KeyEvent*>(&*inEventsToWrite.front())->GetCharData() == '\x1b')
{
    return;
}

这将阻止Cascadia将这些转义代码发送到外壳中。 之后，您的字符（例如@）将正常显示。
或者，您可以删除此代码块以达到相同的效果。

〜 @saadanerdetbare如果您可以创建一个单独的问题详细说明您的问题，
👉＃1401
应该先搜索其他问题。 ♂‍♂️

PS：我确实不得不说，看到社区越来越愿意自行调试这些东西，而不是依赖未知的其他人，这会让我个人感到非常自豪。 🙈🙂

@saadanerdetbare推迟提交新问题，即＃1401：smile：

我仍然在预览应用程序上遇到此问题，我有比利时键盘，无法编写@

@solispauwels，您必须等到下一个版本（或现在自己构建当前的master分支）。

嗨，我刚刚在德语键盘上测试了该提交，除了altgr-E以外，其他所有功能都应打印出€符号。 老实说，我并不需要经常在终端机中使用它，但我想我还是会提到它。 不过，像altgr-m这样的µ也可以工作。

更新：我认为您可以忽略这一点，€符号在标准powershell中也不起作用，因此这似乎不是终端的错，应该早点检查一下。

一切似乎都可以在法语键盘上运行： AltGr+é"'(-è_çà)=$e产生预期的~#{[|`\^@]}¤€

我也使用法语键盘（但我在比利时），并且遇到AltGr +的问题字符。 |＃{} @例如无效。 我正在使用Windows 10 v1903上Windows存储0.2.1715.0的最新版本。

@meuter，您必须等到下一个版本（或现在自己构建当前的master分支）。

Microsoft Store上提供的预览版本中尚未包含来自＃1436的修复程序

@antoineco @ sba923谢谢，这就是我的想法。 我只是克隆了仓库。 vs2017更新完成后，我将从源代码重新构建它：-)

感谢大家为此付出的辛勤工作，并在我们的收件箱中填入报告。 特别感谢@lhecker提交修复程序！ 我们刚刚将其与v0.2.1831.0服务版本一起提交给商店。 商店可能需要一些时间来处理它。

我们刚刚提交给商店

因此，根据我将应用程序发布到Windows应用商店的经验，它需要3天到3周的时间😉

我们刚刚提交给商店

因此，根据我将应用程序发布到Windows应用商店的经验，它需要3天到3周的时间😉

似乎不到6小时。 😋

无论如何，现在在我的瑞典语键盘上一切似乎都很好。 👍

现在可以使用德语键盘👍

它可以与0.2.1831.0版的法语键盘一起使用！ 谢谢

它可以与0.2.1831.0版的法语键盘一起使用！ 谢谢

已确认！

很好！

@ DHowett-MSFT v0.2.1831.0似乎包含此修复程序，但不包括其他一些错误修复程序，例如电力线字体或复制/粘贴键盘，这是否正常？

我确认Alt-Gr可以工作，但是使用Ctrl-Alt来访问相同的键盘键却无法可靠地工作（如果有的话）。

在0.2.1831.0版本中，AltGr组合现在可以与芬兰语键盘一起使用。

@solispauwels版本0.2.1831.0中的唯一修复是发行说明中提到的修复。

请知道，许多1803或更高版本的操作系统可能会遇到Windows Store版本11905.1001.4.0的错误。
商店将“堆叠”要下载的应用程序（请参阅图像），但即使启用了自动下载并且网络不是计量连接，也不会下载这些应用程序。

受影响的用户必须在Microsoft Store中按“检查更新”，以最终获得固定的Store App并启动所有待处理的应用下载。

我确认此问题已在新版本的Terminal中修复。 非常感谢。

我也可以确认，现在已修复。 您可能要取消固定问题。

除了欧元键（AltGr + e）（至少在西班牙语键盘中）以外，它均有效。 其余组合正常工作

来自@ifilgud

除了欧元键（AltGr + e）（至少在西班牙语键盘中）以外，它均有效。 其余组合正常工作

已在Windows 10 1903（18362.175）上进行测试，使用的最新版本为2019-07-08，使用“比利时（Period）” AZERTY键盘。

测试结果：

• 我在键盘上可以使用的所有组合（包括欧元（€）货币符号）都可以在Windows终端中配置为默认的3个控制台中的2个中使用：PowerShell Core和'cmd'（Windows命令提示符）
• 只有在“Windows PowerShell中”确实欧元符号（€）不工作
  
  
  
  • 然而，它没有在PowerShell的怀旧作品直接从Windows开始推出，以及
  
  

Imo，这是与Windows PowerShell相关的新问题，不特定于承载该控制台的Windows Terminal。

我确认@DeChrist的观察。 另一方面，按Ctrl-Alt +（按键）不能按预期方式工作（如果要使用此组合而不是AltGr）。

在运行Windows Terminal Preview版本0.2.1831.0的Windows 10版本18362.175（带有法语键盘）上， AltGr+E的确在以下所有外壳中产生€ ：

• 命令
• Windows PowerShell 5.1
• PowerShell Core 6.2.1
• PowerShell Core 7.0.0-预览.1

在PowerShell_中还有其他AltGr问题的人可以检查他们正在运行的PSReadLine版本吗？

$psrl = Get-Module PSReadLine $psrl.Version $psrl.PrivateData.PSData['Prerelease']

@ sba923 ：

PS C:\Users\myself> $psrl = Get-Module PSReadLine
PS C:\Users\myself> $psrl.Version

Major  Minor  Build  Revision
-----  -----  -----  --------
2      0      0      -1

PS C:\Users\myself> $psrl.PrivateData.PSData['Prerelease']
beta2

@HBelusca您可以尝试：

1. 禁用PSReadLine
2. 升级到最新的beta4 ，请参阅https://github.com/PowerShell/PSReadLine

• Windows 10 1903
• Windows终端0.2.1831.0
• PowerShell v7（包括PSReadline 2.0.0-beta4）
• 德国QWERTZ键盘布局

✅ AltGr + Q →@
✅ AltGr + E →€
❌ Ctrl + Alt + Q →q

这尤其令人沮丧，因为还有一个与mstsc相关的错误，Microsoft至少已经忽略了十年，如果打开RDP会话，则AltGr + Q停止工作。 在这种情况下， Ctrl + Alt + Q仍然有效，因此许多人将其用作解决方法。

Microsoft应该做的是不要触摸键盘流。

外壳程序（explorer.exe）应该捕获所需的任何按键，并将其他所有内容传递给下游。
Terminal.exe最终应仅捕获Alt-F4，甚至可能不捕获Alt-F4，explorer.exe确实应捕获并应用于活动进程。

这意味着Terminal.exe应该只接收键盘流并将其传递给活动的子进程。 没有其他的。

CMD.exe [command.com]应该知道如何捕获所需内容，然后将其余内容传递给自己的子级。

WSL应该获得尽可能多的原始输入。 不要操纵AltGr。 Ctrl-Alt和AltGr不是相同的键盘序列。 在Linux中，存在使用ctrl-alt -...的快捷方式，其产生的结果与AltGr -...不同。

您只有一次机会可以正确执行此操作。 近40年来的第一个机会。 请不要浪费这个机会-微软，我在看着你:)

@thorsig啊，如果四十年前设计Win32输入堆栈时，我们只有在附近。 不幸的是，我们没有，所以有两种主要的方法来接收键盘输入：

• 作为字符，没有修饰符（因此我们无法检测到ALT使其通过终端管道发送）或按方向
• 作为扫描代码，具有修饰符和方向，但实际上只是_物理键位置的表示_

当您开始在操作系统级别以下查看时，扫描代码_are_“尽可能原始输入”模式。 但是，在将它们传递给需要文本输入的应用程序之前，确实需要一点点烹饪。 （编辑以添加：）终端应用程序确实更喜欢将其输入作为文本。 我们无法通过SSH连接发送扫描代码！ 即使我们能够做到，接收者也将需要了解键盘布局以进行翻译。 没头的机器可能没有键盘布局。 （/编辑）

如果像“获得他们按下的文字字符并发送它”那样简单，那么您必须相信我们会做到这一点。 我们不会设计疯狂的解决方案，因为我们是疯狂的人！ ：微笑：

好吧，尽管那时我可能不太了解如何处理输入流，但我仍然在身边。

但是，Linux默认情况下使用原始键码，因此没有问题。 但是，您的ssh连接示例存在缺陷，因为ssh永远不会直接由终端应用程序执行-内部有一个外壳（或整个操作系统抽象，如WSL）负责到达外壳的内容。

如果您所说的正确，那么曾经为Windows编写的每个应用程序（在资源管理器上运行）都必须实现自己的固有键盘处理。 他们没有。 因为它照顾了上游和下游。

我看过代码，分享了“ SMH”。 我可以做得更好吗？ 给定时间，大概。 我能负担得起吗？ 考虑到我没有时间自己做，可能没有。

我仍然发现它值得一提，它已经过分设计，并且会在某些时候（可能早于晚）在下游引起问题。

好吧，尽管那时我可能不太了解如何处理输入流，但我仍然在身边。

但是，Linux默认情况下使用原始键码，因此没有问题。 但是，您的ssh连接示例存在缺陷，因为ssh永远不会直接由终端应用程序执行-内部有一个外壳（或整个操作系统抽象，如WSL）负责到达外壳的内容。

WSL不会进行任何特定类型的翻译。 conhost.exe或Windows终端（如果通过例如XMing运行图形应用程序，则为Gnome终端）会进行适当的转换以发送给pty。 甚至外壳……并不是外壳本身完成了大部分工作。 它是终端驱动程序和位于主端的应用程序（同样，它是conhost.exe，Windows Terminal，如果愿意的话可能是Cygwin Terminal和Linux终端应用程序）。

如果您所说的正确，那么曾经为Windows编写的每个应用程序（在资源管理器上运行）都必须实现自己的固有键盘处理。 他们没有。 因为它照顾了上游和下游。

大多数应用实际上并不关心原始键盘输入。 通过某些Win32库以固有的有损方式处理该问题。 他们不直接使用原始键盘输入。 大多数游戏只关心角色，而游戏可能恰好关心实际布局输入。 两种方法都可以。

我看过代码，分享了“ SMH”。 我可以做得更好吗？ 给定时间，大概。 我能负担得起吗？ 考虑到我没有时间自己做，可能没有。

我仍然发现它值得一提，它已经过分设计，并且会在某些时候（可能早于晚）在下游引起问题。

我建议您研究Linux类似物Gnome-Terminal，并检查它是否更简单或更复杂。 我怀疑更复杂，因为X实际上比GDI32或正在使用的任何窗口API更奇怪。

从0.2.1831.0有回归吗？
在丹麦语键盘上，Windows Terminal Preview v0.3.2142.0不响应AltGr。

Windows Terminal（预览版）
版本：0.3.2142.0
Microsoft Windows 1903 [版本10.0.18362.267]

我有丹麦语键盘和Windows版本v0.3.2142.0 Windows 10.0.18362.239，它是没有任何语言包的英文操作系统。 Alt Gr特殊字符在这里起作用，Ctrl + Alt序列不起作用

我有丹麦语键盘和v0.3.2142.0 Windows版本10.0.18362.239，它是英文操作系统，没有任何语言包。 Alt Gr特殊字符在这里起作用，Ctrl + Alt序列不起作用

我的操作系统：Win10 Home 1903 Build 10.0.18362.267
尽管默认安装了丹麦语语言包，但安装了其他美国语言包的丹麦语操作系统。
嗯-版本10.0.18362.267和10.0.18362.239-有线索吗？!!!

我的操作系统：Win10 Home 1903 Build 10.0.18362.267
尽管默认安装了丹麦语语言包，但安装了其他美国语言包的丹麦语操作系统。
嗯-版本10.0.18362.267和10.0.18362.239-有线索吗？!!!

要获取所有详细信息：
我在
赢得10 Enterprise en-US 1903 build 18362.239
丹麦语键盘，无语言包

只需尝试使用默认的美国语言包登录帐户，然后在该终端上安装了终端，然后切换到丹麦语键盘，以查看所选的语言包是否有影响但没有运气。

不知道这是否可能是某些人的线索，但在从1809年升级到1903年之前，屏幕键盘（ c:\windows\system32\osk.exe ）在所有主机应用程序，cmd.exe，ubuntu / wsl中都表现出相同的行为和powershell.exe（忽略AltGr），但在1903年，此问题似乎已解决。

我可以确认_some_ AltGr序列不起作用。
AltGr Q （= @ ）对我有用，而8 （= [ ）不起作用。

我已经在本地构建了商店版本v0.3.2142.0以调试此问题。 因为我无法弄清楚如何构建AzureConnector，所以不得不将其排除在外： https ://gist.github.com/lhecker/320662cb3fda70af1ca58eabf9f2579a
s事实证明，我本地构建的v0.3.2142.0可以正常工作。 所有AltGr序列
只有终端的商店版本没有。 因为我排除了它，AzureConnector可能在这里有问题吗？ （我是说我怀疑情况确实如此，但是请确保...）

@ DHowett-MSFT @miniksa您（或某人）可以重新检查v0.3.2142.0的商店版本并将其与本地构建的版本进行比较吗？

我有同样的问题。 该终端不适用于该问题，因为必须使用AltGr。 为什么关闭此线程？ 这应该是头等大事。

为什么关闭此线程？

@MasMedIm在仔细检查后，您可能会注意到我们认为此错误已修复，甚至发布了带有此修复程序的版本。

@lhecker非常不寻常。 由于Azure连接器位于不同的层（连接，而不是控件）中，因此它与该连接器没有任何关系……但这很有趣。

您（或某人）可以重新检查v0.3.2142.0的商店版本并将其与本地构建的版本进行比较吗？

我在AltGr特殊字符起作用的版本是商店版本

AltGr（ ~#{[|`\^@]}¤€ ）在这里可以正常使用法语键盘，Windows 10版本1903内部版本18362.267和Windows Terminal Preview 0.3.2142.0

@ sba923我也有法语键盘和相同的Windows版本。 无效的AltGr组合为：＆〜＃{[|`\ ^€ù\
我的终端也是从商店下载的。 我将尝试在本地构建它以供查看。

只是为了详细说明我的情况-有些AltGr +组合键确实有效，而有些组合则无效。

不起作用：

| 关键 AltGr +键，预期：|
| ----- | ----------------------- |
| '2'| '@'|
| '3'| '£'|
| '4'| '$'|
| '7'| '{'|
| '8'| '['|
| '9'| ']'|

作品：

| 关键 AltGr +键，预期：|
| ----- | ----------------------- |
| '0'| '}'|
| '´'| '|' |
| '<'| '\'|
| '¨'| '〜'|
| 'e'| “€” |

注意：“´”，“¨”是死键类型。

系统：Windows 10 64bit Home 1903 Build 10.0.18362.267
Windows Terminal：预览版v0.3.2142.0-商店版本
键盘布局：丹麦语。

@MasMedIm，@ sba923，@lhecker性-你的Windows版本主页像我这样的？
编辑：忘记我的问题。 我本来打算在那儿开始追赶大雁;-)，但是@lhecker似乎已经解决了回归问题！

@ DHowett-MSFT @ henrik-jensen等 al .：我找到了回归的原因。 ¯\ _（ツ）_ /¯
……这使我们所有人都需要提早注意到一些白痴。 😂

新的profiles.json包含Ctrl+Alt+[0-9]类型的快捷方式，可以快速跳转到选项卡1-10。
如果从“设置”文件（ Ctrl ， ）中删除这些快捷方式
遗憾的是，某些组合（例如用于€ AltGr E）尚未成功，因此有人必须花费必要的时间来解决此问题。

由于旧的Windows API的工作方式不同，很难可靠地区分Ctrl Alt快捷键和实际的AltGr按键，但是我将检查这种情况是否可以改善。

@lhecker🥇👍
已确认。 朱比

不幸的是，某些组合，例如€ AltGr E，至今还没有成功，因此必须花费必要的时间来解决。

AltGr E->'€'可以在我的丹麦语键盘布局上使用。 我将尝试在我的地图上添加德国布局，以查看其设置是否可复制。

咬一下子弹怎么样？ 保留旧的CMD.EXE以用于旧版（DOS）应用程序，并仅为将来设计新的Terminal？ 并不是说向后兼容性不是很好-但是有时您只是想打平关系...

@lhecker🥇👍
已确认。 朱比

不幸的是，某些组合，例如€ AltGr E，至今还没有成功，因此必须花费必要的时间来解决。

AltGr E->'€'可以在我的丹麦语键盘布局上使用。 我将尝试在我的地图上添加德国布局，以查看其设置是否可复制。

已安装的德语〜Kezboard〜ups，键盘:-) *和AltGr E->'€'在此设置中有效。

编辑：*'z'/'y'在德语/丹麦语键盘上互换。

新的profiles.json包含Ctrl+Alt+[0-9]类型的快捷方式，可以快速跳转到选项卡1-10。

由于某些原因，这些快捷方式在我的设置文件中为alt + [0-9]，因此我没有遇到问题

现在我想到了一些问题：

• @lhecker也许我们应该对可发现性/历史记录进行回归的新问题，您可以为此添加补丁程序解决方案吗？ 编辑：太好了- @lhecker提出了拉取请求＃2235
• 我不知道默认的〜settings.json〜 profiles.json是在哪里生成的。 它不是资源，所以我认为它在某处进行了硬编码？ 编辑：找到它CascadiaSettings.cpp L369
• 应该选择哪些替代快捷方式。 也许@saadanerdetbare在他的profiles.json （它们在0.3.2142.0之前的版本中是默认值吗？编辑：似乎是这样-＃2014）

@lhecker @ henrik-jensen很有道理。 我是在商店发布后立即从商店安装的，并且对profiles.json进行了一些更改，因此，如果更新由于是自定义而不是默认设置而没有覆盖文件，则不会获得Ctrl + Alt快捷键

@ DHowett-MSFT @ henrik-jensen等 al .：我找到了回归的原因。 ¯_（ツ）_ /¯
……这使我们所有人都需要提早注意到一些白痴。 😂

新的profiles.json包含Ctrl+Alt+[0-9]类型的快捷方式，可以快速跳转到选项卡1-10。
如果从“设置”文件（Ctrl）中删除这些快捷方式，则回归是固定的。
不幸的是，某些组合，例如€ AltGrE，迄今尚未奏效，有人必须花费必要的时间来解决此问题。

由于旧的Windows API的工作方式不同，很难可靠地区分CtrlAlt快捷键和实际的AltGr按键，但是我将检查这种情况是否可以改善。

输入响应，的确是Ctrl + Alt + [0-9]设置

@saadanerdetbare ，是的，@ zadjii-msft已将您的设置更改为此处的新设置＃2014

我确认新快捷键确实会破坏法语键盘上的AltGr（ ~#{[|`\^@]} ）。

我们中的一些人没有看到回归的原因与0.3升级不覆盖现有的profiles.json ，这在Windows Terminal Preview v0.3版本中进行了记录：

注意：如果您以前在此版本之前安装了Terminal，则这些键绑定仅在您删除profiles.json并允许其重新生成后默认显示。 您可以将原始的profiles.json保存在其他位置，并复制自定义项，或者仅手动添加这些键绑定。 我们知道这不是理想的体验，我们正在努力改善这一点。

可以使用ctrl + alt + shift + _digit_，尽管这并不是很容易输入...

@ henrik-jensen我打开了＃2235。

@thorsig您已经被告知Windows API环境中的事务状态。
尤其是考虑到Linux上的bash（像将来可能会在Windows上使用的大多数shell）一样，_not_不会收到原始键码，而是会接收转义序列的常规文本。 终端需要从键盘事件生成的转义序列。 您的Linux shell _不_处理原始键码。 您的终端会。
在继续进行此操作之前，您应该首先了解xterm和vt100（及更高版本）如何工作。
顺便说一句：Linux上的键码也只是键盘上扫描码的虚拟（！=原始）抽象-参见keymaps.5 。 唯一的区别是，在Windows上，很早以前就决定Ctrl + Alt与AltGr相同，这是因为某些键盘缺少AltGr键，但仍然希望能够以某种方式按下AltGr。 决定现在可能超过60岁的人们。 更改此设置并非易事，并且只有微不足道的好处（因为实际上您已经可以在实际中检测到AltGr按键）。

我确认新快捷键确实会破坏法语键盘上的AltGr（ ~#{[|`\^@]} ）。

我们中的一些人没有看到回归的原因与0.3升级不覆盖现有的profiles.json ，这在Windows Terminal Preview v0.3版本中进行了记录：

注意：如果您以前在此版本之前安装了Terminal，则这些键绑定仅在您删除profiles.json并允许其重新生成后默认显示。 您可以将原始的profiles.json保存在其他位置，并复制自定义项，或者仅手动添加这些键绑定。 我们知道这不是理想的体验，我们正在努力改善这一点。

可以使用ctrl + alt + shift + _digit_，尽管这并不是很容易输入...

使用alt + _digit_更容易，它类似于gnome-terminal中的快捷方式。
它可以在我的法语键盘上使用。

如果您使用Alt + digit ，请注意，您将无法将这些键发送到控制台应用程序中。

： tada：此问题已在＃2235中得到解决，Windows Terminal Preview v0.3.2171.0 。：tada：

方便的链接：

• 发行说明
• 店铺下载

AltGr（ ~#{[|`\^@]}¤€ ）在这里可以使用法语键盘，Windows 10版本1903内部版本18362.267，Windows Terminal Preview 0.3正常工作。 2171 .0，并且选项卡切换快捷方式设置为Ctrl+Alt+digit 。

做得好！

感谢您的确认！

不客气！

已为我的系统确认0.3.2171.0修复-丹麦语键盘Win10 Home 1903内部版本10.0.18362.267。
删除了我的profiles.json以获取默认设置，现在AltGr也可以用于新安装（我假设）。
辛苦了@lhecker和其他所有人。

嗨，我认为我在版本0.7上有这个问题。

我不能使用数字键盘ou AltGr + Q（三星笔记本电脑的巴西ABTN2键盘没有问号/斜杠键）在键盘上输入斜杠键。

编辑：我不能输入任何AltGr键。

删除旧版本的PSReadline后，eveything现在可以正常工作。

FWIW，我已经编写了附件的PowerShell脚本，以验证系统上的PSReadline版本/哪个版本处于活动状态。

CheckPSReadLineStatus.zip

高温超导

要解决与beppler报告的问题相同的问题，请执行以下操作：

删除旧版本的PSReadline后，eveything现在可以正常工作。

在高级Powershell Session中执行以下操作：

Install-Module -Name PowerShellGet -Force
Exit

从提升的cmd会话中执行以下操作：
powershell -noprofile -command "Install-Module PSReadLine -Force -SkipPublisherCheck -AllowPrerelease"

此问题的状态如何？
因为查看链接的问题似乎已解决，但对我而言仍然无效。 为了在意大利语键盘布局上打印〜字符，我习惯于执行Alt + 126，但这取决于终端的类型，它具有不同的行为，但是在任何一种情况下，我都无法获得〜字符可以直接在基础外壳中执行打印（git / cmd / powershell / wsl不在Windows终端中嵌入）

这是我使用最新版本的Windows终端发生的情况，在撰写本文时，它是：

Windows Terminal (Preview)
Version: 0.8.10091.0)

@ilmax我在＃3117中破坏了Alt + Numpad输入。 现在，＃3117已被合并，相关的问题已得到解决，我们可以将数字键盘输入重新引入代码库。
不过，我会将其设置为可选的，可配置的行为，因为我可以肯定终端应用程序的大多数潜在用户将不再从中受益。 因此，该应用程序应默认将所有可能的键盘输入发送到外壳，以便您可以配置更高级的vim等按键绑定。
＃4192合并后，实施此操作应该会容易一些。 您必须在此处添加其他逻辑states ，而v键源自数字键盘，而不是常规数字键。 随时提交公关！ 🙂

@lhecker感谢您的快速回复，我只是想知道它的状态，因为我发现的每个问题
不知道我会为此提出一个PR，我从未在before之前看过代码，所以尽管您有建议，我真的不知道从哪里开始。

我只是想知道如何修复git rebase -i的工作流，因为现在我必须打开记事本++之类的东西，键入〜字符，将其复制并粘贴到终端中。

据我所知：您在关于AltGr的话题中有关于_alt +数字键盘序列_的问题？ 这可能就是为什么您找到的所有线程都关闭的原因：AltGr问题已修复。

我确实相信我们有一个单独的问题跟踪alt +数字键盘输入问题。

是的，您是对的，对不起您的困惑。 我认为＃657可能是正确的