Upon importing a data source with non-ascii column names, "u_rplcd_n_ascii_XXX" fields are automatically createdIssue <!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Upon importing a data source with non-ascii column names, fields with column names "u_rplcd_n_ascii_XXX" are automatically created in an import set table instead of being loaded to the existing "u_[non-ASCII]" fields. Release<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Washington Patch 10, Xanadu Patch 5, Yokohama and above Resolution<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } This is the currently expected behavior - the system now continue to support existing import set table column names with non-ascii characters and new import set column names (with non ascii labels) are generated with only ascii characters. The automatically created fields with column names like "u_rplcd_n_ascii_XXX" are automatically assigned both an attribute (e.g., import_attribute_name=項目2) and a label (e.g., 項目2) that map to the original double-byte header found in the Excel or CSV import file. VesrionResolution Xanadu Patch 5 -> XanaduPatch 8 Yokohama -> Yokohama Patch 3 Due to the impact of the following PRB, you need to set a temporary system property (com.glide.loader.replace_non_ascii_column_name=false) to allow existing u_[non-ASCII] fields to continue working.PRB1850436:Unexpected column creation when importing a excel file with Japanese Headers Xanadu Patch 9 and above Yokohama Patch 4 and above Zurich and above Existing u_[non-ASCII] fields and their associated transform maps will continue to work.However, when executing Load Data, fields in the format u_rplcd_n_ascii_XXX will be created automatically instead of u_[non-ASCII] fields for any newly added columns of the Excel and CSV files. Notice: System property com.glide.loader.replace_non_ascii_column_name has been deprecated.If any issues are caused by existing u_[non-ASCII] fields, we recommend recreating the fields using supported formats.Do not use "com.glide.use_column_name_optimizer" ※1 ※1 Some customers might have changed "com.glide.use_column_name_optimizer" system property to avoid the creation of u_[non ascii] fields. Also since PRB1850436 ("Unexpected column creation when importing a excel file with Japanese") issue was fixed in Xanadu Patch 9, Yokohama Patch 4, and later releases, we recommend removing the "com.glide.use_column_name_optimizer" system property after upgrading to one of these versions. Once "com.glide.use_column_name_optimizer" system property is removed, when the customer import new non-ascii columns, new fields with column names "u_rplcd_n_ascii_XXX" will be created automatically, instead of fields with column names "u_X". The existing "u_X" format fields in import set tables will continue to work. However, if there's any issues on importing in the future, the customer might need to remove the existing "u_X" fields and import again to regenerate the fields using the "u_rplcd_n_ascii_XXX" format.