# VTKHDF: 读入FieldData中的StringArray报错

**URL:** https://discourse.vtk.org/t/vtkhdf-fielddata-stringarray/16154
**Category:** Development
**Tags:** file-formats
**Created:** [November 24, 2025, 7:07am UTC](https://discourse.vtk.org/t/vtkhdf-fielddata-stringarray/16154 "2025-11-24T07:07:19Z")
**Posts on this page:** 3
**Page:** 1

<div class="post-metadata">

### Author: ![jie\_baoer](https://discourse.vtk.org/user_avatar/discourse.vtk.org/jie_baoer/32/7202_2.png) [@jie\_baoer](https://discourse.vtk.org/u/jie_baoer)
#### Post date: [November 24, 2025, 7:07am UTC](https://discourse.vtk.org/t/vtkhdf-fielddata-stringarray/16154/1 "2025-11-24T07:07:19Z")

</div>

When I was testing vtkhdf, I found that when the read StringArray was n rows and multiple columns, an error would be prompted

ERROR: In vtkHDFUtilities.cxx, line 558

(nullptr): Dataset: ndims: 2 greater than expected ndims: 0 plus one.

ERROR: In vtkHDFUtilities.cxx, line 602

(nullptr): Error H5Dread

[simple\_unstructured1.vtkhdf](https://discourse.vtk.org/uploads/short-url/yF421wUbJ0xgg5wUEYAy1JLzP1f.vtkhdf) (4.0 MB)

---

<div class="post-metadata">

### Author: ![lgivord](https://discourse.vtk.org/user_avatar/discourse.vtk.org/lgivord/32/3543_2.png) [@lgivord](https://discourse.vtk.org/u/lgivord)
#### Post date: [November 24, 2025, 8:32am UTC](https://discourse.vtk.org/t/vtkhdf-fielddata-stringarray/16154/2 "2025-11-24T08:32:47Z")

</div>

Hello @jie_baoer,

Indeed string array is not well supported by the vtkHDFReader/vtkHDFWriter, there is an issue about that here : [https://gitlab.kitware.com/vtk/vtk/-/issues/19771](https://gitlab.kitware.com/vtk/vtk/-/issues/19771). We need to fix that at some point.

---

<div class="post-metadata">

### Author: ![jie\_baoer](https://discourse.vtk.org/user_avatar/discourse.vtk.org/jie_baoer/32/7202_2.png) [@jie\_baoer](https://discourse.vtk.org/u/jie_baoer)
#### Post date: [November 24, 2025, 8:37am UTC](https://discourse.vtk.org/t/vtkhdf-fielddata-stringarray/16154/3 "2025-11-24T08:37:57Z")

</div>

Thanks for the info! I’ve noted the limitation and will use an alternative method to handle string data.  
Looking forward to the fix in a future release.
