You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some additional discussion/context on #138. The following line caused unit test failures when used with capturing regex due to the presence of the (escaped) \r:
'262|2023-04-21T23:24:06.0630000-04:00|en|00000051|_rsv_35827_-1_1_0_0_S13095D61_E13095D61|Further testing is required.�����,\\r���)������ ��, assist me with this evaluation.|38151741aad7fe51',
This issue was worked around for unit testing in #139, but we should confirm that this is not a persistent issue in regex capturing that will cause errors/fail to capture during actual execution. Assigning this to myself since I hope to have time to take a look at it next week, but completely fine if someone else wants to look at it in the meantime.
The text was updated successfully, but these errors were encountered:
This issue is caused by bad base data. The data in the actual raw log line is unicode characters (specific to FFXIV unicode space) and should have been added with '\uXXXX' instead of raw copy/pasted. I unfortunately don't have the original raw log lines to properly add them in here.
The parse logic should be handling unicode properly to begin with since it handles JP/CN/KR characters fine.
Just need to properly encode the data I guess? If there's still an issue with parsing after that, then it's an actual bug.
Edit: Should be something like this, please double check.
'262|2023-04-21T23:24:06.0630000-04:00|en|00000051|_rsv_35827_-1_1_0_0_S13095D61_E13095D61|Further testing is required.\uefbf\ubdef\ubfbd\uefbf\ubdef\ubfbd\uefbf\ubd2c\u5c5c\u72ef\ubfbd\uefbf\ubdef\ubfbd\u29ef\ubfbd\uefbf\ubdef\ubfbd\uefbf\ubdef\ubfbd\uefbf\ubd20\uefbf\ubdef\ubfbd, assist me with this evaluation.|38151741aad7fe51',
Some additional discussion/context on #138. The following line caused unit test failures when used with capturing regex due to the presence of the (escaped)
\r
:This issue was worked around for unit testing in #139, but we should confirm that this is not a persistent issue in regex capturing that will cause errors/fail to capture during actual execution. Assigning this to myself since I hope to have time to take a look at it next week, but completely fine if someone else wants to look at it in the meantime.
The text was updated successfully, but these errors were encountered: