[scriptingstudio]

This is based on #1748 where Excel renders char data as "0".
Besides this, Excel COM-object converts char data into its decimal representation. It's impossible to explain such Excel's behavior, so it's the easiest way is to convert char type data into string.

Proposed solution

No single line added, just one extended assignment at line 319:

$ws.Cells[$row, $ColumnIndex].Value = if ($v -is [char]) {$v.ToString()} else {$v}

[scriptingstudio]

Weird Excel's behavior

This script I used to see how Excel processes char data:

$xlapp = New-Object -Com Excel.Application
$xlapp.DisplayAlerts = $False
$xlapp.Visible = $True
$WorkBook = $xlapp.Workbooks.Add()
$sheet1 = $WorkBook.Worksheets.Item(1)
[char]$d1 = 'Q'
[char]$d2 = 0x88
[char]$d3 = $null
$sheet1.Cells.Item(1,1) = 'Literal "Q"'
$sheet1.Cells.Item(2,1) = 'Hex "0x88"'
$sheet1.Cells.Item(3,1) = 'Null'
$sheet1.Cells.Item(1,2) = $d1
$sheet1.Cells.Item(2,2) = $d2
$sheet1.Cells.Item(3,2) = $d3
$WorkBook.SaveAs("$home\desktop\111.xlsx")
$xlapp.Quit()

If data ($d) is a regular char Excel will show its decimal value.
If data is null Excel will show 0 like Export-Excel does for any data.
That's why char is a special case.

[Copilot]

🟢 Approval recommended

The localized conversion addresses the reported defect; regression coverage is recommended but nonblocking.

1 open finding

• Add regression test for preserving [char] values as strings · New

What changed in this PR

Fixes character-valued properties exporting as 0, addressing the reported Get-Volume drive-letter issue.

Changes:

• Converts [char] values to strings before assigning Excel cells.
• Preserves handling of other value types and number formatting.

File	Description
Public/​Export-Excel.ps1	Converts character values to strings during export.

🧠 Review effort: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[dfinke]

I snapshot your update as an image, dropped the image into AI. response below.

I'm not onboard with making the change, first time I've seen this raised as a issue.

There are not enough unit tests from the inception of the module to ensure what this may break.

AI Response

When PowerShell assigns a System.Char ([char]) value directly to an Excel COM object (such as Cells.Item()), .NET's COM Interop marshals the 16-bit Char structure as a numeric variant (such as VT_UI2 / VT_I4) rather than a VT_BSTR text string. Because Excel receives a numeric value across the COM boundary, it renders the underlying decimal Unicode/ASCII code point instead of the text character.

Breakdown of the Code Results

• Literal 'Q' ($d1): The character 'Q' has a Unicode/ASCII code point of 0x51, which Excel displays as decimal 81.

• Hex 0x88 ($d2): The hex value 0x88 cast to [char] retains its code point value, displaying as decimal 136.

• $null ($d3): Casting $null to [char] produces the null character \0 (code point 0), which marshals to decimal 0.

---

How to Preserve Text Character Behavior

To force Excel to display the character representation instead of its code point integer:

1. Explicit .ToString() Call:

$sheet1.Cells.Item(1,2) = $d1.ToString()

2. String Interpolation or Casting:

$sheet1.Cells.Item(1,2) = "$d1"
# or
$sheet1.Cells.Item(1,2) = [string]$d1

3. Prepending an Apostrophe (Excel Text Formatting):

$sheet1.Cells.Item(1,2) = "'$d1"

When processing custom objects or pipeline data before passing values to Excel COM or export functions, ensuring properties with [char] types are cast or converted to [string] avoids unexpected numeric coercion.

[scriptingstudio]

In a nutshell: AI confirms my assumption and states the obvious.
Yes, there seems to be no formal test. But the change is obvious and unmistakable, char type data don't make any sense (because unreliable) and should be converted into string.

[dfinke]

well, it's the first time being reporting in, a decade (maybe there was another) and there is a simple work around
so ... not sure I'm going to add, test, make a release and publish