Tales of Series (перевод игр от команды Temple of Tales Translations)

[Evil Finalist]

История русской локализации Tales of Rebirth (PS2)
Глава 7. Очистка строк от лишних данных и работа с нестандартными поинтерами
https://vk.com/temple_of_tales_translations
https://temple-tales.ru/games/tor/russian_localization.html

В начале прошлой главы на первом изображении я наглядно показал, что блоков с поинтерами в исполняемом файле всего более 40 штук. А теперь представьте, что все ранее описанные этапы нужно повторить заново с каждым из них. В таких случаях даже программистам приходится искать вручную каждый блок и идентифицировать все поинтеры. Потому что автоматизировать этот процесс очень сложно, ведь расположение поинтеров в большинстве блоках хаотичное, так как в одних расстояние между поинтерами одно, а в других – другое. Кроме того, расстояние в одном блоке поинтеров между разными указателями тоже может отличаться. А вот насколько сильно – вы можете посмотреть на приведённом изображении ниже:



Визуализация разных расстояний между поинтерами. Красным отмечены области с расстоянием по 4 байта, синим – по 8 байт, а зелёным – по 12 байт соответственно.

В этом случае возникает вопрос: а как в таком беспорядке abcde будет справляться с распознаванием поинтеров? Автор данного приложения этот момент не продумал. Если мы зададим программе интервал, то при извлечении текста в рамках этого интервала приложение будет пытаться прочитать поинтеры принудительно. Иначе говоря, после считывания обычных указателей приложение рано или поздно попытается считать поинтер из той области, которая не является поинтером. И именно в этот момент в строке с извлечённым текстом от программы стоит ожидать различного рода мусора, который будет очень сильно мешать работе в целом. Эти мусорные данные среди полезного текста выглядят примерно вот так:



Розовым, чёрным и зелёным цветами отмечены блоки, которые программа ошибочно принимает за поинтеры и пытается извлечь текст по этим адресам. В результате прочитанные значения могут выходить за пределы массива данных файла, что в свою очередь создаёт различную несогласованность адресов. На данном изображении это отмечено серыми стрелками. Кроме того, если при попытке считывания по ложному смещению попадается первый байт со значением 0x00, то при извлечении эта строка будет пустой и в сформированном блоке поинтера ничего, кроме тега [END], мы не увидим.

Напомню, что файлы с извлечёнными строками текста содержат свой блок данных для каждого поинтера, и в этих файлах их можно спокойно копировать и удалять, а также склеивать между собой как угодно, не нарушая синтаксис. Примерно вот так:



И здесь, как вы уже, скорее всего, догадались, все мусорные блоки с текстом, которые были идентифицированы ошибочно, придётся удалять вручную. По-другому от них никак не избавиться, потому что с помощью abcde этот процесс не автоматизировать. Можно удалять мусорные блоки прямо в текстовом редакторе, но для визуального облегчения всё это я копировал в эксель и уже там сортировал удобным образом. Поскольку в текстовом редакторе весь синтаксис тегов сливается с полезным текстом и различать мусорные данные там довольно непросто: есть риск ошибиться и захватить полезные строки. В экселе же есть возможность графически выделить разные строки, что явно ускоряет идентификацию. Наглядно это выглядит вот таким образом:



Это ещё не всё, что хотелось бы осветить по поводу поинтеров. Дело в том, что, помимо простых указателей с поправкой, ещё существует второй тип поинтеров, которые записаны в функциях в виде инструкций прямо среди основного кода исполняемого файла. И не всегда их легко различить визуально. В нашем случае несколько таких поинтеров попадается в исполняемом файле, и работу с ними мне тоже пришлось освоить. Приложение abcde нам никак не поможет, потому что уровень сложности в этом случае резко возрастает и требует более глубоких знаний и понимания кода архитектуры процессора MIPS R5900, который используется в играх для платформы PlayStation 2. Для поиска таких поинтеров в очередной раз обращаемся к инструментам обратной разработки: IDA Pro или Ghidra. Как и в прошлый раз, опишу этот процесс, выполняемый с помощью IDA Pro.

⬜ Этап 1. Поиск функции, в которой прописан нестандартный поинтер

а) Повторяем первоначальные шаги, которые были описаны в прошлой главе. Ищем нужные нам строки с текстом в исполняемом файле с помощью хекс-редактора, поинтеры которых не получилось найти. В качестве примера я выбрал строку вот с этим текстом: Chambers. Загружаем SLPS_254.50 в IDA Pro. Ждём, как приложение просчитает взаимосвязи всех функций. Далее щёлкаем по вкладке "Hex View-1" и ищем здесь начало того же текста, который нашли в хекс-редакторе. Вам необязательно сначала искать текст в хекс-редакторе, а потом в IDA Pro. Если вы достаточно хорошо ориентируетесь в IDA, то можете сразу начинать поиски текста в этом приложении. После того, как нашли строку с текстом, щёлкаем по вкладке "IDA View-A". Вы увидите вот такое окно:



б) На представленном изображении в прошлом пункте наглядно видно, как чуть ниже строки с текстом программа прописывает адресацию к функции, в которой указан индекс к началу этого текста. Наводим курсором на эту взаимосвязь "# DATA XREF: .text:00153B3C↑o" и щёлкаем 2 раза:



в) После того как два раза нажали на взаимосвязь "# DATA XREF: .text:00153B3C↑o", вас должно перекинуть на окно, которое по своей сути является просмотрщиком дизассемблированного кода:



Таким образом мы попадаем в одну из функций, в которой прописаны определённые инструкции для работы с данной строкой. Именно здесь нам и предстоит ориентироваться в поисках нестандартного поинтера.

⬜ Этап 2. Определение верхней и нижней частей среди инструкций для формирования целого поинтера

а) В первую очередь важно понять, что придётся часто переключаться между окнами "IDA View-A" и "Hex View-1", а также постоянно держать в голове поправку FF000 для точных расчётов. Можно упростить себе задачу и держать под рукой калькулятор для подсчётов в шестнадцатеричной системе счисления. Найденная область функции содержит данные сразу для работы с тремя строками:

Оригинальный текст японской версии:
1) 謎の館
2) The Hidden Chambers
3) この中に何があるのか……<__>全てが謎につつまれた館。

Текущий вариант перевода строк в нашей локализации:
1) Таинственный особняк
2) [SPACE]
3) Особняк, окутанный тайнами.<__>Никто не знает, что в нём.

Все они относятся к названию и описанию локации "Таинственный особняк". Но для того, чтобы вычислить каждый поинтер для всех этих строк, потребуются определённые манипуляции c идентификацией инструкций, в которых и спрятаны поинтеры. Кроме того, поинтеры для каждой строки разделены на 2 части и наша задача каждую из них найти, развернуть и правильно сложить.

Перед тем, как приступить к следующему шагу, нужно немного рассказать об особенностях данного типа поинтеров. Процессоры MIPS работают с 32-битными указателями. Размер любого поинтера в памяти составляет 32 бита. Проще говоря, это 4 байта. Например: 0x0022C268. Это в свою очередь накладывает определённые ограничения, потому что любая инструкция MIPS занимает ровно 4 байта. В этот размер можно уместить: код операции, номера регистров и числовую константу (immediate). В итоге на константу в одной инструкции остаётся всего 2 байта. Это означает, что в одну инструкцию умещается только половина поинтера. Именно поэтому весь указатель собирается из двух инструкций. Первая инструкция загружает верхние 2 байта, а вторая добавляет нижние 2 байта. В этом и заключается основная задача: понять, где в инструкциях прописаны числовые константы для верхней и нижней части поинтера.






б) В окне просмотра дизассемблированного кода "IDA View-A" нужно обратить внимание на следующие строки:

lui $a0, 0x23 # '#'
lui $a1, 0x23 # '#'
lui $v1, 0x23 # '#'

li $a0, unk_22C268
li $a1, aTheHiddenChamb # "The Hidden Chambers"
li $v1, unk_22C290

Первая группа из трёх строк отвечает за верхние части поинтеров, а вторая группа из трёх строк – за нижние. В итоге получаем вот такую взаимосвязь:

Верхняя часть 1 поинтера = lui $a0, 0x23 # '#'
Верхняя часть 2 поинтера = lui $a1, 0x23 # '#'
Верхняя часть 3 поинтера = lui $v1, 0x23 # '#'

Нижняя часть 1 поинтера = li $a0, unk_22C268
Нижняя часть 2 поинтера = li $a1, aTheHiddenChamb # "The Hidden Chambers"
Нижняя часть 3 поинтера = li $v1, unk_22C290

Для того, чтобы корректно отследить каждую часть, а потом сделать определённые изменения в соответствии с нашим переводом, возьмём вторую строку из первой группы и вторую строку из второй группы:

Верхняя часть 2 поинтера = lui $a1, 0x23 # '#'
Нижняя часть 2 поинтера = li $a1, aTheHiddenChamb # "The Hidden Chambers"

Как только щёлкаем в любом месте по нужной нам инструкции в окне "IDA View-A", вся её часть подсвечивается соответствующим образом и в окне "Hex View-1". Пробуем нажать на "0x23" в окне "IDA View-A" (строка верхней части 2-го поинтера), а затем переключаемся на окно "Hex View-1" и наблюдаем, что IDA Pro выделяет все 4 байта этой инструкции:



Первые 2 байта "23 00" в этом выделенном блоке и являются числовой константой, а именно верхней частью нужного нам поинтера. Запоминаем или записываем это значение. Далее приступаем к поиску нижней части поинтера. Для этого пробуем нажать на "aTheHiddenChamb" в окне "IDA View-A", а затем переключаемся на окно "Hex View-1" и снова наблюдаем, как IDA Pro выделяет все 4 байта другой инструкции:



Здесь первые 2 байта "78 C2" тоже являются числовой константой, той самой нижней частью нужного нам поинтера. Теперь у нас на руках обе части. Перед тем как их сложить, нужно их развернуть – не забываем, что на консоли PS2 порядок построения байтов в поинтерах записывается в little-endian виде:
23 00 » 00 23
78 C2 » C2 78

Затем складываем:
00 23 + C2 78 = 00 23 C2 78

Мы практически получили готовый поинтер, но не всё так просто. Если из него вычесть поправку FF000 и в исполняемом файле SLPS_254.50 в хекс-редакторе перейти по этому адресу, то мы не попадём на нужную нам строку, потому что существует определённое правило ещё одной поправки для инструкций, но уже для верхней части. Заключается оно в том, что если 2 байта из нижней части меньше или равны значению 0x8000, то к верхней части прибавляется 1 (то есть +0x10000), а если меньше, то эта поправка не нужна.

В соответствии с этим правилом корректируем полученный поинтер, так как значение нижней части поинтера в нашем случаем больше этого числа: C278 > 8000.

Пересчитываем:
00 23 C2 78 - 00 01 00 00 = 00 22 C2 78

Вот только теперь мы получили правильный поинтер, от которого нужно отнять поправку FF000, о которой я просил вас не забывать:
00 22 C2 78 - 00 0F F0 00 = 12 D2 78

Открываем исполняемый файл в хекс-редакторе и убеждаемся, что все расчёты были проведены правильно и что по данному адресу находится нужная нам строка с текстом:



⬜ Этап 3. Ручное изменение нестандратных поинтеров в хекс-редакторе

а) Ну а теперь, когда нам известно, как найти все нестандартные поинтеры, то можно приступить к их изменению в соответствии с тем переводом текста, который я привёл в начале второго этапа. Есть попытаться вставить текст третьей строки, то он свободно умещается в изначально отведённое пространство. Но со второй строкой сделать это не получится – при попытке укладки переведённого текста в первую строку он начнёт перекрывать текст второй строки. Потому что для первой строки в исполняемом файле всего выделено 15 байт, а наш вариант "Таинственный особняк" занимает 20 байт + ещё нужно учитывать 1 байт окончания строки со значением {00}. Итого для нашего варианта перевода необходим 21 байт, что явно превышает размер 15 байт. Так как укладка текста будет идти в изначальный адрес оригинальной первой строки, то значения поинтера здесь менять не нужно, а вот значения поинтера для второй строки придётся изменить. Для новичков это может звучать немного запутанно, поэтому приведу несколько скриншотов, чтобы стало понятно получше:

[Evil Finalist]

История русской локализации Tales of Rebirth (PS2)
Глава 8. Подготовительный этап работы с текстовыми файлами
https://vk.com/temple_of_tales_translations
https://temple-tales.ru/games/tor/russian_localization.html

Как только разобрались со всеми основными файлами, поинтерами и таблицей кодов, можно приступать к организации удобной среды для работы с текстом и его обратной вставки. Но перед этим я хочу ненадолго вернуться на 12 лет назад и показать на примере нашего первого проекта Tales of Symphonia, как плохо была организована работа по обработке текстовых файлов. Как говорится, первый блин комом. В самом процессе перевода текста и его обратной вставке выявилось очень много неудобств, которые впоследствии привели к выработке удобных алгоритмов, чтобы не топтаться на месте и не выполнять двойную, а зачастую даже тройную работу.

Так уж сложилось, что RangerRus сформировал свою таблицу кодов для Симфонии в простой нумерации от <0001> до <9999> без возможности её правки, а я принял это как данность. Соответственно, в каком виде текст был извлечён, так мы с ним и работали. Мне даже не приходила голову мысль о том, что можно повлиять практически на всё что угодно на любом этапе в каждом процессе. В итоге мы получили чуть более 900 файлов вот в таком виде:



На первый взгляд может показаться, что это даже удобно, так как бывают случаи, когда текст нагромождён куда большим количеством тегов, а также не имеет меток имён персонажей, в чём ориентироваться ещё сложнее. Но тут стоит уточнить: мы не пытались придать какой-то иной вид всем этим файлам ТХТ. Это значит, что переводчики каждый раз, снова и снова, открывали и закрывали буквально все файлы в текстовом редакторе – вручную. Это постоянно плодило много лишних операций. Ещё больше масла в огонь подливало приличное количество дубликатов строк, перевод которых постоянно приходилось копировать. А что ещё хуже, так это изменение перевода какого-то важного и часто встречающегося термина, который потом приходилось переправлять во всех остальных файлах.

Звучит ужасно, не правда ли? Это пример абсолютной неорганизованности как самого процесса работы, так постобработки текста. В какой-то момент я решил сделать небольшую навигацию по файлам и, по сути, это был первый толчок к тому, чтобы в будущем создавать собственные лок-киты для облегчения работы с переводом, но об этом я расскажу позже в следующей главе. Как выглядела попытка первого варианта облегчения работы с кучей текстовых файлов можно посмотреть на изображении, приведённом ниже:



В данной таблице указана общая информация по каждому файлу: название, тип, локация, описания, наличие НИПов, наличие диалогов с Зелосом (квест), наличие диалогов с котисами, процент перевода и редактирования, хронологический порядок файлов относительно сюжета и многое другое.

Данный файл создавался мной в виде таблицы Excel в течение нескольких месяцев. Для того, чтобы заполнить все эти данные, мне потребовалось пройти игру ещё один раз, попутно проставляя различные метки напротив названий файлов. Это немного облегчило работу над переводом текста, но незначительно, так как файл создавался уже ближе к концу перевода.

Когда мы приступили к следующему проекту, мне очень сильно захотелось создать какую-то свою среду для работы с текстом, которая бы не просто помогала, а значительно ускоряла процесс перевода и редактирования. Да так, чтобы это было возможно даже в том случае, когда всю игру переводит не только один человек. Но чтобы всё это работало как часы, нужно заблаговременно выполнить ряд задач. Именно об этом и пойдёт речь в этой главе. Я покажу полный процесс обработки текстовых файлов, начиная с извлечения текстов и заканчивая формированием единой таблицы Excel для создания лок-кита.

⬜ Этап 1. Создание списка файлов и их копирование/перемещение с помощью приложения copyfiles

а) Во время работы над переводом Tales of Symphonia у меня не было необходимости постоянно копировать и перемещать файлы по разным директориям и поддиректориям. Потому что практически все основные файлы всегда находились в каком-то одном месте. Но как только я принялся работать с файлами Tales of Graces f и Tales of Rebirth, то выяснилось, что там каждый файл мог находиться в своей директории или в поддиректории – это с самого начала доставляло головную боль. Повторив процесс копирования из одного места в другое несколько десятков раз, я понял, что теряю очень много времени на решение элементарных задач, которые каждый раз должны выполняться автоматически, чтобы вообще на них не отвлекаться. Сначала я подумал о приложении Total Commander и создании пакетного bat-файла, в котором хотел прописывать все действия, но меня всё равно не устраивал ручной процесс создания списков и адресов. Поэтому я в очередной раз спросил RangerRus, не может ли он сделать такую программу, которая по моей команде будет создавать списки с адресами и копировать все нужные файлы в одно место, а потом, с помощью другой команды, перемещать всё обратно в исходные директории. Разумеется, такую простую задачу он выполнил очень быстро и своей программе дал название "copyfiles". С тех пор я пользуюсь ей при работе практически со всеми нашими проектами. Она продолжает стабильно экономить много времени. Я даже стал воспринимать её как какой-то стандарт, и без создания списка обратного перемещения файлов больше не работаю. Ссылка для скачивания данного приложения приведена во второй главе. А теперь я немного опишу её, чтобы было понятно, насколько она удобна и как вообще ей пользоваться.

В качестве примера возьмём все распакованные контейнеры SCPK из Tales of Rebirth. Для этого нужно воспользоваться приложением ToR toolkit, которое распаковывает все файлы формата SCPK в каждую отдельную одноимённую папку. После того, как мы получили 744 папки с нумерацией от 10197 до 11180, важно понять, что в каждой папке находится множество файлов разных форматов. Наша задача с помощью copyfiles выбрать какой-то один формат и задать условия, при выполнении которых приложение составит список путей к файлам, а также скопирует их все в одно место. Я выбираю файлы формата SCE, потому что именно в них находятся сюжетные диалоги и многие другие строки, которые нужно переводить.

Перемещаем папку SCPK со всеми 744 директориями в корень той папки, где находится copyfiles, затем создаём пакетный bat-файл, в котором прописываем следующие условия:

copyfiles_3.copyfiles_+1_format.bat
copyfiles.exe copyfiles SCPK *.sce*
pause

Запускаем этот файл, и программа автоматически скопирует все файлы расширения SCE в папку copyset_out_dir, а также создаст файл copyset.ini, в котором сформирован список всех скопированных файлов, а также их исходный путь.



Данные манипуляции можно применять абсолютно к любым типам файлов.

⬜ Этап 2. Склейка всех ТХТ-файлов в единый файл с помощью приложения TXTCompile

а) Теперь с помощью ToR toolkit из всех файлов SCE можно извлечь текст. Программа извлекает текст в файлы ТХТ и присваивает им те же названия. Наша дальнейшая задача склеить все ТХТ-файлы в единый файл. Делается это для того, чтобы работать со всем текстом в одном месте, а не мучаться с каждым файлом по отдельности. В этом нам поможет приложение TXTCompile, которое тоже создал RangerRus по моему заказу. В сети можно найти аналоги этой программы, но использовать многие из них при определённых условиях оказалось неудобно. Поэтому я попросил Рейнджера сделать ещё одно приложение, которое удобным образом склеивало бы все файлы ТХТ в единый файл. Кроме того, в этом файле должны быть отдельные строки с метками и названиями файлов, которые были склеены. А уже после различных изменений в этом файле программа должна расклеивать единый ТХТ-файл на исходные отдельные составляющие с полным сохранением структуры данных по количеству строк и кодировке (процесс расклейки будет описан в одной из следующих глав).

Перемещаем все файлы ТХТ в корень той папки, где находится TXTCompile, затем создаём пакетный bat-файл, в котором прописываем следующие условия:

TXTCompile_v1.0_compile+name_txt.bat
TXTCompile_v1.0.exe compile *.txt COMPILED.txt
pause

Запускаем этот файл, и программа автоматически склеит все файлы расширения ТХТ в единый файл COMPILED.txt.



Созданный файл COMPILED.txt выглядит вот так:



⬜ Этап 3. Создание списка дубликатов строк и их отсеивание с помощью приложения TxSrt

а) На этом этапе необходимо максимально обработать полученный файл COMPILED.txt так, чтобы конечный результат был наиболее удобным для переводчиков и редакторов. Огромную помощь в этом сослужит приложение TxSrt, которое тоже создал RangerRus по моему заказу. Потому что рано или поздно дубликаты строк будут доставлять такую огромную боль, что задумаешься о том, чтобы вообще навсегда избавиться от проблем с ними. К слову, сам Рейнджер продолжил использовать эту программу в своих будущих проектах.

Итак, для начала нужно проанализировать файл COMPILED.txt. Для этого создаём пакетный bat-файл, в котором прописываем следующие условия:

TxSrt_1-maketab.bat
TxSrt.exe maketab COMPILED.txt
pause

Запускаем этот файл, и программа проанализирует весь COMPILED.txt на предмет дубликатов строк, а в качестве отчёта создаст файл COMPILED.COPYTAB.txt. Чтобы лучше всего показать эффективность этой программы, я пропущу через неё склейку всех файлов диалогов из игры Tales of Graces f. Ведь в этой игре у нас получается чуть более 1 300 000 строк. Столько не сможет принять даже Microsoft Excel, так что для проведения теста это подойдёт отлично. Если вам интересно всё содержимое COMPILED.txt из PS3-версии Tales of Graces f, то вы можете скачать архив с этим файлом по ссылке чуть ниже, а содержание COMPILED.COPYTAB.txt выглядит примерно вот так:



Скачать #1
https://temple-tales.ru/games/tor/data_design/files/tales_of_graces_f_ps3_scenario_compiled.zip

Скачать #2 (зеркало)
https://disk.yandex.ru/d/Zw7IO7Z2MIuJNQ

То есть в COMPILED.COPYTAB.txt мы видим просто список всех строк, которые имеют хотя бы 1 дубликат. Соответственно, в этот список не попадают строки, у которых дубликатов нет. Кроме того, список формируется по порядку чтения файла с первой строки до последней.

Теперь закрадывается вопрос: а что делать с полученным файлом-отчётом? Его можно спокойно редактировать и удалять все ненужные строки. Важно понимать то, что если вы удалили какую-то строку, то в будущем это очень сильно повлияет на конечный файл. Так как те самые удалённые строки после сортировки дубликатов будут присутствовать по всему документу. В этом и заключается главная задача – оставить в файле те строки, от которых нам нужно избавиться, чтобы не видеть их дубликаты во время работы с текстом. Для первого теста я ничего удалять в файле COMPILED.COPYTAB.txt не буду, а уже на следующем шаге покажу, что у нас получится в обработанном файле.

б) Чтобы получить новый отсортированный файл с учётом файла-отчёта, создаём пакетный bat-файл, в котором прописываем следующие условия:

TxSrt_2-unsort.bat
TxSrt.exe unsort COMPILED.txt
pause

Запускаем этот файл. Программа выполнит свою работу и создаст рядом ещё один файл, но уже отсортированный – COMPILED.UNSORTED.txt. У нас получился файл примерно с ХХХ строками. Большая разница, не правда ли? Было 1 308 304 строк, а теперь стало 24 696. Если более 1 миллиона строк приводит в ужас, то с несколькими десятками тысяч уже можно спокойно работать. Я попытаюсь показать разницу между двумя файлами на приведённом изображении ниже:



В этом отсортированном файле можно спокойно всё переводить так, как вам хочется.

в) Давайте попробуем немного изменить COMPILED.COPYTAB.txt и удалить теги с именами персонажей. Ведь это очень важная часть, которая позволяет понять, к какому персонажу относится та или иная строка. Я удалил эти строки:

<04>($Gf)
<04>($Kf)
<04>($Hf)
<04>($Ff)

После этого запускаем новую сортировку с помощью bat-файла TxSrt_2-unsort.bat. После обработки открываем полученный файл COMPILED.UNSORTED.txt и наблюдаем в нём следующие изменения:



Теперь все строки с тегами имён персонажей остались на своих местах, а все остальные дубликаты строк программа отсеяла.

⬜ Этап 4. Формирование таблицы Excel для работы над переводом и редактированием текста

а) На этом этапе нам нужно удобно уложить отсортированный файл COMPILED.UNSORTED.txt в таблицу Excel. Но сделать это необходимо особым образом, чтобы в процессе работы с текстом можно было крутить любой столбик как угодно, устраивать дополнительную сортировку строк под любые нужды, а также писать столько заметок, сколько захочется. Ведь в этом и заключается главное преимущество таблиц, в отличие от простых ТХТ. Гибкая среда в Excel позволяет настроить всё это практически без ограничений. Степень того, насколько можно сделать рабочий процесс удобнее и легче – зависит только от вас. Более подробно об этом я расскажу в следующей главе, а сейчас просто покажу, как я копирую содержимое файлов ТХТ в таблицу Excel и какие базовые настойки в создаваемой таблице нужно сделать в первую очередь.

Для начала сразу стоит запомнить то, что Excel может скопировать не все знаки из буфера обмена. Например, если в начале каких-то строк стоят кавычки, то при вставке Excel обязательно их удалит. Чтобы этого избежать, сначала при помощи автозамены нужно заменить все кавычки на какой-то отдельный уникальный набор символов, а после вставки – снова при помощи автозамены – вернуть кавычки. Таким образом кавычки у вас останутся на месте. Есть и другие особенности, но всё это познаётся на практике. На приведённом ниже изображении я показываю, как это выглядит:

Скачать #1
https://temple-tales.ru/games/tor/data_design/files/tales_of_graces_f_ps3_scenario_compiled.xlsx

Скачать #2 (зеркало)
https://disk.yandex.ru/d/HNFs3gAYD3xVXQ